Привет, Хабр! Сегодня у нас в программе кое-что особенное. Новые версии ПО важны для пользователей: они предоставляют доступ к новым возможностям на их устройствах. Но ещё важнее получить своевременный доступ к новому ПО для разработчиков. Использовать новейшие инструменты, API, проверить приложение на совместимость, одним из первых внедрить самые свежие и крутые наработки… В общем, мы рады представить вам тестовую версию Android N для разработчиков!



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

Всем привет! В последнее время появилось много средств, библиотек, которые существенно облегчают написание кода под Android. Только успевай за всем следить и все пробовать. Одним из таких средств является библиотека Dagger 2.

В сети уже много различного материала, посвященного данной библиотеке. Но когда я только начинал ознакамливаться с Dagger 2, читал статьи, смотрел доклады, я во всем этом находил один общий недостаток — мне, как человеку, не работавшему со Springом и прочими подобными фреймворками/библиотеками, было довольно сложно понять, откуда берутся зависимости, как они "провайдятся" и что вообще там происходит. На слушателей/читателей обычно сразу "вываливается" большое количество кода с новыми аннотациями. И это как-то работало. В итоге, после доклада/статьи в голове все никак не могло сложиться в единую понятную картину.

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

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

В этой статье мы рассмотрим три самых важных изменения в новом Android, которые не могут быть проигнорированы ни одним разработчиком, который поставил у себя в проекте targetSdk = 23 и выше.
Doze Mode — режим «отключки», в который переходят все устройства на Marshmallow после некоторого времени обездвижения без зарядки.

App Standby — автоматическое лишение приложений доступа к ресурсам устройства, всех которые давно не открывал пользователь.

Runtime Permissions — новая модель запроса разрешений. Теперь мы, как разработчики, каждый раз обращаясь, например, к микрофону устройства, должны проверять, есть ли у нашего приложения разрешение на доступ к нему.

Часто при установке приложения на Android нам приходилось видеть, что оно запрашивает какое-то немыслимое количество разрешений. Например:



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

Некоторые разработчики, чтобы уменьшить недоверие, добавляют в описание приложения на Google Play информацию о том, зачем нужно то или иное разрешение.

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

От переводчика: — я давненько интересуюсь тем, как сделать код Android-приложений чище, и это, наверное, первая статья, после которой у меня не возникло мыслей: "Зачем вот это вот все?" и "Он вообще пробовал когда-то это использовать в жизни?" Поэтому решил перевести, может, еще кому-то будет полезно.

Написать Hello World всегда легко. Код выглядит просто и прямолинейно, и кажется, что SDK очень адаптирована под ваши нужды. Но если у вас есть опыт написания более сложных Android-приложений, вы знаете, что с рабочим кодом все не так. Можно провести часы за попыткой понять, почему ваша корзина покупок не обновляется после изменения ориентации телефона, если недоступен WiFi. Вы предполагаете, что решением проблемы, возможно, будет добавить ещё один if в 457-строчном методе onCreate() вашей активити — где-то между тем кодом, который исправляет падение на самсунгах с Android 4.1 на борту, и тем, который показывает купон на 5$ в день рождения пользователя. Что ж, есть способ получше.

Мы в Remind (прим. пер. — название компании, где работает автор) выкатываем новые функции каждые две недели, и для того чтобы поддерживать эту скорость и высокое качество продукта, нужен способ сохранять код простым, поддерживаемым, разделённым (прим. пер. — "decoupled", в смысле слабой связанности) и тестируемым. Использование архитектурного паттерна MVP позволяет нам делать это и сосредоточиваться на самой значимой части нашего кода — нашей бизнес-логике.

Целью данной публикации не является полный анализ синхронизаторов из пакета java.util.concurrent. Пишу её, прежде всего, как справочник, который облегчит вхождение в тему и покажет возможности практического применения классов для синхронизации потоков (далее поток = thread).

В java.util.concurrent много различных классов, которые по функционалу можно поделить на группы: Concurrent Collections, Executors, Atomics и т.д. Одной из этих групп будет Synchronizers (синхронизаторы).



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

Предлагаю вашему вниманию перевод статьи Ian Lake Intercepting everything with CoordinatorLayout Behaviors.

Вы не продвинетесь далеко в изучении Android Design Support Library, не столкнувшись с CoordinatorLayout. Множество View из Design Library требуют CoordinatorLayout. Но почему? Сам по себе CoordinatorLayout делает не так уж и много, если использовать его с View, входящими в состав Android фреймворка, то он будет работать, как обычный FrameLayout. Так откуда берётся вся его магия? Вот где на сцену выходит CoordinatorLayout.Behavior. Подключив Behavior к дочерней View у CoordinatorLayout, вы сможете перехватывать касания, оконные вставки (window insets), изменения размеров и макета (measurement и layout), а также вложенную прокрутку. Design Library широко использует Behavior чтобы добавить силу большинству функционалу, которую вы видите.

В первой части статьи мы разработали приложение для работы с github, состоящее из двух экранов, разделенное по слоям с применением паттерна MVP. Мы использовали RxJava для упрощения взаимодействия с сервером и две модели данных для разных слоев. Во второй части мы внедрим Dagger 2, напишем unit тесты, посмотрим на MockWebServer, JaCoCo и Robolectric.

Недавно я выступал на конференции Droidcon в Париже с докладом (оригинал на французском), в котором рассматривал проблемы, возникшие у нас в Square при работе с фрагментами и возможности полного отказа от фрагментов.

В 2011-м мы решили использовать фрагменты по следующим причинам:

