2つのモバイルサービスの背後：1つのアプリケーションでのHMSとGMS

こんにちは、Habr！私の名前はアンドレイです。Android用の「ウォレット」アプリケーションを作成しています。 6か月以上前から、HuaweiスマートフォンユーザーがNFCを介して銀行カードを使って非接触で購入代金を支払うのを支援してきました。これを行うには、HMSのサポートを追加する必要がありました：プッシュキット、マップキット、および安全検出。カットの下で、開発中に解決しなければならなかった問題、その理由とその原因を説明し、トピックにすばやく没頭するためのテストプロジェクトを共有します。



新しいHuaweiスマートフォンのすべてのユーザーに、箱から出してすぐに非接触で支払う機能を提供し、他のシナリオでより良いユーザーエクスペリエンスを提供するために、2020年1月に、新しいプッシュ通知、カード、セキュリティチェックのサポートに着手しました。その結果、Huawei電話にネイティブなモバイルサービスを備えたバージョンのWalletがAppGalleryに表示されるはずでした。

これが、最初の調査の段階で私たちが何とか見つけたものです。

• HuaweiはAppGalleryとHMSを制限なしで配布しています。他のメーカーのデバイスにダウンロードしてインストールできます。
• Xiaomi Mi A1にAppGalleryをインストールした後、最初にすべての更新が新しいサイトからプルアップされ始めました。AppGalleryには、競合他社よりも早くアプリケーションを更新する時間があります。
• Huaweiは現在、AppGalleryをできるだけ早くアプリケーションで満たすよう努めています。HMSへの移行をスピードアップするために、彼らは開発者にすでに使い慣れた（GMSに類似した）APIを提供することにしました。
• 最初は、Huawei開発者エコシステムが完全に機能するまで、Googleサービスの欠如が新しいHuaweiスマートフォンのユーザーにとって主な問題である可能性が高く、彼らは必ずそれらをインストールしようとします。

すべての配布サイトで、アプリケーションの1つの共通バージョンを作成することにしました。彼女は、実行時に適切なタイプのモバイルサービスを識別して使用できる必要があります。このオプションは、サービスの種類ごとに個別のバージョンよりも実装に時間がかかるように見えましたが、別のバージョンで勝つことを望んでいました。

• HuaweiデバイスでGooglePlay用のバージョンを取得するリスク、およびその逆のリスクが排除されます。
• 機能トグルの使用を含め、モバイルサービスを選択するための任意のアルゴリズムを実装できます。
• 1つのアプリケーションのテストは、2つのアプリケーションのテストよりも簡単です。
• 各リリースは、すべての配布サイトにアップロードできます。
• 開発/変更中に、コードの記述からプロジェクトのビルドの管理に切り替える必要はありません。

アプリケーションの1つのバージョンでモバイルサービスのさまざまな実装を操作するには、次のことを行う必要があります。

1. 抽象化のすべての要求を非表示にして、GMSでの作業を節約します。
2. HMSの実装を追加します。
3. 実行時にサービスの実装を選択するためのメカニズムを開発します。

PushKitとSafetyDetectのサポートを実装する方法は、Map Kitとは大幅に異なるため、個別に検討します。

プッシュキットと安全検出のサポート

そのような場合にあるはずなので、統合プロセスはドキュメントの調査から始まりました。警告セクションで次の点が見つかりました。

• HuaweiデバイスでEMUIバージョンが10.0以降の場合、トークンはgetTokenメソッドを介して返されます。getTokenメソッドの呼び出しに失敗した場合、HUAWEIプッシュキットはトークン要求を自動的にキャッシュし、メソッドを再度呼び出します。その後、onNewTokenメソッドを介してトークンが返されます。
• HuaweiデバイスのEMUIバージョンが10.0より前であり、getTokenメソッドを使用してトークンが返されない場合、トークンは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.

これらの警告から取り除く主なことは、EMUIの異なるバージョンでプッシュトークンを取得することに違いがあるということです。getToken（）メソッドを呼び出した後、サービスのonNewToken（）メソッドを呼び出すことで実際のトークンを返すことができます。実際のデバイスでのテストでは、EMUI <10.0の電話は、getTokenメソッドが呼び出された後、サービスのonNewToken（）メソッドが呼び出されると、nullまたは空の文字列を返すことが示されています。EMUI> = 10.0の電話は、常にgetToken（）メソッドからプッシュトークンを返しました。



このようなデータソースを実装して、作業のロジックを単一の形式にすることができます。

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)
               })
       }
   }
}

重要な注意事項：

• . , , 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.

-

• サービスの種類ごとに個別のデータソースを作成します。
• モバイルサービスのタイプを入力として受け入れ、特定のデータソースを選択するプッシュ通知とセキュリティのリポジトリを追加します。
• ビジネスロジックの一部のエンティティは、特定の場合に使用するのに適切な（利用可能なサービスからの）モバイルサービスのタイプを決定します。

実行時にサービスの実装を選択するためのメカニズムの開発

