Archive for August, 2011

WebOS and Windows Phone 7 development – Part 2: Windows Phone 7

August 11, 2011 11:20 am

This is part two of a “miniseries” on my forays into mobile development. Part one is here.

3 WindowClipping

My interest in Windows Phone 7 development grew partly out of my experience with writing a simple app for WebOS and partly out of conversations with a friend at work who was really excited about what at the time was the “forthcoming” new mobile OS from Microsoft. I hadn’t paid much attention to Microsoft’s moves in the mobile space, since I’d always been a fan of Palm PDAs and didn’t own a cell phone for a really long time. I figured I was reachable either at my desk or at home most of the time, so why carry a phone and pay another monthly bill on top of all the other ones?

A long conversation on a BART ride got me curious, though, so I checked out the announcements and demos Microsoft gave at the Mobile World Congress 2010 in Barcelona. All I can say is – I was hooked. The user experience presented by Microsoft made sense to me, the user interface was clean, simple and fresh, and the development toolset / technology was something I was pretty familiar with (Silverlight being the close cousin to WPF, which I’ve worked with intensively over the last few years as part of creating the TouchSmart software UI framework.)

Since I had already gotten my feet wet writing a simple app for WebOS, I thought it would be fun to write the same app (more or less) for Windows Phone 7. I had to wait a while for the tools to come out, though, so I had some time to read and learn more in the meantime.

My friend at work heard about a group that was forming around some people from the Silicon Valley Bay.NET user group who wanted to study and learn Windows Phone 7 app development. He had already joined the group, which had its first meeting on June 15, and encouraged me to join as well, so I did, somewhere around late June 2010. The group was incredibly useful in pointing out resources, encouraging people to follow a sort of curriculum and generally keeping one’s spirit up. Not to mention getting to know the Windows Phone 7 developer evangelists in Silicon Valley, William Leong, Kenny Spade and Doris Chen. Without the group, I’m not sure I would have stuck with it.

When I started work on my app, I took advantage of what I had done on the WebOS predecessor. As it turned out, Microsoft’s phone app templates use a close cousin to the WebOS Model-View-Controller pattern that’s very familiar to WPF/Silverlight developers: Model-View-ViewModel. Transferring some of the business logic (the Controller) was relatively straightforward. But because of the differences between C# (the language initially supported by WP7) and JavaScript (the WebOS business logic language) I decided I could do better with my data model than I had done in JavaScript. Ah, the joys of a typed language with excellent tooling support (Visual Studio 2010 Express)! So I rewrote most of the business logic and added a proper unit testing project to my solution. Producing the user interface was an entirely different matter, of course. On WP7, the UI has to be built in either Silverlight or XNA Game Studio. I went with Silverlight, since I already know WPF quite well.

Unfortunately, the version of Silverlight on the phone (version 3, “plus”) leaves out lots of good stuff from WPF, so I couldn’t do some things that I would have liked to do. One thing that I had come to appreciate in particular from WebOS were “editable” text blocks, where the normal mode of operation is that the text is simply displayed without any adornments, but when you tap on the text, it turns into an edit box, where you can change the content. I liked this control so much, I just had to write my own version of it. The Silverlight limitations on WP7 (I can’t remember at this late stage if it was lack of style inheritance or something else) made the result not quite as elegant as it would have been with WPF, but it ended up working well enough. Mobile apps are all about removing clutter and unnecessary steps, so eliminating the need for an edit screen seems to be a good choice, even if the control that enables this isn’t a “standard” control everyone knows about.

On the WebOS app, I didn’t have to worry too much about application lifetime management, in other words I didn’t have to write much code to save and restore the state of the app. WebOS provides multitasking abilities for apps; Windows Phone 7 on the other hand only provides for a single app to run at a time (at least Silverlight apps, “native” apps have more advanced capabilities, including the ability to do things in the “background”, but non-OEM developers can’t currently write “native” apps [Microsoft will remedy some of this with the now final “Mango” update]). Writing the required “tombstoning” code was some extra work, but Microsoft had provided good sample code at a free developer event that I attended. Part of that sample code also included methods that make it easy to work with “isolated storage”, which is what used for storing an app’s data. Thankfully, I didn’t have to resort to using typeless JavaScript objects, but could use fully typed first-class objects with methods and persist them in isolated storage without having to write my own translation code like I had to with WebOS.

