Windows Phone Live Tiles: Not All Tiles Are Created Equal

If you've seen any of the incredible dearth of Windows Phone 7 pre- and post-launch coverage and press releases, you heard about them or seen them. They are those wonderful things on the Windows Phone 7 home screen that provide you with easy access to information - your email, Xbox Live games and other applications. Any application on your phone can have one. They are Tiles. The early demonstrations showed all of the amazing things they could do - provide animations to inform and entertain and update dynamically as new information becomes available. And they were referred to on a regular basis as Live Tiles. They made us all very excited about the Windows Phone 7 platform - well, almost all of us. For another audience, the concept of Live Tiles made us a bit nervous.

For those of us who have been involved with the Windows Phone 7 platform from the initial announcement back at Mobile World Congress and the launch of the development tools at MIX, there typically came a point of realization regarding Windows Phone 7 tiles. For myself, that realization made me look to the future and the launch of the platform to the public. There would be questions from users, and perhaps a bit of disappointment. There might even be some anger.

When Windows Phone 7 was launched in Europe and the Asia/Pacific region on October 21st, 2010, those questions started coming. They came in emails and in forums. The names might have changed, but the question was always quite consistent:

"Why isn't the Live Tile for [Fill in the application name here] doing anything?"

While my answers may have been slightly different in each case, they all always boil down to the same simple fact - Not all Windows Phone 7 Tiles are created equal. In many cases, the reason why they are not is based on very good reasons. Recently, a discussion with Jason Dunn made me realize that it might be a good time to explain some of the reasons to the community-at-large.

What Really Makes A Tile "Live"?

When I first saw Windows Phone 7 demonstrated, I was (like most) very excited about the Tiles concept. When I first heard that third-party developers could tap into this functionality and make the tile for my own application have a live aspect, I was thrilled. Further research into what it would take to get to that point, however, made me realize that there were some "catches" to this. To start, it only takes a moment of thought and some common sense to come to some early conclusions.

In order to be "live", a tile would need to receive some information from somewhere. For the purposes of our discussion, let's suppose that I am creating a reminders application for Windows Phone 7. As a developer, I would love to have my application's tile change when it is time for the user to be reminded. The first thing I realize as a developer is that Windows Phone 7 applications cannot run in the background. Most users as well as developers are aware of this fact. As a developer, the next logical question to ask is "If my application cannot run in the background and tell the tile to update, what can tell the tile to update?" A bit of research provides an answer.

Microsoft has developed and provided an application model that allows for a centralized and Microsoft-maintained environment known as the Microsoft Push Notification Service, or PNS. Because Apple provides a similar service for iPhone and iPad development knows as APNS, I tend to refer to Microsoft's version as MSPNS. The idea is quite simple - a central (and always running) server sends a message to MSPNS which, in turn, locates the device that is supposed to receive the message and passes the message along. The concept may be "simple", but as a developer it creates a new and potentially major level of complexity to my application - I must build my application to include a centralized server component.

Looking back on my original idea of a reminders application, what would this new requirement mean? Well, I would need to do the following:

• I would need to develop a web-based server application to store reminders. My simple client application would now need to be complemented by a Web-based service. This service would likely need to include a database element. When a user creates a new reminder on the phone, the client application would need to connect to the Internet, authenticate (there could be thousands of users of my application; I would need to identify each user correctly), and then store the information. 
• I would need a service to send reminders to the MSPNS. My application would need to have a service that constantly monitors the database, looking for reminders that are due. The service would then send the proper message to the MSPNS.

Of course, this is just a a simple overview of what would need to be put in place in order to have a successful Live Tile implementation. When presented to a developer, there is a lot here to consider - and not all of it is technical.

Live Tile and the "Business Impact"

The first time I presented on the subject of push notifications (earlier this summer), I first thought I would spend a great deal of time in the presentation on the lower-level programming details. After some consideration, however, decided on a different approach. I would talk about the architecture of push notifications, the processes involved for creating such a solution and the business impacts. I was glad that I did.

When the developers I presented to saw what was involved with using MSPNS, they were not necessarily concerned about the technical aspects of implementation. Instead, it was the concerns about the "cost of doing business" related to using push notifications that immediately raised issues. They included -

