🕤 🎨 🛒 Detrás de dos servicios móviles: HMS y GMS en una sola aplicación 🌀 🎮 🚆

¡Hola, Habr! Mi nombre es Andrey, estoy creando la aplicación " Wallet " para Android. Durante más de seis meses, hemos estado ayudando a los usuarios de teléfonos inteligentes Huawei a pagar sus compras con tarjetas bancarias sin contacto, a través de NFC. Para hacer esto, necesitábamos agregar soporte para HMS: Push Kit, Map Kit y Safety Detect. Debajo del corte, les diré qué problemas tuvimos que resolver durante el desarrollo, por qué exactamente y qué surgió, y también compartiré un proyecto de prueba para una inmersión más rápida en el tema.

Para brindar a todos los usuarios de los nuevos teléfonos inteligentes de Huawei la capacidad de pagar sin contacto desde el primer momento y garantizar la mejor experiencia de usuario en otros escenarios, en enero de 2020 comenzamos a trabajar para admitir nuevas notificaciones automáticas, tarjetas y controles de seguridad. El resultado debería haber sido la aparición en AppGallery de una versión de Wallet con servicios móviles nativos de los teléfonos Huawei.

Esto es lo que logramos descubrir en la etapa del estudio inicial.

Huawei distribuye AppGallery y HMS sin restricciones: puede descargarlos e instalarlos en dispositivos de otros fabricantes;
Después de instalar AppGallery en Xiaomi Mi A1, todas las actualizaciones comenzaron a extraerse en primer lugar del nuevo sitio. La impresión es que AppGallery tiene tiempo para actualizar las aplicaciones más rápido que la competencia;
Huawei ahora se esfuerza por llenar la AppGallery con aplicaciones lo más rápido posible. Para acelerar la migración a HMS, decidieron proporcionar a los desarrolladores una API familiar (similar a GMS) ;
Al principio, hasta que el ecosistema de desarrolladores de Huawei esté completamente operativo, la falta de servicios de Google probablemente será el principal problema para los usuarios de los nuevos teléfonos inteligentes de Huawei, e intentarán instalarlos en todos los sentidos .

Decidimos crear una versión común de la aplicación para todos los sitios de distribución. Debe poder identificar y utilizar el tipo apropiado de servicio móvil en tiempo de ejecución. Esta opción parecía más lenta de implementar que una versión separada para cada tipo de servicio, pero esperábamos ganar en otra:

Se elimina el riesgo de obtener la versión destinada a Google Play en dispositivos Huawei y viceversa;
Puede implementar cualquier algoritmo para elegir servicios móviles, incluido el uso de alternancia de funciones;
Probar una aplicación es más fácil que probar dos;
Cada versión se puede cargar en todos los sitios de distribución;
No tiene que cambiar de escribir código a administrar la construcción del proyecto durante el desarrollo / modificación.

Para trabajar con diferentes implementaciones de servicios móviles en una versión de la aplicación, debe:

Ocultar todas las solicitudes de abstracción, ahorrando trabajo con GMS;
Agregue una implementación para HMS;
Desarrollar un mecanismo para elegir la implementación de servicios en tiempo de ejecución.

La metodología para implementar el soporte Push Kit y Safety Detect es significativamente diferente del Map Kit, por lo que los consideraremos por separado.

Soporte Push Kit y Safety Detect

Como debe ser en tales casos, el proceso de integración comenzó con el estudio de la documentación . Los siguientes puntos se encontraron en la sección de advertencia:

Si la versión EMUI es 10.0 o posterior en un dispositivo Huawei, se devolverá un token a través del método getToken. Si no se puede llamar al método getToken, HUAWEI Push Kit automáticamente almacena en caché la solicitud del token y vuelve a llamar al método. Luego, se devolverá un token a través del método onNewToken.

Si la versión de EMUI en un dispositivo Huawei es anterior a la 10.0 y no se devuelve ningún token mediante el método getToken, se devolverá un token mediante el método onNewToken.

For an app with the automatic initialization capability, the getToken method does not need to be called explicitly to apply for a token. The HMS Core Push SDK will automatically apply for a token and call the onNewToken method to return the token.

