When viewing EU airports in metric mode FlightWatch suffered from slight rounding error. The root of the problem was that when NOAA was fetching data for those stations, they converted the presented measurements into US standard units. As FlightWatch only had the NOAA data stream to work with, it was forced to convert them back into metric. Both of these conversions involved some rounding, so you would get odd results. An example of this is demonstrated by the metar below.
EHWO 121755Z AUTO 22009KT 2700 -RA OVC002 09/09 Q1009 AMB
The visibility and altimeter presented were 2700 meters and 1009 mb, but FlightWatch reported 2003.7, and 1008.93. FlightWatch 1.4.1 directly parses out metric visibility and millibars from the raw text, and if you’re viewing in metric mode suffers from no conversions.
Metric unit support is here! Yay!
FlightWatch’s flight category colour scheme was a source of confusion as it did not align to any aviation body’s scheme. It now will correspond to the colour scheme used on NOAA’s aviationweather.gov, which will hopefully eliminate some confusion. Also, the battery use of 1.4.0 should be significantly lower than the 1.3 series.
Now on to future development: Trends are in prototype stage, but are very slow to render. For 1.5.x I can either integrate basic TAF support, or complete Trends. If you’ve an opinion drop me an email or comment in the market, and I’ll take it into account.
I’ve been vacationing in Northern MN for the last two weeks, and for the first time in a long while my phone has been away from a charger for extended periods. This enabled me to get more accurate battery use information, and I have learned that FlightWatch consumes far more battery than it should. The primary culprit is that FlightWatch is greedy with GPS updates, and hence doesn’t allow the phone to sleep the GPS radio often enough. The problem has been fixed and is slated for the next release of FlightWatch.
Which leads me to the dev plan modifications mentioned in the title. Metric support is feature complete and will enter testing soon. Weather trend graphs are, however, only in the prototype stage. Given the multiple requests for Metric support, and the above battery use bug, I have decided to push Trends out, and release FlightWatch 1.4.0 sans Trends, but much, much earlier.
Now on to the free version. FlightWatchLite 1.3.9 appeared to solve the main cause of crashes in sending notifications, but exposed another set of problems, which fortunately occurred only when FlightWatchLite was offscreen. FlightWatchLite 1.3.10 fixes this, and contains the GPS battery use patch. It has been released to the app store.
It turns out that if you mark a bug as old in the market, that you don’t see it on the main page even if it still occurs. There’s an odd case where the service responsible for sending notifications is failing to start, hence the application crashes. It appears this is caused by the system sending a blank intent to the service, which is causing a null pointer exception. I’ve added a bunch of guards to the code which should stop crashes, and am currently testing the logic. If you are running FlightWatchLite, and it’s crashing, please send me an email with your handset model, and I’ll see if I can figure this one out.
Looking at the order history it appears a good portion of FlightWatch users reside outside of the United States. Additionally, my very first feedback on FW requested non-U.S. measurements be made available. Accordingly, along with trends the next FW version will have metric unit support! Also, if anyone out there has spare time, and wants FlightWatch in their language, I’d be more than happy to send you the strings to be translated.
One of the biggest pains in developing the latest FW and FWL releases was getting toasts to display properly. I could get them on the screen fine, but when started from my notification service they would never go away. In previous releases I punted and did some dirty hacks to get around the problem, but after much trolling of newsgroups and piecing together random bits of info I finally figured it out. Do NOT send a toast from an intent service. An intent service will launch it’s own thread, do it’s work and it and its thread go away. Apparently, if android can’t find the component (or thread, I haven’t figured that one out) that displayed your toast, it doesn’t know how to hide it. Hence it stays on the screen until you reboot.
One of the interesting things about writing software is how many times real world experience proves you dead wrong. I have long held the opinion that if your application requires and Internet connection, and making connection attempts costs the user, e.g. battery power, then it’s better for your application to crash when one isn’t available than to attempt reconnects. This, it turns out, results in really, really bad user experiences. Accordingly, FlightWatch 1.3.2 and FlightWatch Lite 1.3.7 now throw toasts or notifications on the screen, and otherwise complain loudly when a connection fails, but do not crash. Additionally FlightWatch Lite1.3.7 contains fixes for a few bugs found while developing the last release of the paid version.
Now on to the future. I mostly consider FlightWatch Lite feature complete. In the near future it will get the Metar Decoder, and may get TAF support, However it was intended as a demo, and as an app that would serve those who do not have advanced WX reporting needs. Additionally, there aren’t that many interesting features left that don’t require me to maintain some infrastructure server side, or that don’t take more work than I’m willing to give out for free.
FlightWatch however, is going to be getting some really cool features. Trend reporting will be in the next feature release. In the mid term, I have access to the AF/D information in machine parsable form, hence I will be able to present runway and X-wind component information. TAFs and SIGMETs are available, and as soon as I find a UI I like they will be made available. Slightly more long term is Route Plans and WX reports along that route, as well as integration with NOTAMs (either natively or via another app). All in all, it looks to be a really fun time to be an aviation app developer
This is a maintenance release which fixes several bugs in metar decoding when ADDS does not return complete information for the station. FlightWatch will now present empty fields if the data for that field is unavailable.
FlightWatch 1.3 adds a feature that many users had been asking for, namely METAR decoding. The raw metar text is a fast, highly efficient representation of WX for those who know how to read it. As FlightWatch is geared to that audience, decoding is not enabled by default, but can be turned on in the preferences screen. Far fewer METARs will fit on the screen, however, and the application will run a little slower as the complexity of rendering is much higher.
Feedback I received, indicated that having both the “Stations Near Me” and “Local Weather” features were redundant. In the interests of reducing application complexity, “Stations Near Me” has been removed in 1.3.
Feedback also indicated it would be useful to see weather near stations in the METAR list, and that feature has been added. The context menu for a metar now has “View weather near this station” which requests the Local Weather as if you are at the selected station. It does not, auto-update like the normal Local Weather screen, however.
Lastly, it is now possible to specify your Local Weather search radius on the preferences screen.
Minor bug fixes and code unification, along with an EULA.