Windows 8 will show up at retail pretty soon! If you haven’t started developing apps for it, get a start on it now. Get some help to guide you from concept to app. They have lots of tips and tricks, access to an architect, and a design consultation. Sign up now!
Friday, August 31, 2012
Sunday, August 26, 2012
Marketplace Dashboard now has full Mango support (finally!) so it will do fast resume, but also has a background agent for Live Tile updates and even notification when an app gets published. In the app you can view number of downloads and crashes like before, but also see day-by-day downloads and crashes, and you can pin a live tile for specific apps to see updated info. Secondary live tiles are only available on 512MB devices (shouldn't affect many devices yet...) and only to paid users.
Gallery Downloader has a bug fix update for some crashes that were occurring sporadically if you double-clicked the Back button by mistake after downloading images. It's annoying how many safeguards are needed to prevent problems like that!
Both updates should be live in another day or two. Enjoy!
Saturday, August 25, 2012
I had been under the impression that the new Windows Phone 8 app model wouldn’t support “classic” Windows Phone 7 apps. From various rumors, it seemed that it might be based on WinRT (which would be good) and Silverlight would no longer be an option (not as good). This seemed like a dumb idea due to the zeroing out of the Marketplace, but I thought maybe it was the price to pay for moving forward. Now I notice that when I submit an app update using current phone tools, I appear to get Windows Phone 8 compatibility for free! Interesting, interesting…
Friday, August 24, 2012
The Async Framework came before WinRT of course, but its amazing integration has come with the new framework. I love the fact that all of the potentially blocking methods are now exposed as asyncronous methods. The IAsyncOperation return type, which is returned from these methods, can be easily awaited to avoid the hassle of callbacks, and for .Net integration, you can always use the AsTask() extension method (though you'll often not need to).
Background operations often require two important things: the ability to cancel them from other threads, and the ability to report progress. Both of these needs are easily addressed using the CancellationToken object and IProgress<> interface. Strangely, from .Net you need to first get the Task adapter, but then you can just pass the CancellationToken to operations, and then call Cancel() method from another thread (often the UI thread).
Progress is a little bit trickier since most framework methods don't have direct support for it. Adding progress reporting to your own methods is almost trivial though. Instead of being limited to simple integer-based progress (like in the older BackgroundWorker class), you can use anything you want since you create your progress handler with a generic type. You can simply return a string to directly display, a number out of 100, or a complex custom object that reports per-item, batch-level, and other information in each report, then write your own code for what to do when the reports come in.
Handling cancellation in your own methods works one of two ways: you can either check to see if cancellation has been cancelled and clean up before throwing the TaskCanceledException, or call the ThrowIfCancellationRequested() method if you don't have any last requests.
The await and async keywords are some amazing compiler trickery. Having written callbacks for asynchronous code for years, it's so refreshing. There's just a tiny bit of mind-bending the first time, but the picture becomes clear pretty quickly! Basically, ignore the async part of it all unless you have special needs. You can always choose not to await, or to wait on more than one operation to complete, or to wait until the first of a group of operations completes, but even these special cases don't really mess things up. Once you learn the new commands you'll be productive quickly.
It's funny. Thinking through how the async features work with return values, exception handling, and the generated state machines, it's not that hard to imagine making it work from scratch. Of course, things are always so much more obvious once you see how they work!
I have some videos coming out soon that walk through some async scenarios. I'll post the links then. In the meantime, grab Windows 8 and Visual Studio 2012 and start figuring it out!