Migrating websites between Windows Azure subscriptions

Ages ago I set up an Azure 3-month trial subscription. More recently (although still over a year ago - I can't remember exactly when) I set up my MSDN subscription. I've added various services to both.
With the recent restructuring of the MSDN Azure benefits I reviewed how much I was spending on the different subscriptions and discovered I would be better off by moving the services that were still on the trial subscription to the MSDN one.

Unfortunately it wasn't straight forward.

I moved most services over but there is no way to migrate websites or mobile services yourself.

It is necessary to make a support request to ask for the services to be moved between subscriptions.

After much back and forth I was informed that they couldn't move the websites.

That's right.
You can't move websites between subscriptions yourself.
Microsoft can't move websites between subscriptions, if the destination subscription already contains websites, without introducing problems: (emphasis and grammar theirs)

"Please note that, currently we have issues while migration services, if the source and destination subscriptions have websites and the migration leads the websites to an inconsistent state."

So what's the lesson here?
If you're wanting to get off a trial subscription (maybe because you're just starting to use an MSDN subscription) be aware of this limitation. Move (or have Microsoft move) any websites before you add any more to the new subscription yourself.

Because of the above I was forced to delete the websites from the old subscription and then recreate them again on the new one.

Hope this information helps someone avoid having to delete and recreate their websites.

What are the essentials I need to know for Windows 8.1?

Windows 8.1 is coming.
Masses of information was released after BUILD but there's too much of it.

Where's the quick guide for developers who have already built for Windows8 and now need to look to update those apps for the changes in 8.1?

In the situation of having 8.0 apps in the store, how do I quickly get them ready for 8.1 with minimal fuss?

At the moment I know I need to do the following, but is there anything else to do too?

• How to support the new/different tile formats/layouts?
• How to manage the changes around having a separate snapped view? 

• How to do this and still support 8.0? Do I need two version of the app or one that can do both?

• What else?

I haven't got time to go through all the masses of information that's been released how do I do this quickly?

App studio and so called "crapps"

You've probably heard, Microsoft recently released Windows Phone App Studio as a way to create Windows Phone apps from a template via a wizard. It's very similar to ZipApp which was created by Microsoft and Nokia (in the UK) earlier this year but that generates both a Windows 8 and a Windows Phone 8 app.

App Studio has been promoted as having two benefits or target uses.
1. It allows anyone to make a simple app for sharing with a few friends or family.
2. It allows developers a jump start in creating an app.

Anyway, there is always a discussion about the value of simple apps based on a template. Particularly if they are based on a single RSS feed.

As this is the sort of app that can easily be created with App Studio I thought I'd have a look at what it does when asked to create an app based on a single RSS feed.
I've also built a few apps based on a single RSS feed and wanted to see how what can be done with App Studio compares with what I can do.
Obviously I wouldn't classify the apps I've made as "crapp", rather they're examples of how to make a valid, useful app that supports a website by providing notification of new content and offline support.

I set out to get as close as I could to what I had created with App Studio as a way to see how good it is and if it was capable of creating something useful for people who'd rather use a tool than pay a professional developer.

Yes, I know that App Studio is still in beta and is likely to be further improved so it may be unfair to review it just yet. Maybe I'll review again it at a future point.

I only used the online wizard and didn't modify the generated code in any way. By doing so I was able to create a simple feed reader with a few advanced WP8 features. 
However, it was far from being ready for the store, let alone being a quality app.

My issues with what was created

