Предыстория

Первая итерация вынос версий библиотек

// creationext {  dagger = '2.25.3'  fabric = '1.25.4'  mindk = 17}// usageprintln(dagger)println(fabric)println(mindk)

// creationval dagger by extra { "2.25.3" }val fabric by extra { "1.25.4" }val minSdk by extra { 17 }// usageval dagger: String by extra.propertiesval fabric: String by extra.propertiesval minSdk: Int by extra.properties

// grdle.propertiesoverriden=2// build.gradleext.dagger = 1ext.overriden = 1// module/build.gradleprintln(rootProject.ext.dagger)   // 1println(dagger)                   // 1println(rootProject.ext.overriden)// 1println(overriden)                // 2

Вторая итерация project.subprojects

allprojects {    repositories {        google()        jcenter()    }}

subprojects { project ->    afterEvaluate {        final boolean isAndroidProject =            (project.pluginManager.hasPlugin('com.android.application') ||                project.pluginManager.hasPlugin('com.android.library'))        if (isAndroidProject) {            apply plugin: 'kotlin-android'            apply plugin: 'kotlin-android-extensions'            apply plugin: 'kotlin-kapt'                        android {                compileSdkVersion rootProject.ext.compileSdkVersion                                defaultConfig {                    minSdkVersion rootProject.ext.minSdkVersion                    targetSdkVersion rootProject.ext.targetSdkVersion                                        vectorDrawables.useSupportLibrary = true                }                compileOptions {                    encoding 'UTF-8'                    sourceCompatibility JavaVersion.VERSION_1_8                    targetCompatibility JavaVersion.VERSION_1_8                }                androidExtensions {                    experimental = true                }            }        }        dependencies {            if (isAndroidProject) {                // android dependencies here            }                        // all subprojects dependencies here        }        project.tasks            .withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile)            .all {                kotlinOptions.jvmTarget = JavaVersion.VERSION_1_8.toString()            }    }}

Третья итерация buildSrc и plugin

import org.gradle.api.JavaVersionimport org.gradle.api.Pluginimport org.gradle.api.Projectclass ModulePlugin implements Plugin<Project> {    @Override    void apply(Project target) {        target.pluginManager.apply("com.android.library")        target.pluginManager.apply("kotlin-android")        target.pluginManager.apply("kotlin-android-extensions")        target.pluginManager.apply("kotlin-kapt")        target.android {            compileSdkVersion Versions.sdk.compile            defaultConfig {                minSdkVersion Versions.sdk.min                targetSdkVersion Versions.sdk.target                javaCompileOptions {                    annotationProcessorOptions {                        arguments << ["dagger.gradle.incremental": "true"]                    }                }            }            // resources prefix: modulename_            resourcePrefix "${target.name.replace("-", "_")}_"            lintOptions {                baseline "lint-baseline.xml"            }            compileOptions {                encoding 'UTF-8'                sourceCompatibility JavaVersion.VERSION_1_8                targetCompatibility JavaVersion.VERSION_1_8            }            testOptions {                unitTests {                    returnDefaultValues true                    includeAndroidResources true                }            }        }        target.repositories {            google()            mavenCentral()            jcenter()                        // add other repositories here        }        target.dependencies {            implementation Dependencies.dagger.dagger            implementation Dependencies.dagger.android            kapt Dependencies.dagger.compiler            kapt Dependencies.dagger.androidProcessor            testImplementation Dependencies.test.junit                        // add other dependencies here        }    }}

Дальше standalone plugin или монорепо

Итого

Что происходит, кто виноват и что делать

Недавно Google прекратил сотрудничество с Huawei. Это привело к тому, что Huawei на своих новых девайсах уже не может использовать сервисы Google (магазин приложений, геолокация, карты, пуши, аналитика etc), что для пользователя превращает девайс в кирпич. Если бы это не была китайская компания, то, скорее всего, на этом её бизнес, связанный с Android, просто бы прекратился. Но компания китайская, большая и они пошли по пути импортозамещения, в кратчайшие сроки реализовав функционал, аналогичный Google сервисам.

В этой серии статей мы хотим поделиться своим опытом использования Huawei Mobile Services в уже готовом приложении, использующем Google Mobile Services для аналитики (Firebase Analytics), карт и геолокации. Текста получилось довольно много и о сильно разных сервисах, засим статей будет несколько. Начнём мы с основ регистрации аккаунта разработчика и базовых вещей в коде.

1. Создаём аккаунт разработчика, подключаем зависимости, подготавливаем код к внедрению. вы тут
2. Встраиваем Huawei Analytics.
3. Используем геолокацию от Huawei.
4. Huawei maps. Используем вместо Google maps для AppGallery.

Если вам интересно узнать технических подробностей, посмотреть код и узнать про подводные камни добро пожаловать под кат!

Что нужно для успешного внедрения

Всё было бы просто, если бы приложение писалось с нуля и не нужно было бы поддерживать как Google так и Huawei. Но мы живём в реальном мире и без сложностей не обойтись. Однако дело сильно упростится, если соблюдён ряд условий.

Но перед перечислением условий надо составить ТЗ. Оно у нас получилось такое:

1. Нам нужно получить 2 версии APK одну для Google Play, с библиотеками от Google, другую для AppGallery, с библиотеками от Huawei.
2. В приложении уже используется Firebase Analytics. Надо его заменить на аналог от Huawei.
3. Есть определение местоположения пользователя. Аналогично заменяем на аналог.
4. Есть карты. Нужно также заменить на аналог, по максимуму сохранив функционал, т.к. в реализации от Huawei некоторые вещи ещё не сделаны.

А вот что сильно сократит прикладываемые усилия:

1. Код должен быть написан хорошо. И быть без багов (хотя это само собой разумеется зачем код с багами писать?). Под хорошо будем подразумевать более-менее стандартную архитектуру, мимикрирующую под Clean.
2. Если код из Google библиотек размазан ровным слоем по всему проекту, то у меня для вас плохие новости. Например у вас может не быть абстракции над аналитикой и/или над полученными от Google координатами. В этом случае придётся её завести, чтобы почистить код от импортов гугловых классов, которые будут недоступны, когда мы уберём их из сборки.
3. Использование DI. Очень упрощает абстрагирование над аналитикой и геолокацией. Используем интерфейсы, через DI передавая нужную реализацию.
4. Карты не слишком сильно кастомизированы. В частности, основная сложность будет с абстрагированием над кластеризацией маркеров.

Подготовка к внедрению

Как и в случае с Google, надо зарегистрироваться, создать проект приложения, получить файл конфигурации.

1. Регистрируемся на https://developer.huawei.com. Тут понадобится паспорт/права + пластиковая карта. День-два вас будут проверять, потом аккаунт заработает. Если вдруг что-то пойдёт не так (забудете что-то указать или укажете неправильно) вам напишут и подробно объяснят. После общения с Google Play всё выглядит очень круто русскоязычная техподдержка отвечает быстро и по делу.
2. Принимаем всякие соглашения об обработке персональных данных. Внимательно читая, конечно же)
3. Создаём проект приложения, указывая пакет (он же ApplicationId).
4. Если вам нужно ещё и встроенные покупки реализовать то надо: а) Заполнить данные банковского счёта б) Распечатать и заполнить заявление о трансграничной передаче персональных данных в КНР в) Отправить скан оного вместе с данными из пункта а г) Отправить заявление из пункта б по почте в Москву. Когда заявление дойдёт вам придёт e-mail и останется только активировать сервис в настройках проекта. На почте бывают накладки возможно, придётся подождать. Я пару недель ждал, потом позвонил ответственному за это в Huawei уверили, что проблему решат. И решили. На русском тоже всё общение очень круто)
5. Включаем сервис аналитики. В отличие от геолокации и карт, включённых по умолчанию, это нужно сделать вручную.
6. Добавляем SHA-256 для всех ключей, которыми будет подписано приложение. Т.е. дебажные ключи и релизный ключ.
7. Скачиваем аналог google-services.json, в случае Huawei называемый agconnect-services.json
8. Создаём разные flavors для Google и Huawei. Наконец-то можно перейти к коду:

В build.gradle (module app) создаём flavors и указываем, что в папках src/google/kotlin, src/google/res, src/huawei/kotlin, src/huawei/res также находиться будет наш код.

android {  ...  sourceSets {      google.java.srcDirs += 'src/google/kotlin'      google.res.srcDirs += 'src/google/res'      huawei.java.srcDirs += 'src/huawei/kotlin'      huawei.res.srcDirs += 'src/huawei/res'  }  flavorDimensions "store"  productFlavors {      google {          dimension "store"      }      huawei {          dimension "store"      }  }}

Также создаём папки src/huaweiDebug и src/huaweiRelease. В них помещаем наш файл конфигурации agconnect-services.json

И добавляем apply plugin: 'com.huawei.agconnect' в конец build.gradle (module app).

И наконец, добавляем в build.gradle проекта:

buildscript {    ...    repositories {        ...        maven {url 'https://developer.huawei.com/repo/'}    }    dependencies {        ...        classpath 'com.huawei.agconnect:agcp:1.2.1.301'    }}allprojects {    repositories {        ...        maven {url 'https://developer.huawei.com/repo/'}    }}

В следующей части встраиваем аналитику

Теперь мы полностью готовы. У нас есть 2 разных варианта сборки для Huawei и Google. У нас подключены необходимые зависимости. Созданы папки, где будет наш код. Создан аккаунт разработчика и выполнены необходимые действия по созданию проекта приложения. У нас даже какое-то ТЗ есть. И мы уже выполнили первый пункт из ТЗ! Отличный повод на этом статью закончить. И уже в следующей встроить аналитику не от Google, а от Huawei.

Весь код, который есть в этом цикле статей вы можете посмотреть в репозитории на GitHub. Вот ссылка.

В прошлой статье мы создавали аккаунт разработчика для использования Huawei Mobile Services и подготавливали проект к их использованию. Теперь пора приступить к встраиванию конкретных сервисов.

Вот полный список статей из цикла:

1. Создаём аккаунт разработчика, подключаем зависимости, подготавливаем код к внедрению. тык
2. Встраиваем Huawei Analytics. вы тут
3. Используем геолокацию от Huawei.
4. Huawei maps. Используем вместо Google maps для AppGallery.

Как должен выглядеть код в уже готовом проекте

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

interface Analytics {    fun send(event: AnalyticsEvent)}interface AnalyticsEvent {    val key: String    val data: Map<String, Any>}fun Map<String, Any>.toBundle() =    Bundle().apply {        forEach { (key, value) ->            when (value) {                is String -> putString(key, value)                is Int -> putInt(key, value)                is Boolean -> putBoolean(key, value)                is Double -> putDouble(key, value)                is Float -> putFloat(key, value)                else -> throw IllegalArgumentException("Unknown data type: ${value::class.simpleName}")            }        }    }open class SimpleEvent(override val key: String) : AnalyticsEvent {    override val data: Map<String, Any> = hashMapOf()    override fun toString(): String = "AnalyticsEvent { key = $key, data = $data }"}open class ParamsEvent(key: String, vararg params: Pair<String, Any>): SimpleEvent(key) {    override val data = params.toMap()}class EventOpenSomeScreen : SimpleEvent("screen_some_screen")

Соответственно, где требуется какое-то событие отправить, вы делаете что-то такое:

@Injectlateinit var analytics: Analytics...analytics.send(EventOpenSomeScreen())

Используем разные реализации аналитики

Если всё вышеописанное верно, то подставлять разные реализации аналитики в разных сборках проще простого.

1. Указываем, что для huawei flavor-а мы используем одну библиотеку, а для google другую:

dependencies {  huaweiImplementation 'com.huawei.agconnect:agconnect-core:1.3.1.300'  huaweiImplementation 'com.huawei.hms:hianalytics:5.0.0.301'  googleImplementation 'com.google.firebase:firebase-analytics:17.2.3'}

1. В DI биндим для типа Analytics экземпляр класса AnalyticsImpl. Сам же AnalyticsImpl у нас будет в двух вариантах. Один в папке src/huawei/kotlin/com/example и выглядеть так:

class AnalyticsImpl(context: Context) : Analytics {    private val analytics = HiAnalytics.getInstance(context)    override fun send(event: AnalyticsEvent) {        analytics.onEvent(event.key, event.data.toBundle())    }}

Другой в папке src/google/kotlin/com/example:

class AnalyticsImpl(context: Context) : Analytics {  private val firebaseAnalytics = FirebaseAnalytics.getInstance(context)  override fun send(event: AnalyticsEvent) {      firebaseAnalytics.logEvent(event.key, event.data.toBundle())  }}

Вот собственно и всё с аналитикой. API библиотек очень похожи и никаких проблем не возникает.

Проверяем, что всё работает

Также, очень удобно можно проверить, что Huawei аналитика работает. Для этого надо:

1. Подсоединить девайс к компьютеру.
2. Выполнить в консоли adb shell setprop debug.huawei.hms.analytics.app ТУТ_APPLICATION_ID_ВАШЕГО_ПРИЛОЖЕНИЯ
3. Открыть консоль разработчика в браузере, перейти в AppGallery Connect -> Мои приложения -> Выбрать приложение -> Раздел "Разработка" -> Управление -> Отладка приложения.
4. Теперь отправленные из приложения события вы будете видеть в реальном времени прямо на сайте.
5. Чтобы отключить режим отладки выполните adb shell setprop debug.huawei.hms.analytics.app .none.

Вот так режим отладки выглядит в браузере:

Дальше геолокация

С аналитикой мы разобрались, в следующей статье покажем как встроить определение геолокации от Huawei в приложение, которое уже использует аналог от Google.

Весь код, который есть в этом цикле статей вы можете посмотреть в репозитории на GitHub. Вот ссылка.

В предыдущих статьях мы создавали аккаунт разработчика для использования Huawei Mobile Services и подготавливали проект к их использованию. И использовали аналитику от Huawei вместо аналога от Google. В этой статье мы будем встраивать определение геолокации от Huawei.

Вот полный список статей из цикла:

1. Создаём аккаунт разработчика, подключаем зависимости, подготавливаем код к внедрению. тык
2. Встраиваем Huawei Analytics. тык
3. Используем геолокацию от Huawei. вы тут
4. Huawei maps. Используем вместо Google maps для AppGallery.

С геолокацией немного сложнее, т.к. надо нюансы учитывать. О них, конечно, тоже расскажем.

Как должен выглядеть код в уже готовом проекте

Исходить будем, опять таки, из того, что у вас геолокация для гугла сделана примерно так:

1) Для проверки разрешения пользователя на доступ к его местоположению использована библиотека RxPermissions примерно так:

class PermissionsHelper {    private var rxPermissions: RxPermissions? = null    /**     * Вызываем в Activity#onCreate     */    fun attach(activity: FragmentActivity) {        rxPermissions = RxPermissions(activity)    }    /**     * Вызываем в Activity#onDestroy     */    fun detach() {        rxPermissions = null    }    fun requestPermission(vararg permissionName: String): Single<Boolean> {        return rxPermissions?.request(*permissionName)            ?.firstOrError()            ?: Single.error(                IllegalStateException("PermissionHelper is not attached to Activity")            )    }}

2) Создан свой класс для местоположения:

data class Location(    val latitude: Double,    val longitude: Double) {    companion object {        val DEFAULT_LOCATION = Location(59.927752, 30.346944)    }}

3) Создана абстракция над поставщиком местоположения:

interface FusedLocationClient {    fun checkPermissions(): Single<Boolean>    fun getLastLocation(): Single<Location>    fun requestLastLocation(): Single<Location>}

4) И используется она примерно так:

class LocationGateway(    private val fusedLocationClient: FusedLocationClient) {    fun requestLastLocation(): Single<Location> {        return fusedLocationClient.checkPermissions()            .flatMap { granted ->                if (granted) {                    fusedLocationClient.getLastLocation()                        .onErrorResumeNext(fusedLocationClient.requestLastLocation())                } else {                    Single.just(Location.DEFAULT_LOCATION) // или ошибку кидаем какую-то                }            }    }}

Используем разные реализации определения геолокации

Если вышеописанное верно для вашего случая, то как и в случае с аналитикой нам понадобятся 2 разные реализации FusedLocationClient FusedLocationClientImpl:

1) В папке src/huawei/kotlin/com/example:

class FusedLocationClientImpl(    private val permissionsHelper: PermissionsHelper,    context: Context) : FusedLocationClient {    private val fusedLocationClient = LocationServices.getFusedLocationProviderClient(context)    override fun checkPermissions(): Single<Boolean> {        val permissions = mutableListOf(Manifest.permission.ACCESS_FINE_LOCATION)        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.P) {            // for huawei we need this permission too after API=28            permissions += Manifest.permission.ACCESS_BACKGROUND_LOCATION        }        return permissionsHelper.requestPermission(*permissions.toTypedArray())    }    override fun getLastLocation(): Single<Location> {        return Single.create { singleEmitter ->            fusedLocationClient.lastLocation                .addOnFailureListener {                    if (singleEmitter.isDisposed) return@addOnFailureListener                    singleEmitter.onError(it)                }                .addOnSuccessListener { newLocation ->                    if (singleEmitter.isDisposed) return@addOnSuccessListener                    if (newLocation == null) {                        singleEmitter.onError(UnknownLocationException())                    } else {                        singleEmitter.onSuccess(                            Location(                                newLocation.latitude,                                newLocation.longitude                            )                        )                    }                }        }    }    override fun requestLastLocation(): Single<Location> {        return Single.create { singleEmitter ->            val locationRequest = LocationRequest.create()                .setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY)                .setInterval(5000)                .setSmallestDisplacement(5.5F)                .setNumUpdates(1)            val callback = object : LocationCallback() {                override fun onLocationResult(result: LocationResult) {                    if (singleEmitter.isDisposed) return                    singleEmitter.onSuccess(                        Location(                            result.lastLocation.latitude,                            result.lastLocation.longitude                        )                    )                }            }            fusedLocationClient.requestLocationUpdates(locationRequest, callback, null)            singleEmitter.setCancellable {                fusedLocationClient.removeLocationUpdates(callback)            }        }    }}

2) В папке src/google/kotlin/com/example:

class FusedLocationClientImpl(    private val permissionsHelper: PermissionsHelper,    context: Context) : FusedLocationClient {    private val fusedLocationClient = LocationServices.getFusedLocationProviderClient(context)    override fun checkPermissions(): Single<Boolean> {        return permissionsHelper.requestPermission(Manifest.permission.ACCESS_FINE_LOCATION)    }    @SuppressLint("MissingPermission")    override fun getLastLocation(): Single<Location> {        return Single.create { singleEmitter ->            fusedLocationClient.lastLocation                .addOnFailureListener {                    if (singleEmitter.isDisposed) return@addOnFailureListener                    singleEmitter.onError(it)                }                .addOnSuccessListener { newLocation ->                    if (singleEmitter.isDisposed) return@addOnSuccessListener                    if (newLocation == null) {                        singleEmitter.onError(UnknownLocationException())                    } else {                        singleEmitter.onSuccess(                            Location(                                newLocation.latitude,                                newLocation.longitude                            )                        )                    }                }        }    }    @SuppressLint("MissingPermission")    override fun requestLastLocation(): Single<Location> {        return Single.create { singleEmitter ->            val locationRequest = LocationRequest.create()                .setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY)                .setInterval(5000)                .setSmallestDisplacement(5.5F)                .setNumUpdates(1)            val callback = object : LocationCallback() {                override fun onLocationResult(result: LocationResult) {                    if (singleEmitter.isDisposed) return                    singleEmitter.onSuccess(                        Location(                            result.lastLocation.latitude,                            result.lastLocation.longitude                        )                    )                }            }            fusedLocationClient.requestLocationUpdates(locationRequest, callback, null)            singleEmitter.setCancellable {                fusedLocationClient.removeLocationUpdates(callback)            }        }    }}

В итоге реализации отличаются 2 вещами: импортами и тем, что в случае Huawei надо запрашивать разрешение на запрос геолокации в фоне на API>28.

Аналогично с аналитикой, в DI биндим для типа FusedLocationClient экземпляр FusedLocationClientImpl. Для разных сборок будет взята та или иная реализация.
Ну и не забываем, конечно, зависимости в скрипте сборки прописать:

dependencies {  huaweiImplementation 'com.huawei.agconnect:agconnect-core:1.3.1.300'  huaweiImplementation 'com.huawei.hms:location:5.0.0.301'  googleImplementation 'com.google.android.gms:play-services-location:17.0.0'}

И не забудьте добавить разрешение на доступ к местоположению в фоне для Huawei сборки! Если такое разрешение уже есть в основном файле AndroidManifest.xml то можете этот пункт пропустить. Если нет то создайте ещё один файл манифеста в папке src/huawei/ с таким содержимым:

<manifest xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    package="com.example">    <!-- huawei location throws error without this permission -->    <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /></manifest>

Подводные камни

Надо иметь в виду, что геолокация от Huawei будет работать при следующих условиях:

1. У вас установлены Huawei Mobile Services на девайсе.
2. Им выданы нужные разрешения.
3. Юзер согласился на определение местоположения в фоне, а не только во время использования.

Дальше встраиваем карты

С геолокацией мы разобрались, в следующей статье покажем как встроить карты от Huawei в приложение, которое уже использует аналог от Google.

Весь код, который есть в этом цикле статей вы можете посмотреть в репозитории на GitHub. Вот ссылка: https://github.com/MobileUpLLC/huawei_and_google_services.

В предыдущих статьях мы создавали аккаунт разработчика для использования Huawei Mobile Services и подготавливали проект к их использованию. Потом использовали аналитику от Huawei вместо аналога от Google. Также поступили и с определением геолокации. В этой же статье мы будем использовать карты от Huawei вместо карт от Google.

Вот полный список статей из цикла:

1. Создаём аккаунт разработчика, подключаем зависимости, подготавливаем код к внедрению. тык
2. Встраиваем Huawei Analytics. тык
3. Используем геолокацию от Huawei. тык
4. Huawei maps. Используем вместо Google maps для AppGallery. вы тут

В чём сложность

К сожалению, с картами не получится так просто, как было с аналитикой и геолокацией. Что и неудивительно, т.к. это гораздо более сложная система сама по себе. И очень часто в приложениях карты и взаимодействие с ними кастомизируется. Например, отображают маркеры, кластеризуют их. Поэтому кода будет много, т.к. надо всё это заабстрагировать, имея в виду некоторые отличия в API карт разных реализаций.

Создаём абстракцию над картой

Надо в разметке использовать разные классы для отображения карты. com.google.android.libraries.maps.MapView для гугло-карт и com.huawei.hms.maps.MapView для Huawei. Сделаем так: создадим собственную абстрактную вьюху, унаследовавшись от FrameLayout и в неё будет загружать конкретную реализацию MapView в разных flavors. Также создадим в нашей абстрактной вьюхе все нужные методы, которые мы должны вызывать на конкретных реализациях. И ещё метод для получения объекта самой карты. И методы для непосредственного внедрения реализации MapView от гугла и Huawei и прокидывания атрибутов для карт из разметки. Вот такой класс получится:

abstract class MapView : FrameLayout {    enum class MapType(val value: Int) {        NONE(0), NORMAL(1), SATELLITE(2), TERRAIN(3), HYBRID(4)    }    protected var mapType = MapType.NORMAL    protected var liteModeEnabled = false    constructor(context: Context, attrs: AttributeSet) : super(context, attrs) {        initView(context, attrs)    }    constructor(context: Context, attrs: AttributeSet, defStyleAttr: Int) : super(        context,        attrs,        defStyleAttr    ) {        initView(context, attrs)    }    private fun initView(context: Context, attrs: AttributeSet) {        initAttributes(context, attrs)        inflateMapViewImpl()    }    private fun initAttributes(context: Context, attrs: AttributeSet) {        val attributeInfo = context.obtainStyledAttributes(            attrs,            R.styleable.MapView        )        mapType = MapType.values()[attributeInfo.getInt(            R.styleable.MapView_someMapType,            MapType.NORMAL.value        )]        liteModeEnabled = attributeInfo.getBoolean(R.styleable.MapView_liteModeEnabled, false)        attributeInfo.recycle()    }    abstract fun inflateMapViewImpl()    abstract fun onCreate(mapViewBundle: Bundle?)    abstract fun onStart()    abstract fun onResume()    abstract fun onPause()    abstract fun onStop()    abstract fun onLowMemory()    abstract fun onDestroy()    abstract fun onSaveInstanceState(mapViewBundle: Bundle?)    abstract fun getMapAsync(function: (SomeMap) -> Unit)}

Чтобы работали атрибуты в разметке нам, конечно, надо их определить. Добавляем в res/values/attrs.xml вот это:

<declare-styleable name="MapView">    <attr name="someMapType">        <enum name="none" value="0"/>        <enum name="normal" value="1"/>        <enum name="satellite" value="2"/>        <enum name="terrain" value="3"/>        <enum name="hybrid" value="4"/>    </attr>    <attr format="boolean" name="liteModeEnabled"/></declare-styleable>

Это нам позволит прямо в разметке, используя нашу абстрактную карту передавать тип карты и нужен ли нам облегчённый режим для неё. Выглядеть в разметке это будет как-то так (реализация MapViewImpl будет показана далее):

<com.example.ui.base.widget.map.MapViewImpl    android:layout_width="match_parent"    android:layout_height="150dp"    app:liteModeEnabled="true"    app:someMapType="normal"/>

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

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

abstract class SomeMap {    abstract fun setUiSettings(        isMapToolbarEnabled: Boolean? = null,        isCompassEnabled: Boolean? = null,        isRotateGesturesEnabled: Boolean? = null,        isMyLocationButtonEnabled: Boolean? = null,        isZoomControlsEnabled: Boolean? = null    )    abstract fun setPadding(left: Int, top: Int, right: Int, bottom: Int)    abstract fun animateCamera(someCameraUpdate: SomeCameraUpdate)    abstract fun moveCamera(someCameraUpdate: SomeCameraUpdate)    abstract fun setOnCameraIdleListener(function: () -> Unit)    abstract fun setOnCameraMoveStartedListener(onCameraMoveStartedListener: (Int) -> Unit)    abstract fun setOnCameraMoveListener(function: () -> Unit)    abstract fun setOnMarkerClickListener(function: (SomeMarker) -> Boolean)    abstract fun setOnMapClickListener(function: () -> Unit)    abstract fun addMarker(markerOptions: SomeMarkerOptions): SomeMarker    abstract fun <Item : SomeClusterItem> addMarkers(        context: Context,        markers: List<Item>,        clusterItemClickListener: (Item) -> Boolean,        clusterClickListener: (SomeCluster<Item>) -> Boolean,        generateClusterItemIconFun: ((Item, Boolean) -> Bitmap)? = null    ): (Item?) -> Unit    companion object {        const val REASON_GESTURE = 1        const val REASON_API_ANIMATION = 2        const val REASON_DEVELOPER_ANIMATION = 3    }}

А вот и остальные классы/интерфейсы:

SomeCameraUpdate нужен для перемещения камеры на карте к какой-то точке или области.

class SomeCameraUpdate private constructor(    val location: Location? = null,    val zoom: Float? = null,    val bounds: SomeLatLngBounds? = null,    val width: Int? = null,    val height: Int? = null,    val padding: Int? = null) {    constructor(        location: Location? = null,        zoom: Float? = null    ) : this(location, zoom, null, null, null, null)    constructor(        bounds: SomeLatLngBounds? = null,        width: Int? = null,        height: Int? = null,        padding: Int? = null    ) : this(null, null, bounds, width, height, padding)}

SomeLatLngBounds класс для описания области на карте, куда можно переместить камеру.

abstract class SomeLatLngBounds(val southwest: Location? = null, val northeast: Location? = null) {      abstract fun forLocations(locations: List<Location>): SomeLatLngBounds}

И классы для маркеров.

SomeMarker собственно маркер:

abstract class SomeMarker {    abstract fun remove()}

SomeMarkerOptions для указания иконки и местоположения маркера.

data class SomeMarkerOptions(    val icon: Bitmap,    val position: Location)

SomeClusterItem для маркера при кластеризации.

interface SomeClusterItem {    fun getLocation(): Location    fun getTitle(): String?    fun getSnippet(): String?    fun getDrawableResourceId(): Int}

SomeCluster для кластера маркеров.

data class SomeCluster<T : SomeClusterItem>(    val location: Location,    val items: List<T>)

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

interface SelectableMarkerRenderer<Item : SomeClusterItem> {    val pinBitmapDescriptorsCache: Map<Int, Bitmap>    var selectedItem: Item?    fun selectItem(item: Item?)    fun getVectorResourceAsBitmap(@DrawableRes vectorResourceId: Int): Bitmap}

Также мы хотим иметь возможность сложной настройки внешнего вида маркера. Например генерируя иконку для него из разметки. Для этого скопируем класс из гугловой библиотеки IconGenerator:

/** * Not full copy of com.google.maps.android.ui.IconGenerator */class IconGenerator(private val context: Context) {    private val mContainer = LayoutInflater.from(context)        .inflate(R.layout.map_marker_view, null as ViewGroup?) as ViewGroup    private var mTextView: TextView?    private var mContentView: View?    init {        mTextView = mContainer.findViewById(R.id.amu_text) as TextView        mContentView = mTextView    }    fun makeIcon(text: CharSequence?): Bitmap {        if (mTextView != null) {            mTextView!!.text = text        }        return this.makeIcon()    }    fun makeIcon(): Bitmap {        val measureSpec = MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED)        mContainer.measure(measureSpec, measureSpec)        val measuredWidth = mContainer.measuredWidth        val measuredHeight = mContainer.measuredHeight        mContainer.layout(0, 0, measuredWidth, measuredHeight)        val r = Bitmap.createBitmap(measuredWidth, measuredHeight, Bitmap.Config.ARGB_8888)        r.eraseColor(0)        val canvas = Canvas(r)        mContainer.draw(canvas)        return r    }    fun setContentView(contentView: View?) {        mContainer.removeAllViews()        mContainer.addView(contentView)        mContentView = contentView        val view = mContainer.findViewById<View>(R.id.amu_text)        mTextView = if (view is TextView) view else null    }    fun setBackground(background: Drawable?) {        mContainer.setBackgroundDrawable(background)        if (background != null) {            val rect = Rect()            background.getPadding(rect)            mContainer.setPadding(rect.left, rect.top, rect.right, rect.bottom)        } else {            mContainer.setPadding(0, 0, 0, 0)        }    }    fun setContentPadding(left: Int, top: Int, right: Int, bottom: Int) {        mContentView!!.setPadding(left, top, right, bottom)    }}

Создаём реализации нашей абстрактной карты

Наконец приступаем к переопределению созданных нами абстрактных классов.

Подключим библиотеки:

//google mapsgoogleImplementation 'com.google.android.gms:play-services-location:17.0.0'googleImplementation 'com.google.maps.android:android-maps-utils-sdk-v3-compat:0.1' //clasterization//huawei mapshuaweiImplementation 'com.huawei.hms:maps:4.0.1.302'

Также добавляем необходимое для карт разрешение в манифест. Для этого создайте ещё один файл манифеста (AndroidManifest.xml) в папке src/huawei/ с таким содержимым:

<manifest xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    package="com.example">    <!-- used for MapKit -->    <uses-permission android:name="com.huawei.appmarket.service.commondata.permission.GET_COMMON_DATA"/></manifest>

Вот так будет выглядеть реализация карт для гугл. Добавляем в папку src/google/kotlin/com/example класс MapViewImpl:

class MapViewImpl : MapView {    private lateinit var mapView: com.google.android.libraries.maps.MapView    constructor(context: Context, attrs: AttributeSet) : super(context, attrs)    constructor(context: Context, attrs: AttributeSet, defStyleAttr: Int) : super(        context,        attrs,        defStyleAttr    )    override fun inflateMapViewImpl() {        mapView = com.google.android.libraries.maps.MapView(            context,            GoogleMapOptions().liteMode(liteModeEnabled).mapType(mapType.value)        )        addView(mapView)    }    override fun getMapAsync(function: (SomeMap) -> Unit) {        mapView.getMapAsync { function(SomeMapImpl(it)) }    }    override fun onCreate(mapViewBundle: Bundle?) {        mapView.onCreate(mapViewBundle)    }    override fun onStart() {        mapView.onStart()    }    override fun onResume() {        mapView.onResume()    }    override fun onPause() {        mapView.onPause()    }    override fun onStop() {        mapView.onStop()    }    override fun onLowMemory() {        mapView.onLowMemory()    }    override fun onDestroy() {        mapView.onDestroy()    }    override fun onSaveInstanceState(mapViewBundle: Bundle?) {        mapView.onSaveInstanceState(mapViewBundle)    }    /**     * We need to manually pass touch events to MapView     */    override fun onTouchEvent(event: MotionEvent?): Boolean {        mapView.onTouchEvent(event)        return true    }    /**     * We need to manually pass touch events to MapView     */    override fun dispatchTouchEvent(event: MotionEvent?): Boolean {        mapView.dispatchTouchEvent(event)        return true    }}

А в папку src/huawei/kotlin/com/example аналогичный класс MapViewImpl но уже с использование карт от Huawei:

class MapViewImpl : MapView {    private lateinit var mapView: com.huawei.hms.maps.MapView    constructor(context: Context, attrs: AttributeSet) : super(context, attrs)    constructor(context: Context, attrs: AttributeSet, defStyleAttr: Int) : super(        context,        attrs,        defStyleAttr    )    override fun inflateMapViewImpl() {        mapView = com.huawei.hms.maps.MapView(            context,            HuaweiMapOptions().liteMode(liteModeEnabled).mapType(mapType.value)        )        addView(mapView)    }    override fun getMapAsync(function: (SomeMap) -> Unit) {        mapView.getMapAsync { function(SomeMapImpl(it)) }    }    override fun onCreate(mapViewBundle: Bundle?) {        mapView.onCreate(mapViewBundle)    }    override fun onStart() {        mapView.onStart()    }    override fun onResume() {        mapView.onResume()    }    override fun onPause() {        try {            mapView.onPause()        } catch (e: Exception) {            // there can be ClassCastException: com.exmaple.App cannot be cast to android.app.Activity            // at com.huawei.hms.maps.MapView$MapViewLifecycleDelegate.onPause(MapView.java:348)            Log.wtf("MapView", "Error while pausing MapView", e)        }    }    override fun onStop() {        mapView.onStop()    }    override fun onLowMemory() {        mapView.onLowMemory()    }    override fun onDestroy() {        mapView.onDestroy()    }    override fun onSaveInstanceState(mapViewBundle: Bundle?) {        mapView.onSaveInstanceState(mapViewBundle)    }    /**     * We need to manually pass touch events to MapView     */    override fun onTouchEvent(event: MotionEvent?): Boolean {        mapView.onTouchEvent(event)        return true    }    /**     * We need to manually pass touch events to MapView     */    override fun dispatchTouchEvent(event: MotionEvent?): Boolean {        mapView.dispatchTouchEvent(event)        return true    }}

Тут надо обратить внимание на 3 момента:

1. Вьюху карты мы создаём программно, а не загружаем из разметки, т.к. только так можно передать в неё опции (лёгкий режим, тип карты etc).
2. Переопределены onTouchEvent и dispatchTouchEvent, с прокидывание вызовов в mapView без этого карты не будут реагировать на касания.
3. В реализации для Huawei был обнаружен крэш при приостановке карты в методе onPause, пришлось в try-catch обернуть. Надеюсь это поправят в обновлениях библиотеки)

Реализуем дополнительные абстракции

А теперь самое сложное. У нас в приложении было достаточно много кода для отображения, кастомизации и обработки нажатия на маркеры и кластеры маркеров. Когда начали это всё пытаться заабстрагировать возникли сложности. Почти сразу выяснилось, что хотя в картах от Huawei есть кластеризация, она не полностью аналогична по функционалу кластеризации от гугла. Например нельзя влиять на внешний вид кластера и обрабатывать нажатия на него. Также в Huawei картах внешний вид отдельных маркеров (и обработка их событий) работает также как и маркеры, которые должны кластеризироваться. А вот в гугло-картах для кластеризующихся маркеров всё иначе отдельная обработка событий, отдельный способ настройки внешнего вида и вообще всё это сделано в рамках отдельной библиотеки. В итоге пришлось думать как переписать код так, чтобы и сохранить функционал для гугло-карт и чтобы карты от Huawei работали.

В общем, пришли в итоге к такому варианту: создаём метод для показа множества маркеров, которые должны кластеризоваться, в него передаём нужные нам слушатели событий и возвращаем лямбду, для функционала выбора маркера. Вот реализация SomeMap для гугло-карт:

class SomeMapImpl(val map: GoogleMap) : SomeMap() {    override fun setUiSettings(        isMapToolbarEnabled: Boolean?,        isCompassEnabled: Boolean?,        isRotateGesturesEnabled: Boolean?,        isMyLocationButtonEnabled: Boolean?,        isZoomControlsEnabled: Boolean?    ) {        map.uiSettings.apply {            isMapToolbarEnabled?.let {                this.isMapToolbarEnabled = isMapToolbarEnabled            }            isCompassEnabled?.let {                this.isCompassEnabled = isCompassEnabled            }            isRotateGesturesEnabled?.let {                this.isRotateGesturesEnabled = isRotateGesturesEnabled            }            isMyLocationButtonEnabled?.let {                this.isMyLocationButtonEnabled = isMyLocationButtonEnabled            }            isZoomControlsEnabled?.let {                this.isZoomControlsEnabled = isZoomControlsEnabled            }            setAllGesturesEnabled(true)        }    }    override fun animateCamera(someCameraUpdate: SomeCameraUpdate) {        someCameraUpdate.toCameraUpdate()?.let { map.animateCamera(it) }    }    override fun moveCamera(someCameraUpdate: SomeCameraUpdate) {        someCameraUpdate.toCameraUpdate()?.let { map.moveCamera(it) }    }    override fun setOnCameraIdleListener(function: () -> Unit) {        map.setOnCameraIdleListener { function() }    }    override fun setOnMarkerClickListener(function: (SomeMarker) -> Boolean) {        map.setOnMarkerClickListener { function(MarkerImpl(it)) }    }    override fun setOnMapClickListener(function: () -> Unit) {        map.setOnMapClickListener { function() }    }    override fun setOnCameraMoveStartedListener(onCameraMoveStartedListener: (Int) -> Unit) {        map.setOnCameraMoveStartedListener { onCameraMoveStartedListener(it) }    }    override fun addMarker(markerOptions: SomeMarkerOptions): SomeMarker {        return MarkerImpl(            map.addMarker(                MarkerOptions()                    .position(markerOptions.position.toLatLng())                    .icon(BitmapDescriptorFactory.fromBitmap(markerOptions.icon))            )        )    }    override fun setPadding(left: Int, top: Int, right: Int, bottom: Int) {        map.setPadding(left, top, right, bottom)    }    override fun setOnCameraMoveListener(function: () -> Unit) {        map.setOnCameraMoveListener { function() }    }    override fun <Item : SomeClusterItem> addMarkers(        context: Context,        markers: List<Item>,        clusterItemClickListener: (Item) -> Boolean,        clusterClickListener: (SomeCluster<Item>) -> Boolean,        generateClusterItemIconFun: ((Item, Boolean) -> Bitmap)?    ): (Item?) -> Unit {        val clusterManager = ClusterManager<SomeClusterItemImpl<Item>>(context, map)            .apply {                setOnClusterItemClickListener {                    clusterItemClickListener(it.someClusterItem)                }                setOnClusterClickListener { cluster ->                    val position = Location(cluster.position.latitude, cluster.position.longitude)                    val items: List<Item> = cluster.items.map { it.someClusterItem }                    val someCluster: SomeCluster<Item> = SomeCluster(position, items)                    clusterClickListener(someCluster)                }            }        map.setOnCameraIdleListener(clusterManager)        map.setOnMarkerClickListener(clusterManager)        val renderer =            object :                DefaultClusterRenderer<SomeClusterItemImpl<Item>>(context, map, clusterManager),                SelectableMarkerRenderer<SomeClusterItemImpl<Item>> {                override val pinBitmapDescriptorsCache = mutableMapOf<Int, Bitmap>()                override var selectedItem: SomeClusterItemImpl<Item>? = null                override fun onBeforeClusterItemRendered(                    item: SomeClusterItemImpl<Item>,                    markerOptions: MarkerOptions                ) {                    val icon = generateClusterItemIconFun                        ?.invoke(item.someClusterItem, item == selectedItem)                        ?: getVectorResourceAsBitmap(                            item.someClusterItem.getDrawableResourceId(item == selectedItem)                        )                    markerOptions                        .icon(BitmapDescriptorFactory.fromBitmap(icon))                        .zIndex(1.0f) // to hide cluster pin under the office pin                }                override fun getColor(clusterSize: Int): Int {                    return context.resources.color(R.color.primary)                }                override fun selectItem(item: SomeClusterItemImpl<Item>?) {                    selectedItem?.let {                        val icon = generateClusterItemIconFun                            ?.invoke(it.someClusterItem, false)                            ?: getVectorResourceAsBitmap(                                it.someClusterItem.getDrawableResourceId(false)                            )                        getMarker(it)?.setIcon(BitmapDescriptorFactory.fromBitmap(icon))                    }                    selectedItem = item                    item?.let {                        val icon = generateClusterItemIconFun                            ?.invoke(it.someClusterItem, true)                            ?: getVectorResourceAsBitmap(                                it.someClusterItem.getDrawableResourceId(true)                            )                        getMarker(it)?.setIcon(BitmapDescriptorFactory.fromBitmap(icon))                    }                }                override fun getVectorResourceAsBitmap(@DrawableRes vectorResourceId: Int): Bitmap {                    return pinBitmapDescriptorsCache[vectorResourceId]                        ?: context.resources.generateBitmapFromVectorResource(vectorResourceId)                            .also { pinBitmapDescriptorsCache[vectorResourceId] = it }                }            }        clusterManager.renderer = renderer        clusterManager.clearItems()        clusterManager.addItems(markers.map { SomeClusterItemImpl(it) })        clusterManager.cluster()        @Suppress("UnnecessaryVariable")        val pinItemSelectedCallback = fun(item: Item?) {            renderer.selectItem(item?.let { SomeClusterItemImpl(it) })        }        return pinItemSelectedCallback    }}fun Location.toLatLng() = LatLng(latitude, longitude)fun SomeLatLngBounds.toLatLngBounds() = LatLngBounds(southwest?.toLatLng(), northeast?.toLatLng())fun SomeCameraUpdate.toCameraUpdate(): CameraUpdate? {    return if (zoom != null) {        CameraUpdateFactory.newCameraPosition(            CameraPosition.fromLatLngZoom(                location?.toLatLng()                    ?: Location.DEFAULT_LOCATION.toLatLng(),                zoom            )        )    } else if (bounds != null && width != null && height != null && padding != null) {        CameraUpdateFactory.newLatLngBounds(            bounds.toLatLngBounds(),            width,            height,            padding        )    } else {        null    }}

Самое сложное, как уже и говорилось в addMarkers методе. В нём используются ClusterManager и ClusterRenderer, аналогов которых нет в Huawei картах. К тому же, эти классы требуют, чтобы объекты, из которых будут создаваться маркеты для кластеризации реализовывали интерфейс ClusterItem, аналога которому также нет у Huawei. В итоге пришлось изворачиваться и комбинировать наследование с инкапсуляцией. Data классы в проекте будут реализовывать наш интерфейс SomeClusterItem, а гугловый интерфейс ClusterItem будет реализовывать обёртка над классом с данными маркера. Вот такая:

data class SomeClusterItemImpl<T : SomeClusterItem>(    val someClusterItem: T) : ClusterItem, SomeClusterItem {    override fun getSnippet(): String {        return someClusterItem.getSnippet() ?: ""    }    override fun getTitle(): String {        return someClusterItem.getTitle() ?: ""    }    override fun getPosition(): LatLng {        return someClusterItem.getLocation().toLatLng()    }    override fun getLocation(): Location {        return someClusterItem.getLocation()    }}

В итоге, снаружи мы будем использовать библиотеко-независимый интерфейс, а внутри карт для гугла будем оборачивать его экземпляры в класс, реализующий ClusterItem из гугловой библиотеки. Подробнее смотрите реализацию addMarkers выше.

Чтобы всё это работало, осталось только вот эти классы добавить:

class SomeLatLngBoundsImpl(bounds: LatLngBounds? = null) :    SomeLatLngBounds(bounds?.southwest?.toLocation(), bounds?.northeast?.toLocation()) {    override fun forLocations(locations: List<Location>): SomeLatLngBounds {        val bounds = LatLngBounds.builder()            .apply { locations.map { it.toLatLng() }.forEach { include(it) } }            .build()        return SomeLatLngBoundsImpl(bounds)    }}fun LatLng.toLocation(): Location {    return Location(latitude, longitude)}

class MarkerImpl(private val marker: Marker?) : SomeMarker() {    override fun remove() {        marker?.remove()    }}

С реализацией для Huawei будет проще не надо возиться с оборачиванием SomeClusterItem. Вот все классы, которые надо положить в src/huawei/kotlin/com/example:

Реализация SomeMap:

class SomeMapImpl(val map: HuaweiMap) : SomeMap() {    override fun setUiSettings(        isMapToolbarEnabled: Boolean?,        isCompassEnabled: Boolean?,        isRotateGesturesEnabled: Boolean?,        isMyLocationButtonEnabled: Boolean?,        isZoomControlsEnabled: Boolean?    ) {        map.uiSettings.apply {            isMapToolbarEnabled?.let {                this.isMapToolbarEnabled = isMapToolbarEnabled            }            isCompassEnabled?.let {                this.isCompassEnabled = isCompassEnabled            }            isRotateGesturesEnabled?.let {                this.isRotateGesturesEnabled = isRotateGesturesEnabled            }            isMyLocationButtonEnabled?.let {                this.isMyLocationButtonEnabled = isMyLocationButtonEnabled            }            isZoomControlsEnabled?.let {                this.isZoomControlsEnabled = isZoomControlsEnabled            }            setAllGesturesEnabled(true)        }    }    override fun animateCamera(someCameraUpdate: SomeCameraUpdate) {        someCameraUpdate.toCameraUpdate()?.let { map.animateCamera(it) }    }    override fun moveCamera(someCameraUpdate: SomeCameraUpdate) {        someCameraUpdate.toCameraUpdate()?.let { map.moveCamera(it) }    }    override fun setOnCameraIdleListener(function: () -> Unit) {        map.setOnCameraIdleListener { function() }    }    override fun setOnMarkerClickListener(function: (SomeMarker) -> Boolean) {        map.setOnMarkerClickListener { function(MarkerImpl(it)) }    }    override fun setOnMapClickListener(function: () -> Unit) {        map.setOnMapClickListener { function() }    }    override fun setOnCameraMoveStartedListener(onCameraMoveStartedListener: (Int) -> Unit) {        map.setOnCameraMoveStartedListener { onCameraMoveStartedListener(it) }    }    override fun addMarker(markerOptions: SomeMarkerOptions): SomeMarker {        return MarkerImpl(            map.addMarker(                MarkerOptions()                    .position(markerOptions.position.toLatLng())                    .icon(BitmapDescriptorFactory.fromBitmap(markerOptions.icon))            )        )    }    override fun setPadding(left: Int, top: Int, right: Int, bottom: Int) {        map.setPadding(left, top, right, bottom)    }    override fun setOnCameraMoveListener(function: () -> Unit) {        map.setOnCameraMoveListener { function() }    }    override fun <Item : SomeClusterItem> addMarkers(        context: Context,        markers: List<Item>,        clusterItemClickListener: (Item) -> Boolean,        clusterClickListener: (SomeCluster<Item>) -> Boolean,        generateClusterItemIconFun: ((Item, Boolean) -> Bitmap)?    ): (Item?) -> Unit {        val addedMarkers = mutableListOf<Pair<Item, Marker>>()        val selectableMarkerRenderer = object : SelectableMarkerRenderer<Item> {            override val pinBitmapDescriptorsCache = mutableMapOf<Int, Bitmap>()            override var selectedItem: Item? = null            override fun selectItem(item: Item?) {                selectedItem?.let {                    val icon = generateClusterItemIconFun                        ?.invoke(it, false)                        ?: getVectorResourceAsBitmap(it.getDrawableResourceId(false))                    getMarker(it)?.setIcon(BitmapDescriptorFactory.fromBitmap(icon))                }                selectedItem = item                item?.let {                    val icon = generateClusterItemIconFun                        ?.invoke(it, true)                        ?: getVectorResourceAsBitmap(                            it.getDrawableResourceId(true)                        )                    getMarker(it)?.setIcon(BitmapDescriptorFactory.fromBitmap(icon))                }            }            private fun getMarker(item: Item): Marker? {                return addedMarkers.firstOrNull { it.first == item }?.second            }            override fun getVectorResourceAsBitmap(@DrawableRes vectorResourceId: Int): Bitmap {                return pinBitmapDescriptorsCache[vectorResourceId]                    ?: context.resources.generateBitmapFromVectorResource(vectorResourceId)                        .also { pinBitmapDescriptorsCache[vectorResourceId] = it }            }        }        addedMarkers += markers.map {            val selected = selectableMarkerRenderer.selectedItem == it            val icon = generateClusterItemIconFun                ?.invoke(it, selected)                ?: selectableMarkerRenderer.getVectorResourceAsBitmap(it.getDrawableResourceId(selected))            val markerOptions = MarkerOptions()                .position(it.getLocation().toLatLng())                .icon(BitmapDescriptorFactory.fromBitmap(icon))                .clusterable(true)            val marker = map.addMarker(markerOptions)            it to marker        }        map.setMarkersClustering(true)        map.setOnMarkerClickListener { clickedMarker ->            val clickedItem = addedMarkers.firstOrNull { it.second == clickedMarker }?.first            clickedItem?.let { clusterItemClickListener(it) } ?: false        }        return selectableMarkerRenderer::selectItem    }}fun Location.toLatLng() = LatLng(latitude, longitude)fun SomeLatLngBounds.toLatLngBounds() = LatLngBounds(southwest?.toLatLng(), northeast?.toLatLng())fun SomeCameraUpdate.toCameraUpdate(): CameraUpdate? {    return if (zoom != null) {        CameraUpdateFactory.newCameraPosition(            CameraPosition.fromLatLngZoom(                location?.toLatLng()                    ?: Location.DEFAULT_LOCATION.toLatLng(),                zoom            )        )    } else if (bounds != null && width != null && height != null && padding != null) {        CameraUpdateFactory.newLatLngBounds(            bounds.toLatLngBounds(),            width,            height,            padding        )    } else {        null    }}

class SomeLatLngBoundsImpl(bounds: LatLngBounds? = null) :    SomeLatLngBounds(bounds?.southwest?.toLocation(), bounds?.northeast?.toLocation()) {    override fun forLocations(locations: List<Location>): SomeLatLngBounds {        val bounds = LatLngBounds.builder()            .apply { locations.map { it.toLatLng() }.forEach { include(it) } }            .build()        return SomeLatLngBoundsImpl(bounds)    }}fun LatLng.toLocation(): Location {    return Location(latitude, longitude)}

class MarkerImpl(private val marker: Marker?) : SomeMarker() {    override fun remove() {        marker?.remove()    }}

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

Используем нашу абстрактную карту

Итак, в разметку мы добавляем MapViewImpl, как было показано выше и переходим к коду. Для начала нам надо из нашей MapView получить объект карты:

mapView.getMapAsync { onMapReady(it) }

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

private fun onMapReady(map: SomeMap) {    map.setUiSettings(isMapToolbarEnabled = false, isCompassEnabled = false)    var pinItemSelected: ((MarkerItem?) -> Unit)? = null    fun onMarkerSelected(selectedMarkerItem: MarkerItem?) {        pinItemSelected?.invoke(selectedMarkerItem)        selectedMarkerItem?.let {            map.animateCamera(SomeCameraUpdate(it.getLocation(), DEFAULT_ZOOM))            Snackbar.make(root, "Marker selected: ${it.markerTitle}", Snackbar.LENGTH_SHORT).show()        }    }    with(map) {        setOnMapClickListener {            onMarkerSelected(null)        }        setOnCameraMoveStartedListener { reason ->            if (reason == SomeMap.REASON_GESTURE) {                onMarkerSelected(null)            }        }    }    locationGateway.requestLastLocation()        .flatMap { mapMarkersGateway.getMapMarkers(it) }        .subscribeBy { itemList ->            pinItemSelected = map.addMarkers(                requireContext(),                itemList.map { it },                {                    onMarkerSelected(it)                    true                },                { someCluster ->                    mapView?.let { mapViewRef ->                        val bounds = SomeLatLngBoundsImpl()                            .forLocations(someCluster.items.map { it.getLocation() })                        val someCameraUpdate = SomeCameraUpdate(                            bounds = bounds,                            width = mapViewRef.width,                            height = mapViewRef.height,                            padding = 32.dp()                        )                        map.animateCamera(someCameraUpdate)                    }                    onMarkerSelected(null)                    true                }            )        }}

Часть кода, понятно, опущена для краткости. Полный пример вы можете найти на GitHub: https://github.com/MobileUpLLC/huawei_and_google_services.

А вот как выглядят карты разных реализаций (сначала Huawei, потом Google):

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

Заключение

Рынок мобильных приложений меняется. Ещё вчера казавшиеся незыблемыми монополии Google и Apple наконец-то замечены не только пострадавшими от них разработчиками (из самых известных последних Telegram, Microsoft, Epic Games) но и государственными структурами уровня EC и США. Надеюсь, на этом фоне наконец-то появится здоровая конкурентная среда хотя бы на Android. Работа Huawei в этой области радует видно, что люди стараются максимально упростить жизнь разработчикам. После опыта общения с тех. поддержкой GooglePlay, где тебе отвечают роботы в основном (и они же и банят) в Huawei тебе отвечают люди. Мало того когда у меня возник вопрос по их магазину приложений у меня была возможность просто взять и позвонить живому человеку из Москвы и быстро решить проблему.

В общем, если вы хотите расширить свою аудиторию и получить качественную тех.поддержку в процессе идите в Huawei. Чем больше там будет разработчиков, тем выше шанс, что и в GooglePlay что-то поменяется в лучшую сторону. И выиграют все.

Весь код, который есть в этом цикле статей вы можете посмотреть в репозитории на GitHub. Вот ссылка: https://github.com/MobileUpLLC/huawei_and_google_services.

Проблема с загрузкой Spring Boot Jar

Сталкивались ли вы с проблемой запуска нового загрузочного архива Spring Boot?

Вообще, новация в этом направлении уже не первая, стандартов особых нет. Поэтому многие огребают проблемы и решают их на форумах и стек-оверфлоу.
Если вы также столкнулись с проблемой, я помогу её решить. В таком случае читаем дальше.

Итак, проблем с BootJar на самом деле хватает. Особенно учитывая, что уже минимум три версии формата поменялось.

Здесь я расскажу о часто встречающемся случае с потерей ресурсов. Конкретнее в моём случае с потерей JSP шаблонов. Почему JSP? Мне так привычнее, проект я по-быстрому начал с них, и не думал, что будут такие проблемы.

Итак структура проекта (стандартный веб):

/src/main/    java/    resources/        static/            some.html        public/    webapp/        WEB-INF/jsp            index.jsp

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

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

Итак, дубль раз. Чуть ли не в первый раз запускаю задачу BootJar. Ярхив готов, деплоим Готово! Сигнала нет, сыпет ошибки 302 + 404 (это авторизация не находит вью). Но это пока не понятно.
Отключаем Секурити всё равно ничего не находит, кроме голимой статики, и то не всей, а только из webjars. ???

Дубль два. Догадываясь о несовместимости jsp и BootJar, пакуем BootWar. Деплоим Не работает. Не помню точно, но примерно то же самое в результате.

Хм, странно. Запускаем BootJar локально всё работает. Чудеса.

Выяснилось: Spring Boot слишком умный, он при запуске из каталога разработки даже релизного ярника всё равно все тащит из каталога разработки. Из другого запускаем перестаёт работать. Фух! Ну хоть отлаживать можно.

Что и делам. Выясняется ресурсы BootJar запакованные не из библиотек (webjars), а из проекта, не включаются в перечисление, и это, оказывается, по дизайну! Подробности здесь.

Вернее не так есть спец-ресурсы в каталогах типа static/, public/. И они вроде находятся, если объявить. Но jsp не видит в упор хоть тресни. И дело не в том, что не там лежат. Оказалось, что Томкат (в нашем плохом случае), грузит jsp особым механизмом после редиректа. И сами jsp можно загрузить без рендеринга, если правильно задать их положение в настройках
spring.resources.static-locations

Но это нас не устраивает.
Оказалось, что при использования встроенного томката, ресурсы вью он грузит отдельно и в первую очередь своей старой встроенной логикой, которую Спрингисты настраивать не научились. А этой логике нужен либо архив Вар, либо он же распакованный (почему кстати при разработке нормально отрабатывает расположение webapp/), либо ресурсы из библиотек, которые прекрасно видны, если правильно упакованы в изначальных либах нужно чтоб лежали в META-INF/resources, как в стандарте сервлетов. Последнее работает даже внутри BootJar. Удивительно.

Почему не сработал распакованный архив? Ё-маё, на амазоне он распакуется черти-куда, и приложение про это место ничего не знает, если не сказать. Но хардкодить пути плохая привычка. Сам ярник запускается затем безо всякой распаковки, хотя вроде права позволяют распаковать прям на месте. Ну да ладно, способ пролетел.

Почему не работает способ с Вар-архивом? Ё-маё, Амазон решил, что лучше меня знает, что я буду грузить именно в яр-формате, хотя интерфейс заявлет о готовности съесть варник. Он этот варник переименовывает в ярник, умник такой. А Томкат не умничает, он смотрит расширение: не Вар ну тогда, извините, это не мой случай.

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

Ладно, проблема понятна. Решение?

Было три варианта.

1. Сделать свой spring-загрузчик ресурсов. Вариант отпал, поскольку, как я уже сказал, Томкат отрабатывает jsp до их запуска.
2. Прокинуть загрузку в Томкат. Стал прикидывать: надо расширить контекст spring-а, прокинуть пути в контекст Томката, там ещё раза два переложить непонятно, насколько сложно, и можно ли без изменения самого томката. Спрингисты не осилили, и я не хочу.
3. Вариант попроще пакуем ресурсы в ресурсную либу в BootJar.

Вот о нём подробнее. Пихать всё в отдельный модуль, как предлагали здесь, не хотелось.
Делаем отдельной задачей в Gradle.
Создаём конфигурацию.

sourceSets {    jsp {        resources.source(sourceSets.main.resources);        resources.srcDirs += ['src/main/webapp'];    }    jmh {        .. ..    }}

Сама задача

task jsp(type: Jar, description: 'JSP Packaging') {    archiveBaseName = 'jsp'    group = "build"    def art = sourceSets.jsp.output    from(art) {        exclude('META-INF')        into('META-INF/resources/')    }    from(art) {        include('META-INF/*')        into('/')    }    dependsOn(processJspResources)}

Задача processJspResources уже создана, её не надо делать. Ставим всё в зависимость и пакуем:

bootJar {    dependsOn(jsp)    bootInf.with {        from(jsp.archiveFile) {            include('**/*.jar')        }        into('lib/')    }}

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

artifacts {    jspImplementation jsp}

Всё, теперь имеем ресурсную либу, которую по всем стандартам томкат должен грузить, и он грузит. Запускаем, как BootJar.

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

Его появлению предшествовало 15 лет практики тестирования в компании IBS AppLine* (лидера российского рынка аутсорсинга услуг тестирования по версии TAdviser за 2018 год на минуточку!). На базе этих знаний и экспертизы мы задались целью ускорить старт проектов, повысить качество тестирования, упростить введение в работу новичков. Решение должно позволить автоматизировать функциональное тестирование веб, мобильных, десктоп-приложений и различных видов API.

В общем, исследовательский центр IBS AppLine Innovation** суммировал весь опыт компании и создал Хамелеон инструмент для автоматизации функционального тестирования. Делался с использованием языка программирования Java и инструментов Cucucmber, Selenium, Appium, Winium, Spring. Этот фреймворк:

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

Теперь подробнее о функционале

Как устроен Хамелеон

Вот несколько особенностей нашего фреймворка:

• Это многомодульный maven-проект, который включает модули тестирования web, мобильных приложений, SAP-приложений, баз данных, Rest API и web-сервисов. Необходимые модули подключаются к проекту.
• Мы взяли проверенные временем оpen source-инструменты, в том числе Selenium, Appium, Winium, и удачно их объединили в одном решении.
• Для ускорения разработки автоматизированных тестов мы создали плагин для среды разработки IntelliJ IDEA. Получился полезный инструмент разработчика автоматизированных тестов. Плагин дополняет возможности IDEA, делая ее полноценным рабочим местом.
• Для удобства разработки автоматизированных тестов для web-приложений мы создали расширение для браузера Google Chrome, которое позволяет добавлять элементы тестируемого приложения в проект прямо из браузера и имеет возможность записи автоматизированного теста в формате Cucumber методом Record&Playback.

Open source-библиотеки

В основе инструмента лежат оpen source-библиотеки Selenium, Appium, Winium, UIAutomation. Для разработки самих тестов используется фреймворк Cucumber, который позволяет писать на русском языке. Такой формат понятен и ручным тестировщикам, и не имеющим отношения к написанию конкретного теста специалистам автоматического тестирования, что снижает порог вхождения сотрудников в проект. Всему, что происходит в Cucumber, соответствуют свои Java-команды, так что при необходимости тесты можно разрабатывать на чистой Java.

Простота установки

Для разработки автоматизированных тестов с использованием Java на рабочую станцию устанавливаются Java JDK, Apache Maven/Gradle, IntelliJ IDEA, плагины для Intellij IDEA, Git Client. У начинающих специалистов это занимает много времени. Мы упростили процесс, разработав общий инсталлятор, который представляет собой .exe-файл с возможностью выбора необходимого ПО для установки на рабочее место:

Начало разработки

Для разработки автоматизированных тестов можно использовать готовые стартеры проектов. Стартеры это архетипы maven, которые содержат готовую структуру проекта. Они хранятся во внутреннем репозитории компании. При создании проекта в IntelliJ IDEA нужно лишь выбрать необходимые. Например, для разработки тестов, которые взаимодействуют с web-приложением и REST, необходимо подключить модули chameleon-selenium-cucumber и chameleon-rest-cucumber.

Немного о фреймворке

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

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

Пример автоматизированного теста:

# language: ru# Тестовые данные:  # $ФИО Иванов Иван Иванович  # $ссылка https://www.appline.ru/Функция: Заявка на обучение  Сценарий: Заявка на обучение    * страница "Главная" загружена    * выбран элемент коллекции "Меню" с параметрами:      | field        | operator | value             |      | Наименование | равно    | Start IBS AppLine |    * нажатием на кнопку "Наименование" загружена страница "Start IBS AppLine"    * поле "Имя" заполняется значением "#{ФИО}"    * поле "Ссылка на резюме" заполняется значением "#{ссылка}"    * выполнено нажатие на "Отправить"    * поле "Required field" видимо

Существуют шаблоны для работы с переменными: операции с датами, математические операции, выполнение кода и т.д. Например, для работы с текущей датой используется шаблон #now{дата; исходный_формат; смещение}. Предположим, в автоматизированном тесте необходимо проверить дату операции, которая была только что осуществлена. Такая проверка будет выглядеть так:

* значение поля "Дата операции" равно "#now{dd.MM.yyyy HH:mm}"

А, например, создать отложенную операцию, которая исполнится завтра:

* поле "Дата операции" заполняется значением "#now{dd.MM.yyyy;+1d}}"

Выполнить программный код можно с использованием шаблона #script{RESULT=выражение_java}. Например, удаление лишних символов в переменной будет выглядеть следующим образом:

* в переменной "Номер_счета" сохранено значение поля "Номер счета"* значение поля "Номер счета" равно "#script{RESULT = Номер_счета.replaceAll("", "")}"

В нашем фреймворке разработаны основные Cucumber-шаги, которые напоминают шаги из ручных тестовых сценариев. Они описывают действия, которые человек может совершить с тестируемым приложением: нажать на элемент, ввести значение в поле, прочитать значение, сравнить значения и т.д. Таких шагов примерно 30. Для часто повторяемых операций такие шаги объединяются в более крупный шаг.

Например, авторизация в приложении может описываться в 3 шага:

Когда заполняются поля:  | field  | value        |  | Логин  | test@test.ru |  | Пароль | 123123       |И выполнено нажатие на "Войти"Тогда страница "Главная" загружена

Или на основе этих шагов создается 1 шаг (пароль в этом случае хранится в отдельном файле с пользователями):

Дано авторизован пользователь "test@test.ru"

Все размеченные элементы тестируемого приложения имеют свой тип, например, Button, TextInput, Combobox, Checkbox и т.д., это позволяет использовать одни и те же Cucumber-шаги для работы с разными типами элементов. Например, есть шаг:

* поле "field" заполяется значением "value"

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

АРМ тестировщика или разработка теста

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

• список тестов,
• объектный репозиторий,
• список доступных действий,
• настройки запуска,
• документацию,
• различные автокомплиты, ускоряющие процесс создания теста.

Список тестов

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

Репозиторий объектов

Традиционный и очень популярный инструмент разработчика автоматизированных тестов шаблон Page Object Pattern. При его использовании элементы тестируемого приложения описываются в отдельных java-классах, которые соответствуют страницам тестируемого приложения. На крупных проектах таких Page Object-классов становится очень много. Кроме того, иногда они еще и называются беспорядочно. В результате для больших проектов такой подход не очень удобен: неизбежно дублирование работы на проектах работает много специалистов, приходится расшифровывать работу коллег и анализировать разметку элементов, а это не всегда проходит гладко.

Поэтому мы создали репозиторий объектов тестируемого приложения. Он хранит все его элементы не в классах, а в одном или нескольких xml-файлах, а плагин для IntelliJ Idea показывает эти xml-файлы в виде древовидной структуры, в которой узлами являются страницы тестируемого приложения. Вместо разномастных английских названий мы используем русский язык, что упрощает работу тестировщиков, так им легче находить размеченные страницы и элементы, а также добавлять новые.

Приведем конкретный пример. Для одного крупнейшего отечественного банка (название по понятным причинам не называем) нами было разработано 20 автотестов, использовавших 78 страниц тестируемых приложений (достаточно длинный бизнес-процесс). В обычных условиях тестировщикам пришлось бы создать 78 java-классов и разметить на них более 2000 элементов. С Хамелеоном мы всю эту громаду открываем в древовидной структуре, в которой их легко и просто просматривать, перетаскивать, компоновать.

Существует два способа добавления элементов в репозиторий.

Добавление в среде разработки IntelliJ IDEA:

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

Также есть возможность добавлять элементы прямо из тестируемого приложения с помощью созданного нами расширения для браузера Google Chrome. Расширение самостоятельно определяет тип элемента, его наименование и подставляет локатор. Для этого достаточно навести мышкой на элемент. Расширение синхронизируется с плагином в IntelliJ IDEA, поэтому все, что происходит в браузере, передается в среду разработки. Так можно наполнять репозиторий объектов, проходя ручной тест в браузере. С помощью расширения можно проверить корректность локатора уже существующего в репозитории элемента.

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

Разработка автоматизированного теста

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

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

При этом доступны подсказки не только для списка возможных шагов, но и для элементов, которые могут участвовать в выбранном действии. Плагин определяет страницу (контекст) и предлагает элементы из репозитория объектов или переменные для сucumber-шага, которые относятся к выбранной странице. Это исключает возможность ошибки при использовании еще не размеченного элемента страницы и ускоряет процесс разработки теста.

Второй способ разработки автоматизированного теста использование репозитория шагов. В плагине в древовидной структуре показываются шаги, которые можно перетащить методом Drag&Drop, как показано ниже. При использовании такого варианта создания автоматизированного теста тоже присутствуют подсказки элементов и переменных. Таким вариантом обычно пользуются начинающие сотрудники, которым проще искать необходимые шаги в репозитории, а не java-классах.

Третий способ разработки автотеста (самый удобный и популярный) с помощью нашего расширения для браузера Google Chrome. Плагин записывает действия пользователя на странице тестируемого приложения и конвертирует их в автоматизированный тест.

Например, пользователь логинится на сайте, нажимая для этого на кнопку Логин. Рекордер записывает шаг * выполнено нажатие на поле Логин. Пользователь заполняет поле Логин значением User, рекордер записывает шаг * поле Логин заполняется значением User и так далее. После этого получившийся автотест можно скопировать и вставить в среду разработки для редактирования. Плагин автоматически, на основе объектного репозитория, определяет, на какой странице находится пользователь, и выполняет поиск размеченных элементов. Если элемента в репозитории нет, то будет предложено его добавить.

Пока рекордер существует только для браузера. В процессе разработки находится рекордер для SAP GUI.

Запуск и отладка

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

• подсветку элементов будут выделяться элементы, с которыми взаимодействует тест;
• запись видео в случае ошибки к отчету будет прикреплено видео прохождения автоматизированного теста;
• конфигурацию запуска браузер, в котором будет выполнен тест;
• режим запуска с графическим интерфейсом или headless-режиме (без графического интерфейса);
• закрытие браузера после теста удобно при разработке длинных тестов или локализации ошибок;
• подключение к открытому браузеру чтобы начать автоматизированный тест не с начала, а с выбранного места, подключаясь к открытому браузеру.

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

Чтобы отслеживать ход выполнения теста, мы разработали консоль, куда перенаправляется весь лог с IntelliJ IDEA. Это позволяет контролировать процесс и понимать, что сейчас выполняет автоматизированный тест. Консоль отображается поверх содержимого экрана и не мешает выполнению теста. Есть возможность настраивать формат вывода в консоль (размер, шрифт, цвет и т.д.).

Документация

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

Тестирование API

Для тестирования API (REST и SOAP) также используется объектный репозиторий. В этом случае страницами будут endpoint, а элементами заголовки и тело запроса.

Во фреймворке реализованы базовые действия с API, при наборе действий происходит автоподстановка параметров вызова.

Отчет о выполнении автоматизированных тестов

В качестве инструмента отчетности был выбран Allure. При запуске тестов из среды разработки IntelliJ IDEA аllure-отчет можно открыть прямо из плагина.

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

Результаты

Хамелеон помог нам не на словах, а на деле.

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

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

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

Наконец, мы получили еще одно преимущество на отечественном рынке: кодирование на русском языке легче освоить. Для этого у нас есть корпоративный университет, где мы обучаем будущих тестировщиков писать автотесты с нуля буквально за месяц. И в этом очень важную роль играет Хамелеон: с его помощью мы закладываем общую базу, на нем обязательно проводим несколько занятий по разработке тестов. Ежемесячно через этот курс проходит 5-10 человек, имеющих базовые знания языка программирования Java.

Планы на будущее

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

* IBS AppLine лидер российского рынка услуг тестирования и обеспечения качества программного обеспечения, разработчик решений для автоматизации тестирования. Компания была создана в 2001 году, в штате более 700 специалистов, общее количество проектов превысило 1500.

** IBS AppLine Innovation (ранее Аплана АйТи Инновации) была создана в декабре 2017 года как центр исследований и разработки компании IBS AppLine (ранее Аплана). Основу команды составили ее собственные опытные инженеры и разработчики.

Всем привет! Я пишу приложения под Android, в мире которого система сборки Gradle является стандартом де-факто. Я решил поделиться некоторыми советами по работе с Gradle с теми, у кого нет чёткого понимания, как правильно структурировать свои проекты и писать build-скрипты.

Часто разработчики используют Gradle по наитию и не изучают целенаправленно, потому что не всегда хватает ресурсов на инфраструктурные задачи. А если возникают какие-либо проблемы, то просто копируют готовые куски build-скриптов из ответов на Stack Overflow. Во многом проблема кроется в сложности и чрезмерной гибкости Gradle, а также в отсутствии описания лучших практик в официальной документации.

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

Небольшой оффтоп для тех, кому совсем ничего не понятно в Gradle-скриптах

Я заметил, что в Android-сообществе встречаются люди, которые могут годами разрабатывать приложения, но при этом не понимать, как работает Gradle. И достаточно продолжительное время и я был одним из них. Но однажды всё же решил, что гораздо проще потратить время на системное изучение Gradle, чем постоянно натыкаться на непонятные проблемы.

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

Теперь к советам.

#1 Не редактируйте Gradle-скрипты через IDE

Android studio умеет генерировать стартовый проект с базовой структурой и готовыми build-скриптами, а также удалять и добавлять модули в существующем проекте. А при редактировании Gradle-скриптов IDE нам заботливо подсказывает, что можно вносить изменения в скрипты через графический интерфейс в меню "File -> Project structure...". И в начале своей карьеры я вполне успешно пользовался этим инструментом. Но у него есть существенный недостаток: IDE не запускает честную фазу конфигурации Gradle и не смотрит на то, что формируется в памяти при сборке, а всего лишь пытается как-то парсить build-скрипты. Зачастую этот инструмент не распознает то, что было написано вручную, что, на мой взгляд, перечеркивает его пользу.

Мой совет: лучше не редактировать скрипты через IDE, а использовать редактор кода.

#2 Обращайте внимание на соглашение по именованию модулей

В Gradle имя проекта (модуля) берется из соответствующего поля name в объекте Project или названия директории, в которой он лежит. В своей практике я видел разные стили именования модулей, например, в camel- или snake- кейсе: MyAwesomeModule, my_awesome_module. Но есть ли какие-то устоявшиеся соглашения об именах модулей? Кажется, официальная документация Gradle ничего нам об этом не говорит. Но нужно принять во внимание тот факт, что проекты Gradle при публикации в Maven будут соответствовать один к одному модулям Maven. И у Maven есть соглашение, что слова в названиях модулей должны разделяться через символ -. То есть правильнее будет такое название модуля: my-awesome-module.

#3 Что выбрать: Kotlin vs Groovy

Изначально в Gradle для DSL использовался язык Groovy, но впоследствии была добавлена возможность писать build-скрипты на Kotlin. Возникает вопрос: что же сейчас использовать? И однозначного ответа на него пока что нет.

Лично я за использование Kotlin, так как не очень хочу только лишь ради build-системы изучать ещё один язык Groovy. Наверно, для всего Android сообщества DSL на Kotlin существенно понижает порог вхождения в Gradle. Кроме того, у build-скриптов на Kotlin лучше поддержка в IDE с автокомплитом, но, тем не менее, она все еще далека от идеала.

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

Если у вас старый большой проект с build-скриптами на Groovy, то могу посоветовать частично попробовать какие-то скрипты перевести на Kotlin, если вам понравится, то можно будет постепенно делать рефакторинг и переписывать все скрипты на Kotlin, не обязательно делать это единовременно.

#4 Как прописывать зависимости в многомодульных проектах

Возьмем небольшой пример проекта со следующей структурой:

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

В чем проблема такого проекта? Здесь будет тяжело глобально обновлять зависимости в каждом из файлов. Очень легко забыть поднять версию в одном из скриптов, и тогда возникнут конфликты. По умолчанию Gradle умеет разрешать такие конфликты, выбирая максимальную версию, так что, скорее всего, сборка будет успешной (поведение можно менять через resolution strategy).

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

Java platform plugin

Разработчики Gradle предлагают для описания зависимостей создать отдельный специальный модуль, где будут описаны только зависимости с конкретными версиями. К этому модулю надо применить java platform plugin. Далее подключаем этот модуль в остальные модули и при указании каких-то внешних зависимостей не пишем конкретную версию:

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

Перейду к общепринятым в сообществе способам описания зависимостей.

Описание зависимостей в extra properties

Достаточно часто можно увидеть практику, когда строки с зависимостями хранят в extra properties корневого проекта, по сути это словарь, доступный всем дочерним модулям. Пример использования можно встретить в некоторых библиотеках от Google.

В корневом проекте описываем зависимости. Вот кусок build-скрипта из библиотеки Google, где зависимость возвращается функцией compatibility:

ext {    compileSdkVersion = 29    minSdkVersion = 14    targetSdkVersion = 29    androidXVersions = [            annotation: '1.0.1',            appCompat: '1.1.0'      // ...    ]}/** * Return the module dependency for the given compatibility library name. */def compatibility(name) {  switch (name) {    case "annotation":      return "androidx.annotation:annotation:${androidXVersions.annotation}"    case "appcompat":      return "androidx.appcompat:appcompat:${androidXVersions.appCompat}"

И обращаемся к ним из дочерних модулей:

dependencies {    api compatibility("annotation")    api compatibility("appcompat")    api compatibility("cardview")    api compatibility("coordinatorlayout")    api compatibility("constraintlayout")    api compatibility("core")    api compatibility("dynamicanimation")    // ...}

Описание зависимостей в скриптовом плагине

Описанный способ с extra properties можно немного модифицировать и вынести описание зависимостей в скриптовый плагин, чтобы не засорять корневой проект. А уже скриптовый плагин можно применить или к корневому, или ко всем дочерним проектам сразу (через allprojects {}), или к отдельным. Такой способ я тоже встречал.

Описание зависимостей в buildSrc

В buildSrc можно писать любой код, который будет компилироваться и добавляться в classpath build-скриптов. В последнее время стало популярно использовать buildSrc для описания там зависимостей. Например, в библиотеке Insetter Chris Banes так и делает.

Все, что нужно, это добавить синглтон со строками в buildSrc, и он станет виден всем модулям в проекте:

object Versions {    const val minSdk = 23    const val compileSdk = 29    const val kotlin = "1.4.20"    const val kotlinCoroutines = "1.4.0"    const val okHttp = "4.9.0"    const val retrofit = "2.9.0"    const val moshi = "1.11.0"}object Dependencies {    object Kotlin {        const val stdlib = "org.jetbrains.kotlin:kotlin-stdlib:${Versions.kotlin}"        const val reflect = org.jetbrains.kotlin:kotlin-reflect:${Versions.kotlin}"    }    object Google {        const val materialComponents = "com.google.android.material:material:1.2.1"        const val googleAuth = "com.google.android.gms:play-services-auth:18.1.0"        const val location = "com.google.android.gms:play-services-location:17.1.0"        const val tasks = "com.google.android.gms:play-services-tasks:17.2.0"    }}

Использовать buildSrc для зависимостей очень удобно, так как будут статические проверки и автокомплит в IDE:

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

Композитные сборки

Можно достичь похожего результата со статическими проверками и автокомплитом, используя композитные сборки, при этом избавившись от проблемы инвалидации всего кэша. Я расскажу про него лишь кратко, а подробный гайд по миграции с buildSrc можно прочитать в статье из блога Badoo или статье от Josef Raska.

В композитных сборках мы создаем так называемые включенные сборки (included build), в которых можно писать плагины и подключать их в своих модулях. Включенные сборки описываются в файле settings.gradle.

Если мы хотим всего лишь подсунуть в classpath build-скриптов строки с зависимостями, то достаточно создать пустой плагин, а рядом с ним положить тот же файл с зависимостями, который мы использовали раньше в buildSrc:

// Build скрипт включенной сборки// ./dependencies/build.gradle.ktsplugins {    `kotlin-dsl`}repositories {    jcenter()    google()}gradlePlugin {    plugins {        register("dependencies") {            id = "dependencies"            implementationClass = com.rmr.dependencies.DependenciesPlugin        }    }}

// Плагин из включенной сборки// ./dependencies/src/main/kotlin/com/rmr/depenendencies/DependenciesPlugin.ktpackage com.rmr.dependenciesimport org.gradle.api.Pluginimport org.gradle.api.Projectclass DependenciesPlugin : Plugin<Project> {    override fun apply(target: Project) {        // Do nothing, just load dependencies to classpath    }}

Все, что осталось сделать, применить плагин к корневому проекту:

plugins{ id("dependencies") }

И мы получим практически тот же результат, как и с использованием buildSrc.

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

#5 Как обновлять зависимости

В любом активном проекте надо постоянно следить за обновлением библиотек. IDE умеет подсвечивать для каждого модуля, описанного в блоке dependencies {}, наличие новых стабильных версий в репозиториях:

Но этот инструмент работает только для зависимостей, описанных строковыми литералами в build-скриптах, а если мы попытаемся использовать способ с композитными сборками, buildSrc или extra properties, то IDE перестанет нам помогать. Кроме того, визуально просматривать build-скрипты в модулях, для того чтобы сделать обновление библиотек, на мой взгляд, не очень удобно.

Но есть решение использовать gradle-versions-plugin. Для этого просто применяем плагин к корневому проекту и регистрируем task для проверки новых версий зависимостей. Этот task надо настроить, передав ему лямбду для определения нестабильных версий:

fun isNonStable(version: String): Boolean {    val stableKeyword = listOf("RELEASE", "FINAL", "GA").any { version.toUpperCase().contains(it) }    val regex = "^[0-9,.v-]+(-r)?$".toRegex()    val isStable = stableKeyword || regex.matches(version)    return isStable.not()}tasks.withType<DependencyUpdatesTask> {    rejectVersionIf {        isNonStable(candidate.version) && !isNonStable(currentVersion)    }}

Теперь запуск команды ./gradlew dependencyUpdates выведет список зависимостей, для которых есть новые версии:

The following dependencies have later milestone versions: - androidx.constraintlayout:constraintlayout [2.0.1 -> 2.0.4]     http://tools.android.com - androidx.core:core-ktx [1.5.0-alpha05 -> 1.5.0-beta03]     https://developer.android.com/jetpack/androidx/releases/core#1.5.0-beta03 - androidx.fragment:fragment-ktx [1.3.0-beta02 -> 1.3.1]     https://developer.android.com/jetpack/androidx/releases/fragment#1.3.1 - androidx.lifecycle:lifecycle-runtime-ktx [2.2.0 -> 2.3.0]     https://developer.android.com/jetpack/androidx/releases/lifecycle#2.3.0 - com.github.ben-manes:gradle-versions-plugin [0.36.0 -> 0.38.0] - com.github.ben-manes.versions:com.github.ben-manes.versions.gradle.plugin [0.36.0 -> 0.38.0] - com.github.bumptech.glide:glide [4.11.0 -> 4.12.0]     https://github.com/bumptech/glide

#6 Старайтесь не использовать feature-флаги в build config

Во многих проектах release, debug и другие сборки отличаются по функциональности. Например, в отладочных сборках могут быть включены какие-то логи, мониторинг сетевого трафика через прокси, debug menu для смены окружений и т.д. И часто для реализации такого используют флаги, прописанные в build config, например:

android {    buildTypes {        getByName("debug") {            buildConfigField("Boolean", "ENABLE_DEBUG_SCREEN", "true")        }        getByName("release") {            buildConfigField("Boolean", "ENABLE_DEBUG_SCREEN", "false")        }    }}

А дальше такие флаги используются в коде приложения:

if (BuildConfig.ENABLE_DEBUG_SCREEN) {} else {}

И у такого решения есть недостатки. Довольно легко перепутать значения флагов и ветки if/else: if(enabled) {} else {} или if(disabled) {} else {}. Именно так однажды, во время рефакторинга, я случайно отправил в релиз то, что должно было включаться только в сборках для QA-отдела (думаю, у многих были похожие истории). Тогда проблему обнаружили оперативно, мы перевыпустили сборку в маркет. Кроме того, недостижимый код может быть скомпилирован и попасть в релиз (здесь я не буду рассуждать о том, что мертвый код может вырезаться из итогового приложения). Ну и многим известно, что любые операторы ветвления лучше заменять полиморфизмом. И в Gradle есть статический полиморфизм.

Вместо флагов можно использовать разные source set для различных build variant ("src/release/java ...", "src/debug/java ..."). А если такой код хочется вынести в отдельные модули, то можно использовать специальные конфигурации: debugImplementation, releaseImplementation и т.д. Тогда мы сможем написать код с одним и тем же интерфейсом, но разной реализацией для различных типов сборок.

Например, мы можем выделить debug menu в отдельный модуль и подключать его только для debug и QA-сборок:

dependencies {    val qaImplementation by configurations    debugImplementation(project(":feature-debug-screen"))    qaImplementation(project(":feature-debug-screen"))}

А stub реализацию для релизной сборки можно реализовать через source set.

#7 Несколько слов про базовую структуру проекта

Совет немного не по теме, но я решил добавить его как часть своего опыта, так как модуляризация напрямую связана с Gradle.

Если для крупных проектов модуляризация кажется вполне очевидным решением, то не совсем понятно, как стоит поступать при старте небольших проектов или когда невозможно предсказать дальнейшее развитие кодовой базы продукта. Нужно ли выделять какие-то модули или достаточно начать с монолита? Я бы, помимо app модуля с основным приложением, всегда выделял как минимум два отдельных модуля:

• UI kit: стили, кастомные элементы управления, виджеты и т.д. Обычно элементы управления на всех экранах приложения делаются консистентно в одном стиле (а возможно, у вас целая дизайн-система), и если в какой-то момент захочется выделить feature-модуль, то он также будет опираться на единый UI kit. Заранее подготовленный модуль с элементами управления и стилями упростит задачу и не потребует значительного рефакторинга приложения.
• Common / utils: все утилитные классы и любые решения, которые не только потребуются в нескольких модулях, но и могут даже копироваться из проекта в проект. Особенно в контексте аутсорса такой модуль будет удобным при старте новых проектов. При вынесении классов в отдельный модуль, а не пакет, можно быть уверенным, что в его коде не окажется каких-либо бизнес сущностей конкретного приложения. Потенциально такой модуль может стать полноценной библиотекой, опубликованной в репозиторий.

#8 Не забывайте про matchingFallbacks

Часто, помимо debug и release, мы создаем и другие типы сборок, например, qa для тестов. И при создании модулей в приложении необязательно их прописывать в каждом build-скрипте. Достаточно при создании своего build type указать в модуле основного приложения те build type, которые следует выбирать при отсутствии каких-то конкретных:

android {    buildTypes {        create("qa") {            setMatchingFallbacks("debug", "release") // если не найдется qa, то искать сначала debug, затем release        }    }}

#9 Убирайте ненужные build variant

Build variant формируются из всех возможных сочетаний product flavor и build type. Возьмем небольшой синтетический пример: создадим три build type debug (отладочная сборка), release (сборка в маркет) и qa (сборка для тестирования), а во flavor вынесем разные сервера, на которые может смотреть сборка, production и staging (тестовое окружение). Возможные build variant будут выглядеть так:

Очевидно, что сборка в маркет, которая будет смотреть на тестовое окружение, совершенно бессмысленна и не нужна (stagingRelease). И чтобы исключить ее, можно добавить variant filter:

android {    variantFilter {        if (name == "stagingRelease") {            setIgnore(true)        }    }}

#10 В некоторых модулях, завязанных на Android Framework, можно не использовать Android Gradle Plugin

Если какой-то из ваших модулей завязан на классы из Android Framework, то вовсе не обязательно сразу применять к нему Android Gradle Plugin и писать там файл манифеста. Модули с AGP более тяжеловесные, чем чистые java/kotlin модули, так как при сборке будут объединяться манифесты, ресурсы и т.д. Когда вам всего лишь требуется для компиляции модуля что-то вроде классов Activity, Context и т.д., то можно просто добавить Android Framework как зависимость:

dependencies {    compileOnly("com.google.android:android:4.1.1.4")}

#11 Как написать Gradle-плагин для CI на примере gitlab

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

Задача сделать так, чтобы в сборках на CI versionCode ставился автоматически и представлял из себя последовательные номера 1, 2, 3 и т.д. Я встречал в своей практике, когда в качестве versionCode брался CI job id или каким-то образом использовался timestamp. В таких случаях versionCode с каждой новой версией повышался и был уникальным, но семантически такие версии выглядели достаточно странно.

Основная идея проста нужно хранить номер будущего релиза где-то во внешнем источнике, куда имеет доступ только сборка, выполняемая на CI. А после каждой успешной публикации нужно инкрементировать этот номер и перезаписывать (нам важно, чтобы сборка не просто успешно выполнилась, но и полученные артефакты распространились для тестировщиков). Стоит оговориться, что такое решение не позволит корректно делать одновременно несколько сборок. Всю эту логику достаточно просто оформить в Gradle-плагин. Как мы уже выяснили, плагины лучше писать, используя композитные сборки.

В случае использования Gitlab CI подставляемый versionCode можно хранить в переменной окружения Gitlab. В его API есть метод для обновления переменных окружения: PUT /projects/:id/variables/:key. Для авторизации используем или project access token, или personal access token для старых версий gitlab.

Расписал добавление такого плагина по шагам, чтобы показать, насколько это просто.

Шаг 1: в настройках проекта на gitlab создать переменные окружения

Нам понадобятся переменные VERSION_CODE_NEXT для хранения номера версии и токен для доступа к API gitlab:

Шаг 2: создать композитную сборку

Добавим в корне проекта директорию ./includedBuilds/ci, а в ней файл build.gradle.kts:

plugins {    `kotlin-dsl`}kotlinDslPluginOptions {    experimentalWarning.set(false)}repositories {    jcenter()    google()}dependencies {    implementation("com.squareup.okhttp3:okhttp:4.9.0")}gradlePlugin {    plugins {        register("gitlab-ci") {            id = "gitlab-ci"            implementationClass = "com.redmadrobot.app.ci.CIPlugin" // Этот плагин создадим в следующих шагах        }    }}

Рядом создадим пустой файл ./includedBuilds/ci/settings.gradle.kts, если этого не сделать, то у вас сломается clean проекта.

В корневом проекте в файл settings.gradle.kts добавим строку includeBuild("includedBuilds/ci").

Шаг 3: написать плагин

Так будет выглядеть метод для получения versionCode, его можно будет использовать в build-скрипте (можно добавить в любой файл: при применении плагина код будет скомпилирован и добавлен в classpath build-скрипта):

const val GITLAB_VARIABLE_NEXT_VERSION = "VERSION_CODE_NEXT"private const val DEFAULT_VERSION_CODE = 1fun getVersionCode(): Int = if (isRunningOnCi()) {    getNextVersionCode()} else {    DEFAULT_VERSION_CODE}private fun isRunningOnCi(): Boolean = System.getenv()["CI"] != nullprivate fun getNextVersionCode(): Int {    return System.getenv()[GITLAB_VARIABLE_NEXT_VERSION]?.toInt()        ?: error("$GITLAB_VARIABLE_NEXT_VERSION must be specified")}

Примерно так можно написать метод для обновления переменной на gitlab:

fun updateGitlabVariable(variable: String, value: String) {    val projectId = System.getenv()["CI_PROJECT_ID"]    val accessToken = System.getenv()["TOKEN_FOR_GITLAB_API"]    val client = OkHttpClient()    val body = MultipartBody.Builder()        .setType(MultipartBody.FORM)        .addFormDataPart("value", value)        .build()    val request = Request.Builder()        .header("PRIVATE-TOKEN", accessToken)        .url("https://gitlab.com/api/v4/projects/$projectId/variables/$variable")        .method("PUT", body)        .build()    client.newCall(request).execute().use { response ->        if (!response.isSuccessful) throw IOException("Couldn't update variable)    }}

Далее пишем task, который при выполнении будет инкрементировать версию:

open class IncrementVersionCode : DefaultTask() {    @TaskAction    fun action() {        val nextVersionCode = getDistributionVersionCode() + 1        updateGitlabVariable(            GITLAB_VARIABLE_NEXT_VERSION,            nextVersionCode.toString()        )    }}

И напишем плагин, который добавит task в проект:

package com.redmadrobot.app.ciimport org.gradle.api.Pluginimport org.gradle.api.Projectclass CIPlugin : Plugin<Project> {    override fun apply(target: Project) {        target.tasks.register("incrementVersionCode", IncrementVersionCode::class.java)    }}

Шаг 4: подключить плагин

В build-скрипте проекта, из которого собирается apk, добавим следующие строки:

plugins {    id("gitlab-ci")}android {    defaultConfig {        versionCode = com.redmadrobot.app.ci.getVersionCode()    }}project.afterEvaluate {    tasks["incrementVersionCode"].mustRunAfter( // Обновление должно происходить только после публикации сборки в Firebase App Distribution        tasks["appDistributionUploadRelease"],        tasks["appDistributionUploadQa"]    )}

Теперь команда ./gradlew assembleRelease appDistributionUploadRelease incrementVersionCode будет делать новую сборку, публиковать ее и инкрементировать версию. Остается добавить эту команду на нужный триггер в ваш скрипт в .gitlab-ci.yml.

В заключение

Думаю, что у многих есть свои best practices по работе с Gradle, которыми вы бы могли поделиться с сообществом. Или что-то описанное в этой статье можно сделать лучше. Так что буду рад увидеть ваши советы в комментариях.

Что ещё посмотреть

Мне очень помогли доклады про работу с Gradle, которые делал Степан Гончаров в разные годы. Ссылки на них, если кому-то интересна эта тема:

• Gradle pipeline optimisation: Beyond basics;
• Gradle от A до Я;
• Абсолютная модуляризация.

И в формате дискуссии: Разбор доклада Степана Гончарова Gradle от А до Я

Процесс создания APK и компиляции кода

Рассматриваемые темы

• Архитектура процессоров и необходимость для виртуальной машины
• Понимание Java виртуальной машины
• Компиляция исходного кода
• Виртуальная машина Андроид
• Процесс компиляции в .dex файл
• ART против Dalvik
• Описание каждой части билд процесса
• Исходный код
• Файлы ресурсов
• AIDL файлы
• Модули библиотек
• AAR библиотеки
• JAR библиотеки
• Android Asset Packaging Tool
• resources.arsc
• D8 и R8
• Dex и Multidex
• Подписывание APK файла
• Ссылки

Архитектура процессоров и зачем нужна виртуальная машина

Понимание Java виртуальной машины

Андроид виртуальная машина

Комплияция в .dex файл

ART против Dalvik

Каждый этап описанного процесса

Source Code (Исходный код)

Resource Files

AIDL Files

Library Modules

AAR Libraries

JAR Libraries

Android Asset Packaging Tool

resources.arsc

D8 и R8

Dex and Multidex

Если количество методов приложения переваливает за 65,536, включая подключенные библиотеки, то произойдет ошибка при билде</b

The method ID range is 0 to 0xFFFF.

Другими словами, вы можете ссылаться на 65,536, или от 0 до. 65,535, если говорить цифрами

Чтобы избежать этого, нужно внимательно следить за зависимостями своего проекта и использовать R8, чтобы удалять неиспользуемый код, или включать мультидекс (multidex)

Подписывание APK файла

Ссылки

• developer.android.com/studio/build
• github.com/dogriffiths/HeadFirstAndroid/wiki/How-Android-Apps-are-Built-and-Run
• logmi.jp/tech/articles/322851
• android-developers.googleblog.com/2017/08/next-generation-dex-compiler-now-in.html
• speakerdeck.com/devpicon/uncovering-the-magic-behind-android-builds-droidfestival-2018

Всем привет,

Наша компания занимается разработкой CUBA Open Source Java фреймворка для разработки корпоративных приложений. Платформа CUBA это целая экосистема, которая включает в себя сам фреймворк и разнообразные аддоны, предоставляющие прикладной функционал, готовый к использованию в несколько кликов. За последние несколько лет фреймворк сильно набрал популярность и сейчас используется более 20 000 разработчиками по всему земному шару. С ростом популярности мы сталкивались с множеством интересных кейсов и в этой статье хотим затронуть один из них. Возможно, этот материал поможет в вашей практике, особенно если вы работаете в организации, в которой вопросы безопасности больно бьют по рукам разработчиков.

Конкретно мы поговорим про тот случай, когда в компании лимитирован доступ к всемирной паутине настолько, что вы не можете пользоваться публичными репозиториями артефактов, например таким, как maven central. Представьте себе, что мы (или вы) поставляем наш фреймворк в такой закрытый контур. Как же нам предоставить все необходимые артефакты, от которых мы зависим, включая транзитивные зависимости? Как потом их обновлять вместе с версиями фреймворка?

В данной статье я хочу рассказать о нашем новом инструменте CUBA SDK консольной утилите, которая позволяет определять все транзитивные зависимости для Maven-библиотек и управлять ими в удаленных репозиториях. Также в статье мы рассмотрим пример, который позволит вам использовать наши наработки для любого Java приложения с применением Maven-зависимостей.

Проблема загрузки транзитивных зависимостей для внутренних репозиториев

Практически любой современный JVM проект, задействующий Apache Maven или Gradle в качестве инструмента сборки, имеет большое количество транзитивных зависимостей для используемых библиотек или фреймворков. При наличии доступного репозитория в сети эти зависимости автоматически разрешаются с помощью менеджера зависимостей.

Но что делать в случае, если публичные репозитории недоступны из внутренней сети?

Возможные варианты решения проблемы

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

Что же нам остается?

• Вариант 0. Упрашивание безопасников.
• Вариант 1. Шлюз.
• Вариант 2. Ручное управление зависимостями.

Вариант 0 рассматривать не будем, рассмотрим вариант 1 и 2.

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

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

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

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

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

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

Как мы предлагаем решать эти проблемы?

CUBA SDK

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

В чем отличие CUBA SDK от оффлайн плагинов для Gradle или Maven?
Главное отличие CUBA SDK не кэширует зависимости конкретного проекта, а позволяет синхронизировать артефакты между внешними и внутренними репозиториями, чтобы разработчикам было комфортно создавать и разрабатывать приложения в закрытой сети.
CUBA SDK не требует проекта и позволяет создать необходимый оффлайн стек фреймворков, аддонов и библиотек со всеми зависимостями.

Для разработчика это может быть полезно, если он работает с несколькими проектами или только планирует начать новый проект и сразу не знает, какие модули будут использоваться в его проекте. С помощью SDK эти модули могут быть заранее загружены в локальный или внутренний репозиторий.

Для организаций это может быть полезно для централизованной синхронизации внутренних репозиториев.

CUBA SDK позволяет с помощью нескольких консольных команд определять все зависимости для артефактов и заливать их в нужные репозитории. Для полностью закрытых сетей можно использовать команды импорта и экспорта или установить CUBA SDK на шлюз.

Преимущества использования CUBA SDK:

• автоматически собирает все зависимости с исходным кодом для загружаемых библиотек
• определяет зависимости для платформы и аддонов CUBA Platform
• проверяет и устанавливает новые версии библиотек
• может работать одновременно с несколькими репозиториями для поиска артефактов, включая локальные maven репозитории
• имеет встроенный Nexus OSS репозиторий артефактов
• даёт возможность загрузки артефактов одновременно в несколько репозиториев, включая локальные maven
• производит импорт и экспорт артефактов со всеми зависимостями
• предоставляет интерактивный режим с подсказками для установки платформы и аддонов CUBA Platform
• использует механизмы Gradle для определения зависимостей
• не зависит от IDE
• может быть установлен на CI сервере

Команды SDK

Полный список доступных команд можно посмотреть на странице GitHub.

CUBA SDK изначально поддерживает три типа компонентов: CUBA Framework, CUBA addon и библиотека, которая может быть загружена через maven координаты. Этот список может быть расширен для других типов компонентов через плагины для CUBA SDK.

Установка компонента в удаленный репозиторий может быть выполнена через команду install. При создании SDK мы предусмотрели вариант, когда SDK может быть установлен на шлюзовом компьютере или на переносном носителе, в этом случае установку компонентов можно сделать через команды resolve и push.

resolve просто определяет и скачивает все зависимости в локальный кэш SDK
push заливает уже скачанные артефакты с зависимостями в настроенные target репозитории

Для работы с репозиториями в SDK есть встроенный менеджер репозиториев.
Менеджер репозиториев поддерживает локальные и удаленные репозитории, которые в SDK разделены на две группы:

• source это репозитории, которые будут использоваться для поиска артефактов
• target репозитории, в которые нужно будет залить эти артефакты

SDK сам может использоваться как репозиторий, для этого с помощью команды setup-nexus SDK скачивает, устанавливает и настраивает репозиторий Nexus OSS. Для запуска и остановки репозитория используются команды start и stop.

Для проверки и установки обновлений достаточно выполнить команду check-updates.

Определение зависимостей

Самая главная проблема, которую должен был решать SDK это корректное определение и сбор зависимостей для компонентов. При разработке мы попробовали несколько подходов для определения транзитивных зависимостей компонентов. Изначально возникла идея, что можно просто распарсить .pom файлы и составить дерево зависимостей. Но идея парсить файлы вручную оказалась не очень хорошей, тем более что Apache Maven все это уже умеет делать из коробки.

Maven как менеджер зависимостей

Поэтому мы решили использовать Apache Maven для определения транзитивных зависимостей компонентов.

Для этого в CUBA SDK скачивается дистрибутив maven в домашнюю папку SDK и через Java Runtime запускаются команды.

Например, с помощью команды

dependency:resolve -Dtransitive=true -DincludeParents=true -DoverWriteSnapshots=true -Dclassifier=<classifier> -f pom.xml

мы определяли все зависимости для компонентов, которые описаны в pom.xml, и эти компоненты автоматически скачивались в локальный кэш maven, после чего с помощью команды

org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy-file -Durl=<repository URL>

артефакты заливались в нужный репозиторий.

Следующая команда позволяет загрузить библиотеку в локальный репозиторий.

org.apache.maven.plugins:maven-dependency-plugin:3.1.1:get -Dartifact=<maven coordinates>

Для выполнения команд Maven в приложении CUBA SDK сгенерировался settings.xml файл. Он содержал список всех репозиториев, которые должны были использоваться для загрузки и выгрузки артефактов.

Gradle как менеджер зависимостей

В первой версии приложения зависимости определялись корректно, но довольно медленно, и при тестировании функционала стали возникать конфликты при определении зависимостей для некоторых аддонов CUBA Platform, хотя при сборке проекта через Gradle таких проблем не возникало.

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

Для вызова задач Gradle используется Gradle Tooling API.

Для определения пути к зависимостями через Gradle мы используем artifact resolution query API. Следующий код позволяет получить путь к исходникам библиотеки:

 def component = project.dependencies.createArtifactResolutionQuery()            .forComponents(artifact.id.componentIdentifier)            .withArtifacts(JvmLibrary, SourcesArtifact)            .execute()            .resolvedComponents[0] def sourceFile = component?.getArtifacts(SourcesArtifact)[0]?.file

Таким образом, мы получили пути ко всем файлам в локальном кэше Gradle и сохраняли их в хранилище SDK.

Для загрузки в локальный кэш и определения зависимостей для компонентов мы добавляем компоненты в конфигурацию и через lenientConfiguration получаем все зависимости.

project.ext.properties["toResolve"].tokenize(';').each {            dependencies.add 'extraLibs', it        }        def resolved = [:]        configurations.all.collect {            if (it.canBeResolved) {                it.resolvedConfiguration.lenientConfiguration.artifacts.each { art ->                    try {                        ...                    } catch (e) {                        logger.error("Error: " + e.getMessage(), e)                        logger.error("could not find pom for {}", art.file)                    }                }            }        }

Мы используем lenientConfiguration, чтобы Gradle скрипт пропускал не найденные зависимости и не падал в случае если компонент не найден в репозиториях.

Для загрузки артефактов в репозитории SDK использует PublishToMavenRepository задачу Gradle.

task publishArtifact(type: PublishToMavenRepository) {    doLast {        if (project.ext.hasProperty("toUpload")) {            def toUpload = new JsonSlurper().parseText(project.ext.properties["toUpload"])            def descriptors = new JsonSlurper().parseText(project.ext.properties["descriptors"])            artifactId toUpload.artifactId            groupId toUpload.groupId            version toUpload.version            descriptors.each { descriptor ->                artifact(descriptor.filePath) {                    classifier descriptor.classifier.type                    extension descriptor.classifier.extenstion                }            }        }    }}

В результате использования Gradle мы избавились от конфликтов при определении транзитивных зависимостей и заметно ускорили работу приложения.

Сборка проекта

Для сборки CUBA SDK мы использовали тот же подход, что и для CUBA CLI. Мы с помощью инструмента jlink собирали все необходимые модули в кастомную JRE, которая поставляется вместе с приложением. Это позволило сделать SDK независимым от установленной на компьютерах пользователей Java. Пример такой сборки можно посмотреть в CLI Core Sample проекте.

Поддержка сторонних плагинов

Так как CUBA SDK построен на основе библиотеки CLI Core, CUBA SDK поддерживает сторонние плагины. С помощью системы плагинов сейчас в SDK реализованы maven и gradle менеджеры зависимостей компонентов и провайдеры для CUBA компонентов.

Рассмотрим пример, как мы можем расширить функционал SDK с помощью плагина. В данном примере мы напишем провайдер для стартеров Spring Boot из хорошо известного Spring Initializr.

Для начала создадим новый проект, для примера возьмем плагин для CUBA CLI, как описано здесь, и добавим зависимости:

implementation "com.haulmont.cli.core:cli-core:1.0.0"implementation "com.haulmont.cli.sdk:cuba-sdk:1.0.1"

Создадим новый провайдер для стартеров spring boot SpringBootProvider, который наследуем от BintraySearchComponentProvider. BintraySearchComponentProvider позволяет автоматически находить доступные версии компонентов, используя Bintray API.

class SpringBootProvider : BintraySearchComponentProvider() {   var springComponentsInfo: SpringComponentsInfo? = null   override fun getType() = "boot-starter"   override fun getName() = "Spring boot starter" ...   override fun load() {       springComponentsInfo = Gson().fromJson(readSpringFile(), SpringComponentsInfo::class.java)   }   private fun readSpringFile(): String {       return SpringComponentsPlugin::class.java.getResourceAsStream("spring-components.json")           .bufferedReader()           .use { it.readText() }   }

Этот провайдер будет искать доступные компоненты из файла spring-components.json, который является json версией yml файла приложения Spring Initializr.

Для маппинга из json в объекты создадим простые data классы:

data class SpringComponent(   val name: String,   val id: String,   val groupId: String?,   val artifactId: String?,   val description: String?,   val starter: Boolean? = true)data class SpringComponentCategory(   val name: String,   val content: List<SpringComponent>)data class SpringInitializr(   val dependencies: List<SpringComponentCategory>)data class SpringComponentsInfo(   val initializr: SpringInitializr)

Для того, чтобы добавить наш провайдер к остальным провайдерам SDK, нужно в init событии плагина зарегистрировать провайдер:

class SpringBootComponentsPlugin : CliPlugin {   private val componentRegistry: ComponentRegistry by sdkKodein.instance<ComponentRegistry>()   @Subscribe   fun onInit(event: InitPluginEvent) {       val bootProvider = SpringBootProvider()       componentRegistry.addProviders(bootProvider)       bootProvider.load()   }}

Все готово. Теперь, чтобы установить наш плагин в терминале или через IDE, нужно выполнить команду gradle installPlugin.

Запустим SDK

Видим, что наш плагин успешно загрузился. Теперь проверим, что вся наша логика работает с помощью команды resolve boot-starter:

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

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

Исходный код тестового плагина можно найти на странице GitHub.

Заключение

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

Если вы самоизолировались в глухой деревне или летите 8 часов в самолете и не готовы платить по 300 евро за 10 мегабайт трафика, то CUBA SDK отличное решение, которое позволит собрать актуальный стек используемых библиотек и фреймворков локально у вас на компьютере.