Как посмотреть значения переменных android studio

Общая информация об отладке в Android Studio

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

Когда вы разрабатываете приложение, то студия собирает отладочную версию программы, соединяется с устройством/эмулятором, устанавливает и запускает её.

Обычно для запуска приложения вы используете значок с зелёным треугольником Run (Shift+F10) на панели инструментов. Для отладки следует нажимать соседнюю кнопку Debug (Shift+F9) с изображением жучка .

Остальные действия будут идентичными — вам надо выбрать устройство, на котором будет происходить отладка.

Android Studio откроет окно Debug. Можно открыть его вручную через кнопку 5: Debug в нижней части среды разработки. Окно показывает потоки и переменные в вкладке Debugger, статус устройства в вкладке Console и системные логи в вкладке Logcat.

Если приложение уже запущено, то необязательно его перезапускать для работы в отладочном режиме. Вы можете нажать на кнопку Attach debugger to Android proccess , которая идёт сразу после кнопку с жучком.

В вкладке Logcat вы видите системные сообщения, включая сообщения от вашей программы, если вы использовали их своём коде. Для записи логов используется класс Log. Подробнее о нём в отдельной статье.

Логи можно просматривать также через панель Android DDMS (Dalvik Debug Monitor Server) — запускается через кнопку 5: Android в нижней части студии. В Android DDMS вы можете просматривать логи только нужного процесса, если нажмёте на кнопку Only Show Logcat from Selected Process .

Точки останова (Breakpoints)

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

Откройте свой исходник, определите строку кода, в которой хотите поставить точку останова и щёлкните по ней. Строка окрасится в жёлтый цвет. Щёлкните в левой части редактора кода в серой области. В этом месте появится красный кружок (повторный щелчок уберёт его), а строка примет розовый цвет. Точку останова можно ставить не только для исполняемого оператора, но и на комментарии.

Запустите приложение в отладочном режиме. Когда выполнение программы дойдёт до установленной точки останова, то студия прекратит дальнейшее выполнение приложения, кружок станет ещё более красным и строка будет выделена. И затем вы можете попытаться выявить причину ошибки.

Для просмотра всех точек останова и их настроек щёлкните на кнопке View Breakpoints в левой части панели Debug . Появится отдельное диалоговое окно.

После того, как вы установили точки останова, щёлкните кнопку Rerun для повторного запуска программы. Когда выполнение кода дойдёт до установленной точки останова, студия выполнит паузу и подсветить строку кода. Панель Debug позволит проверить переменную и выполнить код шаг за шагом.

Для проверки переменных раскройте список в панели Variables. Если панель не видна, то щёлкните кнопку Restore Variables

Для вычисления выражения в текущей точки щёлкните кнопку Evaluate Expression

Для перехода на следующую строку кода без выполнения щёлкните кнопку Step Over .

Для перехода на первую строку кода внутри метода щёлкните кнопку Step Into .

Для перехода на следующую строку за пределами текущего метода щёлкните кнопку Step Out .

Чтобы продолжить работу приложения в нормальном режиме, нажмите кнопку Resume Program .

Отслеживание потребления памяти

Студия позволяет также отслеживать потребления памяти объектами и показывает, какие классы и потоки используют объекты.

Запустите студия в отладочном режиме, щёлкните 6: Android, чтобы открыть панель Android DDMS. Выберите вкладку Devices | logcat, выберите ваше устройство из выпадающего списка, выберите вашу программу по имени пакета из списка запущенных программ.

Щёлкните кнопку Start Allocation Tracking . Начинайте пользоваться программой.

Повторно нажмите на предыдущую кнопку Stop Allocation Tracking. Студия покажет объекты, выделенные системой для работы.

Android Device Monitor

Для анализа потребления памяти, сетевого трафика, поведения приложения при входящих звонках можно использовать графический инструмент Android Device Monitor. Щёлкните кнопку Monitor на панели инструментов. Android Device Monitor откроется в новом окне. Опытные программисты увидят знакомое окно, когда работали с Eclipse.

