Управление зависимостями – одна из наиболее важных функций в арсенале систем сборки. С приходом Gradle в качестве основной системы сборки Android-проектов в части управления зависимостями произошёл существенный сдвиг, закончилась эпоха ручного копирования JAR-файлов и долгих танцев с бубном вокруг сбоящих конфигураций проекта.



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

Когда собаке программисту нечего делать, он начинает все автоматизировать. Мне по роду своей деятельности приходится писать много кода и, конечно, хочется какие-то повторяющие вещи обобщить в виде библиотек, скриптов или шаблонов для Android Studio. О них и поговорим.

Привет, Хабр! Мы открываем набор на вторую стажировку для разработчиков в Redmadrobot. Старт — в середине января.

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

Для тестирования мобильных приложений, работающих с удаленными серверами, QA-инженеру приходится держать под рукой множество разных тестовых аккаунтов, логов, запросов и ответов. Реальность такова, что не всегда удается договориться о предоставлении нужных тестовых данных в срок. Чаще всего серверные разработчики будут незнакомыми вам людьми по ту сторону Скайпа. В таких ситуациях приходится своими руками подменять ответ сервера перед его передачей в приложение.

Чтобы редактировать выдачу сервера и воспроизводить сложные тестовые сценарии в QA Redmadrobot, мы используем Charles.

В мае мы писали, что открываем набор на стажировку для iOS и Android-разработчиков. Опыт был для нас необычный, новый и интересный.

Как все посвященные, конечно, знают, c 25 по 27 сентября в Москве проходило крупнейшее событие в мире Android-разработки — конференция DroidCon. Мы отметились и в числе спикеров, и как слушатели.

На WWDC 2015 инженеры компании Apple заявили, что пересмотрели подход к Deep Linking, в прошлом году компания Google анонсировала App Index — как новый взгляд на глубинные ссылки, в начале 2015 года в мире мобильной разработки заговорили о контекстных Deep Links. Что это за инструмент и как с ним работать применительно к iOS — расскажу в этой статье.

Что это?

Один из способов увеличения конверсии при продвижении IT-продукта — уменьшение барьеров для достижения пользователями искомой цели. В мобильной разработке эта проблема еще актуальней. При использовании e-mail, push или sms-рассылок с информацией о промо-акциях упрощение доступа к функционалу приложения просто необходимо. В такой ситуации просто запуск приложения из внешнего источника — не решение, ведь промо-акция — это конкретное спец.предложение в конкретном разделе. Чтобы после запуска приложения пользователю не пришлось по нему бродить, искать и раздражаться, нужен дополнительный инструмент, предопределяющий навигацию. И такой инструмент есть.
Deep Linking (глубинное связывание) — технология, благодаря которой пользователь может перемещаться между приложениями в заранее определенные разделы.

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

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

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

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

• Бизнес — всегда думает о достижении своих KPI, но редко понимает сложность разрабатываемой системы и удобство для пользователей.
• UX-проектировщик — всегда думает о пользователе, иногда в ущерб бизнесу. Не всегда явно понимает цель бизнеса и пытается навязывать свои идеи.
• Разработчик — думает, как сделать все классно с точки зрения архитектуры системы и программного кода. Пытается примерять пользовательские сценарии на себя, но является технически подкованным человеком, что не свойственно для большинства пользователей.

Если про передачу требований от уровня бизнеса к системному уровню сказано немало и выработался определенный инструментарий, то вот какие артефакты использовать для взаимодействия и передачи знаний между бизнесом, аналитиком и UX-проектированием — вопрос открытый. Этой темой я продолжаю цикл статей по бизнес-анализу в мобильной разработке.

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

• Бизнес — всегда думает о достижении своих KPI, но редко понимает сложность разрабатываемой системы и удобство для пользователей.
• UX-проектировщик — всегда думает о пользователе, иногда в ущерб бизнесу. Не всегда явно понимает цель бизнеса и пытается навязывать свои идеи.
• Разработчик — думает, как сделать все классно с точки зрения архитектуры системы и программного кода. Пытается примерять пользовательские сценарии на себя, но является технически подкованным человеком, что не свойственно для большинства пользователей.

Если про передачу требований от уровня бизнеса к системному уровню сказано немало и выработался определенный инструментарий, то вот какие артефакты использовать для взаимодействия и передачи знаний между бизнесом, аналитиком и UX-проектированием — вопрос открытый. Этой темой я продолжаю цикл статей по бизнес-анализу в мобильной разработке.

