Sharp-eyed readers of this series may have noticed something…suboptimal: Up until this point, we’ve been creating certain objects as global variables. They’re immutable, so that may be technically OK, but those of a certain age have been taught for years how wrong that is, so technically OK or not, it just feels gross. In this post, we’re going to fix that with by implementing inversion of control with Koin...
In the last entry, we looked at how to read data from the device’s local database using Room and display it on the screen, but we did so using dummy data. In this entry, we’ll look at how to use Room in our components to persist user-entered data in our SQLite database...
In the last post — months ago (and, yes, I hand typed the em dash, not some soulless AI :) — we added support for the Room database API, so now we can store data, but we have no way of seeing what we’ve saved. We also have no way of giving it data to save. In this post, we’ll tackle the first part by creating views to show what we have, then loading the database.....
So far, we have a runnable application that has two screens. We can navigate between those screens, but the app doesn’t really do anything. In this post, we’ll start to fix that. We’ll lay out the data model for the application, then introduce the library, Android Room, we’ll use to access it...
In the last post, we added the various pieces to make navigation possible and stopped JUST short of the goal line. In this post, we’ll finish up our navigation discussion by adding a new screen and seeing navigation in action...
So far, we have an app that runs but has only one "screen". Decompose makes adding more screens — and navigating between them — pretty simple. In this post, we’ll start to see how that’s done...
In the last post, we saw — and then ignored — a couple of interesting keywords: expect and actual. In this short post, I’ll give what I hope is enough of an explanation to satisfy the mildly curious.
To recap, the code in question looks like this:
composeApp/src/commonMain/kotlin/com/steeplesoft/giftbook/Platform.kt
interface Platform {
val name: String
}
expect fun getPlatform(): Platform
So… what.....
In this installation in my Mobile App Development series, I’m going to introduce our next architectural layer, Decompose. We’ll look at what it is, why you might want it, and how to get started...
In this installation in my Mobile App Development series, we’ll take a look at the most foundational piece of the puzzle, Compose Multiplatform. We’ll see what it is and how to use it...
In recent years, I’ve found myself needing to build a mobile app here or there, and it has been, at times, a bit of a struggle as the landscape — and opinions about it — are wide and varied. There are debates about native, hybrid, and cross-platform approaches, and once you’ve made that decision, you have to wade through a lot of opinions on what library.....
Sharp-eyed readers of this series may have noticed something…suboptimal: Up until this point, we’ve been creating certain objects as global variables. They’re immutable, so that may be technically OK, but those of a certain age have been taught for years how wrong that is, so technically OK or not, it just feels gross. In this post, we’re going to fix that with by implementing inversion of control with Koin...
In the last entry, we looked at how to read data from the device’s local database using Room and display it on the screen, but we did so using dummy data. In this entry, we’ll look at how to use Room in our components to persist user-entered data in our SQLite database...
In the last post — months ago (and, yes, I hand typed the em dash, not some soulless AI :) — we added support for the Room database API, so now we can store data, but we have no way of seeing what we’ve saved. We also have no way of giving it data to save. In this post, we’ll tackle the first part by creating views to show what we have, then loading the database.....