As the Pay It Square Android app continues to gain in popularity I have decided to turn my attention to the other platform I am working to develop my knowledge for: Windows Phone 7. As a .NET programmer I have longed for the ability to use C# and the other features of .NET to create mobile apps, WP7 gives me that chance. I have had a chance to play with the platform in the past and even created a couple simple apps. However, I decided it was time to do something serious and so I started my journey to making the Windows Phone 7 version.
This will be the first part in a series of posts detailing my experiences and thoughts on the platform at different stages.
Planning
I started off by planning the data architecture for my application. I am a big believer in using Dependency Injection and Reflection to handle common tasks. Very often with such systems you have to transmit data over the wire in a string based format (JSON, XML). I understand where the rules of not using reflection in mobile systems comes from, I just think when platforms require a Duel Core chip, you can start to throw those sort of rules out the window.
I decided for my design, I wanted to try for a Repository pattern fronted by a Service based middle tier. Basically, my pages would talk through services to repositories which would handle the communication to the web service in either XML or JSON format.
So right at the start, I hit a bump. Whether its due to lack of maturity or just uncertainties about the platform, no one has really come up with a good way to fully integrate DI into the WP7 development experience, and least nothing compared to Guice on Android. I looked at things like Funq and Caliburn.Micro, all of which seem incomplete to me or require more moving parts then I want to maintain.
In the end, I settled for straight Ninject and went about figuring out a way I could integrate this in myself using their WP7 bits. After not finding a pattern I was in love with I decided to work on the UI instead while I pondered good implementation patterns.
The UI
In my opinion, one of WP7 strengths is XAML and the level of customization that you can achieve by defining your own templates, this is made even easier with Blend. However, to say this is easy is a bit of a misnomer in my book. Perhaps it is because I am so used to DrawableXML in Android and the simplistic nature to quickly apply common design idioms to controls that I feel like WP7 gives you almost too much. Lets face it, to really make XAML work well, you have to be a decent designer as well.
But I decided to dive in anyway. The thing about WP7 is they do offer you default styles and therefore the ability to automatically get a good look and feel. While this works well for simple apps, step into a more complicated app with a specialized color scheme, such is the case with Pay It Square. Besides, good learning experience.
Conclusion
My final resolve was to skip out on data architecture planning and head straight to UI design with a basic concept of what I wanted. The idea here is to establish application flow first, something that I consider very difficult in Windows Phone 7 due to the “difference” in the way the frames are handled.
I find that Microsoft has elected to, not surprisingly, stick with many of the idioms that they perfected from the web. Thus thinking about each screen as a “page” rather then a “screen” makes more sense. The only challenge with this is managing the back stack, since you can no longer mark a screen as finished (as in Android) and have it removed from the stack. All you can rely on is catching an invalid flow movement and redirecting, much like with the back button in web applications.
One has to wonder if this resemblance to the web is intentional and thus represents Microsoft’s fence position between mobile web and native mobile. Only time will tell. For now I am moving through the process of creating the various templates that will comprise my interface.