Здравствуйте, я Android разработчик и я больше не боюсь ProGuard...

Обычно, об этой утилите вспоминают, когда сталкиваются с dalvik dex-limit issue или с требованием улучшить безопасность приложения. К сожалению, правильно настроить Proguard удается далеко не с первого раза. Я часто наблюдал, как многие, сломав проект, выключают Proguard и включают поддержку Mulditex и каждый раз немножечко грустил по этому поводу, ведь Proguard помогает как сократить размер приложения, так и повысить его производительность.

В итоге, я решил написать статью, в которую смогу поместить всю полезную информацию, которую я узнал за несколько лет работы с Proguard и которая могла бы помочь как совсем новичкам, так и тем, кто уже что-то знает.

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

Привет, Хаброжители! У нас вышло 3-е издание книги Пола и Харви Дейтл, Александера Уолда:

Предлагаем подробно ознакомится с разработкой приложений для смартфонов и планшетов Android с использованием Android Software Development Kit (SDK). Многие навыки программирования для Android, представленные в книге, также применимы к разработке приложений для Android Wear и Android TV.

В книге представлены передовые технологии разработки мобильных приложений для профессиональных программистов. В основу книги заложен принцип разработки, ориентированной на приложения, — концепции разработки продемонстрированы на примере полностью работоспособных приложений Android, а не фрагментов кода. Каждая из глав 2–9 начинается с вводной части, в которой вкратце описано разрабатываемое приложение. Затем приводятся результаты тестирования приложения и обзор технологий, применяемых в процессе его разработки. Далее выполняется подробный анализ исходного кода приложения.

От переводчика: Некоторые термины, которые использует автор, не имеют общепринятого перевода (ну, или я его не знаю:), поэтому я решил оставить большинство на языке оригинала — они всё равно понятны и для тех, кто пишет под android, но не знает английский.
Куда писать об ошибках и неточностях, вы знаете.

За последние несколько месяцев, а также после дискуссий на Tuenti с коллегами вроде @pedro_g_s и @flipper83 (кстати говоря, 2 крутых Android-разработчика), я решил, что имеет смысл написать заметку о проектировании Android-приложений.

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

В статье «Moxy — реализация MVP под Android с щепоткой магии» мы рассказывали, как побороть проблему жизненного цикла и разделить код своего Android-проекта на слои. Однако MVP (даже при умной кодогенерации view state в Moxy) заставляет писать огромное количество лишнего кода (создавать связанные друг с другом классы и интерфейсы presenter и view). На самом деле эту работу за вас должен делать робот! :) Настало время еще сильнее уменьшить boilerplate при помощи кастомизации шаблонов Android Studio под Moxy.

Привет, Хабр! Настало время, когда можно сказать, что «new build system» Gradle является стандартом отрасли Android-разработки. Инструмент сделан настолько просто и удобно, что большинство разработчиков не испытает трудностей, даже не зная, как он устроен, и какие дополнительные возможности в нём есть — возникающие проблемы легко решаются с помощью 5 минут на StackOverflow, путем копирования «магического кода» в конфигурационные файлы. Возможно, в том числе из-за этого не все разработчики изучают Gradle детально и не знают о многих его полезных возможностях, которые существенно облегчают жизнь.

1. Вступление

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

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

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

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

Говоря о базовых знаниях, надо отметить, что умение писать красивый профессиональный код — это то, что по тем или иным причинам, в эти базовые знания категорически не входит. Вместо этого, в соответствующих заведениях, а также в книжках, нам рассказывают про алгоритмы, языки, принципы ООП, паттерны дизайна…

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!

В мире Android разработки существует множество интересных библиотек, и сегодня мы рассмотрим детище компании Square — Retrofit. Что же это за зверь такой? Retrofit (согласно официальному сайту) — типобезопасный HTTP-клиент для Android и Java. Он является незаменимым инструментом для работы с API в клиент-серверных приложениях. Каких-то лет 5 назад Android-разработчикам для работы с сетью приходилось воротить горы кода с обратными вызовами, AsyncTask'ами и прочими «низкоуровневыми» вещами. И компания Square выпустила такую замечательную библиотеку — Retrofit.

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