Скриншоты и видео

Вы можете делать скриншоты и видео работающего приложения.

Запустите приложение и откройте панель 6: Android. Щёлкните кнопку Screen Capture в левой части панели.

По такому же принципу можно сделать видеозапись через кнопку

Источник

Можно ли просматривать переменные во время выполнения?

Я знаю основы отладки, и я знаю, что могу добавлять часы к переменной, которая останавливает выполнение программы при заданном условии. Но я не хотел останавливать программу каждый раз, когда мне нужно увидеть значение переменной. Я также не хочу регистрировать значение каждой релевантной переменной в logcat … Я только хотел увидеть их значения, как я, на контрольных точках, только во время выполнения.

Я программирую Android в Android Studio.

Спасибо за помощь!

Когда ваша программа остановилась в точке останова, щелкните значок справа от меню отладчика (см. Рисунок ниже). Вы можете ввести методы или имена переменных в это окно и посмотреть, что они будут.

Вы можете ввести любое выражение, которое вам нравится (до тех пор, пока оно находится в пределах области, где вы нарушили код), и вводить любые жестко закодированные значения или объекты без повторного запуска вашего проекта.

Чтобы добавить переменную в список наблюдения

Начните с размещения точки останова в классе, где вы хотите посмотреть определенную переменную. Запустите код, и как только он достигнет точки останова из окна окна «Переменные», вы увидите все доступные переменные. Просто выберите тот, который вы хотите посмотреть, а затем щелкните правой кнопкой мыши и выберите «Добавить в часы» из раскрывающегося списка.

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

Источник

Использование отладчика Android Studio по максимуму

Это хитрость, о которой я узнал совсем недавно у Senior Android разработчика в моей компании, и теперь я чувствую себя несчастным, сожалея о времени, которое я провел в ожидании сборки Gradle, чтобы проверить свои изменения при написании Android приложений.

Вот типичный сценарий, который каждый Android разработчик мог бы встретить, по крайней мере, один раз в течение своего жизненного цикла разработки. У вас есть список элементов, которые вы хотите показать в ListView или RecyclerView.

Ниже приведен наш возлюбленный метод onBindViewHolder , который связывает вашу модель с вашими view-компонентами RecyclerView.

Теперь, допустим, вы захотели изменить цвет текста для каждого третьего элемента в списке. Таким образом, код будет выглядеть примерно так:

Затем вы нажмёте Run и дождётесь завершения сборки и увидите ваши изменения, так?

Теперь вы бы подумали, существует ли другой путь для достижения этой же цели?

Твой выход, Android Studio! Да, нам не нужен внешний плагин или инструмент для достижения вышеупомянутой задачи и более того, нам даже не придется заново собирать проект. Вы не ослышались, мы обойдёмся без Gradle 🙂 Вот как!

Шаг 1 — Необходимо определить конфигурацию запуска

Такая конфигурация запуска позволит нам запускать наше приложение и присоединять к нему отладчик из Android Studio, а также вы сможете присоединить его к уже запущенному процессу.

Нажмите Run → Edit Configurations.

Edit Configurations» data-src=»https://habrastorage.org/getpro/habr/post_images/925/25e/e1a/92525ee1a0fa26e7cca96d237563c9fa.png»/>

В верхнем левом углу диалогового окна щелкните значок «+» и выберите Android App.

Теперь дайте ему имя, мне нравится называть его Run-Only, но вы можете называть его как угодно.

Выберите модуль, который содержит код вашего приложения, в приведенном ниже скриншоте он называется app.

Важный шаг:

В разделе Installation Options выберите Nothing;
В Launch Options выберите Default Activity;
В разделе Before Launch удалите Gradle-aware Make.

Таким образом, конфигурация должна выглядеть следующим образом:

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

Теперь поставьте breakpoint поближе к строке, которую вы хотите проверить. В нашем случае мы разместим ее там, где мы устанавливаем текст.

Щелкните правой кнопкой мыши на breakpoint и снимите флажок Suspend (рус. приостановить).

