Adobe Experience Platform Mobile SDKs – Debugging

This article is part of the Adobe Experience Platform Mobile SDKs mini-series. It is about debugging your app.

You can find the overview here.

Today, we’ll talk about an aspect of development that, on mobile apps, is a royal pain, at least compared to the browser-based and extension-supported debugging we do when we deploy on web sites.

Project Griffon

When you work with Javascript and a tag manager, the Console in your browser is an easy and powerful way to debug. On top, you have a multitude of extensions helping you with your work.

In contrast, to debug mobile apps, most cases involve man-in-the-middle type approaches, like using Charles to check on the traffic sent by the app.

“Project Griffon” is a different approach altogether, currently in beta, involving a web service with user interface, plus a Launch Extension that you compile into your app.

The Project Griffon Extension can connect to the web service, and it can report everything that happens within the Experience Platform Mobile SDKs, so you can easily analyse it in the UI. You can also export your debugging sessions to JSON for analysis in other tools.

Now you know why we had to look at deep linking: launching your app via deep link will tell the Extension to record to the service, and it allows the Extension to connect to a specific “session” (you’ll see)

So, let’s do this!

Extension & Coding

As usual, find the Extension in the Catalog in your mobile Property in Launch

Add it to a Library, then publish that Library all the way through.

In Android Studio, add the usual code snippets to your build.gradle and MainActivity.java

Rebuild the app, and you’re good to go.

Connecting

With your app deployed on the emulator or (better) your phone, it is time to use Griffon.

Log into it using https://experience.adobe.com/griffon (not griffon.adobe.com) on your desktop.

Use the “Create Session” button to start a little wizard.

Hit “Start”

Give your session a name, and put in the URL that you specified when you made the deep link. Make sure you use the correct URL! Mine was http, not https, and that does matter.

When you click “Next”, Griffon shows you a deep link and QR code. Use these to start your app on your emulator or mobile device.

You’ll see a 4-digit pass code a bit further down, which you must enter on your device for authentication.

That’s it, your app is connected, and Griffon can see everything the SDK sends.

Debugging — in App

The first thing you’ll notice in your app is a big Griffon logo in the top right corner.

You can move that logo around, in case it is on top of any UI element you want to use or test.

If you tap the logo, you get to the Griffon screen, which shows you a condensed view of what you can see in the Griffon UI, too.

You can also, here, disconnect from Griffon.

Debugging — the UI

The Griffon Web UI is more powerful.

You’ll see a list of events that Griffon received from the app.

That list will update when you do something in/with the app.

Tapping the “email” icon button at the bottom right in the app, as an example, leads to Target replacing two parts of the screen (we built that in the article about Target), and some tracking (we built that in the article about Analytics).

You can see all of that traffic in the list, immediately.

You can see the data that was sent to Analytics

And you can see what Target sent back to the app

Cool, right?

Debugging — Analytics

Griffon has specific views, too, for Analytics and Places. You access those via the “Home” menu.

Select Analytics and the view changes radically.

First of all, all non-Analytics messages are hidden. Second, you can see information regarding the event more easily, such as the state name for trackState calls, and context Data that is passed. And third, some of the events are “queued”

After a bit of time, some or all of them will change to “processed”

What happens here is that Griffon goes and tries to pull the hit back out of Analytics, so it can show you what actually went through.

I consider this extremely useful!

Update 2020-03-03 – you can read more on this in the next article

Notes

Places, too, has a UI in the Griffon web UI.

You can see the requests go out

And you can see what POIs are being sent back by Places

You can also check the Places traffic right in your app, when you tap the Griffon icon:

The official documentation for Project Griffon is online, even though at the time when this article goes live, Griffon is still beta.

I do NOT know when it’ll be generally available, but I hope it will be soon.

I also do not know whether there will be more dedicated “decoders”, e.g. for Target or any other application or Extension.

There is “Custom Validation”, which you can use to build your very own “decoder”. There might be an article about this at some point, but for now, may I direct you to the official documentation for this feature?

And may I point out that you can manage those “decoders” via gists?

Certainly looks interesting!