Дебаж как боженька. План дебага Android приложения
Не для кого не секрет, что в ходе разработки мобильного приложения возникает масса ситуаций, где разработчик мог допустить ошибку, что-то не предусмотреть и т.д. Разновидностей багов невероятное множество. Частично защититься от них можно покрыв приложение автотестами, но все равно, так или иначе какой-нибудь косяк всплывёт, все мы люди.
В этой статье я бы хотел затронуть тему багов, которые происходят в runtime. Я не буду углублять в то, как пользоваться отладчиком или профайлером в Android Studio, затрону просто методологию, подход на конкретном примере.
Большая часть мобильных приложений по сути своей являются клиент - серверными, иными словами - ходят по запросу на какой-то сервер, получают данные, десериализуют, преобразовывают в удобный для отображения вид и отображают.
Возьмем случай, когда у нас был выполнен запрос на сервер, но данные на UI мы не увидели, баг повторяется всегда и не являются плавающим, каков тут план отладки?
План отладки регулярного бага с отображение на UI данных с сервера:
- Самый первый и самый примитивный пункт, это воспроизвести баг и заглянуть в Logcat вашей IDE, возможно там засел Exception, который был обработан, но игнорировался на UI (как правило на UI мы не отображаем серверные ошибки). Хорошо, если через консоль всё понятно и на этом можно заканчивать отладку
- Если консоль с логами не вывела нам никакой runtime exception, то нужно убедиться, а наш запрос вообще уходит? Он что-то получает в ответ? Тут есть 2 пути, первый путь, это прикрутить LoggingIntercepter на ваш http клиент и выяснить в консоли, получаем ли мы что-то, а второй путь, это запустить Postman/Swagger и дернуть запрос, понять, получаем ли мы ответ.
- Если ответ от сервера приходит с корректным статусом и тело ответа не пустое, а представляет какие-то данные в виде json, то самое время проверить, а правильно ли вы аннотировали модельки для десериализации данных, правильно ли описаны синтаксически все поля, не стоит ли где аннтация @Transient и т.д.
- Если и с моделями данных всё ОК, то самое время включить дебаггер Android Studio и начать исследовать вызовы функций и маппинг моделей, начиная от data слоя к presentation, устанавливая точки остановок и изучая стек вызываемых фреймов в debug console
Согласитесь, это простой случай, но даже в нём без плана действий новичок может выбрать неверный шаг и начать с дебаггера студии, а проблема была в том, что данные от сервера криво десериализуются.
Можно усложнить ситуацию и добавить локальное хранение кэша в БД SQlite, использую популярную ORM Room, как тогда в этом случае не заблудиться в подходах и не просидеть весь день в поисках злосчастной ошибки?
План отладки регулярного бага в цепочке backend-local database-UI:
- Первые 3 пункта можно повторить из предыдущего чек-листа
- Если запрос на бэкэнд отрабатывает корректно и все данные приходят, то стоит заглянуть в БД, а хранится ли у нас там что-то, это можно сделать через Database Inspector или через любую программу, которая открывает файл sqlite базы данных
- Если и там данные хранятся корректно, то самое время проверить на правильность ваш SQL запрос, который скорее всего будет @Query и может иметь определенную сложность. Для начала надо просто скопировать этот запрос и сделать его напрямую к БД через ту же программу, в которой открыли ваш файл БД, на крайний случай поставить точку остановки отладчиком на том методе, который вызывает выполнение sql запроса и в evaluate expression руками прописать выполнение запроса через билдер
- Если с БД всё корректно, то включаем дебаггер Android Studio и продолжаем исследовать точками остановок наш код от data до presentation слоя
Конечно, можно пойти ещё дальше и усложнить баг нерегулярностью воспроизведения, но чаще всего така история бывает, когда код не покрыт автотестами. Бывает так, что в силу обстоятельств нет возможности и времени писать автотесты. Основная задача в таком случае, это научиться стабильно воспроизводить баг, в этом обычно помогают тестировщики мануалы (ручные). Так как мануальные тестировщики большую часть действий крутят UI и кнопки, то и подход в исследовании кода под дебаггером скорее всего будет с presentation слоя приложения. Хотяяяя... опять же, смотря какой баг, но давайте пока рассматривать вот такой путь.