Reckoner Update May 2023

Last updated on

This has been a bit of a slower month for Reckoner development. Almost every weekend had something going on. Even with that, I was able to get quite a few things complete.

☁️ Sync

I am taking a hard pivot with cloud syncing. Originally I was going to support a server based synchronization model. As noted in my State of Reckoner post, I had already integrated PocketBase with the application and created a synchronization model for it. However, this does require the user to setup the server. I was also planning to provide a turnkey hosting solution utilizing something like Supabase or AppWrite. However, there are a couple of tradeoffs with these approaches.

client server model
Typical client server model

Setting up a shared synchronization server does incur some cost on my end, particularly if I don’t get people to pay for it. People can be particularly stingy for something that they assume should be available out of the box. Even if the other free services that support it use it to harvest your data. To that end, I am going to investigate adding peer-to-peer synchronization into Reckoner.

When talking to my brain trust, I envision this as being similar to Brave browser sync or Syncthing. I even found a dart package which implements data and some media peer-to-peer connection via PeerJS. I plan to add something like a scannable QR code which devices can use to uniquely connect. For the end user, the complexity of this would be non-trivial but should be doable. And this would make device syncing free without the need for me to setup expensive infrastructure.

peer-to-peer model
Peer-to-peer synchronization model

Under the Hood Changes 🧑‍🔧

I made changes to the primary keys to use string UUIDs over integer incremented IDs. This should prevent synchronization conflicts which could arise if two clients created a transaction before they synced. I also did start on preliminary encryption management for the synchronization server, but could probably reuse the code for peer-to-peer synchronization.

The application state management was getting a bit unwieldy as I was using the Change Notifier Provider pattern for all of my application level state management. I just happened to stumble on State Notifier, which is similar to Change Notifier with the exception that the object is immutable. This greatly simplified state management as I could directly access data in a build context without being concerned with the caller mutating the object directly. While this is not a big concern for a single person project, it’s good to have these safeguards in place to prevent bad practices in the future. I can already see how this simplified and made my code more readable.

Flutter actually has a lot of options on how you can manage application state. I initially tried using the BLoC library, but found that it was more complicated than the actual needs of Reckoner. The simple state management using Provider was more than sufficient for my needs. Although, I may investigate the GetIt package as that does have some appeal for application global state with better dependency injection for testing.

Reckoner α Release 🎉

I am soft launching Reckoner v0.1 builds! While the latest web build has been available for some time at app.reckoner.finance, I have spent most of this month getting releases available for Linux (AppImage and Flatpak) and for Android. This is NOT stable and should be used for testing only! I spent some time trying to package it as a snap package, but couldn’t seem to get it to work. Check out the releases page to download the Linux Flatpak or Android APK.

Edit: Removed reference to the FDroid repo.

Launch as Web AppGet it on Codeberg

What’s Next

I’m now going to divide tasks based on what will be needed for the next release.

General Tasks

Version 0.1: Single Device Operation

Version 0.2: Multi-Device Synchronization

Version 1.0 (Future)


← Reckoner Update April 2023

Reckoner Update June 2023 →