After I had made good progress bringing the Open app to the same level of functionality that my WebOS app had, I noticed that there was a Bing Maps control available from Microsoft, and thought it would be interesting to see what I could do with that. The Open app allows the user to enter a store address. Wouldn’t it be nice if the app could draw you a map to the store, and based on the route’s duration tell you if you can get to the store in time before closing or if the store will be open by the time you get there? Certainly! It was surprisingly easy to use the Bing Map control (except for one thing that I’ve blogged about before), and I had the new feature implemented in a matter of hours. I think what took longest was to get my API key to actually be approved/deployed by Microsoft.

After testing the finished app and checking it against Microsoft’s publishing guidelines, I proceeded to the Windows Phone 7 Marketplace (now called AppHub) to start the publishing process. Because of my involvement with the peer learning group hosted at Microsoft, I had gained access to the second wave of “early access” certification for Windows Phone developers. This meant that I was able to work through the submission process before it was open to the public. I had a few hiccups getting that far, eventually got approval to start submitting my app for certification.

Publishing an app is probably about the same amount of work for both WebOS and Windows Phone. I get the impression that Microsoft’s testers are quite thorough, at least they were when I went through the process. They’re also pretty fast. After preparing all the required materials (several app icons, background image for the Phone Marketplace, marketing text, etc.) and submitting the app, it took about 3 days to get it approved, if I remember correctly. According to my xap file timestamp, I produced the 1.0 version on October 18, 2010 and it was released on October 21, 2010. The awesome folks at (thanks Luigi!) helped me track down that it was among the first 2000 apps submitted, at #1983 or so. [Incidentally, I published a second app, called Countdown, which also took 3 days to get approved (submitted on December 26, 2010 and published on December 29, 2010; it was #5123 in the Marketplace).] When I updated one of my apps to version 1.1, I got a failure report back (I hadn’t tested tombstoning well enough) and was impressed by the quality of the report. It really helped me find and reproduce the issue quickly.

I have not had time to update either of my apps any further since publishing version 1.1, but perhaps some of the new features in “Mango” will encourage me to do so. A live tile for the Countdown app has been requested in the reviews of the app, for example, and producing that functionality without Mango would require me to create and host a web service, not something I’m willing to pay for at the moment. With Mango, the app itself will be able to update its tile…

Speaking of payment, you may wonder if this venture has been worth it from a monetary perspective. I would say “not quite”, but since I haven’t spent anything on promoting my apps I don’t know if it could have gone better. Open is $1.99 and Countdown is free. Open has a trial version, which is ad supported and Countdown is free with ads. I’ve sold 5 copies (at this point) of Open and made perhaps fifteen dollars in ad revenue from both apps (so no payouts on either front yet). I was lucky enough to get my $99 Marketplace fee refunded due to publishing two apps by a certain deadline for a Microsoft promotion. But figure in the time I spent on creating the apps, and this definitely has been an exercise more for the sake of learning and personal enjoyment than for the sake of financial gain.

Finally, since this is part two of a series on mobile development, I need to comment a little on the two experiences of doing WebOS versus Windows Phone. To me, the phone/OS experiences on the two come pretty close. WebOS is similar to the HP TouchSmart 2.x/3.x concept of an app carousel and works beautifully. I like WebOS a lot from a user perspective (I just REALLY wish there was a WebOS phone model closer in size to the iPhone or my current LG Quantum or the Samsung Focus), but developing for WebOS is hampered (for me at least) by the relative lack of good development tools. Windows Phone provides a unique user experience, hampered a little by the lack of multitasking, but absolutely SHINES in the area of development tools. Microsoft also invests a LOT into the developer ecosystem, as evidenced by the evangelists participating (on their own time, no less) in peer learning groups, such as the one I participated in. They use this as a vehicle to give people early access to phone hardware for testing and to keep the energy and motivation up among developers. I’ve not been aware of such support existing for WebOS.

