Enol Sim贸n
02/02/2024, 3:04 PMMainActivity
with several fragments, and I was for now using AndroidView
to inflate those fragments. It means that I was actually keeping the fragments, with its functions for UI in it, and now I reached the point that I wanted to implement those sections on iOS.
For that, I wanted to get ride of the fragments, and just create Compose
functions that I can import directly on iOS. So I will keep the MainActivity
to include the composables inside, and a UIViewController
that will do the same on iOS.
However I am realizing now that for some screens, I will need to use native code for some UI interactions, like the login in FB and Google dialogs, opening the mail client, etc. If for example I have a kotlin file called SplashScreen.kt
where I have the @Composable
functions, where can I define those platform specific functions? One alternative would be to implement them in the Activity/UIViewController and pass them as arguments to the composable. I think that I should use expect/actual
though, but I don鈥檛 know what is a good practice for that in terms of where I should put those expect
functions.
Thank you in advance!McEna
02/03/2024, 6:45 AMEnol Sim贸n
02/03/2024, 11:40 AMexpect/actual
approach, but I understand that can not put the expect
functions inside the Screen
file, dou you know if there is any convention or standard about where to place them? In the ui
directory together with the screen itself? SHould it be called something like Screen_Impl
or something similar?McEna
02/03/2024, 2:26 PMexpect
inside a class from the common sourcesetMcEna
02/03/2024, 2:31 PMMcEna
02/03/2024, 2:33 PMexpect/actual
modifiers, and you had several submodules consuming a particular body of code which in turns needs to change between flavors/build types/variants, how would you shape the code so you can do that?McEna
02/03/2024, 2:36 PMinterface
declaration, but platform-wide.McEna
02/03/2024, 2:40 PMactual
implementations. Personally, I keep them as part of each layer. So, if i have some ui
that needs redefining, I will have the common part in the ui
package from the common sourceset, and the same package for the implementation in the platform sourcesets.McEna
02/03/2024, 2:46 PMMcEna
02/03/2024, 2:49 PMMcEna
02/03/2024, 2:53 PMMcEna
02/03/2024, 2:56 PMPlatformBoundImageLoader
could be an interface
instead of an expect
class, and you would have to remember to implement and inject the right instance across every sourceset. Instead of this, you would pass an specific implementation of PlatformBoundImageLoader
(in fact, that's the initial implementation of the image loading process).McEna
02/03/2024, 3:04 PMexpect/actual
, so they are a bit verbose and convoluted, but at this point, you know how to inject platform code inside common code, and you can start refactoring those parts (which is what I started to do, hence the expect/actual declarations).McEna
02/03/2024, 3:09 PMexpect/actual
, but rather regular interfaces. Same thing when structuring the rest of your code. Disassemble the problem as usual, then use expect/actual
if it makes sense, and at the level it does, either for functions, or classes.Enol Sim贸n
02/05/2024, 8:59 AM