既存の Android アプリケーションのマイグレーション

improve this page | report issue

概説

IBM MobileFirst Platform Foundation バージョン 6.2.0 以降で作成された既存のネイティブ Android プロジェクトをマイグレーションするには、現行バージョンの SDK を使用するようにプロジェクトを変更する必要があります。 次に、v8.0 で使用が中止された、または v8.0 に含まれていないクライアント・サイド API を置き換えます。 マイグレーション・アシスト・ツールはコードをスキャンし、置き換える API のレポートを生成できます。

ジャンプ先

バージョンアップの前準備として既存の MobileFirst ネイティブ Android アプリケーションをスキャン

マイグレーション・アシスト・ツールは、ネイティブ Android アプリケーションのソースをスキャンし、V8.0 で非推奨または使用中止となった API のレポートを生成することにより、IBM Mobile Foundation の以前のバージョンで作成されたアプリケーションのマイグレーションの準備を支援します。

マイグレーション・アシスト・ツールを使用する前に、以下の情報を知っておくことが重要です。

  • 既存の Mobile Foundation ネイティブ・アプリケーションがある必要があります。
  • インターネット・アクセスが必要です。
  • node.js バージョン 4.0.0 以降がインストールされている必要があります。
  • マイグレーション・プロセスの制限についてよく読み、理解します。 詳しくは、以前のリリースからのアプリケーションのマイグレーションを参照してください。

以前のバージョンの Mobile Foundation で作成されたアプリケーションは、一部変更を行わないと V8.0 ではサポートされません。 マイグレーション・アシスト・ツールは、既存のアプリケーションのソース・ファイルをスキャンすることによりこのプロセスを簡素化し、V8.0 で非推奨となった API、非サポート対象となった API、または変更された API を識別します。

マイグレーション・アシスト・ツールでは、アプリケーションの開発者コードおよびコメントの変更や移動は行いません。

  1. 以下のいずれかの方法を使用してマイグレーション・アシスト・ツールをダウンロードします。
    • Git リポジトリーから .tgz ファイルをダウンロードします。
    • MobileFirst Operations Console から MobileFirst Developer Kit をダウンロードします。これには、mfpmigrate-cli.tgz という名前のファイルとしてマイグレーション・アシスト・ツールが含まれています。
  2. マイグレーション・アシスト・ツールをインストールします。
    • ツールをダウンロードしたディレクトリーに移動します。
    • 以下のコマンドを入力することにより、NPM を使用してツールをインストールします。
    npm install -g
    
  3. 以下のコマンドを入力して、Mobile Foundation アプリケーションをスキャンします。

    mfpmigrate scan --in source_directory --out destination_directory --type android
    

    source_directory
    プロジェクトの現在のロケーション。

    destination_directory
    レポートが作成されるディレクトリー。

    マイグレーション・アシスト・ツールを scan コマンドと共に使用した場合、このツールは、既存の Mobile Foundation アプリケーション内にある、V8.0 で削除された API、非推奨となった API、または変更された API を識別し、識別された宛先ディレクトリーにそれらを保存します。

Gradle を使用した Android プロジェクトのマイグレーション

Gradle を使用して、MobileFirst SDK が追加された Android アプリケーションをマイグレーションします。

Android Studio および Android SDK が適切にセットアップされていることを確認します。 システムのセットアップ方法について詳しくは、Android Studio 概要を参照してください。 プロジェクトは、Android Studio/Gradle セットアップに準拠していて、Mobile Foundation にアップグレードする前にエラーなしでコンパイルされる必要があります。

注: このタスクでは、Android プロジェクトが Android Studio を使用して作成されていること、および Android Studio (7.1) の使用による新規アプリケーションまたは既存アプリケーションへの Mobile Foundation SDK の追加で述べられているように、MobileFirst SDK が追加されていることを想定しています。

Android Studio プロジェクトが、MobileFirst SDK の以前のバージョンを追加するようにセットアップされている場合は、build.gradle 依存関係エンクロージャーから compile グループを削除します。 例えば、7.1 からアップグレードする場合は、以下のグループを削除します。

compile group: 'com.ibm.mobile.foundation',
            name:'ibmmobilefirstplatformfoundation',
            version:'7.1.0.0',
            ext: 'aar',
            transitive: true

これで、ローカルまたはリモートの SDK ファイルを使用して V8.0.0 の SDK と構成を追加できるようになりました。 Android アプリケーションへの MobileFirst SDK の追加を参照してください。

注: 新しい SDK をインポートした後は、Javadoc ファイルを手動でインポートする必要があります。 『Android Studio Gradle プロジェクトへの Javadoc の登録』を参照してください。

これで、MobileFirst SDK を使用してネイティブ Android アプリケーションの開発を始めることができます。 V8.0.0 での API の変更にコードを適合させる必要がある場合があります (Android コードの更新を参照)。

次の作業

使用が中止された、または V8.0 に含まれていないクライアント・サイド API を置き換えます。

Android コードの更新

IBM Mobile Foundation V8.0 では、Android SDK に対する多くの変更が導入されています。これにより、以前のバージョンで開発されたアプリケーションの変更が必要になる可能性があります。
以下の表では、MobileFirst Android SDK の変更をリストします。

使用が中止された Android API エレメント

API エレメント マイグレーション・パス
WLConfig WLClient.getConfig() 代替はありません。
  • WLDevice WLClient.getWLDevice()
  • WLClient.transmitEvent(org.json.JSONObject event)
  • WLClient.setEventTransmissionPolicy(WLEventTransmissionPolicy policy)
  • WLClient.purgeEventTransmissionBuffer()
