https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
m

Marko Novakovic

02/06/2023, 9:07 PM
if I want to leverage `expect`/`actual` mechanism and I want to have abstraction for testing, would this be good practice or there is some other way?
Copy code
interface AccountStore {
    val account: Flow<Account>
}

class AccountStoreImpl(platformAccountStore: PlatformAccountStore) : AccountStore {
    override val account = platformAccountStore.account
}

expect class PlatformAccountStore {
    val account: Flow<Account>
}
AccountStore
is abstraction and it’s used for testing and
PlatformAccountStore
is, as name says, where I will implement Android and iOS specific behaviours
p

Pablichjenkov

02/06/2023, 9:11 PM
You can place it in the sourceSet for androidApp and iOSApp inside the "shared" library folder. Or you can define it in the application code. Either in Kotlin in the case of Android and swift in the case of iOS
m

Marko Novakovic

02/06/2023, 9:15 PM
I can skill `expect`/`actual` altogether. I didn’t see the forest for the trees 😄
it will not force me to write actual implementation tho. but it’s not a big deal
p

Pablichjenkov

02/06/2023, 9:17 PM
Exactly 💯
I have the same feeling
m

Marko Novakovic

02/06/2023, 9:17 PM
thanks 🙂
r

russhwolf

02/07/2023, 12:19 AM
Once you have an interface for something, having an
expect class
is almost always redundant and just gives you another layer you have to change any time you adjust the interface. If you want to have a default in common without needing to inject anything, I usually do something like
expect val defaultAccountStore
and then the
actual
can be the platform implementation.
m

Marko Novakovic

02/07/2023, 10:33 AM
yes
expect
with
interface
feels weird, thanks
6 Views