1 Общее по проекту

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Общее
Необходимо разработать библиотеки и мобильное приложение для смартфона, удовлетворяющее следующим требованиям:
Минимальная версия ОС, поддерживаемая приложением, должна быть: Android - 14.0, iOS -18.0.
В качестве бэкенда будет использован SAAS решение, с доступом через REST API. 
Задание будет выдано в виде задач в системе управления разработкой (таск-трекер). Каждая задача будет помечена соответствующим спринтом. Каждая задача должна пройти все следующие этапы на канбан доске (предусмотрено ограничение в получении баллов в случае, если задача не удовлетворяет условия ниже; если обнаружили ошибку в трекинге, можно откатиться/отредактировать и продолжить работу):
1)	Готово к разработке - здесь располагаются все задачи до выполнения.
2)	В работе - здесь задача должна находится пока над ней идет работа, на этом этапе указываются коммиты
3)	Готово к тестированию - конкурсант должен самостоятельно переместить, карточку завершив работу
В работе необходимо использовать систему контроля версий Git, который предоставляет организатор.
Необходимо строго следовать предложенному дизайну.
Вся верстка должна быть адаптивной (следует учитывать разные размеры экранов). Необходимо:
•	Избегать появления большого пустого пространства: 
o	Требование: Если макет Figma подразумевает растягивание фоновых элементов или блоков, они должны масштабироваться. Если пустота не является дизайнерским решением, она считается ошибкой.
-	Следить за отсутствием искажения элементов:
o	Требование: Соотношение сторон ключевых элементов (аватарки, превью товаров, иконки) должно быть жестко зафиксировано и соответствовать макету.
-	Все элементы должны полностью находится в границах и на месте, указанном в макете:
o	Требование: Вся важная информация (заголовки, CTA-кнопки, иконки навигации) должна находиться строго внутри отведенных направляющих и полностью помещаться на экране без горизонтального скролла.
-	Учитывать расстояние между элементами:
o	Требование: Фактические пиксельные отступы на скриншоте с устройства должны соответствовать математической пропорции относительно макета Figma (либо жестко фиксироваться на всех экранах, если это предусмотрено DS).
-	Используйте шрифты согласно макету:
o	Требование: Шрифты не должны заменяться на системные аналоги. Размер текста должен быть читаемым, но строго соответствовать значениям из Figma. При изменении размера экрана текст может переноситься или обрезаться в троеточие, но не должен обрезаться по высоте или ширине самим блоком.
-	Общее Требование: Верстка признается адаптивной и успешной только при полном соответствии расположения всех блоков тому, как это спроектировано дизайнером для соответствующего типа устройств.
-	Дизайн предложен в Figma. [https://www.figma.com/design/uBd1PQFzaEREQarAsaPdsc/%D0%98%D0%9C%D0%AD%D0%A7--Orignal-?node-id=0-1&t=lRWHygd0R6ZFzk9T-1](https://www.figma.com/design/uBd1PQFzaEREQarAsaPdsc/%D0%98%D0%9C%D0%AD%D0%A7--Orignal-?node-id=0-1&t=lRWHygd0R6ZFzk9T-1)
Необходимо осуществлять документирование кода.
•	Состав обязательной документации в коде.
Для каждого создаваемого класса верхнего уровня (Activity/Fragment/ViewModel/Repository, Widget и т.д.) в коде должны присутствовать структурированные комментарии, включающие следующие метаданные:
Описание назначения класса (Краткое описание):
Комментарий должен содержать четкое описание ответственности (Single Responsibility) данного класса. Необходимо указать, какую функцию системы он реализует (например: «Класс отвечает за аутентификацию пользователя по биометрическим данным» или «Репозиторий для работы с API каталога товаров»).
Идентификационные данные:
Дата создания: Дата создания файла/класса в формате ДД-ММ-ГГГГ.
Автор создания: Номер участника.
Для обеспечения ясности алгоритмов обязательному комментированию подлежат вложенные элементы программного кода:
Публичные методы: Следует описывать назначение метода (что он делает), а также входные параметры (что принимает) и возвращаемые значения (что отдает), если это не тривиальные геттеры/сеттеры.
Сложные алгоритмы (более 5 строк): Внутри методов необходимо использование строчных комментариев для пояснения нетривиальных логических блоков (условий, циклов, математических вычислений).

•	ТРЕБОВАНИЯ К ЛОГИРОВАНИЮ:
Уровни логирования
Участник обязан использовать различные уровни логирования для категоризации событий:
•	DEBUG (Отладка): Для отображения технической информации, необходимой в процессе разработки и отладки (например, содержимое полученных данных, результаты вычислений).
•	INFO (Информация): Для фиксации ключевых событий жизненного цикла приложения (например, «Активити создано», «Запрос к API отправлен», «Пользователь авторизован»).
•	ERROR (Ошибка): Для записи информации об исключительных ситуациях и сбоях (например, «Ошибка загрузки данных с сервера: таймаут»).
Обязательные точки логирования
Следующие события в обязательном порядке должны быть задокументированы в логах (с использованием соответствующего уровня):
1.	Жизненный цикл экранов (например Activity/Fragment): Логирование вызовов основных методов (onCreate, onStart, onResume, onPause, onStop, onDestroy) с уровнем INFO.
2.	Сетевые запросы и работа с БД:
o	Начало запроса/операции (INFO).
o	Успешное получение ответа/результата (DEBUG).
o	Возникновение ошибки (ERROR) с указанием типа ошибки.
3.	Обработка пользовательского ввода: Логирование нажатий на критические кнопки (например, «Отправка формы», «Начать игру») с уровнем INFO.
4.	Обработка исключений (Exceptions): Любой try-catch блок должен содержать запись в лог с уровнем ERROR и сообщением об исключении.
Формат сообщений
Сообщения должны быть информативными и однообразными. Необходимый формат:
[Тег_компонента]: Событие — Детали
Пример:
[AuthViewModel]: Авторизация — Успех для пользователя user@mail.com
[ApiRepository]: Ошибка — Не удалось список игроков (код 500)
No results