Как только вы снимете флажок, диалог расширится и покажет больше опций.

Нам интересен раздел Evaluate and log. Мы напишем там выражение, чтобы проверить изменения в нашем элементе RecyclerView. Нажмите на маленький значок голубого цвета справа от окна ввода Evaluate and log, чтобы развернуть его до более крупного редактора, и добавьте выражение для тестирования, и нажмите Ok, а затем Done.

Теперь нажмите на иконку Debug с выбранной конфигурацией Run-Only и посмотрите на эту магию.

Приложение должно запуститься с вашей Activity по умолчанию, и вы должны увидеть внесенные там изменения. Также, если вы уделяете пристальное внимание IDE, в самом низу вы увидите только одну запускаемую задачу: Launching Activity.

Хотелось бы услышать ваши впечатления, когда вы опробуете эту хитрость!

Источник

Гайд по отладке Android-приложения: ищем баги и читаем логи

Иногда в приложении встречаются ошибки, которые нельзя увидеть даже после запуска. Например, код компилируется, проект запускается, но результат далёк от желаемого: приложение падает или вдруг появляется какая-то ошибка (баг). В таких случаях приходится «запасаться логами», «брать в руки отладчик» и искать ошибки.

Часто процесс поиска и исправления бага состоит из трёх шагов:

1. Воспроизведение ошибки — вы понимаете, какие действия нужно сделать в приложении, чтобы повторить ошибку.
2. Поиск места ошибки — определяете класс и метод, в котором ошибка происходит.
3. Исправление ошибки.

Если приложение не падает и чтение логов ничего не даёт, то найти точное место ошибки в коде помогает дебаггер (отладчик) — инструмент среды разработки.

Чтобы посмотреть на логи и воспользоваться дебаггером, давайте напишем простое тестовое (и заведомо неправильное) приложение, которое даст нам все возможности для поиска ошибок.

Это будет приложение, которое сравнивает два числа. Если числа равны, то будет выводиться результат «Равно», и наоборот. Начнём с простых шагов:

1. Открываем Android Studio.
2. Создаём проект с шаблоном Empty Activity.
3. Выбираем язык Java, так как его, как правило, знают больше людей, чем Kotlin.

Нам автоматически откроются две вкладки: activity_main.xml и MainActivity.java. Сначала нарисуем макет: просто замените всё, что есть в activity_main.xml, на код ниже:

Можете запустить проект и посмотреть, что получилось:

Теперь оживим наше приложение. Скопируйте в MainActivity этот код:

В этом коде всё просто:

1. Находим поля ввода, поле с текстом и кнопку.
2. Вешаем на кнопку слушатель нажатий.
3. По нажатию на кнопку получаем числа из полей ввода и сравниваем их.
4. В зависимости от результата выводим «Равно» или «Не равно».

Запустим приложение и введём буквы вместо чисел:

Нажмём на кнопку, и приложение упадёт! Время читать логи. Открываем внизу слева вкладку «6: Logcat» и видим:

Читать логи просто: нужно найти красный текст и прочитать сообщение системы. В нашем случае это java.lang.NumberFormatException: For input string: «f». Указан тип ошибки NumberFormatException, который говорит, что возникла какая-то проблема с форматированием числа. И дополнение: For input string: «f». Введено “f”. Уже можно догадаться, что программа ждёт число, а мы передаём ей символ. Далее в красном тексте видно и ссылку на проблемную строку: at com.example.appdebugging.MainActivity$1.onClick(MainActivity.java:26). Проблема в методе onClick класса MainActivity, строка 24. Можно просто кликнуть по ссылке и перейти на указанную строку:

Конечно, метод parseInt может принимать только числовые значения, но никак не буквенные! Даже в его описании это сказано — и мы можем увидеть, какой тип ошибки этот метод выбрасывает (NumberFormatException).

Здесь мы привели один из примеров. Типов ошибок может быть огромное количество, все мы рассматривать не будем. Но все ошибки в Logcat’е указываются по похожему принципу:

