As prompted by http://shiflett.org/blog/2012/mar/ideas-of-march
I like blogs.
I read the titles of hundreds of blog articles each day and usually end up reading dozens of posts.
There are 2 main reasons (that I can think of right now) that I like blogs though:
1. I like how anyone can write a blog. Yes, even little old me. Blogs have allowed me to read the thoughts, ideas, experiments, plans and more of hundreds of people. And I'd never have even heard of or met most of them if it wasn't for their blog.
Not that this means I think everyone should write a blog though. And yes, I include myself again there sometimes. ;)
2. Blogs are probably the way I learn most new things in the software development world. Yeah, StackOverflow is probably up there too, but all the important and useful information in software dev seems to come from individuals experiences and not from official documentation. I'm certain that if no-one was blogging I'd spend more of my time fumbling through badly orgainsed and ill structured documentation.
Thank you bloggers of the world.
Thursday, March 15, 2012
Wednesday, March 14, 2012
Slides from last months Scottish user group talks
Last month I went to Scotland to talk at some user groups about Windows Phone development and general mobile development principles that can be applied to all platforms.
I've had some requests for the slides from those talks. (The latest evolution of the slides since the last time I gave these talks.) So here they are:
I've had some requests for the slides from those talks. (The latest evolution of the slides since the last time I gave these talks.) So here they are:
NanoIOC - How I do Depenedency Injection on #WP7
When it comes to Dependency Injection / IOC there isn't a good story for Windows Phone*.
There's nothing built in and lots of people have created their own solutions. Including, but not limited to,: Funq, MicroIoc, TinyIoc, this or this. But none of them work the way I want to.
I want:
I don't want:
I don't care about:
There are two factors which influence my requirements:
1. My past experience with Castle Windsor - Chosen after evaluating what was available at the time (about 4 years or so ago.)
2. My experience with working in development teams where there would always be at least one person who wasn't interested in learning anything new, best practices or, seemingly, code quality. I've learnt that if you're working with such people, or anyone new to the industry, that you'll save yourself a lot of work (in fixing up their errors, mistakes and repeatedly explaining things to them) if everything is explicit and clear and not "magic" because if they can't understand it they can't update it or fix it if there's a problem.
So I've written something myself: http://github.com/mrlacey/NanoIoC
Yes, the name is a tounge-in-cheek reference to MicroIoc & TinyIoC but hints that mine has much less code. (It's less than 90 LOC.)
Yes, I know it's more of a DI framework than an IOC one but the terms are used fairly interchangable out in the real world so I'm happy with this.
How to use it:
For the class that has some external dependencies, we declare this by marking them up with an interface "ISupportInjectionOf<T>". As an example, if we wanted to indicate a page had a dependency up an "IRepository" and an "IDateTimeHelper" we'd do this:
Then within our constructor we'd resolve these dependencies:
Yes, we could resolve the dependencies at any time, but in my code it'll always be in the constructors.
This is important for maintaining testability and maintainability. (I'm establishing a convention.)
In the above example I'd also include a constructor overload for directly injecting the dependencies during testing:
Simple!
Configuration:
Configuration is simple and done at app level. We can declare how each dependency should be resolved separately:
Or via a fluent interface:
Obviously these examples all use interfaces. But we don't have to. Assuming that we didn't want to hide "DateTimeHelper" behind an interface, we can just do this (note the type is inferred):
The above examples are all creating an instance to use for every time the dependency is resolved.
Instead, we could pass an instance of a singleton in the traditional way:
If you want different instances each time a dependency is resolved simply pass a factory and get the new instances that way.
What do you think?
Useful?
Interesting?
Something you may consider using?
Want it bundled into a NuGet package? (Either as a library or the single source file)
I'd love to know what you think.
* It would be awesome if in a (prefereably near) future version of the Windows Phone SDK, it included tooling to allow it to be easier to implement good development practices in our Windows Phone code. It's awesome that they've made it easy for people to get started with developing for the platform but those beginners need, in time, to know how to write better code and if the tools stop them there's no incentive for them to learn. And for those of us who consider ourselves professionals and do this for a living, we want to be able to apply best practices to our code (work) and not have the SDK and the tooling get in the way and stop us doing basic things.
There's nothing built in and lots of people have created their own solutions. Including, but not limited to,: Funq, MicroIoc, TinyIoc, this or this. But none of them work the way I want to.
I want:
- Automatic constructor parameter injection
- Explicit indication of where a dependency exists
- Explicit configuration of how dependencies should be resolved
- Fluent configuration
I don't want:
- Parameter injection
- Automatic resolving of dependencies
- An aribtrary ServiceLocator
I don't care about:
- Letting the container manage singletons
- Nested/chained dependency resolution
There are two factors which influence my requirements:
1. My past experience with Castle Windsor - Chosen after evaluating what was available at the time (about 4 years or so ago.)
2. My experience with working in development teams where there would always be at least one person who wasn't interested in learning anything new, best practices or, seemingly, code quality. I've learnt that if you're working with such people, or anyone new to the industry, that you'll save yourself a lot of work (in fixing up their errors, mistakes and repeatedly explaining things to them) if everything is explicit and clear and not "magic" because if they can't understand it they can't update it or fix it if there's a problem.
So I've written something myself: http://github.com/mrlacey/NanoIoC
As pointed out in the comments, this doesn't provide automatic constructor injection. Unfortunately the platform just doesn't support a way of doing that. This is my next best thing. - Hope that makes it clearer.
Yes, the name is a tounge-in-cheek reference to MicroIoc & TinyIoC but hints that mine has much less code. (It's less than 90 LOC.)
Yes, I know it's more of a DI framework than an IOC one but the terms are used fairly interchangable out in the real world so I'm happy with this.
How to use it:
For the class that has some external dependencies, we declare this by marking them up with an interface "ISupportInjectionOf<T>". As an example, if we wanted to indicate a page had a dependency up an "IRepository" and an "IDateTimeHelper" we'd do this:
public partial class MainPage : PhoneApplicationPage,
ISupportInjectionOf<IRepository>,
ISupportInjectionOf<IDateTimeHelper>
{
Then within our constructor we'd resolve these dependencies:
private IRepository repository;
private IDateTimeHelper dateTime;
public MainPage()
{
InitializeComponent();
repository = this.GetDependency<IRepository>();
dateTime = this.GetDependency<IDateTimeHelper>();
}
Yes, we could resolve the dependencies at any time, but in my code it'll always be in the constructors.
This is important for maintaining testability and maintainability. (I'm establishing a convention.)
In the above example I'd also include a constructor overload for directly injecting the dependencies during testing:
#if TEST
public MainPage(IRepository repo, IDateTimeHelper dateTimeHelper)
{
InitializeComponent();
this.repository = repo;
this.dateTime = dateTimeHelper;
}
#endif
Simple!
Configuration:
Configuration is simple and done at app level. We can declare how each dependency should be resolved separately:
NanoIocConfig.RegisterDependency<IRepository>(new ViewModelRepository());
NanoIocConfig.RegisterDependency<IDateTimeHelper>(new DateTimeHelper());
Or via a fluent interface:
NanoIocConfig.RegisterDependency<IRepository>(new ViewModelRepository())
.And<IDateTimeHelper>(new DateTimeHelper());
Obviously these examples all use interfaces. But we don't have to. Assuming that we didn't want to hide "DateTimeHelper" behind an interface, we can just do this (note the type is inferred):
NanoIocConfig.RegisterDependency(new DateTimeHelper());
dth = this.GetDependency<DateTimeHelper>();
The above examples are all creating an instance to use for every time the dependency is resolved.
Instead, we could pass an instance of a singleton in the traditional way:
NanoIocConfig.RegisterDependency<IRepository>(ViewModelRepository.Instance);
If you want different instances each time a dependency is resolved simply pass a factory and get the new instances that way.
What do you think?
Useful?
Interesting?
Something you may consider using?
Want it bundled into a NuGet package? (Either as a library or the single source file)
I'd love to know what you think.
* It would be awesome if in a (prefereably near) future version of the Windows Phone SDK, it included tooling to allow it to be easier to implement good development practices in our Windows Phone code. It's awesome that they've made it easy for people to get started with developing for the platform but those beginners need, in time, to know how to write better code and if the tools stop them there's no incentive for them to learn. And for those of us who consider ourselves professionals and do this for a living, we want to be able to apply best practices to our code (work) and not have the SDK and the tooling get in the way and stop us doing basic things.
Monday, March 12, 2012
Metro designs require imagination but provide endless possibilites.
I've heard it claimed that due to the restrictions that are imposed on Metro style apps "they're all going to end up looking the same" and "there's no opportunity to differentiate".
I'm calling BS on this.
Not only are people making such claims forgetting about the myriad applications which were all battleship grey and/or seemed to want to copy Outlook regardless of whether it made sense or not.
Such claims are focusing on the restrictions and ignoring the opportunities. Metro is intended to "inspire innovation".
Let's consider some other design opportunities which may be considered restrictive:
Watches are simple things. They have a strap and a face. If digital they'll show some numbers. If analog they'll have two or three hands. In theory that's very limited, but there are thousands of different looking watches available.
Or consider shoes. They have an upper, a sole, a heel and possibly some kind of fastening. Again, that's a very simple set of components but again, there are thousands and thousands of shoes available and they can look wildly different from each other.
Within an application we have many more options and possibilities when compared with something simple like a watch or a shoe.
If you find apps are starting to look the same then it shows a lack of imagination and creativity by the person(s) creating the app. It's not a limitation of the platform. It's a limitation in the imagination of the people creating them.
I'm calling BS on this.
Not only are people making such claims forgetting about the myriad applications which were all battleship grey and/or seemed to want to copy Outlook regardless of whether it made sense or not.
Such claims are focusing on the restrictions and ignoring the opportunities. Metro is intended to "inspire innovation".
Let's consider some other design opportunities which may be considered restrictive:
Watches are simple things. They have a strap and a face. If digital they'll show some numbers. If analog they'll have two or three hands. In theory that's very limited, but there are thousands of different looking watches available.
Or consider shoes. They have an upper, a sole, a heel and possibly some kind of fastening. Again, that's a very simple set of components but again, there are thousands and thousands of shoes available and they can look wildly different from each other.
Within an application we have many more options and possibilities when compared with something simple like a watch or a shoe.
If you find apps are starting to look the same then it shows a lack of imagination and creativity by the person(s) creating the app. It's not a limitation of the platform. It's a limitation in the imagination of the people creating them.
Wednesday, March 07, 2012
Debugging deserialization errors in JSON.NET
Ever have a problem handling deserialization issues with JSON.NET?
Did you know it has built in functionality to help debug deserialization errors?
Well, it does.
To help debug such scenarios you can do something like this:
I find that being able to get into the debugger when something won't deserialize I can quickly and easily identify the cause of the issue.
Hope this is useful to someone
Did you know it has built in functionality to help debug deserialization errors?
Well, it does.
To help debug such scenarios you can do something like this:
if (!string.IsNullOrEmpty(json)) { var settings = new JsonSerializerSettings { Error = (sender, args) => { if (System.Diagnostics.Debugger.IsAttached) { System.Diagnostics.Debugger.Break(); } } }; result = JsonConvert.DeserializeObject<T>(json, settings); }
I find that being able to get into the debugger when something won't deserialize I can quickly and easily identify the cause of the issue.
Hope this is useful to someone
Tuesday, March 06, 2012
Want help with Tombstoning?
I originally built TombstoneHelper to try and make it a bit easier to handle tombstoning in Windows Phone 7 apps. It covers some of the basics but doesn't go as far as most people need and their is still lots of confusion, amongst many, about how to handle tombstoning in an app.
I think I've finally got a good enough idea about the best practices for how to handle tombstoning for almost all situations and, probably more importantly, I've got some time to update the TombstoneHelper library.
But I have a couple of questions:
Is anyone interested in an updated TombstoneHelper? which would handle ViewModels too.
Are you usingthe current version?
How else do you handle tombstoning in your apps?
I think I've finally got a good enough idea about the best practices for how to handle tombstoning for almost all situations and, probably more importantly, I've got some time to update the TombstoneHelper library.
But I have a couple of questions:
Is anyone interested in an updated TombstoneHelper? which would handle ViewModels too.
Are you usingthe current version?
How else do you handle tombstoning in your apps?
Wednesday, February 29, 2012
My Anywhere Working Tips
As prompted by this.
I often find that I work from a combination of home, client site, coffee shop and even, sometimes, trains.
Here are my tips for anyone else who may be in such varied working connections, and yes, they all come under the umbrella guidance of ensure that you take responsibility for having power and connectivity.
I hope some of this is helpful and doesn't just make you wonder how much kit I carry around with me each day. ;)
I often find that I work from a combination of home, client site, coffee shop and even, sometimes, trains.
Here are my tips for anyone else who may be in such varied working connections, and yes, they all come under the umbrella guidance of ensure that you take responsibility for having power and connectivity.
- Charge devices whenever you get a chance. - Whether it's laptop, phone or something else. It's when you get confident about remaining battery life that you run out.
- Get spare batteries for everything and keep them charged. - Laptop batteries are the most obvious one, but don't forget phones and even a keep a few AA batteries around for your mouse.
- Get a universal charger. (Probably a USB based one so you can plug any usb device straight into a waal socket/outlet). - With all these devices to keep charged you could end up with a lot of cables to carry around too. Avoid this as far as possible.
- Get good headphones. -You want to be able to listen to quiet music/podcasts but still not hear ambient noise around you. Just make sure you can always hear when the phone rings.
- If you're working somewhere public and distractions come to you (i.e. Someone noisy sits down at an ajacent table) move! - The short interruption of moving is better than a long period of being distracted.
- Spare laptop battery. - Because coffee shops don't have enough public sockets/outlets.
- Spare phone - Just in case or if you haven't got a spare batteryand you have to make, or take, that important call.
- MiFi Unit - So you don't have to worry about finding WiFi
- 2nd MiFi unit (or sim) for a different network - Once you get stuck somewhere with no WiFi and no signal on a particular network you'll know why.
- Carry a tablet as well as your laptop. - 2 screens are a must for productivity but carrying a second monitor or laptop around isn't always practical. For moving web browsing or email off your laptop while you're working, a tablet can be a great alternative.
I hope some of this is helpful and doesn't just make you wonder how much kit I carry around with me each day. ;)
Friday, February 03, 2012
So I was wrong: W8 & WP8 to have a shared core.
Back in December I gave some fairly well reasonsed arguments about why I thought that the next version of Windows Phone 8 would not be based on the same underlying framework as the also forthcoming Windows 8.
Based on a leak reported yesterday (see here and here), it looks like I was wrong and I have 3 reactions.
I'm excited.
In many ways this is more than I could have hoped for. There are loads of cool features previously announced for Windows 8 that I would love to see and be able to use on the phone. And yes, also some I wouldn't.
I'm not counting my chickens yet.
There are still no public confirmation, details or timelines for any of this. I also wouldn't be surprised if we didn't see a greater similarity with Silverlight 5 than with WinRT in the short term.
I'm a bit nervous.
What will it mean for things going forward? (If advances in both platforms are to be kept in sync in the future.)
In the mobile space the market demands yearly updates. (Just consider the reaction when there was no iPhone 5 announced last year.--The 4S was considered by most as a disappointing stop gap to whatever comes next.)
On the desktop this (yearly frequency of updates) hasn't been seen in the past and is something that businesses don't want, as frequent (even yearly) updates become very expensive and awkward for them to manage. (Supporting the enterprise has always been one of Microsoft's strengths so I don't see them looking to upset the enterprise. Especially as one of the reasons for this initial synchronization and a lot of the upcoming changes are to support enterprise scenarios.)
Forcing updates to multiple systems to be permanently tied together just causes more work and slows releases. Microsoft know this and we've seen lots of products which were historically always released together change to be released separately and more frequently over recent years. I trust they're smart enough to do the right thing here (whatever that may be).
Based on a leak reported yesterday (see here and here), it looks like I was wrong and I have 3 reactions.
I'm excited.
In many ways this is more than I could have hoped for. There are loads of cool features previously announced for Windows 8 that I would love to see and be able to use on the phone. And yes, also some I wouldn't.
I'm not counting my chickens yet.
There are still no public confirmation, details or timelines for any of this. I also wouldn't be surprised if we didn't see a greater similarity with Silverlight 5 than with WinRT in the short term.
I'm a bit nervous.
What will it mean for things going forward? (If advances in both platforms are to be kept in sync in the future.)
In the mobile space the market demands yearly updates. (Just consider the reaction when there was no iPhone 5 announced last year.--The 4S was considered by most as a disappointing stop gap to whatever comes next.)
On the desktop this (yearly frequency of updates) hasn't been seen in the past and is something that businesses don't want, as frequent (even yearly) updates become very expensive and awkward for them to manage. (Supporting the enterprise has always been one of Microsoft's strengths so I don't see them looking to upset the enterprise. Especially as one of the reasons for this initial synchronization and a lot of the upcoming changes are to support enterprise scenarios.)
Forcing updates to multiple systems to be permanently tied together just causes more work and slows releases. Microsoft know this and we've seen lots of products which were historically always released together change to be released separately and more frequently over recent years. I trust they're smart enough to do the right thing here (whatever that may be).
Don't use the OnSelectionChanged event to trigger navigation #wp7dev
It's a comon practice. Hey, it' even in some of the default templates.
But don't attach an event handler to the `OnSelectionChanged` (or equivalent `OnSelectedItemChanged`) events and then use this as the trigger for starting navigation.
This is typically used when there are options displayed in a list[box] and the user can select an item to navigate to the appropriate page. It's also really common for such a list to be large enough that the user must scroll to see all the items. Therein lies the problem. It's common for the first part of the swipe gesture (intended to scroll the list) to be interpreted as a selection. This then causes the app to navigate to the item that was touched while swiping, not the one the user actually wanted.
Instead, add a handler for the `Tap` event of the individual item. This way you don't risk confusing the gestures.
This way you'll have an app that behaves as the user expects. This is definitely a step towards having happier users which will hopefully help lead to you havinng more of them.
But don't attach an event handler to the `OnSelectionChanged` (or equivalent `OnSelectedItemChanged`) events and then use this as the trigger for starting navigation.
This is typically used when there are options displayed in a list[box] and the user can select an item to navigate to the appropriate page. It's also really common for such a list to be large enough that the user must scroll to see all the items. Therein lies the problem. It's common for the first part of the swipe gesture (intended to scroll the list) to be interpreted as a selection. This then causes the app to navigate to the item that was touched while swiping, not the one the user actually wanted.
Instead, add a handler for the `Tap` event of the individual item. This way you don't risk confusing the gestures.
This way you'll have an app that behaves as the user expects. This is definitely a step towards having happier users which will hopefully help lead to you havinng more of them.
Wednesday, February 01, 2012
I'm heading to Scotland to talk about #WP7Dev and "thinking mobile and beyond""
On the 21st, 22nd and 23rd of February, I'm heading north of the border to talk at user groups in Edinburgh, Dundee and Aberdeen.
If you're anywhere near and can make it, it'd be great to see you there. Or if you know someone nearby then please spread the word.
Yes, this is further than I've ever travelled to present before but I thought the opportunity to feel like a rock star, jet setting, developer/presenter was too much to miss out on. (At least this once.)
- Tuesday 21 February
- Wednesday 22nd February
- Thursday 23rd February
If you're anywhere near and can make it, it'd be great to see you there. Or if you know someone nearby then please spread the word.
Yes, this is further than I've ever travelled to present before but I thought the opportunity to feel like a rock star, jet setting, developer/presenter was too much to miss out on. (At least this once.)
Tuesday, December 13, 2011
The absolutely most important thing developers need to know about #Windows8
Forget Metro.
Forget tablets.
Forget WinRT.
Forget building apps in HTML/JS.
The absolutely most important thing developers (and anyone involved in the creation, design, sale, marketing, etc. of software) need to know is based on the fact that it is designed to be used on multiple devices.
Which leads to my point. People (your users/customers) are starting to use a wider variety of devices. And not only that, they are using them in different/new ways and this requires that the applications which run on them work/behave in different/new ways too.
Windows 8 tells "desktop" developers they MUST start thinking about developing for multiple devices and uses.
Whether it's a 10" tablet, a 15" laptop or a desktop PC with a 32" screen, these different form factors encourage use in different ways. But that's just an example of where we'll initially see Win8. There's also the even smaller tablet and phone devices. There's table based interfaces. There's wall sized interfaces. There's also many more we probably can't even begin to imagine yet. Even in Sci-Fi films. But one day, probably sooner than you think, we'll be building apps to run on such devices.
If you've heard me talk at any point in the last 4 years or so, you will have inevitably/hopefully heard me say that all developers should start learning about developing for mobile NOW as it will help prepare you for all the plethora of devices they'll inevitably end up building for in the future.
If you're a developer who currently only targets the laptop/desktop environment usage scenario whether for APPS OR WEBSITES and you care about how your skills will meet the future demands of the marketplace. I can't recommend strongly enough that you should go and learn about HOW developing for mobile is different.
I'm not saying you should go and learn how to build apps for Windows Phone, iPhone or Android, etc. What you need to know is how apps designed for those platforms are different from ones that run on the "desktop".
If you have experience developing apps for the desktop environment you'll bring with you (whether you intend it or not) a number of assumptions and expectations about what your app should look like, how it should work and how people will use it. The good thing about mobile development is that it challenges all these common assumptions and so forces you to think differently.
Once you know how to challenge your thinking about these areas regarding mobile development you'll be prepared and ready to approach developing for other devices, form factors, etc. in a way which will help you create apps which work well on that platform.
In turn this will lead to apps which are easier (possible?) for your users/customers to use. Which can only be good for you/your company. Afterall, if people can't use your software they wont do so for long. This makes it much harder to get repeat business or referals.
Alternatively if your business is based on income from selling support contracts then you probably want (or need?) your software to be bad. So you should probably check out all the things you shouldn't be doing as it would only make your app better.
Side note.
You may try and argue that previously PC apps were used on PCs and laptops. But, seriously, can you show me the apps you have been building which allow for these (slightly) different environments. Thought not.
Forget tablets.
Forget WinRT.
Forget building apps in HTML/JS.
The absolutely most important thing developers (and anyone involved in the creation, design, sale, marketing, etc. of software) need to know is based on the fact that it is designed to be used on multiple devices.
Which leads to my point. People (your users/customers) are starting to use a wider variety of devices. And not only that, they are using them in different/new ways and this requires that the applications which run on them work/behave in different/new ways too.
Windows 8 tells "desktop" developers they MUST start thinking about developing for multiple devices and uses.
Whether it's a 10" tablet, a 15" laptop or a desktop PC with a 32" screen, these different form factors encourage use in different ways. But that's just an example of where we'll initially see Win8. There's also the even smaller tablet and phone devices. There's table based interfaces. There's wall sized interfaces. There's also many more we probably can't even begin to imagine yet. Even in Sci-Fi films. But one day, probably sooner than you think, we'll be building apps to run on such devices.
If you've heard me talk at any point in the last 4 years or so, you will have inevitably/hopefully heard me say that all developers should start learning about developing for mobile NOW as it will help prepare you for all the plethora of devices they'll inevitably end up building for in the future.
If you're a developer who currently only targets the laptop/desktop environment usage scenario whether for APPS OR WEBSITES and you care about how your skills will meet the future demands of the marketplace. I can't recommend strongly enough that you should go and learn about HOW developing for mobile is different.
I'm not saying you should go and learn how to build apps for Windows Phone, iPhone or Android, etc. What you need to know is how apps designed for those platforms are different from ones that run on the "desktop".
If you have experience developing apps for the desktop environment you'll bring with you (whether you intend it or not) a number of assumptions and expectations about what your app should look like, how it should work and how people will use it. The good thing about mobile development is that it challenges all these common assumptions and so forces you to think differently.
Once you know how to challenge your thinking about these areas regarding mobile development you'll be prepared and ready to approach developing for other devices, form factors, etc. in a way which will help you create apps which work well on that platform.
In turn this will lead to apps which are easier (possible?) for your users/customers to use. Which can only be good for you/your company. Afterall, if people can't use your software they wont do so for long. This makes it much harder to get repeat business or referals.
Alternatively if your business is based on income from selling support contracts then you probably want (or need?) your software to be bad. So you should probably check out all the things you shouldn't be doing as it would only make your app better.
Side note.
You may try and argue that previously PC apps were used on PCs and laptops. But, seriously, can you show me the apps you have been building which allow for these (slightly) different environments. Thought not.
Friday, December 09, 2011
Windows Phone 8 and WinRT
I've heard a lot of people claim that they think that the next major version of Windows Phone (which they assume will be called Windows Phone 8) will use WinRT as part of the phone's OS. I don't.
At this point I should state that even though I have spent a few months earlier this year working at Microsoft (in their Windows Phone Centre of Excellence). I do not have any insider knowledge of Windows Phone beyond what has already been publically released.
Here's why I don't think that the next version of Windows Phone (whether it's called 8 or "apollo" or anything else the internets may speculate at): Time!
WinRT is part of Windows 8 (if you weren't aware).
What's the timeline for the release of Win8?
We don't know, but I'm going to make a, hopefully, intelligent guess.
The only thing we know about it were announced back in September (at BUILD) when it was in the pre-alpha stage. Based on that and what we know from the time it's taken for previous Windows operating systems to be released, I think we'll be lucky to see it publically available before the end of 2012. There are some rumours that we may see a beta in early 2012 which sounds reasonable and ties in with what we might expect.
What about Windows Phone v.Next? (Which from now on I'll call WP8 to save typing.)
Again there is no public information on timelines for releases but we can make some informed decisions based on a knowledge of the "mobile space", the release schedule of other mobile operating systems and the timeframes over which WP 7.0 & 7.1/7.5 were released. I don't think it's unreasonable to expect to have details of WP8 announced in February, have an SDK released around April/May and have general availability/public rollout around September.
That means that, realistically, the details of WP8 need to be fairly locked down by February (if not several months before). At this time Win8 could still be in a very variable position. I don't see Microsoft letting WP8 dictate feature lockdown for Win8 (and it shouldn't). Similarly, Microsoft can't afford to delay WP8, possibly for many months, until Win8 is stable.
They're two separate (albeit related) operating systems which have their own requirements, uses, users and competitors and therefore require their own release schedules.
Any other arguments?
In a number of ways Windows Phone is still playing catch up to other, more mature or fully featured mobile operating systems. It's going to be better for Microsoft to spend time addressing (at least) some of these disparities and adding or refining features and functionality which will allow WP8 to compete in the mobile arena than doing things that improve parity with a desktop operating system.
Yes, sharing development resources across multiple platforms is a great thing but it's more important that the individual platforms are strong enough to compete individually. There will never be a situation where the exact same codebase will (or should!?) run on both platforms though, so perfect synchronicity is an unnecessary (and impossible?) goal.
Additionally we need to consider what WinRT actually includes.
WinRT is an alternative/update to Win32 which provides a set of APIs which can be used/consumed in the same way as the APIs of .net. Having to do things with Win32 on the desktop can be less than ideal or so difficult as to lead many/most to not even try. On the phone this doesn't matter. The only things you & I (us mere mortals - not Microsoft, operators or OEMs) can do on the phone are in managed code through a .net API (the compact framework - v 3.7). We don't have to address issues about things which are hard or impossible to do with Win32 APIs. It's not that the functionality isn't available. The whole issue is irrelevant.
Yes there are some things in WinRT that it would be nice to see in Windows Phone but I hope they can be migrated to WP without needing to make a major change to the underlying OS.
Making a dramatic change to Windows Phone such that it had anything more than a trivial impact on the upgrade path of 7.X apps would be a big issue and upset a lot of WP7 developers. At a time when Microsoft are still trying to persuade companies/developers of the merits of building apps for WP adding unnecessary hurdles to upgrade paths would not, in my opinion, be a smart move.
At this point I should state that even though I have spent a few months earlier this year working at Microsoft (in their Windows Phone Centre of Excellence). I do not have any insider knowledge of Windows Phone beyond what has already been publically released.
Here's why I don't think that the next version of Windows Phone (whether it's called 8 or "apollo" or anything else the internets may speculate at): Time!
WinRT is part of Windows 8 (if you weren't aware).
What's the timeline for the release of Win8?
We don't know, but I'm going to make a, hopefully, intelligent guess.
The only thing we know about it were announced back in September (at BUILD) when it was in the pre-alpha stage. Based on that and what we know from the time it's taken for previous Windows operating systems to be released, I think we'll be lucky to see it publically available before the end of 2012. There are some rumours that we may see a beta in early 2012 which sounds reasonable and ties in with what we might expect.
What about Windows Phone v.Next? (Which from now on I'll call WP8 to save typing.)
Again there is no public information on timelines for releases but we can make some informed decisions based on a knowledge of the "mobile space", the release schedule of other mobile operating systems and the timeframes over which WP 7.0 & 7.1/7.5 were released. I don't think it's unreasonable to expect to have details of WP8 announced in February, have an SDK released around April/May and have general availability/public rollout around September.
That means that, realistically, the details of WP8 need to be fairly locked down by February (if not several months before). At this time Win8 could still be in a very variable position. I don't see Microsoft letting WP8 dictate feature lockdown for Win8 (and it shouldn't). Similarly, Microsoft can't afford to delay WP8, possibly for many months, until Win8 is stable.
They're two separate (albeit related) operating systems which have their own requirements, uses, users and competitors and therefore require their own release schedules.
Any other arguments?
In a number of ways Windows Phone is still playing catch up to other, more mature or fully featured mobile operating systems. It's going to be better for Microsoft to spend time addressing (at least) some of these disparities and adding or refining features and functionality which will allow WP8 to compete in the mobile arena than doing things that improve parity with a desktop operating system.
Yes, sharing development resources across multiple platforms is a great thing but it's more important that the individual platforms are strong enough to compete individually. There will never be a situation where the exact same codebase will (or should!?) run on both platforms though, so perfect synchronicity is an unnecessary (and impossible?) goal.
Additionally we need to consider what WinRT actually includes.
WinRT is an alternative/update to Win32 which provides a set of APIs which can be used/consumed in the same way as the APIs of .net. Having to do things with Win32 on the desktop can be less than ideal or so difficult as to lead many/most to not even try. On the phone this doesn't matter. The only things you & I (us mere mortals - not Microsoft, operators or OEMs) can do on the phone are in managed code through a .net API (the compact framework - v 3.7). We don't have to address issues about things which are hard or impossible to do with Win32 APIs. It's not that the functionality isn't available. The whole issue is irrelevant.
Yes there are some things in WinRT that it would be nice to see in Windows Phone but I hope they can be migrated to WP without needing to make a major change to the underlying OS.
Making a dramatic change to Windows Phone such that it had anything more than a trivial impact on the upgrade path of 7.X apps would be a big issue and upset a lot of WP7 developers. At a time when Microsoft are still trying to persuade companies/developers of the merits of building apps for WP adding unnecessary hurdles to upgrade paths would not, in my opinion, be a smart move.
Monday, November 07, 2011
Recorded live at Nokia World 2011
On the 2nd day of Nokia World I was invited to be part of the audience at the recording of the 361 Degrees podcast.
Allegedly, the audience was made up of "bloggers and mobile gurus". As I'm not much of a blogger that must, finally, make me a "mobile guru"! ;) (maybe it was all the other mobile guru's I was in the presence of that made me sound so nervous.)
Listen at http://audioboo.fm/boos/534345-s02-e02-361-live-at-nokia-world-2-of-2
Nando's in London app
Ok, this was a somewhat tounge in cheek creation but it still has potential value, hopefully, to lots of people. As ever, comments, feedback, etc. appreciated ;)
Wednesday, October 26, 2011
Nokia World Keynote Buzzword Bingo
I had the idea for this but completely forgot. If I'd remembered/had more time I'd have put this all in a proper bingo board format. Feel free to do that yourself if you so wish.
Regardless, here, in no particular order, are a few words I think we may be hearing quite a lot today:
And many more besides too, I'm sure.
Regardless, here, in no particular order, are a few words I think we may be hearing quite a lot today:
- ecosystem
- mango
- everywhere
- local
- payment
- monetization
- reach
- efficiency
- Qt
- beautiful
- opportunities
- global
- new
- smarter
- partnership
- millions
- services
- maps
- apps
- community
- developers
- knowledge
- future
- devices
- metro
- pure
- future
- alpha
- marketplace
- hub
- personal
- cloud
And many more besides too, I'm sure.
Wednesday, October 19, 2011
The popularity of TombstoneHelper
A few weeks ago, as you're probably aware, Justin Angel published an analysis of the apps available in the marketplace which included a breakdown of 3rd party libraries actually in use.
Down at number 26, is my Tombstoner helper library, which was apparently being used in 307 (or about 1% of all) apps.
It is of course very flattering to know that it is being used so widely and helping developers improve their apps. What I find interesting is how it compares with some of the other libraries available. There are a number of other libraries which have much higher download numbers (both in Codeplex & NuGet) and yet are much lower in the list. This shows that you can't take download numbers to strongly. It's actual usage that counts.
The sad thing is that with the forthcoming encryption of XAPs such analysis of the marketplace in the future will not be possible. :(
BTW. I am still planning on another version of the library. Stay tuned.
Down at number 26, is my Tombstoner helper library, which was apparently being used in 307 (or about 1% of all) apps.
It is of course very flattering to know that it is being used so widely and helping developers improve their apps. What I find interesting is how it compares with some of the other libraries available. There are a number of other libraries which have much higher download numbers (both in Codeplex & NuGet) and yet are much lower in the list. This shows that you can't take download numbers to strongly. It's actual usage that counts.
The sad thing is that with the forthcoming encryption of XAPs such analysis of the marketplace in the future will not be possible. :(
BTW. I am still planning on another version of the library. Stay tuned.
Friday, October 07, 2011
How to stop toolkit transitions affecting performance
I was recently debugging a performance issue in an app and couldn't work out why the fill rate was so high based on what was on the page.
It was so high (>3.2) that it was definitely having a negative effect on performance. Depending on who you talk to, you'll be told that the fill rate should be below either 2.5 or 3.0 to avoid affecting performance. In my experience, I've noticed performance impacted above a fill rate of 2.0 so I always aim to keep it below this.
The only exception I'll accept is a panorama with a large background image.
If you're not familiar with the Fill Rate it represents the number of pages worth of pixels that are painted in each frame. For more information on this and other performance counters see MSDN.
After much digging and as you may have guessed from the title of this post, I identified that the fill rate was higher on the pages in apps that were using the Transitions from the Silverlight Toolkit.
In fact, the culprit is the TransitionFrame.
Here's the fill rate on a simple page which uses the default PhoneApplicationFrame:
The fill rate is the number at the bottom (00.0967).
If we switch over the using a TransitionFrame
The fact the fill rate is (almost) a full page made me suspect the TransitionFrame was the culprit.
If you look at the source (and scroll down a bit) you'll see that it is:
The striking thing about this is that it's painting the colour that is the same as the background behind it anyway. If the selected theme has a dark background it's painting black on top of black. Or, if the theme has a light background it paints white on white.
If we combine this knowledge of the unnecessary work the TransitionFrame is doing with the fact that anything transparent doesn't contribute to the fill rate a solution presents itself to us. We just need to make the background of the TransitionFrame transparent instead:
If you're using the transition effects from the toolkit you should definitely look to make this change to your code and create a more performant UI for your app.
It was so high (>3.2) that it was definitely having a negative effect on performance. Depending on who you talk to, you'll be told that the fill rate should be below either 2.5 or 3.0 to avoid affecting performance. In my experience, I've noticed performance impacted above a fill rate of 2.0 so I always aim to keep it below this.
The only exception I'll accept is a panorama with a large background image.
If you're not familiar with the Fill Rate it represents the number of pages worth of pixels that are painted in each frame. For more information on this and other performance counters see MSDN.
After much digging and as you may have guessed from the title of this post, I identified that the fill rate was higher on the pages in apps that were using the Transitions from the Silverlight Toolkit.
In fact, the culprit is the TransitionFrame.
Here's the fill rate on a simple page which uses the default PhoneApplicationFrame:
If we switch over the using a TransitionFrame
//RootFrame = new PhoneApplicationFrame();
RootFrame = new TransitionFrame();
The fill rate now jumps up dramatically (to 00.9999 - this isn't quite 1 as the SystemTray is enabled) with no visual clue as to why. Yes, a whole page of pixels is painted for no visual difference.
If you look at the source (and scroll down a bit) you'll see that it is:
Yes, that's right the frame is painted with the background brush colour with every frame, as well as the page being painted.The striking thing about this is that it's painting the colour that is the same as the background behind it anyway. If the selected theme has a dark background it's painting black on top of black. Or, if the theme has a light background it paints white on white.
If we combine this knowledge of the unnecessary work the TransitionFrame is doing with the fact that anything transparent doesn't contribute to the fill rate a solution presents itself to us. We just need to make the background of the TransitionFrame transparent instead:
//RootFrame = new PhoneApplicationFrame();
RootFrame = new TransitionFrame
{
Background = new SolidColorBrush(Colors.Transparent)
};
And with this change the fill rate falls back down to it's previous level:
Wednesday, September 28, 2011
Renewing developer phone registration
I share this in the hope that it will help out someone else in the future.
Today I was surprised to see that when I tried to run an app on one of my devices I got a message saying that the app had been revoked and I must uninstall it.
This surprised me as it was an app that is still in development.
After a bit of poking around I discovered that the developer registration for the device had expired. Yes, when you "unlock" a phone for development it only stays in that state for a year.
Dealing with this was simply a case of removing the device from the "my registered devices" list in app hub and then unlocking it again. I initially tried to unlock it again without first removing it from the list but this failed to work, despite the tool saying that unlock had been successful.
As we approach a time when devices became available to all there are likely to be lots of developers who start to see the same situation as they too will have had [unlocked] devices for a year.
Please also note that when the unlock has expired it also not possible to deploy to a device from within Visual Studio (or Blend) and you'll see a message about checking the device is developer unlocked.
Today I was surprised to see that when I tried to run an app on one of my devices I got a message saying that the app had been revoked and I must uninstall it.
This surprised me as it was an app that is still in development.
After a bit of poking around I discovered that the developer registration for the device had expired. Yes, when you "unlock" a phone for development it only stays in that state for a year.
Dealing with this was simply a case of removing the device from the "my registered devices" list in app hub and then unlocking it again. I initially tried to unlock it again without first removing it from the list but this failed to work, despite the tool saying that unlock had been successful.
As we approach a time when devices became available to all there are likely to be lots of developers who start to see the same situation as they too will have had [unlocked] devices for a year.
Please also note that when the unlock has expired it also not possible to deploy to a device from within Visual Studio (or Blend) and you'll see a message about checking the device is developer unlocked.
Tombstone Helper v2.5 now available
Just a quick note that version 2.5 of my TombstoneHelper library is now available. It fixes an issue where a textbox which had previously contained text which included a colon would throw an exception when restoring.
You can get it from nuget and codeplex.
Version 3 will hopefully be available soon. It will include support for ViewModels and the Silverlight Tookit.
You can get it from nuget and codeplex.
Version 3 will hopefully be available soon. It will include support for ViewModels and the Silverlight Tookit.
Wednesday, September 14, 2011
Windows 8 does not use Metro!
"Ooh, ooh, ooh. Windows 8 looks just like Windows Phone 7 - it's metro too."
No.
Stop.
Wait.
Metro is the name of the design language for Windows Phone 7. If you've been paying attention, everyone (who's "on message") has been saying that Windows 8 is "metro-like" or "metro inspired" or the apps are in a "metro style".
Those suffixes are important.
This isn't just me being picky. There is an important difference to be aware of.
I've seen lots of WP7 apps which don't quite "get" Metro and as a consequence don't quite feel right or worse still feel clunky or awkward or not as intuitive as a good app should or worse still don't work as expected, or like most other (including the built in) apps on the phone.
If you approach Windows 8 app development assumming it'll be exactly the same as Windows Phone 7 then you risk making a variation of those same mistakes and creating more sub-standard apps. - The world already has more than enough of them. We don't need any more. Thank you.
There are aspects of the Metro design language which are specific to the phone context:
"Focus on the individual"
"It's Personal"
"Relevant ... to your location"
These are primarily phone based characteristics.
I say this is important because I don't want you to get carried away and start thinking that you should recompile your phone apps for Windows 8 just because, in principle, it's simple to do, and just because you can.
Hopefully you've designed and built your Windows Phone 7 app to be the best it can be and to be perfectly suited for use on the phone and make the best of the platform and the screen real estate available to you. - Such an app doesn't necessarily directly translate to running on everything from a 7" tablet to a 30"+ PC monitor.
So what's different on Windows 8 when it comes to metro-like/style/inspired apps?
Expect more information about creating metro style apps to be released and made available over the coming months and be sure to check out the videos from BUILD on Channel 9. Especially the XAML related sessions (as identified by Tim Heuer).
No.
Stop.
Wait.
Metro is the name of the design language for Windows Phone 7. If you've been paying attention, everyone (who's "on message") has been saying that Windows 8 is "metro-like" or "metro inspired" or the apps are in a "metro style".
Those suffixes are important.
This isn't just me being picky. There is an important difference to be aware of.
I've seen lots of WP7 apps which don't quite "get" Metro and as a consequence don't quite feel right or worse still feel clunky or awkward or not as intuitive as a good app should or worse still don't work as expected, or like most other (including the built in) apps on the phone.
If you approach Windows 8 app development assumming it'll be exactly the same as Windows Phone 7 then you risk making a variation of those same mistakes and creating more sub-standard apps. - The world already has more than enough of them. We don't need any more. Thank you.
There are aspects of the Metro design language which are specific to the phone context:
"Focus on the individual"
"It's Personal"
"Relevant ... to your location"
These are primarily phone based characteristics.
I say this is important because I don't want you to get carried away and start thinking that you should recompile your phone apps for Windows 8 just because, in principle, it's simple to do, and just because you can.
Hopefully you've designed and built your Windows Phone 7 app to be the best it can be and to be perfectly suited for use on the phone and make the best of the platform and the screen real estate available to you. - Such an app doesn't necessarily directly translate to running on everything from a 7" tablet to a 30"+ PC monitor.
So what's different on Windows 8 when it comes to metro-like/style/inspired apps?
- Think "touch-first" but don't rule out and remember to support Mouse (& keyboard) Events.
- Embrace the touch language and don't deviate from it.
- Be prepared to scale across different screens.
- The experience should transcend the process.
- Take pride in craftsmanship
- Do more with less
- "Win as one"
Expect more information about creating metro style apps to be released and made available over the coming months and be sure to check out the videos from BUILD on Channel 9. Especially the XAML related sessions (as identified by Tim Heuer).
Tuesday, September 13, 2011
Windows Phone 7 and Windows 8
Lots of details were announced about Windows 8 today at the BUILD conference.
One thing I heard quite a bit was "if you're a Windows Phone 7 developer you're now a Windows 8 developer too".
This is because you can use the same development tools & languages and share a design language heritage.
You may recognise this as being very similar to a phrase that was used a lot last year: "If you're a Silverlight developer your now a Windows Phone 7 developer." (Because both use the same develompent tools and languages.)
That statement was as wrong then as it is now!
They are not identical and so the statements aren't true.
It's like saying "if you know how to drive a motorbike you know how to drive a bus".
If you can drive a motorbike there are lots of things you'll have learnt that will be useful when it comes to learning how to drive a bus but that there are (I imagine and hope-I don't drive either) lots of important differences too.
If you've got some experience developing for Windows Phone 7 (or Silverlight) then it'll certainly help when you want to start building for Windows 8 but don't expect it to be exactly the same.
Also, don't expect any WP7 apps to run as is on Win8. At the very minimum you'll need to recompile but you should also look to make appropriate use of a UI (& UX) which is more appropriate to Win8. And yes, I totally expect this to mean you'll likely need multiple UIs to support the plethora of devices which Win8 will run on.
I'll probably write more on this in the future, when more Win8 details are available but don't expect this fundamental principle to change.
One thing I heard quite a bit was "if you're a Windows Phone 7 developer you're now a Windows 8 developer too".
This is because you can use the same development tools & languages and share a design language heritage.
You may recognise this as being very similar to a phrase that was used a lot last year: "If you're a Silverlight developer your now a Windows Phone 7 developer." (Because both use the same develompent tools and languages.)
That statement was as wrong then as it is now!
They are not identical and so the statements aren't true.
It's like saying "if you know how to drive a motorbike you know how to drive a bus".
If you can drive a motorbike there are lots of things you'll have learnt that will be useful when it comes to learning how to drive a bus but that there are (I imagine and hope-I don't drive either) lots of important differences too.
If you've got some experience developing for Windows Phone 7 (or Silverlight) then it'll certainly help when you want to start building for Windows 8 but don't expect it to be exactly the same.
Also, don't expect any WP7 apps to run as is on Win8. At the very minimum you'll need to recompile but you should also look to make appropriate use of a UI (& UX) which is more appropriate to Win8. And yes, I totally expect this to mean you'll likely need multiple UIs to support the plethora of devices which Win8 will run on.
I'll probably write more on this in the future, when more Win8 details are available but don't expect this fundamental principle to change.
Friday, August 26, 2011
Improvements in Music & Video hub integration #wp7dev
Back in January I wrote about some of the Gotchas when integrating with the Music and Video Hub.
With the latest/mango update to Windows Phone 7 there are a couple of changes/improvements to note.
MediaHistoryItem.Source
This is property still exists and is still not used for anything but it no longer needs to be set. (Even thought the examples on MSDN still show it being set.)
ImageStream / MaxImageSize
Previously this was a tiny 16kb and it made it impossible to show high quality images (of album artwork or packshots) at 358x358 (or 173x173) pixels.
Good news!
This has been dramatically increased to a much more practical 75kb.
Disappointingly this still isn't clearly documented in MSDN and the page on How to: Integrate with the Music and Videos Hub for Windows Phone (only lists the physical image dimensions, not the size on disk) and we have to rely on an exception to know what the limit is:
Also disappointingly, that page doesn't allow for community content. :(
I'm sure there's a good reason that not every page supports community content but it would be nice if they did because I'd add some useful information there is I could. I suspect more people would read that there than this here.
With the latest/mango update to Windows Phone 7 there are a couple of changes/improvements to note.
MediaHistoryItem.Source
This is property still exists and is still not used for anything but it no longer needs to be set. (Even thought the examples on MSDN still show it being set.)
ImageStream / MaxImageSize
Previously this was a tiny 16kb and it made it impossible to show high quality images (of album artwork or packshots) at 358x358 (or 173x173) pixels.
Good news!
This has been dramatically increased to a much more practical 75kb.
Disappointingly this still isn't clearly documented in MSDN and the page on How to: Integrate with the Music and Videos Hub for Windows Phone (only lists the physical image dimensions, not the size on disk) and we have to rely on an exception to know what the limit is:
Also disappointingly, that page doesn't allow for community content. :(
I'm sure there's a good reason that not every page supports community content but it would be nice if they did because I'd add some useful information there is I could. I suspect more people would read that there than this here.
Wednesday, August 24, 2011
#wp7dev NoDo Tools won't deploy to Pre-Mango phone after Zune upgrade to 4.8
This morning I had an issue where after updating the desktop Zune software to the new version (4.8) Visual Studio (running the NoDo development tools*) became unable to deploy or debug apps running on a phone. This was the case with a phone running a Nodo version (specifically 7.0.7392) and another phone running a pre-NoDo build.
Obviously, losing the ability to deploy to and test on an actual device was of concern. After a few worried minutes involving restarting the software (Zune & Visual Studio) and rebooting the phone we resolved this issue by rebooting the PC. Panic over.
Hopefully knowing that a reboot may be required may save someone else a bit of time.
* I have a separate machine running the Mango SDK RC which wasn't affected.
Obviously, losing the ability to deploy to and test on an actual device was of concern. After a few worried minutes involving restarting the software (Zune & Visual Studio) and rebooting the phone we resolved this issue by rebooting the PC. Panic over.
Hopefully knowing that a reboot may be required may save someone else a bit of time.
* I have a separate machine running the Mango SDK RC which wasn't affected.
Sunday, August 14, 2011
Catching an uncatchable exception
Recently we had an interesting issue in a Windows Phone 7 app I was working on that proved awkward to address. The code in question related to playing a video via the MediaPlayerLauncher.
The code in question looked like this:
"Not allowed to call Show() when a navigation is in progress"
As a first we tried wrapping the above code in a simple try..catch block to handle the unhandled exception:
Next we tried to determine if navigation was in progress by comparing the CurrentSource and Source properties of the page but that didn't work either.
Then I had an idea.
What if we split the separated the generation of the object and the calling of the method?:
I'm a big fan of not writing any code I don't have to and so having to write more than I think should be absolutely necessary here is a little bit disappointing. It's good to know, however that this isn't an exception I can't do anything about.
In this situation I can happily ignore this exception as if the user has hit back shortly after trying to lauch the video it's reasonable to assume they don't actually want to watch it.
The code in question looked like this:
new MediaPlayerLauncher { Media = fileUri }
.Show();
The issue we had was that if the user triggered the launching of the MediaPlayer and then very quickly hit the back button then they could get the following error.
"Not allowed to call Show() when a navigation is in progress"
As a first we tried wrapping the above code in a simple try..catch block to handle the unhandled exception:
try
{
new MediaPlayerLauncher { Media = fileUri }
.Show();
}
catch (Exception exc)
{
...
}
But this didn't work.
Next we tried to determine if navigation was in progress by comparing the CurrentSource and Source properties of the page but that didn't work either.
Then I had an idea.
What if we split the separated the generation of the object and the calling of the method?:
var mediaLauncher = new MediaPlayerLauncher();
mediaLauncher.Media = fileUri;
try
{
mediaLauncher.Show();
}
catch (InvalidOperationException exc)
{
...
}
This did allow us to catch and handle the exception. Yay!
I'm a big fan of not writing any code I don't have to and so having to write more than I think should be absolutely necessary here is a little bit disappointing. It's good to know, however that this isn't an exception I can't do anything about.
In this situation I can happily ignore this exception as if the user has hit back shortly after trying to lauch the video it's reasonable to assume they don't actually want to watch it.
Microsoft and me. A disclaimer
If you didn't know, I'm a freelance developer. If you're looking for someone to do some mobile development, particularly on Windows Phone 7, then please get in touch.
Recently I've been doing some work for Microsoft. They're keen that I make it clear that anything I say on this blog, or via my Twitter account (@mrlacey) is entirely my own thought, opinion, etc.
Nothing I say here is the opinions of anyone but myself.
As far as I am concerned there is no conflict of interest with my continuing to run the Windows Phone User Group and do a short term contract with Microsoft. The group continues to remain an independent group. If you have any concerns over this then please let me know.
Recently I've been doing some work for Microsoft. They're keen that I make it clear that anything I say on this blog, or via my Twitter account (@mrlacey) is entirely my own thought, opinion, etc.
Nothing I say here is the opinions of anyone but myself.
As far as I am concerned there is no conflict of interest with my continuing to run the Windows Phone User Group and do a short term contract with Microsoft. The group continues to remain an independent group. If you have any concerns over this then please let me know.
Subscribe to:
Posts (Atom)