Lo principal que hay que sacar de estas advertencias es que hay una diferencia en recibir un token de inserción en diferentes versiones de EMUI . Después de llamar al método getToken (), el token real se puede devolver llamando al método onNewToken () del servicio. Nuestras pruebas en dispositivos reales han demostrado que los teléfonos con EMUI <10.0 devuelven un valor nulo o una cadena vacía cuando se llama al método getToken, después de lo cual se llama al método onNewToken () del servicio. Los teléfonos con EMUI> = 10.0 siempre devolvían un token de inserción del método getToken ().

Puede implementar una fuente de datos de este tipo para llevar la lógica del trabajo a una sola forma:

class HmsDataSource(
   private val hmsInstanceId: HmsInstanceId,
   private val agConnectServicesConfig: AGConnectServicesConfig
) {

   private val currentPushToken = BehaviorSubject.create<String>()

   fun getHmsPushToken(): Single<String> = Maybe
       .merge(
           getHmsPushTokenFromSingleton(),
           currentPushToken.firstElement()
       )
       .firstOrError()

   fun onPushTokenUpdated(token: String): Completable = Completable
       .fromCallable { currentPushToken.onNext(token) }

   private fun getHmsPushTokenFromSingleton(): Maybe<String> = Maybe
       .fromCallable<String> {
           val appId = agConnectServicesConfig.getString("client/app_id")
           hmsInstanceId.getToken(appId, "HCM").takeIf { it.isNotEmpty() }
       }
       .onErrorComplete()
}

class AppHmsMessagingService : HmsMessageService() {

   val onPushTokenUpdated: OnPushTokenUpdated = Di.onPushTokenUpdated

   override fun onMessageReceived(remoteMessage: RemoteMessage?) {
       super.onMessageReceived(remoteMessage)
       Log.d(LOG_TAG, "onMessageReceived remoteMessage=$remoteMessage")
   }

   override fun onNewToken(token: String?) {
       super.onNewToken(token)
       Log.d(LOG_TAG, "onNewToken: token=$token")
       if (token?.isNotEmpty() == true) {
           onPushTokenUpdated(token, MobileServiceType.Huawei)
               .subscribe({},{
                   Log.e(LOG_TAG, "Error deliver updated token", it)
               })
       }
   }
}

Notas importantes:

. , , AppGallery -, . , HmsMessageService.onNewToken() , , , . ;
, HmsMessageService.onMessageReceived() main , ;
com.huawei.hms:push, com.huawei.hms.support.api.push.service.HmsMsgService, :pushservice. , , Application. , , , Firebase Performance. -Huawei , AppGallery HMS.

-

Creamos una fuente de datos separada para cada tipo de servicio;
Agregue un repositorio para notificaciones push y seguridad que acepte el tipo de servicios móviles como entrada y seleccione una fuente de datos específica;
Alguna entidad de lógica empresarial determina qué tipo de servicios móviles (de los disponibles) es apropiado para usar en un caso particular.

Desarrollo de un mecanismo para elegir la implementación de servicios en tiempo de ejecución

¿Cómo proceder si solo se instala un tipo de servicios en el dispositivo o ninguno en absoluto, pero qué hacer si los servicios de Google y Huawei se instalan al mismo tiempo?

Esto es lo que encontramos y dónde empezamos:

Al introducir cualquier nueva tecnología, se debe utilizar como prioridad si el dispositivo del usuario cumple con todos los requisitos;
EMUI >= 10.0 - ;
Huawei Google- EMUI 10.0 ;
Huawei Google-, . , Google- ;
AppGallery Huawei-, , .

El desarrollo del algoritmo resultó ser, quizás, el asunto más agotador. Aquí convergieron muchos factores técnicos y comerciales, pero al final pudimos encontrar la mejor solución para nuestro producto . Ahora es incluso un poco extraño que la descripción de la parte más discutida del algoritmo encaje en una oración, pero me alegro de que al final haya resultado simple:

Si ambos tipos de servicios están instalados en el dispositivo y fue posible determinar que la versión de EMUI es <10, usamos Google, de lo contrario usamos Huawei.

Para implementar el algoritmo final, es necesario encontrar una forma de determinar la versión de EMUI en el dispositivo del usuario.