• красный текст;
• тип ошибки — в нашем случае это NumberFormatException;
• пояснение — у нас это For input string: «f»;
• ссылка на строку, на которой произошла ошибка — здесь видим MainActivity.java:26.

Исправим эту ошибку и обезопасим себя от некорректного ввода. Добавим в наши поля ввода android:inputType=»number», а остальной код оставим без изменений:

Теперь можем вводить только числа. Проверим, как работает равенство: введём одинаковые числа в оба поля. Всё в порядке:

На равенство проверили. Введём разные числа:

Тоже равно. То есть приложение работает, ничего не падает, но результат не совсем тот, который требуется. Наверняка вы и без дебаггинга догадались, в чём ошибка, потому что приложение очень простое, всего несколько строк кода. Но такие же проблемы возникают в приложениях и на миллион строк. Поэтому пройдём по уже известным нам этапам дебаггинга:

1. Воспроизведём ошибку: да, ошибка воспроизводится стабильно с любыми двумя разными числами.
2. Подумаем, где может быть ошибка: наверняка там, где сравниваются числа. Туда и будем смотреть.
3. Исправим ошибку: сначала найдём её с помощью дебаггера, а когда поймём, в чём проблема, — будем исправлять.

И здесь на помощь приходит отладчик. Для начала поставим точки останова сразу в трёх местах:

Чтобы поставить или снять точку останова, достаточно кликнуть левой кнопкой мыши справа от номера строки или поставить курсор на нужную строку, а затем нажать CTRL+F8. Почему мы хотим остановить программу именно там? Чтобы посмотреть, правильные ли числа сравниваются, а затем определить, в какую ветку в нашем ветвлении заходит программа дальше. Запускаем программу с помощью сочетания клавиш SHIFT+F9 или нажимаем на кнопку с жучком:

Появится дополнительное окно, в котором нужно выбрать ваш девайс и приложение:

Вы в режиме дебага. Обратите внимание на две вещи:

1. Точки останова теперь помечены галочками. Это значит, что вы находитесь на экране, где стоят эти точки, и что дебаггер готов к работе.
2. Открылось окно дебага внизу: вкладка «5: Debug». В нём будет отображаться необходимая вам информация.

Введём неравные числа и нажмём кнопку «РАВНО?». Программа остановилась на первой точке:

1. Сразу подсвечивается синим строка, где программа остановлена: в окне кода на 28-й строке и в левом окне отладчика (там даже можно увидеть, какой метод вызван, — onClick).
2. В правом, основном окне отладчика, всё гораздо интереснее. Здесь можно увидеть инстансы наших вью (answer, first, second), в конце которых серым текстом даже отображаются их id. Но интереснее всего посмотреть на firstInt и secondInt. Там записаны значения, которые мы сейчас будем сравнивать.

Как видим, значения именно такие, какие мы и ввели. Значит, проблема не в получении чисел из полей. Давайте двигаться дальше — нам нужно посмотреть, в правильную ли ветку мы заходим. Для этого можно нажать F8 (перейти на следующую строку выполнения кода). А если следующая точка останова далеко или в другом классе, можно нажать F9 — программа просто возобновит работу и остановится на следующей точке. В интерфейсе эти кнопки находятся здесь:

Остановить дебаггер, если он больше не нужен, можно через CTRL+F2 или кнопку «Стоп»:

В нашем случае неважно, какую кнопку нажимать (F9 или F8). Мы сразу переходим к следующей точке останова программы:

Ветка правильная, то есть логика программы верна, числа firstInt и secondInt не изменились. Зато мы сразу видим, что подпись некорректная! Вот в чём была ошибка. Исправим подпись и проверим программу ещё раз.

Мы уже починили два бага: падение приложения с помощью логов и некорректную логику (с помощью отладчика). Хеппи пас (happy path) пройден. То есть основная функциональность при корректных данных работает. Но нам надо проверить не только хеппи пас — пользователь может ввести что угодно. И программа может нормально работать в большинстве случаев, но вести себя странно в специфических состояниях. Давайте введём числа побольше и посмотрим, что будет:

Не сработало — программа хочет сказать, что 1000 не равна 1000, но это абсурд. Запускаем приложение в режиме отладки. Точка останова уже есть. Смотрим в отладчик:

Числа одинаковые, что могло пойти не так? Обращаем внимание на тип переменной — Integer. Так вот в чём проблема! Это не примитивный тип данных, а ссылочный. Ссылочные типы нельзя сравнивать через ==, потому что будут сравниваться ссылки объектов, а не они сами. Но для Integer в Java есть нюанс: Integer может кешироваться до 127, и если мы вводим по единице в оба поля числа до 127, то фактически сравниваем просто int. А если вводим больше, то получаем два разных объекта. Адреса у объектов не совпадают, а именно так Java сравнивает их.

Есть два решения проблемы:

1. Изменить тип Integer на примитив int.
2. Сравнивать как объекты.

Не рекомендуется менять тип этих полей в реальном приложении: числа могут приходить извне, и тип лучше оставлять прежним. Изменим то, как мы сравниваем числа:

Всё работает. Наконец-то! Хотя… Давайте посмотрим, что будет, если пользователь ничего не введёт, но нажмёт на кнопку? Приложение опять упало… Смотрим в логи:

Опять NumberFormatException, при этом строка пустая. Давайте поставим точку останова на 26-й строке и заглянем с помощью отладчика глубже.

Нажмём F8 — и перейдём в глубины операционной системы:

Интересно! Давайте обернём код в try/catch и посмотрим ошибке в лицо. Если что, поправим приложение. Выделяем код внутри метода onClick() и нажимаем Ctrl+Alt+T:

Выбираем try / catch, среда разработки сама допишет код. Поставим точку останова. Получим:

Запускаем приложение и ловим ошибку:

Действительно, как и в логах, — NumberFormatException. Метод parseInt выбрасывает исключение, если в него передать пустую строку. Как обрабатывать такую проблему — решать исключительно вам. Два самых простых способа:

1. Проверять получаемые строки first.getText().toString() и second.getText().toString() на пустые значения. И если хоть одно значение пустое — говорить об этом пользователю и не вызывать метод parseInt.
2. Или использовать уже готовую конструкцию try / catch:

Теперь-то точно всё в порядке! Хотя профессиональным тестировщикам это приложение никто не отдавал: поищете ещё ошибки? 🙂

Иногда в приложении встречаются ошибки, которые нельзя увидеть даже после запуска. Например, код компилируется, проект запускается, но результат далёк от желаемого: приложение падает или вдруг появляется какая-то ошибка (баг). В таких случаях приходится «запасаться логами», «брать в руки отладчик» и искать ошибки.

Часто процесс поиска и исправления бага состоит из трёх шагов:

1. Воспроизведение ошибки — вы понимаете, какие действия нужно сделать в приложении, чтобы повторить ошибку.
2. Поиск места ошибки — определяете класс и метод, в котором ошибка происходит.
3. Исправление ошибки.

Если приложение не падает и чтение логов ничего не даёт, то найти точное место ошибки в коде помогает дебаггер (отладчик) — инструмент среды разработки.

Чтобы посмотреть на логи и воспользоваться дебаггером, давайте напишем простое тестовое (и заведомо неправильное) приложение, которое даст нам все возможности для поиска ошибок.

Это будет приложение, которое сравнивает два числа. Если числа равны, то будет выводиться результат «Равно», и наоборот. Начнём с простых шагов:

1. Открываем Android Studio.
2. Создаём проект с шаблоном Empty Activity.
3. Выбираем язык Java, так как его, как правило, знают больше людей, чем Kotlin.

Нам автоматически откроются две вкладки: activity_main.xml и MainActivity.java. Сначала нарисуем макет: просто замените всё, что есть в activity_main.xml, на код ниже:

Можете запустить проект и посмотреть, что получилось:

Теперь оживим наше приложение. Скопируйте в MainActivity этот код:

В этом коде всё просто:

1. Находим поля ввода, поле с текстом и кнопку.
2. Вешаем на кнопку слушатель нажатий.
3. По нажатию на кнопку получаем числа из полей ввода и сравниваем их.
4. В зависимости от результата выводим «Равно» или «Не равно».

Запустим приложение и введём буквы вместо чисел:

Нажмём на кнопку, и приложение упадёт! Время читать логи. Открываем внизу слева вкладку «6: Logcat» и видим:

Читать логи просто: нужно найти красный текст и прочитать сообщение системы. В нашем случае это java.lang.NumberFormatException: For input string: «f». Указан тип ошибки NumberFormatException, который говорит, что возникла какая-то проблема с форматированием числа. И дополнение: For input string: «f». Введено “f”. Уже можно догадаться, что программа ждёт число, а мы передаём ей символ. Далее в красном тексте видно и ссылку на проблемную строку: at com.example.appdebugging.MainActivity$1.onClick(MainActivity.java:26). Проблема в методе onClick класса MainActivity, строка 24. Можно просто кликнуть по ссылке и перейти на указанную строку:

Конечно, метод parseInt может принимать только числовые значения, но никак не буквенные! Даже в его описании это сказано — и мы можем увидеть, какой тип ошибки этот метод выбрасывает (NumberFormatException).

Здесь мы привели один из примеров. Типов ошибок может быть огромное количество, все мы рассматривать не будем. Но все ошибки в Logcat’е указываются по похожему принципу:

• красный текст;
• тип ошибки — в нашем случае это NumberFormatException;
• пояснение — у нас это For input string: «f»;
• ссылка на строку, на которой произошла ошибка — здесь видим MainActivity.java:26.

Исправим эту ошибку и обезопасим себя от некорректного ввода. Добавим в наши поля ввода android:inputType=»number», а остальной код оставим без изменений:

Теперь можем вводить только числа. Проверим, как работает равенство: введём одинаковые числа в оба поля. Всё в порядке:

На равенство проверили. Введём разные числа:

Тоже равно. То есть приложение работает, ничего не падает, но результат не совсем тот, который требуется. Наверняка вы и без дебаггинга догадались, в чём ошибка, потому что приложение очень простое, всего несколько строк кода. Но такие же проблемы возникают в приложениях и на миллион строк. Поэтому пройдём по уже известным нам этапам дебаггинга:

1. Воспроизведём ошибку: да, ошибка воспроизводится стабильно с любыми двумя разными числами.
2. Подумаем, где может быть ошибка: наверняка там, где сравниваются числа. Туда и будем смотреть.
3. Исправим ошибку: сначала найдём её с помощью дебаггера, а когда поймём, в чём проблема, — будем исправлять.

И здесь на помощь приходит отладчик. Для начала поставим точки останова сразу в трёх местах:

Чтобы поставить или снять точку останова, достаточно кликнуть левой кнопкой мыши справа от номера строки или поставить курсор на нужную строку, а затем нажать CTRL+F8. Почему мы хотим остановить программу именно там? Чтобы посмотреть, правильные ли числа сравниваются, а затем определить, в какую ветку в нашем ветвлении заходит программа дальше. Запускаем программу с помощью сочетания клавиш SHIFT+F9 или нажимаем на кнопку с жучком:

Появится дополнительное окно, в котором нужно выбрать ваш девайс и приложение:

Вы в режиме дебага. Обратите внимание на две вещи:

1. Точки останова теперь помечены галочками. Это значит, что вы находитесь на экране, где стоят эти точки, и что дебаггер готов к работе.
2. Открылось окно дебага внизу: вкладка «5: Debug». В нём будет отображаться необходимая вам информация.

Введём неравные числа и нажмём кнопку «РАВНО?». Программа остановилась на первой точке:

