Question: in which cases is `AndroidThreeTen.init(this)` a "must"?

[jakewharton]

Question: in which cases is `AndroidThreeTen.init(this)` a "must"?

[AndroidDeveloperLB]

Or maybe it's possible to load a compressed file from the start?

[JakeWharton]

It is always required as it loads the timezone database.

[JakeWharton]

And it's already compressed

[AndroidDeveloperLB]

Why do I need the timezone, though?
I mean, the LocalDate doesn't have a timezone...
And, is it possible to use the built in one of Android API 26, instead of the one of the library, when it's the current one that the app runs on ?
This could remove the need of this initialization...

[JakeWharton]

Your code can switch between the platform one and the backport but this library won't be providing that functionality. If you want to try to use the library without the timezone database you're free to, but there are no guarantees the entirety of the code which uses it is in ThreeTenBP, not this library, so I don't know what uses it or what doesn't.

…

On Tue, Jan 9, 2018 at 10:12 AM AndroidDeveloperLB ***@***.***> wrote: Why do I need the timezone, though? I mean, the LocalDate doesn't have a timezone... And, is it possible to use the built in one of Android API 26, instead of the one of the library, when it's the current one that the app runs on ? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEUt8NmX1eAk4JfCJJ9YqxJgYcsrKks5tI4HAgaJpZM4RXwDN> .

[AndroidDeveloperLB]

That's too bad.
About compression, I think it can be better compressed, even with zip.
Look :

[JakeWharton]

Compression optimizes for storage, not decoding. You'll cause more memory to be used and more CPU to be used in order to load the data. If you want to speed up the load then removing compression and enabling less work is what's desired. But regardless, the format of the file is an implementation detail of ThreeTenBP and not this library which only repackages it into the assets of the aar and tells ThreeTenBP to load it from there.

…

On Tue, Jan 9, 2018 at 10:20 AM AndroidDeveloperLB ***@***.***> wrote: That's too bad. About compression, I think it can be better compressed, even with zip. Look : [image: image] <https://user-images.githubusercontent.com/5357526/34728000-493df91c-f561-11e7-8189-ba7f450b0a30.png> — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEQ9CZRjvicyyuKKmAVU1IMaUwdNcks5tI4OrgaJpZM4RXwDN> .

[AndroidDeveloperLB]

But isn't loading from storage the slower part?
I mean, RAM&CPU usage is always faster than disk read, no?

Or maybe it depends on the file that's loaded?
I guess if the compression is too complex, it could in theory become slower, but is it really the case here?

[JakeWharton]

You can use systrace to confirm one way or the other.

…

On Tue, Jan 9, 2018 at 10:35 AM AndroidDeveloperLB ***@***.***> wrote: But isn't loading from storage the slower part? I mean, RAM&CPU usage is always faster than disk read, no? Or maybe it depends on the file that's loaded? I guess if the compression is too complex, it could in theory become slower, but is it really the case here? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEeGOfL1Ixv_9diABQfOmKXxVz44rks5tI4dZgaJpZM4RXwDN> .

[AndroidDeveloperLB]

I've tested the next codes, and compared the time it took for both:

    private fun originalLoading() {
        val provider: TzdbZoneRulesProvider
        var inputStream: InputStream? = null
        try {
            inputStream = resources.openRawResource(R.raw.original)
            provider = TzdbZoneRulesProvider(inputStream)
        } catch (e: IOException) {
            throw IllegalStateException("TZDB.dat missing from assets.", e)
        } finally {
            if (inputStream != null) {
                try {
                    inputStream.close()
                } catch (ignored: IOException) {
                }
            }
        }
        ZoneRulesProvider.registerProvider(provider)
    }

    private fun newLoading() {
        val provider: TzdbZoneRulesProvider
        var zin: InputStream? = null
        try {
            zin = ZipInputStream(resources.openRawResource(R.raw.tzdb))
            val ze = zin.nextEntry
            provider = TzdbZoneRulesProvider(zin)
            zin.closeEntry();
        } catch (e: IOException) {
            throw IllegalStateException("TZDB.dat missing from assets.", e)
        } finally {
            if (zin != null) {
                try {
                    zin.close()
                } catch (ignored: IOException) {
                }
            }
        }
        ZoneRulesProvider.registerProvider(provider)
    }

