21 Jan 2021
When using Kotlin Multiplatform, the Kotlin/Native compiler produces a framework for iOS/macOS corresponding to the shared code
module (am assuming single module for purposes of this discussion). A number of different approaches are used then to ensure that the XCode project is wired
up to use that framework and that it is regenerated whenever an XCode build takes place after the shared code has been updated. These are typically based on use of CocoaPods plugin or custom gradle packForXCode() type task that’s
executed from an XCode run script. What’s common in these approaches is that a say iOS developer needs to have access to the shared Kotlin code and
a setup to allow building the framework. Generally this is seen as being the preferred way of working (allowing all developers to
update and build the shared code as needed). However there are cases where it does make sense for the shared code to be consumed in XCode as a prebuilt
binary and one option for that is to publish/consume the code as a Swift Package. In this article I’m going to outline how this was done for
PeopleInSpace project using the Multiplatform Swift Package
Gradle plugin.
03 Jan 2021
One area of “friction”, when developing an iOS client that uses Kotlin Multiplatform code, is the consumption of APIs from
shared code that expose a Kotlin Flow. This has typically required providing APIs for starting to collect the flow (and passing data back to iOS
client through provided closure/lambda) and then for cancelling the flow (through associated job). A related question then is how this process
can be integrated in to particular reactive frameworks being used on iOS. One example of such a framework is RxSwift and
Russell Wolf wrote an article (and published associated code )
last year that described how to manage process of integrating with that framework. I had started to use Swift’s Combine framework in a number of projects
and this article describes exploration to use Russell’s approach with that.
22 Dec 2020
There are a number of ways in which Android and iOS development is “converging” at the moment but I think the most exciting area
is the adoption of Declarative UI frameworks on both platforms -SwiftUI on iOS and Jetpack Compose on Android. As such,
my interest is always piqued, when I see tweets like following from Thomas Ricouard, by what would be involved in creating a Jetpack Compose version of a project like this.
An added interest in this case is the use of GraphQL and also saw this as an opportunity to try out the
Apollo GraphQL library (and, for bonus points, it’s Kotlin Multiplatform support!).
The code shown here is included as part of MortyComposeKMM project on Github.
28 Nov 2020
I recently updated PeopleInSpace project to make use of Kotlin Flow in shared multiplatform
code to poll for the position of the International Space Station (ISS). As part of that work I had initially updated PeopleInSpaceViewModel in
the Android app to use StateFlow (along with stateIn()) instead of LiveData. However there were some lifecycle implications of this change
when used alongside Jetpack Compose that have caused me to revert, for now, to using LiveData. This article is intended to capture results of that comparison.
Note that this is based on Jetpack Compose 1.0.0-alpha07.
03 Nov 2020
There have been indications in recent times of changes being made that would allow use of Jetpack Compose to develop UI for desktop apps. That became closer to reality today when it was noticed that EAP version of IntelliJ IDE has option now to create projects that target use of Compose on desktop JVM platforms (Windows, Linux, macOS). In this article I’m going to outline initial exploration of using this capability in PeopleInSpace repo. Changes made are included in this branch.
31 Oct 2020
Kotlinx Coroutines recently introduced the StateFlow API, described as “A Flow that represents a read-only state with a single updatable data value that emits updates to the value to its collectors”. This is generally seen as a replacement for LiveData on Android but also, importantly, something that can be used in shared Kotlin Multiplatform code.
03 Oct 2020
A big factor in the increasing adoption of Kotlin Multiplatform is the ever growing number of KMP libraries that are becoming
available. A new addition to this list, albeit in beta right now, is Kodein-DB, described as
an “embedded NoSQL indexed document database for Android, iOS, and client JVM”. In this post I’m going to describe what was
involved in adding initial use of Kodein-DB to BikeShare project.
25 Jul 2020
I’m in process of migrating Galway Bus over to use
Jetpack Compose and one particular requirement is the ability to
show bus stops (and also bus positions) on a Google Map. It seems like this is something that ultimately will exist
as specific Jetpack Compose @Composable but for now it looks like only way to add a map like this is using AndroidView.
15 May 2020
The options for adding dependency injection to a Kotlin Multiplatform project have up to now been pretty limited and if, like me,
you’ve been using Koin for your Android projects then you’ll have been excited to see following
announcement earlier today!
02 May 2020
Next up on our Kotlin Multiplatform journey I thought it would be interesting to look at bringing
PeopleInSpace to the web….using Kotlin/JS and making use of same Kotlin shared code
that we’ve used on other platforms. In line with project in general we’re going to make the minimum changes needed to support this (these posts are
primarily aimed at (a) giving people a “flavor” of what’s possible, and (b) providing minimal setup needed to get someone
up and running using particular technology). Note also that this is heavily inspired by
this excellent Kotlin/JS codelab.
18 Apr 2020
Most of the focus of Kotlin Multiplatform has, understandably, been on targeting the development of apps that run on Android and iOS. However,
other platforms are supported so when I saw following announcement of SQLDelight’s support for macOS I was curious to see what would be
involved in developing a basic app on that platform that uses same shared Kotlin code used in PeopleInSpace
(A little bit more background on initial effort working with Android and iOS in following post Minimal Kotlin Multiplatform project using Compose and SwiftUI)
25 Jan 2020
So, in previous post (Minimal Kotlin Multiplatform project using Compose and SwiftUI)
I gave brief overview of PeopleInSpace,
a small repository that was designed to illustrate key moving parts of a Kotlin Multiplatform project (running on Android, iOS,
and later, watchOS). However, although I’m reluctant to add much else to the project, one key gap was around locally persisting
the data we got back from remote server. The somewhat serendipitous combination of following activities in last few weeks also provided further encouragement
to add such functionality to the project (1) Neal’s addition of watchOS support to PeopleInSpace,
and (2) watchOS support was added to SQLDelight (Kotlin Multiplatform persistence library).
22 Dec 2019
In previous posts I’ve used GalwayBus repo to illustrate results
of various explorations I’ve done in to the use of Kotlin Multiplatform.
However I thought there’d be value in creating a more minimal project that would allow clearer illustration of key moving parts of a multiplatform
project and thus PeopleInSpace was created. It also provided opportunity
to try out use of Jetpack Compose for the Android app (with UI being developed on iOS
using SwiftUI - using pretty much
same approach outlined in SwiftUI meets Kotlin Multiplatform!).
21 Jul 2019
In Introduction to Multiplatform Persistence with SQLDelight it was mentioned that we still needed way to “manage observing of data updates (some interesting work being done on extension that supports Kotlin Coroutines Flow)”. Well, not long after that SQLDelight 1.1.4 was released with the aforementioned Flow support and this post gives short overview of exploration done to start using it.
21 Jun 2019
Most mobile apps store data locally on the device. This could just be some local settings/preferences but frequently also includes caching of data returned from queries to back end services. For at least the latter case that data is typically stored in an SQLite database (and, importantly, SQLite is used on both iOS and Android). There are low level libraries available to access SQLite database but this is normally achieved using libraries that provide a higher level abstraction….these typically being Core Data on iOS and, at least more recently, Room Persistence Library on Android.
08 Jun 2019
Announced at WWDC last week, SwiftUI is a new
declarative UI framework that is described as an “innovative, exceptionally simple way to build user interfaces across all Apple platforms with the power of Swift.”.
This approach to UI development has been popularised recently with emergence of Flutter, something
that was also likely the inspiration for Jetpack Compose which was announced at
Google I/O a few weeks back (SwiftUI appears to be at a significantly more advanced state of maturity
than Jetpack Compose and is available to try out in Xcode 11 beta…but also important to note that it does require iOS 13).