1. Сразу подсвечивается синим строка, где программа остановлена: в окне кода на 28-й строке и в левом окне отладчика (там даже можно увидеть, какой метод вызван, — onClick).
2. В правом, основном окне отладчика, всё гораздо интереснее. Здесь можно увидеть инстансы наших вью (answer, first, second), в конце которых серым текстом даже отображаются их id. Но интереснее всего посмотреть на firstInt и secondInt. Там записаны значения, которые мы сейчас будем сравнивать.

Как видим, значения именно такие, какие мы и ввели. Значит, проблема не в получении чисел из полей. Давайте двигаться дальше — нам нужно посмотреть, в правильную ли ветку мы заходим. Для этого можно нажать F8 (перейти на следующую строку выполнения кода). А если следующая точка останова далеко или в другом классе, можно нажать F9 — программа просто возобновит работу и остановится на следующей точке. В интерфейсе эти кнопки находятся здесь:

Остановить дебаггер, если он больше не нужен, можно через CTRL+F2 или кнопку «Стоп»:

В нашем случае неважно, какую кнопку нажимать (F9 или F8). Мы сразу переходим к следующей точке останова программы:

Ветка правильная, то есть логика программы верна, числа firstInt и secondInt не изменились. Зато мы сразу видим, что подпись некорректная! Вот в чём была ошибка. Исправим подпись и проверим программу ещё раз.

Мы уже починили два бага: падение приложения с помощью логов и некорректную логику (с помощью отладчика). Хеппи пас (happy path) пройден. То есть основная функциональность при корректных данных работает. Но нам надо проверить не только хеппи пас — пользователь может ввести что угодно. И программа может нормально работать в большинстве случаев, но вести себя странно в специфических состояниях. Давайте введём числа побольше и посмотрим, что будет:

Не сработало — программа хочет сказать, что 1000 не равна 1000, но это абсурд. Запускаем приложение в режиме отладки. Точка останова уже есть. Смотрим в отладчик:

Числа одинаковые, что могло пойти не так? Обращаем внимание на тип переменной — Integer. Так вот в чём проблема! Это не примитивный тип данных, а ссылочный. Ссылочные типы нельзя сравнивать через ==, потому что будут сравниваться ссылки объектов, а не они сами. Но для Integer в Java есть нюанс: Integer может кешироваться до 127, и если мы вводим по единице в оба поля числа до 127, то фактически сравниваем просто int. А если вводим больше, то получаем два разных объекта. Адреса у объектов не совпадают, а именно так Java сравнивает их.

Есть два решения проблемы:

1. Изменить тип Integer на примитив int.
2. Сравнивать как объекты.

Не рекомендуется менять тип этих полей в реальном приложении: числа могут приходить извне, и тип лучше оставлять прежним. Изменим то, как мы сравниваем числа:

Всё работает. Наконец-то! Хотя… Давайте посмотрим, что будет, если пользователь ничего не введёт, но нажмёт на кнопку? Приложение опять упало… Смотрим в логи:

Опять NumberFormatException, при этом строка пустая. Давайте поставим точку останова на 26-й строке и заглянем с помощью отладчика глубже.

Нажмём F8 — и перейдём в глубины операционной системы:

Интересно! Давайте обернём код в try/catch и посмотрим ошибке в лицо. Если что, поправим приложение. Выделяем код внутри метода onClick() и нажимаем Ctrl+Alt+T:

Выбираем try / catch, среда разработки сама допишет код. Поставим точку останова. Получим:

Запускаем приложение и ловим ошибку:

Действительно, как и в логах, — NumberFormatException. Метод parseInt выбрасывает исключение, если в него передать пустую строку. Как обрабатывать такую проблему — решать исключительно вам. Два самых простых способа:

1. Проверять получаемые строки first.getText().toString() и second.getText().toString() на пустые значения. И если хоть одно значение пустое — говорить об этом пользователю и не вызывать метод parseInt.
2. Или использовать уже готовую конструкцию try / catch:

Теперь-то точно всё в порядке! Хотя профессиональным тестировщикам это приложение никто не отдавал: поищете ещё ошибки? 🙂

Источник