Comments 31
Кем принято? Зачем автору сотня личных сообщений с просьбой поставить кат, если достаточно одного комментария? Тем более что личку зачастую смотрят реже комментов, а за час-другой неплохую статью заминусуют насмерть.
Насчет описок не спорю — лучше писать в личку.
Вау-вау, палегче.
Мне почему-то всегда про замечания об ошибках то же самое пишут — пиши в личку, чётров грамма-наци, минусуют, сливают карму. А тут практически обратное. В чём секрет, Шерлок?
Выражаю благодарность DmitryO за ссылку на эту интересную статью :-)
Все неточности перевода, непонятности и пожелания прошу писать в личку, ошибки будут оперативно исправлены.
Вообще, было сложно понять, какие термины нужно перевести, а какие оставить на английском. Я старался делать примерно так, как это принято в предыдущих статьях Хабра по Android, чтобы читателям было понятнее (мне самому не очень понятно, почему «фрагменты» обычно пишут на русском, а «activity» оставляют на английском). Заранее приношу свои извинения любителям русского языка за выражения типа «релизная сборка» и «обфускировать» — увы, это специализированный технический текст и альтернативы, как правило, были не лучше. А если оставлять все эти термины на английском, как мы обычно делаем в профессиональным диалогах с коллегами, тут пол-текста будет латиницей :-)
Всегда пожалуйста )

Кстати, я там еще подкинул любопытного материала на перевод.
Используйте систему сборки Gradle и стандартную структуру проекта
Почему, например, не Maven?
Не пишите свой собственный HTTP-клиент, лучше используйте библиотеки Volley или OkHttp
А Aquery можно?
Используйте библиотеку Jackson для парсинга данных в формате JSON
Не GSON?
Не делайте слишком глубокую иерархию элементов ViewGroup
Слишком много это сколько? Стоило бы пруфы привести. Например этот от автора хорошей книги по Android.
Есть два распространённых варианта: старая Ant & Eclipse ADT структура проекта — либо новая Gradle & Android Studio.
Maven & Eclipse?
Всегда используйте ProGuard или DexGuard
Зачем? Ужимать код? Это мелочи по сравнению с ресурсами. Обфускации? Не всегда требуется. Я не говорю, что не надо использовать ProGuard, но не понимаю, почему автор так категорично навязывает его использование.
не могу быть уверен, почему так написали авторы статьи, могу лишь озвучить своё мнение :-)

1. По нашим ощущениям, Gradle действительно функциональнее Maven и позволяет писать более компактный код. Я без проблем приведу примеры вещей, которые может Gradle и не может Maven, но не наоборот. Впрочем, статьи по этому поводу пишутся уже минимум лет 5

2. Aquery, конечно, можно :-)

3. По мнению авторов, Jackson более функционален, это явным образом написано в статье. Не могу уточнить, не использовали

4. Оценка глубины иерархии — вопрос хороший, и на Хабре обсуждался, насколько помню, но явно за рамками статьи для новичков. Это же относительно короткий набор советов, а не полноценная книга по Android-разработке :-)

5. Пусть меня поправят знатоки Eclipse, давненько не открывал, вроде под Maven там надо было ставить плагин. Android Studio же дружит с Gradle «из коробки», так что выражение автора имеет некоторый смысл

6. выражение «Always use ProGuard or DexGuard» мне тоже кажется чересчур сильным
Если принять во внимание, что ваш проект в дальнейшем будут поддерживать другие Android разработчики, то Gradle предпочтительнее, чем что либо еще, т.к. в последнее время является чуть ли не стандартом для сборки Android приложений. Даже если вы лучше разбираетесь с Maven, заставлять это других делать не вижу смысла.

Возможно я не прав, но приложение, после обфускации с помощью ProGuard должно работать быстрее: названия методов становятся короче -> поиск по ним становится быстрее. Использовать DexGuard во всех подрят приложениях не вижу смысла.

