Untersuchen des Vorlagenprojekts

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

• Navigieren in der Projektstruktur für Mobile SDK React Native-Anwendungen
• Konfigurieren Ihres Projekts für Debugging oder Produktion
• Finden der Mobile SDK React Native-Beispielanwendung und Open Source Libraries auf GitHub

Wenn Sie eine Anwendung mit forcereact erstellen, passt das Skript eine Vorlage mit den Argumenten an, die Sie zur Verfügung stellen. Diese angepasste Vorlage ist das Projekt für Ihre neue Mobile SDK-Anwendung. Für React Native definiert die Vorlage eine native Containeranwendung, die direkten Zugriff auf das native Betriebssystem ermöglicht. Dieser Container bildet die Brücke zwischen Ihrem JavaScript-Code und der Android- oder iOS-Laufzeitumgebung. In einigen Fällen kann es sein, dass Ihre Entwicklungsanforderungen Anpassungen an diesem zugrundeliegenden Container notwendig machen. Schauen wir uns kurz an, was in der Anwendung enthalten ist.

Der iOS-native Teil des Vorlagenprojekts ist nahezu identisch mit dem eines nativen iOS-Projekts. Seine zwei Klassen übernehmen Folgendes:

• Konfigurieren von Mobile SDK für den Start
• Instanziieren und Anzeigen der Stammansicht
• Initiieren und Durchführen von Login und Authentifizierung

Öffnen Sie <Ausgabeverzeichnis>/ios/FirstReact.xcworkspace in Xcode. Beim Ansehen der Arbeitsumgebung kann leicht der Eindruck entstehen, dass es sich um ein natives iOS-Projekt handelt. Die AppDelegate-Klasse enthält beispielsweise den Großteil der Codebausteine einer nativen iOS-Anwendung. Der React-spezifische Code befindet sich in der Methode setupRootViewController von AppDelegate.

- (void)setupRootViewController
{
    NSURL *jsCodeLocation;
    jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" 
                                                                    fallbackResource:nil];
    RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation
                                                        moduleName:@"SecondReact"
                                                 initialProperties:nil
                                                     launchOptions:self.launchOptions];
    rootView.backgroundColor = [[UIColor alloc] initWithRed:1.0f 
                                                      green:1.0f 
                                                       blue:1.0f 
                                                      alpha:1];
    UIViewController *rootViewController = [UIViewController new];
    rootViewController.view = rootView;
    self.window.rootViewController = rootViewController;
}

Öffnen Sie in Android Studio Ihr Projekt FirstReact/android, wechseln Sie in die Projektansicht und sehen Sie unter FirstReact/app/app/src/main/java/com.mytrail.react nach. Dort finden Sie zwei native Java-Klassen: MainActivity und MainApplication. Diese Klassen sind vergleichbar mit ihren rein nativen Mobile SDK-Gegenstücken.

Die Klassen MainApplication und MainActivity erfüllen dieselben Zwecke wie in nativen Android-Projekten:

• Konfigurieren von Mobile SDK für den Start
• Instanziieren und Anzeigen der Startaktivitäten
• Initiieren und Durchführen von Login und Authentifizierung

Die Hauptunterschiede zwischen nativen und React Native-Vorlagen für diese Klassen sind ihre Basisklassen. In React Native-Anwendungen erweitert MainApplication meist Application, implementiert aber auch ReactApplication. MainActivity erweitert die Klasse SalesforceReactActivity, die wiederum ReactActivity erweitert. ReactApplication und ReactActivity stammen aus der React Native-Bibliothek von Facebook. Bei genauer Betrachtung der Implementierungen stellt man fest, dass die meisten Codepfade letztendlich zu einem React Native-Objekt führen. Zu diesen Objekten gehören React-orientierte Spezialisierungen vieler Mobile SDK-Klassen wie SalesforceReactSDKManager.

