#Google вплотную взялся за задачу «сделать жизнь #Android разработчиков проще».

Пару недель назад выкатили видео, в котором рассказали что нового и реально интересного есть в #Jetpack - наборе инструментов для андроид разработчика.

Из самого для меня интересного:

👉 #Hilt. Рекомендованная библиотека для Dependency Injection. Она построена на #Dagger, но реализует то, что обычно приходилось делать костылями. Теперь есть простой и понятный способ инжекстится в Android Framework и Jetpack library классы.
👉 Paging 3. Переписанная Paging 2 на корутинах. Вообще, попробовав раз корутины и поняв их идеологию, возвращаться к RX для простой многопоточность уже не захочется.
👉 Navigation с Dynamic feature. Сам навигационный компонент всё никак не доходят руки нормально попробовать, но выглядит интересно. Теоретически можно строить навигацию, предполагая что все экраны в наличии, а по факту динамически подгружать фичи по мере использования. Модулярность в действии.
👉 Упрощение Request #Permission. Наконец. Теперь в понятном виде, легко и непринужденно можно запрашивать Runtime Permissions. Раньше использовал RxPermissions, которые делали жизнь проще, но сейчас вообще шик.
👉 Autofill IME. Клавиатура вообще всегда была больным местом. Кстати, в андроиде, начиная с 11 с помощью WindowInsets появилась возможность (наконец!) синхронизировать контент приложения с клавиатурой. А тут еще подвезли интересный API, который позволяет отображать inline suggest в подсказках к клавиатуре.

В общем, кажется жизнь андроид разработчика налаживается 😉 https://bit.ly/3drdezJ

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

Основные мысли:

👉 Юнит тесты помогают писать качественный код, быстро работают и создаются. Тем не менее они не гарантируют что вся система работает так как задумано. Такие тесты говорят где проблема конкретно в вашем коде.

👉 Функциональные тесты могут работать сравнительно долго и быть сложными по своей структуре. Главная их цель – убедиться, что код делает то, что было изначально задумано. Такие тесты говорят где проблема в реализации и логике.

А вы пишите тесты к вашему коду 🙈? https://bit.ly/3ghOIm8

И #Kotlin #Coroutines и Architecture component - практически must have в сегодняшнем Android приложении.

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

👉 Часть 1: https://medium.com/androiddevelopers/livedata-with-coroutines-and-flow-part-i-reactive-uis-b20f676d25d7
👉 Часть 2: https://medium.com/androiddevelopers/livedata-with-coroutines-and-flow-part-ii-launching-coroutines-with-architecture-components-337909f37ae7
👉 Часть 3: https://medium.com/androiddevelopers/livedata-with-coroutines-and-flow-part-iii-livedata-and-coroutines-patterns-592485a4a85a

Как-то раньше я совсем не использовал Котлиновские #Flow, пора это исправить. Хороший повод выпилить RX из текущего проекта на корню 🙈

ДомКлик - проект при поддержке Сбербанка в сфере недвижимости ищет Android разработчика.

Почему я это читаю 🙈?
Месячная посещаемость 9.5млн по Similarweb, 4.6🌟 в маркете намекает, что у команды, стоящей за проектом есть о чем поучиться. Это именно продуктовая технологическая компания.

А еще у них есть блог на Хабре.
https://habr.com/ru/company/domclick/

Город: Москва, м.Кутузовская
Формат: офис, гибкий график
Занятость: полная
ЗП: от 150.000 до 300.000

Обазанности как обычно. Разработка приложений, поддержка, code review и вот это всё.

Требования тоже стандартные. Опыт от 1.5 лет. Понимание что такое Android 📱

Плюшки:

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

https://team.domclick.ru/

Писать в телегу 24/7 @vamelan

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

Этот факт побудил написать мини статью о том, что такое логирование, как использовать #logcat и вообще как помочь себе писать качественные Android приложения без боли и страданий. https://bit.ly/2Cxfc52

Техническая #конференция для команд мобильной разработки #Mobius 2020 уже 11–14 ноября, Online.

