DroDev | Мобильная разработка: мысли вслух
460 subscribers
104 photos
229 links
Обсуждаю и рассказываю как сделать жизнь разработчика в команде интересной, легкой и продуктивной.

По всем вопросам @dilix90
Download Telegram
This media is not supported in your browser
VIEW IN TELEGRAM
Вот почему поддержка проекта не менее важна чем его запуск.
Есть  несколько причин, почему я не люблю и не использую onClick в xml  разметках #layout. Вот главные:

1) Неявный вызов метод из "верстки" тяжело воспринимать при чтении кода
2) При #CodeReview проследить логику становится очень сложно
3) #AndroidStudio не всегда корректно видит использования методов и кнопок

Используете ли вы определение onClick прямо в верстке?
Надеюсь все знают, что #View в #Android может принимать не 2 (видно\нет), а 3 значения:

View.VISIBLE
View.INVISIBLE
View.GONE

Правильно ли их используешь ты 🙃?
Пиши в комменты в каких случаях используешь View.INVISIBLE 👻, а когда View.GONE 🕶
Время от времени крупные компании проводят митапы, в том числе по  #Android разработке. Такие бывают у Avito (http://bit.ly/2ogUXS9), Касперского, Яндекса и т.д.

Так вот, недавно в Авито один такой прошел, самый сок можно найти на хабре, приятного просмотра! http://bit.ly/2AZk92g
This media is not supported in your browser
VIEW IN TELEGRAM
Всегда грамонтно рассчитывайте свои силы и не бойтесь сказать "Нет" если проект вам не по скилу.
В блог пишу статьи на интересные разработчику темы.

Хочешь задавать тон и читать про то, что интересно именно тебе?

Оставляй пожелания в комментах или в специальной теме для заявок в ВК 🗣
4 строчки кода и несколько косяков.
Какие #ошибки вы видите в данном сниппете?
#Аналитика в мобильных приложениях для разработчика - страшный сон архитектуры вашего проекта. Всё потому, что мы, как разработчики, уважаем #SOLID, инкапсуляцию и всё такое... А потом приходит аналитик, маркетолог и просят всякую дичь. Например поведение пользователя на экране в зависимости от предыдущего экрана. И вот прощай #инкапсуляция.

Статья на тему как встраиваю аналитику обычно я - в черновиках и в работе, а тем временем ребята из La moda рассказывают как это делают они: https://habr.com/ru/company/lamoda/blog/469761/.

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

#Firebase #analytics (http://bit.ly/2OQwQoe)
Бесплатно и сердито. Можно строить воронки по событиям, но нельзя использовать параметры событий в нем.  Атрибуция (понять от куда пришел пользователь) есть, но в Appsflyer проще. Можно выгружать "сырые" данные в #BigQuery. Это круто, удобно и все такое, но надо повозиться. Зато можно настроить любые графики, данные и все что можно себе представить.

#Appsflyer (https://lite.ms/mTmv5y)
Использовался в основном для атрибуций. Причем, говорят (не пробовал), есть атрибуция рекламы по ТВ. В интерфейсе воронки по событиям можно разделять на каналы. У ребят из моей команды были проблемы отправить в AppsFlyer события с сервера, чтобы следить за ЖЦ пользователя в разрезе клиент-серверного единого пространства.

#Amplitude (http://bit.ly/2IPq7Ha)
Воронки - чума, можно строить по событиям, учитывать параметры и порядок ивентов. Посмотреть обезличенную инфу по пользователям на каждом этапе воронки и узнать кто конкретно отвалился. Например недавно прибежал аналитик и "айайай, у нас после релиза почему то >50% после первого экрана онбординга отваливаются". Зашли в amplitude, выгрузили список отвалившихся пользователей. Из условных 50 пользователей за период 30 было из США с одной и той же моделью телефона и из одной подсети. Все бы ничего, но приложение в сторе не доступно оттуда :D Выдвинули гипотезу, что это авто (или не очень) тесты после раскатки и спокойно пошли работать дальше.


