Though, in the meantime, 4.1 and 4.2 got taken care of and released into the wild. You can find 4.2 on your friendly neighborhood App Store. These are both incremental releases, but there is some good stuff in there like Dropbox support (finally) and multicopter model types.

The coding elves are busy working on putting in a few cool things for whatever comes after 4.2. Parallel charging/discharging support is wrapping up along with a few other goodies.

There is all kinds of goodies in 4.0.0, many thanks to the beta testers who did great work beating on the app.

Happy flying!

Then, I am not sure you heard this, but I guess Apple announced a new iPhone?

Along with the phone came new development tools which created a few other issues.

So, we are holding the release until next month. This will give us a chance to get it updated for iOS 6 as well as iPhone 5. Plan is to get the submission to the App Store elves at Apple right around the end of September which would put it in the store early October. This will add one more bullet to the feature list:

• Support for iOS 6 as well as the iPhone 5.

The only bad news out of this (well, other than the delay), is that RCL 4 will now require iOS 4.3 or greater. This means that 3.8.2 will be the last release than runs on the venerable iPhone 3G. Long story as to why this is so, but it is due to some changes in the development tools and a desire not to leave anyone with an iPhone 3G running a broken 4.0.0 release that we cannot release an update for.

We are still looking for a few good beta testers, so drop us an email if you are interested.

The feature list can be found after the jump…

There was a fair amount of work under the hood, but here is what is new in 3.7:

• New database elements for propellers. Models and events can now specify a propeller. The battery performance plots can filter on propellers now.
• New database elements for event “style”. Models and events can now specify a style. The battery performance plots can filter on styles now.
• Support for “retiring” a model or battery. This keeps the data in RCLogbook, but moves it to a separate page accessible from the main Model and Battery tab.
• Support for filtering individual cycles from the battery performance plots. This way, if you know a cycle is an outlier, you can exclude it from being included in the plots.
• Check list pages before and after events now have a “Check All” and “Uncheck All” button to streamline check lists.
• Check list notes fields are now exposed in the UI.
• When selecting batteries for an event, batteries are now sorted in order of least recently charged within a group of batteries with the same capacity, cells, etc.
• Directly entering an event has been streamlined by removing the “Date Select” page; this is now handled through the “Event Complete” page.
• New default added to set the duration of a directly-entered event to the duration of the model’s last event.
• New default added to set the charge amount of a charge cycle to the capacity of the battery.
• When the web server is running, the app will disable the device auto lock to avoid changing the port number.
• Battery performance pages now default to setting the slider to the time corresponding to 80% capacity.
• Fixed a number of visual issues and glitches under iOS 5.
• Fixed bug under iOS 5 that could cause the URL for the web server to incorrectly point to the IP of the cellular interface, not the WiFi interface.
• Fixed bug in battery performance plots that could cause a crash for particular small data sets.
• Fixed a bug in event location selection that could lead to a crash.
• Miscellaneous tweaks, updates, re-factoring, and stability improvements.

That about does it.

Onward!

So others can learn from what has, so far, not been one of the smoothest RCLogbook release cycles, here is what happened…

Back when 3.5.0 was being laid down, the feature set was a little more extensive. As a result, I decided that RCLogbook would require iOS 4 at minimum. As a result, there were a few places where I moved from some existing code that worked to new APIs introduced in iOS 4 that were more compact, easier to use, and so on.

As development wore on, some choices were made to drop some of the originally planned features in favor of getting 3.5 out faster. With the pull-in, it was also decided that I would not leave iOS 3 behind quite yet. So, I began to back out some of the iOS 4 specific changes (or, rather, appropriately guard them – originally I had not guarded them since, hey, the app was going to require iOS 4 at minimum so why do a “if iOS 4” song-and-dance).

You can see where this is going. Turns out, I did not get them all in 3.5.0. Turns out I also did not get them all in 3.5.1. While no bugs are ever OK, the transgression in 3.5.0 is a slightly more forgivable – I did get most of guards in place. The transgression in 3.5.1 is a matter of rushing the release out to help out the user base on iOS 3 (of which there are at least a handful of folks who have emailed me with tales of crashes) and not taking the time to make sure I really had all of the guards in place this time. It also did not help that I assumed the bug report was for the crash I was seeing locally (in this case, “add a flight” could mean either with or without the event timer). It turns out that there were three escapes that needed to be fixed and I assumed that the one I fixed was the one the user was seeing, which was not the case.

What I learned:

• Guard always if there is even a sliver of a chance that you might want to run on an OS that does not support the API.
• Always ask for clarification on bug reports to make sure you are fixing what is being reported, not a different bug.
• Stop, take time, and double-check.

Generally, before you update to a new version it is good practice to download the complete binary database from the current version. That way, you had a copy of your database in the unlikely event things come off the rails.