Ошибка № 1: не учитывать, что всё должно быть на своих местах
Экосистема Android стремительно распространяется по всему миру. Вместе с этим растёт и сообщество, состоящее из непохожих друг на друга людей: из разных социальных слоёв, с ограниченными возможностями, тех, кто хочет иметь прикольные функции, например, ночной режим и многих других, кто использует Android-приложения в своей повседневной жизни.
Разработка приложений для такого разнообразного сообщества — непростая задача. Я не говорю сейчас об архитектуре высокого уровня. Напротив, речь идёт о простых вещах, таких как как строки, цвета, размеры и др.
Чаще всего людям комфортно использовать приложения на родном языке. Важным моментом является сохранение всех строк в одном файле (обычно strings.xml), что позволит быстро добавлять файлы строк на разных языках.
То же относится к цветам, размерам и стилям. Когда вы решите сделать что-то вроде темного режима или настройки макетов для просмотра на планшете, с этим будет легко справиться. Суть в следующем: храните код в одном месте для повторного использования, а не жёстко кодируйте каждый раз.
Ошибка № 2: не использовать фрагменты
На начальном этапе Android-разработки рекомендовалось использовать отдельную активность (activity) для каждого экрана. Со временем из-за этого разработчики столкнулись с разными проблемами. Кроме того, активность, являющаяся точкой входа в приложение, была уязвимостью.
Если у вас есть опыт Android-разработки, то вы наверняка знаете, что использование активности имело смысл пару лет назад, когда API-фрагменты ещё не были сильно развиты.
Переносимся в 2020 год, и команда Android-разработчиков рекомендует использовать фрагменты для создания каждого экрана и поддерживать одну или несколько активностей во всём приложении для их размещения. Это называется Single Activity Architecture.
Использование такой архитектуры значительно снижает количество взаимодействий извне приложения. Новый компонент навигации Jetpack тоже по большей части основана на Single Activity Architecture.
API-фрагменты сделают вашу жизнь намного проще. Может быть, через пару лет Android-разработка полностью перейдёт от активности к ним.
Ошибка № 3: не использовать DataBinding и ViewBinding
С самого начала среда Android-разработки основывалась на трёх типах файлов: XML, Kotlin и Java. Файлы XML содержат всё, что связано с дизайном, а файлы Kotlin и Java включают всё остальное.
Потом появилась необходимость связать пользовательский интерфейс и бизнес-логику. Всё началось с печально известной функции findviewbyid. Ситуация улучшилась, когда появились DataBinding и ViewBinding.
Основная цель ViewBinding — решить проблему объединения с помощью типобезопасности и null-безопасности во время рабочего цикла.
DataBinding позволяет связывать компоненты пользовательского интерфейса в макетах с источниками данных, используя декларативный формат, а не программный.
Ошибка № 4: не использовать Kotlin и сопрограммы
Прошло несколько лет с тех пор, как Google объявил Kotlin рекомендуемым языком для разработки Android-приложений. Это было одно из трансформационных решений: Kotlin решил проблемы Java и облегчил процесс разработчикам.
Использование Kotlin открыло доступ к новым функциям: расширениям, функциям области видимости, классам данных, null-безопасности и др. С помощью этого языка вы также можете заниматься мультиплатформенной и серверной разработкой.
Асинхронное программирование играет ключевую роль в мобильной разработке. На ранних этапах использовали AsyncTask, затем — RxJava. Наконец, появились сопрограммы. Сейчас это стандартное решение для асинхронных задач. Мощные функции и простая реализация делают их более адаптируемыми.
Kotlin делает разработку простой и лаконичной, а сопрограммы позволяют последовательно выполнять асинхронные задачи без необходимости изучать что-то новое.
Ошибка № 5: некорректно применять инструменты проектирования
Недооценка ConstraintLayout
В комплекте с ConstraintLayout идёт множество удобных функций: рекомендации, барьеры, группа, соотношение сторон, поток, слой и др. Благодаря этому с помощью ConstraintLayout можно рисовать практически любой отдельный экран.
ConstraintLayout отличается от ReklativeLayout и LinearLayout. Не путайте их. Вы можете создать плоские макеты без иерархии вложенности, что позволит рисовать меньше слоёв на View.
Чрезмерное использование ConstraintLayout
Не следует злоупотреблять мощными функциями этого инструмента. Там, где пользовательский интерфейс можно создать с помощью FrameLayout или LinearLayout, использование ConstraintLayout будет необоснованно.
Страх использования MotionLayout
ConstraintLayout подходит для разработки сложных вариантов использования, но не для создания анимации и переходов. С этим справится MotionLayout.
MotionLayout — это подкласс ConstraintLayout, который включает в себя все его функции. Он полностью декларативен, может реализовать сложные переходы в XML, а также обратно совместим с уровнем API 14. Это значит, что этот инструмент подходит для 99% случаев.
Новый редактор MotionLayout в Android Studio 4.0 упрощает работу. Он предоставляет классную среду для реализации переходов, MotionScenes и многого другого.
Ошибка № 6: не исследовать вопрос безопасности
Хранение конфиденциальных данных
Многие разработчики используют общие настройки для хранения конфиденциальных данных пользователя. Но оставлять их в общих настройках Android, базе данных или локальном хранилище рискованно. Их легко взломать.
Эту проблему можно решить с помощью новой библиотеки хранилища данных, библиотеки с зашифрованными настройками или путём самостоятельного шифрования.
Безопасная коммуникация
Многие Android-разработчики считают, что использование HTTPS может обезопасить их взаимодействие с серверами. Но это не так. Хакеры часто внедряются в канал связи, чтобы запутать серверы и клиентов. Это атака с так называемой технологией «незаконный посредник» (англ. man in the middle). Чтобы линия связи с сервером была безопасной, необходимо закрепить сертификат.
Ошибка № 7: не использовать все возможности Android Studio
Не имеет значения, насколько мощным является инструмент, если вы не научитесь пользоваться им правильно. Нам, разработчикам, очень повезло с Android Studio. Грех не воспользоваться всеми возможностями этой среды разработки.
У Android Studio есть много скрытых функций: удобные ярлыки, живые шаблоны, шаблоны файлов, предопределенные структуры проекта, плагины генератора кода и многое другое. А для продуктивности во время рабочего цикла можно использовать инспектор базы данных, инспектор макета, профилировщик и не только.
Android Studio также предоставляет инструментальную поддержку для нескольких библиотек, таких как редактор навигации для просмотра навигационного графика приложения и редактор движения для эффективных анимации и переходов.
Ошибка № 8: Не использовать библиотеки Jetpack
«Jetpack — это набор библиотек, который помогает разработчикам использовать передовые методы, сокращать шаблонный код и писать код, который работает согласованно на всех Android-версиях и устройствах. Так разработчики могут сосредоточиться на коде, который им важен сейчас ».
— Android Jetpack
Библиотеки JetPack включают в себя основные функции: paging3 для разбивки на страницы, Room для локальной базы данных, WorkManager для длительных фоновых задач, DataStore для улучшенного хранения данных, Hilt для DI, компоненты для навигации в пользовательском интерфейсе приложения, App Startup для сокращения времени запуска приложения и т. д.
Библиотеки созданы с учётом производительности, с ними легко реализовать сложные задачи с минимальным количеством кода.
Читайте также:
- Clean Architecture в Android для начинающих
- Операционная система Android
- Знакомьтесь, компонент Navigation в Android!
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Siva Ganesh Kantamani: 8 Common Mistakes in Android Development.
