This article is part of the Adobe Experience Platform Mobile SDKs mini-series. It is about debugging your app.
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.
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
Rebuild the app, and you’re good to go.
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.
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
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
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!