WebOS and Windows Phone 7 development – Part 1: WebOS

August 10, 2011 11:20 am

This is the first of a two part “miniseries” of my forays into developing for mobile platforms. Part two is here.


After Phil McKinney announced a WebOS app development contest at HP’s internal technology conference, Tech Con ’10, I was somewhat drawn to trying my hands at this unknown “beast” (lure of the prize? Maybe.) In a conversation with Jon Rubinstein on the first evening of Tech Con I had mentioned how Microsoft’s tools provide incredible developer productivity and I asked if Palm’s toolset provides something similar. Jon mentioned project Ares and encouraged me to try it out. More on that later.

Over lunch that last day of Tech Con, I mentioned in a conversation with my colleagues that I was going to develop an app that helps you keep track of store opening hours. After lunch I had a little bit of time before my flight back to California, so I rudely ignored my fellow travelers and started downloading and installing the “regular” Palm WebOS tools: Java, VirtualBox, Eclipse, the SDK toolset, Google Chrome and the Aptana Studio plugin for Eclipse. I didn’t start writing code right away. I had just finished installing stuff when it was time to get on the shuttle for the airport.

My next steps were to read up on the overview documentation that Palm provides at and to start running the emulator and toolset. I’m no stranger to (D)HTML/CSS and JavaScript. One of my first projects at HP was developed almost entirely using that combination. Admittedly, that was quite some years ago. I’m a little surprised that someone would build a mobile platform based on technology that old, but I guess the rationale is sound: anyone who can develop a webpage can now develop mobile apps. (I’m not entirely sure I’d want just anyone who theoretically can do it to actually do it. Sorry. Little digression.) So, I’m no stranger to the technology, but I still needed to brush up. So I went off to to check out the JavaScript references (in particular the Date class docs) etc. Part of the journey also took me to a few articles at Linux Magazine (WebOS is based on Linux – another decades old technology stack, hmmmm – but then, so is the Windows Kernel and a bunch of other pieces of software) where some of the details around data persistence were explored. I knew that I’d have to store the data locally, since I couldn’t possibly support running a web/cloud service anywhere. Some other detours led me to the JSON website and the Prototype framework.

My first tentative steps were to get the app from the Linux Magazine articles up and running, which didn’t take too long. Then came experimenting with my “business logic”. Palm apps are nicely partitioned according to the Model – View – Controller software pattern, so trying out some “Model” approaches was worthwhile. During all this, I kept bouncing back and forth between the Linux Mag articles, the SDK documentation, Palm’s developer forums and the JavaScript documentation at w3schools.

After working with the TimePicker widget for a bit (store opening hours are central to the app, after all), I settled on using Date as the main “Model” for the app. Unfortunately JavaScript can’t store Date in the local persistence layer of WebOS. What can be persisted are object primitives (strings, integers, lists, arrays and such), and Date is not one of those. The persistence format in WebOS is JSON (JavaScript Object Notation), which is a string representation of a JavaScript object that the JavaScript interpreter can “rehydrate” by calling “eval()” on the string that’s retrieved from storage (or a web service call). Date objects don’t persist well, so I had to work out a way to “dehydrate” and “rehydrate” my Date-based data model. I’m sure there are better ways to do it than what I came up with, but my method is basically to “dehydrate” by calling Date.getTime() and storing that away. “Rehydration” is the reverse: construct a Date object from the stored getTime() value (which is the number of milliseconds since the “epoch”, Midnight on January 1, 1970).

After settling on the data model, I started some work on the business logic. I figured out the rules for determining a single day’s open/closed status and did debugging on that. This is where one of my frustrations with the toolset started to surface. Debugging is pretty painful on WebOS at first. It seemed that all I had at my disposal were “tracing” statements in combination with looking at log files in the emulator. To do that, I had to connect to the emulator running the app by using Putty (an SSH client that’s included in the toolset) to localhost port 5522. And every time I made a code change, I had to re-deploy the app, etc. It wasn’t until the end of my project that I discovered the semi-standalone log viewer from palm, hosted at and the corresponding debugger at The unfortunate thing, of course, is that these two only work if you have a live Internet connection. The other unfortunate thing is that my data model is an object that none of the tools know how to “Visualize”. By that I mean that even though AresDebug can show me my Date object, it can’t show me the various interesting “parts” like the Date, Month, Year or Day.

