Hello,
I would like to check with you about any performance issue in adobe analytics tracking in Android app when Tag need to trigger on previous page when visitor visit back from current page.
In adobe analytics tracking in Android app, currently we are using onCreate/onCreateView function to trackState for page tracking.
Is my understanding is correct about page tracking in onCreate/onCreateView of previous page can't trigger the tag again in Android app when visitor visit back from current page?
To trigger tag on previous page, do we need to write trackState in onResume function?
If we write trackState in onResume function, is there any impact in Android app's performance?
Any recommendation for how to implement this?
Thank you.
Solved! Go to Solution.
Views
Replies
Total Likes
Actually, Adobe's documentation is referring to onResume for the lifecycle tracking and hence I use that for trackState as well, https://aep-sdks.gitbook.io/docs/getting-started/enable-debug-logging#lifecycle-metrics
Referring to the Activity lifecycle at https://developer.android.com/guide/components/activities/activity-lifecycle#alc, onResume is the better place than onCreate, as onCreate will only trigger once when the activity is created after the app process had been killed.
I didn't test the following to prove it.
So not only the "previous page", even when the user navigates to some other different activities in the Android app and navigate back to this very original activity via normal menu navigation, there will no more trackState from onCreate as the app process had never be killed and hence no onCreate invoked.
OnResume is called when the app is sent to the background and then resumed... it doesn't directly correspond to your onCreate or onCreateView. OnResume is tied more closely with the onPause function.
You should absolutely be using onPause to stop analytics when the app is sent to the background, and onResume when the app is brought back to the forefront... Assuming you have LifeCycle metrics enabled, onPause when the app is sent to the background will prevent inflated "crashEvents" from firing (if analytics is not paused, and the app is sent to the background, then the user force closes the app by swiping it off, a Crash will be reported on the next launch - this is not what you want). Using the onPause to pause Lifecycle metrics, then restarting LifeCycle metrics using onResume is the recommended implementation. You should be able to let you developers know what action to perform on onResume (including restarting lifecycle metrics, and you could even take a timestamp of when onPause was fired and send on trackState IF the time elapsed is more than 30 mins - or whatever your session timeout is set to)
As for returning to the previous page, I am not entirely sure all the Android actions that are available (I am not a mobile developer), but in order to re-display the page, the developers must be leveraging some action, they should be able to trigger analytics with that.
Actually, Adobe's documentation is referring to onResume for the lifecycle tracking and hence I use that for trackState as well, https://aep-sdks.gitbook.io/docs/getting-started/enable-debug-logging#lifecycle-metrics
Referring to the Activity lifecycle at https://developer.android.com/guide/components/activities/activity-lifecycle#alc, onResume is the better place than onCreate, as onCreate will only trigger once when the activity is created after the app process had been killed.
I didn't test the following to prove it.
So not only the "previous page", even when the user navigates to some other different activities in the Android app and navigate back to this very original activity via normal menu navigation, there will no more trackState from onCreate as the app process had never be killed and hence no onCreate invoked.
Views
Likes
Replies
Views
Likes
Replies