Android-разработчик
Думаю, каждый из нас периодически сталкивается с непонятными микрофризами при взаимодействии с, казалось бы, простым UI…
Просто скролишь список, и тут — бац! Лагнуло! Сегодня я бы хотел разобрать одну из множества причин такого поведения — работу с ресурсами. Мы разберёмся, в каких случаях работа с ресурсами может стать проблемой. Почему это происходит и как лучше всего от этого избавится.
«Дело было вечером, делать было нечего» — именно так родилась идея сделать вью с возможностью зума, распределяющую юзеров по рангам в зависимости от кол-ва их очков. Так как до этого я не имел опыта в создании собственных вьюшек такого уровня, задача показалась мне интересной и достаточно простой для начинающего… но, *ох*, как же я ошибался.
С конца 2019 Huawei поставляет Android-смартфоны без сервисов Google, в том числе без привычного всем магазина приложений Google Play. В качестве альтернативы китайская компания предлагает собственные разработки — Huawei Mobile Services (HMS), а также магазин AppGallery. В этом тексте мы расскажем, как с этим жить и работать.
В марте Google Play стал рассылать письмо-предупреждение для разработчиков, использующих Huawei Mobile Services в своих мобильных приложениях. И в этом письме было сказано, что использование HMS в сборках для Google Play противоречит политикам стора приложений, а на решение проблемы дается 120 дней. В противном случае Google Play обещает перестать принимать обновления для таких приложений.
После получения такого “письма счастья” мы окончательно убедились, что наша единая сборка приложения для всех сторов с переключением платформенных сервисов в рантайме – не самое надежное решение в столь изменчивом мире. В общем, мы решили оперативно перейти на раздельные сборки. Особенность нашего решения в том, что мы сохранили GMS+HMS сборку приложения для AppGallery, добавив в наш проект возможность сделать чистую GMS-сборку для Google Play. Мы использовали флейворы, но в связке с многомодульностью нам удалось затащить под флейворы лишь минимальное количество кода.
В этой небольшой статье я расскажу о нашей архитектуре разделения сборок для разных сторов, проблемах, с которыми столкнулись, а еще поделюсь статистикой по активным HMS-пользователям.
main thread (главном потоке), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI). Как только вы начинаете добавлять к вашему приложению такие «затратные по времени» куски кода, как загрузка данных из сети или обработка изображений на main thread (главном потоке), то работа вашего UI начинает сильно замедляться и даже может привести к полному его «замораживанию». 
сoncurrency), которая позволяет одновременно выполнять две или более независимые задачи (tasks): вычисления, загрузку данных из сети или с диска, обработку изображений и т.д.
Sql, RegExp, Gradle — что их объединяет? Всё это примеры использования проблемно-ориентированных языков или DSL (domain-specific language). Каждый такой язык решает свою узконаправленную задачу, например, запрос данных из БД, поиск совпадений в тексте или описание процесса сборки приложения. Язык Kotlin предоставляет большое количество возможностей для создания собственного проблемно-ориентированного языка. В ходе статьи мы разберемся, какие инструменты есть в арсенале программиста, и реализуем DSL для предложенной предметной области.
Весь синтаксис, представленный в статье, я объясню максимально просто, однако, материал рассчитан на практикующих инженеров, которые рассматривают Kotlin, как язык для построения проблемно-ориентированных языков. В конце статьи будут приведены недостатки, к которым нужно быть готовым. Используемый в статье код актуален для Kotlin версии 1.1.4-3 и доступен на GitHub.
Хочу поделиться историей, ну и заодно услышать мнения других участников хабрасообщества. Это небольшая история о том, как агрессивное внедрение методологии разработки Agile (Scrum) в отдельно взятой российской IT компании послужило началом исхода из компании лучших разработчиков. Обычно в статьях про Agile рассказывают, какая это классная и полезная методология, и вообще — это лучшее, что было придумано в этом направлении. Возможно, эта статья поможет взглянуть на Agile с другой стороны, ведь у любой монеты, как оказалось, есть две стороны.
Всем привет! Сегодня я бы хотел поговорить об архитектуре Android-приложений.
На самом деле я не очень люблю доклады и статьи на данную тему, но недавно ко мне пришло осознание, с которым я бы хотел поделиться.
Приветствую вас, уважаемые хабражители! На написание статьи меня подтолкнул этот пост (а точнее, то чувство резкого локального повышения температуры в районе… хм, поясницы, обычно возникающее, когда в интернете кто-то неправ).
Начнем с самого начала. Полностью согласен, что "между жизненным циклом активности и работой RecyclerView есть нечто общее" – это "нечто" – необходимость понимать, что мы делаем и зачем. И читать документацию. А невыполнение этих двух необходимостей, как и сон разума, рождает монстров. Только вот с тем, как предлагает с этими монстрами бороться предыдущий автор, я категорически не согласен.
От переводчика:
Уже опубликовано много материалов по MVC и его производным паттернам, но каждый понимает их по-своему. На этой почве возникают разногласия и холивары. Даже опытные разработчики спорят о том, в чем отличие между MVP, MVVM и Presentation Model и что должен делать тот или иной компонент в каждом паттерне. Ситуация усугубляется еще и тем, что многие не знают истинную роль контроллера в классическом варианте MVC. Предлагаю вашему вниманию перевод хорошей обзорной статьи, которая многое проясняет и расставляет всё по своим местам.
На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.
