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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

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

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

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

Наверняка каждый Android разработчик работал со списками, используя RecyclerView. А также многие успели посмотреть как организовать пагинацию в списке, используя Paging Library из Android Architecture Components.

Все просто: устанавливаем PositionalDataSource, задаем конфиги, создаем PagedList и скармливаем все это вместе с адаптером и DiffUtilCallback нашему RecyclerView.

Но что если у нас несколько источников данных? Например, мы хотим иметь кэш в Room и получать данные из сети.

Кейс получается довольно кастомный и в интернете не так уж много информации на эту тему. Я постараюсь это исправить и показать как можно решить такой кейс.

Возможность использовать translucent в андроид появилась ещё в KITKAT. И выглядит в правильном дизайне это довольно эффектно. А с появлением моды на девайсы с "Чёлками", кажется, просто необходимой вещью в любом тёплом ламповом стартапчике.

Давайте представим ситуацию: вы запилили офигительно красивый, скроллящийся под StatusBar и NavigationBar дизайн. И вот вы добавляете поле ввода и понимаете, что adjustResize у вас не работает.

Вы можете:

1. Забить, – пользователь сам закроет клавиатуру, чтобы посмотреть что под ней.
2. Отказаться от translucent, стиль – это не ваше, всё будет олдово, надёжно, как у всех.
3. Как только пользователь начинает скроллить, скрывать клавиатуру. Вы молодец! Всё правильно сделали, skype даже под ios так делает! А там и прозрачности-то нет.
4. Вынести все поля ввода на отдельные экраны. Как бонус — каждый лишний переход на экран, минус удобство и конверсия.
5. Запилить свой adjustResize.

• RecyclerView selection — выбор элементов теперь из коробки;
• Slices — новый способ отображать контент другого приложения;
• новые элементы дизайна: BottomAppBar, ChipGroup и другие;
• мелкие изменения одной строкой.

Как и для многих разработчиков, папка .idea в Android Studio для меня всегда была, как черный ящик: я знал, что она существует, я знал, что её всегда добавляют в .gitignore, но я решил узнать, для чего же там нужны те или иные файлы и папки, чтобы у меня была возможность обрабатывать иногда возникающие git-конфликты, и для того, чтобы точно знать, какой файл можно безопасно добавить в .gitignore, а какой нет.

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

Решил написать о некоторых вещах, которых, по моему мнению, стоит и не стоит избегать при использовании корутин Kotlin.

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

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

Вопрос о жизненном цикле (life cycle) активности (activity) или фрагмента (fragment) андроид-приложения чрезвычайно важен для практикующего андроидчика (андроид-разработчика). Почему? Потому что порядок выполнения обратных вызовов всех методов, связанных с состоянием жизненного цикла (onCreate(), onStart() и т.д.), жёстко задан и неправильное его применение приведёт к неработоспособности приложения. При чём здесь жизненный цикл? — спросит внимательный хаброчитатель. Ведь в заголовке, вроде бы, речь не о нём? Отвечаю: между жизненным циклом активности и работой RecyclerView есть нечто общее — это НАЛИЧИЕ ЖЁСТКОГО ПОРЯДКА выполнения методов обратного вызова при использовании данного виджета, и, следовательно, необходимость ЕГО ПРАВИЛЬНО ПРИМЕНЯТЬ.

Если этого не делать, то списки могут вести себя крайне загадочным образом.

От переводчика

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

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

От переводчика

Здравствуйте, хабрчане. Это перевод статьи-документации к новой технологии Navigation для Android-разработчиков. Технология сейчас находится в стадии разработки, но уже доступна для использования и очень даже работает в превью версии Android Studio 3.2 и выше. Я уже опробовал её в действии и могу сказать что меня она впечатлила. Наконец-то осуществление смены экранов перестало быть чем-то сложным, особенно если используется передача данных от одного экрана к другому. Собственно, перевод я делаю для того чтобы больше русскоязычных разработчиков обратило внимание на технологию, и чтобы упростить её изучение.
Если заметите существенные ошибки или неточности, прошу сообщать в комментариях.

Что такое WebView?