It might be fun to share our real world experience...
# multiplatform
t
It might be fun to share our real world experiences with multiplatform. I may complain and ask a lot of questions, but I have used the tech to great effect thus far: I have one shared library/framework used in 3 different iOS apps and 2 different Android apps, all in production. This includes maybe 12 different models and 20 APIs thus far (and I am not even half way to wrapping them all). I have a wrapper on Android that converts standard callback to Kotlin Result, and a wrapper on iOS side that converts the callbacks to Swift Result type (with some misc. Swift extensions to make things more Swift like). The major issues I have are around testing and switching between IntelliJ, Android Studio and AppCode and generally learning gradle well enough to be useful. But I am optimistic these wrinkles will be smoothed out and more and more of our logic will be moved into this shared code area (perhaps even one day be used from JS).
šŸŒ¶ļø 3
k
We’re actively shipping with a few smaller clients. Most of our prod work has been open source, but have some much bigger work in the pipeline for later in the year (hopefully). Many more people have heard of the tech and are interested. To be fair, that’s all we talk about, so maybe that’s all we hear about, but still. Curious why you need to switch to Android Studio? Most Android things are in Intellij.
t
Yes, perhaps I should move to IntelliJ instead of AS. I just recently purchased the whole JetBrains pack, so that I could use the Ultimate version. My typical work flow is like so: - When writing Android and common code, I use AS (with the app project loaded that has the shared code linked in via the Settings.gradle file). I cannot edit the iOS side here, because AS does not show the iOSMain source. - When writing iOS and common code, I have Xcode and IntelliJ running (with just the shared project loaded), since InteliJ shows the iOSMain source. I use the kotlin-native-cocoapods plugin to generate the podspec which is then linked to Xcode project. So I add code in IntelliJ, do a gradle build to make sure it works, then move to Xcode and do a run/debug.
j
Thanks for your feedback! I found just using AS+Xcode to be best combo. Appcode is a bit limited still Apart from IDE, what do you feel are the biggest/challenges and things missing? For me its def the TDD. (IDE support is flaky, lack of mockk, build times)
Is your common code unit tested?
t
Yeah, my dream would be IntelliJ for Android and AppCode for iOS, both linked to the common code and not interfering with each other (sometimes I have to invalidate cache and restart). Testing is too hard, yes. I expect to be able to write tests against common in common test, and then if I run iOSTest it will run the iOS tests then the common tests (in the context of iOS) and if I do AndroidTest (plain old check I guess) it would run the Android tests and then the common tests (in the context of Android). But this does not all work seamlessly yet. If I am running Xcode, and it needs to build the framework, then it chokes on the iOSTest task, so I have to disable it. I try to put the API tests in common, since that is where they are implemented, but getting all the coroutines testing in place correctly has eluded me.
j
My challenges w/ running tests are only within IDE. Executing via gradle works well for both platforms. To get around the lack of mockk support you are creating mocks/fakes manually?
t
Also I find that having half the build.gradle files online in Groovy, and the other half in Kotlin makes more work for everybody. We ought to all choose one or the other. I should not have to do code conversions in build files when I just want to write app code. šŸ™‚
I do not do any mocking - I just call the APIs directly and use real data..
j
I think using groovy/kotlin for build files is personal pref
Ok, I aim for complete unit test coverage. I use the ktor mock server to test api
t
I agree that it is personal pref, just pointing out it is more work for others to re-use work if the sample you have found does not match your personal pref
j
Have build times been an issue w/ productivity for you?
I think more impactful when doing TDD
t
They could always be better, and I certainly feel them, esp when I make a change in the common code and the build from Xcode. I did just buy a decked out mac mini (1TB PCI-E SSD and 32GB RAM) to try to minimize it though…
j
Cool. Which libs are you using? ktor+serialization+coroutine?
t
exactly. minimal coroutine code - it is all inside the shared code, with the external APIs using callback that return a (T, Error) tuple-like thing. Serialization has worked very well, though I have not done anything super complex yet. I also wrote a custom DateTime expect/actual layer to hide NSDate ThreeTen LocalDateTime differences for just the min of what we need.
āž• 1
k
What features from mockk would you absolutely need at a minimum for a marking framework? i’m working on a low fi minimum mocking plug-in
ā¤ļø 2
j
I think most basic case is just mocking responses: every { myClass.sayHi() } return { "Hello World" }
just the public apis. static, private etc I think are less common and are more common in legacy code
and basic verify/spy usage
o
@kpgalligan can sync in private or in this thread about some thoughts regarding plugin... (I am mockk author and tried to write plugin twice)
t
@tylerwilson even android studio works surprisingly good for basic kotlin ios code (and shows the source, too)
t
Right, if you are in Project view. I normally hang out in Android view. I did try to switch to IntelliJ for my Android projects, but none of my layout files would load. So back to AS for all Android builds for now. Thanks!
k
Our team uses AS after the project is set up, but project setup in AS isn’t as good. Library work I do all in Intellij.
t
Yeah, I try to work mostly in IJ when working in the shared code, esp. around trying to run tests (though I still have issues there too, so my code is currently undertested.) šŸ˜ž
k
@oleksiyp We chatted about this a bit. Happy to chat more, but a compiler plugin for Mockk will be pretty difficult, as you’ve mentioned in the past. I’m playing with an interim idea. An intellij plugin that will essentially inject code into a class to let you ā€œmockā€ interfaces. Far less powerful, but also far simpler without reflection. Something like this from the Swift world: https://github.com/seanhenry/SwiftMockGeneratorForXcode https://github.com/seanhenry/MockGenerator
I don’t know how useful that will be. However, Mockk has a ton of features. Trying to implement that as is with a compiler plugin seems exceptionally difficult. I’ve already coded the Intellij plugin part. It’s super basic, but again, far less functional. Haven’t finished it because I’m not sure it’s worth it. If there’s a reasonable path to Mockk on native, happy to chat.
o
In regards to compiler plugin, it is really a question on how to intercept calls. All the rest is kind of abstracted out in multiplatform code and +-should be automatically available. IntelliJ plugin is an interesting idea. Didn't think about it so far.
Two years ago there were plans to perform big refactoring to Kotlin compiler. Do you know if it was performed?
k
It’s in progress, as far as I know
Compiler plugins are still not ā€œpublicā€
That’s part of my concern. I’m thinking of the intellij thing as a temporary-ish, but also not sure how useful it’ll be (it’s been sitting around for a few weeks as a result)
u
@tylerwilson do you use multiplatform files (eg.
kotlinx-files
)?
t
I am unsure what kotlinx-files is, but I do not use it afaik. From kotlinx I use serialization and coroutines.