If init is called after Activity.onStart() than recording doesn't work

[LukasVykuka]

Is calling init before onStart mandatory? What if we need initialize SM independently on Activities or App lifecycle?

[adamblack]

Hello @LukasVykuka ,

could you try to call start() SDK method in case you are calling init method inside Activity.onStart()? That should do the trick.

[LukasVykuka]

Unfortunately it doesn't work.

Maybe it is caused by registering ActivityLifecycleCallbacks after onStart so onActivityStarted callback method can't be called?

We need init and start SM asynchronously in our business layer, independently on Activity lifecycle. So even if SM will be started after current Activity is displayed, recording should start immediately.

[adamblack]

Hi @LukasVykuka ,

apologies, my bad. :x I just released new version: 0.9.0.2.2.1-beta

There is a new init function called initIrregular It is almost the same as init, but as a last parameter you can pass your current activity. We will try to handle this internally in future releases but it is not so easy to find non-hackish way how to obtain current activity. This version is not officially mentioned in our docs since it is fix only for you but we are going to release new version soon with new functionality together with initIrregular function as well.

[LukasVykuka]

Thanks for effort. I will try this version during week.

[LukasVykuka]

Ok, this kinda work.

But I observe another related issue why we don't see complete recording. If SM is inited in App.onCreate() than evertime app is put on background I can see in logcat that MPEG4Writer is processing frames (and sending them to backend?), which is correct behaviour. But if SM is inited in activity which is not first activity of app than MPEG4Writer is not triggered by putting app on background, but is triggered periodically every ~30 frames while app is foreground.

Under "activity which is not first activity of app" imagine this scenario: LauncherActivity -> SplashAtivity -> LoginActivity SM is inited in SplashAtivity. LoginActivity is started with FLAG_ACTIVITY_CLEAR_TOP and FLAG_ACTIVITY_NEW_TASK flags so LauncherActivity and SplashAtivity are destroyed together.

Correct me if I'm wrong but what I can see from your obfuscated code, you increment and decrement some counter (perhaps by which you determine that frame processing should trigger or not?) if activity call onStart and onStop. Problem in this scenario is that counter is increment once (in SplashAtivity.onStart) but decremented twice (in LauncherActivity.onStop and in SplashAtivity.onStop) and therefore in LoginActivity counter is 0 after onStart and -1 after onStop so frame processing is not triggered.

Do you see this as issue?

[adamblack]

I will test this scenario on my side but it should work ok. Rendering/Sending of the video to the backend might not be always done while going to background. -> In most cases yes, but last batch might be cached and sent to our backend on next start of the app. It depends on memory/GC and if the system lets us do that.

In the example you described above, LauncherActivity should not be considered as a candidate for lifecycle logic since its onStop callback is no longer valid once SplashActivity is visible to the user. However, as I said, I can try the scenario on my side as well and let you know. :]

Just wondering, using classic init method in onCreate method in SplashActivity is not possible?

[LukasVykuka]

I will test this scenario on my side but it should work ok. Rendering/Sending of the video to the backend might not be always done while going to background. -> In most cases yes, but last batch might be cached and sent to our backend on next start of the app. It depends on memory/GC and if the system lets us do that.

Thanks for clarification.

Just wondering, using classic init method in onCreate method in SplashActivity is not possible?

Unfortunately nope because we fetch API key from our backend (we don't want hardcode key to app) while SplashAtivity is visible. Immediately after it's fetched we init SM.

[adamblack]

@LukasVykuka I tested several scenarios and it seems to me it works ok. Most relevant scenario to yours is that I used initIrregular just after successful login API call (basically SplashActivity) and before new activity was started.

[LukasVykuka]

You are right, it work. Recording appears in web after delay (from 30 minutes to 1 hour). But you above explain why it is and we are ok with it.

[adamblack]

Good to hear @LukasVykuka :]

We released new version, change log: https://github.com/smartlook/smartlook-android-sdk

Thanks for the input, initIrregular method is part of new version as well.