Adobe Experience Platform Mobile SDKs – Prerequisites

Welcome to part 1 of the Adobe Experience Platform Mobile SDKs mini-series. This part is about prerequisites.

You can find the overview here.

Prerequisites

I have had Android phones since the HTC Desire HD came out, so all my examples for mobile are always in Java, for Android. I am also firmly in the not-Mac camp, so the first prerequisite for me is to download and install Android Studio for Windows.

Next you need to load and install an SDK, and decide whether you want to debug using your phone, or an emulator. There are resources out there that tell you how to do all of this. Since you are a developer, I trust you’ll be fine with those.

Right. So you have Android Studio, the correct SDK(s), and you created yourself a virtual phone using the AVD Manager.

Onwards.

Launch

When you want to tag a mobile app using the Adobe Experience Platform Mobile SDKs, you need a Launch Property.

Head over to Launch, then create a Property. Make sure you make it a Mobile Property!

When you look at the Extensions, you’ll notice that mobile Properties come with two of them per default: Mobile Core, and Profile

Create a Library, add those two Extensions, build it, then push it all the way to Production.

That’s all we need to do in Launch for now.

Android Project

I know you might think this should be part of the coding chapter, but we’re really only setting up a project and adding Launch, so I decide that those are prerequisites, too.

Open Android Studio and follow the “Start a new Android Studio project” wizard.

For the Android app to load the AEP Mobile SDKs, you must modify three files:

1. AndroidManifest.xml
2. build.gradle (the one for the Module app)
3. MainActivity.java (or whatever your app’s main class is called)

You change AndroidManifest.xml to add necessary permissions, you amend build.gradle so the build process will load and embed the libraries needed by the AEP Mobile SDKs, and you add code to MainActivity.java that initialises all those libraries when the app launches.

AndroidManifest.xml

For the SDKs to work, the app has to be able to access the Internet, of course. So we need to add two lines to the AndroidManifest.xml file:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

The second permission is necessary so the SDKs can decide whether they can connect and send, or whether the device is offline. If the device should be offline, the SDKs can, depending on Extensions, buffer data, or just decide to not send.

build.gradle

Gradle is a standard build system on Android. The Adobe Experience Platform Mobile SDKs can be used directly with gradle (and CocoaPods if you develop for iOS).

You manage which parts of the SDKs you need in Launch, and then copy the right modules into build.gradle so that the app will actually include them when it is built.

For our very easy setup, we have to add the following lines in the dependencies section:

implementation 'com.adobe.marketing.mobile:userprofile:1.+'
implementation 'com.adobe.marketing.mobile:sdk-core:1.+'

These lines can be copied straight from the “Environments” tab in Launch, if you like:

MainActivity.java

Our app currently has only one Activity (or screen, or what on iOS would be called a View), and the code behind this Activity sits in MainActivity.java.

This is where we must initialise everything, including the AEP Mobile SDKs.

You can copy the code from Launch, like you did for build.gradle

If you paste that correctly, the onCreate method will look like this:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    MobileCore.setApplication(this.getApplication());
    MobileCore.setLogLevel(LoggingMode.DEBUG);

    try {
        UserProfile.registerExtension();
        Identity.registerExtension();
        Lifecycle.registerExtension();
        Signal.registerExtension();
        MobileCore.start(new AdobeCallback() {
            @Override
            public void call(Object o) {
                MobileCore.configureWithAppID("3028746f70eb/d6b1ea7ebece/launch-e736742547f3");
            }
        });
    } catch (InvalidInitException e) {
        e.printStackTrace();
    }

    setContentView(R.layout.activity_main);
    Toolbar toolbar = findViewById(R.id.toolbar);
    setSupportActionBar(toolbar);

    FloatingActionButton fab = findViewById(R.id.fab);
    fab.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View view) {
            Snackbar.make(view, "Replace with your own action", Snackbar.LENGTH_LONG)
                    .setAction("Action", null).show();
        }
    });
}

The code here initialises the SDK, sets the log level to DEBUG, then registers all Extensions that we are using.

Line 15 is the interesting bit, and the one that is different from the Mobile SDKs of old: the MobileCore.configureWithAppID() method will cause the app to query Launch for a configuration update.

Launch? Configuration update?

“Query Launch for a configuration update”? What?

Glad you asked!

With the AEP Mobile SDKs, the configuration is no longer done via the ADBMobileConfig.json file. Instead, apps will on first launch query a URL hosted by Launch, and that URL will deliver a configuration. The app will cache the configuration, just in case.

On subsequent starts, the app will again query Launch for (updated) configuration, but it will fall back to using the cache if that is recent or if it is necessary.

So the configuration of the SDK happens in Launch, these days.

Example: if you want to add Analytics to your app, you start by adding the Analytics Extension to your property, and when you do so, you configure things like the Report Suite ID right there.

A very obvious question then is: how much can you change in Launch, and where does it end, i.e. what changes come with an update of the app?

Parts of the answer are easy:

• If you add an Extensions, you need to update the app
• Updating to new versions of the SDKs or Extensions is done via an update of the app
• Passing any additional data into Analytics will likely mean you need to update the app
• If you want to remove any functionality, Extension, tracking, you will have to update the app
• If you change the report suite ID in the Analytics Extension, you do not have to update the app

There will be an article later in the series about probing the limits of what Launch can and cannot do.

For now, we are done with the prerequisites. Next time, we’ll learn how to add Target to our app.