Comments (9)
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.
Related Issues (20)
- How to disable sdk at runtime? HOT 5
- In App Messaging still shows in device even if it was stopped in Dashboard HOT 1
- FetchManagerImpl.fetchInAppMessages - NullPointerException - Parameter specified as non-null is null HOT 3
- Manually tracked token is not tracked HOT 5
- Tracking ActivityLifecycleCallbacks on main thread HOT 1
- Exponea not initialized because of missing Gson Proguard/R8 rules HOT 1
- Lock contention issue HOT 2
- Shutting down the Cloud Messaging API (Legacy) in June, 2024 HOT 1
- Campaign parameter xnpe_cmp should not be required HOT 7
- Doesn't call onNewIntent HOT 1
- Image Decoding on Main Thread HOT 4
- Better way to initialise an AuthorizationProvider class? HOT 1
- Conflict between Exponea SDK WorkManager Initialization and WorkManager initialization in Application. HOT 2
- Timestamp not present in customers/events request body HOT 1
- Notification sound is played while the Notification chanel is set to be silent HOT 3
- Android 14 (Api 34) support HOT 2
- Remove DB calls on Main Thread HOT 3
- Exponea Safe Mode wrapper caught unhandled error java.lang.NoSuchMethodError HOT 9
- Migrate from javax.annotation:jsr250-api:1.0 HOT 2
- 3.15.0 Exponea Init error - java.lang.NoSuchMethodError: No virtual method add HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from exponea-android-sdk.