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

“Не прошло и года!” – скажут те, кто был на предыдущей встрече Rambler.Android, но такая ирония будет не очень уместна, ведь год все же прошел, и наша компания возобновляет проведение открытых митапов Android-разработчиков, интервалы между которыми в дальнейшем будут ощутимо короче.

За это время многое произошло, как внутри Rambler&Co, так и во всем мире мобильной разработки. И наша команда получила бесценный опыт, которым желает поделиться со всеми неравнодушными к созданию быстрых и красивых Android-приложений.

О чем же мы хотим поговорить?

Update: После 18:30 на страничке нашей мансарды будет доступна прямая трансляция митапа.

Добрый день! Наша команда уже больше года занимается разработкой почтового клиента МойОфис для платформы Android (приложения МойОфис мы разрабатываем для всех популярных платформ).

Сегодня мы хотим рассказать о технологиях, которые мы используем в разработке нашего почтового клиента. А именно, о механизмах Dependency Injection в виде библиотеки Dagger 2. В статье мы опишем основные части библиотеки и расскажем, как их использовать в Android-проекте.

В Edison мы часто сталкиваемся с оптимизацией мобильных приложений и хотим поделиться материалом, который считаем крайне полезным, если вы решаете одну из двух задач: а) хотите чтобы приложение меньше тормозило; б) хотите сделать красивый, мягкий и гладкий интерфейс для массового пользователя.

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

(Читать первую часть)

Часто при разработке клиента мы сталкиваемся с задачей отображения какой-либо информации с сервера, базы данных или еще чего-нибудь в виде списка. И при прокручивании списка данные должны автоматически подгружаться и вставляться в список незаметно для пользователя. У пользователя вообще должно сложиться впечатление, что он скроллит бесконечный список.

В данной статье я бы хотел рассказать вам о том, как сделать автоподгружаемый список простейшим в реализации для разработчика и максимально эффективным и быстрым для пользователя. А также о том, как нам в этом здорово поможет RxJava с ее главной догмой — «Everything is Stream!»

Привет хабр!

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

Вместо пролога

Я, пожалуй, нарушу традицию всех подобных статей и не буду рассказывать, зачем нужен NDK. Если вы это читаете, значит вам он зачем-то понадобился. Но один из реальных кейсов использования мы, конечно же, рассмотрим.

Эта история началась с того, что на Google I/O 2015 была представлена поддержка нативной разработки прямо не выходя из студии, Android-студии. Естественно, Google, как всегда, наобещал и заставил ждать, пока они все это выкатят для обычных людей. И вот 9 июля это свершилось: на stable channel появился кусочек того пирога, который нам наобещали.

Вместо введения

Во многих практических задачах требуется выполнение различных фоновых действий, будь то проигрывание музыки, обмен данными с сервером или просто слежение за действиями пользователя дабы похитить у него реквизиты кредитных карт. Ну а если не получится, то по крайней мере завалить его целевой рекламой, используя полученные сведения. Как уже давным-давно все знают, в Android такие вещи оформляются в виде службы (Service).

Официальная документация гласит, что ОС Android останавливает службу только в случае нехватки памяти. Тем не менее, существует и другие случаи. Пользователь может сам остановить службу, используя предоставляемые ему средства меню Settings/Apps, там же он может сделать и полную остановку приложения. Но для этого ему надо напрягаться и, в общем-то осознавать свои действия и их последствия. К сожалению, для уничтожения службы у него есть и другие возможности, которыми он может пользоваться бессознательно. В частности, если в нашем приложении ранее была запущена хоть одна Activity, видимая в истории, то пользователь буквально одним движением пальца сможет вынести соответствующую задачу. Как ни парадоксально, попутно Android вышибет и весь процесс вместе со службой.

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

Когда разработка мобильных приложений в компании переходит на промышленные рельсы, неизменно всплывает вопрос об автоматической сборке. Continuous Integration — это то, что является неотъемлемой частью процесса. Итог этого процесса — сборки для тестирования на устройствах компании для OTA распространения заказчикам и удаленным тестировщикам.

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

Итак, эта статья о том, как реализовать копирование сертификатов и профилей для iOS сборок и свойств, и ключей для Android сборок на все слейвы дженкинса в рамках Continuous Integration. Такая автоматизация экономит время и помогает избежать ошибок. Статья будет интересна разработчикам мобильных приложений и тем, кто администрирует Jenkins.

Поехали!

Разрабатывая наш Мобильный Банк мы однажды столкнулись с такой проблемой.

А именно: при использовании библиотеки GSON для сериализации/десериализации в/из JSON на некоторых устройствах от HTC в рантайме мы получали креш. Причина такого поведения в том, что некоторые устройства от HTC имеют в своей прошивке свою версию GSON, которая более старая чем та которую использовали мы в своих проектах. А андроидовский java class loader при загрузке класса в память предпочитает «системную» версию, вместо версии в проекте.

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

Для решения проблемы необходимо переупаковать GSON (или любую другую библиотеку) с помощью утилиты JarJar. После переупаковки артефакт будет иметь новую структуру пакетов, которую необходимо использовать в директивах импорта в своем проекте. Для этого нужно подключить переупакованный jar к своему проекту вместо исходного.

