Хотелось бы начать эту статью хоть с какого-то приветствия, но так как мы собрались тут ради хоть как-то полезной информации, перейду сразу к делу. Итак, немного вводных и постановка проблемы: любому начинающему разработчику нужен опыт. А как наработать опыт? Именно опыт, а не просто определённый объём зазубренной теории с полным нулём практики. Есесна написать что-то своё – проект, который не стыдно и в портфолио положить, да и просто перед знакомыми похвастаться.
А для чего нужна эта статья? Прежде всего показать, что ничего такого страшного (и уж тем более сложного) в том, чтобы попробовать написать что-то своё нет и быть не может. Ну и поделиться опытом, проблемами, которые у меня возникли, да и просто вызвать хоть какой-то отклик у более опытных товарищей.
План прост: написать приложение, которое помогает отслеживать количество каких-либо базовых упражнений. Возьмём, к примеру, следующие: отжимания, приседания и стояние в планке. Почему именно такие упражнения? Всё просто: для них любому человеку потребуются лишь руки, ноги и, по возможности, чистый пол (не обязательно, но эстетического удовольствия для).
А что получилось в итоге, вы сможете посмотреть в конце. Ссылочку на репозиторий я оставлю.
Итак, от слов – к делу. Часть 1: подготовка
Глупо было бы начинать, не имея какого-либо плана действий. Как минимум, я должен чётко знать, что я хочу создать. Идея приложения, которое может помочь отслеживать количество сделанных упражнений, вряд ли является сверхновой, потому что разного рода трекеров достаточно, но как собственный проект для длительного ковыряния вполне.
Буквально в пути был создан примерный дизайн приложения (ну и по мелочи, типа виджетов. Так, на будущее), который вы можете узреть ниже:
А что по функциональному наполнению? Календарь, отображение текущей даты, прогресс-бар по упражнениям, с возможностью добавлять своё, и простенькое (пускай даже пока не особо функционирующее), но меню. В дальнейшем также планирую добавить отслеживание прогресса, изменение ежедневных целей, возможность смены темы приложения с светлой на тёмную, ну и хоть какую-нибудь, но всё же геймификацию рутинного процесса: достижения за непрерывность, наличие соревновательного режима между пользователями и т. д. (да, ехидная зелёная сова-манипулятор тихонько наблюдает из-за угла).
Итак, план есть, практики нет. Пора это исправить.
Часть 2: создание основы основ приложения
Прежде всего, переходя к практике, я начал с выбора среды разработки. Мои попытки что-то сделать в IntellIj IDEA (фух, вроде правильно написал, но не суть. Не кидайтесь камнями, в случае чего) пресеклись некоторыми причинами (в том числе и меньшим удобством), в связи с чем было решено перейти в знакомый всем хоть сколько-то сведущим в мобильной разработке Android Studio. А там и макет удобный, и работать приятнее…
В общем, к сути. Да, я мог бы расписывать каждую кнопочку, которую я добавлял, но кому это может быть интересно? Поэтому кратко постараюсь пробежаться по всем «штукам», которые я смог попробовать добавить в своё приложение.
Что же, начнём. Тема приложения. Если и стоит с чего-то начинать создание, то это вряд ли с выбора темы. При попытке создать кривыми путями тёмную тему, я столкнулся с некоторыми проблемами, о чём позже.
… И да, я немного сглупил, ибо даты (а точнее числа, их обозначающие) сливались с фоном (по крайней мере, именно во время тестового запуска). Поэтому было решено оставить стандартный цвет фона (на время наработки прототипа), а более точной настройкой параметров отображения календаря заняться позднее (что будет сопряжено с подключением базы данных для реализации остального функционала).
В итоге проблема была решена заменой цвета фона (да, моя «тёмная тема» была сделана именно таким кривым способом). И был добавлен календарь, вот:
Ну и то, что оказалось самым интересным в реализации, и что получилось самым «вырвиглазным», так это progressbar-ы, которые хоть и адекватно функционируют в рамках своих обязанностей, но визуально это выглядит не самым лучшим образом (+ пункт в копилку будущих исправлений)
Часть 3: реальные тесты
Пришла пора собрать проект и протестировать на реальном устройстве, а не на виртуальной машине. Предварительно протестировав непосредственно на «виртуально-реальной» машине (т. е. просто подключив свой телефон) и исправив кое-какие моменты (в частности, просто изменив формат выведения даты, ибо первоначальный способ просто не работал), я скомпилировал это всё в апк-файл, готовый для распространения.
Итак, пациент скорее жив, чем мёртв, а это значит, что ничего не сделано зря. Пока я это пишу (и дай б-же, чтобы у меня сохранились все скриншоты, которые я делал во время разработки), я уже успел прикинуть несколько основных вещей, которые я должен сделать для того, чтобы перевести приложение из разряда не просто работающей «аппликации» в разряд простенького приложения, которое будет хоть чем-то полезно. Но до того момента ещё достаточно работы, а на этом всё. Такие дела.
К слову, с плодами моих трудов вы можете ознакомиться здесь: https://github.com/AlexUnderTheLulz/MyEverydayActivity
В общем, буду рад любому фидбеку (адекватному – опционально)
Комментарии (12)
RomanZy
16.11.2023 10:21+1Сам новичок, но хочется узнать у автора:
1) Почему Java, а не Kotlin - большинство проектов уже не используют Java в Android;
2) Почему нет разбиения на слои?
- Раздел 3 про реальные тесты без самих тестов (практика написания тестов где?), вообще не соответствует тестированию.
- Проект крайне простой, чтобы публиковать на Habr, даже как проба пера в копирайтинге, проект больше похож на приложение из 1,5 часового видео обучающих школ, которые тоже на примере всё в одной активности показывают.
Без обид сказано, но на конкурентном рынке новичку с таким проектом ничего не светит, без архитектуры вообще, без тестов. Желаю тебе по больше узнать про архитектуру и тому подобное.
P.s. Это ещё даже не дебри - это луг.
AlexUnderTheLulz Автор
16.11.2023 10:21+1Я знаю, что проект ещё совсем сырой и скорее может называться просто аппликацией, нежели чем приложением. Но это лишь начало, которое, разумеется, не может ни на что претендовать. Я и не собираюсь использовать его в портфолио на данном моменте. Суть статьи в том, чтобы показать, что начать хоть что-то делать не так уж страшно/сложно, а дальше пойдёт гораздо легче. Ну и тесты понимать не как "программное" тестирование (иначе я бы добавил соответствующий тег), а скорее просто проверка того, что получилось. По мере разработки данного проекта я может и продолжу кратко писать о реализации тех или иных штук, а может просто напишу статью по итогам, когда они будут.
Почему Java, а не Kotlin? Суть в том, что я стараюсь освоить именно этот язык, а в качестве проекта для более продуктивного изучения выбрал то, что может быть полезным в повседневной жизни, а не будет просто простаивать куском кода на гитхабе.RomanZy
16.11.2023 10:21Вы самостоятельно андроид изучаете или через курсы?
AlexUnderTheLulz Автор
16.11.2023 10:21Конкретно андроид разработку я стараюсь изучить сам. Какие-то гайды или помощь более опытных товарищей при возникновении проблем - моё всё. Сам же язык я изучаю более систематизировано, ибо на него и ориентируюсь.
meaqese
16.11.2023 10:21Зачем писать тесты если ещё продукт нуждается в больших доработках?
AlexUnderTheLulz Автор
16.11.2023 10:21Смотри комментарий чуть выше. Это не тесты в классическом их понимании, а просто проверка приложения на жизнеспособность.
NeoCode
У меня есть некие собственные впечатления о разработке под андроид. Я на чем только не писал, однажды решил ради интереса попробовать и под Android. Сам язык (Java или Kotlin) никаких проблем разумеется не вызвал, после С/С++ и общих представлений о множестве других языков. А вот что не понравилось, так это тотальная зависимость Android Studio (а конкретно системы сборки Gradle) от интернета. Если интернет не совсем обычный (хитрые корпоративные политики безопасности на шлюзе) или его вообще нет, оно не работает. Если интернет есть и обычный - оно лезет туда на каждый чих и что-то скачивает. Создает какие-то кэши скачанного, которые очень быстро раздуваются до гигабайтных размеров. Это печально, коробочные продукты в которые "все включено" гораздо приятнее.
Еще: если допустим скачиваешь чей-нибудь проект с гитхаба, написанный для Visual Studio (С++, C#), или для Qt - проблем со сборкой как правило нет. Даже проекты олдскульного Visual Studio 6 1998 года конвертируются в форматы любых современных студий. Здесь же - сразу какие-то заморочки, и обычно ничего не собирается, по причинам загадочным и не имеющим отношения к синтаксическим ошибкам в коде. Т.е. программист, вместо того чтобы думать об абстракциях кода, вынужден будет заниматься каким-то шаманством непонятно с чем. Это печально, и еще раз наводит на мысли о принципиальной неправильности самой концепции "систем сборки" как таковых.
Что касается GUI, то могу только сказать - да, есть некая специфика, интуитивно она мне не очень понравилась, но я особо и не разбирался. Допускаю что все это нужно для универсального описания GUI, способного работать на произвольном размере экрана и с произвольными настройками пользователя.
D7ILeucoH
Странно, что за подобный но обоснованный спич я ловлю бесконечный поток минусов, а тебе при незнании существования тогла "offline mode" как-то удаётся получать плюсы)
А ошибок при клонировании какого-то дикого проекта я давно уже не замечаю, такое обычно было когда кто-то секреты криво удалял или добавлял в гит файлы, которые даже по умолчанию записаны а gitignore потому что содержат инфу о компе...
Что реально должно было напрягать - жизненный цикл, к примеру. Ну или поддержка старых Андроидов)
NeoCode
Не, не секреты. Проекты простейшие. Там именно что-то с работой gradle и его файлами. И даже было такое, что компилятор или какой-то другой инструмент сборки падал на каких-то файлах (Execution failed for task ':app:processDebugMainManifest'), при этом AndroidStudio выдавала подсказки что нужно исправить. Вообще все это создает впечатление полнейшей несогласованности набора инструментов. Даже вот пункты меню типа "Sync project with Gradle files" - это вообще что? Правая рука не знает что делает левая?
Сама АндроидСтудия как IDE - просто отличная, никаких нареканий; но им бы открутить все эти сборочные поделия и написать полностью свою интегрированную в IDE инфраструктуру сборки проектов, в идеале основанную на простых "файлах проектов" (xml как в Visual Studio) без всякой императивщины (да, я считаю что любые активные скрипты в файле проекта - зло, и в 99% не нужны, достаточно просто списка файлов исходников и перечня опций компилятора, а там где нужны, должны быть огорожены специальными тегами наподобие prebuild_action / postbuild_action).
D7ILeucoH
Секреты - я имел в виду пароли. Пароли, в т.ч. от ключей сертификатов хранились до недавнего времени в файле gradle в открытом виде...
Насчёт работы без IDE - никто не мешает открыть проект в том же VS Code чтобы наблюдать только дерево файлов. Саму сборку проекта легко делать через ./gradlew скрипты - кстати именно так и происходит сборка на современных CI CD в больших проектах.
Андроид Студио сильно любят за подсказки. Мне кажется что она идеальная. Да, жрёт гораздо больше ресурсов чем лет 10 назад... но в целом можно отключить в настройках лишние скрипты, включить power safe mode...
Аналогов Студии нет, хотя бы по тому что есть предпросмотр XML вёрстки (с выбором тем, девайсов) и удобный (как и во всех продуктах JetBrains) дебаггинг.
Старички ещё помнят Eclipse, но кажется его никто сейчас с этой целью не использует (китайцы не в счёт).