• The app must support a wide tile (even if there is no value in doing so)
• The main tile must have a title (even if the image on the tile includes the app name/text)
• The main tile must have static content on the back.
• Some of the colors can be changed but not all of them. This means that it's not possible to make a theme agnostic app.
• Some of the header text can be set to an empty string but the space on the page is still reserved for that text which means that if I don't want the header shown there will be a big space on screen.
• Titles are never wrapped so if the RSS feed includes an article with a long title that title will never be fully visible. Headlines and titles are normally important. They encourage the user to read the full text so this is a big issue.
• The main page of the generated app is a panorama with only one item in it. This is a bad practice as it is a poor use of the control and ends up in much wasted space and a header which can't be fully appreciated.
• The margins and spacing within the app are wrong. They are inconsistent within the app and do not match the defacto, and recommended, standards of the platform.
• If the RSS feed is from a Wordpress blog (and there are more than a few of them around) then it doesn't pick up the author of an item.
• The full text of an item isn't retrieved/displayed in the app. This means that the user must click through to view the full text in the browser.
• Images from within the text are not displayed.
• The app supports speech to text to read an article. Unfortunately there's no way to stop reading once it has been started and if the speak button is tapped twice then the reading of the article is done twice.
• While it is possible to share an article via the sharing task but no way to share via SMS or email. Both of which are highly recommended as a sharing options to have in an app.
• There is no caching of information or offline support! - Yes really! In this day and age, the most basic and essential of requirements for a mobile application, one that is used in an inconsistently connected manner, isn't supported by the app. :(
• The "live" tile is never updated. So it's not really live.
• It's possible to pin an item. But if you tap on that pin when there is no network connection then the app crashes. Yes, in a "it won't pass certification" kind of way.
• The app includes the ability to set a preconfigured image as the lock screen image. But that image is never updated and can't be modified or updated when new content is loaded.
• The app can show lock screen notifications but this is only the hardcoded text set on the backof the tile when the app is created and is never changed.
• The app include the ability to show lock screen status but has no icon configured and is completely pointless without an iconic tile. I had a flip tile. The main tile is never updated so the point of it being used to provide a notification on the lockscreen is worthless.
• The app includes a splash screen. But it should be able to load fast enough to not need one. That one is there, and not even optional, shows a poorly optimised app that takes longer to start than it need.
• The generated XAP is 2.56MB. For a simple RSS reader! A large part of this is due to the inclusion of a lot of third party libraries which aren't used by this app. A bit of selective compilation wouldn't go amiss.
• And probably more...

Of course some of these issues may be considered as minor and are easy to fix by modifying the generated code.
My concern is that people see the app/code that is generated and, as it comes from Microsoft, assume that it is good and an example of the quality of apps that people should be producing.
Let's hope that anyone using the generator at the moment takes the time to modify the generated code accordingly.
Let's also hope that the App Studio is improved to address some of the above issues too.

Faster JSON serialization with ServiceStack.Text

I've been using JSON.Net to serialize objects to and from JSON for years.

However, ever since I heard that ServiceStack had a faster JSON serializer I've wanted to try it.
After all, speed is important, especially on a mobile devices, and if I can make my code run faster by just swapping out one third party library for another then that's a simple decision.

Today I finally got around to trying it and to do so I built a console app so I could put the two methods side by side.


Look both methods are very similar. And as I rarely do anything more complicated with JSON than just serialize or deserialize this is great.

Obviously the above isn't enough for me to prove that it's faster. I'm just trusting the benchmark testing done by others.

It's also a smaller DLL so it will reduce the overall XAP size and download time. Plus app load time too. :)

My only slight reservation is that ServiceStack doesn't give me the debugging assistance I get with Json.Net. Maybe I'll look to just use Json.Net in the debug build if this becomes an issue.

If you're going to truncate text...

