Vorhandene Android-Anwendungen umstellen

improve this page | report issue

Übersicht

Wenn Sie ein mit der IBM MobileFirst Platform Foundation ab Version 6.2.0 erstelltes natives Android-Projekt migrieren möchten, müssen Sie das Projekt so modifizieren, dass es das SDK der aktuellen Version verwendet. Ersetzen Sie dann die clientseitigen APIs, die weggefallen oder nicht in Version 8.0 enthalten sind. Das Unterstützungstool für die Migration kann Ihren Code scannen und Berichte zu den zu ersetzenden APIs generieren.

Fahren Sie mit folgenden Abschnitten fort:

Vorhandene native MobileFirst-Android-Apps in Vorbereitung eines Versionsupgrades scannen

Das Unterstützungstool für die Migration hilft Ihnen, Ihre mit einer früheren Version der IBM Mobile Foundation erstellten Apps vorzubereiten, indem es die Quellen der nativen Android-App scannt und einen Bericht der in Version 8.0 weggefallenen oder nicht weiter unterstützten APIs generiert.

Die folgenden Informationen müssen vor Verwendung des Unterstützungstools für die Migration beachtet werden:

  • Sie benötigen eine native, mit der Mobile Foundation erstellte Android-Anwendung.
  • Sie benötigen Internetzugriff.
  • Node.js ab Version 4.0.0 muss installiert sein.
  • Sie müssen die Einschränkungen des Migrationsprozesses kennen und verstehen. Weitere Informationen finden Sie unter Apps früherer Releases umstellen.

Mit früheren Versionen der Mobile Foundation erstellte Apps müssen geändert werden, damit sie in Version 8.0 unterstützt werden. Das Unterstützungstool für die Migration vereinfacht diesen Änderungsprozess, indem es die Quellendateien der vorhandenen App scannt und APIs identifiziert, die in Version 8.0 weggefallen sind oder nicht weiter unterstützt werden bzw. modifiziert wurden.

Das Unterstützungstool für die Migration modifiziert oder verschiebt keinen Entwicklercode und keine Kommentare Ihrer App.

  1. Wählen Sie eine der folgenden Alternativen, um das Unterstützungstool für die Migration herunterzuladen:
    • Laden Sie die .tgz-Datei aus dem Git-Repository herunter.
    • Laden Sie das MobileFirst Developer Kit über die MobileFirst Operations Console herunter. Das Kit enthält die Datei mfpmigrate-cli.tgz mit dem Unterstützungstool für die Migration.
  2. Installieren Sie das Unterstützungstool für die Migration.
    • Navigieren Sie zu dem Verzeichnis, in das Sie das Tool heruntergeladen haben.
    • Installieren Sie das Tool mit npm. Geben Sie dazu den folgenden Befehl ein:
    npm install -g
    
  3. Scannen Sie die mit der Mobile Foundation erstellte App. Geben Sie dazu den folgenden Befehl ein:

    mfpmigrate scan --in Quellenverzeichnis --out Zielverzeichnis --type android
    

    Quellenverzeichnis
    Aktuelle Position des Projekts

    Zielverzeichnis
    Verzeichnis, in dem der Bericht erstellt wird

    Wenn der Scanbefehl des Unterstützungstools für die Migration verwendet wird, identifiziert das Tool APIs in der vorhandenen, mit der Mobile Foundation erstellten App, die in Version 8.0 gelöscht oder geändert wurden oder nicht weiter unterstützt werden und speichert sie im angegebenen Zielverzeichnis.

Android-Projekt mit Gradle umstellen

Sie können Gradle verwenden, um Ihre Android-Anwendung mit dem MobileFirst-SDK zu migrieren.

Stellen Sie sicher, dass Sie Android Studio und das Android-SDK ordnungsgemäß eingerichtet haben. Weitere Informationen zur Einrichtung Ihres Systems finden Sie unter Android Studio Overview. Ihr Projekt muss mit dem Setup von Android Studio/Gradle konform gehen und fehlerfrei kompatibel sein, bevor Sie ein Upgrade auf die Mobile Foundation durchführen.

Hinweis: Bei diesem Schritt wird davon ausgegangen, dass das Android-Projekt mit Android Studio erstellt wurde und das MobileFirst-SDK hinzugefügt wurde (siehe SDK der Mobile Foundation in Android Studio (7.1) zu einer neuen oder vorhandenen Anwendung hinzufügen).

