Posts tagged ‘Mobile Computing’

It’s not an iPhone. It’s a µMac !

A web forum member asked about “racetracks in the sky” – referring to flight tracks that are depicted in three dimensions. I've had APRS in my airplane since the very first flight.

I answered the forum question but then decided to create a little video to demonstrate how I get those rolercoaster pictures.

Here is why I consider an iPhone to be a more of a computer than a phone.

I fired up DisplayRecorder on the iPhone to record a demonstration video. I started by opening Mobile Safari on the iPhone. I then visited mail2600.com which processes and maintains aircraft APRS data. I showed a map view of a flight. I then clicked on the “Google Earth” link and the website downloaded a KML file. Safari automatically offered to launch the mobile Google Earth app. I then did a little navigating – pan, zoom, and rotate. Finally, I stopped the recording.

I had DisplayRecorder save the video to my camera roll. I then launched Mobile iMovie where I cut out a few mistakes I had made, added some captions and a few fade effects. I had a 1 minute and 15 second video.

Next, I launched Mobile GarageBand, picked a tempo and then did some quick math to determine how many bars of 4/4 music I needed to make 1 minute an 15 seconds. I grabbed a couple loops of Latin rhythm and sequenced an electric keyboard track. I finished by having GarageBand transfer the new music back to iMovie.

iMovie combined the music and the edited video and exported it directly to Vimeo. Vimeo transcoded it and sent me a notification.

I launched Mobile Vimeo and grabbed the web markup from its “share” feature.

I finished by launching WordPress for iOS, pasted in the Vimeo markup and authored this blog post.

At no time did I turn my office computers on. They entire process was complete on my iPhone.

 

Apple’s narrow view – breaks the web

If this were baseball, the umpire would be calling “STRIKE 2″ !

A little while ago, a developer was telling me that HTML5 and its localStorage spec was no guarantee that a web app's data would be their when needed. I thought he was spreading a conspiracy theory. Turns out he was right.

Apple chose to implement its Mobile Safari and WebKit API using a lawyer's interpretation of the spec. Where as other browser providers have implemented the “spirit of the law”, Apple chose the “letter of the law”.

User agents must have a set of local storage areas, one for each origin.

User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.

Because the W3C draft specification says “should” rather than “shall”, Apple is within its rights to purge local storage when it chooses and without end user content.

This decision by Apple means a developer can not guarantee to be able to implement a mobile web application that will run off-line. For most developers and their end users, this is an inconvenience and will result in (a) some extra code, (b) the need to always store local data back to a server, and (c) the occasional hit when everything needs to b reloaded because Apple threw stuff away.

Well, that was bad. Now comes Apple's latest “holier than thou” decision. Apple has chosen to interpret the HTTP caching rules different from other browser providers (or Apple just got stupid and introduced a bug).

Responses to this [POST] method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.

Apple's interpretation is to cache if not explicitly told NOT TO. So, whereas other browser providers check to see if an application has requested caching, Apple Mobile Safari checks to see if an application has requested not to cache.

Once again Apple's interpretation of the specifications is unique to say the least. It breaks developer's code and long held practice but hey, they're Apple. They can do anything.

 

The all new “Aircraft Weight and Balance” Web Application

 

The aircraft Weight & Balance App for smartphones is done. It’s been done for about a week but needed to do some usability testing and then create the video tutorial. I’ve had other hints on my mind so is had to wait. The wait is over.

The mobile web app is really just a specialized calculator so there is no reason it needs an Internet connection. Thus, even though the app is written with HTML, CSS, and JavaScript, it works in airplane mode on iPhones and iPod Touches (and probably android devices but I don’t have any for testing).

A few changes from the first release …

  • Helper feature to remind new users to add the app to their home screen
  • Dynamic UI to support a wider range of aircraft configurations from single seat to four occupants and up to three baggage areas.
  • CG results are displayed graphically as well as numerically.
  • Warning messages for missing configuration, over gross, and out of CG
  • This version of the app uses the jqMobi framework in place of jqTouch

