Бывали ли у вас ситуации, когда ваше приложение работало некорректно у отдельно взятого тестировщика или на отдельно взятом устройстве? Кажется, что с такой ситуацией так или иначе знаком каждый разработчик. И найти причину проблемы порой может быть достаточно сложно из-за сложности получения информации: нет возможности снять логи, заглянуть в БД или Shared Preferences приложения и т.д. Некоторые из этих проблем можно решить просто попросив тестировщика зайти в браузер.

Именно для этого и была начата разработка библиотеки Ultra Debugger. На данный момент она позволяет:

  • Отлеживать состояния приложения с помощью метода saveValue(Context context, String key, Object value). Можно посмотреть, работает ли прямо сейчас сервис, последнее высчитанное значение и т.д.
  • Писать логи с помощью метода addLog(Context context, String text[, Throwable throwable]).
  • Просматривать и редактировать Shared Preferences.
  • Просматривать и редактировать записи в SQLite.
  • Просматривать файлы, в том числе файлы в папке приложения.
  • Просматривать значения полей в текущем активити.
  • Вызывать методы в текущем активити.

Сама библиотека построена на модулях. За счет этого, при желании можно отключить ненужный функционал, а также расширять его путем добавления новых модулей.

Разработчику

Интеграция библиотеки очень проста:

  1. Прописываем зависимости:

    debugCompile 'ru.bartwell:ultradebugger:1.3'
    compile 'ru.bartwell:ultradebugger.wrapper:1.3'

    Как мы видим, основная зависимость подключается только для debug-сборок. При необходимости, можно подключать ее только для определенных flavor.

    Отдельно подключаем wrapper. Это необязательно, мы можем вызывать методы библиотеки напрямую, но тогда могут возникнуть сложности при отключении библиотеки для релизных сборок. Он представляет собой обертку, которая вызывает методы библиотеки используя рефлексию. Да, рефлексия непроизводительна, но для debug-сборок это кажется не таким критичным.

  2. В классе Application инициализируем библиотеку:

    @Override
    public void onCreate() {
    	super.onCreate();
    	// Wrapper будет работать только в debug-сборках
    	UltraDebuggerWrapper.setEnabled(BuildConfig.DEBUG);
    	// Необязательный второй параметр указывает порт для веб-интерфейса
     	UltraDebuggerWrapper.start(this, 8090);
    }

    BuildConfig.DEBUG может быть заменен например на BuildConfig.FLAVOR.equals(«dev»).

  3. При необходимости добавьте логи и сохраните нужные значения:

    UltraDebuggerWrapper.saveValue(context, «SomeValue», 12345);
    UltraDebuggerWrapper.addLog(context, «Some event»);

При запуске приложения в логи будет выведена строка содержащая ссылку на веб-интерфейс. Ссылка формируется из IP-адреса смартфона и номера порта указанного при вызове метода start(). При желании IP-адрес смартфона и номер порта можно получить с помощью методов UltraDebuggerWrapper.getIp() и UltraDebuggerWrapper.getPort() и вывести их в виде Toast или диалогового окна.

Тестировщику

Использовать библиотеку тестировщику тоже довольно просто. Нужно просто подключить смартфон и компьютер к одной WiFi-сети, набрать IP-адрес смартфона и порт в браузере (например, 192.168.0.33:8090). Может потребоваться разблокировать смартфон и запустить приложение. После этого откроется меню подключенных модулей и с помощью перехода по ссылкам можно будет получить необходимую информацию. Вот так выглядит например просмотр файлов:

image
Да, WEB-интерфейс выглядит по-спартански :) Но нужную информацию при этом получить вполне позволяет.

Заключение

Определенно здесь есть плацдарм для доработок. Можно наращивать количество модулей, можно улучшить UI и UX веб-интерфейса, добавить тесты и поработать над качеством кода. Конечно, это все — прямая обязанность автора библиотеки. Но если вдруг Ultra Debugger покажется вам полезным и у вас возникнет желание добавить модуль или что-то доработать — смело создавайте Pull Request, приветствуется любая помощь по проекту.
Поделиться с друзьями
-->

Комментарии (7)


  1. kolipass
    19.07.2017 07:19
    +1

    А чем не подошли популярные решения:


    amitshekhariitbhu/Android-Debug-Database
    facebook/stetho


    И ещё несколько других менее популярных?


    От себя реквестирую фичу: sqlcipher бы...


    1. bartwell
      19.07.2017 10:31

      У первого достаточно узкий функционал. Второе лично мне кажется не очень удобным в использовании. Ну и из всех решений, которые мне удалось найти на тот момент, я не встретил ни одного расширяемого. Здесь же достаточно просто создать собственный модуль при необходимости, притом практически под любой функционал.

      К сожалению, мне не доводилось пока работать с sqlcipher. Бегло проглядел, кажется, что его поддержку можно реализовать на базе уже существующего модуля SQLite. Не могу обещать, что смогу это сделать в ближайшее время. Если у вас будет возможность — буду рад вашей помощи и отвечу на любые ваши вопросы.


  1. Arvalon
    19.07.2017 13:37
    +1

    Ultra Debugger умеет перехватывать сетевые запросы? Через вышеупомянутое stetho можно обернуть сетевое взаимодействие и наглядно смотреть что там происходит, отлаживать REST-запросы.

    Да, запускать не очень удобно, надо переподключатся если приложение перезапустилось, вообще только через Хром работает. Но предоставляет возможности поковыряться наверное везде в приложении, где только может потребоваться — SharedPrefs, SQLite и др.


    1. bartwell
      19.07.2017 13:44

      В данный момент нет. Однако, модульность позволяет свободно расширять функционал. Тоже уже задумывался, что возможно неплохо было бы добавить.


    1. CheY
      19.07.2017 19:47
      +1

      А есть ли возможность через Stetho или Ultra Debugger модифицировать запросы/ответы. Т.е. получить полноценный HTTP-proxy? Я так и не нашёл такой возможности, а это чуть ли не основная фича, которую хотелось бы получить.


      1. bartwell
        19.07.2017 19:51

        Чаще всего для этого используют Fiddler или Charles… Ultra Debugger сейчас такой возможности не предоставляет.


        1. CheY
          20.07.2017 12:45

          Да, их и используем (+ burp). Но есть несколько минусов:
          — они не специализированы для мобильных
          — они ничего не могут сделать с траффиком через мобильный интернет
          — они требуют установки пользовательских сертификатов для проксирования https
          — пользовательские сертификаты требуют отключения certificate pinning'а, если он есть, а также разрешения на доверие к ним в манифесте андроид-приложений начиная с 23-ей версии, если не ошибаюсь

          Это все решаемо. Но такая прослойка между приложением и api для работы с сетью естественным образом обошла бы все эти проблемы.