​​Splitties
#библиотека

Думаю, что многие из тех, кто пишет на Kotlin, согласятся, что при помощи него можно значительно уменьшить количество кода, если сравнивать с Java. Безусловно это польза. В одной презентации увидел фразу, которая звучит как «Less code — less bugs», где есть доля истины.

Помочь в уменьшении кода может коллекция библиотек Splitties. По сути, это набор extention-функций, которые уменьшают число boilerplate кода. Основная часть методов сделана под Android, но разработчики уже написали часть из них и под multiplatform. Особенно радует то, что в проект не нужно тянуть всю библиотеку целиком — можно выбрать только те модули, которые нужны.

Список модулей впечатляет: это и работа с Activity, с Alert Dialog, Permissions, Views. А кроме этого, есть собственный View DSL, немного напоминающий декларативный UI.

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

​​Забытое искусство написания конструкторов
#статьи #разработка

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

Сейчас у нас с каждым днём становится всё больше и больше инструментов для разработки, больше «best practises» и современных языков программирования.

Но мы живём в не идеальном мире и часто забываем о некоторых практиках, которых стоит придерживаться. Одна из них — это написание конструкторов.

Конструкторы с большим количеством параметров нарушают принцип единой ответственности: ваш класс делает слишком много одновременно. Максимальное рекомендуемое количество параметров, передаваемое в конструктор — 4. Звучит нереально, учитывая, например, конструкторы Presenter. Автор описывает такой пример:

class ProfilePresenter
@Inject
constructor(
@MainThreadScheduler private val mainScheduler: Scheduler,
@IOScheduler private val ioScheduler: Scheduler,
private val profileApi: ProfileApi,
private val userRepository: UserRepository,
private val analytics: Analytics,
private val errorReporter: ErrorReporter
private val referrerTracker: ReferrerTracker,
private val shareTracker: ShareTracker,
private val tracksRepository: TracksRepository,
private val playlistRepository: PlaylistRepository
)

Если бы мы использовали Koin, то код стал бы похож на следующее:
ProfilePresenter(get(), get(), get(), get(), get(), get(), get(), get(), get(), get())

Безусловно, это затрудняет понимание инициализации, и тут лучше использовать именование параметров. Но вернёмся к тому, как уменьшить количество параметров.

• выделите общие зависимости
Посмотрев на код, мы можем увидеть общую группу Scheduler:

@MainThreadScheduler private val mainScheduler: Scheduler,
@IOScheduler private val ioScheduler: Scheduler,

Всё это можно объединить одним интерфейсом:
interface RxSchedulers {
val io: Scheduler
val computation: Scheduler
val main: Scheduler
}

• используйте фасады
В тех случаях, когда обёртка интерфейсом не помогает, мы можем сделать фасад, спрятав туда похожие классы.
В нашем примере подобными являются классы, ответственные за аналитику:
private val analytics: Analytics,
private val referrerTracker: ReferrerTracker,
private val shareTracker: ShareTracker

Попробуем скрыть их в фасад:
class ProfileTracker(
private val analytics: Analytics,
private val referrerTracker: ReferrerTracker,
private val shareTracker: ShareTracker
fun trackProfileOpened(referrer: String) =
referrerTracker.profileOpened(referrer)
fun trackProfileShared() =
shareTracker.profileShared()
}

• используйте use case
Ещё одним полезным советом является использование use case. Например, у нас есть несколько репозиториев, ответственных за работу профиля. Мы можем сделать из них один класс:
class ProfileUseCase(
private val userRepository: UserRepository,
private val tracksRepository: TracksRepository,
private val playlistRepository: PlaylistRepository,
)

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

Расширение возможностей Android Studio

Продуктивность в написании кода — важная часть работы программиста. И её улучшить можно не только за счет библиотек, но и с помощью плагинов IDE.

Уже сегодня можно послушать о том, как писать плагины самостоятельно. На примере, спикер расскажет как написать свой плагин для генерации кода, который сэкономит много времени при работе с ViewModel + Dagger.

Спикер — Павел Стрельченко — Android разработчик в компании hh.ru, занимается поддержкой основных приложений и разрабатывает внутренние инструменты для улучшения работы своей команды.

Подключайтесь к стриму сегодня, в 20:00 по Москве тут.

А вот и свежий #квиз на внимательность.

Он также больше подходит как тест на собеседование. И честнее решать его без помощи ввода в среду разработки 😉.

