Remote control aircraft flight logging
Remote Control Aircraft Flight Logging V2

Why this app?

My first big app was the Remote Control Aircraft Flight Log app, which consumed a great deal of my time and proved a very ambitious app to write. The result was Ok, but was also way more complex than I had hoped for. Learning doesn't usually result in a clean, slick result. This was definitely not clean and slick.

So, this app was born. It's a new version of the same flight log and uses some of the same code (not everything was over complicated in the old app). However, I wanted an iPad specific version and I wanted to be able to use some of the iOS 16 features that I couldn't use in the previous app.

The app you see here is a work in progress. It's a long way from a finished and polished flight logging app. That said, the majority of it hangs together and I am working out the bugs I introduced by simplifying the code and eliminating a lot of the intermediate objects that I simply didn't need. It will continue to evolve.

Key Learning Points

What did I want to achieve

My previous flight log was constrained by a desire to make it compatible with iOS 15. NavigationView is a great tool, but it makes somethings very difficult and I found myself writing a lot of code to ensure detail views were being updated properly. It worked but was way more complex than I felt it needed to be.

Version 2 uses NavigationSplitView which enhances the way split views work in iOS 16 and allowed me to remove a lot of the code I had written to maintain detail views. Coupled with the removal of some intermediate Data Transfer Objects (DTO's) that I just plain didn't need, I was set to remove a lot of complexity for this version.

So, my aims for this version expand on the previous version by adding:

  • Core Data.
    • Simple migration to add a object and relationship.
    • Ad-hoc query - retrieve only what I need for certain functionality rather than populating whole object graphs for minimal data.
  • Reusing and expanding the shared framework I created for the V1 code.
  • Greatly simplifying the code.
  • Using iOS 16 specific components to simplify view maintenance.
  • Creating an iPad specific app that can run on the Mac.
  • Find some way to incorporate reporting into an iOS app.

The development of the previous app led to the creation of the Utility Views framework. By way of proof of code sharing, this V2 app extended this framework to include a new control.

Also, for this development I also created a framework of Utility Classes to contain some of the classes that are pretty universal. In this case, a developer logging system.

Reporting proved to be a nightmare as I couldn't find any reporting libraries that gave me any kind of useful output. I'm sure there must be something out there, but I failed to find it. So, I was forced to write PDFTools to create my own PDF generation system.. It's not complicated to use and the results are acceptable. It probably needs a little more work, but that will evolve over time.

I had a spec, of sorts for this project. It's more of a simple list of requirements, but it gives some insight into what I was trying to achieve.

Below is what the regulation states for 'over 25kg' models but in reality most these fields won't be fill in for every flight. Smaller models also need to keep a log but would need just a subset of these fields so the same log would meet the requirements for all. In addition to below, every model pilot must now be registered with the CAA. So this would also need to appear somewhere.

The CAA have not specified what needs to be recorded and in what format, but CAP722 gives in Section B3.1.5 ‘Record keeping’ the requirements for operations in the Specific Category, the category under which all over 25kg model aircraft are operated.

Flight activities for each UAS should be recorded by the UAS operator within a logbook. The logbook may be generated in either electronic or paper formats.

  • If the paper format is used, it should contain, in a single volume, all the pages needed to log the holder’s flight time. When one volume is completed, a new one will be started based on the cumulative data from the previous one.
  • Records should be stored for 2 years in a manner that ensures their protection from unauthorised access, damage, alteration, and theft.

The following information must be recorded:

  • the identification of the UAS (manufacturer, model/variant, serial number);
  • the date, time, and location of the take-off and landing;
  • the duration of each flight;
  • the total number of flight hours/cycles;
  • the name of the remote pilot responsible for the flight;
  • the activity performed;
  • any significant incident or accident that occurred during the operation;
  • a completed pre-flight inspection;
  • any defects and rectifications;
  • any repairs and changes to the UAS configuration
What it looks like

And the end result is...

And this is what I have ended up with once so far. It is a work in progress so is not complete. I have medium sized plans for additions and have a list of rafactoring bugs to deal with. However, this will give you a view of where I am going.

The reporting side is handled by generating PDF files. I have three for this version of the App;

Source code

No secrets here

While this is a work in progress and the code hasn't really been reviewed and optimised, I figure there is no reason to share what I have written so far. I have plans for what I want to do with this app but no specific timescale for achieving them. If you have a play with the source code, please bear that in mind. You can find the source code in my Flight Log V2 repo.


Am I really any good?

Don't take my word for my abilities, take a look at other peoples opinions about me.