企業アプリケーションのトピックは、数年にわたって会議や記事で活発に議論されてきました。 誰もが「蜂蜜の樽」を描きます。家やオフィスからすぐに、いつでも手元に...一般的に、ビジネス上の問題を迅速に解決するための有望で便利なツールです。

しかし、「軟膏で飛ぶ」ということで止めましょう。 牧歌的な写真は、従業員間でアプリケーションを配布および更新する問題によって損なわれる可能性があります。 経験によれば、エンタープライズアプリケーションの作成だけでは不十分です。 また、ターゲットオーディエンスに配信する便利な方法を見つけて、更新する必要があります。

EastancTechnologiesでは、多数の企業モバイルアプリケーションを作成してきましたが、インストールと更新の問題は常にホットなトピックでした。 すべてのオプションの中で、1つはむしろ技術的で興味深いようです-独自のアプリストア。 投稿では、エンタープライズアプリケーションのユーザー向けにAndroid用ストアを実装した方法の詳細を共有します。

実際、問題は何ですか？

問題があるかどうか考えてみましょう。 結局のところ、Androidに企業アプリケーションをインストールする方法はいくつかあります。

• Google Play
  これがAndroidアプリケーションの場合は、ゲートに放り込んで、それで終わりです。 問題ありません！ だから、そうではない。 第一に、すべての顧客が公営店舗での内部使用のためにアプリケーションを見たいとは限りません。

第二に、常識では、会社の従業員ではないユーザーにとっては、公開アプリケーションがユーザーの閉じたグループのみに焦点を合わせていることは問題に思えるかもしれません。

Appleは間違いなく握手をしている。 Googleの物事はよりシンプルで、厳密な制御はありません。 しかし、基本的な倫理があります。 このようなアプリケーションを使用してストアをスローすることは、開発者にとって適切な動作ではありません。

3番目の理由もあります。 企業には複数の企業モバイルアプリケーションがある場合があります。 また、公式アプリケーションストアでそれらを探す必要がなく、すべてが1か所にある場合に便利です。

• 会社のウェブサイト
  OK、サイト上のすべてのアプリケーションをドロップし、リンクを配置しましょう。 これらのリンクを使用して、ユーザーはサイトからアプリケーションをダウンロードできます。 メカニズムは機能しているようで、ページは美しいです。 しかし、アプリケーションを更新する必要があることをユーザーに通知する方法はありますか？

はい、アプリケーションに自己更新メカニズムを組み込むことができます。 起動時に、アプリケーションはサーバーに移動し、新しいアセンブリがインストールされているかどうかを確認します。 もしそうなら、それは自己交換のプロセスを開始します。 このようなスキームは機能しますが、パフォーマンスを維持するには多大な労力が必要です。

• MDMプロバイダー
  MDMソリューションは、現在多くの製品が市場に出回っている企業でのモバイルアプリケーションの配布に最適です。 すべてが非常に便利です。 ストアからMDMエージェントをダウンロードし、アプリケーションにログインすると、従業員のスマートフォンが実行されます。 サーバーから従業員の電話まで、セキュリティポリシーを設定したり、公式ストアのアプリケーションを有効または無効にしたり、企業アプリケーションをインストールしたりできます。 それは夢のように聞こえます...しかし、夢は高価です。

よく知られているMDM AirWatchソリューションの例では、デバイス1台あたり月額4〜6ドルで会社が注いでいることがわかります。

従業員ごとに毎年多額を支払う必要があるのは恥ずかしいことです。 また、従業員が多い場合はどうなりますか？ 率直に言って、それは高価な喜びです。

• F-ドロイド
  ソース（ https://gitlab.com/fdroid ）で利用可能なF-Droidをニーズに合わせて調整するオプションがあります。 しかし、このソリューションは重く、2〜3社のアプリケーションに使用することは冗長のようです。

  
  
• Android for Work
  Googleのソリューションの機能を使用することは素晴らしいことです。 しかし現時点では、これは顧客企業が「組織にAndroid for Workサービスを含め、企業のモバイルインフラストラクチャを管理するサービスのプロバイダーを選択する」ことを要求していることを意味します（ リンク ）。 つまり、本質的に、EMMソリューションのプロバイダーにお金を払わなければならないことを再び理解します。

ご覧のとおり、それぞれのアプローチは十分ではありませんでした。 これにより、考えを集め、アプリケーションストアを設計および実装しました。
実装の詳細についてさらに説明します。

まず最初に

ストアを便利にするには、利用可能なアプリケーションのリストを表示するだけでは不十分です。 新しいバージョンの確認、アプリケーションディストリビューションのダウンロードとインストールなど、多くの使い慣れたユーザーアクションをプログラムに教える必要があります。 幸いなことに、Android APIはそのような機能を実装するための多くの便利なツールを提供します。

使用可能なアプリケーションのリストを取得する

おそらく最も簡単な部分:)データの形式と内容についてサーバーと交渉し、利用可能なアプリケーションに関する情報のリストを提供するように彼に教える必要があります。 誰もがHTTPS / REST / JSONが大好きです。

コンテンツに関しては、アプリケーションごとに以下を報告します。

