Android типовые ошибки разработки приложений
Список от руководителя проектов компании-разработчика MobileUp Олега Широкова.
Несколько месяцев вы с разработчиками трудились над созданием приложения. Настало время его выпускать. Все фичи готовы и работают, как задумано.
Но всё же есть вероятность, что в процессе был упущен какой-нибудь важный момент. Поэтому мы собрали список распространённых ошибок, которые нужно обязательно проверить перед релизом, даже если вас убеждают, что всё нормально.
Материал поможет продакт-менеджерам и собственникам бизнеса на клиентской стороне убедиться в том, что их приложение действительно готово к релизу и не нуждается в срочных доработках.
Нужно проверить, как приложение ведёт себя в проблемных ситуациях. Детально это изучают тестировщики, поэтому здесь речь идет о быстром smoke-тесте самых популярных кейсов.
Если приложение использует геолокацию, то нужно проверить, как оно ведёт себя в типичных случаях.
Первая ситуация: пользователь запретил приложению доступ к геолокации
Как проверить: в настройках запретить приложению доступ к геоданным и запустить приложение.
iOS-приложение Maps.me показывает детальную инструкцию по включению геолокации. iOS-приложение «Яндекс.Карты» вообще ничего вам не сообщит, пока вы не нажмете кнопку определения местоположения.Вторая ситуация: приложению не удаётся быстро определить координаты пользователя. Например, если он находится в помещении или выключил Wi-Fi и мобильный интернет.
Как должно быть: показать последнее определённое местоположение пользователя, а если его нет — показать какую-то точку по умолчанию или заглушку, но не карту в море.
Как проверять: включить авиарежим и запустить приложение.
Приложения Google Maps, «Яндекс.Карты», Maps.me (iOS-версии) показывают последнее определенное местоположение. Android-приложение Waze показывает пользователю карту в море.Первая ситуация: пользователь совершает действие, для которого нужен доступ к интернету. Например, нажимает на кнопку «Загрузить». А интернета в этот момент нет.
Как проверить: запустить приложение, выключить интернет, нажать на какую-нибудь кнопку действия.
При попытке найти ближайшие велостанции iOS-приложение «Велогород» подсказывает, что доступа к интернету нет. В iOS-версии TaxFree4U при тапе на кнопку «Восстановить» ничего не происходит.Вторая ситуация: пользователь хочет перейти в другой раздел приложения, например, из бокового меню, а доступа к интернету нет.
Как проверить: запустить приложение, зайти в один из разделов, потом перейти в другой, отключить интернет, вернуться в предыдущий раздел.
Третья ситуация: интернет есть, но нестабильный — и он пропал в процессе загрузки экрана.
Как проверить: запустить приложение, зайти в один из разделов, потом перейти в другой раздел, для которого нужно загрузить много данных с сервера, и в процессе загрузки отключить интернет.
iOS-приложение «ВКонтакте» при разрыве связи с интернетом оставляет ленту в том состоянии, в котором успело её загрузить. iOS-версия HeadHunter при разрыве соединения вместо уже найденных и показанных на экране вакансий раньше показывала заглушку. Достаточно было немного поскроллить экран с результатами поиска.Четвёртая ситуация: при открытии экрана не было интернета, он появился уже после.
Обработка такой ситуации нужна не в каждом приложении и не на каждом экране. Но она очень актуальна для чатов, соцсетей и приложений, работающих с картой.
Как должно быть: приложение периодически проверяет, не появился ли интернет снова. Если появился — загружает нужные данные автоматически без дополнительных действий со стороны пользователя.
Как проверить: запустить приложение, включить авиарежим, выключить авиарежим.
iOS-приложение Uber при появлении интернета автоматически возобновляет загрузку данных. iOS-версия «Яндекс.Такси» ждёт, пока пользователь сдвинет карту.Логика и сценарий проверки здесь такие же, как и при проблемах с интернетом. Только вместо отключения интернета нужно попросить серверного разработчика отдавать приложению различные ошибки.
Любой грамотный дизайнер или разработчик скажет вам, что текст на экране так же важен, как удобный интерфейс и отсутствие багов. Пользователи часто не могут разобраться с непонятными пояснениями и названиями кнопок. А конкурентов и многочисленных «диванных» экспертов знатно повеселят найденные орфографические ошибки.
Поэтому обязательно нужно заглянуть на каждый экран приложения и проверить тексты на внятность и орфографические ошибки. Для ускорения работы можно попросить разработчиков сделать скриншоты всех экранов и состояний через специальный сервис. Например, Fastlane Snapshot.
В продуманных приложениях названия кнопок соответствуют тому, что произойдёт при их нажатии, и побуждают к действию. Например: «Выбрать» и «Подтвердить» вместо «ОК», «Отказаться» вместо «Отмена», «Найти мастера» вместо «Поиск мастеров».
iOS-приложение «Эриус» просто объясняет, что нужно сделать пользователю. А инструкция по оплате в iOS-приложении «Метро Москвы» написана сложным канцелярским языком, в котором тяжело разобраться.Когда пользователь совершает критичные действия, которые нельзя вернуть назад или которые могут доставить ему неудобства, нужно обязательно показывать диалоги-подтверждения. Примеры таких действий: выход из учётной записи, удаление контента, отмена заказа и так далее.
iOS-приложение «ВКонтакте» при выходе из учётной записи запрашивает подтверждение. iOS-приложение PlayStation разлогинивает сразу.Когда пользователь только установил приложение, в некоторых разделах у него будет пусто, например, в списке заказов. Чтобы эти разделы не были пустыми и грустными, в них размещают специальные заглушки с картинкой и пояснением, как заполнить этот раздел.
В продуманном приложении помимо текста будет кнопка. Например, «Создать первый заказ».
В продуманных приложениях на видном месте (например, в боковом меню или в профиле) есть контакты технической поддержки. Это позволяет уменьшить количество гневных отзывов в App Store и Google Play.
В iOS-версии Aladdin телефон и email техподдержки расположены на видном месте. А в iOS-приложении iTunesConnect есть только ссылка на веб-страницу с FAQ, при переходе на которую возникает ошибка: «Page not found».Перед релизом в приложения обычно интегрируют один или несколько сервисов по сбору аналитики: Google Analytics, Mixpanel, Fabric.io, Flurry, Appsee. Собранные данные можно удобно просматривать в веб-интерфейсе.
Если это ваше первое мобильное приложение, то вы, скорее всего, не будете детально знать, какие действия нужно отслеживать. Но есть минимальный набор, который точно нужно настроить.
Чтобы отслеживать, как часто приложение «падает» и у какого процента пользователей, настраивают сбор крэшей. Кроме того, они помогают разработчикам быстрее разобраться с причиной падения.
Статистика самых распространенных крэшей в Crashlytics для приложения DMV GenieЧасть этой информации можно посмотреть в iTunesConnect или Google Developer Console и без интеграции отдельного сервиса. Полный набор: количество установок, количество активных пользователей, среднее время, проводимое в приложении и прочее, — доступен только в специализированных сервисах аналитики.
Эта информация даст понять, востребовано ли ваше приложение и помог ли бюджет на продвижение.
Так вы сможете узнать, в каких разделах приложения пользователи проводят больше всего времени. Например, если у вас есть важный раздел с акциями, но пользователи туда не заходят, то, возможно, интерфейс приложения нужно доработать.
Если в приложении пользователи что-то заказывают или покупают, смотреть количество этих действий и считать конверсию удобно в аналитике. Для этого нужно настроить специальные «кастомные события». В приложении «Туту ЖД» список таких событий занимает четыре полных листа А4.
Раздел статистики по событиям в Google Analytics для приложения Aerostat iOSНа ранних этапах разработчик обычно настраивает взаимодействие с внешними сервисами через тестовые аккаунты. Например:
- отправку тестовых сборок (HockeyApp, TestFlight и так далее);
- крэшлог и сбор аналитики (Crashlytics, Google Analytics, Firebase и так далее);
- карты (Google Maps, «Яндекс.Карты», OSM и так далее);
- push-уведомления (Firebase и другие).
К моменту релиза приложения все эти сервисы должны быть переведены на аккаунты заказчика. Это может показаться очевидным, но мы не раз сталкивались с ситуациями, когда это не было сделано. Также после перевода всех сервисов на аккаунты заказчика нужно проверить, что они работают.
Мне кажется всю статью нужно заменить на один совет:
Проверьте, что вы наняли квалифицированного специалиста по тестированию
Так что мы вас понимаем, но пример не самый удачный. ;-)
Когда рассматривается удобство интерфейса, то общих принципов достаточно не всегда. Что если метрики сильно падают от смены текста на кнопке? Что делать?
Мы тексты на СТА - тестируем АБ-тестами регулярно. Результаты часто контринтуитивные (детали сказать не можем). :)
Правильные решения находятся в точке баланса метрик и создания верных ожиданий у пользователя.
Экосистема Android стремительно растет по всему миру и распространяется на различные группы людей. Люди из разных слоев общества, люди с ограниченными возможностями, пользователи, которые просто хотят иметь новомодные фичи, такие как ночной режим (темная тема), начинают использовать приложения Android в своей повседневной жизни.
Разработка приложений для широкого потребителя/diverse community — непростая задача. Я говорю здесь не об архитектурах высокого уровня. Напротив, речь идет о простых вещах: строки, цвета, размеры и т. д., которые все же имеют сильное влияние на современную Android-разработку.
Обычно для комфортного пользования приложением люди выбирают свой родной язык. Ключевая практика здесь — хранить все строки в одном файле (обычно strings.xml), чтобы можно было быстро добавить разные строковые файлы на разных языках.
Это же применимо и к параметрам: цвет, размер, стиль, — и если вы решите обеспечить поддержку приложением темной темы или добавить настройку лейаутов для работы на планшете, так это будет сделать проще. Короче говоря: собирайте весь такой код в одном месте, чтобы его можно было повторно использовать и легко изменять и заменять, вместо того чтобы хардкодить значения по всему проекту.
2. Неиспользование фрагментов
На заре Android-разработки рекомендовалось использовать отдельные активити для каждого экрана. Вследствии этого через какое-то время разработчики столкнулись с разного рода проблемами. Также, тот случай, когда активити является точкой входа в приложение, оказался уязвимостью.
Если у вас был опыт работы Android-разработчиком, то вы знаете, что пару лет назад, когда фрагменты (Fragments API) еще не были настолько развиты, использование активити было оправданно.
Перенесемся в 2020 год. Команда Android рекомендует использовать фрагменты в проектировании каждого экрана и поддерживать одно или несколько активити на все приложение для хостинга фрагментов. Это хорошо известно нам как Single Activity Architecture.
Использование этой архитектуры значительно сокращает количество внешних взаимодействий с приложением. Новый Jetpack navigation component главным образом основан на Single Activity Architecture. API Fragments значительно упростит вашу жизнь. Возможно, через пару лет Android-разработка совсем уйдет от активити к фрагментам.
3. Неиспользование Data Binding или View Binding
Среда разработки Android с самого начала базировалась на трех типах файлов: XML, Kotlin и Java. Файлы XML содержат все, что связано с дизайном, а файлы Kotlin/Java включают все остальное.
Рано или поздно встает необходимость связать пользовательский интерфейс (UI) и бизнес-логику, и именно здесь data binding (привязка данных) и view binding (привязка представления) играют ключевую роль. Связь между пользовательским интерфейсом и бизнес-логикой изначально осуществлялась через печально известную функцию findviewbyid.
Для решения этой проблемы рекомендуется использовать view binding и data binding. Основная цель view binding’а — решить проблему связывания с типом и null safety в рантайме.
Data binding необходим скорее для всеобщего блага. Оно позволяет связывать компоненты пользовательского интерфейса в лейаутах с источниками данных, используя декларативный формат, а не программным путем.
4. Неиспользование Kotlin и корутин
Прошло несколько лет с тех пор, как Kotlin, с подачи Google, стал рекомендуемым языком для разработки Android приложений. Это было очень серьезное трансформационное решение: Kotlin разобрался со всеми болевыми точками в Java и смог облегчить работу разработчиков.
Использование Kotlin в разработке Android-приложений открыло новые возможности благодаря таким фичам, как расширения, функции области видимости (scoped functions), классы данных, ключевое слово object , null safety и т. д. Помимо Android-разработки, с помощью Kotlin вы также можете осуществлять мультиплатформенную и серверную разработку.
Асинхронное программирование играет ключевую роль в разработке мобильных приложений. На ранних этапах мы использовали AsyncTask . Со временем появилась RxJava, что принесло много изменений. Но RxJava имеет очень крутую кривую обучения и совершенно другой подход к коллбекам.
После появились корутины (coroutines) — решение Kotlin для асинхронного программирования с простым подходом. В наши дни корутины стали стандартным решением для реализации асинхронных задач. Мощные фичи и простая реализация делают их более адаптируемыми.
Kotlin делает вашу разработку простой и лаконичной, тогда как корутины позволяют выполнять асинхронные задачи последовательно без необходимости изучать что-либо новое. Использование корутин в ваших разработках приводит только к более продуктивным и эффективным результатам.
5. Ошибки проектирования
Недостаточное использование ConstraintLayout
ConstraintLayout содержит множество удобных функций, таких как guidelines , Barriers , Group , aspect ratio , flow , Layer и многое другое. Благодаря всем этим функциям ConstraintLayout может отрисовать практически каждый экран (от простых до сложных вариантов использования).
ConstraintLayout отличается от Relative и Linear лейаутов. Поэтому не стоит использовать его так же. Мы можем создавать плоский лейаут без иерархии вложенности, что позволяет рисовать меньшее количество слоев.
Чрезмерное использование ConstraintLayout
Мощные функции сопряжены с риском злоупотребления ими. Использовать ConstraintLayout в пользовательском интерфейсе, когда можно обойтись FrameLayout или LinearLayout , — нелепое решение.
Страх перед MotionLayout
ConstraintLayout — правильный выбор при разработке сложных сценариев, но не для реализации анимации и переходов, где эффективным решением будет использовать MotionLayout.
MotionLayout — это подкласс ConstraintLayout , который включает в себя все его прекрасные фичи, и он полностью декларативен с возможностью реализации сложных переходов в XML. MotionLayout обратно совместим с API 14 уровня, что подразумевает 99% охват сценариев использования.
Новый редактор MotionLayout в Android Studio 4.0 облегчает работу с MotionLayout . Он предоставляет отличную среду для реализации переходов, MotionScenes и т.д.
MotionLayout — это не сложные вычисления и алгоритмы, а простой декларативный подход к реализации анимации и переходов с помощью нового модного редактора в Android Studio.
6. Пробелы в системе безопасности
Хранение конфиденциальных данных
Хранение конфиденциальных данных в общих настройках (shared preference) Android, базе данных или локальной области хранения — это риск, так как их легко взломать. Многие разработчики не знают об этом и используют общие настройки для хранения конфиденциальных данных пользователя.
Эту проблему можно решить с помощью новой библиотеки datastore или библиотеки Encrypted preference или путем самостоятельной реализации шифрования.
Секьюрная связь
Для создания безопасной линии с сервером, нам необходимо реализовать закрепление сертификата.
7. Недостаточная осведомленность о возможностях Android Studio
Неважно, насколько мощным является оружие, если вы не умеете правильно им пользоваться. Нам, разработчикам, повезло, что у нас есть такой мощный инструмент, как Android Studio, и хорошо бы знать, как использовать его эффективно.
В Android Studio есть много скрытых фич, как, например: удобные ярлыки, живые шаблоны, шаблоны файлов, готовые структуры проекта, плагины для генерации кода, кастомизация и многое другое. Для более эффективной работы есть также такие фичи, как инспектор базы данных, лейаут инспектор, профилировщик.
Android Studio также предоставляет инструментальную поддержку нескольких библиотек, таких как редактор навигации для просмотра графа навигации приложения и редактора движения для реализации анимаций и переходов красивым образом.
8. Отказ от использования библиотек Jetpack
«Jetpack - это набор библиотек, который помогает разработчикам не отставать от лучших практик, сокращать шаблонный код и писать код, который работает согласованно на всех устройствах и версиях Android, чтобы разработчики могли сосредоточиться на коде, который им важен. ” — Android Jetpack
Библиотеки Jetpack охватывают крупные фичи, такие как paging3 для пагинации, Room для локальной базы данных, WorkManager для продолжительно работающих фоновых задач, DataStore для улучшенного хранения данных, Hilt для DI, navigation component для навигации в UI приложения, App Startup для сокращения времени запуска приложения и многое другое.
Все эти библиотеки созданы с учетом производительности и простоты использования для реализации сложных задач с меньшим количеством кода.
На этом все. Надеюсь, что эта статья оказалась для вас полезной. Спасибо за внимание!
Знаете ли вы, что в Google Play Store выставлено на продажу 2,89 млн приложений, а в App Store — около 1,98 млн? Но только некоторым из них удалось завоевать рынок.
А задумывались ли вы когда-нибудь, почему одни приложения становятся успешнее других, хотя не очень-то отличаются от своих незадачливых конкурентов?
Мы часто не видим разницы между созданием успешных и провальных приложений. Между тем, первые идеальны с точки зрения функциональности и удобства в использовании, в то время как вторые страдают от ошибок разработчиков. Нередко создатели приложений допускают просто нелепые оплошности, которые становятся головной болью пользователя.
Поговорим о 10 основных недоработках, которые не позволяют Android-приложениям становиться хитами продаж. Если вам удастся благополучно избежать их, то вы сможете рассчитывать на прибыль, достойную вашего нелегкого труда.
1. Поспешное написание кода
- Прежде чем написать какую-нибудь функцию для приложения, проведите мозговой штурм.
- Чтобы создать высококачественный контент или код без ошибок, всегда следуйте алгоритму: п одумать → исследовать → спланировать → написать → подтвердить → модифицировать → написать код.
- Продолжайте мозговой штурм до тех пор, пока не решите, что достаточно продумали и спланировали функцию. Только тогда переходите к коду. Придерживаясь этой методики, вы сэкономите силы и напишете код с минимумом ошибок.
- Будьте предусмотрительны: не беритесь сразу за несколько функций. Спланируйте сначала одну и постарайтесь ее реализовать.
- Совершенствуйте навыки поиска в Google, чтобы тщательно исследовать функцию и выработать системный подход к решению проблем, с которыми можно столкнуться при ее реализации. Найдя решение, не приступайте сразу копировать и вставлять код, попытайтесь сперва понять концепцию, лежащую в его основе.
- Снова и снова задавайтесь вопросом, работает ли написанный вами код и можно ли его улучшить. Новички обычно довольны быстро написанным кодом, так как он, похоже, работает. Усвоив однажды эту порочную практику, они не могут совладать с соблазном использовать ее в последующих проектах.
2. Неупорядоченный код
Одна из наиболее распространенных и самых больших ошибок, которые допускает каждый второй или третий разработчик, — это написание плохо организованного кода.
Организация кода — это то же самое, что наведение порядка в комнате. Конечно, можно не делать ежедневной уборки независимо от того, насколько грязно вокруг . Но мириться с беспорядком получится лишь до того момента, пока не понадобится найти вещь, которая давно не попадалась на глаза.
По мере роста команды организация кода становится куда более важной задачей. Плохо организованный код отнимает время у любого, кто будет вынужден разбираться в нем. По этой причине в большинстве компаний, которые занимаются программным обеспечением, приняты стандарты программирования — они позволяют упростить обслуживание кода.
Около полугода назад я работал над проектом в небольшой команде. Чтобы разобраться, как работает код, написанный мной в тот период, мне нужно сначала просмотреть код всего проекта. Было бы намного проще, если бы мы заранее побеспокоились о хорошей организации.
3. Неосведомленность о возможностях Android Studio
Не имеет значения, насколько действенным и мощным является оружие, пока вы не научитесь правильно им пользоваться.
Android Studio — среда разработки с множеством полезных функций. Например:
- редактор визуальной разметки (Visual Layout Editor);
- быстродействующий эмулятор (Fast Emulator);
- удобные ярлыки;
- шаблоны для добавления новых действий;
- заранее определенные структуры проектов;
- плагины генератора кода.
Кроме того, Android Studio предлагает поддержку Kotlin , мощного языка для Android-проектов, а также калибровку мониторов для развертывания эффективных переходов и анимации.
Android Studio помогает легко и эффективно подключаться к облачной базе данных Firebase .
Чтобы разработчики могли использовать сторонние библиотеки при создании своих приложений, Android Studio предоставляет поддержку gradle и maven.
Чтобы создавать надежные Android-приложения как в одиночку, так и в команде, важно уметь пользоваться Android Studio и другими инструментами, такими как Github.
4. Излишнее усложнение пользовательского интерфейса
Иногда разработчики усложняют интерфейс, в то время как он должен быть простым и удобным для пользователя.
Приложения для Android с улучшенным пользовательским интерфейсом получили огромное внимание и множество скачиваний. Вот основные признаки удобного интерфейса:
- быстрая загрузка экрана;
- тематика и цвета, соответствующие основному назначению приложения;
- ненавязчивая реклама;
- использование изображений и анимации;
- упрощенный процесс регистрации.
5. Интеграция большого объема функций
Зачастую разработчики интегрируют в приложения множество функций вместо того, чтобы сосредоточиться на нескольких, но хорошо проверенных. Между тем, действительно успешные приложения, как правило, не отличаются многофункциональностью, но отлично работают с ограниченным набором функций.
Разработчикам стоит доводить до ума несколько качественных функций, а не интегрировать те, что не имеют никакого значения для потребителей. Большинство людей приводят в замешательство непонятно управляемые и потому недоступные для них опции.
Пользователи немедленно удаляют приложение, как только обнаруживают в нем слишком много бесполезных функций. Чтобы предотвратить подобную ситуацию, определите основные возможности приложения, соответствующие его цели.
6. Ожидание завершения сетевого запроса
Все мы знаем, как справляться с задачами с длительным временем выполнения, например выгрузка и загрузка файлов, запросов базы данных и т. д. Для этого пользователю показываются определенные загрузчики и индикаторы выполнения.
Тем не менее пользователь часто ожидает завершения задач, не имея полной уверенности в успешности сетевого запроса, поскольку не исключены сбои в работе сети, неэффективная обработка данных или иные проблемы с интернетом.
Но успешные сетевые вызовы более вероятны, чем неудачные. Так зачем же ждать успешного ответа сервера? Именно такой подход позволит пользователю предположить успех сетевого запроса до его завершения и гарантирует обработку сбоев при их возникновении.
Допустим, вы разрабатывает социальную сеть и хотите оптимизировать пользовательский опыт, чтобы индикатор выполнения сигнализировал о новых лайках. Гораздо лучше сразу оповещать об этом пользователя. Если же произойдет какая-либо ошибка, стоит уведомить и о ней, обрабатывая сетевые вызовы в фоновом режиме.
Заставлять пользователя ждать без необходимости — не лучший подход в современной разработке приложений. Люди не хотят ждать. Такой пользовательский интерфейс может сократить количество скачиваний.
7. Отсутствие обработки ошибок и сбоев в работе Сети
Большинство масштабных и сложных проектов по разработке приложений нуждается в поддержке нескольких программистов. Вот почему почти всегда есть вероятность каких-либо ошибок в программном обеспечении.
Приложение, скорее всего, не перестанет функционировать после ошибок, если вы предусмотрите их обработку. Такой подход позволит клиенту продолжать работу после возникновения ошибки, а вам — получить отчет о том, как именно она произошла.
Еще одна веская причина необходимости обработки ошибок — это безопасность! Некоторые ошибки, если не будут обработаны должным образом, могут привести к тому, что программа и базовая операционная система окажутся в уязвимом состоянии.
Обработка ошибок должна быть предусмотренным и хорошо продуманным процессом. Ведь даже при корректном обслуживании ошибки могут записываться в журнал регистрации или выводить на экран экстренные уведомления, предоставляя потенциальным злоумышленникам ценную информацию с указанием на конкретные уязвимости.
Таким образом, важнейшей задачей любого проекта является обработка ошибок и сбоев. Игнорирование всевозможных погрешностей приведет к невозможности их устранения.
Кроме того, отсутствие удобной обработки ошибок производит не лучшее впечатление на пользователя. Это может привести к тому, что он просто удалит приложение.
Поэтому предусмотрите обработку любых возможных ошибок и сбоев удобным для пользователя и разработчика способом.
8. Отказ от Kotlin-сопрограмм
Kotlin был представлен Google как самый популярный, мощный и рекомендуемый язык для разработки Android-приложений.
Огромным преимуществом этого языка являются Kotlin-сопрограммы. Они позволяют выполнять длительные и трудоемкие задачи в фоновом/рабочем потоке, чтобы снизить нагрузку на главный .
Чтобы приложение оставалось отзывчивым и работало бесперебойно, рекомендуется освободить главный поток. Этого легко достичь с помощью Kotlin-сопрограммы.
Как и потоки, сопрограммы могут выполняться параллельно. Кроме того, они настолько дешевы, что можно создать их тысячи без каких-либо проблем с памятью.
9. Недоработанные UI/UX
Это не ошибка, а просто упущение с точки зрения удобства для пользователя. Как уже было сказано, приложения для Android с отличным интерфейсом пользуются наибольшей популярностью. Поэтому настоятельно рекомендуется улучшать его.
Моменты, которые следует учитывать при улучшении UI/UX
Изображения, в отличие от обычного текста, лучше помогают раскрыть смысл информации. Поэтому они являются чрезвычайно важным контентом. Одно изображение может сообщить пользователю больше, чем тысяча слов. Но изображения потребляют много памяти .
Предположим, у вас есть изображение размером 4000 X 3000 пикселей (потребляющее около 4 байта * 4000 * 3000 = 45,7 МБ). Это слишком много памяти (45,7 МБ ОП) для одного изображения!
Теперь посмотрим на эту проблему с точки зрения разрешения экрана. Для демонстрации изображения размером 4000 X 3000 на экране с разрешением 1920 X 1080 пикселей потребуется всего 4 байта * 1920 * 1080 = 7.9 МБ.
Для выполнения вышеуказанной задачи необходимо:
- Измерить видовую конфигурацию, в которой будет демонстрироваться изображение.
- Соответствующим образом масштабировать/обрезать слишком большое изображение.
- Отобразить масштабированное/обрезанное изображение.
- Использование фрагментов
Запуск отдельной задачи для каждого экрана приложения может быть неэффективным, поскольку система будет хранить в памяти столько задач, сколько сможет.
Фрагменты также полезны, когда вы разрабатываете приложение, подходящее как для телефонов, так и для планшетов.
- Использование динамики, растровых изображений и анимации
Растровые изображения, движущиеся картинки и анимация играют жизненно важную роль, когда речь заходит о привлекательном и информативном UI с точки зрения пользователя.
Анимация может расширить набор визуальных подсказок, которые уведомляют пользователя о том, что происходит в приложении. Это особенно важно, когда пользовательский интерфейс изменяет состояние, например когда загружается новый контент или становятся доступными новые действия. Анимация также придает приложению изысканный, более качественный внешний вид.
10. Неэффективное тестирование приложения
Это самая распространенная и нелепая ошибка разработчиков, которые не понимают, что тестирование — самый важный этап любого проекта. Вот почему предупреждение этой ошибки должно быть первостепенной задачей для создателя приложения.
Тестирование перед поставкой приложения клиенту гарантирует качество программного обеспечения. Тщательно протестированный софт обеспечивает надежность, безопасность и высокую производительность. А это гарантирует минимальные временные затраты, экономическую эффективность и, как следствие, удовлетворенность пользователей.
Кроме того, если приложение должным образом организовано и протестировано, то в будущем в него можно легко добавлять новые функции, поскольку удаление или редактирование старого кода напрягает многих разработчиков.
Что следует учитывать при тестировании
- Не проверяйте приложение только на одном устройстве, это может привести к проблемам после представления продукта публике. Некоторые функции могут работать бесперебойно на одном устройстве, но на другом перестанут отвечать на запросы. Поэтому тестируйте приложение на нескольких устройствах (как можно большем количестве).
- Тестируйте приложение на устройствах с низким объемом памяти, различными разрешениями экрана, более старыми версиями ОС. Используя эту практику, вы сможете точнее обнаруживать ошибки как в функционале приложения, так и в пользовательском интерфейсе.
- Протестируйте более тщательно функции, которые отвечают за сетевой запрос (например, при отключении или ослаблении подключения к интернету), чтобы обеспечить эффективную обработку сетевых сбоев.
- Протестируйте как можно более тщательно приложение перед его поставкой пользователю.
Итоги
Разработка приложений для Android таит в себе множество возможностей. Извлечь из них выгоду и создать собственный рынок можно, если избегать вышеуказанных ошибок.
Экосистема Android стремительно растет по всему миру и ее сообщество становится все более разнообразно. Люди из разных слоев общества, люди с ограниченными возможностями, люди, которые хотят иметь необычные функции, такие как ночной режим, и многие другие, используют приложения Android в своей повседневной жизни.
Обычно люди чувствуют себя комфортно, используя приложение на родном языке. Важным шагом является сохранение всех строк в одном файле (обычно strings.xml) для быстрого добавления файлов локализации для разных языков.
2. Не использовать Фрагменты
На заре Android-разработки рекомендовали использовать отдельные Активити для каждого экрана. Со временем разработчики столкнулись с разными проблемами из-за этого. Кроме того, Activities, являющиеся точками входа в приложение, стали уязвимостями.
Если вы какое-то время являетесь разработчиком Android, то знаете, что использование Активити имело смысл пару лет назад, когда API Фрагментов еще не был настолько развит.
Следование этой архитектуре сократит значительное количество взаимодействий вне приложения. Новый компонент навигации Jetpack основан на Single Activity Architecture. Fragments API сделает вашу жизнь намного проще. Возможно, через пару лет разработка под Android переключится с Активити на Фрагменты. И к лучшему.
3. Не использовать Data Binding или View Binding
Среда разработки Android с самого начала была основана на трех типах файлов: XML, Kotlin и Java. Файлы XML содержат все, что связано с дизайном, а файлы Kotlin/Java включают в себя все, кроме дизайна.
В конце концов, необходимо было связать пользовательский интерфейс и бизнес-логику, и именно здесь привязка данных и привязка представления играют ключевую роль. Связь между пользовательским интерфейсом и бизнес-логикой начинается с печально известной функции findviewbyid.
Связывание данных служит для общего блага. Оно позволяет связывать компоненты пользовательского интерфейса в макетах с источниками данных, используя декларативный формат, а не программно.
4. Не использовать Kotlin и корутины
Прошло несколько лет с тех пор, как Google объявил Kotlin рекомендуемым языком для разработки приложений для Android. Это было одно из трансформационных решений: Kotlin исправил болевые точки Java и упросил тяжелую работу разработчиков.
Использование Kotlin для разработки Android открыло новые возможности с такими функциями, как расширения, область видимости, классы данных, object выражение, null безопасность и т.д. Помимо разработки Android, вы также можете начать многоплатформенную и серверную разработку с Kotlin.
Асинхронное программирование играет ключевую роль в мобильной разработке. На ранних этапах мы использовали AsyncTask. Со временем появилась RxJava, и это коренное изменение. Но у RxJava есть большая кривая обучения и совершенно другой подход с обратными вызовами.
Затем появились корутины, решение Kotlin для асинхронного программирования с простым подходом. В наши дни корутины стали стандартным решением для реализации асинхронных задач. Мощные функции и простая реализация делают их более адаптируемыми.
Kotlin делает вашу разработку простой и краткой, в то время как корутины позволяют выполнять асинхронные задачи последовательно без необходимости изучать что-либо новое. Использование их в ваших разработках приведет только к более продуктивным и эффективным результатам.
5. Ошибаться в дизайне
В дизайне можно выделить сразу несколько ошибок разработчиков:
- Недооценка ConstraintLayout
- Чрезмерное использование ConstraintLayout
- Боязнь MotionLayout
6. Незнание основных уязвимостей
Хранение конфиденциальных данных
Хранение конфиденциальных данных в Android shared preference, базе данных или локальном хранилище представляет собой риск. Их легко взломать. Многие разработчики не знают об этом и используют shared preference для хранения конфиденциальных данных пользователя.
Эту проблему можно решить с помощью новой библиотеки хранилища данных или библиотеки предпочтений Encrypted или путем реализации шифрования самостоятельно.
Безопасные коммуникации
7. Не знать возможности Android Studio
Не имеет значения, насколько мощным является ваше оружие, если вы не умеете правильно им пользоваться. Как разработчики, нам повезло, что у нас есть такой мощный инструмент, как Android Studio, но вы должны знать, как его эффективно использовать.
Есть много скрытых функций, таких как удобные шорткаты, живые шаблоны, шаблоны файлов, предопределенные структуры проектов, плагины генератора кода, настройки и многое другое. У нас также есть инспектор базы данных, инспектор макета, профилировщик и многое другое, чтобы быть продуктивными.
Android Studio также предоставляет инструменты отладки для редактора навигации для просмотра графа навигации приложения и редактор движения для реализации эффективных анимаций и переходов.
8. Не использовать библиотеки Jetpack
Библиотеки JetPack охватывают основные функции, такие как paging3 для разбивки на страницы, Room для локальной базы данных, WorkManager для длительных фоновых задач, DataStore для улучшенного хранения данных, Hilt для DI, navigation component для навигации в приложении, App Startup для сокращения времени запуска приложения и т.д.
Все эти библиотеки созданы с учетом производительности и простоты использования в сложных задачах с меньшим количеством кода.
Читайте также: