[QUESTION] Best practices for re-initializing Split after shutdown() about android-client

[trod-123]

Thanks for getting back @chillaq !

We have several activities in our app from which a user can leave, so if we were to opt in for such a solution it'd require larger refactoring than necessary just to solve this issue that on the surface I think can have a more localized solution.

Have you other clients that had a similar issue?

What other key things does splitClient.destroy() take care of? Since we don't rely on Split for tracking our impressions, is it safe for us to forego this call entirely and keep our SplitClient running until it is killed by the OS when the app is destroyed?

[chillaq]

Hi @trod-123

When client.Destroy is called, then the factory instance is disabled, to use the SDK again, you would need to create new factory object, otherwise it will return control.

If your app do not exist after onStop hook, then it does not makes sense to use it for client.Destroy. I would recommend using different hook, checkout this link for suggestions: https://stackoverflow.com/questions/31566344/how-can-i-manage-onapp-exit-event-and-do-something-before-app-closes

The advantage of using client.Destroy is it will post all impressions in the cache to Split cloud that were not posted.

Hope that helps.

Thanks
Bilal

[pkang94]

Bumping,

@chillaq can you or someone else from Split confirm that it is safe to forego the SplitClient.destroy() call, and that only drawback might be that some cached impression data is lost?

From what I could tell, the main benefit of calling SplitClient.destroy() is that:

• unpublished impressions will be flushed
  • we do not currently use Split for impressions, so there is no loss here
  • it is not even guaranteed that these impressions will be uploaded
• background tasks (e.g. synchronizing threads) will be stopped
  • background tasks will be destroyed anyways once application process is destroyed
• cache is cleared
  • cache will be destroyed anyways once application process is destroyed
  • app will always create a new SDK factory + client when launched, no risk of referencing old client’s cache
• connection is closed
  • connection will be closed regardless once application process is destroyed

If I am understanding correctly, as long as we follow recommended best practices re: initializing new SDK factory / client on app launch, there should be no risk of not calling SplitClient.destroy() on app close.

Sources:
https://help.split.io/hc/en-us/articles/360020343291-Android-SDK#shutdown
https://www.youtube.com/watch?t=459&v=ooiDZ6eL-xw&feature=youtu.be
https://help.split.io/hc/en-us/articles/360049698832-Calling-client-Destory-does-not-post-impressions-in-Android-SDK

[chillaq]

Hi @pkang94, Actually even if you don't use destroy(), the cache will still be flushed when the app shuts down, the SDK will post the impressions as it hooks into the app shutdown hook.

client.destroy() is only recommended if you:
1- Do not need to use the SDK anymore until the app restart.
2- You need to create another factory using different user id, so we don't have two factories dunning at the same time.

Hope that helps.

Thanks
Bilal

[pkang94]

Hey @chillaq ,

Thank you for your quick response. I would like some clarification on the following:

1- Do not need to use the SDK anymore until the app restart.
I would like to to confirm what sort of scenario this would involve. Would this be something like "we initialize Split on app launch, but only use it in one specific flow. Once the user passes this flow, we no longer use Split so destroy the client (and re-initialize next time user launches the app)?

Also, can you explain how this shutdown hook works? I assume it's line 215 in SplitFactoryImpl.java:

Runtime.getRuntime().addShutdownHook(new Thread() {
    @Override
    public void run() {
        // Using the full path to avoid conflicting with Thread.destroy()
        SplitFactoryImpl.this.destroy();
    }
});

I have seen the associated logging messages (lines 189-205) in our app when we directly destroy the Split client on logout.

2021-10-15 14:24:07.227 V/SplitFeatureManagementService<main>: __dispose__
2021-10-15 14:24:07.271 W/SplitSDK: Shutdown called for split
2021-10-15 14:24:07.272 E/SplitSDK: An error has ocurred while parsing stream from:  : stream closed
2021-10-15 14:24:07.985 I/SplitSDK: Flushing impressions and events
2021-10-15 14:24:07.985 I/SplitSDK: Successful shutdown of lifecycle manager
2021-10-15 14:24:07.985 I/SplitSDK: Successful shutdown of segment fetchers
2021-10-15 14:24:07.985 I/SplitSDK: Successful shutdown of metrics 1
2021-10-15 14:24:07.986 I/SplitSDK: Successful shutdown of metrics 2
2021-10-15 14:24:07.986 I/SplitSDK: Successful shutdown of ImpressionListener
2021-10-15 14:24:07.988 I/SplitSDK: Successful shutdown of httpclient
2021-10-15 14:24:07.988 I/SplitSDK: Successful shutdown of manager
2021-10-15 14:24:08.771 I/SplitSDK: Successful shutdown of task executor

However, I have not seen these logging messages when the app is closed (e.g. via removing from recent apps list) or when the phone itself is shut down. I also tried use this shutdown hook directly from our app with custom logging messages, but have not seen it being triggered either. How do you know that this shutdown hook works as intended?

[chillaq]

Hi @pkang94 , you are correct, for Android and iOS, shutting down the app without calling cleint.destroy() will not post the impressions, this is only supported in Javascript running on browser.
For now it is recommended to call client.destroy() when the app is shutting down.

Thanks
Bilal