• ID AppId、逆ドメイン表記。
• アプリケーションの名前。
• versionCode。 アプリケーションのバージョンを表す整数。 ユーザーにはこの番号は表示されませんが、アプリケーションの現在のバージョンが最新かどうかは明確に示されます。
• versionName。 ユーザーに表示されるアプリケーションのバージョン。 任意の文字列を使用できますが、通常は「1.19.144」のようになります
• アプリケーションに関する簡単な情報。
• アプリケーションアイコンへのリンク。 どこにもアイコンはありません。
• アプリケーション配布パッケージへのリンク。 ユーザーがこのアプリケーションのインストール/更新を決定した場合、後で役立ちます。

サーバーからの応答例：

[ { "id": "etr.appstore", "name": "App Store", "info": "      ", "versionName": "1.3", "versionCode": 6, "url": "https://myappstore.ru/appstore/etr.appstore.apk", "icon": "https://myappstore.ru/appstore/appstore/etr.appstore.android.png" }, { "id": "ru.eastbanctech.mobileregistrator", "name": " ", "info": "     ,           ", "versionName": "v1.1.5", "versionCode": 115, "url": "https://myappstore.ru/appstore/appstore/ru.eastbanctech.mobileregistrator.release.apk", "icon": "https://myappstore.ru/appstore/appstore/ru.eastbanctech.mobileregistrator.release.android.png" } ] 

ストア自体のモバイルクライアントもアプリケーションストアにあるため、自身を更新できることに注意してください:)

この問題を解決するために、Retrofit2 / OkHttpの使用が実質的に標準になりました。 RxJava-オプション。 インターネットからアイコンを表示するには、FacebookのFrescoを使用します。これは、他のプロジェクトで既に正常に使用されているためです。 ピカソは機能性と使いやすさの両方でフレスコと競合できますが。 ところで、私たちはすでにKotlinを使用しているので、記事のすべての例がその上にあります。

インストールされたアプリケーションに関する情報

ストアの各アプリケーションは、ユーザーによって既にインストールされている場合とまだインストールされていない場合があります。 さらに、インストールされた各アプリケーションは、現在のバージョンであるか、すでに古くなっている可能性があります。 もちろん、これはすべて、ストアのエンドユーザーを知るのに役立ちます。 幸いなことに、Android APIを使用すると、インストールされているすべてのアプリケーションに関する情報を取得できます。このため、特別な権限も必要ありません。

 val installedApps = context.packageManager.getInstalledPackages(PackageManager.GET_META_DATA) 

このコマンドは、インストールされたアプリケーションに関する情報をPackageInfo形式で返します 。 そこでは多くの有用なデータを見つけることができますが、 packageNameとversionCodeのみが有用です。

インストール済みのリストと利用可能なアプリケーションのリストを受け取ったら、結果のアプリケーションのリストとすべての結合情報を表示する必要があります。 RxJavaに関するいくつかの記事のチュートリアルのようですね。 ;）使用するRxJava：

  class RemoteAppModel //        class DeviceAppModel //        val storeAppsObs: Observable<List<RemoteAppModel>> = appsService.getApps() val localAppsObs: Observable<List<DeviceAppModel>> = deviceService.installedApps() Observable.combineLatest(storeAppsObs, localAppsObs) { onlineAppList, localAppList -> //     //              onlineAppList.map { onlineApp -> //       ,    val localApp = localAppList.find { it.id == onlineApp.id } AppInfo(onlineApp, localApp) } } 

結果のリストは、RecyclerViewなどを使用してユーザーに既に表示されています。 ユーザーが使用できるアクションのリストは非常に明白です。

• AppInfoモデルにlocalAppが含まれていない場合、アプリケーションはまだインストールされておらず、ダウンロード/インストールできます。
• モデルにlocalAppがある場合、ローカルコピーのバージョンコードとサーバー上のディストリビューションを比較する必要があります。 新しいバージョンがある場合は、再度ダウンロード/インストール（更新）します。

アプリケーションのインストール

アプリケーションのインストールでは、すべてがそれほど単純ではありません。 この問題は、次の2つの方法で解決できます。配布キットをインストールするか、プログラムで自分で実行するようにユーザーに依頼します。

最初のアプローチは非常に簡単に実装されます。

  //uri -    apk- override fun install(uri: Uri) { val intent = makeInstallerIntent(uri) context.startActivity(intent) } private fun makeInstallerIntent(uri: Uri): Intent { val intent = Intent(Intent.ACTION_VIEW) intent.setDataAndType(uri, "application/vnd.android.package-archive") intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) { //  Android N             Uri, //        ,        val targets = context.packageManager.queryIntentActivities(intent, PackageManager.MATCH_DEFAULT_ONLY) targets.forEach { info -> context.grantUriPermission(info.activityInfo.packageName, uri, Intent.FLAG_GRANT_READ_URI_PERMISSION) } } return intent } 

意図を開始し、制御を配布システムのインストーラーの手に渡します。

