От переводчика: постарался все изложить максимально близко к оригиналу. Перевод получился в свободной форме — думаю это лучше передаст смысл статьи. На картинках есть всплывающие подсказки. Оригинал здесь.
Я решил написать о некоторых типичных ошибках и проблемах, с которыми когда-то столкнулся сам, когда начинал разрабатывать Android-приложения три года назад, и нескольких других, с которыми сталкивались начинающие Андроид-разработчики. Итак, поехали!
1. Тот момент, когда ты сделал все страницы своего приложения используя Активити, а твой босс сказал тебе, что он хочет чтобы страницы можно было перелистывать свайпом
И ты пытаешься объяснить, что прежде чем можно будет менять страницы приложения свайпом, активити нужно переделывать во фрагменты
Совет: одно из лучших решений, что ты можешь предпринять — всегда использовать фрагменты, а активити использовать только для управления фрагментами. Активити — это доисторические традиции Андроида. Использование фрагментов — безусловно приносит пользу. Но это не правило, а всего лишь один из способов избежать подобной проблемы.
2. Когда ты пытаешься собрать релиз-версию приложения, после добавления сотни зависимостей, и получаешь таинственные и непонятные ошибки от ProGuard, которые нереально пофиксить
Совет: в зависимости от рабочего процесса, это неплохая практика чтобы собрать релиз-версию проекта и не ждать долгие месяцы пока проект не будет завершен. Это позволит протестировать приложение и легко определить ошибки, пока кодовая база еще достаточно маленькая.
Другой хорошей практикой будет проверка правила ProGuard'а для фреймворков, которые применяются в проекте. Имеет смысл добавить нужные правила ProGuard для библиотеки и все должно хорошо работать.
3. Когда ты пытаешься обновить код, который был написан без соблюдения какой-либо архитектуры
Совет: эта тема заняла бы целый рассказ. Лучше всего проверить старый код и написать несколько тестов, исключив в нем ошибки, перед тем как начать рефакторинг. Поверь мне, если это не твой собственный проект, ты не захочешь переписывать его с нуля.
4. Когда ты забыл загрузить маппинг-файл ProGuard’а в аналитику сбоев Firebase, и последний билд крэшнулся с обфусцированными ошибками
Совет: можно установить автоматическую загрузку маппингов ProGuard’а в инструменты аналитики сбоев Firebase. Подробнее об этом можно прочитать здесь.
5. Когда загрузил свое первое приложение в Google Play Store и получил всего 50 загрузок за три месяца…
Совет: в первую очередь лучше создавать приложения, которые необходимы людям, тогда ты обретешь успех в маркете. Также, приложение не сможет разрекламировать себя само.
Ты потратил 500 часов своего времени на создание приложения, и не можешь позволить себе потратить несколько долларов и сотню часов чтобы продвинуть его?
6. Когда ты вернулся к своему коду, который писал 3 месяца назад
Совет: это одновременно и хорошо и плохо. Хорошо — потому что ты стал лучше писать код за последние три месяца и теперь видишь свои собственные ошибки. А почему плохо? На самом деле ничего серьезного: ты вырос за три месяца и вряд ли сделаешь похожие ошибки
7. Когда пытаешься собрать проект в Android Studio на старом, слабом компьютере
Совет: существует официальное руководство как ускорить сборку проекта.
8. Когда твое приложение крашится только в release-mode и ты не видишь логи, чтобы узнать что происходит
Совет: самое простое решение — внедрить crash reporter, например Crashlytics, и ты сможешь зафиксировать ошибку в консоли.
9. Когда ты ждешь бэкэнд-разработчика чтобы завершить API.
Совет: можно попросить структуру будущего API у бэкенд-разработчиков и создать макет используя какие-либо фиктивные данные для работы. Это не всегда будет хорошо работать, и придется иногда вносить некоторые изменения чтобы потом работать с реальным API.
10. Когда твое приложение стало популярным в Google Play Store.
Совет: включай свою любимую песню и танцуй! Ты отлично поработал и это не было зря!
Постарайся не потерять популярность в маркете, и начинай проводить вечеринки (Пожалуйста пригласи меня).
Продолжай делать потрясающие приложения которые нужны людям, и помни:
Комментарии (10)
musicriffstudio
29.11.2017 09:32Активити — это доисторические традиции Андроида. Использование фрагментов — безусловно приносит пользу.
какую?
Skerrigan
29.11.2017 09:47Как минимум не придется «все переписывать» (тут ржущий смайлик).
Arvalon
29.11.2017 10:51Присоединюсь к обсуждению п.1 — замена активностей на одну с кучей фрагментов в ней. Плюсы уже описали — большая гибкость, модульность, меньше переделок если например да, потребуется загнать все экраны в swipe для перелистывания. А на большом экране — размещать сразу несколько на одном экране.
Но а минусы, подводные камни? Использование вложенных фрагментов, как там с этим? Насколько помню есть (была?) проблема с сохранением состояния вложенных фрагментов (фрагментов во фрагменте), они не переживали пересоздания, и есть способ костыль решить эту проблему — setRetainInstance.
Может быть есть ещё какие-нибудь ограничения, усложнения при использовании схемы «одна активность — много фрагментов»? Наложение lifecycle активности и фрагментов, использование FrafmentDialog'ов, ещё что-нибудь не всплывёт?
RYGITAL Автор
29.11.2017 09:55Возможность легко адаптировать приложение под планшеты (или большие экраны);
И как ни крути — с фрагментами интерфейс более гибкий чем с активитиmusicriffstudio
29.11.2017 10:12А конкретней? Ширину элементов нельзя указать или изменить?
Гугл ясно говорит что фрагменты вводились для возможности сборки одного активити из нескольких фрагментов, т.е. для модульности и повторному использованию кода элементов.
RYGITAL Автор
29.11.2017 10:29Можно задать ширину, высоту, поведение — в зависимости от требований.
То бишь мы берем активити как корневой элемент, на котором будем располагать один или несколько фрагментов.
При этом для смартфона можно сделать чтобы одновременно показывался только один фрагмент на экране (а фрагменты менялись смахиванием), а для планшета можно разместить сразу все фрагменты на экране (потому что места хватит).musicriffstudio
29.11.2017 10:40так и без фрагментов это можно сделать.
См. назначение фрагментов от производителя
You can combine multiple fragments in a single activity to build a multi-pane UI and reuse a fragment in multiple activities. You can think of a fragment as a modular section of an activity, which has its own lifecycle, receives its own input events, and which you can add or remove while the activity is running (sort of like a «sub activity» that you can reuse in different activities).
преимущество фрагментов в повторном использовании кодаRYGITAL Автор
29.11.2017 10:43Ну да — это их предназначение
И из него вытекают остальные преимущества (такие как простота создания и изменения интерфейса)
jawaharlalnehru
Самое простое — вставить в тэг application в AndroidManifest.xml. Тогда логи будут показываться даже в release-mode. Главное — не забыть убрать строчку перед загрузкой в Google Play. А Crashlytics подключают, когда хотят отловить крэши у пользователей на неподключённых к Android Studio устройствах.
niveus_everto
Можно еще сделать buildType stage и применять release настройки