Una forma de hacerlo es leer las propiedades del sistema:

class EmuiDataSource {

    @SuppressLint("PrivateApi")
    fun getEmuiApiLevel(): Maybe<Int> = Maybe
        .fromCallable<Int> {
            val clazz = Class.forName("android.os.SystemProperties")
            val get = clazz.getMethod("getInt", String::class.java, Int::class.java)
            val currentApiLevel = get.invoke(
                    clazz,
                    "ro.build.hw_emui_api_level",
                    UNKNOWN_API_LEVEL
            ) as Int
            currentApiLevel.takeIf { it != UNKNOWN_API_LEVEL }
        }
        .onErrorComplete()

    private companion object {
        const val UNKNOWN_API_LEVEL = -1
    }
}

Para la correcta ejecución de los controles de seguridad, además es necesario tener en cuenta que el estado de los servicios no debe requerir actualización.

La implementación final del algoritmo, teniendo en cuenta el tipo de operación para la que se selecciona el servicio y determinando la versión EMUI del dispositivo, puede verse así:


sealed class MobileServiceEnvironment(
   val mobileServiceType: MobileServiceType
) {
   abstract val isUpdateRequired: Boolean

   data class GoogleMobileServices(
       override val isUpdateRequired: Boolean
   ) : MobileServiceEnvironment(MobileServiceType.Google)

   data class HuaweiMobileServices(
       override val isUpdateRequired: Boolean,
       val emuiApiLevel: Int?
   ) : MobileServiceEnvironment(MobileServiceType.Huawei)
}

class SelectMobileServiceType(
        private val mobileServicesRepository: MobileServicesRepository
) {

    operator fun invoke(
            case: Case
    ): Maybe<MobileServiceType> = mobileServicesRepository
            .getAvailableServices()
            .map { excludeEnvironmentsByCase(case, it) }
            .flatMapMaybe { selectEnvironment(it) }
            .map { it.mobileServiceType }

    private fun excludeEnvironmentsByCase(
            case: Case,
            envs: Set<MobileServiceEnvironment>
    ): Iterable<MobileServiceEnvironment> = when (case) {
        Case.Push, Case.Map -> envs
        Case.Security       -> envs.filter { !it.isUpdateRequired }
    }

    private fun selectEnvironment(
            envs: Iterable<MobileServiceEnvironment>
    ): Maybe<MobileServiceEnvironment> = Maybe
            .fromCallable {
                envs.firstOrNull {
                    it is HuaweiMobileServices
                            && (it.emuiApiLevel == null || it.emuiApiLevel >= 21)
                }
                        ?: envs.firstOrNull { it is GoogleMobileServices }
                        ?: envs.firstOrNull { it is HuaweiMobileServices }
            }

    enum class Case {
        Push, Map, Security
    }
}

Soporte del kit de mapas

Después de la implementación del algoritmo para seleccionar servicios en tiempo de ejecución, el algoritmo para agregar soporte para la funcionalidad básica de los mapas parece trivial:

Determinar el tipo de servicios para mostrar mapas;
Infle el diseño apropiado y trabaje con una implementación de mapa específica.

Sin embargo, hay una característica aquí de la que quiero hablar. Rx of the brain te permite agregar cualquier operación asincrónica casi en cualquier lugar sin el riesgo de reescribir toda la aplicación, pero también impone sus propias limitaciones. Por ejemplo, en este caso, para determinar el diseño apropiado, lo más probable es que deba llamar a .blockingGet () en algún lugar del hilo principal, lo cual no es nada bueno. Puede resolver este problema, por ejemplo, utilizando fragmentos secundarios:

class MapFragment : Fragment(),
   OnGeoMapReadyCallback {

   override fun onActivityCreated(savedInstanceState: Bundle?) {
       super.onActivityCreated(savedInstanceState)
       ViewModelProvider(this)[MapViewModel::class.java].apply {
           mobileServiceType.observe(viewLifecycleOwner, Observer { result ->
               val fragment = when (result.getOrNull()) {
                   Google -> GoogleMapFragment.newInstance()
                   Huawei -> HuaweiMapFragment.newInstance()
                   else -> NoServicesMapFragment.newInstance()
               }
               replaceFragment(fragment)
           })
       }
   }

   override fun onMapReady(geoMap: GeoMap) {
       geoMap.uiSettings.isZoomControlsEnabled = true
   }
}