I'm not sure if I did the correct unzip-loading, but newLoading took around 90 ms, while the originalLoading took around 60 ms.

So I think you are right here.
Did I implement it correctly though?
And why did you put the file in the assets folder? Just to keep its original file name?
I think using assets folder is almost the same as the raw resource folder, no?

[JakeWharton]

See http://blog.danlew.net/2013/08/20/joda_time_s_memory_issue_in_android/ for an explanation.

…

On Tue, Jan 9, 2018 at 10:58 AM AndroidDeveloperLB ***@***.***> wrote: I've tested the next codes, and compared the time it took for both: private fun originalLoading() { val provider: TzdbZoneRulesProvider var inputStream: InputStream? = null try { inputStream = resources.openRawResource(R.raw.original) provider = TzdbZoneRulesProvider(inputStream) } catch (e: IOException) { throw IllegalStateException("TZDB.dat missing from assets.", e) } finally { if (inputStream != null) { try { inputStream.close() } catch (ignored: IOException) { } } } ZoneRulesProvider.registerProvider(provider) } private fun newLoading() { val provider: TzdbZoneRulesProvider var zin: InputStream? = null try { zin = ZipInputStream(resources.openRawResource(R.raw.tzdb)) val ze = zin.nextEntry provider = TzdbZoneRulesProvider(zin) zin.closeEntry(); } catch (e: IOException) { throw IllegalStateException("TZDB.dat missing from assets.", e) } finally { if (zin != null) { try { zin.close() } catch (ignored: IOException) { } } } ZoneRulesProvider.registerProvider(provider) } I'm not sure if I did the correct unzip-loading, but newLoading took around 90 ms, while the originalLoading took around 60 ms. So I think you are right here. Did I implement it correctly though? And why did you put the file in the assets folder? Just to keep its original file name? I think using assets folder is almost the same as the raw resource folder, no? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEU006GSTMg23wIiXnWYKttEERh-Gks5tI4xqgaJpZM4RXwDN> .

[AndroidDeveloperLB]

An explanation to what? The assets decision? This :

For some reason getResourceAsStream() does some rather extreme caching and takes up a ton of memory if you use it**.

?

You mean it take much more RAM when using res/raw ? But why is it this way? Is it true for all Android versions? Is it always recommended to avoid using res/raw, and use assets folder instead? If so, shouldn't Google suggest such a thing in the IDE then?

But they talk about taking it from Jar, not from resource folder. Or is it the same?
And, is there any way to make it use the timezones set by the OS, if it's API 26 and above, so that it won't need to load it from a file at all?

I've now tested on my device (Nexus 5x with Android 8.1), and here are the results of testing assets vs raw :

using original call of AndroidThreeTen.init(this) :
Before call: used 1.4 MB
After call: used 2.4 MB

using function of originalLoading :
Before call:1.5 MB
After call: 2.5 MB

I don't see much difference here. On some cases I've ran it, one of them took a tiny bit more, and on others the other. Maybe it got optimized on Android 8.1 or somewhere below?
Maybe it's one of the optimizations they did, that make it now hard to notice, like what they did with Bitmaps (I wrote about it here) ?
Then again, my way of measuring might not be so accurate, as it's tricky to measure memory on Java world...

Here's my POC to test it:

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        val handler = Handler()
        System.gc()
        handler.postDelayed( {
            Log.d("AppLog", "heap mem before:" + getHeapMemStats(this) )
//        AndroidThreeTen.init(this)
            originalLoading()
            System.gc()
            handler. postDelayed({
                Log.d("AppLog", "heap mem after:" + getHeapMemStats(this) )
            }, 1000)
        }, 1000)
    }

fun getHeapMemStats(context: Context): String {
    val runtime = Runtime.getRuntime()
    val maxMemInBytes = runtime.maxMemory()
    val availableMemInBytes = runtime.maxMemory() - (runtime.totalMemory() - runtime.freeMemory())
    val usedMemInBytes = maxMemInBytes - availableMemInBytes
    val usedMemInPercentage = usedMemInBytes * 100 / maxMemInBytes
    return "used: " + Formatter.formatShortFileSize(context, usedMemInBytes) + " / " +
            Formatter.formatShortFileSize(context, maxMemInBytes) + " (" + usedMemInPercentage + "%)"
}

Which Android version do you have? Can you test it on older Android versions, maybe?