You can install the application at: 53VG.com/wb. I hope pilots find the app useful. Leave feedback if there are features you’d like to see in the next release!

 

Addendum: a post to an aviation related forum reminded me of a small assumption I made in the app. While the data entry of the settings and the flight data are all meant to work with either English or metric units, the fuel load is in US Gallons and converts to US pounds during the calculation. Thus, the app does not really support metric. Sorry about that.

I probably won’t use jqMobi next time

Almost a year ago I wrote a mobile web application for my iPhone. It was a simple aircraft weight-and-balance calculator. The nice part was it would work without an Internet connection and it remembered all the settings from the last time it was used.

I wrote it for my airplane. It worked for any pilots long as they were flying an RV-8.

Over the past week of evenings, I rewrote the application to support a wide range of airplanes. I also took the opportunity to try a new mobile web application framework – jqMobi

The author(s) of jqMobi claim they have built a leaner faster replacement for the widely used jQuery Mobile. I'm not sure they hit their mark.

My gut tells me they have good intentions but insufficient resources to get the job done. I know jQuery is getting fat and slow on older iOS devices. JqMobi is smaller but for my project, it was still slow on older hardware. More worrisome is that is it very unpredictable and buggy. Something as simple as running their own “kitchensink” test application and switching themes (a part of their test) shows spacing and layout bugs. Worse still, they have made code paths that are totally unpredictable for tough events and form input. The lack of documentation and examples means you are debugging their code more often than your own.

Update 1: I was able to change my application's CSS and HTML to behave with the jqMobi parsing of the input fields withing the fieldset. The original markup worked fine for jqTouch and Dojo.

A google search shown low adoption for jqMobi and a fair amount of friction between jqMobi and the jQuery Mobile team. My guess is jqMobi was built by a team for their own use and the public release is secondary.

Update 2: The lack of online public usage and commentary means that most searches for “jqMobi” and a “question” will show jQuery results. There may be adoption going on but it is not public.

What does all of this mean ?

Simple – I don't trust jqMobi to get better and I don't trust it to be around and supported a year from now. There's no good reason to risk it.

Sadly, I have finished the weight-and-balance re-write using jqMobi. I finally have everything working. It took about 30 hours. But, I'm not going to release it. Instead, I will rip out jqMobi and re-write everything to either Dojox Mobile or jQuery Mobile.

Update 3: I did e re-write using Dojo. It was pretty quick. I attribute mush of that to the fact I've re-written the application three times now and the CSS, HTML, and JavaScript is very modular now. The Dojo documentation is also extensive. The Dojo implementation was the fastest of all the different frameworks – even on my old 1st generation iPod Touch. Sadly, I could not find a single working example of Dojo in full off-line mode. I posted to internal and external sites but no success. The off-line requirement was the show-stopper. Since I had the jqMobi version working, and I needed to release the update, I went ahead and cleaned up the final code and posted the app.

Chalk this one up to a “character building exercise” :-(

 

A developer in designer’s clothing

When working as a user interface designer – especially when focused on mobile computing – I find that a lot of my software developer methods take over. Whereas most of my peers are fluent in Photoshop, I use tools like GIMP and ImageMagick as well as programming languages and tools.

A recent example is my need for lots of similar graphics resources.

When building web applications for Apple devices like the iPhone and iPad, there are a dozen or more different sizes and shapes needed. In many cases, the graphic content is the same but it must be scaled and cropped. The square icon needs three sizes to accommodate the two different iPhone resolutions and the iPad. The launch screen has four sizes – two for the iPhones and one each for the iPad in landscape and portrait. There are even different icon sizes needed for the settings page when develop native apps.

Rather an create each image, I create one master image at a large “pre-determine” size. From that one image, I have scripted the generation of all the other graphics. The script even creates the iOS styled rounded corner icons with the glossy effect.

The script does not yet create some of the Android OS specific graphics but most will be easy to add.

If you are interested in the script or to look at the results, visit http://communicat.us/auto-graphics for an example.