Мой выбор - при старте проекта, если там и так используется Firebase - добавить аналитику от него. С ним можно уже запускаться, хоть будет понятно что происходит. Дальше Amplitude для более продвинутых воронок. Appsflyer уже если собираетесь поливать усиленно траффиком.
This media is not supported in your browser
VIEW IN TELEGRAM
Рефакторинг и расплата с "техническим долгом" должны быть аккуратными, так, чтобы не наломать еще больше дров.
Есть предложение. Задумал ряд мини статей-заметок в формате FAQ "как сделать <тут-что-то-интересное> в #Android". Например "как организовать мониторинг сетевого подключения".

Внутри только сок, вкратце что надо. Примеры кода и ссылочка на github где уже реализовано описанное + ссылка на google play где можно пощупать реализованное.

К тебе, дорогой слушатель, ровно 2 вопроса.
1) интересен ли такой формат (опрос ниже 🔽)?
2) есть ли определенные темы, которые хотелось бы увидеть (пишем в комментах, обсуждениях)?
Выложили видео с DroidCon NY.

А между тем, пока вы их смотрите, примеры кода, про которые говорил в прошлый раз практически готовы. Остается дописать "объяснительные записки" в виде небольших FAQ статей и первая версия этой движухи будет доступна. Скорее всего это произойдет уже на следующей неделе.

А пока продолжаем следить за новостями и статьями, впереди много интересного! https://www.droidcon.com/videos?path=NewYork%20City
И снова немного про кросс-платформенную разработку.

В свободное время попробовал написать небольшое приложение на #Flutter
- это и правда классный инструмент, чтобы быстро сделать #MVP, но есть нюансы
- не надо думать, что "написал один раз и забыл". Например решил подключить Firebase. Пришлось открыть xcode и android studio, чтобы добавить нужные файлы и зависимости.
- некоторые фишки нужно дописать, даже если они есть в нативе. FirebaseUI Auth есть для #Web/#Android/#iOS. А чтобы подключить ее к flutter, не залезая в исходники - придется поискать библиотеку или писать самому.
- работает не всегда и не везде. Я, как Андроид разработчик, быстро завел приложение на эмуляторе. А вот iOS отказался работать, потому что конфигурация на первом этапе была сделана не совсем верно.

Итого - писать сразу под обе платформы - отличные подход, если вам нужно быстро приложение под 2+ платформы. Но надо быть готовым, что базовые знания для каждой платформы должны быть. Также, для сборки iOS нужна будет MacOS. И тут не только про flutter, часто в интернете натыкаюсь на вопросы про разные фреймворки из разряда "как заставить работать <фича> на <framework>".

Вот еще пара развернутых мыслей про кросс-платформ: https://tproger.ru/experts/native-or-crossplatform/
#Airship (тот, который раньше назывался #UrbanAirship) - оказался крайне удобным инструментом когда нужно реализовать сложные сценарии доставки сообщений пользователю.

Можно посылать Push определенным сегментам, по событиям, таймингу и тд. Конечно все это можно сделать напрямую со своего сервера (по сути написать такой функционал руками), но я более чем уверен, что

а) Это не будет в итоге сильно дешевле
б) Маркетинг отделу будет не так удобно как могло бы быть

Airship позволяет доставлять либо Pushы, либо in-app сообщения, а также интегрировать Message center в приложение. Message center - своего рода inbox, в котором складываются пришедшие сообщения. Причем поддерживается RICH формат, который откроется в WebView. Т.е. дизайнер может рисовать любой лендинг, который будет показывать в приложении.

Так что, если будет стоять задача по-быстрому (но не бесплатно) реализовать комплексный подход для маркетинга внутри приложения - Airship хорошо справится с задачей. https://www.airship.com/
Смена темы в #Android приложении может быть сделана через простую установку setTheme, но тогда нужно будет пересоздать #Activity.

Можно поменять UI прямо на лету, даже во время прокрутки #ScrollView.

Оба подхода имеют место быть. Важно понимать что они есть и как реализовать переключения тем разными способами. https://dimlix.com/switch-theme-android/
This media is not supported in your browser
VIEW IN TELEGRAM
Если даже один человек из команды "не тащит", то рано или поздно это отразиться на продукте и на вас лично.