As a follow up to my latest blog post, I want to show how easy it is to have a working Live Tile for your app. Here it is in brief:
- 1- create a static image or a webservice returning one (optimal size is 173×173 px), have it available on the web
- 2- include the following code snippet in your Application_Launching method
new ShellTileSchedule
{
RemoteImageUri = new Uri(@"http://yourwebsite.com/pathtoimageorwebservice"),
Recurrence = UpdateRecurrence.Interval,
Interval = UpdateInterval.EveryHour,
MaxUpdateCount = 0,
StartTime = DateTime.Now
}.Start();
- 3- there’s no 3. Now how hard was that?
ShellTileSchedule is the easiest way to have your Live Tile up and running in no time. So where’s the catch you may ask? Well, I’d love to say there aren’t but that wouldn’t be true: here are a few points to pay attention to.
#1 the first tile update won’t happen until the specified time interval has passed, and ’1 hour’ is the shortest interval you can use. This doesn’t help with testing / fine tuning your Tile.
#2 the Windows Phone dev team itself suggests to put the code above in Application_launching, and this makes perfect sense on the first run of your app. One issue is that subsequent calls to the same method will re-schedule the update for 1 hour later. In this scenario, if your app is opened twice in 1 hour, the Tile update won’t happen.
#3 there’s no way to tell if the scheduler is active or if it has been deactivated (it happens without notice if it fails to download the pic 3 times). If there was, #2 wouldn’t be an issue.
What to do? Personally I’d just live with it, as the ‘Mango‘ update is supposed to give better and more stable tools to handle Live Tiles from a developer point of view.
One way to make #2 a smaller problem would be – for example – to run the initialization code just once every day, so that launching the app won’t re-schedule the update. In the event that it gets deactivated it would be fixed the next day.
But if you’re a perfectionist and got a lot of time in your hands, check out this blog post by Silverlight MVP Mark Monster, who provides a better (but more time consuming) solution to most of these issues.