• The obvious additional cost of creating and maintaining all of this newly-needed code. The audience I spoke to consisted primarily of independent developers and hobbyists - a large target audience for Microsoft and Windows Phone 7. While creating a client application is definitely "on their radar", creating something far more complex would likely take more time and effort than is desired.
• The cost of maintaining a web-based solution.There is far more than development costs when dealing with a web-based solution. The cost of hosting a solution (especially when a database is involved) can become quite large rather quickly.
• The cost of providing the proper Quality of Service. This is a HUGE consideration. The user expectation is 24/7/365 for any solution, regardless of where the application or pieces of the application reside. Anyone who has run a large and successful website with a worldwide audience can usually attest to this - just ask Jason. ;-) For a small independent or hobbyist developer, this is a major commitment - often far more than they had bargained for and want to deal with.

Not surprisingly, quite a few of the developers in the audience for my presentation simply said "No way". They would build their applications, but Live Tile functionality was not going to be a part of the solution. It is important to note that there is no requirement for making a tile "live"; there are simply some requirements and guidelines on making your tile "fit in" with the overall Windows Phone 7 experience.

I walked away from that presentation realizing that Live Tiles could very well be the exception rather than the rule on any given Windows Phone 7 device. I also wondered "What could Microsoft do to help here?" 

What Can Microsoft Do To Help with Live Tiles?

While there are several possible options for Microsoft to consider in relation to making Live Tiles easy to implement, none comes without a major sacrifice to either developers or Microsoft and the platform. Among the possibilities -

• Allow background processing.This would be the easiest solution for developers. Of course, this goes against the core foundations that were set forth for the Windows Phone 7 platform. While I may not receive much favor for my belief on this issue, I have come to agree with Microsoft on this stance. With a target audience focused on consumers who "just want the phone to work", allowing background processing opens the door to a number of complexities that typically diminish the user experience - memory, performance and battery life. As a regular user of Windows Mobile and Android devices (both of which allow background processing), I can tell you that these issues are a sore point for users who are not in the "power user" category and do not understand (or want to understand) how to use advanced tools to monitor, diagnose and correct these problems.
• Provide an on-device notification service. With the .NET Compact Framework and Windows Mobile, developers were provided with the State and Notification API, or SNAPI. This functionality allowed an application to subscribe (i.e. - "listen for") to various events and then respond when they occurred.  Granted, this model assumed that the application was, of course, running in the background. My thought - perhaps a service that the operating system runs and manages, with an application saying "hey - when x happens at a certain time, notify me". Granted, the number of things that could be set up in this scenario would be somewhat limited, but would work for time-based scenarios (setting a reminder, for example) and simple events (when the battery reaches a certain level or a new phone call comes in). While an on-device notification service is not a perfect solution, it may make for a nice compromise. Developers would have more functionality than they currently have, and by being controlled at the platform level Microsoft can manage the service properly to maintain the quality of service needed for the platform.
• Extend MSPNS to be a "solution" rather than a "service". Currently, the cost of creating a server solution to support push notifications is prohibitive for most developers. If Microsoft were to provide a more robust solution that mitigates the need for complex development and hosting, more developers would "take the plunge". Once again, the limitations of such a solution might still make this a prohibitive option (thinking along the same lines as the on-device notification service), but the idea that "something is better than nothing" might help.

Bottom line - there is no one "magic bullet" solution to the current situation. Even if a new approach was decided upon, it will take some time to implement and roll out to the masses.

Conclusion

Over the years, I have come across various pervasive questions around Windows Mobile and Windows Phone that seem to have no "satisfactory" answer, at least for the consumers asking the question. The first that comes to mind was "Why can't I upgrade my Windows Mobile device to the newest version of the operating system?" I decided then to write about how the Windows Mobile ecosystem works and why things were the way they were. I didn't solve the problem; I just tried to help people understand.

Windows Phone 7 Live Tiles may be the latest incarnation of a question that provides no satisfactory answer. Once again, I could only hope to help to shed some light on why things are...well, the way they are. When all is said and done, I hope that this piece helps in understanding why all Windows Phone 7 tiles are not created equal and may not be for some time. While the additional knowledge doesn't change anything, it at least helps in addressing the question "Why?"

Don Sorcinelli is a Microsoft MVP for Mobile Devices and a consultant with 20 years of enterprise software development experience spanning a variety of technologies and platforms. He has spent much of the last decade focused on mobile technologies for both business and personal productivity. He is currently a Product Engineer focused on mobile applications across mobile device platforms.

Do you enjoy using new hardware, software and accessories, then sharing your experience with others? Then join us on the Thoughts Media Review Team! We're looking for individuals who find it fun to test new gear and give their honest opinions about the experience. It's a volunteer role with some great perks. Interested? Then click here for more information.