Hello, what do you think about the AndroidX DataSt...
# android
l
Hello, what do you think about the AndroidX DataStore API? What do you like, and what do you dislike? If you don't use it, is there any reason for that besides lack of time to focus on it? Curious about other's points of view on that.
⏸️ 1
j
I like the API, I don't like it is not Multiplatform
p
Lack of default encryption
☝️ 4
g
I’m just waiting it to get stable to give it a try. Right now we kinda abuse of SharedPrefs by saving json in there and we also use Hawk, which we’ve been long wanting to move away since it’s not maintained anymore. I recently found that we can use serializers other than Protobuf and it made me excited about it.
l
The API of AndroidX Datastor is now stable since it's in beta FYI.
g
oh, I missed the
API
word in your message, my mistake!
f
when I migrated to the datastore API the only challenge was how to read settings that are required at app start, as all the reads are asynchronous now. There is no out of the box solution to read something in a blocking way - I get that this is the idea after all, but there are scenarios where some info is needed before we can decide how to start the app.
👀 1
j
@Francesc just
runBlocking { ... }
f
I know, but that's less than ideal
l
That's most likely why Android 12 is getting first-class support for splahs/launch screens. That allows to delay displaying the UI without janking the main thread and delaying the event loop.
f
splash screens only kick in until the main Activity is inflated. If what you need to do is in the
onCreate
of the Activity, then the splash won't help you.
☝️ 1
a simple example, say you want to offer a user selectable override to set the theme (light/dark), in the view system this must be set in
onCreate
l
I don't "inflate" main activity. Been doing Kotlin-only UIs since 2017.
You can delay what you call in
onCreate
to after.
f
inflate is a generic term that means "the view is ready to be displayed", I don't mean literally inflation APIs
not if what you do must be done before the parent's
onCreate
l
Did you actually look at the splash screen Android 12 API?
f
no, but even if that's helpful, setting min API to 12 is something like 8 years in the future
l
Then, look at it. You'll see that it allows to customize the ending of the splash screen, so you can keep it until you get the data of whether you should use dark or light theme.
And for older API levels, just use the system, or keep the glitch 🤷
f
that's not really a solution then, is it?
1
just a workaround
l
That's a solution, that's the best you can get.
🚫 1
f
let's agree to disagree then
l
With current Android platform APIs at the very least.
If Android had a way to store a small amount of data that is guaranteed to be available without janking, on app process creation, you could use it for your use case, but since there's no such API, this is the best you can get unless you want to mess with the event loop by blocking the UI thread. I'm as unsatisfied as you by the current offering, but that doesn't mean there's no solution.
f
it's semantics, I would not call something that requires running
runBlocking
on your UI thread a solution - gets you what you need, yes, but it's not ideal. In my case I was not too concerned because I also migrated the app to Jetpack Compose so I can display a placeholder content until I have the data I need, but in the view system that's not an option.
1
l
I wasn't talking about
runBlocking
but about the other asynchronous things I mentioned.
In the view system, yes, it's a pain…
j
@louiscad another use case is setting a theme
the user can select one theme, it will be saved in a datastore, you want to avoid the UI flicks because it is showing the default theme and a few ms later the selected one (when the app starts)
l
@Francesc You dreamed of it, you got it. Android 12+ users will benefit: https://developer.android.com/reference/android/app/UiModeManager.html#setApplicationNightMode(int)
f
excellent, that's great to hear, and thanks for the heads-up!
🙂 1