Нам захотелось автоматизировать эту задачу и в итоге появился Gradle JarJar Plugin, доступный в Maven Central. Плагин позволяет указать jar-библиотеки и правила для переупаковки их с помощью JarJar.

17 октября был опубликован Android 5.0 SDK, который принес новые виджеты и материальный дизайн. Мы расширили библиотеки поддержки, чтобы вы могли использовать ваши последние разработки и на предыдущих версиях Android. Это изменения включают в себ крупное обновление для AppCompat, а так же библиотеки RecyclerView, CardView и Palette.

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

Всем привет! Меня зовут Андрей Комрачков, я Android-разработчик в компании Aviasales и сегодня хочу показать вам видеозапись своего доклада, который я подготовил для LearnDroid – бесплатной online-школы Android-разработчиков, запущенной 30 марта компаниями Google и e-Legion.



Тема доклада: Android Animation Framework.
Цель урока: дать общие представления о том, какие у разработчика есть инструменты и возможности, а также как их применять на практике.
Продолжительность: 32 минуты полезной информации, без регистрации и смс.

Привет, Хабрахабр! В прошлом году мы впервые предоставили разработчикам тестовую версию Android L и получили множество полезных отзывов, которые касались Material Design, а также новых платформ Android Auto, TV и Wear. Вчера на конференции Google I/O мы объявили о повторении нашего удачного опыта: встречайте тестовую версию Android M.



Разработчики остались довольны ранним доступом к новой версии Android в прошлом году: он позволил обновить и оптимизировать приложения для новой версии операционной системы, в которой было введено много нового (в том числе и полностью переосмыслен дизайн и гайдлайны по проектированию интерфейса). Мы хотим и дальше предоставлять разработчикам возможность качественно подготовиться к релизу новой версии ОС: как вы и просили, мы обеспечим более четкий график обновлений SDK и тестовой версии Android M.

Никому не нравятся креши с OutOfMemoryError

Работая над Square Register, мы рисуем подпись клиента используя битмап-кеш. Поскольку этот битмап размером с экран устройства, у нас было очень много OutOfMemory крешей во время создания его.



Мы пробовали несколько подходов ни один из которых не решил проблему:

• Использовали Bitmap.Config.ALPHA_8
• Ловили OutOfMemoryError, вызывали сборку мусора и пробовали снова (подглядели в GCUtils),
• Мы не рассматривали вариант с размещением битмапов вне кучи Java. К счастью Fresco еще не существовало,
  

    Относительно не так давно появилась замечательная библиотека Espresso для тестирования UI Android приложений. Её преимущества над аналогами обозревались не один раз. Если вкратце, то они заключаются в том, что это разработка Google для собственной ОС (ранее они сами использовали Robotium), а так же в лаконичности синтаксиса и скорости работы. Итак, мы решили идти в ногу со временем и использовать Espresso. Но нам мало тех плюсов, что уже есть, мы хотим BDD (http://en.wikipedia.org/wiki/Behavior-driven_development), мы хотим скриншотов и отчетов в json и html, мы хотим запускать это все на CI, в конце концов! Но обо всем по порядку. Я расскажу как подружить Cucumber (http://habrahabr.ru/post/62958/) и Espresso (http://habrahabr.ru/post/212425/) на небольшом примере. Всех, кто устал от Appium, кто хочет уйти от Robotium и тех, кому небезразлично тестирование Android, прошу под кат.

Введение

Первое, что я хочу сказать: статья не претендует на сильно глубокий уровень, скорее я хочу рассказать о том, что производительность это не только «быстрее с NDK на С++» и «экономьте память, а то сборка мусора будет часто запускаться», а это целый комплекс мер, потому что проблемы с производительностью возникают не когда одна функция медленно работает, а в комплексе.
Не было ли у вас ощущения, что приложение тормозит, а вы уже не знаете что делать — и память вроде не жрет, и профайлером уже посмотрели, а решения все нет. Если да, то эти заметки для вас.
Понятия и термины я переводить не буду, так как я думаю что почти все разработчики их не переводят.

Back-end не всегда функционирует так идеально, как указано в API-спецификации. Например, кто-нибудь забывает внести обязательный параметр в JSON-строку выдачи или вместо «0» решает вписать null. Если такие данные проникают в мобильное приложение, последствия могут быть самые неприятные.
Сегодня я расскажу об инструменте, который используется для выявления таких случаев. Это Runscope.

“Это унылое диалоговое окно действительно нужно?”

В этой статье я изложил главные принципы Material Design и дал советы по их воплощению. Текст написан по следам мастер-класса для разработчиков, который мы, Роботы, устраивали совместно с российским офисом Google (Think Mobile).


Когда-то все продукты Google выглядели по-разному плохо. Даже один продукт на разных платформах выглядел неконсистентно.

Все стало меняться в 2011 году, когда в Google начали усиленно работать над унификацией визуальной части экосистемы своих продуктов и назвали все это Project Kennedy.

Если вам в проекте необходимо загружать картинки и/или отправлять http-запросы, выполнять любую другую долгую операцию, которая может заблокировать UI поток, то как ни крути придется использовать решение для выполнения асинхронных запросов.

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