デバイスに1種類のサービスしかインストールされていない場合、またはまったくインストールされていない場合はどうすればよいですか。ただし、GoogleサービスとHuaweiサービスの両方が同時にインストールされている場合はどうすればよいですか。



これが私たちが見つけたものと私たちが始めた場所です：

• 新しいテクノロジーを導入する場合、ユーザーのデバイスがすべての要件を完全に満たしている場合は、それを優先事項として使用する必要があります。
• EMUI >= 10.0 - ;
• Huawei Google- EMUI 10.0 ;
• Huawei Google-, . , Google- ;
• AppGallery Huawei-, , .

アルゴリズムの開発は、おそらく最も疲れるビジネスであることが判明しました。多くの技術的およびビジネス的要因がここに収束しましたが、最終的には、当社の製品に最適なソリューションを思いつくことができました。アルゴリズムの最も議論されている部分の説明が1つの文に収まるのは少し奇妙ですが、最終的には単純に次のようになったことを嬉しく思います。

両方のタイプのサービスがデバイスにインストールされていて、EMUIバージョンが10未満であると判断できた場合は、Googleを使用します。それ以外の場合は、Huaweiを使用します。

最終的なアルゴリズムを実装するには、ユーザーのデバイスでEMUIバージョンを判別する方法を見つける必要があります。



これを行う1つの方法は、システムプロパティを読み取ることです。

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
    }
}

セキュリティチェックを正しく実行するには、サービスの状態を更新する必要がないことを考慮する必要があります。



サービスが選択される操作のタイプを考慮し、デバイスのEMUIバージョンを決定する、アルゴリズムの最終的な実装は、次のようになります。

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
    }
}

マップキットのサポート

実行時にサービスを選択するためのアルゴリズムを実装した後、マップの基本機能のサポートを追加するためのアルゴリズムは簡単に見えます。

1. マップを表示するためのサービスのタイプを決定します。
2. 適切なレイアウトを膨らませ、特定のマップ実装で作業します。

ただし、ここで説明したい機能が1つあります。Rx of the brainを使用すると、アプリケーション全体を書き直すリスクなしに、ほぼどこにでも非同期操作を追加できますが、独自の制限もあります。たとえば、この場合、適切なレイアウトを決定するには、ほとんどの場合、メインスレッドのどこかで.blockingGet（）を呼び出す必要がありますが、これはまったく適切ではありません。この問題は、たとえば、子フラグメントを使用して解決できます。

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)
       }
   }
}

これで、個々のフラグメントごとにマップを操作するための個別の実装を作成できます。同じロジックを実装する必要がある場合は、使い慣れたアルゴリズムに従うことができます。MapFragment.onMapReady（）で行われるように、1つのインターフェイスで各タイプのマップの作業を調整し、このインターフェイスの実装の1つを親フラグメントに渡します。

何が起こったのか

アプリケーションの更新バージョンのリリース後の最初の数日で、インストール数は100万に達しました。これは、AppGalleryの注目の機能と、いくつかのメディアやブロガーによってリリースが強調されたという事実に一部起因しています。また、アプリケーションの更新速度も向上しました。結局のところ、versionCodeが最も高いバージョンがAppGalleryに2週間存在していました。



w3bsit3-dns.comのスレッドで、アプリケーション全般、特に銀行カードのトークン化に関する有益なフィードバックをユーザーから受け取ります。 Huaweiの有料機能のリリース後、フォーラムの訪問者数が増加し、彼らが直面する問題も増えています。私たちはすべてのアピールに取り組み続けていますが、大きな問題は見られません。



一般に、AppGalleryでのアプリケーションのリリースは成功し、問題を解決するためのアプローチが機能していることが判明したと結論付けることができます。選択した実装方法のおかげで、GooglePlayとAppGalleryの両方でアプリケーションのすべてのリリースをアップロードすることができます。



この方法を使用して、アプリケーションAnalytics KitにAPMを追加し、Account Kitのサポートに取り組んでいますが、そこで停止する予定はありません。新しいバージョンが利用可能になるたびに、HMSにはさらに多くの機会があります。

あとがき

AppGalleryへの開発者アカウントの登録はGoogleよりもはるかに複雑です。たとえば、身元を確認するのに9日かかりました。これがすべての人に起こるとは思いませんが、遅れると楽観主義が失われる可能性があります。したがって、記事で説明されているデモソリューション全体の完全なコードとともに、すべてのアプリケーションキーをリポジトリにコミットしました。これにより、ソリューション全体を評価するだけでなく、提案されたアプローチをテストして改善する機会も得られます。



パブリックスペースへの出口を使用して、ウォレットチーム全体、特に感謝したいと思いますumpteenthdev、ArtemKulakovとEgorAganinは、HMSをウォレットに統合するための貴重な貢献をしてくれました。

便利なリンク

• GitHubの完全なデモプロジェクトコード。
• AppGallery . HMS-Core AppGallery;
• Push Kit codelab;
• Map Kit codelab;
• Safety Detect codelab;
• - Huawei. AppGallery Connect;
• «» 4PDA.