Flying? Don’t forget your apps !!

Learnt a little lesson off late; that is what this post will be about. I have been working on big Windows Phone 7 app (actually the soon to be available Sogeti Hub) along with a couple of buddies. We were code complete and testing edge cases while having the app deployed on my HTC HD7. Then, on a recent flight to Florida, I just felt like running the app with no data access. Ooopsie .. nasty crashes everywhere!

Well, you need not always have to buy plane tickets in order to test your apps; the point is all mobile apps need to be well tested for gracious failures in “Airplane Mode”. I think we developers have gotten a little spoilt with increased computing power & high speed data connectivity. Mobile solutions, kind of, bring us down to the details again where we need to worry about lean performance & not assume ubiquitous data connectivity/location services. A well designed mobile app could have a lot of cloud support; but has to account for unavailability of resources and be mindful of user experience.

All that said, here are some details on where I had gone wrong. This is WP7 & Silverlight stuff, but should apply to corresponding things in other platforms. There were multiple instances where I was consuming RESTful API and in .NET, my favorite & possibly easiest way to go across asking for data is the “WebClient” class. Since Silverlight does not allow UI thread blocking, most web requests take this form:

WebClient objName = new WebClient();
objName.DownloadStringCompleted += new DownloadStringCompletedEventHandler(EventHandlerName);
objName.DownloadStringAsync(someDestinationURI);

 

Essentially, the idea is to wire up an event handler, fire off a call & expect the event handler to execute when we have a response. Now, my event handler was conservative & checked for any error first up, like this:


private void EventHandlerName (object sender, DownloadStringCompletedEventArgs e)
 {
 if (e.Error != null)
 {
 // Do some error handling here.
 }
 else
 {
 // Move on happily with life.
 }
}

 

Now, here is the BIG DIFFERENCE. While testing in the emulator, I had shut off all connectivity on my laptop. Interestingly, the event handler always fired & we caught the error in the handler. While the app is running on phone in “Airplane Mode”, we never get to the event handler !! I am guessing this is because of how the “WebClient” class behaves; possible bug may be?

The safer solution is the enclose the “WebClient” call within a “Try-Catch” block and do immediate error handling if the “WebClient” class fails to make any progress. I would love to find out what unhandled exception was being thrown, and wish there was a way of debugging an app while it was using the data connections on the phone. Open question for me is how the “WebClient” class treats a phone in “Airplane Mode” differently as compared to a computer with no connectivity.

If anyone has the answer or had similar experiences, please drop a comment. Hope this was helpful.

Adios!

Mobility @ Sogeti Microsoft Bootcamp

Back in mid-Feb, I was really happy to drive down to Dayton’s Wright State University where Sogeti was hosting a Microsoft Bootcamp for new hires in the company. I was asked to speak about Windows Phone 7 & Mobility in general. It was great !! It is so much fun speaking of Mobile solutions to fresh minds. And the audience was awesome. If these folks are the future of Sogeti, we are in good hands! So, thank you to all who attended.

If you guys are interested in the slides or any links that you found interesting, the whole slide deck may be found at the location below. Please note this is an internal Sogeti site & the slides are proprietary. Please use your credentials to pull down the presentation deck from here:

https://connex.sogeti.com/Practices/mtg/ems/Shared%20Documents/Training/MSFT%20Bootcamp%20Mobility.ppt

Also, we talked about a few alternative Mobile development approaches. Some interesting links would be as follows:

Hope all you guys take great interest in Mobile solutions and take us to the next level.

Adios!

PS: The slide deck has been updated after our June Bootcamp.

Flick is the new Scroll !

It has been a full week now since I started using my Microsoft Arc Touch mouse; about time to write a quick gadget review! This mouse came out of the usual plethora of MSFT design experiments around mice; but looks like nothing else out there & had my attention from the time it was announced. So, pre-order followed and the mouse was delivered right ­in time for the holidays. So, here’s what worked & what didn’t:

Pros:

· The mouse came packed in a shiny unbelievably-thin box.

· Very thin contour for the mouse. About 1-1.5 inches thick & tapering. Let’s just say FLAT.

· Great for travel; super light.

· Super cool that the mouse curls up to the palm’s contour, and that is what turns on the mouse, saving battery otherwise.

· Left & Right clicks work smoothly.

· Tactile feedback on flicks is very nice. So, is inertia on scroll.

· Customizable touch sensitivity makes it easy to make the mouse work to your needs.

· Tapping works nicely for page-up, page-down & middle-click.

· BlueTrack technology makes for very precise pointing.

· Great on long web pages or my methods with 2000 lines of code ..ha ha.

 

Cons:

· Does not seem to move very well on uneven surfaces because of its shape.

· Left & Right clickable areas may seem a little too widely spaced when compared to few other mice in the market.

· The contour will keep palms well stretched. This may not be a bad thing after all; but takes a little getting used to.

· Rear edge is a bit of dust/lint magnet.

 

A more detailed review can be found here:

http://www.crunchgear.com/2010/09/10/review-microsoft-arc-touch-mouse/

In all, small & nifty, with lot of attention to design; but also works as intended.

Enjoy!