In the first part I wrote a bit about what I want to do and did a small investigation to see if this is technically possible or not. Now it’s time to think a bit how the application will function, how it will run and based on these, how I will build it.

Big picture design

In essence, our application model is a list of screens, each screen having some properties (like layout, number of fields) and a list of fields. The core model is quite simple:

To this, we will need to have some sort of importer, to load and save this model from the .fit file.

The Importer and Exporter, most probably, will be used to translate our model to and from the significantly more complex .fit file, handling all the binary fields, any checksums and this will be the point were the FIT SDK library will be used. But other than that, the model is totally decoupled from the FIT SDK and if in the future this SDK changes, it shouldn’t affect too much the core functionality.

Also, by inverting the dependency between the core models and the Importer/Exporter, I’m ensuring the app will easily support other formats in the future, either a different activity format from Garmin or, why not, devices from other vendors.

So, even though I don’t see an immediate need to have multiple importer/exporters here, I prefer to create this extensibility point from the very beginning (it will also help with testing the application).

Above the models will sit the UI, to allow the user to modify these lists of screens of data fields. It will, in its most basic form, look something like:

But it would be more user friendly to display something more familiar to the user, like the actual image of a watch and arrange the fields the same way the watch displays them.

Both UI types should be easily to achieve (and change between them) with the help of the MVVM pattern: the Viewmodels can even be the same, and just the View will be different.

With this in mind, I can also have different UI’s for different platforms and have the core functionality and the Viewmodels be the same everywhere.

I want to be able to run this at least on Windows but also on some Android and iOS phones (why not?) and definitely on the web, in a browser, maybe the user doesn’t want to install an app just to edit a few times some activity profiles on his watch, so having the app running in a browser definitely worth the hassle of dealing with a bit of CSS.

But if I make the app to run in the browser, then why bother anymore with Windows desktop and Android and iOS? Well, the browser is a bit limited in accessing USB devices so it might not be a very straightforward experience for the user. The user will need to browse his watch’s file system, find the appropriate activity profile files and open those in the browser.

With a dedicated Windows desktop app, I have more access and I can directly read and display in the app the existing activity profile files, the user dealing only with changing the fields. Maybe it doesn’t seem like much, but UX is very important, even for such a simple application.

This would be a great fit for the new MAUI / Reunion project / .Net 6, to have the same code and be able to deploy on multiple platforms, but the few tests I did as of now (July 2021) didn’t work as expected, so for the moment I will stick with .Net 5.

I will aim, however, to have as much code as common as possible, definitely the models and the core functionality, the importer and the exporter, but also at the Viewmodels level. Ideally, only the UI part should differ. I will start with Windows desktop (WPF) and then do the Blazor version, and finally an Android one (maybe by that time, .Net 6 will be more usable).