Всем привет!

С самого начала ведения этого канала, я не рассказывал о том, кто я, где работаю и чем занимаюсь, я не связывал канал с собой. Мне кажется, что это неправильно, особенно когда на канале уже больше 5000 человек. Так давайте же исправим это! 😊

Меня зовут Александр Горшков, и я автор этого канала. Уже больше 5 лет я работаю Android-разработчиком из которых последние 2 года – удалённо. Мне очень нравится этот формат работы, так как он позволяет удачно планировать своё время и много путешествовать, чем я собственно и пользуюсь.

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

Кроме этого, я организатор GDG сообщества у себя в городе Брянск. Об этом сообществе вы не раз читали у меня на канале.

Мне всегда можно написать в личные сообщения @al_gorshkov.
Ваш фидбек нереально заряжает писать новые посты и делать «движухи». Если вдруг у вас есть какие-то идеи для канала или вам не хватает какой-то информации, связанной с Android — вы всегда можете написать мне об этом.

Возможно, кому-то интересно, чем я живу вне канала, поэтому вот ссылка на мой Instagram: https://www.instagram.com/al.gorshkoov

Спасибо что вы здесь!
До новых постов! 😎

​​Single click в Android
#разработка #статьи #опрос

Казалось бы, что может быть проще, чем сделать клик на кнопку. Используй стандартный View.OnClickListener и будь уверен, что кнопка нажмётся. Однако, не всё может быть столь очевидно.

Опытные разработчики сталкивались с какими-то задвоенными действиями в приложении. Например, два запроса в сеть вместо одного. Часто причиной подобного поведения является именно стандартный ClickListener.

Решения может быть два:
• блокировка кнопки до появления какой-то реакции или ответа;
• добавление небольшой задержки при нажатии на кнопку.

Любопытно, что аннотация @OnClick из библиотеки ButterKnife, использовала именно DebouncingOnClickListener под капотом.
Но сегодня, когда основная масса разработчиков использует Kotlin synthetics или View Binding, мы забываем про этот «хак».

Автор в статье напоминает об этой фиче и рассказывает, как просто использовать его, совмещая с extension-функциями Kotlin. Получилось довольно удобно, и теперь можно делать:

my_button.setOnCLick(intervalMillis = 500) {
// Do stuff
}

вместо стандартного клика.

Кто считает, что клик с задержкой — это костыль?

Ask me anything! — Badoo
#статьи

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

Думаю, что приложение Badoo особо не нуждается в представлении. 🤓
В Android-приложениях этой компании больше 1,3 млн строк кода, а в Android-команде более 20 разработчиков. Основной язык разработки — Kotlin, архитектурные паттерны — MVI и RIBs, база данных — SQLite.
А сегодня разработчики отвечают на вопросы из комментариев.

Задать интересующий вопрос можно тут.

​​Как именовать цвета в Android?
#статьи #разработка

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

Уверен, что вы видели подобные цвета в каких-то проектах: login_button_background или confirmed_bg_gradient_end. Основная проблема — это отсутствие возможности переиспользовать эти цвета без ущерба к смыслу.

Вторым распространённым подходом является нейминг в стиле палитры Material Colors. Например, тут вы можете увидеть цвета red_50, red_100, green_a100 и т.д. Проблема в том, что если вы видите цвета с цифрами на конце, то это не дает полное представление о том, как выглядит этот цвет. Например, красный с индексом 50 — это цвет, который больше похож на розовый. Это делает их повторное использование также затруднительным.

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

Как по мне, любопытный подход, который можно взять на вооружение.

​​Как обеспечить безопасность приложения?
#разработка #статьи #комментарии

Для большинства приложений — безопасность очень важная вещь. Это особенно она важна, если вы работаете с данными пользователей или у вас есть покупки. Ведь никто не хочет, чтобы платной версией приложения пользовались бесплатно. 😉

Автор в статье дал несколько советов, которые значительно улучшат безопасность внутри приложения.

• обфускаций кода — наверное, первая и самая важная вещь, которая должна быть у вас включена. Для этого нужно прописать minifyenabled = true в вашем build.gradle приложения. Начиная с Android Studio 3.5 по умолчанию включен R8 вместо pro-guard, что, судя по всему, делает реверс-инжениринг приложения тяжелее. Обязательно проверьте своё приложение после включения этого флага и уделите особое внимание enum-классам.

