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!
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.
AndroidManifest.xml
build.gradle
(the one for the Module app)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.
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2020/01/2019-12-02_17h09_12.png?w=656&h=423)
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.
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.
4 thoughts on “Adobe Experience Platform Mobile SDKs – Prerequisites”