class GoogleMapFragment : Fragment(),
   OnMapReadyCallback {

   private var callback: OnGeoMapReadyCallback? = null

   override fun onAttach(context: Context) {
       super.onAttach(context)
       callback = parentFragment as? OnGeoMapReadyCallback
   }

   override fun onDetach() {
       super.onDetach()
       callback = null
   }

   override fun onMapReady(googleMap: GoogleMap?) {
       if (googleMap != null) {
           val geoMap = geoMapFactory.create(googleMap)
           callback?.onMapReady(geoMap)
       }
   }
}

class HuaweiMapFragment : Fragment(),
   OnMapReadyCallback {

   private var callback: OnGeoMapReadyCallback? = null

   override fun onAttach(context: Context) {
       super.onAttach(context)
       callback = parentFragment as? OnGeoMapReadyCallback
   }

   override fun onDetach() {
       super.onDetach()
       callback = null
   }

   override fun onMapReady(huaweiMap: HuaweiMap?) {
       if (huaweiMap != null) {
           val geoMap = geoMapFactory.create(huaweiMap)
           callback?.onMapReady(geoMap)
       }
   }
}

Ahora puede escribir una implementación separada para trabajar con el mapa para cada fragmento individual. Si necesita implementar la misma lógica, puede seguir el algoritmo familiar: ajustar el trabajo con cada tipo de mapas en una interfaz y pasar una de las implementaciones de esta interfaz al fragmento principal, como se hace en MapFragment.onMapReady ()

Que vino de eso

En los primeros días después del lanzamiento de la versión actualizada de la aplicación, el número de instalaciones alcanzó el millón. Lo atribuimos en parte a la función destacada de AppGallery, y en parte al hecho de que nuestro lanzamiento fue destacado por varios medios y blogueros. Y también con la velocidad de actualización de las aplicaciones; después de todo, la versión con el código de versión más alto estuvo en AppGallery durante dos semanas.

Recibimos comentarios útiles sobre el funcionamiento de la aplicación en general y sobre la tokenización de tarjetas bancarias en particular de los usuarios de nuestro hilo en w3bsit3-dns.com. Después del lanzamiento de la funcionalidad de pago para Huawei, el foro ha aumentado en número de visitantes, al igual que los problemas que enfrentan. Seguimos trabajando en todos los llamamientos, pero no observamos ningún problema masivo.

En general, el lanzamiento de la aplicación en AppGallery fue exitoso y podemos concluir que nuestro enfoque para resolver el problema resultó estar funcionando. Gracias al método de implementación elegido, todavía tenemos la capacidad de cargar todas las versiones de la aplicación tanto en Google Play como en AppGallery.

Usando este método, hemos agregado a la aplicación Analytics Kit , el APM , trabajando para apoyar el Account Kit y no planeamos detenernos allí, más aún con cada nueva versión que HMS está disponible aún más oportunidades .

Epílogo

Registrar una cuenta de desarrollador con AppGallery es mucho más complicado que el de Google. Para mí, por ejemplo, la etapa de verificación de la verificación de identidad tomó 9 días. No creo que esto le pase a todo el mundo, pero cualquier retraso puede disminuir el optimismo. Por lo tanto, junto con el código completo de la solución de demostración completa descrita en el artículo, he comprometido todas las claves de la aplicación en el repositorio para que tenga la oportunidad no solo de evaluar la solución en su conjunto, sino también ahora mismo de probar y mejorar el enfoque propuesto.

Utilizando la salida al espacio público, quiero agradecer a todo el equipo de Wallet y especialmenteenésimodev, Artem Kulakov y Egor Aganin por su invaluable contribución a la integración de HMS en Wallet.

Enlaces útiles

Código del proyecto de demostración completo en GitHub;
AppGallery . HMS-Core AppGallery;
Push Kit codelab;
Map Kit codelab;
Safety Detect codelab;
- Huawei. AppGallery Connect;
«» 4PDA.

Detrás de dos servicios móviles: HMS y GMS en una sola aplicación