GeoLocation 用の Android API またはサード・パーティー・パッケージを使用してください。
  • WL.Client.getUserInfo(realm, key)
  • WL.Client.updateUserInfo(options)
代替はありません。
  • WL.Client.getUserInfo(realm, key
  • WL.Client.updateUserInfo(options)
代替はありません。
WLClient.checkForNotifications() WLAuthorizationManager.obtainAccessToken("", listener) を使用して、サーバーへの接続を確認し、アプリケーション管理ルールを適用してください。
  • WLClient.login(java.lang.String realmName, WLRequestListener listener, WLRequestOptions options)
  • WLClient.login(java.lang.String realmName, WLRequestListener listener)
AuthorizationManager.login()を使用します。
  • WLClient.logout(java.lang.String realmName, WLRequestListener listener, WLRequestOptions options)
  • WLClient.logout(java.lang.String realmName, WLRequestListener listener)
AuthorizationManager.logout()を使用します。
WLClient.obtainAccessToken(java.lang.String scope,WLResponseListener responseListener) WLAuthorizationManager.obtainAccessToken(String, WLAccessTokenListener) を使用して、サーバーへの接続を確認し、アプリケーション管理ルールを適用してください。
  • WLClient.getLastAccessToken()
  • WLClient.getLastAccessToken(java.lang.String scope)
AuthorizationManagerを使用してください。
WLClient.getRequiredAccessTokenScope(int status, java.lang.String header) AuthorizationManagerを使用してください。
WLClient.logActivity(java.lang.String activityType) com.worklight.common.Logger を使用してください。
WLAuthorizationPersistencePolicy 代替はありません。 許可パーシスタンスを実装するには、許可トークンをアプリケーション・コードに保管し、カスタム HTTP 要求を作成します。 詳しくは、Java™ カスタム・リソース要求実装サンプルを参照してください。
  • WLSimpleSharedData.setSharedToken(myName, myValue)
  • WLSimpleSharedData.getSharedToken(myName)
  • WLSimpleSharedData.clearSharedToken(myName)
Android API を使用して、アプリケーション間でトークンを共有してください。
WLUserCertificateManager.deleteCertificate(android.content.Context context) 代替はありません。
BaseChallengeHandler.submitFailure(WLResponse wlResponse) BaseChallengeHandler.cancel() を使用します。
ChallengeHandler カスタム・ゲートウェイ・チャレンジには、GatewayChallengeHandler を使用します。 MobileFirst セキュリティー検査チャレンジには、SecurityCheckChallengeHandler を使用します。
WLChallengeHandler SecurityCheckChallengeHandler を使用します。
ChallengeHandler.isCustomResponse() GatewayChallengeHandler.canHandleResponse() を使用します。
ChallengeHandler.submitAdapterAuthentication チャレンジ・ハンドラーで同様のロジックを実装してください。 カスタム・ゲートウェイ・チャレンジ・ハンドラーには、GatewayChallengeHandler を使用します。

サポートされなくなった、レガシー org.apach.http API に依存している Android API

API エレメント マイグレーション・パス
org.apache.http.Header[] は非推奨になりました。 そのため、以下のメソッドは削除されました。  
org.apache.http.Header[] WLResourceRequest.getAllHeaders() 代わりに、新しい Map<String, List<String>> WLResourceRequest.getAllHeaders() API を使用してください。
WLResourceRequest.addHeader(org.apache.http.Header header) 代わりに、新しい WLResourceRequest.addHeader(String name, String value) API を使用してください。
org.apache.http.Header[] WLResourceRequest.getHeaders(java.lang.String headerName) 代わりに、新しい List<String> WLResourceRequest.getHeaders(String headerName) API を使用してください。
org.apache.http.Header WLResourceRequest.getFirstHeader(java.lang.String headerName) 代わりに、新しい WLResourceRequest.getHeaders(String headerName) API を使用してください。
WLResourceRequest.setHeaders(org.apache.http.Header[] headers) 代わりに、新しい WLResourceRequest.setHeaders(Map<String, List<String>> headerMap) API を使用してください。
WLResourceRequest.setHeader(org.apache.http.Header header) 代わりに、新しい WLResourceRequest.setHeaders(Map<String, List<String>> headerMap) API を使用してください。
org.apache.http.client.CookieStore WLClient.getCookieStore() ClearableCookieJar WLClient.getPersistentCookies()と置き換えられました。
WLClient.setAllowHTTPClientCircularRedirect(boolean isSet) 代替はありません。 MFP クライアントでは、サーキュラー・リダイレクトが許可されます。
  • WLHttpResponseListener
  • WLResourceRequestWLHttpResponseListener を取る以下のすべてのメソッド:
    • WLResourceRequest.send(java.util.HashMap formParameters,WLHttpResponseListener listener)
    • WLResourceRequest.send(org.json.JSONObject json, WLHttpResponseListener listener)
    • WLResourceRequest.send(byte[] data, WLHttpResponseListener listener)
    • WLResourceRequest.send(java.lang.String requestBody,WLHttpResponseListener listener)
    • WLResourceRequest.send(WLHttpResponseListener listener)
    • WLClient.sendRequest(org.apache.http.client.methods.HttpUriRequest request,WLHttpResponseListener listener)
    • WLClient.sendRequest(org.apache.http.client.methods.HttpUriRequest request, WLResponseListener listener)
非推奨になった Apache HTTP クライアント依存関係のために削除されました。 要求および応答を完全に制御できる独自の要求を作成してください。
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on November 27, 2019