4 дня, несколько треков, более 30 технических докладов без воды о работе платформ (#iOS/#Android) и языков программирования (#Java/#Kotlin/#Swift) под капотом, инфраструктуре, трендах в мобильной разработке, спикеры с мировыми именами, воркшопы и Q&A-сессии.

Подробная программа появится на сайте конференции, там же можно приобрести билеты: https://bit.ly/30W66XK

Кроме билетов на Mobius действует единый билет на все осенние конференции JUG Ru Group: https://bit.ly/3hOrB3x

#Firebase от #Google, о котором ранее писал в том числе в блоге содержит прямо пул полезных инструментов для мобильного разработчика. От хостинга до аналитики с искусственным интеллектом и ML Kit. Сейчас хотел бы поговорить отдельно про Database функционал.

Fierbase Databse - по сути NoSql база в облаке. Довольно быстро настраивается, описываются правила доступа и можно работать. Все в целом неплохо… пока речь идет только о хранении данных одного пользователя. Так сказать такой облачный кэш для вашего приложения.

У нас начались с ним проблемы, когда захотели написать бэкофис под БД. Т.е. такую небольшую субдоминанта поверх, чтобы было удобно вести сервис. Так как это NoSql база, то в целом она плохо рассчитана на сильно связанные данные и таблицы, чтобы сделать простые отчеты через несколько таблиц пришлось повозиться. Но на этом самое веселое только началось.

Бесплатный режим Firebase включает 50 тысяч доступов на чтение. Вроде много. Я даже выставил «бюджет» в 5$ на всякий случай, чтобы заметить если вдруг что. Все заработало (не так быстро, как могло бы быть с SQL, но все же). А через неделю внезапно оказалось, что наши скрипты для бэра выжирали примерно 11 миллионов чтений в день 😄, что стоило примерно 100-200$ за эту неделю.

Опты с Firebase DB показал (я могу быть не прав, поправьте, если так), что
* Eдобно использовать, когда вам нужен простой бак, хранящий инфу одного пользователя
* Это может стоить дорого, а ограничить жестко возможности нет (только придет уведомление)
* Если вам нужен более продвинутый бэк, то, вероятно писать его поверх Firebase DB так себе идея. Лучше взять даже старый добрый MySQL и иметь контролируемое решение.

А что вы думаете про Firebase Datastore? (Именно про datastore, а не другие сервисы, о которых можно поговорить отдельно). https://bit.ly/31zSJgn

Запустили игру, почти тетрис, но не совсем 🙂
Сама игра на #Unity, первая версия зарелижена пока что только под #Android.

Интересный момент. Предыдущие игры делал от начала до конца самостоятельно. С #Tetcore же ко мне обратился приятель, который по сути разработал игру процентов на 80-90 и попросил помочь с финальными штрихами и релизом.

Так вот, когда делаешь с нуля и до конца в "одно лицо" - на выходе может все казаться идеальным и удобным. А вот когда берешь абсолютно новый для тебя геймплей и пробуешь... тут сразу всплывают неудобства и очевидные издевательства над пользователем 🙈 Более чем уверен, что если бы сам делал, то было бы тоже самое, только я бы об этом не узнал без внешнего теста.

В итоге допилили управление и туториал и субъективно стало удобнее. (Но это не точно, ведь я тоже замылился по факту). И запустили AS IS. Получить фидбек от реальных людей лучше раньше чем позже.

К чему это я?

* Всегда проверяйте ваши идеи на совершенно не искушенных пользователях. То, что вам кажется 100% очевидным по факту может оказаться непреодолимым для большинства.
* Работа «по другую сторону баррикад» - именно не непосредственно в разработке, а со стороны продакт менеджмента дает понять почему порой на ваших проектах PM кажется вам каким-то странным 😉
* Баги будут всегда. Это нормально. Для нового продукта бывает критически важно вовремя запуститься, а не пытаться достичь недостижимого идеала.

И да, буду крайне признателен за оценочку в маркете 😉 https://bit.ly/3kgifj9

Наконец-так вышло то, что все* давно ждали!

*Не знаю как вы, но я и многие кого знаю из мобайла - точно.

#Google дал возможность оставлять отзыв о приложении прямо внутри приложения🌟

Теперь можно попросить пользователя оценить его опыт ровно тогда, когда он на это готов и не выгонять его из приложения при этом теряя конверсии. https://bit.ly/30IPbsR

#Google довольно давно веел фичу «Отчет о тестировании» в Google play developer console. Вероятно вы ей уже пользовались, но на всякий случай решил напомнить о ней еще раз.

Когда вы загружаете APK/AppBundle в консоль, то Google прогоняет на версии ряд тестов. Он запускает ваше приложение на живых девайсах и даже постит скриншоты в консоль 🔥

По факту тестирования на почту упадет письмо с результатами.

Примечательно, что тестирование запускается не только на релизной версии, но и даже на версиях, предназначенных для внутреннего тестирования. Кстати если, вы им еще не пользуетесь, советую присмотреться, туда можно вообще пушить с вашего CI: https://dimlix.com/deploy-android-app-with-ease/ 😉

Итого последовательность действий при релизе может быть такая:
* Закидываете релиз кандидата в internal channel в google play
* Тестируете сами и ждете тестов от Google
* Смотрите отчет, какие потенциальные проблемы есть, вплоть до того, какие кликабельные зоны меньше рекомендуемого
* Катите оттестированное приложение в релиз
* ...
* Профит!

Заметил (даже может быть очередной раз) полезную вещь про работу в команде.

С ~2016 года на всех проектах работал либо один, либо был самым сенсорным человеком на проектах. Порой коллеги в команде на замечания по коду на PR и в целом по общению говорили «о, круто\не знал такого\хорошое замечание». И сам, отвечая за техническую реализацию проекта в «одном лицо» смотришь на код и думаешь «ну вроде архитектура, код и вообще проект четкий, структурированный и тд».

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

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

О чем это я? Если есть возможность поработать в команде с технически сильным коллегой - стоит этим воспользоваться. Тут даже дело не в том, что он скажет как надо, а в том что можно подумать над проблемой «с разных сторон». Полагаю именно по-этому считается, что в компании (читай «стартапе») должно быть 2 учредителя. Монополярная точка зрения - довольно рискованный подход.

При использовании #ViewModel и #LiveData время от времени всплывает проблема, когда в LiveData хочется запулить объект ровно один раз. Например это может быть сообщение об ошибке. Зачем его показывать и\или обрабатывать несколько раз?

Для этого есть замечательная небольшая надстройка LiveEvent. Он позволяет решить ровно эту проблему по сути одной строчкой кода. LiveEvent дальше возвращается как LiveData и можно с ней работать и быть уверенным, что результат доставить исключительно 1 раз. Удобно. https://bit.ly/2Egn3UV

Разговоры про #ViewHolder уходят еще во времена когда #RecyclerView не был еще написан и балом правил #ListView (я даже об этом писал: https://dimlix.com/listview-recyclerview-android/).

Сейчас все изменилось. Пришел модульный RecyclerView и все стало хорошо. Точнее было хорошо пока не пришел #Kotlin с синтетиком.

Доступ ко #View через точку - крайне удобная штука хочу заметить, но в компании с ViewHolder может сыграть злую шутку.

Специально для этого есть интерфейс #LayoutContainer. Есть даже длинная буржуйская статья на тему что там внутри и как правильно им пользоваться. https://bit.ly/3lbV3mG

#Яндекс проводит конкурс на тему мобильной разработки.

Будет проходить с конца сентября по ноябрь, призы:

💰  300 000 рублей за 1 место
💰  150 000 рублей за 2 место
💰  100 000 рублей за 3 место
🔑  Промокоды на сервисы Яндекса за топ-100 https://bit.ly/3aIPF5w

#Kotlin выкатился в версии 1.4.
Из интересного (ну если опустить о том, что Котлин сам по себе интересен чуть более чем полностью).

👉 Подсветка кода работает быстрее, особенно заметно на больших файлах. Полезно когда комп не очень шустрый.
👉 Базовый отладчик корутин.
👉 Еще больше автозамен и дополнений. У Jetbrains интеллектуальность ввода всегда был прямо магией какой-то.
👉 Еще больше информации по ссылке.

Если вы всё еще используете Java, то таки попробуйте Kotlin, рекомендую! https://bit.ly/2YvWLpf

Иногда люди пишут #Unit тесты. Также иногда в этих тестах #Exception - ожидаемый результат. И вот тут на разных проектах видел конструкцию, которая вызывается в try-catch и далее происходит #Assert. Не надо так 😅

Для случаев, когда вам нужно проверить, что тестовый метод вернет исключение есть замечательная конструкция Expected.  Она говорит о том, что в данном случае ожидается исключение заранее известного типа.

Каждый год проходят множество конференций по IT.
И тут вдруг подумал - а кто здесь ходит\участвует в разных ITшных тусовках, конференциях и митапах?

Вы задумывались как Covid-19 повлиял на игровую индустрию в мобайле?
А вот кто-то точно задумывался, и более того, приготовил отчет на эту тему.

Исследование покрывает вопросы, как то
👉 Как пандемия повлияла на длину сессий?
👉 В какие типы игр люди играли больше находясь на самоизоляции?
👉 Как часто используются социальные логины в игру?

Не то, чтобы must have инфа, но точне любопытная. https://bit.ly/2YQPfFr