I have mobile notifications set up on Twitter for when someone mentions me. (I'm @mrlacey by the way.)

The other day, I noticed this:

Notice the highlighted text. It seems to suggest an account name that starts with an "r". That's odd I thought. None of my twitter accounts start with an "r".
"I wonder what account it's from? I know, I'll look at the full message and see"

Hmmmm!?

If you're going to truncate text in your app, I'd recommend doing a better job of it than this.

Preparing for 1080P screens in GDR3

Apparently there's something called GDR3 coming to Windows Phone 8 at some point in the future.
Allegedly it will include support for devices with 1080P screens.

As developers, is there anything we can do to be prepared for working with such devices?

1080P is 1.5 times larger (in both dimensions) than 720P.

This should make it really easy to support such devices. You just design and develop for them in the same way as for 720P (and everything else-probably) and let the autoscaler take care of everything else.
I expect that the SDK will also be updated to add appropriate emulator and designer support too.

If you want, or need, to use different images (or other resources) at different sizes, you can handle this in the same way as you would at the moment. (MSDN article explaining how)

So what can or should developers do now to be prepared for a future new screen size?

Nothing yet, just be prepared to possibly add larger sized images-if you want/need them.
Plus expect to have to test on more devices in future too.

mice, scrollbars and lazy loading don't mix

If you're designing for a platform that allows user input in multiple forms you must account for all the forms of user input at each time.

Let's consider what happens if you've got a list that the app will add more to it when the user gets near to the end.
For example, imagine a list that starts with 20 items and when the user gets 5 from the end it loads 10 more. If the app can always load more this will go on forever or maybe it only does this until it can load no more.
Now consider a non-touch screen device--there are still a lot of them around.  To scroll the list the user uses their mouse and drags the scrollbar.
Considering the above, if the user drags the scrollbar 75% of the way down we reach the magic trigger value. Let's say the user hovers at this point to view the items at that position in the list. But then all of a sudden, without the user doing anything, the items on display have changed.


What happened?

• The user was confused.
• The user lost confidence in their ability to use the app.
• The user lost confidence in the app.

Not feelings or reactions you should want to create in your users. Well, not if you want them to come back and use your app again, leave positive reviews or recommend it to others.

What happened technically?
After the additional items had been added to the list, it changed from showing the items 75% of the way through 20 items to be showing the items at 75% through 30 items. Depending on how many items are visible at once this might mean that the items that were on display are now completely gone.

If you have an app that incorporates lazy loading, I'd recommend implementing an alternative way of allowing a user to interact with the list than just dragging the scrollbar if using a mouse.

How often should an app be updated?

Of course there is some variation for different apps but how often should an app be updated?

If you need to fix a major bug then yes, get that update out quick.
Never updating an app is probably a bad idea.

But beyond that it gets a bit complicated.

Is it good to release an update every time a small fix is made?

Should you release regular updates on a predictable schedule? Even if one of those updates contains only a very minor fix? What if you break that schedule and your users have come to expect regular updates?

If the app alerts the user when new versions are available, should this have an impact on how often you release? It might make the user more aware when they stop?

If the app includes a version history, is there any value in including the release date of each release? Or a string reason not to?

What if the app is a relatively dumb client but you update the server side logic on a regular basis (either to fix bugs or add features), should this be informed to the user in some way? How?

Is it worth planning, in advance, an update shortly after you launch? As part of a promotional campaign which aims to demonstrate how responsive you are and how you listen to your early customers?

How long is too long to leave between releasing an update?

Is it ok to release an update with just bug fixes and no new features?
Of course it'd be great if you never had any bugs to fix...

How much functionality do you need to justify calling it a major update?

Obviously a new version must be tested before it should be released. Do apps built with a large amount of automated testing get updates released more often? Got any examples?

Similarly, do apps built with automated release tools get released more often? Because it's easier to? Got any evidence?



This is a potentially difficult, and controversial(?), area. No doubt some people have some strong opinions.
I'd love to hear your thoughts.
It'd also be good to know that other people releasing apps are thinking about this issue...

Mobilista Rockstars - get your discount code here

This is awesome! As soon as I saw the details I broke out my credit card and booked my place.

"3 events, 3 continents, 32 keynote speakers, 1 topic - The future of mobile".

I'm not just a Windows Phone developer. I've been developing for all sorts of mobile platforms for more than a decade. I'm obsessed with all things mobile. Many years ago I was told that if you want to be an expert in a field you should read every book in your field. I've given it a good go and am really excited to hear from many of the authors I've read. I'm also really looking forward to attending a mobile conference and not just hearing all the same things over again. I'm really expecting to hear some new and exciting things.

It's not cheap but the first 100 tickets in each country are cheaper. You can also get a 10% discount by using the code 1MRDD78

Just head on over to http://mobilistarockstars.com/ for more information and to book your place. Don't forget the discount code. ;)

See you in London ;)

Programmatically restarting a device

If you follow me on twitter, you may have seen me discussing a bug in the SDK which causes devices to reboot.
This wasn't as a result of doing anything untoward or deliberately malicious. This was just as a result of passing what should be valid data to a method in the API.
I wasn't looking for any particular issue, I was just testing some functionality as part of an application.

Being the responsible adult that I am I reported it to the Windows Phone team. They confirmed it as a bug and have raised it in their bug tracking database.
This hasn't been fixed in GDR2 but will hopefully be fixed in a future update.

Some people on Twitter suggested that I include it in an app as a feature. So I did just that.
I created a simple app that allows the restarting of the phone after a short, animated countdown.
A small beta with a few dozen volunteers confirmed that it worked across a wide variety of devices.
Unfortunately the certification team weren't happy with such an app being in store and so rejected it.
I don't think that it breached any of the store requirements but I don't expect I'd get anywhere debating it. Sorry, no restart app coming soon.

Many people have asked about how to do this.
Sorry though, I don't see any value in sharing the specifics. It's not like it can be used in an app. :(

3 image editing options for Windows Phone apps

If you want advanced image editing capabilities within your app then the new Nokia Imaging SDK should give you all the power you need. But there are a couple of other options available for you too.

Telerik's RadControls include an ImageEditor.
(Remember the control suite is included in the Nokia Premium Developer Program)

Aviary also have a Windows Phone SDK. It's free for (probably) most use but there are advanced and support options you can pay for.