2番目のインストール方法ではさらに多くのコードが必要になりますが、主な問題はコードの量ではなく、apkファイルのプログラムインストールにはプログラムがandroid.permission.INSTALL_PACKAGES特権を必要とするという事実です。

次の2つの場合、アプリケーションをシステムと見なすことができます。

• アプリケーションは、ファームウェアと同じキーで署名されています
• アプリケーションは、Androidのバージョンに応じて、/ system / priv-appまたは/ system / appディレクトリにインストールされます。 ルートアクセスを使用してシステムパーティションにアプリケーションをインストールするか、ファームウェアとMODをインストールするのと同じ方法でブートローダーと回復モードでインストールできます。

ご存じのとおり、すべてのユーザーが2番目の方法でストアのインストールに対処できるわけではありません。 ただし、両方のオプションを組み合わせることに煩わされることはありません。別のプラグインアプリケーションでソフトウェアインストールを実装します。 クライアントは、インストールされたプラグインの可用性を確認し、利用可能な場合はインストールを委任できます。それ以外の場合は、通常の方法でディストリビューションをインストールします。 2番目のパスに従うことにした場合、いくつかの有用なリソースがあります。

• システムインストーラーのソースコード
• F-Droidのシステムインストーラプラグイン

更新を確認する

彼らの正しい心の誰もが1時間ごとに店を開いて新しいバージョンをチェックすることはありません、電話はそれを独立してそして目に見えないようにユーザーに行うべきです。 Androidには、定期的なバックグラウンド作業を行う方法がいくつか用意されています。 多くの一般的な方法を分析しました。

アラームマネージャー

おそらく最も人気のある方法です。 ネットワーク上でAlarmManagerを使用するための十分な指示とガイドがあります。

長所：

• すべてのAPIで動作します
• バッテリーを消耗しないように構成できます
• 時間、イベント、定期的にタスクスケジュールを柔軟に構成できます。
• 非常に人気：見つけやすいドキュメントと使用例

短所：

• 再起動後に機能しなくなる
• プロセスを交換すると動作しなくなる
• アプリケーション設定から強制終了してオフにすると動作しなくなる

再起動後、ブロードキャストBOOT_COMPLETEを聞くと、回復を試みることができます。

SyncAdapterおよびSyncService

ローカルデータとサーバー上のデータを同期するように設計されています。 やりたいことだけ。

長所：

• リストされた短所AlarmManagerがありません
• インターネットアクセスがある場合にのみ開始されます（おそらくマイナス:)）

短所：

• あなたはそれを機能させるために多くの定型コードを書く必要があります
• 定期的なバックグラウンド作業専用に設計されているため、柔軟なバックグラウンド作業スケジュールを設定することは困難です

Jobcheduler

AlarmManagerとSyncAdapterの利点を組み合わせた素晴らしいフレームワーク。 安定、効率的かつ柔軟に動作します。 欠点が1つあります：API 21+

Firebase JobDispatcher

バックポートJobSchedulerと見なすことができます。

長所：

• すべてのAPIで実行されるJobScheduler

短所：

• デバイスにGooglePlayServicesが必要です

どちらを選択するかは個々の問題です。 以前のロリポップのSyncAdapterとAPI 21+のJobSchedulerのスキームにこだわります。

サーバー

最初は、Firbase Hostingをバックエンドとして使用して、独自のサーバーなしで完全に行うことができました。 ホスティングには、すべてのメタ情報を含むすべてのapkファイル、アイコン、jsonファイルがありました。 このようなスキームはしばらくの間は機能しましたが、多くの明らかな欠点がありました。誰もjsonファイルを手動で書きたくないため、間違ったものを書き込む大きなリスクがあります。

そこで、このプロセスを自動化し、NodeJSに基づいてサーバーを作成することにしました。
多種多様なnpmライブラリの中で、apkファイルからversionCode 、 versionNameさらにはアプリケーションアイコンを取得できる非常に便利なapp-bundle-infoモジュールを見つけました。

その結果、アプリケーションの公開時の人的要因が最小限に抑えられます。サーバーは、配布の有効性を独立して検証し、すべての技術情報を独自に取得します。

おわりに

会社の従業員にモバイルアプリケーションを提供するというアイデアは適切で正しいものですが、同時に、アプリケーションの配信と関連性のサポートの問題を解決する必要があります。

この記事では、従業員が企業アプリケーションのリストを手元に置いてインストールできるだけでなく、それらを更新するメカニズムも提供する方法について説明しています。

開始するには、デバイスの設定で不明なソースからアプリケーションをインストールし、ストアアプリケーションをダウンロードする機能を有効にする必要があります。その後、すべてが半自動モードで実行されます。 アプリストア自体も、新しいバージョンとアップデートをダウンロードできます。

このソリューションは、COPEスキームに非常に適しています（従業員に会社の電話が与えられ、事前のセットアップ手順が既に実行されている場合）。

私たちにとって、このアプローチは特定の顧客に結び付けられていないため、良いものでもありました。 ソリューションは再利用できます。 アプリケーションがダウンロードされるサーバーのアドレスを、アプリケーションストア内の会社のロゴから置き換えるだけで十分です。

良い一日と企業のアプリケーションをお楽しみください！