Пожалуй одно единственное «но» по поводу хранения компоновки в стороннем приложении — она должна состоять исключительно из компонентов Android-фреймворка, которые разделяются между всеми приложениями. Если в компоновке определен кастомный виджет, кода которого нет в «клиентском» приложении, то компоновку просто не получиться надуть из xml.
Любой рекурсивный алгоритм можно переписать в нерекурсивном виде.
Это чаще всего делается для того чтобы избежать переполнения стека. Не хочу показаться занудой, но при приведенной Вами реализации Вы можете на него наткнуться из-за того, что в каждой итерации цикла выделяете память для двух целочисленных, хотя могли определить их вне цикла и при каждой итерации просто менять их значения
На Android, при удалении и повторной установке приложения на девайсе, Метрика идентифицирует это событие так, как будто очередной пользователь поставил себе приложение. Но это ведь гробит статистику о пользователях на корню…
Спасибо, конечно, что всем популярно объяснили, но я не думал, что добавление фаз тестирования произошло не так давно, судя по тому, что Вы только сейчас об этом пишете
Стоит учесть, что Google предупреждает о том, что время публикации приложения, вне зависимости от того в какой фазе Вы его публикуете, может занимать до 24 часов, хотя по опыту при малом охвате стран, версий и девайсов — не более часа.
И еще один интересный нюанс, связанный с наличием прав доступа у одного тестировщика и к альфе и к бете. Если и в альфе и в бете лежат разные версии приложения, такой тестер будет иметь доступ только к тому, что выложено в альфе.
Спасибо за то что поделились опытом. Но у меня есть несколько вопросов и уточнений, если что-то не учитываю или неправильно понимаю, поправляйте:
Весь доклад, по сути говорит о том, что при тестировании Вы занимаетесь покрытием только того, что касается графического интерфейса, делая скидку на то, что среди всего этого могут всплыть баги, ведущие к низкоуровневым проблемам.
Robotium — это фреймворк для тестирования черного ящика и то что Вы используйте только его для тестирования своих приложений, как я понял из доклада, обусловлено только тем, что в процессе разработки Вы сваливаете весь процесс тестирования на Ваших QA, которые не знают всех нюансов написанного кода, а в особенности того, что происходит внизу, и соответственно вынуждены работать с черным ящиком. Это очень спорный момент, по мне, так гораздо больше багов можно выявить если написанием тестов занимается помимо QA сам разработчик, который знает где и что в коде может всплыть. Компромиссный вариант — white box тестирование с использованием Robolectric за разработчиком, а затем black box тесты с помощью Robotium+Spoon от QA. Хотя тот же Square, который сделал Spoon вполне обходится им в связке с Robolectric.
И еще один момент — на приведенной диаграмме процесса разработки непонятно, где происходит процесс устранения багов, найденных в ходе тестирования.
На самом деле, на мой взгляд, здесь основной акцент делается не столько на факте остановки света, каким бы мнительным он не казался, сколько на факте обеспечения квантовой когерентности с помощью подобной модели световой памяти.
Это фигня! :) У нас в бизнес-центре можно устроить следующее западло: лифт едет по пяти этажам. Находясь на четвертом, вызываешь лифт, который едет наверх, заходишь в него и нажимаешь на первый этаж. Лифт доезжает до положенного пятого, на который его вызвали до тебя, останавливается, не открывает двери и едет вниз под звуки вербальной агрессии из уст людей, вызвавших его с первого этажа на пятый.
Мое личное ИМХО относительно абстрактных моделей Android Framework — скоро Gingerbread уйдет в небытие — и соответственно использование HttpClient от Apache уже медленно, но верно теряет смысл, HttpURLConnection выйдет на первый план. Кстати, вот ссылочки на неплохие обертки, работают как на Java так и на Android (здесь и здесь)
Меня больше интересует другой момент, как Вы производите отладку http-трафика? При использовании HttpClient спасал их Logger, а вот как Вы справляетесь при использовании HttpURLConnection? Я к сожалению не смог найти чего-либо более вменяемого, чем отладка трафика с эмулятора через Wireshark.
Это чаще всего делается для того чтобы избежать переполнения стека. Не хочу показаться занудой, но при приведенной Вами реализации Вы можете на него наткнуться из-за того, что в каждой итерации цикла выделяете память для двух целочисленных, хотя могли определить их вне цикла и при каждой итерации просто менять их значения
Создать заглушку для синглтона.
И еще один интересный нюанс, связанный с наличием прав доступа у одного тестировщика и к альфе и к бете. Если и в альфе и в бете лежат разные версии приложения, такой тестер будет иметь доступ только к тому, что выложено в альфе.
Весь доклад, по сути говорит о том, что при тестировании Вы занимаетесь покрытием только того, что касается графического интерфейса, делая скидку на то, что среди всего этого могут всплыть баги, ведущие к низкоуровневым проблемам.
Robotium — это фреймворк для тестирования черного ящика и то что Вы используйте только его для тестирования своих приложений, как я понял из доклада, обусловлено только тем, что в процессе разработки Вы сваливаете весь процесс тестирования на Ваших QA, которые не знают всех нюансов написанного кода, а в особенности того, что происходит внизу, и соответственно вынуждены работать с черным ящиком. Это очень спорный момент, по мне, так гораздо больше багов можно выявить если написанием тестов занимается помимо QA сам разработчик, который знает где и что в коде может всплыть. Компромиссный вариант — white box тестирование с использованием Robolectric за разработчиком, а затем black box тесты с помощью Robotium+Spoon от QA. Хотя тот же Square, который сделал Spoon вполне обходится им в связке с Robolectric.
И еще один момент — на приведенной диаграмме процесса разработки непонятно, где происходит процесс устранения багов, найденных в ходе тестирования.
Меня больше интересует другой момент, как Вы производите отладку http-трафика? При использовании HttpClient спасал их Logger, а вот как Вы справляетесь при использовании HttpURLConnection? Я к сожалению не смог найти чего-либо более вменяемого, чем отладка трафика с эмулятора через Wireshark.
0_0
Вы дату публикации на WP и на Guardian внимательно посмотрели?
Никто не знает, то что снизу — это злостный стеб? Или это альтернатива?