/android-homeworks

Primary LanguageKotlin

Домашние задания по android-разработке

В этот репозиторий вы будете загружать свои домашние задания, которые были заданы вам на занятии, или с которыми вы ознакомились в репозитории android-lessons. В репозитории лежат папки с именем каждого студента, в этих папках будут находиться ваши задания.

Процесс первоначальной настройки репозитория:

  1. Сделайте форк этого репозитория на свой аккаунт (кнопка Fork в правом верхнем углу).
  2. С помощью git clone клонируйте репозиторий с вашего аккаунта к себе на компьютер. Важно: клонировать нужно именно с помощбю git clone, а не загружать архивом. Таким образом вы получите проект с уже инициализированным гитом и ссылкой на удаленный репозиторий.
  3. В своей именной папке создайте новый проект или перенесите в нее уже готовый, на основе которого будете делать задание. Назовите проект по шаблону Фамилия-Lx, где x - номер урока, на котором было задано это задание (напр. Goncharov-L2).
  4. Закоммитьте и запушьте изменения на свой форкнутый репозиторий (git add . -> git commit -> git push). Первоначальная настройка завершена.

Процесс выполнения домашнего задания:

  1. Зайдите в свою именную папку (на вашем компьютере) и создайте новый проект или зайдите в уже созданный проект, на основе которого будете выполнять задание.
  2. Выполните задание.
  3. Закоммитьте и запушьте изменения на свой форкнутый репозиторий (git add . -> git commit -> git push).
  4. После загрузки изменений на свой репозиторий создайте пулл реквест на вливание своей ветки main в ветку main этого репозитория (вкладка pull requests в вашем репозитории - new pull request). Назовите пулл реквест по шаблону Фамилия-Lx, где x - номер урока, на котором было задано это задание (напр. Goncharov-L2).
  5. Запросите у меня ревью через меню "Reviewers" (MegaR1CK).
  6. Ожидайте запроса правок.
  7. Когда правки будут запрошены, откройте пулл реквест и просмотрите их. Откройте проект, внесите в него правки, закоммитьте и запушьте изменения на свой репозиторий. После исправления каждой правки нажимайте кнопку "Resolve conversation" под правкой.
  8. Запросите у меня ревью через меню "Reviewers" (MegaR1CK).
  9. Если я запрошу правки еще раз, повторите пункты 9-10.
  10. Если меня все устроит, я дам аппрув на ваш пулл реквест и сам волью вашу ветку в данный репозиторий. От вас ничего не требуется.
  11. Задание может считаться выполненным только, когда оно влито в данный репозиторий.

Примечание: если вы делаете задание на основе проекта с прошлых уроков, то переименовывать проект не нужно, однако ваш пулл реквест вы называете соответствующе. вы можете работать над одним проектом несколько уроков, но одному пулл реквесту соответствует только одно задание.

Руководство по именованию

У многих студентов в процессе выполнения заданий возникли большие проблемы с именованием сущностей, поэтому во избежание многочисленных правок, я добавил этот раздел. Отмечу, что именование сущностей имеет огромное значение не только в android-разработке, но и во всем программировании. Понятные имена позволяют вам и другим людям сходу понимать написанный вами код, и не лезть в контекст, чтобы догадаться о роли и значении сущности, что может сэкономить большое количество времени. Единый стиль именования улучшает качество и понятность кода, особенно если над проектом работает несколько человек (или один человек проверяет много проектов). Требования к именованию:

  1. Общее - для всех сущностей (элементы интерфейса в разметке, классы, методы, переменные и т. д.) задавайте такие имена, чтобы можно было легко понять, что это за сущность и что она делает только по имени, причем понять не только вам, но и стороннему человеку. После обозначения каждого имени задавайте себе вопрос: "Смог бы сторонний программист, не знакомый с программой, понять, что это за сущность?" Если ответ - нет, переделывайте.
  2. Id для элементов интерфейса в xml-разметке - именуем в стиле camelCase по шаблону (название элемента интерфейса)(название экрана)(уточнение (необязательно)). Название элемента интерфейса должно быть без сокращений! Никаких et, tv и прочего. Уточнение используется в том случае, если на экране находится несколько подобных элементов интерфейса и нужно уточнить, для чего используется конкретно этот элемент интерфейса. Например, на экране регистрации несколько полей ввода, поэтому для каждого поля поясняем, что именно туда вводится. Примеры: editTextRegisterName, textViewSplashTitle, buttonLogin, imageViewProfileAvatar, frameLayoutSplash.
  3. Переменные - здесь все довольно просто - именуем в camelCase в соответствии с пунктом 1. Из-за огромного разнообразия имен переменных трудно добавить еще какие-то правила. Примеры: currentDate, userPassword, orderDescription.
  4. Методы - именуем в camelCase так, чтобы в имени метода был отражено действие, которое выполняет этот метод. Если перевести имя метода на русский язык, то должен получиться глагол в неопределенной форме (ПРОВЕРИТЬ пароль, ОТКРЫТЬ экран, НАЙТИ элемент). Примеры: checkPassword, runRequest, openRegister, bindOrder. Исключением являются методы жизненного цикла, но вы их переопределяете, а не создаете.
  5. Классы (стандартные) - классы именуются в PascalCase (как camelCase, только первая буква большая). Классы следует называть, опираясь на роль, которую они выполняют в приложении. Примеры: Validator, Observer, SingleLiveEvent.
  6. Классы (активности) - именуются по шаблону (то, что происходит в активности/основная роль активности)Activity. Заметьте, что последним словом любого класса активности должно быть Activity. Примеры: SplashActivity, OnboardingActivity, ProfileActivity.
  7. Изображения (drawable) - именуются в стиле snake_case (все буквы маленькие, через нижнее подчеркивание) по шаблону (тип)_(описание). Типы изображений - фон (bg), иконка (ic), картинка (img) и т. д. Описание формируется из того, где используется эта картинка, содержимое абсолютно не важно. ИСКЛЮЧЕНИЕ - иконки. Так как иконки могут использоваться во многих местах приложения, описание для иконки должно отражать то, что на ней нарисовано. Примеры: bg_splash, img_onboarding_main, ic_close, ic_add.
  8. Макеты (layout) - имя совпадает с именем соответствующей активности, однако именование происходит в snake_case и слово activity стоит в начале, а не в конце. Не стоит сильно заморачиваться, если вы создаете активности через мастера, макеты именуются автоматически. Примеры: activity_main, activity_sign_in.
  9. Строки (strings) - именуются с snake_case по шаблону (название экрана)(назначение). Назначение - место, которое строка занимает в приложении. КАТЕГОРИЧЕСКИ запрещено дублировать значения строк в их именах (welcome_onboard, forgot_password, enter_name). Значения строк запросто могут измениться, а имя останется, поэтому имя должно отражать смысл строки. Примеры: login_email_hint, splash_title, profile_description.
  10. Коммиты - именуются в стандартном письменном стиле так, как вы пишете предложения. Имя коммита должно отражать то, что вы сделали в этом коммите. Запрещено называть коммиты своими именем и фамилией, датами или набором символов. Также все действия в имени коммита должны быть в инфинитиве (Add, а не Added, Fix, а не Fixed). Точку в конце ставить не нужно. Старайтесь уместить сообщение коммита в одно небольшое предложение.

Также рекомендую почаще изучать код проектов (как тех, которые мы делали на занятиях, так и совершенно сторонних) и смотреть на названия встроенных классов/методов/переменных, чтобы лучше усвоить данные правила.