• проверка на root — по сути root позволяет пользователям делать на их устройстве чуть больше, чем обычным пользователям, например изменение системных файлов или доступ ко внутреннему хранилищу приложения. Запрет использования приложения на root-устройствах может быть критичным.
Мне не приходилось делать проверку на root, но судя по всему, есть решение в виде библиотеки RootBeer.

• зашифрованное соединение с сервером — не мне рассказывать, что большинство приложений связаны с сервером. Обязательно проверьте, насколько безопасно это соединение: это обязательно должно быть https соединение. Можно добавить ещё Certificate Pinning, которым вы будете шифровать каждый запрос на сервер. Пример есть тут.

• шифрованное локальное хранилище — тут важно оценить «важность» тех данных, которые хранятся на устройстве. Если эти данные позволяют выполнять запросы на сервер от лица пользователя (например, это token), то обязательно стоит задуматься о безопасном хранении этой информации. Для шифрования sharedpreferences можно использовать security-crypto, который хоть и не находится в релизной стадии, но уже работает довольно сносно.

• debug mode и логи — никогда не кладите в логи какую-то важную информацию. Проверьте, включен ли deguggable = false в релизном билде.

А что ещё важно учитывать, чтобы сделать приложение безопасным? Давайте обсудим в комментариях

​​Firebase App Distribution
#разработка

Одним из способом доставки билда тестировщикам, является Firebase App Distribution. Это хороший и простой способ. И у него есть следующие преимущества:
• бесплатный;
• нет лимитов на размер файла приложения;
• работает и на iOS и на Android;
• можно добавлять группы тестировщиков;
• можно приглашать в тестирование по ссылке;
• добавление release notes к каждому билду;
• интеграция с Android Studio.

Для меня ключевым является последний пункт. Даже если у вас в проекте нет CI-системы, то вы легко можете выполнить одну gradle-команду, чтобы загрузить свежую версию приложения в Firebase с release notes и оповестить всех ваших тестировщиков.

Оповещением займется сам Firebase, а мы давайте посмотрим, как же получить release notes от HEAD в git до последнего тега. Пусть все коммиты с префиксом {ADD} — это наши release notes.
Для этого выполним команды:
1) def tagNumber = "git describe --abbrev=0 --tags".execute().text.trim() — вернёт там последий тэг
2) def releaseNotes = ("git --no-pager log ${tagNumber}...HEAD --no-merges --date-order --format=%s --grep {ADD}").execute().text.trim() — вернёт нам список коммитов с префиксом {ADD}
3) new File("release_notes.txt").text = releaseNotes — сохраним всё в файл

А дальше чуть-чуть настроим Firebase:

firebaseAppDistribution {
releaseNotesFile = project.rootProject.file('release_notes.txt')
}


Укажем, что хотим взять release notes именно из этого файла, а остальные настройки лучше посмотреть тут.

Осталось только объединить описанные выше команды в одну при помощи gradle task, назовём её logs и выполним эти команды:

task getLogsAssembleAndDistributeQaRelease(type: GradleBuild) {
tasks = ['clean',
'logs',
'appDistributionUploadQaRelease']
}

В итоге наш билд улетит в Firebase, главное дождаться сборки и не выключить компьютер. 😉

Друзья, нужна ваша помощь.

На канале хочу запустить новую рубрику. Суть её состоит в том, чтобы брать интервью у разработчиков, живущих в других странах и городах.
Будем разговаривать про уровень жизни в стране, культурные привычки, наличие работы, насколько легко туда переехать, нравится ли жить там, сколько стоит жизнь, ну и самое важное — какой зарплатный уровень и налоги.
Получится обширная статья про страну, направленная на жизнь разработчика. Ну а цифры буду суммировать в табличку, чтобы сделать вывод: «Где же лучше жить разработчику?»

Скажите, насколько было бы вам интересно видеть эту рубрику? Какие страны хотелось бы видеть прежде всего и в каком формате?

Лично мне это кажется интересным, ведь информации из первых рук в Интернете не так много. Пишите в комментариях или мне в личку @al_gorshkov и, конечно, голосуйте реакциями. 🤓

Ого, понял, что идея с рубрикой вам зашла!

Особая благодарность подписчикам, которые написали мне в личку с предложением рассказать о своём городе. Если кто-то ещё хочет, но при этом стесняется — не надо переживать, пишите мне @al_gorshkov, уверен, что остальным будет интересно прочитать о вашем опыте.😌

