Документ описывает опыт разработчика по устранению проблем в нескольких мобильных проектах, связанных с неудачным выбором технологий, таких как butterknife и rxandroid. Обсуждаются негативные последствия этих библиотек, включая ухудшение пользовательского опыта и сложности в поддержке приложений. Приводятся примеры успешного переписывания кода и улучшения оценок приложений после исправлений.

1. История нескольких
проектов
и что в них пошло не так
Вячеслав Романюк

2. Немного обо мне
• В мобильной разработке с
2009 года, в разработке
вообще – с 2007
• В Complex Networks
работаю уже 5 лет
• Среди прочих, создали
приложения для двух
музыкальных конференции
с количеством участников в
каждой более 50000
человек в течении двух дней

3. Что мы обсудим сегодня
• Случай, когда выбранная технология испортила User
Experience и убила проект безвозвратно
• Пример технологии, которую адаптировали слишком
рано, что усложнило дальнейшую разработку
• Пример использования библиотеки ButterKnife,
которая принесла вполне ощутимый вред, но не пользу
• Реальная ситуация с использованием RxAndroid,
которая сделала проект практически
неподдерживаемым

4. • Проект был написан контакторами как web view с
кодом на основе React.js (React Native был
представлен только в 2015 году)
• Приложение зависало, показывало ошибки по
любому поводу и без него
• В Google Play Market было меньше 5000 активных
пользователей (с учетом крайне агрессивной рекламы
и куче траффика, направлявшегося в магазин), кучи
гневных отзывов и оценка 2.3.

5. После полного
переписывания кода
• Приложение было переписано полностью на Java
• В течении 6 месяцев после публикации количество
активных установок перевалило за 50.000
• Оценка в Play Market поднялась до 4.2
• Отрицательные комментарии от старой версии
приложения были на столько сильно заплюсованы
аудиторией прошлой версии приложения, что
продолжали показываться как наиболее актуальные
даже при таких показателях

7. Navigation Architecture
Component

8. Как должно было быть

9. Как было большую часть
времени: 400 строк XML кода

10. ButterKnife

11. ButterKnife помогает:
• Сделать код визуально чище
• Сгруппировать View в список или массив и применять
ко всем им одни и те же модификации
• Убрать из кода анонимные классы для Listeners и
забыть о findViewByID

12. Минусы ButterKnife
• По факту, эта библиотека не привносит в проект
ничего полезного, кроме спорного комфорта
разработчика
• Для каждого класса, который использует аннотации
ButterKnife, генерируется отдельный ViewBinder класс

15. • Соответственно, цена вызова findViewByID сильно
возрастает
• Сгенерированные классы очень быстро суммируются
в размере конечного APK
• В одном из проектов уход от библиотеки уменьшил
размер APK на 1,5 Мб (притом имплементация
ButterKnife занимает всего 17Кб)
• В большинстве случаев публичные поля (как и поля
вообще) для View не нужны, но они необходимы для
корректной работы библиотеки

16. Плюсы RxAndroid
• Прекрасное решение для реактивной реакции на
результаты запросов или длительных операций в
фоне
• Огромное количество вспомогательных ресурсов и
ответов на StackOverflow
• Позволяет гранулярно работать с результатами
работы запросов/функций, видоизменять их,
объединять с другими такими же результатами

17. Минусы RxAndroid
• Высокий порог вхождения
• В большинстве случаев 90% функционала библиотеки
не нужно, а потому можно использовать обычные
Callback
• Огромное количество кода, необходимого для
настройки и правильной обработки результатов
• В случае отсутствия адекватной документации,
новому члену команды (или новой команде) сложно
поддерживать проект

18. • Проект, доставшийся от крупной аутсорсинговой компании
• Больше половины кода – код RxAndroid
• Крайне устаревшие версии библиотек
• Сжатые сроки на фикс багов
• Проблема на экране ввода данный для доставки и оплаты
онлайн заказа, логически разделенного по
сворачивающимся блокам
• После завершения ввода данных в каждом из блоков, новая
информация посылается на сервер для уточнения суммы
заказа
• Текущий блок сворачивается автоматически, а следующий
таким же образом разворачивается

19. Суть проблемы
• После завершения ввода данных
в первом блоке данные
отправляются на сервер, первый
блок сворачивается и
открывается второй
• После завершения ввода данных
во втором блоке происходит то
же самое
• Перед открытием третьего блока
первый и второй по очереди
вновь разворачиваются и снова
сворачиваются
• Конечная сумма к оплате не
корректна

20. • Документации у проекта нет
• Есть четыре разных backend-а, на которые делаются
запросы
• Запросы и кастомный парсинг результатов громоздки
и запутаны
• С точки зрения data flow такого поведения быть не
должно, код перехода из состояния в состояние
должны отрабатывать корректно

21. В чем была проблема:
• На одном из серверов в ответе на один из запросов было
переименовано поле
• Результат запроса не проходил валидацию и из-за настроек
RxAndroid в массив результатов подставлялся последний корректный
• Экран был имплементирован так, что в одно и то же время мог быть
открыть только один раскрывающийся блок
• Триггером для открытия первого блока было как раз отсутствие
переименованного поля
• Каждый разворачивающийся блок проверял на корректность только
свою часть массива результатов, которые указывали на то, что нужно
открыть следующий блок

22. Из-за запутанности кода
RxAndroid и отсутствия
документации на решение
проблемы ушло полторы недели

23. Спасибо за внимание
• twitter/instagram: @sromanuk
• email: sromanuk@me.com