In-App Message not being handled by SDK about exponea-android-sdk HOT 9 CLOSED

Hi, thanks for trying it out! All in-app messages features should be working now, but it's BETA since we're still polishing it to support all possible application setups correctly.

I'm now realizing I should have added a LOT more logging, these automagical features are pain in the ass to debug. I'll add them to the next patch release.

Every time an event is tracked, we call InAppMessageManagerImpl.showRandom and check if in-app message definition and images are preloaded or not. If they are not, we add the message to pendingShowRequests and display after everything is loaded. With Exponea.loggerLevel = Logger.Level.INFO you should see a message in logcat saying Add pending in-app message for event type session_start to be shown after data is loaded.

With all data loaded, we try to pick an in-app message in InAppMessageManagerImpl.getFilteredMessages. There are couple of filters:

• image is preloaded: check your image url or try "ALERT" message type that doesn't have image
• schedule filter setup on Exponea servers: 'Display immediately, stop manually' is default and should always display
• event filter setup on Exponea servers: double check event name
• display filter setup on Exponea servers: for testing I recommend "Always" option

If a message passes these filters, we display it in InAppMessagePresenter.show. We start a new activity from what we believe current activity is.

I'd suggest checking that your logger is set to info(it's default) and looking into logcat for something out of the ordinary. If you're willing to spend a bit of time debugging this the flow above should be a reasonable guide. I'll try to implement better logging for this as soon as possible so it's easier to figure out why the message isn't showing.

from exponea-android-sdk.

Logs are actually not a huge issue, there is decent amount (although more logs never hurt anyone, right). What's more weird though is that Studio is not picking up sources for Exponea automatically and I usually have to resort to downloading this repo and pointing Studio to it manually. But that's unrelated.

After some more debugging, yeah - seems my initial guess was incorrect. InAppMessages set for app start were having trouble simply because the internal tracking of session start wasn't 100% reliable. As you mentioned EventManagerImpl waits for correct eventType to call showRandom, however the session start many times simply didn't arrive so the IAM didnt even get a chance to show up.

As for IAM triggered by events other than session start, I noticed it sometimes failed in InAppMessagePresenter::show during activity == null check. I'm drawing blanks as to why that might be, although I wonder if (ironically) the debugger isn't at fault here maybe somehow messing up activities during breakpoints.

from exponea-android-sdk.

I'll look into missing sources, that's pretty bad. Our publish to maven pipeline was ancient and I'm currently replacing it.

Seems like both of the issues you're experiencing are related. For session tracking we hook into application lifecycle to see when the app is backgrounded and foregrounded. For in-app messages we hook into app lifecycle as well to see what is the top-most activity currently. To do this we use context that is given to us when the SDK is initialized.

What context are you using? What android version you're testing on?

from exponea-android-sdk.

New version 2.7.3 contains improved in-app message logging and sources have been published to maven

from exponea-android-sdk.

Oh wow, thanks for sources with 2.7.3 already, makes breakpoints a lot easier.

Using application context for Exponea init, Pixel with android 10 so that's pretty much as clean as we get android-wise.

Looking at some logcat prints I set up, could the issue be caused by lateinit of sdk? Although we log events pretty early in our app life, we still have pretty much all analytics injected lazily. Since trackSessionStart comes from SessionManagerImpl::onActivityResumed, it seems this wont go off if the registration for ActivityLifecycleCallbacks comes only after onActivityResumed was already called for current activity.

This is what seems to happen when message fails to show

onActivityCreated() called with: activity = [SplashActivity]
onActivityStarted() called with: activity = [SplashActivity]
onActivityResumed() called with: activity = [SplashActivity]
onActivityPaused() called with: activity = [SplashActivity]
onActivityCreated() called with: activity = [MainActivity]
onActivityStarted() called with: activity = [MainActivity]
onActivityResumed() called with: activity = [MainActivity]
registerActivityLifecycleCallbacks called in SessionManagerImpl
onActivityStopped() called with: activity = [SplashActivity]
onActivityDestroyed() called with: activity = [SplashActivity]

Correct IAM show (just for a comparison); this is when forcing sdk init to happen as early as possible

registerActivityLifecycleCallbacks called in SessionManagerImpl
onActivityCreated() called with: activity = [SplashActivity]
onActivityStarted() called with: activity = [SplashActivity]
onActivityResumed() called with: activity = [SplashActivity]
InAppMessagePresenter:75 currentActivity set [SplashActivity]
SessionManager:33 onActivityResumed
EventManagerImpl:75 track() SESSION_START
onActivityPaused() called with: activity = [SplashActivity]
onActivityCreated() called with: activity = [MainActivity]
onActivityStarted() called with: activity = [MainActivity]
onActivityResumed() called with: activity = [MainActivity]
InAppMessagePresenter:75 currentActivity set [MainActivity]
SessionManager:33 onActivityResumed
onActivityCreated() called with: activity = [com.exponea.sdk.view.InAppMessageActivity]
onActivityStarted() called with: activity = [com.exponea.sdk.view.InAppMessageActivity]
onActivityResumed() called with: activity = [com.exponea.sdk.view.InAppMessageActivity]
InAppMessagePresenter:75 currentActivity set [com.exponea.sdk.view.InAppMessageActivity]
SessionManager:33 onActivityResumed
onActivityStopped() called with: activity = [SplashActivity]
onActivityDestroyed() called with: activity = [SplashActivity]

This looks like very likely culprit, although to be honest I'm not sure what to do with it. Forcing init to happen very early seems like obvious solution to the problem, however in the case above the InAppMessage showed way before MainActivity was ready, the app was not really in "presentable" state yet - that's why we have SplashActivity there for now. Personally I'd also prefer if lateinit/lateinject of analytics stayed possible even when we want to use InAppMessages. However if this usage is not really supported I'll try to make it work somehow

from exponea-android-sdk.

Seems like you found the issue. Just like you wrote, it's recommended to initialize SDK as early as possible. Ideally in Application/first activity onCreate. Both session tracking and in-app messages need an "activity resume" to happen to work properly. What I think you can do is to initialize after Splash is done in MainActivity onCreate. Then SDK starts up and gets callbacks in onResume and everything should work fine. You could also initialize early in splash screen, but instead of showing in-app message on session_start, show it on a different(custom) event.

from exponea-android-sdk.

Hmm. Well, I understand although I can't say I'm a big fan. That's because we put a lot of work into deferring non-essential tasks out of app start process which is fairly "expensive" in our case (rendering engine initialization and first pass, network downloads, disk operations). Startup time is one of internal metrics we keep an eye and even though Exponea is reasonably lightweight I feel extra network requests/downloading+cache of image for InAppMessage would have noticeable impact. I'd definitely prefer if sdk could pick up app-start during init even when it happened in the past from its point of view.

Feel free to close this issue as we found the problem. Maybe as small improvement suggestion you could edit the install guide (which says it's okay to init in activity/fragment) just so other folks don't run into same headscratcher unexpectedly.

from exponea-android-sdk.

We just released a new version of the SDK https://github.com/exponea/exponea-android-sdk/releases/tag/2.7.4

In this version, if you use a resumed AppCompatActivity in Exponea.init() as context, the SDK will start a session and show in-app message which should solve the issue you were having

from exponea-android-sdk.

Awesome! Had to bend some dagger injects since we were injecting application context, but that's well worth it the advantages of better app start. Thanks a lot for help

from exponea-android-sdk.