I have just published yesterday my first Windows Store app called YouTube DJ. It gets your YouTube playlists and allows you to play them on your Windows 8/RT device, including when the application is in the background. This is an app I can genuinely say I will use (a lot!). I use YouTube to listen to music, and leave it open in autoplay so I can listen to music while I use my computer.
There are a couple of reasons why I decided to make this app. First, if I want to play music from YouTube playlists on my Surface tablet, I don't like to have to do it through the desktop browser because I don't like to use the desktop from my Surface. The second reason is to be able to control playback using the media keys on my keyboard (play, pause, next track...). I never really bothered with those keys before Windows 8, but now that Windows 8 has a pretty cool volume control popup that shows you info about the current track, and pause/next track buttons, I became quite a fan of those media keys, since you know exactly what happens when you press them (the volume control popup gives you a visual feedback). Obviously, the browser version of YouTube doesn’t support those keys.
So, if like me, you use YouTube for listening to music, make sure to download my app. It is completely free!
The development of that app took a few weeks, but I only worked on it during my spare time. I learned a few valuable lessons while developing it, and I'm going to list the important ones in that post.
The learning curve
I used XAML and C# to develop YouTube DJ. I actually have some prior experience with Silverlight and WPF. What I can say about the learning curve from the point of view of someone already familiar with Silverlight, is that there is none. All you know about Silverlight (or WPF) applies to Windows Store Apps development. Of course, the full list of controls is a little bit different (like the new ProgressRing), default templates are different, since they are adapted to
the new design principles (you can find all the default styles and
templates from this list I published on my MSDN blog), some things can also behave differently than with Silverlight or WPF, but overall, 95% of your Silverlight skills will be reused.
From my experience developing YouTube DJ, XAML with Windows Store Apps is actually much better than XAML with Silverlight, bindings all work as you expect them to (Silverlight had some weird restrictions), custom dependency properties work exactly the same as non-custom dependency properties (again that wasn't the case with Silverlight). I can say that the developer experience was much better than with Silverlight.
Follow metro guidelines
I’m not really a design genius, but I am very conscious that the user experience of an application can make or break it, so I always try to put some effort into design, with varying success. Working on Windows Store apps was really pleasant from that standpoint, because the guidelines, default styles, etc… give you a good base to build upon. Of course, some apps have great success making very custom user interfaces, but many have mixed results too. MSDN provides a huge number of articles about guidelines for Windows Store app, and I highly recommend them. I myself published a blog post about spacing and typography.
Don’t hide important features of your app
This may sound like this contradicts my previous advice, but it doesn’t. If search is important in your app, provide a button on the main screen for opening the search charm (you will notice that's what YouTube DJ does). Unfortunately, if you simply provide search through the charm, a large proportion of your users will not discover it. Windows 8/RT paradigms are still being learned by people, and it will take time before people immediately know where to find search. Do implement it as a charm though (for people who know where to find it), but have a button in your interface that opens the search pane. This is the same for important commands, they can be placed on the page, rather than in the app bar. Many people don’t think immediately about the app bar, though it will become more natural over time.
Embrace asynchronous programming
- Always return a Task (not void) if your function is async, to avoid losing the possibility to know when the operation completed. The only exception to that is if you implement an event handler which needs to return void.
- When you call a method that returns a task, try to always await it at one point, unless this is really a fire and forget operation, of which you don’t even care if it fails. You will get a compiler warning if you fail to use a task you obtain by calling another function.
- If you get cross thread exceptions, use the dispatcher to run the code on the UI thread. This will turn synchronous code async though, as there might be a queue of items waiting to be run on the UI thread.
Short loading times
If you get your data from a web service, and your app cannot be used before that data is loaded, then cache it for next time the user launches your app, so that it launches faster next times. Apps are very similar to websites in that regard, users have little patience, and if an app spends its time loading data, users will stop using it. As a rule of thumb, compare it to a website. It you think you would find your app too slow if it was a website running in your browser, then you need to somehow make it faster (caching can be an option).
Be prepared for certification
Make sure telemetry is turned on in your Windows Store developer account
This will give you very useful information about the usage of your app: how often people use it, and for how long, does it crash, and how, etc… Microsoft collects the data for you, if the user opts in. The data is anonymized during collection.
That's it, I hope you will found those advices useful, and don’t forget to try my free app YouTube DJ!