Joda-time-android no longer works on sync process beginning 2.10.9

[elye]

Beginning version 2.10.9, where App Startup is used in Joda-time-android, the Joda time doesn't get initialized in the non-main process anymore. When if I switch back to version 2.10.7.2, then everything works

My suspicious it's the AppStartup bug/issue, where it only setup for the main process and not the other process. Not sure if there's any setting to get it setup for all processes. e.g. it is not working in the sync process of a syncService i.e. any services with android:process set.

To demonstrate the issue, I have created a very simple design in https://github.com/elye/issue_android_joda_time_app_startup with

• MainApplication
• MainActivity
• MainService
• SyncService
• AccountService

When running it, the MainApplication, MainActivity and MainService that run on the main process works fine.
But the MainApplication and MainService that run on the sync process can no longer get the timezone.

Run the app and track the log using TrackDebug, you'll get log like below

D/TrackDebug: MainApplication com.example.myapplication Thread[main,5,main]
D/TrackDebug: - MainApplication America/New_York
D/TrackDebug: Dispatchers.IO com.example.myapplication Thread[DefaultDispatcher-worker-2,5,main]
D/TrackDebug: - Dispatchers.IO America/New_York
D/TrackDebug: MainService com.example.myapplication Thread[main,5,main]
D/TrackDebug: - MainService America/New_York
D/TrackDebug: MainApplication com.example.myapplication:sync Thread[main,5,main]
D/TrackDebug: - MainApplication The datetime zone id 'America/New_York' is not recognized
D/TrackDebug: Dispatchers.IO com.example.myapplication:sync Thread[DefaultDispatcher-worker-1,5,main]
D/TrackDebug: - Dispatchers.IO The datetime zone id 'America/New_York' is not recognized
D/TrackDebug: SyncService com.example.myapplication:sync Thread[main,5,main]
D/TrackDebug: - SyncService The datetime zone id 'America/New_York' is not recognized

Hope this ease debugging from your side.

[dlew]

Interesting; I'll look into it. Might be an issue with the App Startup lib.

In the meantime, you can manually initialize joda-time-android in other processes using JodaTimeInitializer. (Or just keep using 2.10.7.2)

[dlew]

According to the AndroidX app startup author, this is on purpose. I will look into the best way to support multiprocess apps and add it to the FAQ.

[dlew]

@elye Do you find the explanation in #279 to be sufficient?

[elye]

Sorry for the late response @dlew.

My preference would be to remove App Startup and use back the previous JodaTimeAndroid.init() in the application. This is cleaner and works across both single and multi-process app.

Or optionally keep the JodaTimeAndroid.init() together with the App Startup, and the init() will do the instantiation if the App Startup didn't kick in. Else do nothing. So you can have the benefit of both world (e.g. for those using single process, they dont' need to init(), but for multi-process, they don't need to setup the App Startup for each process.

As per your new documentation, for using AppInitializer.getInstance(this).initializeComponent(JodaTimeInitializer::class.java), I thought we need to provide something like below as well. (if not won't it get double initialize in the main process") ?

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    tools:node="merge" >
    <meta-data android:name="net.danlew.android.joda.JodaTimeInitializer"
        tools:node="remove" />
</provider>

[dlew]

I don't want to go back to making everyone call init() because multi-process is the corner case - there are far more people benefitting from not having to think about joda-time-android's initialization.

We could set things up so that calling JodaTimeInitializer is idempotent, then you can re-init to your heart's content and nothing will go wrong. (Though I think that might already be the case, really, but we can really make sure it is.)

Also, if you use AppInitializer then you do not need the <provider>.