Android Academy про Android 11
#конференции

Уже прошло пару месяцев с момента появления Android 11, но всё равно ещё есть доклады, которые рассказывают о новых фишках и деталях.

Ребята из Android Academy Global делают мероприятие, где будет 3 темы:

1️⃣ Jetpack Dagger Hilt, Мануэль Виво, Google
2️⃣ ActivityResultApi and AppStartUp Api, Алексей Быков, Revolut
3️⃣ Jetpack Paging 3, Дмитрий Мовчан, Revolut

Оно будет уже совсем скоро, 4 августа в 19:00 по Москве. А зарегистрироваться можно тут.

​​Оптимизация приложения для автозаполнения
#разработка

Совсем недавно, столкнулся с интересным, и на первый взгляд, странным багом. У одного пользователя приложения при вводе параметров в EditText появлялось всплывающее сообщение с выбором логина и пароля для входа в него (в приложение).
Пришлось капнуть в сторону решения этого бага, и выяснил одну деталь, которую я раньше игнорировал.

При создании нового EditText в xml, он предлагает ввести атрибут importantForAutofill. Чтобы убрать warning, можно просто игнорировать этот атрибут или добавить в EditText параметр tools:ignore="Autofill". В этом случае, вы уберёте warning, но сможете поймать похожий на мой баг.

Однако лучше не полениться и оптимизировать своё приложение для сервисов автозаполнения. 😊
Например, если вы не хотите, чтобы ваш EditText был доступен для заполнения, используйте в нём параметр android:importantForAutofill="no". Но, например, для ввода логина или пароля, можно поставить этот атрибут yes и добавить новый атрибут android:autofillHints="password" для паролей и android:autofillHints="emailAddress" для e-mail.

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

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

​​Жизнь в Израиле
#интервью #экспаты

Итак, начнём новую рубрику на канале!

Наш первый гость — это Андрей Раньков. Он проживает в Израиле, город Кфар-Саба (15 км от Тель-Авива) вместе с женой и двумя детьми. Андрей является Mobile Lead в компании Appcard.

У каждого из вас есть возможность спросить его о жизни в Израиле, легко ли туда попасть разработчику, каков уровень жизни да и вообще всё, что вы давно хотели спросить у местного жителя, но не знали у кого.

Ссылка на форму, где можно задавать свои вопросы тут.

А если у вас есть предложения или вопросы по этому формату, или же вы проживаете в других странах и хотите поделиться опытом, то пишите мне @al_gorshkov.

​​Используйте In-App Review API для Google Play ревью
#разработка

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

Наконец-то Google даёт нам API для того, чтобы пользователь мог поставить оценку приложения прямо в нем. 👍🏻
Подробнее о том, как работает API можно почитать тут.

По сути, это API — часть Play Core Library, которая сделана для Java/Kotlin, C++ и Unity. Google подчёркивает, что важно определить, где в вашем приложении самое лучшее место для того, чтобы попросить пользователя оставить оценку.

​​Анимация как в Google почте
#разработка #статьи

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

В этой статье автор описывает, как сделать анимацию открытия почты приложения Google-почта. На мой взгляд, получилась приятная и ненавязчивая анимация, которую можно использовать в качестве основной при открытии экранов вашего приложения.

​​KotlinX Datetime
#разработка #библиотека

Совсем недавно разработчики из JetBrains анонсировали библиотеку для работы с датами kotlinx-datetime версии 0.1.

Это здорово, потому что до последнего момента не было возможности работать с датами напрямую из Kotlin. И если мы, как Android-разработчики, могли напрямую ссылаться на API java.time.*, то при работе с мультиплатформой такой возможности не было.

Более детально о работе с этой библиотекой можно прочесть тут

​​Давненько на канале не проводилось конкурсов. Это нужно срочно исправлять😉

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

Старт конкурса 19 августа в 18:00. Задачку, как всегда, можно будет решить в течении 48 часов.

В этот раз за призы отвечают ребята из команды Badoo.
И вас ждёт 3 призовых места:
🥇место — толстовка + сумка + мерч;
🥈 место — футболка + сумка + мерч;
🥉 место — сумка + мерч.

Кстати, команда Badoo Tech, ведёт интересный Telegram канал, где делится своим опытом. Подписан и давно читаю: @badoo_tech