I'm trying to actually learn koin now. i saw that ...
# koin
c
I'm trying to actually learn koin now. i saw that it was talked about at kotlinconf so im starting there. I'm kinda confused by this line. createdAtStart.
Why do you need createdAtStart. Wouldn't this next slide take care of things?
j
startKoin builds the graph, but it doesn't create instances of objects. Those (even singletons) are built as you
get
them. So if you need a singleton that is created right at `startKoin`call (for example if you need to do something at the application start) you need to mark it as
createdAtStart
🙌 1
if all singletons were built at the
startKoin
then larger applications might have some stuttering problems at start (frame drops, long startup time etc)
c
interesting. i guess i dont get why i didn't have to think about this with hilt/dagger. stuff was created as you needed it (i think?)
j
Normally, when you
get()
a class it's created. With this flag, however, it's immediately instantiated as soon as start Koin. One example of where this is useful would be a class that logs app startup time. You'd mark it as
createdAtStart
and then without needing to inject it anywhere, it will run on startup. This concept is called an eager initialisation. With Dagger you'd use it in the same scenarios. Another example would be pre-loading something for performance. I use this in only one of the apps I work on, to pre-load a cache before it's ever injected anywhere. We do the load on a background scope, but it's nice to have it already kicked off on app startup since in our case all users will touch this cache in their sessions.
🙌 1
c
thanks for the info. i guess in that same scenario. with dagger. i would think if i wanted to use that logger, then it'd already be instantiated before i use it. i will have to just use koin to get used to it i think
a
if you need activate the Koin logger to print what's going on under the hood, and see object creation: https://insert-koin.io/docs/reference/koin-android/start#koin-logging-for-android
c
Oh. thats awesome. TIL
👌 1
just following up on the androidLogger. it makes sense that it would be likely only in debug builds right? like... i should probably not log in my production builds?
a
yes, you can adjust level of logs if needed: androidLogger( <LEVEL> )