The Magic Bullet 🎯
Hello friends!
I hope you're enjoying this Serial Maker newsletter! If you missed any of the past editions, make sure to check them out. And if you know someone who might benefit from this newsletter, please forward this email to a friend. 😀
For the last few years, I've been fine-tuning an approach to mobile app development that significantly speeds up production time, elegantly handles asynchronous uni-directional data flows, and keeps code clean and organized. My efficiency, my ability to develop for multiple platforms simultaneously, and app stability increased across all my projects.Â
Until it didn't.
This issue is all about how a magic bullet isn't always so magical 🎩
Â
TLDR
A single approach is not appropriate for all cases
The customer doesn't care how something is built
Done is better than perfect
My perfect framework
Each time I start a new project I build upon a framework I've pieced together to improve the development process of mobile apps. Virtually every mobile app project I see includes some form of local data storage, a server API component, deep linking, and logically grouped views. Using a combination of Realm for data storage, standard abstracted networking libraries for API consumption, an MVVM (model-view-viewmodel) design pattern, and reactive programming, I'm able to build virtually identical code bases for both iOS and Android apps. It's as close as code-once-deploy-anywhere as you can get without adding an extra layer of abstraction in front of native apps. This combination is amazing, and it's taken my development to the next level!
Â
Daykeeper
For the last month or so, I've been hard at work building a digital replacement for my bullet journal. I'm calling it Daykeeper. At its core, Daykeeper is a to-do app (I know, I know. It's different, trust me). So the majority of the user interaction takes place around lists of completable tasks. It should be super-simple. Table/Recycler views are built specifically for this purpose. As usual, this is going to need local data storage, a cloud API, and uni-directional data flow. So I built this using my go-to framework. It worked, for the most part. But as I've been using this day-to-day I'm continually finding things that just aren't quite right.
Simple things, like keeping the keyboard visible as your cycling through list items proved suprisingly difficult. Making a new bullet item the input focus immediately after adding it to a list was requiring all sorts of hacky workarounds. Things needed to happen instantly, and waiting for a view model to update the data, and reacting to that in the UI just felt clunky.
I spent weeks trying to get this to work at the level I expect in the existing go-to structure. And then I gave up. I went back to handling events right in the UI — the exact opposite of what I've been trying to do in my code for the last few years. But guess what? It just worked. And it works so perfectly, that I can't justify trying to build this any other way.Â
Â
Nobody cares
And I realize, no one will care about any of this. People using this app just want it to work. So I'm cramming all my separate concerns into the UI layer, and no one knows except for me. It works, and that's what matters. I've written about being a Pragmattic Perfectionist before. This is one of those times, and my work is better from it.
Â
Libraries in this email
Here's a short list of some of the libraries I'm using in my magic bullet framework. Just remember, they don't work for everything!
If you're interested in learning more about my approach to cross-platform native mobile app development, please reply and let me know if you'd like to see a blog article about it.
Keep making, and thanks for reading! 🙌
Hit reply to tell me what you're making. I'm looking for anyone interested in talking about their own side-projects and maker journey, so speak up if you'd like to appear in Serial Maker. I'd also love to know what you thought of this issue, and what you want to hear about in the future.
Until next week,
Craig
Â