After making progress on the logic for one day of opening hours, I worked my way toward the logic for a whole week of opening hours. This meant starting to work with arrays of objects and that made the debugging situation worse. Now I had to trace a set of Date objects seven times in order to make headway. Seeing the log output from that was really messy.

In parallel to the business logic work, I started sketching out the UI flow and settled on four scenes/cards to use in creation/editing of store opening hour information. Most of these scenes were easy enough to come up with. The main problem was aligning items in list widgets so their placement was “pleasing to the eye”. That sometimes required padding and using tables in the HTML code along with general CSS tinkering. While using <div> elements with certain palm CSS class styles (“palm-group” in particular), I discovered that using a self-closing <div /> element could create issues with rendering the UI properly. I had to use opening <div> and closing </div> elements to get the correct rendering. Another thing I found a bit maddening was that I had to resort to padding in list rows to get items centered vertically. The style inheritance tree was just too much for me to wade through. I tried a couple of times, using the Palm Inspector, but it didn’t get me very far.

After most of the UI was settled, I had to finalize the business logic. This took the bulk of my development time, and was quite frustrating because of the difficulties of debugging/tracing/seeing traces using the Palm log tool via SSH. I ended up spending all of Memorial Day weekend on this (except for a few hours on Sunday where I got away to spend some quality time at a pool party). Memorial Day was another full working day where I thought I had finalized all the business logic…

Alas, I discovered in preparing my app for submission to the Palm site that there were still bugs lurking and that I needed to tinker a bit more with the UI. So I added a few images, twiddled icon sizes around, wrote up the required “marketing” text, etc. Each morning and evening I tested the app only to conclude that there were still calculation bugs.

Finally I convinced myself that it was time to formalize my testing efforts, so I put together a table on paper, sketching out various valid and invalid/tricky test data scenarios. I then coded these up in some “unit tests” (really just part of the app’s logic, but the tests only run if a certain flag is set in the startup code).

Other finishing touches included making the store opening hours definition less repetitive/labor intensive, adding a splash of color here and there, making it possible to delete the entire database and enabling two buttons in the UI based on conditions related to the store data the user enters: If a phone number is entered, enable calling up the dialer app to make a quick call to the store – if an address is entered, enable a button to take the user to a map of the store using the built-in mapping app. And with all those things in place, I finally submitted the app to the Palm catalog on June 4, 2010.

You’ll notice that I didn’t mention the Ares development tool yet. That’s because I didn’t use it much. Once I started on the path of using the SDK tools, I was unable to “round-trip” the app between Ares and the SDK toolset. I could upload the app just fine, but the App UI didn’t show up in the Ares environment. So perhaps I should have started out using Ares, but then I would have been limited to developing only while having a live Internet connection. Not something I find very comforting.

How much time did I spend on this adventure? Since I didn’t keep a log, I can only make rough estimates, but here’s the breakdown from memory:

Reading SDK docs
2 – 4 hours

Download and install tools
2 hours

Reading other articles
1 – 2 hours

Reading JavaScript docs
4 – 6 hours

6 – 8 hours

30 – 40 hours

Refining UI, testing
8 hours

Preparing for submission
2 – 4 hours

So that’s somewhere between 55 and 74 hours. A lot of effort for a simple app? Probably. Worth the time, considering the value of the prize? Perhaps not. Great value in learning the ins and outs of a new platform and having some serious geek fun? Absolutely!!!

Why the big number on Debugging? This is where I get back to the productivity question/issue I posed to Jon Rubinstein. Debugging was so painful and time-intensive because the tools just didn’t provide what I needed. What I would have wanted was an environment that provides a coding and debugging experience that helps track down bugs in a matter of minutes. Variables should be easily inspected, breakpoints set / made conditional, etc. etc. The Palm Ares debugger provides some of this, but there is still lots of room for improvement.

All in all, it was great fun writing a WebOS app and learning about the platform. I highly recommend you do it yourself, if you are so inclined.