private final ReactNativeHost mReactNativeHost = new ReactNativeHost(this) {
   @Override
   public boolean getUseDeveloperSupport() {
      return BuildConfig.DEBUG;
   }
   @Override
   protected List<ReactPackage> getPackages() {
      @SuppressWarnings("UnnecessaryLocalVariable")
      List<ReactPackage> packages = new PackageList(this).getPackages();
      // Packages that cannot be autolinked yet can be added manually here, for example:
      // packages.add(new MyReactNativePackage());
      packages.add(SalesforceReactSDKManager.getInstance().getReactPackage());
      return packages;
   }
   @Override
   protected String getJSMainModuleName() {
      return "index";
   }
};

@Override public List<NativeModule> createNativeModules(ReactApplicationContext reactContext) {
   List<NativeModule> modules = new ArrayList<>();  
   modules.add(new SalesforceOauthReactBridge(reactContext));
   modules.add(new SalesforceNetReactBridge(reactContext));
   modules.add(new SmartStoreReactBridge(reactContext));
   modules.add(new MobileSyncReactBridge(reactContext));
   return modules;
}

Die React Native-Laufzeit ruft diese Methode und andere Überschreibungen auf, um den Zauber zu wirken, der JavaScript-Methoden als nativen Mobile SDK-Code ausführt.

/*** The react.gradle file registers a task for each build variant (e.g. bundleDebugJsAndAssets
* and bundleReleaseJsAndAssets).
* These basically call `react-native bundle` with the correct arguments during the Android build
* cycle. By default, bundleDebugJsAndAssets is skipped, as in debug/dev mode we prefer to load the
* bundle directly from the development server. Below you can see all the possible configurations
* and their defaults. If you decide to add a configuration block, make sure to add it before the
* `apply from: "../../node_modules/react-native/react.gradle"` line.
*
* project.ext.react = [
*   // the name of the generated asset file containing your JS bundle
*   bundleAssetName: "index.bundle",
*
*   // the entry file for bundle generation
*   entryFile: "index.js",
*
*   // whether to bundle JS and assets in debug mode
*   bundleInDebug: false,
*
*   // whether to bundle JS and assets in release mode
*   bundleInRelease: true,
*
*   // whether to bundle JS and assets in another build variant (if configured).
*   // See http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
*   // The configuration property can be in the following formats
*   //         'bundleIn${productFlavor}${buildType}'
*   //         'bundleIn${buildType}'
*   // bundleInFreeDebug: true,
*   // bundleInPaidRelease: true,
*   // bundleInBeta: true,
*
*   // the root of your project, i.e. where "package.json" lives
*   root: "../../",
*
*   // where to put the JS bundle asset in debug mode
*   jsBundleDirDebug: "$buildDir/intermediates/assets/debug",
*
*   // where to put the JS bundle asset in release mode
*   jsBundleDirRelease: "$buildDir/intermediates/assets/release",
*
*   // where to put drawable resources / React Native assets, e.g. the ones you use via
*   // require('./image.png')), in debug mode
*   resourcesDirDebug: "$buildDir/intermediates/res/merged/debug",
*
*   // where to put drawable resources / React Native assets, e.g. the ones you use via
*   // require('./image.png')), in release mode*   resourcesDirRelease: "$buildDir/intermediates/res/merged/release",
*
*   // by default the gradle tasks are skipped if none of the JS files or assets change; this means
*   // that we don't look at files in android/ or ios/ to determine whether the tasks are up to
*   // date; if you have any other folders that you want to ignore for performance reasons (gradle
*   // indexes the entire tree), add them here. Alternatively, if you have JS files in android/
*   // for example, you might want to remove it from here.
*   inputExcludes: ["android/**", "ios/**"],
*
*   // override which node gets called and with what additional arguments
*   nodeExecutableAndArgs: ["node"]
*
*   // supply additional arguments to the packager
*   extraPackagerArgs: []
* ]
*/