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

С ~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

#Монетизация мобильных приложений - отдельная наука.
Взять, запилить несколько инапов и/или подписок, выложить приложение и ждать волны баксов - иллюзия, которая разбивается примерно сразу.

Набрел на позновательно-интересную статью (англ.) про то, как компания затачивает игру под in-app.

Несколько интересных моментов:
👉 Очевидно, что в игре должно быть достаточно контента. Каждый отдельно взятый пользователь стоит денег. Причем относительно немалых. Логично его удерживать как можно дольше, постепенно "заставляя" тратить деньги. Конкретно в статье в основном паке уровней их аж 2000.

👉 UI коммуникация может подталкивать людей к покупке. Как пример простая иконка, обозначающая уровень сложности. Используешь ли "Hard" или "Extreme" - может повлиять на выбор пользователя какие усилители надо будет купить.

👉 Для новых пользователей можно предлагать купить "Starter pack". Если честно, в ряде игр я и сам такое покупал. Логика простая - начинаешь играть, хочешь, чтобы было чуть легче, пока не втянешься в геймплей. Да и просто игра хорошая - почему бы не "проспонсировать разработчика".

Бонус: ранее слышал, что в рамках монетизации можно использовать тот факт, что пользователю тяжелее расстаться с тем, что он уже "заработал", нежели пробудить желание получить нечто в будущем. На этом тоже часто играют разработчики игр. Вы скорее заплатите, чтобы продолжить уровень после gameover нежели расстанетесь с деньгами до начала уровня за повышенный шанс его пройти. https://bit.ly/31M1F3r

Мы уже наблюдали за разными попытками "упростить разработку мобильных приложений" через разные конструкторы. Но вот идею верстать аппки через Google таблицы - что-то новенькое 😅

"Мы хотим, чтобы не программистам было проще создавать приложения, а вообще всем." (с) Дэвид Сигел глава Glide.

Вот я с ним не до конца согласен. Дело даже не в том, что я боюсь, что разработчики перестанут быть нужны, а в том, что даже если получится сделать так, чтобы создать приложение занимало минуты и не требовало навыков... То ведь спам поток в маркеты будет уже не остановить 🙈

Вечное "Быстро, качественно, дешево. Можно выбрать любые 2" пока никто не победил. https://bit.ly/352t2s8

#Android #Jetpack тут на #SharedPreferences покусился 😱

Представил альфу #DataStore. Внутри #Kotlin #Coroutines и #Flow. Есть две реализации

👉 #Proto Datastore. Позволяет хранить типизированные объекты. Привет Protocol Buffer.
👉 #Preferences Datastore. Тут можно хранить ключ-значение.

Работа с данными асинхронна, консистентна и транзакциональна.
По ссылке там даже табличка сравнений есть. https://bit.ly/35ptvVx

#Flavors - очень полезная штука в #Android разработке.
Они позволяют задавать разные конфигурации одного и того же приложения.

Также для flavors есть dimensions - это (как следует из названия) измерение, в котором живет очередной flavor. Оно помогает перемешивать несколько flavor в отдельный конечный build variant.

К примеру вы можете собрать Free и Paid версию приложения и в каждый тип также можно собрать на тестовом и реальном окружении.

В целом очень удобная штука, но главное заранее продумать необходимые flavors и dimensions, иначе можно и запутаться во всех доступных вариантах сборки 😜

Рубрика "А что - так можно было?".
Если вы разрабатываете инди игру, то можно официально уведомить google о том, что вы делаете и попасть в подборку Indie Corner Featuring.

#PlayIndie - регулярно обновляемая подборка Indie игр в Google play store. https://bit.ly/329Rmq0

"#CI для бедных" или как не страдать при деплое билдов тестировщикам и в маркет.

"Для бедных" в это контексте - важно. Фраза о том, что в больших компаниях зачастую есть #DevOps, инфраструктура и это всё, что позволяет разработчику код писать, а не думать о деплое дальше своей локальной машины. Зачастую в стартапах нет таких привилегий.

Есть и хорошая новость - для этих целей есть ряд бесплатных классных тулзов.

Первая вещь, чем довольно давно пользуюсь - #CircleCI. Позволяет без лишней боли собрать проект. Работает на докерах. Понятное окружение, удобная интеграция. Кстати, про деплой через CircleCI я уже даже как-то писал.

Второе открытие этого год - #Github actions. Позволяет прямо в Github запилить билд. Даже есть интеграции дальше с доставкой во всякие #Firebase app distribution. Работают триггеры на пулреквесты, пуши и всякие разные actions.

Понятное дело у всех есть бесплатные лимиты. Но коли вы из них выйдете - наверное с проектом все отлично и можно и заплатить за четкий #SaaS.

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

#Hilt в #Android выглядит довольно интересно... Но только для небольших проектов.

Он позволяет прямо быстро завести приложение с использованием #DI, но цена этому - жесткие ограничения на обязательность аннтотаций и ограниченный набор компонент.

Неплохой вариант, когда надо сходу заинжектить нечто в #Acitivty или фрагмент, но тут может быть собака зарыта. Скорее всего, в большом проекте у вас будут всякие разные слои - данных, логики, представления и тд. И вот тут-то окажется, что, вполне возможно, в сами Активности и Фрагменты инжектить ничего и не надо, потому что они выступают просто как морда, а все данные и вся магия происходит ниже. Вон там, ниже, и нужны все не тривиальные зависимости. А тут-то Hilt уже не поможет. https://bit.ly/33d4z0t

На чем вообще можно писать #Android #UI Тесты?
*Зачем и стоит ли это делать - отдельный вопрос 🙈

В статьей на хабре в блоге Авито разобраны инструменты, которые позволяют писать ЮАйные тесты.

Моё личное мнение, что писать UI тесты явно стоит тогда, когда хотя бы большинство #Unit тестов на месте и делают свою работу. https://bit.ly/3bNixde

Вдруг кто не знал. В #Android можно наследовать темы в стилях 2-мя способами. Через точку и через parent. Если определить две родительские темы, то parent выиграет, т.е. смысла в этом нет.

Через точку удобно создавать иерархии своих же стилей, через parent - наследовать чужие.