Wenn Ihr Android-Studio-Projekt für das Hinzufügen einer früheren Version des MobileFirst-SDK konfiguriert war, entfernen Sie compile group aus den Abhängigkeiten (“dependencies”) in build.gradle. Wenn Sie beispielsweise ein Upgrade für Version 7.1 durchführen, entfernen Sie die folgende Gruppe:

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

Jetzt können Sie mit lokalen oder fernen SDK-Dateien das SDK und die Konfiguration von Version 8.0.0 hinzufügen (siehe MobileFirst-SDK zu Android-Anwendungen hinzufügen).

Hinweis: Nach dem Import des neuen SDK müssen Sie die Javadoc-Dateien manuell importieren (siehe Javadocs in einem Android-Studio-Gradle-Projekt registrieren.

Jetzt können Sie mit dem Entwickeln Ihrer nativen Android-Anwendung mit dem SDK der MobileFirst beginnen. Möglicherweise müssen Sie Ihren Code an die Änderungen der API von Version 8.0.0 anpassen (siehe Android-Code aktualisieren).

Nächste Schritte

Ersetzen Sie die clientseitigen APIs, die weggefallen oder nicht in Version 8.0 enthalten sind.

Android-Code aktualisieren

In IBM Mobile Foundation Version 8.0 gibt es eine Reihe von Änderungen am Android-SDK, durch die Änderungen an Apps erforderlich sein können, die mit früheren Versionen entwickelt wurden.
In den folgenden Tabellen sind die Änderungen am MobileFirst-Android-SDK aufgelistet.

Weggefallene Android-API-Elemente

API-Element Migrationspfad
WLConfig WLClient.getConfig() Kein Ersatz
  • WLDevice WLClient.getWLDevice()
  • WLClient.transmitEvent(org.json.JSONObject event)
  • WLClient.setEventTransmissionPolicy(WLEventTransmissionPolicy policy)
  • WLClient.purgeEventTransmissionBuffer()
Verwenden Sie für die Geoortung die Android-API oder Pakete von anderen Anbietern.
  • WL.Client.getUserInfo(realm, key)
  • WL.Client.updateUserInfo(options)
Kein Ersatz
  • WL.Client.getUserInfo(realm, key
  • WL.Client.updateUserInfo(options)
Kein Ersatz
WLClient.checkForNotifications() Verwenden Sie [WLAuthorizationManager.obtainAccessToken("", listener)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/html/refjava-worklight-android-native/html/com/worklight/wlclient/api/WLAuthorizationManager.html?view=kc#obtainAccessToken(java.lang.String,%20com.worklight.wlclient.api.WLAccessTokenListener), um die Verbindungsmöglichkeiten zum Server zu überprüfen und Anwendungsmanagementregeln anzuwenden.
  • WLClient.login(java.lang.String realmName, WLRequestListener listener, WLRequestOptions options)
  • WLClient.login(java.lang.String realmName, WLRequestListener listener)
Verwenden Sie [AuthorizationManager.login()](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/html/refjava-worklight-android-native/html/com/worklight/wlclient/api/WLAuthorizationManager.html?view=kc#login(java.lang.String,%20org.json.JSONObject,%20com.worklight.wlclient.api.WLLoginResponseListener).
  • WLClient.logout(java.lang.String realmName, WLRequestListener listener, WLRequestOptions options)
  • WLClient.logout(java.lang.String realmName, WLRequestListener listener)
Verwenden Sie [AuthorizationManager.logout()](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/html/refjava-worklight-android-native/html/com/worklight/wlclient/api/WLAuthorizationManager.html?view=kc#logout(java.lang.String,%20com.worklight.wlclient.api.WLLogoutResponseListener).
WLClient.obtainAccessToken(java.lang.String scope,WLResponseListener responseListener) Verwenden Sie [WLAuthorizationManager.obtainAccessToken(String, WLAccessTokenListener)](http://www.ibm.com/support/knowledgecenter/en/SSHS8R_8.0.0/com.ibm.worklight.apiref.doc/html/refjava-worklight-android-native/html/com/worklight/wlclient/api/WLAuthorizationManager.html?view=kc#obtainAccessToken(java.lang.String,%20com.worklight.wlclient.api.WLAccessTokenListener), um die Verbindungsmöglichkeiten zum Server zu überprüfen und Anwendungsmanagementregeln anzuwenden.
  • WLClient.getLastAccessToken()
  • WLClient.getLastAccessToken(java.lang.String scope)
Verwenden Sie AuthorizationManager.
WLClient.getRequiredAccessTokenScope(int status, java.lang.String header) Verwenden Sie AuthorizationManager.
WLClient.logActivity(java.lang.String activityType) Verwenden Sie com.worklight.common.Logger.
WLAuthorizationPersistencePolicy Kein Ersatz. Für die Implementierung der Autorisierungspersistenz müssen Sie das Autorisierungstoken im Anwendungscode speichern und angepasste HTTP-Anforderungen erstellen. Weitere Informationen finden Sie im Implementierungsbeispiel für angepasste Java-Ressourcenanforderungen (Java™ custom resource-request implementation sample).
  • WLSimpleSharedData.setSharedToken(myName, myValue)
  • WLSimpleSharedData.getSharedToken(myName)
  • WLSimpleSharedData.clearSharedToken(myName)
Verwenden Sie für die anwendungsübergreifende Nutzung von Token die Android-APIs.
WLUserCertificateManager.deleteCertificate(android.content.Context context) Kein Ersatz
BaseChallengeHandler.submitFailure(WLResponse wlResponse) Verwenden Sie BaseChallengeHandler.cancel().
ChallengeHandler Verwenden Sie für angepasste Gateway-Abfragen GatewayChallengeHandler. Verwenden Sie für Abfragen von MobileFirst-Sicherheitsüberprüfungen SecurityCheckChallengeHandler.
WLChallengeHandler Verwenden Sie SecurityCheckChallengeHandler.
ChallengeHandler.isCustomResponse() Verwenden Sie GatewayChallengeHandler.canHandleResponse().
ChallengeHandler.submitAdapterAuthentication Implementieren Sie ähnliche Logik in Ihrem Abfrage-Handler. Verwenden Sie für angepasste Gateway-Abfrage-Handler GatewayChallengeHandler.

Von den traditionellen org.apach.http-APIs abhängige und nicht mehr unterstützte Android-APIs

API-Element Migrationspfad
org.apache.http.Header[] wird nicht mehr verwendet. Aus diesem Grund wurden die folgenden Methoden entfernt:  
org.apache.http.Header[] WLResourceRequest.getAllHeaders() Verwenden Sie stattdessen die neue API Map<String, List<String>> WLResourceRequest.getAllHeaders().
WLResourceRequest.addHeader(org.apache.http.Header header) Verwenden Sie stattdessen die neue API WLResourceRequest.addHeader(String name, String value).
org.apache.http.Header[] WLResourceRequest.getHeaders(java.lang.String headerName) Verwenden Sie stattdessen die neue API List<String> WLResourceRequest.getHeaders(String headerName).
org.apache.http.Header WLResourceRequest.getFirstHeader(java.lang.String headerName) Verwenden Sie stattdessen die neue API WLResourceRequest.getHeaders(String headerName).
WLResourceRequest.setHeaders(org.apache.http.Header[] headers) Verwenden Sie stattdessen die neue API WLResourceRequest.setHeaders(Map<String, List<String>> headerMap).
WLResourceRequest.setHeader(org.apache.http.Header header) Verwenden Sie stattdessen die neue API WLResourceRequest.setHeaders(Map<String, List<String>> headerMap).
org.apache.http.client.CookieStore WLClient.getCookieStore() Durch ClearableCookieJar WLClient.getPersistentCookies() ersetzt
WLClient.setAllowHTTPClientCircularRedirect(boolean isSet) Kein Ersatz. Der MFP-Client lässt kreisförmige Umleitungen zu.
  • WLHttpResponseListener
  • WLResourceRequest und alle Methoden, die WLHttpResponseListener verwenden:
    • 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)
Wegen nicht weiter unterstützter Apache-HTTP-Clientabhängigkeiten entfernt. Erstellen Sie Ihre eigene Anforderung, um volle Kontrolle über Anforderung und Antwort zu haben.
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 February 27, 2020