Где я нахожусь, куда мне идти, кажется я заблудился…

На следующий день после прилета в Нью-Йорк я договорился встретиться с другом в Центральном парке у Conservatory Garden Center Fountain. Огромный парк с бесконечными тропинками, лужайками, мостами, прудами, одна большая экосистема внутри мегаполиса из металла и стекла. Чтобы быстрее добраться до места, мне посоветовали поставить апп — официальное приложение Central Park.

Houston we have a problem

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

Привет, Хабр! Хочу рассказать вам о библиотеке Chronos для Android (API level >= 9), цель которой – облегчить написание долгих операций, например, сетевых запросов, или обращений к БД.

Какую проблему решаем?

Не секрет, что для Android задача выполнения асинхронных операций всегда была одной из самых частовстречающихся. Действительно, крайне мало приложений работают исключительно в оффлайн, и где можно обойтись без сетевого взаимодействия. И уж совсем крохотная их часть обходится без обращения к постоянной памяти устройства, будь то база данных, Preferences или обычный файл. Однако, на протяжении истории развития системы нам так и не было предложено ни одного достаточно удобного решения “из коробки”.

В некоторых коллективах рождается свой внутренний лексикон (особенно если люди собрались веселые, и отношения между коллегами складываются неформальные). Собственный сленг и внутренние мемы есть и у нас — делимся первой частью офисного словаря Роботов :)

Среди крупнейших конференций по Android-разработке в Европе особо можно отметить Droidcon в Берлине и в Лондоне. В столице Великобритании конференция в этом году еще только намечается, а на той, что недавно прошла в Германии, я уже побывал. Далее — небольшой отчет о том, что интересного удалось услышать и увидеть на берлинском Droidcon.

В Сан-Франциско продолжается главная конференция разработчиков под Apple-платформы: iOS, Mac OS X и новую watchOS 2. Неделя в самом разгаре, сессии в основном технические. Уже более-менее понятно, с чем нам придется иметь дело в ближайшие месяцы, адаптируя и совершенствуя свои приложения к релизу новых систем, так что спешу поделиться новостями с вами.

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



Материал будет интересен в первую очередь разработчикам под платформы iOS и Mac OS, но, возможно, здесь каждому что-то придется по душе.

Первая реакция на Keynote любой конференции — будь то Google I/O или WWDC — «все было ожидаемо, ничего революционного». Это часто можно услышать как от разработчиков, так и от людей, вообще мало понимающих в технологиях и требующих продуктов, которые немедленно произведут на них впечатление. Вчера в ходе keynote мы увидели несколько анонсов, которые зададут тон развитию продуктов Apple на будущий год, но многие жалуются на отсутствие нового Apple TV, скучные фичи и прочие глупости.

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

Первой и основной проблемой, с которой мы столкнулись при разработке приложения под Apple Watch, было отсутствие тестовых устройств. Значительная часть заморочек, о которых пойдет речь в этой статье, напрямую связана с этим фактом. Ну а потом мы дорвались до часов и снова плясали с бубнами, чтобы приложение корректно заработало, да и просто попало в стор.

Идея, дизайн и начало разработки

Разбираться с Apple Watch мы начали в ноябре 2014 года, как только появился в доступе WatchKit SDK. Досконально изучили гайдлайны и всю информацию, которая была доступна в сети. На момент непосредственного старта разработки приложения «Мой Билайн» под Apple Watch у нас уже был сложившийся набор идей и четкое понимание того, что мы хотим получить на выходе. На этом проекте не проводилось потребительских исследований, но на помощь пришел собственный пользовательский опыт с wearables — многие сотрудники Redmadrobot давно пользовались Pebble, и мы нарисовали под эти часы не один прототип, экспериментировали и с отрисовкой концептов под Android Wear. Для Apple Watch мы продумали пользовательские сценарии и то, как все это могло бы интегрироваться с основным iOS-приложением. Сценарий смапили на SDK «Билайна» и на SDK Apple Watch, после чего стало понятно, что делать нужно, а что не следует или нельзя реализовать в принципе.

Паттерн MVС появился достаточно давно и создавался с целью разделения бизнес-логики приложения от представления. Но далеко не все программисты реализуют его правильно, из-за чего возникают «Толстые тупые уродливые контроллеры» содержащие тонны кода. В этой статье пойдет речь о правильной реализации View классов, для того чтобы уменьшить количество кода в контроллерах и оставить место чистой бизнес-логике приложения.