Things I wish I learned about Live Tiles a little earlier
I haven't written about .NET here in a while (and probably won't again for another while), but I wanted to put some thoughts up here in case other folks are looking for some details about Live Tiles on the Windows Phone 7.
These are things I learned before and during developing my Gold Price app, which is now available on the Zune marketplace. As well as looking up the current gold price on Yahoo, it puts the price on a Live Tile so you don't even have to open the app to stay current with the price of gold. Feel free to buy it!
Live Tiles are currently one of the unique features of Windows Phones. I love it that my Gold Price app isn't even possible on an iPhone. iOS just doesn't have the notion of 'live' icons on the start screen, beyond a simple (1-100) count. If you're Apple, you can do some fancy icon stuff (like the calendar app, which changes the icon to reflect the day and month), but if you're just a regular iOS developer you're out of luck. To the left is a screenshot of the ‘start’ screen (of the emulator – getting screenshots from the real phone is Much Too Hard, unlike in iOS) showing the Gold Price app’s Live Tile. The tile updates every hour, with no user intervention. Live Tiles try to keep themselves visibly up-to-date, updating when the screen is unlocked but not bothering when the screen remains locked. If the phone owner is asleep, the phone naturally doesn’t bother making any network calls.
Here are some things I wish I learned about Live tiles a little earlier:
- You can't have an animated Live Tile, unless you're Microsoft. In some ways this is a shame - I dislike restrictions on what developers can do when the OS creator just gets to do whatever the hell they like (such as background processing on both WP7 and iOS). On the other hand, I don't really want the weird and wacky world of Geocities-like animated tiles on my phone either. If there was an option to turn off animated tiles, I'd probably have them turned off anyway, so on balance I won't be losing too much sleep over this one.
- The Live Tile image is (generally) created and hosted on a web server somewhere, not via a callback into your app code. This means there's a dependency on network connectivity for updating the Live Tile.
- This network dependency also means apps that use Live Tiles need to have a server infrastructure behind them, even if it is only a small one. The ongoing cost of a web server means I think we’ll see fewer free Live Tile apps than if there was a server-less way of updating Live Tiles.
- Mike Ormond has a great outline of how to plug a ShellTileSchedule into your app.
- Problems with Live Tile updates are hard to debug. Everything must be just right for it to succeed, but many things can go wrong and I haven't found any way to tell where the problem is.
- Your server must send the Live Tile image within 15 seconds of the request from the phone. This could be a problem if you're dependent on a web service call to another web server (like mine, which currently goes to Yahoo to fetch the pricing data). Network problems, latency, slow servers and bad DNS may be outside your control, but they can all make your image-fetching time lower than you’d like.
- The image itself must be small (less than 80kb in size) It surprised me that the PNG generated for my Live Tile was so big when it's a compressed (albeit lossless) format. I ended up going with JPEG - it looks a little more washed out than the PNG version, but I'm confident it'll have no size issues.
- It surprised me even more that the exact same .NET 4.0 code generated a much larger image file on my server than on my development machine. I ended up putting some code in the image generator/handler to check the size of the generated image (just so I could return an 'error' image that is guaranteed to be small enough) to help track down problems with fetching Live Tiles.
- From discussions with other folks, it looks like the LiveTileSchedule adds the Live Tile update to the schedule, or resets the schedule for that tile if it has stalled because of an error, but - importantly - it doesn't change the time the update is scheduled to run.
For example, if your Live Tile is scheduled to update in 5 minutes, and you load your app and it calls its LiveTileSchedule code, your Live Tile is still scheduled to run in 5 minutes. (Otherwise someone who opened your app every half hour would constantly reset any hourly schedule and the Live Tile would never update.)
- It is possible to have your app trigger an immediate update of the Live Tile although the code (and the mechanism itself) seems horribly contorted. Mark Monster has a great description of how this all works. You have to set up a Push Notification channel, then have your app send itself a Push Notification telling itself that the Live Tile has been updated. Again, there's a dependency on network connectivity for this to succeed, so even if your app has all the data to generate the new Live Tile itself, and you embed the image generation code in your app, you still need a network available to send a Push Notification from your app to your app using a Live Tile URL local to your app.
If you’ve any comments, or if I’ve got any of this wrong, or if you’ve got a great example of a Live Tile app, please let me know or comment below!
Categories: .NETPermalink #.
Posted by 'geoff' on Sunday, 06 February 2011 at 6:49PM
Comments, Trackbacks and Pingbacks
This means there's a dependency on network connectivity for updating the Live Tile.
Isn't that the whole point of a Live Tile? To use the network to update based on an information feed? I can't think of an example of a Live Tile that wouldn't have a dependency on network connectivity ...
Posted by 'Tony Hansen
' on Saturday, 26 February 2011 at 1:01AMOne case where I'd like to be able to generate a Live Tile image locally
Thanks for that. I didn't really expand on that point in the article, but yeah, I can see quite a few uses where an app creator would want to update the Live Tile when they don't have network access.
Take as an example a Tamagochi-style app. If I were writing it, I'd like the Live Tile to update with the current state of my Tamagochi creature (Is it hungry? Lonely? Playing? Sleeping?), all of which the app on the phone knows. If Live Tiles could be updated on a schedule via a callback into my app, it could generate the Live Tile on its own (Silverlight is great at graphics, after all), all without ever needing to connect to the network.
However, that's not possible with the current Live Tile mechanism. Right now to create an app like that I'd have to maintain a dedicated server infrastucture to keep the data up to date, I'd need to duplicate the game code on the server (so it would know what to do as time elapses without the game being launched) as well as needing the image-generation code on the server to post the updated Live Tile image. That all seems horribly unnecessary for such a simple application.
I could maybe kludge around some of this by having the app send itself a notification of a new Live Tile, and have a handler for the Live Tile URL on the client generate the image on the fly and return that when the phone asks for the Live Tile. I haven't tried that, but it might be possible. Even if it is, it seems horribly contorted and the network serves only to introduce a (fairly flaky) point of failure.
That said, there are plenty of drawbacks with generating a Live Tile via a callback into the code. How would it be handled? A callback that just took a closure would be really nice but very difficult for MS to implement, so maybe a self-contained interface/type that had access to the same isolated storage would be better. Even with that in place, MS would need to put strict limits on resource usage, just as it does with the time allowed to fetch a Live Tile and the size of the Live Tile image file. Maybe it could give the thread a five-second limit before aborting it if it hadn't generated an image?
I have no intention of ever creating a Tamagochi-style game, but I thought it was a nice example of one case where I'd rather be able to generate the image locally and never need access to the network.
Posted by 'Geoff Taylor
' on Sunday, 27 February 2011 at 1:49PMi like live tiles too
Posted by 'james braselton
' on Thursday, 20 March 2014 at 12:40AM15 live tiles running at one time
Posted by 'james braselton
' on Thursday, 20 March 2014 at 11:50PMDew Drop – February 6, 2011 | Alvin Ashcr...Things I wish I learned about Live Tiles a litt...
Posted by 'Pingback
' on Monday, 07 February 2011 at 12:46AMMax of 1 Tile per App
One other restriction is that apps can only have one tile (live or not), a feature that is available to the OS but not 3rd party.
This would be fantastic for easy of entry into an app dealing with multiple accounts, the same way email accounts are handled.
Posted by 'Anthony
' on Saturday, 12 February 2011 at 12:00PMAbsolutely!
Thanks Anthony - you're absolutely right! I've ranted about that myself in the past, but forgot to put it on my list above.
You're quite right, you can only have one Live Tile per app, and only one installation of each app per phone. It's another one of those annoying things that MS can do that regular developes just can't.
The reason I've ranted about this in the past is because of the way it affects apps like my Gold Price app. I can't have one general 'price' app that you (as a user) can configure to put a Gold Live Tile on your start screen as well as a Silver Live Tile, a Platinum Live Tile etc. The one Live Tile per app limit means you'd need to install a separate app for each price Live Tile you wanted, and the limit of one installation per device means I can't create a general app that allows you to install it multiple times, picking the precious metal you wanted for each installation.
Posted by 'Geoff Taylor
' on Saturday, 12 February 2011 at 3:22PMTWC9: mvcConf, WP7 Tools update, AsmSpy, JavaSc...How Windows Phone 7 Live Tiles work, their limi...
Posted by 'Pingback
' on Sunday, 13 February 2011 at 11:57AMTWC9: mvcConf, WP7 Tools update, AsmSpy, JavaSc...How Windows Phone 7 Live Tiles work, their limi...
Posted by 'Pingback
' on Monday, 14 February 2011 at 1:59AM