Часто думают, что программирование — есть что-то сложное и недетское. Однако это, в принципе, играючи опровергает большое количество коммерческих компаний — от Apple (Swift Playground) и до Tynker, ориентированных на ребят от 5 лет. Ну или возьмем тот же Code.org — здесь вы можете найти курсы для детей 4+.

Но это все — про дополнительное образование. А что же происходит в это время в школах? Обучением детей начальной и средней школы программированию мы в нашей компании занимаемся уже почти 2 года и за это время прошли множество трансформаций и перечитали большое количество талмудов. И теперь хотим поделиться основными сделанными выводами…

В данной статье я хотел бы вкратце рассказать про самые последние best practices от Google. Я постарался выделить самые основные моменты, чтобы читатель сразу мог понять, что именно какая-либо фича дает разработчику. Не удивляйтесь, если где-то повторяюсь. Конспектировал + добавлял от себя по ходу просмотров видео в www.youtube.com/channel/UCVHFbqXqoYvEWM1Ddxl0QDg

Также к каждому пункту приводятся все необходимые ссылки для более подробного ознакомления с конкретной best practice.

Я ясно помню тот день в далеком 2014 году, когда я решил заняться программирование под Android. Это оказалось лучшим решением, которое я принял в моей жизни. Уже прошло почти два с половиной года, и за это время у меня возможность кое-чему научиться.

Когда я только начал, я не знал никого, кто мог бы научить меня, показать, как правильно нужно делать. И я совершил МНОЖЕСТВО ошибок, в так же потратил кучу времени на то, чтобы потом их исправить.

Полтора года спустя, мне выпал шанс поработать с очень талантливыми и опытными Android-разработчиками, которые направляли меня и помогли мне привести все в порядок. Эти две составляющие научили меня многому. Я понял, что надо ДЕЛАТЬ, а самое главное, что НЕ НАДО.

И уже какое-то время я, как могу, стараюсь помогать другим разработчикам — прямо или косвенно. Вот мои профили: StackOverflow и Github.

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

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

Привет! Я Катя, и я – трудоголик тестировщик самого популярного приложения для новых знакомств.

Итак, раннее утро, вы – мобильный QA. Вы приходите на работу, завариваете крепкий кофе и хотите взять пару мобильных устройств для тестирования новой фичи, осознавая, какие муки выбора вам предстоят. Что это будут за устройства?

Рано или поздно каждый мобильный тестировщик задаётся вопросом, на каком количестве устройств тестировать новый функционал, чтобы поймать максимальное количество девайсозависимых багов, потратив минимум времени. Автотесты ещё не написаны, перед вами абсолютно новые фичи. И если с iOS есть хоть какая-то ясность, и список устройств ограничен, то Android «расплодился» в полнейший ад. Вы удивитесь, но для счастья нужно всего три–четыре Android-устройства. Я хочу рассказать, как с точки зрения опытного тестировщика их выбрать.

Всем привет!

Не так давно мы с вами осознали, что мобильное приложение — это не просто тонкий клиент, а это действительно большое количество самой разной логики, которое нуждается в упорядочивании. Именно поэтому мы прониклись идеями Clean architecture, прочувствовали, что такое DI, научились использовать Dagger 2, и теперь с закрытыми глазами способны разбить любую фичу на слои.

Но мир не стоит на месте, и с решением старых проблем приходят новые. И имя этой новой проблемы — мономодульность. Обычно об этой проблеме узнаешь, когда время сборки улетает в космос. Именно так и начинаются многие доклады про переход на многомодульность (раз, два).
Но почему-то все при этом как-то забывают, что мономодульность сильно бьет не только по времени сборки, но и по вашей архитектуре. Вот ответьте на вопросы. На сколько у вас AppComponent большой? Не встречаете ли вы периодически в коде, что фича А зачем-то дергает репозиторий фичи Б, хотя вроде такого быть не должно, ну или оно должно быть как-то более верхнеуровнево? Вообще у фичи есть какой-то контракт? А как вы организовываете общение между фичами? Есть какие-то правила?
Вы чувствуете, что мы решили проблему со слоями, то есть вертикально все вроде хорошо, но вот горизонтально что-то идет не так? И просто разбиением на пакеты и контролем на ревью не решить проблему.

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

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