Sunday, December 23, 2012
UPDATE: Well, obviously this hasn't made it out yet. I've had it through certification several times now and I'm waiting for it again. They seem to have trouble testing it since it requires an active Marketplace account (you'd think they could manage!), and then my last submission somehow made a "forbidden" function call all of a sudden. Grr... Hopefully better news soon!
Saturday, December 22, 2012
while( NavigationService.CanGoBack ) NavigationService.RemoveBackEntry();
Monday, October 22, 2012
Anyone else I know going? Let me know! I'd love to hang out.
WinRT is a brand new paradigm for developing apps due to its rethinking of the environment, but it's not a totally new product either. Read this article by Peter Bright/Ars Technica to get an amazingly in-depth (and correspondingly long!) take on the evolution of Windows and how it leads to WinRT. It's a great read!
Link: Turning to the past to power Windows' future
Monday, October 15, 2012
Friday, September 21, 2012
Sunday, September 16, 2012
Thursday, September 6, 2012
I’m tired of waiting! According to the Nokia press conference yesterday, developers may be able to get the SDK next week. It seems that you must have apps in the marketplace already in order to qualify, but I’m not even sure if that’s the only requirement. Considering the leak from a few months ago (which I never got) it seems like they must be close enough for developers to start working on their apps. I want as much time as possible to get my apps updates, but also to write apps that use the new features. Voice to text, text to voice, protocol handlers to invoke other apps, lenses, the Kid’s Corner, more available working memory, full Bluetooth integration, and greater platform access should combine to make an amazing developer experience (not to mention better apps for end-users!). I really hope that I’ll qualify next week, and that I won’t have to then wait even longer until actually getting the bits! Sound off if you are also excited, and what features you are most waiting for.
Tuesday, September 4, 2012
So, the Marketplace Dashboard update almost made it through testing! The biggest problem turned out to be it's performance on low-memory phones like the Nokia Lumia 610. I was surprised since I knew that it ran fine, but it ended up being more subtle than that.
First of all, you should know that background agents won't run with 256MB phones. For that reason I was already hiding the option for that on those devices (and feeling pretty smug about it!).
|Lumia 610 (256MB RAM)|
Bottom line, it's not just peak memory that you need to worry about. With less memory, things can run slower. If you are using timeouts, you should probably increase those too. Unfortunately, that part's going to be hard to test on the emulator. You can only do your best though! Being aware of this might save you some frustration later.
Friday, August 31, 2012
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!
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!