А вообще, вы можете сделать Pull Request в оригинальную статью на github со своими комментариями;)
1. Потому что Gradle единственная официально поддерживаемая гуглом система сборки под андроид. Ну и с эстетической точки зрения gradle красивее.
2. Неа, Aquery нельзя. Он во всю поддерживает reflection что при включении proguard добавит неимоверное количество головной боли. Ну и сломать код гораздо проще, т.к. ошибки компиляции превращаются в ошибки исполнения. В статье неточность, там должно быть написано Volley И okhttp. OkHttp гарантирует что используется последняя реализация http движка, а volley оборачивает это и добавляет кеширование, мультиплексирование запросов и загрузку картинок в придачу. Правда volley гугл тоже забросил, так что можно посмотреть на альтернативы.
3. С глубокой иерархией две проблемы — во-первых, это приводит к StackOverflowExceptions на старых девайсах и во-вторых если используются RelativeRayout или любые другие двухпроходные layouts то это будет жутко тормозить.
4. Эклипс больше не поддерживается. Ну и по сравнению с AndroidStudio он убог.
5. Потому что рано или поздно но вы придете к проблеме 65k methods, а если решать ее Multidex-ом то получится тормозящее чудовище типа клиента фейсбука. Прогуард кроме выкидывания кода который вы не используете еще дает существенную оптимизацию потребления памяти и скорости выполнения.
вполне хорош, доводилось использовать
но вряд ли автор мог перечислить все хорошие библиотеки для http-запросов, тут скорее акцент на том, чтобы начинающие разработчики не писали свои велосипеды, а посмотрели по сторонам
Volley и OkHttp — вполне себе решения, тоже живут у нас в production
Почему тогда акцентирование именно на сетевом стеке? Ведь таким образом можно вообще всё обобщить: «Не пишите свои велосипеды, если есть уже готовые решения».
это были конкретные примеры велосипедов, на мой взгляд, вполне удачные
по крайней мере не раз доводилось видеть (как правило, именно у начинающих разработчиков) объёмные реализации сетевых взаимодействий, по функциональности легко покрываемые тем же OkHttp, или, если брать шире, Retrofit
Потому что эта статья — перевод списка советов, полученных исходя из опыта работы вполне конкретной команды.
Вполне очевидно, что кто-то более чем успешно пользуется другими инструментами и библиотеками.
Не стоит злоупотреблять API уровня Android, например, слепо полагаясь на механизм Intent для внутренней работы приложения. Вы можете повлиять на операционную систему Android или другие приложения, вызвав ошибки или зависания. Например, известно, что если ваше приложение использует механизм Intent для внутренней коммуникации между пакетами приложения, вы можете вызвать зависание в несколько секунд, если приложение было открыто сразу после загрузки операционной системы.
Не понял, что это значит. Объясните подробнее, плз.
Возможно речь идет о некоторых ограничениях метода. Например, если вы положите в Intent список из миллиона строк, то вероятнее всего, принимающая сторона «не заведется». Если это будет Activity, то вы не увидите даже запуска метода onCreate(), как и хоть какого-нибудь сообщения в лог – такую ошибку становится непросто поймать.
Или, если вы напишете свой Parcelable, который будет не просто раскладываться в POJO, а лезть, например, в кеш, то десериализация такого объекта в неродном процессе также, скорее всего, ни к чему хорошему не приведет.
кода пользователь поймает баг и пришлёт вам обфускированный лог ошибок.

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

Подводные камни: Genymotion не позволяет использовать в приложении такие сервисы Google, как Google Play Store или Maps.

Это только если не научить его их использовать. :)
Я бы еще добавил, что нужно смотреть на правильную организацию потоков и передачу данных между ними. Для этого можно взять широкоизвестный Robospice, или недавно представленный нами Chronos. Очень часто ведь люди пишут все на AsyncTask'ах, когда 2015 год на дворе, а потом приложение неадекватно себя ведет, стоит только несколько раз повернуть экран.
Помните о ограничении dex-файла на количество методов, и избегайте использования большого количества библиотек. Приложения Android, при упаковке в dex-файл, имеют жёсткое ограничение в 65536 ссылочных методов

Ну если не получается уложиться, то можно использовать multidex.
developer.android.com/tools/building/multidex.html
К сожалению выйти за 65к очень просто даже в средненьком проекте,
достаточно подключить для авторизации Facebook SDK и получить кучу не нужного кода.
меня в этой статье больше всего смутил раздел «Фреймворки для тестирования»
чем ребят из Futurice не устраивает Espresso, входящий в официальный com.android.support, поддерживающий API начиная с Froyo, совместимый с Junit4 — мне совершенно непонятно :-|
живёт у нас в production уже пол-года и никаких проблем с тестированием UI не наблюдаем
Так ребята ж делятся своим опытом. Есть дисклеймер. Вот если бы вы поделились опытом своей команды, там бы стоял Espresso.
В смысле, pull request им прислать? (issue по мотивам этой статьи им уже вкатили) :-D или написать «Best Practices» от MyCompany? :-)
На самом деле, вопрос был в некоторой степени риторический, конечно. Имелось в виду донести информацию, что есть не только Robotium.
А не устраивает их в Espresso с большой вероятностью то, что переходить на другой фреймворк тестирования — это убиться можно сколько работы, разве что в новых проектах начинать потихоньку.

Правда чтоли pull request отправить? :-) Один вон уже прислал перевод "to French" :-D
Смысла особого не вижу в pull request. Они же вполне однозначно написали, что делятся своим личным опытом. И если Futurice не использует Espresso, то зачем им его упоминать?
...[DexGuard] Он может легко разделить Dex-файл на несколько для обхода ограничения в 65k методов...

MultiDexApplication отлично справляется.
Only those users with full accounts are able to leave comments. Log in, please.