• Тогда мы ещё не поддерживали планшеты, но знали, что когда-нибудь будем. Фрагменты помогают создавать адаптивный пользовательский интерфейс, и потому казались хорошим выбором.
• Фрагменты являются контроллерами представлений, они содержат куски бизнес-логики, которые могут быть протестированы.
• API фрагментов предоставляет возможность работы с backstack'ом (в общих чертах это выглядит так же, как и работа со стэком Activity, но при этом вы остаётесь в рамках одной Activity).
• Так как фрагменты построены на обычных представлениях (views), а представления могут быть анимированы средствами Android-фреймворка, то фрагменты могли в теории дать нам возможность использовать более интересные переходы между экранами.
• Google рекомендовал фрагменты к использованию, а мы хотели сделать наш код как можно более стандартным.

С 2011-го года много воды утекло, и мы нашли варианты получше.

Что такое MVP

MVP – это способ разделения ответственности в коде приложения. Model предоставляет данные для Presenter. View выполняет две функции: реагирует на команды от пользователя(или от элементов UI), передавая эти события в Presenter и изменяет gui по требованию Presenter. Presenter выступает как связующее звено между View и Model. Presenter получает события из View, обрабатывает их(используя или не используя Model), и командует View о том, как она должна себя изменить.

У такого подхода к разделению ответственности есть ряд плюсов:

1. Сильно упрощается написание тестов к коду
2. Легко менять какую-то часть, не ломая при этом другую
3. Код разбивается на мелкие кусочки, за счёт чего он становится более понятным и читабельным

В то же время, конечно, есть и минусы:

1. Кода становится больше
2. К этому подходу нужно привыкать
3. На данный момент не сильно распространённый(но известный) подход, поэтому приходится всем рассказывать о нём

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

В этой статье мы поговорим о проектировании архитектуры и создании мобильного приложения на основе паттерна MVP с использованием RxJava и Retrofit. Тема получилась довольно большой, поэтому подаваться будет отдельными порциями: в первой мы проектируем и создаем приложение, во второй занимаемся DI с помощью Dagger 2 и пишем тесты unit тесты, в третьей дописываем интеграционные и функциональные тесты, а также размышляем о TDD в реалиях Android разработки.

Ура, свершилось! У платформы с открытыми онлайн-курсами Stepic.org появились приложения под iOS и Android.
В этом коротком посте мы расскажем о процессе работы над приложениями — выборе платформ, используемых технологиях и API, и даже дадим ссылки на исходный код.


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

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



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

В процессе создания новых приложений очень часто приходится писать однотипный код и воспроизводить уже проверенные временем структуры классов. IDE (в частности Android Studio) облегчает во многом задачи, связанные с созданием новых компонентов для приложения. Список шаблонных Aсtivity растет с каждой новой версией SDK Tools. Но что если нужно создать свой собственный шаблон? Для одного файла это легко, но что делать, если нужно создать шаблон с созданием нескольких файлов? Зная возможности IDE, это вполне реализуемо, ведь Activity создается вместе с файлом разметки, да и фрагмент к ней добавить можно. Однако описание такой функциональности найдено не было, потому пришлось искать решение для данной возможности самостоятельно.

Под катом хочу рассказать вам о том, как эта возможность реализуется в Android Studio.

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



Статья не претендует на глубину и/или академичность. Это попытка систематизировать опыт и обратить внимание разработчиков на не очень очевидные аспекты.

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

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

Треды, или цепочки писем в почте, — одна из фич, на которые у гиков и массовой аудитории полярные взгляды. Гики активно ими пользуются; обычные пользователи, как показывают наши опросы, относятся к ним скорее настороженно. Во-первых, непривычно, во-вторых, люди опасаются, что не смогут сориентироваться в цепочках. Когда мы реализовывали треды в веб-версии Почты Mail.Ru, мы помнили об этом челлендже — и нашли, как нам кажется, максимально удобный и интуитивно понятный алгоритм группировки, который будет удобен и гикам, и менее продвинутым юзерам. За основу в работе над мобильными тредами мы взяли систему, разработанную большой Почтой, так как мы не хотели запутать пользователей и делать разную логику. Наша задача с точки зрения продукта заключалась в том, чтобы и веб-треды, и мобильные треды работали для пользователя одинаково. Но многие вещи пришлось переделывать с учетом офлайн-работы. О том, как мы сделали в Android-приложении Почты Mail.Ru цепочки, где письма не теряются даже при сбоях в сети, я расскажу в этой статье (о том, как сделали то же самое в iOS-приложении, расскажем в одном из следующих постов).

Привет, Хабрахабр! Не так давно мы подводили итоги конкурса по Material Design, и в комментариях нас просили показать реально популярные и красивые Material-приложения. Что же, встречайте: «Сбербанк Онлайн» в новом, современном интерфейсе. Про процесс создания приложения интереснее узнать от самих создателей.
Мы передаём слово команде разработчиков Android-приложения Сбербанка, чтобы вы услышали об опыте создания такой сложной штуки, как UI мобильного банк-клиента, из первых уст. Большую часть поста написал freeuser, так что спасибо говорите ему. ;)

В рамках образовательных программ в e-Legion мы проводим лекции по Android-разработке в лаборатории ИТИС КФУ. Двумя из них мы решили поделиться с вами. Лекции посвящены набирающему популярность фреймворку RxJava.

Лекция 1

В лекции рассказано про:

• Общие идеи фреймворка RxJava, зачем это нужно и как с этим работать
• Способы создания различных Observable и самые основные операции над ними
• Основных операторов преобразования Observable, а также о методе cache
• Операции соединения Observable и их последовательного / параллельного выполнения.

Презентация.