Developing WordPress for Windows Phone

As a supporter of both WordPress and the Windows Phone platform, I was of course drawn to the WordPress for Windows Phone app. Since getting involved in the app’s development in May, I’ve explored the codebase and done plenty of brainstorming about the app’s future. What follows is a brief history of the app and initial thoughts on what it’s like working on its development.

Background

The WordPress mobile apps are primarily developed and maintained by the Mobile team at Automattic, although all of the apps are themselves open source. At present, there are three developers and one designer on the Mobile team, and they try to spread their efforts among the six mobile apps.

Each app has its own P2 development blog and Trac instance, and anyone from the general population can contribute patches and file tickets. In practice, however, it appears that the vast majority of the work is done by the Automattic employees.

I wish more people would contribute to these projects, as they are a great opportunity to get involved in open source on a smaller scale, since these apps are much less complex than WordPress itself.

WP7 App Beginnings

Windows Phone 7, which was a reset of Microsoft’s mobile strategy, launched worldwide in October/November of 2010. In December 2010, the WordPress for Windows Phone app was first released. Version 1.1, which fixed a set of important bugs, was released shortly thereafter.

The app was a “partnership between iSoftStone, Microsoft and [Automattic]”. As far as I can tell (as an outsider), the app was primarily developed by iSoftStone, a Chinese outsourcing company. The app was a port of the WordPress app for Android, with a light UI skin to match the WP7 “Metro” design style, including the popular panorama control.

Once the app was “complete” and iSoftStone had delivered the code, their involvement was essentially done. From there, the Automattic team filed tickets for several bugs, but never really moved forward on v1.2.

Version 1.2

Around mid-May 2011, on the eve of purchasing a WP7 device for my personal use, I decided to see how I could help out. As a developer with a fair amount of C# experience who was going to be using a WP7 device as my primary phone, I thought I was well-positioned to lend some support to the app development.

It appeared that the app had been abandoned, though I was told that it was just on hiatus until some process issues were worked out. So I started playing with the app and discovered a number of annoying bugs, some of which didn’t have tickets yet.

The app had not been updated since the v1.1 release in December, and since then a WP7 OS update (NoDo) had come out with copy/paste support and some performance improvements, neither of which the app properly supported. So I worked on some patches to solve those shortcomings and put them up on the trac.

Soon after, the Automattic team started contributing too and the commits started flowing. The iSoftStone dev fixed his final outstanding bugs, and I contributed patches where I could to help the Automattic team take care of the rest.

Version 1.2 was finally released at the beginning of August, see the release post for details on the features added. At this time, I was given commit access, and thus officially joined the dev team.

Prepping for Mango

With the v1.2 release, we had fixed almost all of the tickets in Trac and most of the glaring flaws in the app. However, there is still a ton of room for improvement. August was a mini-vacation for me, so I had hoped to get some good work done on the app in anticipation of the Mango launch this fall.

On August 22, the WP7 app store opened the door for apps targeting the Mango release (WP7.5), which offers a large number of new features and APIs. This includes support for multitasking, multiple live tiles per app, background agents, built-in SQL CE databases, and more. Consumers will be able to get Mango phones within the next month or two, and I wanted to have an update ready for them.

Most of my work on the app to-date had been relatively superficial changes, and I had not yet dug deep into the internals. However, to implement a database backend or improve live-tile support, I would have to make deep changes. And, boy, was I in for a shock.

Architecture?!

I’ve worked on a healthy variety of software projects, from pet projects to large enterprise applications at companies like Microsoft. I’ve become fond of concepts like Separation of Concerns and Do Not Repeat Yourself, and basic architecture patterns like MVC (or its Silverlight/WPF variant, MVVM).

The WordPress for Windows Phone app codebase is a total mess. XAML code-behinds gleefully call XML-RPC methods or into the global singleton containing all the app’s data structures. The XML-RPC methods themselves are a convoluted mess of string interpolation and concatenation, using string templates from multiple sources (some in RESX files, some inline with logic). Because the data is in a singleton and code-behinds, designers can’t work on the app in Blend. In short, highly coupled code with almost no separation of concerns.

Perhaps the original developers were under intense time pressure, and had to sacrifice maintainable architecture to hit a tight deadline. Been there, done that. However, given that this was primarily the work of an outsourcing firm, my suspicions are that the truth lies elsewhere…

How To Go Forward

So, given the state of the code, what’s the right way to proceed? I see three options:

Option #1 is to start piecemeal refactoring the app towards a “proper” MVVM architecture. Use MVVMLight or Caliburn, and start moving code from XAML code-behinds to ViewModels. In the process, decouple the data layer too, so that it can eventually be replaced with a SQL CE database backend. I imagine this would take a few months at a reasonable pace; but a few months means that Mango users will have to wait for fast-switching support and all the other niceties that Mango apps get over NoDo apps.

Option #2 would be to do a minor update for Mango, perhaps just multiple tiles (per-blog) and a background agent to keep the data fresh. Thus we could do a v1.3 Mango release to tide people over until we can get around to the work in option #1.

Option #3 would be to just soldier on and learn to live with code duplication and tight coupling. This makes it harder to make changes, but maybe releases could happen sooner. If we stumble along long enough, maybe we won’t have any users or Windows Phone will radically change and require a rewrite anyway.

The code snob in me would prefer #1, and I may get started on that on my own. The pragmatist in me would prefer #2. The developer in me would want to quit a project that would choose #3.

I suspect that next week at BUILD we will learn that WinPhone apps will have an easy path towards compatibility with Windows 8; a properly architectured MVVM app would make it super-easy to bring the WP7 app over to W8, or even to existing Windows versions by writing a WPF UI layer over the same ViewModels and data backends. Just another reason to go for option #1 or #2.

Conclusion

Sadly, WP7’s marketshare just isn’t very high, and Automattic has a very small team of mobile developers. I understand and respect their decision to work primarily on the iOS and Android mobile apps. Isaac, Dan, and Dan have been extremely gracious and helpful to me over the past several months, and my complaints/criticisms are not aimed at them.

My academic studies prevent me from pouring significant time into the project, so the app has been sitting since the v1.2 release. If there are other Microsoft stack developers out there who are interested, please post on the dev blog and get involved! With some more manpower, I think we can do great things with this app.

In the short-term, I’ll likely start work on an MVVM refactor and post that work on GitHub. If it doesn’t work out, then no harm done. If it does, and the rest of the team approves, we can merge that back into the primary SVN repository.

Beyond the app’s internal workings, I also have many thoughts about its user interface design. With custom post type support (hopefully) coming in XML-RPC in WordPress 3.4, I have some ideas for how to prepare the app to support more than just posts, pages, and comments. I also have ideas for how to make it better match the WP7 styling and behaviors, support rich text editing, and more. Look for my next post on that topic next week.

Leave a Reply