А нам тут недавно пользователь писал, что мы оказывается вирусы в своё приложение встраиваем :-) Ему так Сбербанк сказал! Пол-часа успокаивали… А что приложению Сбера в нашем не понравилось, понять так и не смогли.
Может не позволить, Вы правы. Есть ещё пара жёстких вариантов — можно стирать первый разделитель при постановке второго (я обычно при виде таких фокусов вспоминаю родственников этих проектировщиков UX вежливо ругаюсь :-D ) или сделать визуальную маску, чтобы знаки до разделителя и после вводились в разные поля.
На самом деле всё от модели использования зависит, конечно. У автора, насколько мне известно, это практически всегда короткие числа с одним-двумя знаками после запятой, а ввод с самодельной числовой клавиатуры — не надо ждать, пока ОС свою откроет/закроет.
Идеалогически мне Ваш вариант больше всего нравится, но в системах ввода «а-ля калькулятор» он пока не прижился.
это верно лишь в общем случае, но, к примеру, попробуйте в любом калькуляторе ввести второй разделитель. Да и у Google в гайдах есть примеры ввода чего угодно, только не дробных чисел :-)
В смысле, pull request им прислать? (issue по мотивам этой статьи им уже вкатили) :-D или написать «Best Practices» от MyCompany? :-)
На самом деле, вопрос был в некоторой степени риторический, конечно. Имелось в виду донести информацию, что есть не только Robotium.
А не устраивает их в Espresso с большой вероятностью то, что переходить на другой фреймворк тестирования — это убиться можно сколько работы, разве что в новых проектах начинать потихоньку.
Правда чтоли pull request отправить? :-) Один вон уже прислал перевод "to French" :-D
меня в этой статье больше всего смутил раздел «Фреймворки для тестирования»
чем ребят из Futurice не устраивает Espresso, входящий в официальный com.android.support, поддерживающий API начиная с Froyo, совместимый с Junit4 — мне совершенно непонятно :-|
живёт у нас в production уже пол-года и никаких проблем с тестированием UI не наблюдаем
не могу быть уверен, почему так написали авторы статьи, могу лишь озвучить своё мнение :-)
1. По нашим ощущениям, Gradle действительно функциональнее Maven и позволяет писать более компактный код. Я без проблем приведу примеры вещей, которые может Gradle и не может Maven, но не наоборот. Впрочем, статьи по этому поводу пишутся уже минимум лет 5
2. Aquery, конечно, можно :-)
3. По мнению авторов, Jackson более функционален, это явным образом написано в статье. Не могу уточнить, не использовали
4. Оценка глубины иерархии — вопрос хороший, и на Хабре обсуждался, насколько помню, но явно за рамками статьи для новичков. Это же относительно короткий набор советов, а не полноценная книга по Android-разработке :-)
5. Пусть меня поправят знатоки Eclipse, давненько не открывал, вроде под Maven там надо было ставить плагин. Android Studio же дружит с Gradle «из коробки», так что выражение автора имеет некоторый смысл
6. выражение «Always use ProGuard or DexGuard» мне тоже кажется чересчур сильным
это были конкретные примеры велосипедов, на мой взгляд, вполне удачные
по крайней мере не раз доводилось видеть (как правило, именно у начинающих разработчиков) объёмные реализации сетевых взаимодействий, по функциональности легко покрываемые тем же OkHttp, или, если брать шире, Retrofit
вполне хорош, доводилось использовать
но вряд ли автор мог перечислить все хорошие библиотеки для http-запросов, тут скорее акцент на том, чтобы начинающие разработчики не писали свои велосипеды, а посмотрели по сторонам
Volley и OkHttp — вполне себе решения, тоже живут у нас в production
Выражаю благодарность DmitryO за ссылку на эту интересную статью :-)
Все неточности перевода, непонятности и пожелания прошу писать в личку, ошибки будут оперативно исправлены.
Вообще, было сложно понять, какие термины нужно перевести, а какие оставить на английском. Я старался делать примерно так, как это принято в предыдущих статьях Хабра по Android, чтобы читателям было понятнее (мне самому не очень понятно, почему «фрагменты» обычно пишут на русском, а «activity» оставляют на английском). Заранее приношу свои извинения любителям русского языка за выражения типа «релизная сборка» и «обфускировать» — увы, это специализированный технический текст и альтернативы, как правило, были не лучше. А если оставлять все эти термины на английском, как мы обычно делаем в профессиональным диалогах с коллегами, тут пол-текста будет латиницей :-)
ну, лично у меня от фрагментов были примерно такие же ощущения, как от функционального анализа в универе :-)
то есть сначала не понимал, потом не понимал, а потом привык :-D
я как раз хотел английский попрактиковать :-) цель выглядит неплохо
а не многовато для одной статьи на Хабре?
в общем, если этот комментарий наберёт несколько плюсов, переведу на этой неделе :-)
Вы предлагаете по кнопке Back открывать предыдущий экран верхнего уровня Navigation Drawer? Это очень похоже на «анти-паттерн навигации в Android № 6». Гайдлайны Google это явным образом не рекомендуют (System Back at the top level of the app).
да, спасибо за уточнение :-)
анализ кода — очень важный момент, без количественных метрик оценки качества кода процесс разработки многое теряет
я поставил SonarQube (уж очень он мне понравился) и подсчёт code coverage (видимо, с помощью jacoco) в TODO list, но lint и findbugs быстрее и проще подключить
Ну, если серьёзно, идея интересная, только кому свои данные доверить? Некоторые вот уже собирали, могут начинать обрабатывать
вспоминаю родственников этих проектировщиков UXвежливо ругаюсь :-D ) или сделать визуальную маску, чтобы знаки до разделителя и после вводились в разные поля.На самом деле всё от модели использования зависит, конечно. У автора, насколько мне известно, это практически всегда короткие числа с одним-двумя знаками после запятой, а ввод с самодельной числовой клавиатуры — не надо ждать, пока ОС свою откроет/закроет.
Идеалогически мне Ваш вариант больше всего нравится, но в системах ввода «а-ля калькулятор» он пока не прижился.
На самом деле, вопрос был в некоторой степени риторический, конечно. Имелось в виду донести информацию, что есть не только Robotium.
А не устраивает их в Espresso с большой вероятностью то, что переходить на другой фреймворк тестирования — это убиться можно сколько работы, разве что в новых проектах начинать потихоньку.
Правда чтоли pull request отправить? :-) Один вон уже прислал перевод "to French" :-D
чем ребят из Futurice не устраивает Espresso, входящий в официальный com.android.support, поддерживающий API начиная с Froyo, совместимый с Junit4 — мне совершенно непонятно :-|
живёт у нас в production уже пол-года и никаких проблем с тестированием UI не наблюдаем
1. По нашим ощущениям, Gradle действительно функциональнее Maven и позволяет писать более компактный код. Я без проблем приведу примеры вещей, которые может Gradle и не может Maven, но не наоборот. Впрочем, статьи по этому поводу пишутся уже минимум лет 5
2. Aquery, конечно, можно :-)
3. По мнению авторов, Jackson более функционален, это явным образом написано в статье. Не могу уточнить, не использовали
4. Оценка глубины иерархии — вопрос хороший, и на Хабре обсуждался, насколько помню, но явно за рамками статьи для новичков. Это же относительно короткий набор советов, а не полноценная книга по Android-разработке :-)
5. Пусть меня поправят знатоки Eclipse, давненько не открывал, вроде под Maven там надо было ставить плагин. Android Studio же дружит с Gradle «из коробки», так что выражение автора имеет некоторый смысл
6. выражение «Always use ProGuard or DexGuard» мне тоже кажется чересчур сильным
по крайней мере не раз доводилось видеть (как правило, именно у начинающих разработчиков) объёмные реализации сетевых взаимодействий, по функциональности легко покрываемые тем же OkHttp, или, если брать шире, Retrofit
но вряд ли автор мог перечислить все хорошие библиотеки для http-запросов, тут скорее акцент на том, чтобы начинающие разработчики не писали свои велосипеды, а посмотрели по сторонам
Volley и OkHttp — вполне себе решения, тоже живут у нас в production
Все неточности перевода, непонятности и пожелания прошу писать в личку, ошибки будут оперативно исправлены.
Вообще, было сложно понять, какие термины нужно перевести, а какие оставить на английском. Я старался делать примерно так, как это принято в предыдущих статьях Хабра по Android, чтобы читателям было понятнее (мне самому не очень понятно, почему «фрагменты» обычно пишут на русском, а «activity» оставляют на английском). Заранее приношу свои извинения любителям русского языка за выражения типа «релизная сборка» и «обфускировать» — увы, это специализированный технический текст и альтернативы, как правило, были не лучше. А если оставлять все эти термины на английском, как мы обычно делаем в профессиональным диалогах с коллегами, тут пол-текста будет латиницей :-)
то есть сначала не понимал, потом не понимал, а потом привык :-D
хотя некоторые приятные вещи типа удобного backstack и дешёвых (по реализации) анимаций они дают
а не многовато для одной статьи на Хабре?
в общем, если этот комментарий наберёт несколько плюсов, переведу на этой неделе :-)
анализ кода — очень важный момент, без количественных метрик оценки качества кода процесс разработки многое теряет
я поставил SonarQube (уж очень он мне понравился) и подсчёт code coverage (видимо, с помощью jacoco) в TODO list, но lint и findbugs быстрее и проще подключить