diff --git a/TOC.md b/TOC.md new file mode 100644 index 0000000..483ffdd --- /dev/null +++ b/TOC.md @@ -0,0 +1,52 @@ +--- +user-guide-title: Adobe Target Mobile v4 Tutorial +user-guide-url: /content/help/en/target-learn/mobile-sdk-v4/overview.html +audience: end-user +--- + +# Adobe Target Mobile v4 Tutorial {#mobile-sdk-v4} + ++ [Overview](overview.md) ++ [Download and Validate the Sample App](download-validate-and-update-the-sample-app.md) ++ [Add Requests](add-requests.md) ++ [Add Parameters](add-parameters.md) ++ [Personalize Layouts](personalize-layouts.md) ++ [Personalize with Geolocation](personalize-with-geolocation.md) ++ [Feature Flagging](feature-flagging.md) ++ [Recommendations](recommendations.md) + + diff --git a/add-parameters.md b/add-parameters.md new file mode 100644 index 0000000..a18b145 --- /dev/null +++ b/add-parameters.md @@ -0,0 +1,13 @@ +--- +title: +seo-title: +description: +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement +--- + +# Add Parameters diff --git a/add-requests.md b/add-requests.md new file mode 100644 index 0000000..22725ee --- /dev/null +++ b/add-requests.md @@ -0,0 +1,358 @@ +--- +title: Adobe Target location request scenarios +seo-title: Adobe Target location request scenarios +description: Adobe Target mobile SDK methods can be used to display Target locations in several scenarios. +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement +--- + +# Add Adobe Target Requests + +The Adobe Mobile Services SDK (v4) provides Adobe Target methods & functionality that enable personalize your app with different experiences for different users. + +In this lesson, you will implement + +## Learning Objectives + +At the end of this lesson, you will be able to: + +* **Implement and Use a Prefetch Request** +* **Implement and Use a Prefetch "Blocking" Request** +* **Implement and Use a Live Location Request** +* **Implement and Use a Batch Request with Multiple Target Locations in one Call** +* **Combine Prefetch & Live Locations** +* **Clear Prefetched offers from Cache** + +## We.Travel App + +This article discusses multiple scenarios using a sample travel app. The app has a search feature that finds available bus routes. The app will be used for demonstration purposes. + +* Target locations are prefetched on the home screen, so no Target content appears, but locations are cached in the device behind the scene +* The search results screen loads a Target location and displays banners based off a JSON offer loaded from the Target server. +![We.Travel app with Target serving a banner](assets/travel_app2.jpg) + +## Implement a Prefetch Request + +A prefetch request uses the Android Mobile SDKs to fetch offer content as few times as possible by caching the server responses. Creating a prefetch request with an array of locations can be configured to call the Target server and retrieve content for many locations at once. All content will be retrieved and cached, and will then be retrievable from the cache by all future calls for this content for the specified location names. Additional location names can be added to this array, as appropriate, to support the increased scope and sophistication of the install. + +Additional details - [Prefetch offer content in Android](https://docs.adobe.com/content/help/en/mobile-services/android/target-android/c-mob-target-prefetch-android.html) + +### prefetchContent() Code + +Here is the syntax of the Target.prefetchContent() Java request to be installed: + + +```java +public void targetPrefetchContent() { + List prefetchList = new ArrayList<>(); + Map profileParameters; + profileParameters = new HashMap(); + profileParameters.put("ProfileParam18Sep", "1"); + Map travelParameters1 = new HashMap(); + travelParameters1.put("travelParam18Sep", "1"); + travelParameters1.put("at_property", "7962ac68-17db-1579-408f-9556feccb477"); + prefetchList.add(Target.createTargetPrefetchObject("travelTest3", travelParameters1)); + Target.TargetCallback prefetchStatusCallback = new Target.TargetCallback() { + @Override + public void call(final Boolean status) { + HomeActivity.this.runOnUiThread(new Runnable() { + @Override + public void run() { + String cachingStatus = status ? "YES" : "NO"; + System.out.println("Received Response from prefetch : " + cachingStatus); + setUp(); + } + }); + }}; + Target.prefetchContent(prefetchList, profileParameters, prefetchStatusCallback); +} +``` + +### Validate the prefetch request + +Now that the SDK is implemented and our initial globalprefetch location call has been setup, let's validate the requests & responses from the Adobe Target Servers. The Adobe Target SDK can be validated on your mobile app by using an Android Emulator & reviewing verbose logging in your Android IDE environment. This article demonstrates how to use the Android Studio IDE to debug Target server calls for the Adobe Mobile Services SDK version 4. + +Android Studio's Android Emulator & Logcat feature can be used to validate requests & responses from the Adobe Target servers. If you're using a different IDE such as Eclipse, logging should follow a similar process. Importing your own Android app into Android Studio to use the Logcat feature will allow the same validation. + +* In Android Studio, select the Logcat console (View > Tool Windows > Logcat OR select the Logcat tab @ the bottom of the screen) +* On the Logcat filter bar, select "Verbose" and set the filter keyword to "adbmobile" (note: if the filter menu doesn't show, try setting the console to a floating window: Window > Active Tool Window > Floating Mode) +* Run the Android Emulator and look for the Target request and response. "Response received" indicates that the server connection and response was successful: + +![Finding the request in Logcat]( assets/logcat_example.jpg) + +* Remove the "adbmobile" filter and note any connection errors. Most errors are likely caused from incorrect request syntax or configuration. Proxy settings in the Emulator settings can also cause connection errors. + +#### Verify the Target Activity in the UI + +If an Activity is already created in the Target UI, the location requested in the Target SDK call (if successful) can be seen in the location drop-down menu under Activities > (Select Activity Name) > Edit Activity > Experiences: + +If no Activity has not yet created, create a new one: + +* Select Activities > Create Activity +* Select the Activity Type (such as A/B Test) +* Select Mobile App +* Select "Form" as the Experience Composer +* Select the Workspace & Property +* The location drop-down on a selected Experience shows the locations that are registered: + +![Locations will show in interface dropdowns in the Form Composer]( assets/target_location_dropdown2.jpg) + +#### Response Details Example + +Here are the details of the response from the Logcat console (expanded JSON view for readability): + +```java +{ +"requestId":"4988228c-8430-4e33-b3ca-37ce82e3a90c", +"client":"ecserverside", +"id": + { + "tntId":"111568817282645-907045.28_29", + "marketingCloudVisitorId":"34552764763276759957814173181896264559" + }, +"edgeHost":"mboxedge28.tt.omtrdc.net", +"contentAsJson":false, +"prefetchResponses": + [{ + "mbox":"travelTest3", + "parameters": + { + "a.ltv.amount":"0", + "MboxParam18Sep":"1", + "at_property":"7962ac68-17db-1579-408f-9556feccb477" + }, + "content":"{\"id\":\"1\",\"bannersToDisplay\":\"blue_green\"}", + "eventTokens":["iuniIAuYUHON1jhC+7UzfmqipfsIHvVzTQxHolz2IpSCnQ9Y9OaLL2gsdrWQTvE54PwSz67rmXWmSnkXpSSS2Q=="], + "clientSideAnalyticsLoggingPayload":{"pe":"tnt","tnta":"308228:0:0|2"} + }] +} +``` + +The main key/value pairs to validate and check for accuracy are listed below: + +| Key | Value | +|--- |--- | +| client | your Adobe Target clientCode value - unique to your environment | +| tntId | primary identifier in Target for an individual user | +| prefetchResponses | for prefetch requests: this object list locations (mboxes) that are prefetched and cached into device memory and any profile parameters included in the request | +| at_property | the Target property from which mboxes (locations) are served. This value is found in the Target interface under Setup > Properties > (select the property of the offer) > (code box) | +| mbox | the location identifier used in Activities in Adobe Target | +| content | for prefetch requests: content delivered to the specified mbox | + +##### JSON Offers: Common Errors + +For JSON Offers: If the request appears to be sending properly, but continues to return default content, check all the parameters in the Target.loadRequest call. If the "targetParameters" value is empty for a JSON offer request, default content will be returned: + +![Default content returned in the response]( assets/error1.jpg) + +To correct this, make sure the at_property is defined and set in the loadRequest. This ensures the offer is being served from the correct Target property. + +![Make sure the at_property parameter is defined if using workspaces]( assets/mboxparam1.jpg) + +The correct Target property is found in the target property is found in the Target interface under Setup > Properties > select the property of the offer. + +##### JSON Offer Conversion + +The Target.loadRequest method returns an offer in String format. If you're displaying a JSON offer, it needs to be converted from String to JSON after a response is returned in order to parse or reference items within the JSON object. + +## Use a Prefetch "Blocking" Location Call + +Configuring Target methods as prefetch "blocking" requests provides two main benefits: + +* The prefetch method call Target in the "background". It caches locations (mboxes) in device memory for quick access later in the session. This avoids excessive requests to the server & results in a faster app experience. +* A "Blocking" request enables Target content to load into the app before other app content is loaded. + +In the code examples below, the changes were made to the main activity of the We.Travel app. The result is an app launch with Target prefetching before any other content loads. + +A prefetch blocking request can be set up in an Android Activity by moving the app's content layout methods from the onCreate() method to a separate method that Target calls after a location request. + +### Code Example: Move app layout logic to a new method + +```java +// Move the setContentView() method (and other app layout logic) from +// onCreate() into a new setUp() function: + +private void setUp() { + setContentView(R.layout.activity_home); + + // add other logic for app setup +} +``` + +### Code Example: Call setUp() AFTER Target callback + +```java +// Add a call to setUp() at the end of the Target location or prefetch call. +// This example loads a prefetch request and then calls setUp(): + +public void targetPrefetchContent() { + List prefetchList = new ArrayList<>(); + Map profileParameters; + profileParameters = new HashMap(); + profileParameters.put("ProfileParam18Sep", "1"); + Map travelParameters1 = new HashMap(); + travelParameters1.put("travelParam18Sep", "1"); + travelParameters1.put("at_property", "7962ac68-17db-1579-408f-9556feccb477"); + prefetchList.add(Target.createTargetPrefetchObject("travelTest3", travelParameters1)); + Target.TargetCallback prefetchStatusCallback = new Target.TargetCallback() { + @Override + public void call(final Boolean status) { + HomeActivity.this.runOnUiThread(new Runnable() { + @Override + public void run() { + String cachingStatus = status ? "YES" : "NO"; + System.out.println("Received Response from prefetch : " + cachingStatus); + setUp(); + } + }); + }}; + Target.prefetchContent(prefetchList, profileParameters, prefetchStatusCallback); +} + +``` + +## Use a Live Location Request + +On the bus results screen, if we wanted to display an offer related to the bus destination, a live location request should be called for that offer instead of a prefetched location. This is because the offer needs to be changed depending on where the user wants to travel to. Prefetched locations could be used with other elements on the screen not related to the destination (like general discounts or promotions). + +### JSON Offers + +This demo uses JSON offers to determine which banners to display. In the Target interface, create JSON offers for each experience: + +![JSON Offers in the Target interface](assets/json_offers.jpg) + +### Code Example: Live Location Request + +A live location request is called with the **Target.loadRequest()** method. This request below calls the JSON offer, retrieves an ID element from the JSON object, and uses that ID to determine the right assets to display. + +```java +// SINGLE Location SCENARIO - JSON OFFER +public void targetLoadRequest() { + Map mboxParam; + mboxParam = new HashMap(); + mboxParam.put("at_property", "7962ac68-17db-1579-408f-9556feccb477"); + Target.loadRequest("travelTest3", "----default_mbox----", null, null, mboxParam, new Target.TargetCallback() { + @Override + public void call(final String s) { + SearchBusActivity.this.runOnUiThread(new Runnable() { + @Override + public void run() { + try { + JSONObject obj = new JSONObject(s); + banner_id = obj.getInt("id"); + } catch ( + Throwable t) { + Log.e("My App", "Could not parse malformed JSON: \"" + s + "\""); + } + + setUpSearch(); + getSearchData(); + + } + }); + } + }); +} + +``` + +In the demo app's getSearchData() method, add the returned banner_id (and the next banner if desired): + +```java +// FIND BANNER DETERMINED BY ADOBE TARGET OFFER +searchOffersList.add(offerList.get(banner_id)); +searchOffersList.add(offerList.get(banner_id+1)); +//searchOffersList.addAll(offerList); +searchOffersAdapter.notifyDataSetChanged(); +``` + +## Request Multiple Target Locations in one Call + +To display multiple mboxes on the Bus Results Screen, multiple target locations can be requested in a single call. In this example, we'll display one mbox in the top offer area of the screen, and another mbox just above the bus search results. + +Multiple mboxes are built & displayed as follows: + +* Create a TargetRequestObject for each location +* Add each TargetRequestObject to an Array +* Add the Array to the **Target.loadRequests()** method and call the locations + +### Code Example: Multiple Locations + +Here is an example from the Bus Results activity. The code is called from the activity's onResume() method. Note that the parameters for the createTargetRequestObject() method are in a different order than the targetLoadRequest() method. + +```java +// MULTIPLE MBOX SCENARIOS- 2 JSON OFFERS +public void targetLoadRequests() { + +// Create Multiple Target Location Requests & send in one loadRequests() call + +// 1st Location +Map mboxParam; +mboxParam = new HashMap(); +mboxParam.put("at_property", "7962ac68-17db-1579-408f-9556feccb477"); +TargetRequestObject request1 = Target.createTargetRequestObject("mboxTest3", "--mboxTest3_default--", mboxParam, null, null, new Target.TargetCallback() { + @Override + public void call(final String s) { + SearchBusActivity.this.runOnUiThread(new Runnable() { + @Override + public void run() { + try { + JSONObject obj = new JSONObject(s); + banner_id = obj.getInt("id"); + } catch ( + Throwable t) { + Log.e("My App", "Could not parse malformed JSON: \"" + s + "\""); + } + } + }); + } +}); + +// 2nd Location +TargetRequestObject request2 = Target.createTargetRequestObject("mboxTest4", "--mboxTest4_default--", mboxParam, null, null, new Target.TargetCallback() { +@Override +public void call(final String s) { + SearchBusActivity.this.runOnUiThread(new Runnable() { + @Override + public void run() { + try { + // Get JSON Offer name + JSONObject obj2 = new JSONObject(s); + String offer2_name = obj2.getString("offer2_name"); + Log.d("Sent:", s); + + // Get 2nd banner based on JSON offer name & display above Bus results + ImageView target_banner = findViewById(R.id.target_banner); + int offer2_id = getResources().getIdentifier(offer2_name, "drawable", getPackageName()); + target_banner.setImageResource(offer2_id); + } catch ( + Throwable t) { + Log.e("My App", "Could not parse malformed JSON: \"" + s + "\""); + } + } + }); +} +}); + +// Create Array of both requests +List locationRequests = new ArrayList<>(); +locationRequests.add(request1); +locationRequests.add(request2); + +// Send Location Requests +Target.loadRequests(locationRequests, null); +setUpSearch(); + +} + +``` + +### Result + +2 Target locations are displayed on the screen: + +![Two locations in the app serving content](assets/2mboxes.jpg) diff --git a/download-validate-and-update-the-sample-app.md b/download-validate-and-update-the-sample-app.md new file mode 100644 index 0000000..eb16a78 --- /dev/null +++ b/download-validate-and-update-the-sample-app.md @@ -0,0 +1,43 @@ +--- +title: How to Validate Adobe Target for your mobile app +seo-title: How to Validate Adobe Target for Your Mobile App +description: The Adobe Target SDK can be validated on your mobile app by debugging Target server calls in an Android Emulator. +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement +--- + +# Download, Validate, and Update the We.Travel Sample App + +The We.Travel sample app is pre-implemented is the Adobe Mobile Services SDK v4. You just need to update it so it points to your own Experience Cloud Org and solution accounts. + +## Learning Objectives + +At the end of this lesson, you will be able to: + +* Download and Open the We.Travel sample app in Android Studio +* Update the Target Client Code to use your own Target account +* Add a request to the sample app +* Validate the request using Logcat + +## Download the We.Travel App + +* Download the [We.Travel App](https://github.com/adobe-target/sample-app-android/tree/SDKv4) + +## Verify the SDK Implementation + +The Adobe Mobile Services SDK, has been preinstalled within the We.Travel app [according to the documentation](https://docs.adobe.com/content/help/en/mobile-services/android/getting-started-android/requirements.html). Before proceeding with setting up our initial Target call, let's verify the SDK implementation steps. + +* Open Android Studio +* Select "Open an existing Android Studio Project" + ![NEEDS ALT TEXT](assets/mobile-launch-install-openProject.png) +* Open the build.gradle file at the root of the We.Travel Android folder +* Open the ADBMobileConfig.json file in the assets folder of the project +* Update the ADBMobileConfig.json file to you use your own the target.clientCode and otehr account values set to the correct value for your implementation + ![NEEDS ALT TEXT](assets/insert_screenshot.png) +* Verify that the correct [Target Classes & Methods](https://docs.adobe.com/content/help/en/mobile-services/android/target-android/c-target-methods.html) are implemented with the correct Target location names (previously known as mboxes) + +[Next "Add Target Requests" >](add-requests.md) diff --git a/feature-flagging.md b/feature-flagging.md new file mode 100644 index 0000000..df58f28 --- /dev/null +++ b/feature-flagging.md @@ -0,0 +1,13 @@ +--- +title: +seo-title: +description: +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement +--- + +# Feature Flagging diff --git a/images/2mboxes.jpg b/images/2mboxes.jpg deleted file mode 100644 index 76df963..0000000 Binary files a/images/2mboxes.jpg and /dev/null differ diff --git a/images/error1.jpg b/images/error1.jpg deleted file mode 100644 index 16c2813..0000000 Binary files a/images/error1.jpg and /dev/null differ diff --git a/images/json_offers.jpg b/images/json_offers.jpg deleted file mode 100644 index cc3b88f..0000000 Binary files a/images/json_offers.jpg and /dev/null differ diff --git a/images/logcat_example.jpg b/images/logcat_example.jpg deleted file mode 100644 index 8f7e342..0000000 Binary files a/images/logcat_example.jpg and /dev/null differ diff --git a/images/mboxparam1.jpg b/images/mboxparam1.jpg deleted file mode 100644 index f903154..0000000 Binary files a/images/mboxparam1.jpg and /dev/null differ diff --git a/images/prefetch_call.jpg b/images/prefetch_call.jpg deleted file mode 100644 index d40b818..0000000 Binary files a/images/prefetch_call.jpg and /dev/null differ diff --git a/images/readme.md b/images/readme.md deleted file mode 100644 index 8b13789..0000000 --- a/images/readme.md +++ /dev/null @@ -1 +0,0 @@ - diff --git a/images/target_location_dropdown.jpg b/images/target_location_dropdown.jpg deleted file mode 100644 index 5e7d13e..0000000 Binary files a/images/target_location_dropdown.jpg and /dev/null differ diff --git a/images/target_location_dropdown2.jpg b/images/target_location_dropdown2.jpg deleted file mode 100644 index 6db2019..0000000 Binary files a/images/target_location_dropdown2.jpg and /dev/null differ diff --git a/images/travel_app.jpg b/images/travel_app.jpg deleted file mode 100644 index 54f8a3a..0000000 Binary files a/images/travel_app.jpg and /dev/null differ diff --git a/images/travel_app2.jpg b/images/travel_app2.jpg deleted file mode 100644 index 67c8070..0000000 Binary files a/images/travel_app2.jpg and /dev/null differ diff --git a/images/travel_app_2_locations.jpg b/images/travel_app_2_locations.jpg deleted file mode 100644 index c6da8d7..0000000 Binary files a/images/travel_app_2_locations.jpg and /dev/null differ diff --git a/mpc-adobe-target-mobile-app-scenarios V2.md b/mpc-adobe-target-mobile-app-scenarios V2.md deleted file mode 100644 index 0ac00e7..0000000 --- a/mpc-adobe-target-mobile-app-scenarios V2.md +++ /dev/null @@ -1,221 +0,0 @@ ---- -description: Adobe Target mobile SDK methods can be used to display Target locations in several scenarios. -seo-title: Adobe Target location request scenarios -title: Adobe Target location request scenarios ---- - -# Adobe Target Location Request Scenarios -The Adobe Mobile Services SDK version 4 provides Adobe Target methods & functionality that enable you customize your mobile app implementation and tailor it for different experiences. -* **Request using a Prefetch "Blocking"** -* **Request using a Live Location** -* **Request Multiple Target Locations in one Call** -* **Requests combining Prefetch & Live Locations** -* **Clearing Prefetched Locations from Cache** - -#### We.Travel App -This article discusses multiple scenarios using a sample travel app. The app has a search feature that finds available bus routes. The app will be used for demonstration purposes. - -* Target locations are prefetched on the home screen, so no Target content appears, but locations are cached in the device behind the scene -* The search results screen loads a Target location and displays banners based off a JSON offer loaded from the Target server. -![](images/travel_app2.jpg) - - -## Use a Prefetch "Blocking" Request -Configuring Target methods as prefetch "blocking" requests provides two main benefits: - -* The prefetch method call Target in the "background". It caches locations (mboxes) in device memory for quick access later in the session. This avoids excessive requests to the server & results in a faster app experience. -* A "Blocking" request enables Target content to load into the app before other app content is loaded. - -In the code examples below, the changes were made to the main activity of the We.Travel app. The result is an app launch with Target prefetching before any other content loads. - -A prefetch blocking request can be set up in an Android Activity by moving the app's content layout methods from the onCreate() method to a separate method that Target calls after a location request. - -#### Code Example: Move app layout logic to a new method -``` -// Move the setContentView() method (and other app layout logic) from -// onCreate() into a new setUp() function: - -private void setUp() { - setContentView(R.layout.activity_home); - - // add other logic for app setup -} -``` - -#### Code Example: Call setUp() AFTER Target callback - -``` -// Add a call to setUp() at the end of the Target location or prefetch call. -// This example loads a prefetch request and then calls setUp(): - -public void targetPrefetchContent() { - List prefetchList = new ArrayList<>(); - Map profileParameters; - profileParameters = new HashMap(); - profileParameters.put("ProfileParam18Sep", "1"); - Map mboxParameters1 = new HashMap(); - mboxParameters1.put("MboxParam18Sep", "1"); - mboxParameters1.put("at_property", "7962ac68-17db-1579-408f-9556feccb477"); - prefetchList.add(Target.createTargetPrefetchObject("mboxTest3", mboxParameters1)); - Target.TargetCallback prefetchStatusCallback = new Target.TargetCallback() { - @Override - public void call(final Boolean status) { - HomeActivity.this.runOnUiThread(new Runnable() { - @Override - public void run() { - String cachingStatus = status ? "YES" : "NO"; - System.out.println("Received Response from prefetch : " + cachingStatus); - setUp(); - } - }); - }}; - Target.prefetchContent(prefetchList, profileParameters, prefetchStatusCallback); -} - -``` - -## Use a Live Location Request -On the bus results screen, if we wanted to display an offer related to the bus destination, a live location request should be called for that offer instead of a prefetched location. This is because the offer needs to be changed depending on where the user wants to travel to. Prefetched locations could be used with other elements on the screen not related to the destination (like general discounts or promotions). - -#### JSON Offers -This demo uses JSON offers to determine which banners to display. In the Target interface, create JSON offers for each experience: - -![](images/json_offers.jpg) - -#### Code Example -A live location request is called with the **Target.loadRequest()** method. This request below calls the JSON offer, retrieves an ID element from the JSON object, and uses that ID to determine the right assets to display. - -``` -// SINGLE MBOX SCENARIO - JSON OFFER -public void targetLoadRequest() { - Map mboxParam; - mboxParam = new HashMap(); - mboxParam.put("at_property", "7962ac68-17db-1579-408f-9556feccb477"); - Target.loadRequest("mboxTest3", "----default_mbox----", null, null, mboxParam, new Target.TargetCallback() { - @Override - public void call(final String s) { - SearchBusActivity.this.runOnUiThread(new Runnable() { - @Override - public void run() { - try { - JSONObject obj = new JSONObject(s); - banner_id = obj.getInt("id"); - } catch ( - Throwable t) { - Log.e("My App", "Could not parse malformed JSON: \"" + s + "\""); - } - - setUpSearch(); - getSearchData(); - - } - }); - } - }); -} - -``` - -In the demo app's getSearchData() method, add the returned banner_id (and the next banner if desired): - -``` -// FIND BANNER DETERMINED BY ADOBE TARGET OFFER -searchOffersList.add(offerList.get(banner_id)); -searchOffersList.add(offerList.get(banner_id+1)); -//searchOffersList.addAll(offerList); -searchOffersAdapter.notifyDataSetChanged(); -``` - - -## Request Multiple Target Locations in one Call -To display multiple mboxes on the Bus Results Screen, multiple target locations can be requested in a single call. In this example, we'll display one mbox in the top offer area of the screen, and another mbox just above the bus search results. - -Multiple mboxes are built & displayed as follows: - -* Create a TargetRequestObject for each location -* Add each TargetRequestObject to an Array -* Add the Array to the **Target.loadRequests()** method and call the locations - -#### Code Example -Here is an example from the Bus Results activity. The code is called from the activity's onResume() method. Note that the parameters for the createTargetRequestObject() method are in a different order than the targetLoadRequest() method. - -``` -// MULTIPLE MBOX SCENARIOS- 2 JSON OFFERS -public void targetLoadRequests() { - -// Create Multiple Target Location Requests & send in one loadRequests() call - -// 1st Location -Map mboxParam; -mboxParam = new HashMap(); -mboxParam.put("at_property", "7962ac68-17db-1579-408f-9556feccb477"); -TargetRequestObject request1 = Target.createTargetRequestObject("mboxTest3", "--mboxTest3_default--", mboxParam, null, null, new Target.TargetCallback() { - @Override - public void call(final String s) { - SearchBusActivity.this.runOnUiThread(new Runnable() { - @Override - public void run() { - try { - JSONObject obj = new JSONObject(s); - banner_id = obj.getInt("id"); - } catch ( - Throwable t) { - Log.e("My App", "Could not parse malformed JSON: \"" + s + "\""); - } - } - }); - } -}); - -// 2nd Location -TargetRequestObject request2 = Target.createTargetRequestObject("mboxTest4", "--mboxTest4_default--", mboxParam, null, null, new Target.TargetCallback() { -@Override -public void call(final String s) { - SearchBusActivity.this.runOnUiThread(new Runnable() { - @Override - public void run() { - try { - // Get JSON Offer name - JSONObject obj2 = new JSONObject(s); - String offer2_name = obj2.getString("offer2_name"); - Log.d("Sent:", s); - - // Get 2nd banner based on JSON offer name & display above Bus results - ImageView target_banner = findViewById(R.id.target_banner); - int offer2_id = getResources().getIdentifier(offer2_name, "drawable", getPackageName()); - target_banner.setImageResource(offer2_id); - } catch ( - Throwable t) { - Log.e("My App", "Could not parse malformed JSON: \"" + s + "\""); - } - } - }); -} -}); - -// Create Array of both requests -List locationRequests = new ArrayList<>(); -locationRequests.add(request1); -locationRequests.add(request2); - -// Send Location Requests -Target.loadRequests(locationRequests, null); -setUpSearch(); - -} - -``` - -#### Result: -2 Target locations are displayed on the screen: - -![](images/2mboxes.jpg) - - -## Combining Prefetch & Live Location Requests -The scenario above (Request Multiple Target Locations in one Call) also demonstrates how to request a prefetched location ("mboxTest3" was prefetched on the home screen) and a live location request from the server, both in a single call. This can be done with the **Target.loadRequests()** method. - - -## Clearing Prefetched Locations from Cache -Suppose a special add-on offer was prefetched and cached on the booking > seating screen. A user may revisit that screen later. However, if the user decides to change the bus line during the app session, the prefetched offer should be cleared so a new offer for the new bus line can display. All prefetched locations are cleared with the **Target.clearPrefetchCache()** method. - diff --git a/mpc-adobe-target-mobile-app-scenarios.md b/mpc-adobe-target-mobile-app-scenarios.md index 57422bd..33cb614 100644 --- a/mpc-adobe-target-mobile-app-scenarios.md +++ b/mpc-adobe-target-mobile-app-scenarios.md @@ -1,10 +1,17 @@ --- -description: Adobe Target mobile SDK methods can be used to display Target locations in several scenarios. -seo-title: Adobe Target location request scenarios title: Adobe Target location request scenarios +seo-title: Adobe Target location request scenarios +description: Adobe Target mobile SDK methods can be used to display Target locations in several scenarios. +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement --- # Adobe Target Location Request Scenarios + The Adobe Mobile Services SDK (v4) provides Adobe Target methods & functionality that enable you customize your mobile app implementation and tailor it for different experiences. * **Use a Prefetch "Blocking" Location Call** * **Request using a Live Location** @@ -12,15 +19,17 @@ The Adobe Mobile Services SDK (v4) provides Adobe Target methods & functionality * **Requests combining Prefetch & Live Locations** * **Clearing Prefetched Locations from Cache** -#### We.Travel App +## We.Travel App + This article discusses multiple scenarios using a sample travel app. The app has a search feature that finds available bus routes. The app will be used for demonstration purposes. * Target locations are prefetched on the home screen, so no Target content appears, but locations are cached in the device behind the scene + * The search results screen loads a Target location and displays banners based off a JSON offer loaded from the Target server. ![](images/travel_app2.jpg) - ## Use a Prefetch "Blocking" Location Call + Configuring Target methods as prefetch "blocking" requests provides two main benefits: * The prefetch method call Target in the "background". It caches locations (mboxes) in device memory for quick access later in the session. This avoids excessive requests to the server & results in a faster app experience. @@ -30,22 +39,22 @@ In the code examples below, the changes were made to the main activity of the We A prefetch blocking request can be set up in an Android Activity by moving the app's content layout methods from the onCreate() method to a separate method that Target calls after a location request. -#### Code Example: Move app layout logic to a new method -``` -// Move the setContentView() method (and other app layout logic) from +### Code Example: Move app layout logic to a new method + +```java +// Move the setContentView() method (and other app layout logic) from // onCreate() into a new setUp() function: private void setUp() { - setContentView(R.layout.activity_home); - - // add other logic for app setup + setContentView(R.layout.activity_home); + // add other logic for app setup } ``` -#### Code Example: Call setUp() AFTER Target callback +### Code Example: Call setUp() AFTER Target callback -``` -// Add a call to setUp() at the end of the Target location or prefetch call. +```java +// Add a call to setUp() at the end of the Target location or prefetch call. // This example loads a prefetch request and then calls setUp(): public void targetPrefetchContent() { @@ -71,18 +80,20 @@ public void targetPrefetchContent() { }}; Target.prefetchContent(prefetchList, profileParameters, prefetchStatusCallback); } - ``` ## Use a Live Location Request -On the bus results screen, if we wanted to display an offer related to the bus destination, a live location request should be called for that offer instead of a prefetched location. This is because the offer needs to be changed depending on where the user wants to travel to. Prefetched locations could be used with other elements on the screen not related to the destination (like general discounts or promotions). -#### JSON Offers +On the bus results screen, if we wanted to display an offer related to the bus destination, a live location request should be called for that offer instead of a prefetched location. This is because the offer needs to be changed depending on where the user wants to travel to. Prefetched locations could be used with other elements on the screen not related to the destination (like general discounts or promotions). + +### JSON Offers + This demo uses JSON offers to determine which banners to display. In the Target interface, create JSON offers for each experience: -![](images/json_offers.jpg) +![JSON Offers in the Target interface](assets/json_offers.jpg) + +### Code Example -#### Code Example A live location request is called with the **Target.loadRequest()** method. This request below calls the JSON offer, retrieves an ID element from the JSON object, and uses that ID to determine the right assets to display. ``` @@ -118,7 +129,7 @@ public void targetLoadRequest() { In the demo app's getSearchData() method, add the returned banner_id (and the next banner if desired): -``` +```java // FIND BANNER DETERMINED BY ADOBE TARGET OFFER searchOffersList.add(offerList.get(banner_id)); searchOffersList.add(offerList.get(banner_id+1)); @@ -126,8 +137,8 @@ searchOffersList.add(offerList.get(banner_id+1)); searchOffersAdapter.notifyDataSetChanged(); ``` +## Request Multiple Target Locations in one Call -## Request Multiple Target Locations in one Call To display multiple mboxes on the Bus Results Screen, multiple target locations can be requested in a single call. In this example, we'll display one mbox in the top offer area of the screen, and another mbox just above the bus search results. Multiple mboxes are built & displayed as follows: @@ -135,11 +146,12 @@ Multiple mboxes are built & displayed as follows: * Create a TargetRequestObject for each location * Add each TargetRequestObject to an Array * Add the Array to the **Target.loadRequests()** method and call the locations - -#### Code Example + +### Code Example + Here is an example from the Bus Results activity. The code is called from the activity's onResume() method. Note that the parameters for the createTargetRequestObject() method are in a different order than the targetLoadRequest() method. -``` +```java // MULTIPLE MBOX SCENARIOS- 2 JSON OFFERS public void targetLoadRequests() { @@ -203,19 +215,18 @@ Target.loadRequests(locationRequests, null); setUpSearch(); } - ``` -#### Result: -2 Target locations are displayed on the screen: +### Result -![](images/2mboxes.jpg) +2 Target locations are displayed on the screen: +![Two locations in the app serving content](assets/2mboxes.jpg) ## Combining Prefetch & Live Location Requests -The scenario above (Request Multiple Target Locations in one Call) also demonstrates how to request a prefetched location ("mboxTest3" was prefetched on the home screen) and a live location request from the server, both in a single call. This can be done with the **Target.loadRequests()** method. +The scenario above (Request Multiple Target Locations in one Call) also demonstrates how to request a prefetched location ("mboxTest3" was prefetched on the home screen) and a live location request from the server, both in a single call. This can be done with the **Target.loadRequests()** method. ## Clearing Prefetched Locations from Cache -Suppose a special add-on offer was prefetched and cached on the booking > seating screen. A user may revisit that screen later. However, if the user decides to change the bus line during the app session, the prefetched offer should be cleared so a new offer for the new bus line can display. All prefetched locations are cleared with the **Target.clearPrefetchCache()** method. +Suppose a special add-on offer was prefetched and cached on the booking > seating screen. A user may revisit that screen later. However, if the user decides to change the bus line during the app session, the prefetched offer should be cleared so a new offer for the new bus line can display. All prefetched locations are cleared with the **Target.clearPrefetchCache()** method. diff --git a/mpc-target-mobile-app-validation V2.md b/mpc-target-mobile-app-validation V2.md deleted file mode 100644 index 1a026dd..0000000 --- a/mpc-target-mobile-app-validation V2.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -description: The Adobe Target SDK can be validated on your mobile app by debugging Target server calls in an Android Emulator. -seo-title: How to Validate Adobe Target for Your Mobile App -title: How to Validate Adobe Target for your mobile app ---- -# Adobe Target Mobile Implementation - -This lesson will cover a comprehensive mobile Target implementation, showcasing different Target scenarios and customizations within a Demo app. Download the We.Travel App [Here](https://github.com/Adobe-Marketing-Cloud/busbooking-mobileapps) - -The foundational step of the Adobe Target implementation, the mobile SDK, has been preinstalled within this demo app. But before proceeding in setting up the Global mbox, let's verify the SDK implementation steps. - -#### Verify the SDK Implementation - -* Download and add the [Adobe Mobile Services SDK](https://docs.adobe.com/content/help/en/mobile-services/android/getting-started-android/requirements.html) to your project -* Add the ADBMobileConfig.json file to the assets folder in your project -* Verify that that ADBMobileConfig.json file has the target.clientCode value set to the correct value for your implementation -* Verify that the correct [Target Classes & Methods](https://docs.adobe.com/content/help/en/mobile-services/android/target-android/c-target-methods.html) are implemented with the correct Target location names (mboxes) - -#### Implement Global mbox (PreFetch) -A prefetchContent mbox uses the Android Mobile SDKs to fetch offer content as few times as possible by caching the server responses. Creating a prefetch request with an array of mbox locations can be configured to call the Target server and retrieve content for many mbox locations at once. All content will be retrieved and cached, and will then be retrievable from the cache by all future calls that contain cached content for the specified mbox names. Additional mbox names can be added to this array, as appropriate, to support the increased scope and sophistication of the install. -Additional details - [Prefetch offer content in Android](https://docs.adobe.com/content/help/en/mobile-services/android/target-android/c-mob-target-prefetch-android.html) - -##### prefetchContent() Code Example -The Target.prefetchContent() Java method was used to prefetch & cache an mbox. Here is the syntax of the request: - -``` -public void targetPrefetchContent() { - List prefetchList = new ArrayList<>(); - Map profileParameters; - profileParameters = new HashMap(); - profileParameters.put("ProfileParam18Sep", "1"); - Map mboxParameters1 = new HashMap(); - mboxParameters1.put("MboxParam18Sep", "1"); - mboxParameters1.put("at_property", "7962ac68-17db-1579-408f-9556feccb477"); - prefetchList.add(Target.createTargetPrefetchObject("mboxTest3", mboxParameters1)); - Target.TargetCallback prefetchStatusCallback = new Target.TargetCallback() { - @Override - public void call(final Boolean status) { - HomeActivity.this.runOnUiThread(new Runnable() { - @Override - public void run() { - String cachingStatus = status ? "YES" : "NO"; - System.out.println("Received Response from prefetch : " + cachingStatus); - setUp(); - } - }); - }}; - Target.prefetchContent(prefetchList, profileParameters, prefetchStatusCallback); -} -``` - - -## How to Validate Adobe Target (SDK v4) for your mobile app{#how-to-validate-Adobe-Target-for-your-mobile-app} - -Now that the SDK is implemented and our initial prefetch mbox call has been setup, let's validate the requests & responses from the Adobe Target Servers. The Adobe Target SDK can be validated on your mobile app by using an Android Emulator & reviewing verbose logging in your Android IDE environment. This article demonstrates how to use the Android Studio IDE to debug Target server calls for the Adobe Mobile Services SDK version 4. - -### Validate with an Emulator - -Android Studio's Android Emulator & Logcat feature can be used to validate requests & responses from the Adobe Target servers. If you're using a different IDE such as Eclipse, logging should follow a similar process. You can also import your Android app into Android Studio to use the Logcat feature. - - -#### Debug Requests & Responses with Logcat -* In Android Studio, select the Logcat console (View > Tool Windows > Logcat OR select the Logcat tab @ the bottom of the screen) -* On the Logcat filter bar, select "Verbose" and set the filter keyword to "adbmobile" (note: if the filter menu doesn't show, try setting the console to a floating window: Window > Active Tool Window > Floating Mode) -* Run the Android Emulator and look for the Target request and response. "Response received" indicates that the server connection and response was successful: - -![](images/logcat_example.jpg) - -* Remove the "adbmobile" filter and note any connection errors. Most errors are likely caused from incorrect request syntax or configuration. Proxy settings in the Emulator settings can also cause connection errors. - -#### Verify the Target Activity in the UI -If an Activity is already created in the Target UI, the location requested in the Target SDK call (if successful) can be seen in the location drop-down menu under Activities > (Select Activity Name) > Edit Activity > Experiences: - -If an Activity is not yet created, create a new one: - -* Select Activities > Create Activity -* Select the Activity Type (such as A/B Test) -* Select Mobile App -* Select "Form" as the Experience Composer -* Select the Workspace & Property -* The location drop-down on a selected Experience shows the locations that are registered: - -![](images/target_location_dropdown2.jpg) - - - -#### Response Details Example -Here are the details of the response from the Logcat console (expanded JSON view for readability): - -``` -{ -"requestId":"4988228c-8430-4e33-b3ca-37ce82e3a90c", -"client":"ecserverside", -"id": - { - "tntId":"111568817282645-907045.28_29", - "marketingCloudVisitorId":"34552764763276759957814173181896264559" - }, -"edgeHost":"mboxedge28.tt.omtrdc.net", -"contentAsJson":false, -"prefetchResponses": - [{ - "mbox":"mboxTest3", - "parameters": - { - "a.ltv.amount":"0", - "MboxParam18Sep":"1", - "at_property":"7962ac68-17db-1579-408f-9556feccb477" - }, - "content":"{\"id\":\"1\",\"bannersToDisplay\":\"blue_green\"}", - "eventTokens":["iuniIAuYUHON1jhC+7UzfmqipfsIHvVzTQxHolz2IpSCnQ9Y9OaLL2gsdrWQTvE54PwSz67rmXWmSnkXpSSS2Q=="], - "clientSideAnalyticsLoggingPayload":{"pe":"tnt","tnta":"308228:0:0|2"} - }] -} -``` -The main key/value pairs to validate and check for accuracy are listed below: - -| Key | Value | -|--- |--- | -| client | your Adobe Target clientCode value - unique to your environment | -| tntId | primary identifier in Target for an individual user | -| prefetchResponses | for prefetch requests: this object list locations (mboxes) that are prefetched and cached into device memory and any profile parameters included in the request | -| at_property | the Target property from which mboxes (locations) are served. This value is found in the Target interface under Setup > Properties > (select the property of the offer) > (code box) -| mbox | the location identifier used in Activities in Adobe Target | -| content | for prefetch requests: content delivered to the specified mbox | - - -#### JSON Offers: Common Errors -For JSON Offers: If the request appears to be sending properly, but continues to return default content, check all the parameters in the Target.loadRequest call. If the "mboxParameters" value is empty for a JSON offer request, default content will be returned: - -![](images/error1.jpg) - -To correct this, make sure the at_property is defined and set in the loadRequest. This ensures the offer is being served from the correct Target property. - -![](images/mboxparam1.jpg) - -The correct Target property is found in the target property is found in the Target interface under Setup > Properties > select the property of the offer. - - -#### JSON Offer Conversion -The Target.loadRequest method returns an offer in String format. If you're displaying a JSON offer, it needs to be converted from String to JSON after a response is returned in order to parse or reference items within the JSON object. diff --git a/mpc-target-mobile-app-validation.md b/mpc-target-mobile-app-validation.md index 22b8733..e81df1c 100644 --- a/mpc-target-mobile-app-validation.md +++ b/mpc-target-mobile-app-validation.md @@ -1,8 +1,15 @@ --- -description: The Adobe Target SDK can be validated on your mobile app by debugging Target server calls in an Android Emulator. -seo-title: How to Validate Adobe Target for Your Mobile App title: How to Validate Adobe Target for your mobile app +seo-title: How to Validate Adobe Target for Your Mobile App +description: The Adobe Target SDK can be validated on your mobile app by debugging Target server calls in an Android Emulator. +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement --- + # Adobe Target Mobile Implementation ## Overview @@ -36,7 +43,7 @@ With this walkthrough, it is assumed that you have an Adobe Id and the required It is also assumed that you are familiar with Android development in Java. You will get more out of this walkthrough if you can comfortably read and understand code. -The foundational step of the Adobe Target implementation, the mobile SDK, has been preinstalled within this demo app. But before proceeding in setting up the Global mbox, let's verify the SDK implementation steps. +The foundational step of the Adobe Target implementation, the mobile SDK, has been preinstalled within this demo app. But before proceeding in setting up the Global mbox, let's verify the SDK implementation steps. ## Verify the SDK Implementation @@ -54,7 +61,7 @@ Additional details - [Prefetch offer content in Android](https://docs.adobe.com/ ##### prefetchContent() Code Here is the syntax of the Target.prefetchContent() Java request to be installed: -``` +```java public void targetPrefetchContent() { List prefetchList = new ArrayList<>(); Map profileParameters; @@ -80,8 +87,7 @@ public void targetPrefetchContent() { } ``` - -## How to Validate Adobe Target (SDK v4) for your mobile app{#how-to-validate-Adobe-Target-for-your-mobile-app} +## How to Validate Adobe Target (SDK v4) for your mobile app Now that the SDK is implemented and our initial globalprefetch location call has been setup, let's validate the requests & responses from the Adobe Target Servers. The Adobe Target SDK can be validated on your mobile app by using an Android Emulator & reviewing verbose logging in your Android IDE environment. This article demonstrates how to use the Android Studio IDE to debug Target server calls for the Adobe Mobile Services SDK version 4. @@ -89,16 +95,16 @@ Now that the SDK is implemented and our initial globalprefetch location call has Android Studio's Android Emulator & Logcat feature can be used to validate requests & responses from the Adobe Target servers. If you're using a different IDE such as Eclipse, logging should follow a similar process. Importing your own Android app into Android Studio to use the Logcat feature will allow the same validation. -#### Debug Requests & Responses with Logcat * In Android Studio, select the Logcat console (View > Tool Windows > Logcat OR select the Logcat tab @ the bottom of the screen) * On the Logcat filter bar, select "Verbose" and set the filter keyword to "adbmobile" (note: if the filter menu doesn't show, try setting the console to a floating window: Window > Active Tool Window > Floating Mode) * Run the Android Emulator and look for the Target request and response. "Response received" indicates that the server connection and response was successful: -![](images/logcat_example.jpg) - + ![Finding the request in Logcat](assets/logcat_example.jpg) + * Remove the "adbmobile" filter and note any connection errors. Most errors are likely caused from incorrect request syntax or configuration. Proxy settings in the Emulator settings can also cause connection errors. #### Verify the Target Activity in the UI + If an Activity is already created in the Target UI, the location requested in the Target SDK call (if successful) can be seen in the location drop-down menu under Activities > (Select Activity Name) > Edit Activity > Experiences: If no Activity has not yet created, create a new one: @@ -110,22 +116,21 @@ If no Activity has not yet created, create a new one: * Select the Workspace & Property * The location drop-down on a selected Experience shows the locations that are registered: -![](images/target_location_dropdown2.jpg) - - + ![Locations will show in interface dropdowns in the Form Composer](assets/target_location_dropdown2.jpg) #### Response Details Example -Here are the details of the response from the Logcat console (expanded JSON view for readability): -``` +Here are the details of the response from the Logcat console (expanded JSON view for readability): + +```json { "requestId":"4988228c-8430-4e33-b3ca-37ce82e3a90c", "client":"ecserverside", "id": - { - "tntId":"111568817282645-907045.28_29", - "marketingCloudVisitorId":"34552764763276759957814173181896264559" - }, + { + "tntId":"111568817282645-907045.28_29", + "marketingCloudVisitorId":"34552764763276759957814173181896264559" + }, "edgeHost":"mboxedge28.tt.omtrdc.net", "contentAsJson":false, "prefetchResponses": @@ -143,6 +148,7 @@ Here are the details of the response from the Logcat console (expanded JSON view }] } ``` + The main key/value pairs to validate and check for accuracy are listed below: | Key | Value | @@ -150,22 +156,22 @@ The main key/value pairs to validate and check for accuracy are listed below: | client | your Adobe Target clientCode value - unique to your environment | | tntId | primary identifier in Target for an individual user | | prefetchResponses | for prefetch requests: this object list locations (mboxes) that are prefetched and cached into device memory and any profile parameters included in the request | -| at_property | the Target property from which mboxes (locations) are served. This value is found in the Target interface under Setup > Properties > (select the property of the offer) > (code box) +| at_property | the Target property from which mboxes (locations) are served. This value is found in the Target interface under Setup > Properties > (select the property of the offer) > (code box) | | mbox | the location identifier used in Activities in Adobe Target | | content | for prefetch requests: content delivered to the specified mbox | - #### JSON Offers: Common Errors + For JSON Offers: If the request appears to be sending properly, but continues to return default content, check all the parameters in the Target.loadRequest call. If the "targetParameters" value is empty for a JSON offer request, default content will be returned: -![](images/error1.jpg) +![Default content returned in the response](assets/error1.jpg) To correct this, make sure the at_property is defined and set in the loadRequest. This ensures the offer is being served from the correct Target property. -![](images/mboxparam1.jpg) +![Make sure the at_property parameter is defined if using workspaces](assets/mboxparam1.jpg) The correct Target property is found in the target property is found in the Target interface under Setup > Properties > select the property of the offer. - #### JSON Offer Conversion + The Target.loadRequest method returns an offer in String format. If you're displaying a JSON offer, it needs to be converted from String to JSON after a response is returned in order to parse or reference items within the JSON object. diff --git a/overview.md b/overview.md new file mode 100644 index 0000000..3d1b0e6 --- /dev/null +++ b/overview.md @@ -0,0 +1,59 @@ +--- +title: Adobe Target location request scenarios +seo-title: Adobe Target location request scenarios +description: Adobe Target mobile SDK methods can be used to display Target locations in several scenarios. +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement +--- + +# Overview + +_Implement and Use Adobe Target with Adobe Mobile Services SDK v4 for Android_ is the perfect starting point for Android developers who are already using Adobe Mobile Services SDK v4 and want to start personalizing app experiences with Adobe Target. + +A demo Android app is provided for you to complete the tutorial, so you can learn the underlying techniques. After completing this tutorial, you should be ready to start implementing Target in your own Android app! + +After completing this tutorial you will be able to: + +* Validate the [Adobe Mobile Services SDK](https://docs.adobe.com/content/help/en/mobile-services/android/getting-started-android/requirements.html) setup +* Implement the following types of Target requests: + * Global Pre-Fetch of all Target content + * Blocking request (runs before App display) + * Non-Blocking request (runs in the background) + * Real-Time (non-caching) + * Cache Busting Re-Fetch +* Add parameters to requests for enhanced personalization, including geo-location +* Build Feature Flagging Activities (Using Target to roll out new features) +* Personalize Layouts & Offers +* Use Adobe Target Recommendations + +## Prerequisites + +In these lessons, it is assumed that you: + +* Have an Adobe Id and approver-level access to the Adobe Target interface +* Know your Adobe Target Client Code to direct Target calls to your own account. The Client Code is shown in the Adobe Target interface on the Setup > Implementation > Edit at.js settings screen +* Know your Adobe Experience Cloud Org Id +* Have access to and are familiar with the [Mobile Services user interface](https://mobilemarketing.adobe.com) +* Know your Analytics tracking server and have a report suite id you can use for this tutorial +* POI references? +* Have an IDE for Android mobile app development. This tutorial features [Android Studio](https://developer.android.com/studio/install) in various steps and screenshots + +If you do not have the required access to the Experience Cloud Solutions, reach out to your Experience Cloud Administrator. + + + +Also, it is assumed that you are familiar with Android development in Java. You do not need to be a master of Java to complete the lessons, but you will get more out of them if you can comfortably read and understand code. + +## About the Lessons + +In these lessons, you will implement the Adobe Target into a demo app called "We.Travel" using your own Adobe Target account. The App has capabilities that will allow you to implement a variety of Adobe Target scenarios before you do so in your own app. + +![We.Travel app](assets/weTravel.png) + +Let's get started! + +[Next "Download, Validate, and Update the Sample App" >](download-validate-and-update-the-sample-app.md) diff --git a/personalize-layouts.md b/personalize-layouts.md new file mode 100644 index 0000000..a979d5a --- /dev/null +++ b/personalize-layouts.md @@ -0,0 +1,13 @@ +--- +title: +seo-title: +description: +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement +--- + +# Personalize Layouts diff --git a/personalize-with-geolocation.md b/personalize-with-geolocation.md new file mode 100644 index 0000000..75c9f37 --- /dev/null +++ b/personalize-with-geolocation.md @@ -0,0 +1,13 @@ +--- +title: +seo-title: +description: +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement +--- + +# Personalize with Geolocation diff --git a/recommendations.md b/recommendations.md new file mode 100644 index 0000000..444b39e --- /dev/null +++ b/recommendations.md @@ -0,0 +1,13 @@ +--- +title: +seo-title: +description: +seo-description: +feature: mobile +kt: kt-3040 +audience: developer +doc-type: tutorial +activity-type: implement +--- + +# Recommendations