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.

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.

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 https://www.361podcast.com/s02e02

Nando's in London app

In, or visiting, London and want some PERi-PERi chicken but don't know where the nearest Nando's is? Never fear, this app will help you find your nearest Nando's restaurant. See it on a map, get directions, check facilities or just call for take away. If you're a spicy chicken lover this is the app for you.

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 ;)

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:

• 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.

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.

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

            //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.

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:

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:

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.

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.

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.

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?

• 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).

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.

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.

#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.

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:

                    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.

Getting version numbers and names right is hard

Rant alert! You have been warned!

Managing platform & SDK version names and numbers can be hard. When you want a simplified, public name for these that can be used in marketing and promotion things can easily get confusing.

Let's consider Windows Phone:

Once upon a time there was "Pocket PC"
Then there was "Smartphone" - before it became a generic term.
This was followed by "Windows Mobile"
When "Windows Mobile" (the OS) reached version 6.X it was marketed to the public as being "Windows Phone"
Then Microsoft announced "Windows Phone 7 Series"
This was quickly rebranded "Windows Phone 7"
This first major update to this was codenamed "mango"
When beta versions of the "mango" tool were made available to developers they were versioned as 7.1.
It's been reported that, when it's officially released, what has previously been "codenamed mango" will be version 7.5 and the platform as a whole will be referred to as simply "Windows Phone"

We're now in the position where names are being reused and there are multiple names and version numbers for the same thing. :(

If this wasn't potentially confusing enough some (hopefully well meaning) people have started retagging blogs, tweets, questions, etc. with their own personal preference for the name and sometimes version number.

In a folksonomy it's "folkS" plural!
If you're a single person, with limited, demonstrated, knowledge and experience of anything and you want to start changing what things are called (especially if it's something I care about) please don't. It doesn't make you clever or important and you coudl end up doing more harm than good.
It's also a waste of time to manually retag things when ways to create aliases exist.

Blindly changing things without addressing the reasons why they need changing or informing the people who are continuing to create items with the "older" tag just compounds problems and confusion.

Grrr

To those who said I was certifiable...

...  you were right!

It seems that a few other people on Twitter are reporting that they haven't received their results from taking the beta exam yet. As I received mine yesterday (I tend not to check email at the weekend) I'm guessing that results are being sent out slowly.

Creating a horizontally scrolling list #wp7dev

I recently needed to show someone how to make a ListBox scroll horizontally rather than vertically. Here's what I did:

The key part is: '<StackPanel Orientation="Horizontal" />'
It's this that controls the direction. of item display.

The next two parts give us the correct scrolling behaviour that we want.
Setting 'ScrollViewer.HorizontalScrollBarVisibility="Auto"' enables horizontal scrolling.
Setting 'ScrollViewer.VerticalScrollBarVisibility="Disabled"' prevents vertical scrolling.

The thing to note is that setting XxxxScrollBarVisibility doesn't just control the visibility if the scrollbar it also controls whether scrolling in that direction is possible.

Must have game: Sonic 4 Episode 1 (for WP7)

Disclaimer: This review is part of a shameless attempt to win fabulous prizes.

If I think back, it's with a slight sense of regret that I probably spent more time playing computer games than doing homework while I was at school. The vast majority of the time I wasted away was spent playing 4 games (or groups of games): Mario, Zelda, Tetris & Sonic.
I don't expect to ever see Mario or Zelda games on a Windows Phone (or XBox) and I've already got the 200 gamers points for Tetris on WP7. Fortunately now I can relive my mis-spent youth by spending far too much time playing Sonic.

It's games like this that make me stop and appreciate how far we've come with technology and just how powerful the phone in my pocket really is. I remember when graphics like this on a console were cutting edge and impressive.
While still looking good even now, the graphics aren't what this game is about though. Sonic is from the golden age of computer games when gameplay was everything! No gimmicks or throwing of animals. This is all about running (really fast) jumping on weird animal creatures and collecting rings. As computer games go, it doesn't get much better than this.

I'm not sure how this is the 4th part in the series as it seems like a rehash of levels from earlier versions of the app. That doesn't matter though it's a great way to relive my childhood and swap sleep for time spent with a speedy blue hedgehog.

Maybe in episode 2 Tails (that was the name of the fox-wasn't it?) will be back?

Get it from the marketplace now (trial available).

Do you want a .app domain for your app?

This is cross posted on the WPUG blog.

In 2012 ICANN will make the gTLD of .app available. As you can imagine, there is likely to be a lot of interest in controlling this due to the potential demand for such domains.

The .app project is a community funded and executed project to obtain rights to the .app gTLD:

"We’re looking to gain support from the community together the funds necessary to build and operate the .app gTLD in perpetuity. Our aim is to keep the .app gTLD open and accessible such that it becomes an entity that properly support the mobile application software development community, particularly in areas of intellectual property protection."

The project is currently looking to gain support and raise the necessary funds to run the gTLD.

So why should you care?

Well, if you ever think you might want a .app domain and don't want to have to pay huge amounts for it then you may benefit from offering your support now.

What can you do?

Head on over to the website and register you interest then follow them on twitter at @dotappapp.

yet more examples?

It's been suggested that I make more of this blog. One common suggestion is that I post some examples of how to do common tasks on Windows Phone 7.
There are already quite a few sites/blogs which do this. I'm a bit reluctant to be another "me too" and contribute more content which is little more than a rehash of content already on MSDN.
Sorry if that's a bit critical of some others.


What do you think?
What would you like me to write about?

XNAUK + WPUG = #DevChatUK (July 21st)

+

Come join both XNA-UK and WPUG for a mad bash twitter evening in a DevChat style Mashup on:

Thursday 21^st July
7 – 9 PM UK time
#DevChatUK

We’re going to hijack the twitter hashtag #DevChatUK and do a wide scale Q&A / Chat session on all things Phone, XNA, Silverlight and Mobile development in general (including multi-platform questions)

So come join in, publicise your current projects, lets us know who you are or just come and get info on what all this noise is about with online help from the experts in the field.

We recommend using a web service like http://tweetchat.com/ and enter the HashTag #DevChatUK to join in the fun.

Book Review: 101 Windows Phone 7 apps - Volume 1: Developing apps 1-50

The prospect of a book with over 1100 pages long can seem a bit daunting. Considering this book is only volume 1 and only the first 50 apps it could seem even more so. The good news though is that this book is easy to read, thorough and full of up to date information.

The "unconventional" structure of the book where each chapter shows how to create a separate app is interesting and different but a lot of the apps created seem quite contrived and unuseful. Hopefully anyone reading this book will not end up creating their own versions of the apps that are in this book but will use the lessons it teaches to create their own apps which go beyond what's here and make something special.

A large reason for the size of the book is that all the code mentioned is printed in the book. Much of this seems unnecessary, especially as all the code is available for download.

Even though each chapter is focused on creating an individual app chapters build on each other so it really requires reading cover to cover. It then provides a useful reference for each feature which you can return to later but it does really require a full read first. This can be a bit much if you have some familiarity with Windows Phone 7 as a development platform.

Beyond the basic technical facts, this book provides numerous design and usability recommendations which are equally important for anyone getting started with developing apps for Windows Phone 7. These recommendations show a breadth and depth of experience and insider knowledge with WP7 and provide valuable pointers to anyone who is or wants to develop apps.

So what about the up to date information? The people I know who have written books say how long it takes. With that in mind I was impressed by the way that the book included information and details about the February update to the Silverlight Toolkit. (The book was published in April.)

I'm looking forward to volume 2 and the inevitable follow up with details about the new features and functionality coming in the mango update.


Disclaimer: I was given a free copy of this book but had been planning to buy it anyway. I'm still planning to buy the second volume.

TombstoneHelper V2.0 released #wp7dev

Great news - Version 2.0 of TombstoneHelper is now available from http://tombstonehelper.codeplex.com/

Actually it's been there for a fortnight, I've just been very slow to finish this post.

According to the change history it includes the following:

• A bunch of fixes
• Added the ability to limit the number of objects that should be saved. (This helps aid performance by not searching for other controls once it's found the ones you want to save.)
• Added support for ToggleSwitch
• Added horizontal scrollviewer offset support
• Added the ability to remember text entered in TextBoxes & Password boxes
• Added the ability to remember the control with focus
• Added the ability to remember the text selected within a TextBox (if appropriate)
• Added support for the Pivot control. (Be sure to name it!)
• Added the ability to specify the Types to tombstone through a generic interface. (Only up to 3 tyeps currently.)
• Added some basic extensibility support.
• Added support for the Panorama control via extensibility. (This was to demonstrate an extensibility implementation and to not add Panorama support by default as use of this isn't always desirable.)

If you look at the source for the demo app you'll see examples of everything being used. When I get the time I'll update the documentation and maybe blog about it some more.

If you have any questions or comments please add them in the comments here or in the discussions tab on codeplex.

For reference, the need to support Tombstoning doesn't go away with Mango but becomes less likely to be needed. One of the knock on effects is that it becomes harder to test tombstoning support in mango. I'm talking to the WP7 team about this and will duly report back.

I plan to continue to update and extend this library to make tombstoning easier through Mango. And beyond...

If you use and like it, please rate it on the NuGet site: http://nuget.org/List/Packages/WP7TombstoneHelper

Simplifying use of SQL CE in Mango #WP7Dev (1 of n)

One of the features that the "Mango" tools introduce for Windows Phone development is a built in SQL Compact Edition (SQL CE) database. While learning about how to use it I was struck by how much better the experience could be.

As such, here is the first in what I hope will be a series of pointers and tips for making working with a database easier.

If you want to learn more about using SQL CE with Windows Phone codename "Mango" then I also recommend you check out the following on MSDN:
How to: Create a Basic Local Database Application for Windows Phone
and
Hands-On-Lab: Using local database in To-do application

---

When working with a database it's good practice to persist any changes to the datacache as quickly as possible. This means you'll probably end up doing something like this:

  db.MyItems.InsertOnSubmit(myNewItemInstance);
  db.SubmitChanges();

or this:

  db.MyItems.DeleteOnSubmit(anItemInstance);
  db.SubmitChanges();

quite a lot.

The only reason you may not want to do the above (Calling `SubmitChanges` after every call to `XxxxxOnSubmit()`) is if you were performing a number of insertions or deletions in a loop. In this case it may be wise (more performant) to call `SubmitChanges()` at the end.

When looking at even a short amount of code that does insertions or deletions it strikes me that there is a lot of duplication and that if those functions are always called together then it may make sense to bundle them up into a single function.

As it may not be immediately obvious how to do this (I had to explore a couple of options before I ended up with this), I present a simple class with some extension methods which does just that:

public static class TableExtensions
{
  public static void InsertAndSubmitChanges(this Table table, T entity) where T : class
  {
    table.InsertOnSubmit(entity);
    table.Context.SubmitChanges();
  }

  public static void DeleteAndSubmitChanges(this Table table, T entity) where T : class
  {
    table.DeleteOnSubmit(entity);
    table.Context.SubmitChanges();
  }
}  

By using the above class, it means that where we were previously having to write 2 lines of code we can now just write 1 and still get the same functionality!

  db.MyItems.InsertAndSubmitChanges(myNewItemInstance);

  db.MyItems.DeleteAndSubmitChanges(anItemInstance);  

I hope this helps you write less code. (In a good way of course.)
Please let me know if you find this helpful.

Consumer features coming in Mango

I'm sorry but this is more shaky video. I hope you can cope.

Nick Hedderman demonstrates some of the new features coming in Mango.
Communications


Apps


Web

Move aside and let the MANGO through!

If you're interested in Windows Phone 7 development and were offline, for whatever reason, today or have been sleeping under a rock, you may have missed that the Beta version of the next version of the Windows Phone 7 development tools (codename "Mango") were released today.


You can read more details at http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/05/24/developer-news-beta-mango-tools-available-today.aspx then get it from http://create.msdn.com/en-US/news/WPDT_7.1_Beta

Check out this video (sorry it's a bit wobbly-I hope you don't get sea sick watching it) to see what was said at the launch.

WP7 OS Version numbers

For my own reference and because I couldn't find anywhere else where this had been documented. Here are the different OS Version numbers for each of the WP7 releases/updates.

7.0.7004.0 - Original public release
7.0.7008.0 - "Pre-Nodo" update (contained changes to support the NoDo update)
7.0.7390.0 - NoDo (No-Donuts) update (included performance improvements and cut and paste)
7.0.7392.0 - Security update

Update: See http://www.microsoft.com/windowsphone/en-us/howto/wp7/basics/update-history.aspx

Minify the size of your XAP file with some help from Telerik

As every good Windows Phone 7 developer knows. It's generally a very good idea to make the size of your XAP file as small as possible. Among other things this can help towards faster app loading times.

For an app I've been working on recently (more off than on) I wanted to get the start up time as short as possible. One of the ways I've been doing this has been to remove unnecessary external libraries and to optimise my use of the ones that I do need.
Now, while I'm a big fan of NuGet sometimes I don't want everything in a library. In this instance I created a version of the library I was using specifically restricted to the functionality that the app needs. I did this by getting the source of the library I was using (well actually libraries as there were 2), added the source project to my solution, excluded everything I didn't need from the project and then linked my app to that project rather than the downloaded copy of the compiled library.

Before I started this process my app was 599Kb. After the above process I got it down to 298Kb but there were still a couple of large assemblies in my XAP file that were bugging me.
These were both from Telerik (part of their WP7 control suite) but as I was just using a small part of the functionality available in those libraries this bugged me. As source wasn't available, I couldn't use the above technique. So I tweeted about it.

A few hours later I had a very interesting response.

It turns out Telerik already have a solution to this problem. It's called the Telerik Minifier and it provides 2 option:
1. You tell it which objects you specifically want and it gives you a set of libraries which contain just those. or
2. You point it at your XAP file and it removes everything it can to make it smaller. (I'm guessing it does the process in option 1 but just manages the updating of the XAP file for you.)

I opted for option 2 and then a minute or so later my XAP file was down to 209Kb in size.

And yes, my app now opens super fast. So fast in fact that I'm not including a Splash Screen!

Update
After some questions about what's actually happening, have a look at the image below.

On the left is the contents of the XAP before minification. On the right is the contents of the XAP after minification. The Telerik controls have been replaced with new versions which only contain the necessary code for running the app.

#WP7Dev app feedback #7

This is part of my series of app reviews.

After a long break I finally got round to providing some more reviews. In the hope that these points (from multiple reviews) will help you think about your apps, here are some of the (anonymized) feedback points:

• There’s no way (currently) to get back to the settings after first launch. (As you’ve requested location permission this should be a cause to fail marketplace submission)
• On the first panorama item, I would expect to be able to tap the map image to be able to do something.
• It might be good to have a quick way to [do something] in either direction. Without having to create 2 [items].
• The panorama background image doesn't appear to relate to the functionality and content of the app.
• There doesn’t appear to be a way to un-favourite a[n item].
• Rather than “Tap to add X” you could just use “add X” as the tapping is implied. Similar also in other places.
• On the X screen:
  
  • It strikes me that the available space could be used much better used.
  • Do you need the title? I don’t think so.
  • The transition between “X” and “Y” isn’t obvious. I wondered for a bit what these terms meant. Could you make this clearer for the user? On the first few uses of the app at least?
  • Showing the time that the last location information was received might be a useful addition.
  • When status is “Z” it would be good to also indicate that the app will try and get a location again soon. I did wonder when I first saw this.
• The help screen seems completely superfluous and this information could be added elsewhere.
• It would be good if the "contact support" option indicated it was going to try and send an email.
• I'm not sure that putting the views in a pivot is the best option. I keep accidentally navigating between pivot items when trying to [manipulate the content on screen].
• The speed of rotation of the 3D model can be quite fast which can make it hard to get the exact position desired. I noticed this when trying to get back to the original view.
• Could you add a double tap option which would automatically revert the image to the default view?
• Add support for tombstoning
  
  • remember the selected pivot item
  • if the [content has been manipulated] then remember this also
• While it's not possible to use the checkboxes to select more than 6 objects, if you have 6 selected and then add another this is automatically selected and you end up with 7 selected and it doesn't complain.
• Why can't I edit an item? - even if only the ones I create.
• your terminology alternates between "item" and "object" within the app.

Here's what one of the creators of the apps thought of my feedback:

"thanks a lot, this is extremely helpful! Running the app I agree with every single point you make (and can't understand how I did not notice these issues before...)"

The marketplace needs a higher quality bar for screenshots!

I know nothing's perfect and I know the Marketplace team are doing a great job of a difficult task. It just seems like more should be done to

From the Windows Phone 7 Application Certification Requirements (section 4.6).

"Screenshots must only contain application graphics, and must not include any emulator chrome."

But then there are these: (images linked directly from the marketplace.)

These screenshots show a combination of browser chrome and developer frame rate (performance) counters.

Yes, I've seen lots more examples.
No, I don't think it reflects well on the Marketplace as a whole. :(

What would I like to see?
4.6 being more rigorously enforced.
and a new clause being added to the certification requirements that screenshots don't include performance counters.
Is that too much to ask for?

TombstoneHelper now in NuGet

My new Windows Phone 7 library for helping with tombstoning (http://tombstonehelper.codeplex.com/) is now available via NuGet.

Also at http://www.nuget.org/List/Packages/WP7TombstoneHelper

Please use, and suggest improvements.

Tombstoning = A Top Tweet

I thought a "Top Tweet" was something only celebrities got.

Seems tombstoning is a popular subject. Check out http://tombstonehelper.codeplex.com/ and let me know if it's helpful or you have any questions on using it.

If you want to see more on handling it, also check out this post by Peter Torr.

Making tombstoning easier [#wp7dev]

Sometimes tombstoning can be tricky.
Often it takes a lot of boilerplate code.

Things just got much easier.

Now all it takes is 2 lines of code:

    protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)
    {
        base.OnNavigatedFrom(e);

        this.SaveState();  // <- first line
    }

    protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
    {
        base.OnNavigatedTo(e);

        this.RestoreState();  // <- second line
    }

Get all the tombstone helper goodness from http://tombstonehelper.codeplex.com/ Already got some tombstoning support in your app but not handling the scrollviewer scroll position? Just do this:

this.SaveState(typeof(ScrollViewer));

Head on over to codeplex: http://tombstonehelper.codeplex.com/ for more details and please be sure to let me know what you think.

Binding to static classes in Windows Phone 7

It's a common request to be able to bind to a global variable in various parts of an application. It's often common that such variables are static.
This question seems to pop up in forums rather regularly and often the advice given is that this isn't possible or to include the "global" variable as part of the model being used as the DataContext of the page. Such duplication of functionality in the model is a bad idea and totally unnecessary.

It's not possible to bind to a static class as binding requires an object instance.
You can, however, bind to static properties of a class.

So we can bind to the static properties of the following.

namespace StaticBinding
{
  public class MyStaticClass
  {
    private static string myStaticProperty = "my static text";

    public static string MyStaticProperty
    {
      get { return myStaticProperty; }
      set { myStaticProperty = value; }
    }
  }
}

We can then create an application level resource which we can actually bind to:

.. xmlns:myns="clr-namespace:StaticBinding"


  

(Sorry, don't know why the syntax highlighter has forced upper case - I'm sure you're smart enough to work out what should and shouldn't be upper case though. ;)

With the above configured we can then bind to our global property in any page we wish. We just need to set the `Source` and `Path` of the binding.

..


.. 

A nice upside of this is that you even get intellisense on the `Path`. (Assuming you've set the `Source` first.)



X-Ref: http://stackoverflow.com/questions/5323052/data-binding-a-string-variable-of-static-class-to-textblock-in-phone-7/5325257#5325257

Gotchas when forcing the theme colour in a Windows Phone 7 app

Windows Phone 7 support two background themes: light and dark.

When combined with the accent colour, this allow the user a level of customization and personalization of their device and the applications they use.

As a general rule it's good to allow your application to reflect the theme and accent colout the user has selected. Sometimes, however, you may want to "force" the theme of the app. This means that regardless of the them the user selects the application always looks the same.

Look at these two versions of the same app:

The image on the left was taken with the dark them selected and the one on the right with the light theme.
It looks like all is fine.

However, if we want to support the inclusion of the `SystemTray`, so that the user can see the time, battery level, network conection status, etc. then the system theme colour will show through and there's nothing you can do about it. Apart from not include the SystemTray, of course.

If you want to use a MessageBox in your application then you'l have a similar issue. This is what the default MessageBox looks like when a light theme is selected but a dark theme is forced.

The solution is to make your own version of a MessageBox.

Creating your own version of a message box is relatively simple. Creating your own SIP/Keyboard is a lot more complicated if you want to recreate all the functionality of the built in one.

My advice, don't force the theme unless you have a REALLY good reason and have the time and patience to deal with all the consequences.

#WP7Dev app feedback #6

Here's the feedback I recently gave to the creator of an app.

This is part of my series of app reviews.

In summary, I said it was "a nice app which is well executed".

Here's the feedback:

• It would be nice if the main screen would remember the selected panorama item after being tombstoned.
• When viewing items and swiping from side to side, there's no indicator of when the end of the list of items has been reached.
• When viewing an item, tapping it to return to the main menu was, initially, unexpected and caused me to accidentally navigate backwards several times. Especially/even when scrolling down.
• If viewing the item summaries for a single category, it's not clear what I'm navigating between when I swipe from side to side.
• If viewing an item and the app is tombstoned, I would expect the app to display that item again when I navigate back to it.
• If only one category is configured, on the first panorama item, is it necessary to have the "all items" option as well as the category.
• In trial mode, it's possible to view articles of featured items, but not other items. This inconsistency was surprising.
• When adding a new feed it would be good to also add this to a new category, not just select from existing ones.
• When adding/editing a feed, is a cancel option really necessary? Can you not just rely on the back button to perform a cancel action?
• When adding a category the entered text is required to be at least 2 characters long. This includes spaces. This means that it's possible to create categories made just of spaces.
• The detecting of duplicate category names also doesn't include spaces at the start or end of the entered text which means that duplicates can, seemingly, appear to be created.
• When a featured item is selected but the main progress bar is still being displayed, this appears over the top of the popup.
• When a featured item is marked as read from the popup all featured items are reanimated. This takes time and makes the app seem unresponsive and means it's hard to quickly view multiple featured items and mark them read at the same time.
• In the email created from the about screen, you may want to include the version number of the application. This will likely be helpful to you when investigating any reported error or problem. (Especially if someone is reporting a bug you think is fixed.)

#WP7Dev app feedback #5

Here's the feedback I recently gave to the creator of an app.

This is part of my series of app reviews.

In summary, I said it was "a simple, well executed app".

Here's the feedback:

• On the main/menu page I would disable scrolling of the options/list as everything fits on the screen without needing to scroll.
• When searching the word list it would be good to indicate when no words match the entered text. This is generally preferable to just leaving a blank screen as it makes it clear that there are no results to display.
• Add tombstoning support to the search function so that on returning to the application it looks as it did when the user navigated away.
• When using the next and previous buttons to navigate, I would recommend either making the list wrap around (so that selecting previous from the first item goes to the last item-and vice versa) or disable the previous button when on the first word and the next button when on the last word.
• In the list, there is uneven capitalization of the first words in sentences.
• In the list, most (but not all) of the sentences that span multiple lines appear to have a space before the first word. This creates an inconsistent left margin.
• In the "XXXXX" display, the list is very long and may benefit from using a "long list selector" as in other places in the app.
• In the "Test Yourself" mode, the page title says "test #N of 20" but it's really it's "question" number N, not "test" number N. I'd recommend changing the text to just be "N of 20".
• In the "Test Yourself" mode, restrict the clickable space between options to prevent the chances of accidentally selecting an option other than the one intended. With this change it would be possible to remove the need to confirm (apply) the selected option. I find the confirmation step a bit frustrating.
• If I back out of a test I am prompted to confirm that I wish to make this action as my progress will be lost but if I go back into this option my position in the test is remembered.
• When the results of the test are displayed there is no clear indication of what the user should do next. How about adding options to try another test or returning to the main menu? I know that the back button can be used to return to the main menu and it's normally a bad idea to duplicate the number of ways you can perform the same navigation but there is currently a dead end. Adding instructions to the page to use the back button to navigate back to the main menu would take up more space and take longer to read than tappable text to do the navigation directly.
• On the about screen, I would recommend increasing the tappable area around the URL for your website so that it is easier to tap.

#WP7Dev app feedback #4

Here's the feedback I recently gave to the creator of an app.

This is part of my series of app reviews.

In summary, I said it was "a lovely simple app which is well executed. It has impressive performance in terms of the speed of loading remote data."

Here's the feedback:

• In the Marketplace description, some names are not capitalized correctly.
• The highlight effect you have applied to the application icon is similar to the effect automatically applied to most iPhone apps. I would recommend removing this highlighting from the icon image so the app looks like it belongs on the platform.
• I like the splash screen image but the logo it displays doesn't seem to match the branding of the rest of the app (apart from the color).
• While I like the color you have used in the app I wonder if it's everyone's favourite. Have you considered using the phone accent color for this? It may help the user gain a greater sense of ownership of, affinity for and connection with the app.
• Add tombstoning support to remember the selected pivot item and scroll position in that item.
• There is no need to include the same options in both the application bar and the application menu.
• I would recommend only including the "reload" option on the application bar. I would expect that this would be a frequently used option and having it always available will be helpful. Having it in the application menu makes it harder to access as it requires an extra tap and therefore takes slightly longer.
• I would expect that the settings would be rarely accessed and so access to this functionality should be moved to the application menu so it doesn't distract or get pressed accidentally.
• The convention for pivot item headers is for them to be entirely lower case. You should adjust "About" and "Settings" accordingly.
• Add tombstoning support to remember which of the "About" or "Settings" pivot items were displayed when returning to the app. Remembering scroll position would also be good too.
• The Settings screen has application bar items which are duplicated in the application bar menu. There is no need for this duplication.
• On the setting screen there should be no need to have a cancel button which just closes the current page/navigates backwards. The back button on the phone does this already.
• On the setting screen there is no need to have a Save button as the selected options are automatically remembered applied.
• The entire application bar can therefore be entirely removed from the settings screen.
• The about screen also has an application bar with save and cancel options but these don't relate to anything on screen.
• On the about screen I would recommend making the email address stand out more to make it more obvious that it can be tapped to trigger sending an email. Colouring the email address with the phone accent color and increasing it's size would be my recommendation.
• In the email created from the about screen, you may want to include the version number of the application. This will likely be helpful to you when investigating any reported error or problem.

Still not got the pre-update? Fake it!

<justforfun>
You've sat quietly by as the rest of the world seems to be going on about the first Windows Phone 7 update (the pre-update) but have yet to have your device let you know that the update is available to you.

Well, if you want to get a feel for what it'll be like when that moment does finally come, you just need a simple bit of code:

Guide.BeginShowMessageBox("An update is available.",
                          "Updates can make your phone work better and add new features. They can make your phone more secure too.\r\n\r\nTo learn more and install this update, connect your phone to your computer.",
                          new []{"close"},
                          0,
                          MessageBoxIcon.None,
                          null,
                          null);

</justforfun>

WP7Clipboard - A clipboard API for #wp7dev

Background

• Windows Phone 7 doesn't have an API for a Clipboard. (Actually, in the current version it doesn't even include a clipboard. - But, the ability to cut, copy and paste text will be added in the update coming later this month.)
• I wrote an app, back in December 2010 (see video and please comment at http://www.wp7comp.com/scratch-pad/trackback/), that enables the cutting, copying and pasting of text and even sharing it between multiple applications. (Some people have the idea that you can't share data between apps on the device but I proved this isn't the case. Check the video or get it from the Marketplace to see/confirm that it doesn't use any unrestricted APIs or use a web service for storing/sharing the data.)

Short version
Head over to http://wp7clipboard.codeplex.com/ and get the code to see how I did this and use the library in your own applications.

Longer version
Constraints are good. They focus the mind and can provide structure where chaos can sometimes reign.
By their nature, mobile devices are very constrained. Many of these constraints are passed to (forced upon?) the applications that run on the devices.

Windows Phone 7 development has some potentially limiting constraints in this area:

• No cut and paste support (currently)
• No clipboard
• No shared file system

There are 2 ways we can react to constraints:

1. We can complain about them.

or

2. We can work with them.

I opt for the later.
I knew there had to be a way to do this! Just because it seemed that everyone and their dog was complaining about a "lack of copy and paste" wasn't going to stop me.

"Cut and paste" is really only about copying and manipulating objects (strings in this case) in memory. Just because there isn't a UI for this doesn't mean we can't do it. We just need to build a UI.

Just because the platform doesn't provide a clipboard (functionality to store objects in persistent memory and make them available to all apps) doesn't mean we can't create the functionality ourselves. But this is where the fun begins...

All Silverlight based apps run inside a sandbox and can only create files inside "IsolatedStorage". There's no shared storage facility.

Rather than focus on what we don't have, let's think about what we can do.
Well, even in a Silverlight app we can use some of the XNA libraries.
Through the XNA APIs we can create and read images in the Pictures hub. (We can't delete them but we'll just have to live with that.)
After a little experimentation I discovered that the API will only allow us to save a valid JPEG file in to the pictures hub.
Never mind, there are ways of hiding information within pictures.
I had another idea in mind though. Due to something I worked on a long time ago, I know that the JPEG file format includes an end of file marker. I also know that almost all implementations of code to read JPEG format files ignores everything after the end of file marker. A quick check later and I verified that this is the case on WP7 too.

Yes, that's the secret, I include the data I wish to store in the "clipboard" inside a JPEG image file (the clipboard images littered through this post) after the end of file marker. Then, when I want to read from the "clipboard" I just get the most recent file from the users MediaLibrary and retrieve the extra data from the end of the file.

AFAIK only one person managed to correctly guess what I'd done.

Now you can do this in your apps too. I've encapsulated the functionality from ScratchPad into a separate library and made it open source at http://wp7clipboard.codeplex.com/
Originally this only supported text but I've started to add some functionality for processing (cutting and pasting) images too. It's still a beta but hopefuly some of you will find it useful, helpful or interesting.

A word of warning. Using this method creates files on the users phone which you can't programmtically delete. After sustained use, this will clutter up the users "saved pictures" folder and they will have to manually delete the files there. If you use this library/technique you may want to warn your users about this and give them the option to disable the functionality.

If possible I'd recommend sharing data between apps by synchronising it to a web based system. Connectivity issues aside that will probably make working with large amounts of data easier and provide backup/redundancy options.

I'd love any feedback you have on this.

How ScratchPad does copy and paste ... [#wp7dev]

In response to public demand I'm going to explain how I got Scratch Pad (my Windows Phone 7 app which supports cut 'n' paste and a shared clipboard API) to work.

This is the first of 2 posts on the subject. In this post I'm going to explain how I manipulate the text to create cut and paste within the app. In the next I'll show how I created a shared clipboard. And how you can add the functionality to your own apps too!

The cutting, copying and pasting of text within an app is simple really. It basically involves storing a copy of the text in question in a string variable within the code.

private string localClipboard;

To be able to select more than a single word, the code supports a "shift" mode:

private bool shiftSelected;

private int shiftSelectPositionStart;

private int shiftSelectPositionLength;

private void ShiftClick(object sender, EventArgs e)
{
    shiftSelected = !shiftSelected;

    shiftSelectPositionStart = tb.SelectionStart;
    shiftSelectPositionLength = tb.SelectionLength;
}

Which can be combined with a SelectionChanged event on the text to capture the larger string. (Being sure to consider if the new selection point is before or after the original/previous selection.)

private void SelectionChanged(object sender, RoutedEventArgs e)
{
    var currentStart = tb.SelectionStart;
    var currentLength = tb.SelectionLength;

    if (shiftSelected)
    {
        if (shiftSelectPositionStart < currentStart)
        {
            tb.SelectionStart = shiftSelectPositionStart;
            tb.SelectionLength = currentStart - shiftSelectPositionStart + currentLength;
        }
        else
        {
            tb.SelectionStart = currentStart;
            tb.SelectionLength = shiftSelectPositionStart - currentStart + shiftSelectPositionLength;
        }
    }

    shiftSelected = false;
}

Copying text is easy:

private void CopyClick(object sender, EventArgs e)
{
    this.localClipboard = tb.SelectedText;
}

But cutting text is slightly more complicated as we need to replace the original string with the text before and after the selection.

private void CutClick(object sender, EventArgs e)
{
    this.localClipboard = tb.SelectedText;

    var removeAt = tb.SelectionStart;

    var afterCut = tb.Text.Substring(removeAt + tb.SelectionLength);

    var beforeCut = tb.Text.Substring(0, removeAt);

    tb.Text = beforeCut + afterCut;

    tb.SelectionStart = beforeCut.Length;
}

Then that just leaves pasting the text back in at a newly selected location.

private void PasteClick(object sender, EventArgs e)
{
    var insertAt = tb.SelectionStart;

    tb.Text = tb.Text.Substring(0, insertAt) +
              this.localClipboard +
              tb.Text.Substring(insertAt + tb.SelectionLength);

    tb.SelectionStart = insertAt + this.localClipboard.Length;
    tb.SelectionLength = 0;
}

The above also selects the newly pasted string. Simples! Now, while you digest all that, please head on over to http://www.wp7comp.com/scratch-pad/ and leave some lovely comments - Thanks.

What hackers can teach us about what might be coming in future versions of Windows Phone

Ever wondered why so many of the "hacked" Windows Phone 7 apps show loading additional ringtones or accessing the camera directly?

Well I've had a little look at what some of the hackers have been doing and have found a few managed assemblies that aren't publicly available and it seems to be these that most of the people exploring in this area have been looking at.

So, for your amusement, interest and to satisfy your curiosity, here, in no particular order are some of those methods:

public abstract class Camera : IDisposable
{
  // ...
}

public sealed class PhotoCamera : Camera
{
  // ...
}

public sealed class VideoCamera : Camera
{
  // ...
}

public sealed class RingtoneLibrary
{
  // ...
  public void AddRingtone(Stream ringtoneSource, string ringtoneName)
  {
    // ...

    StreamHelper helper = new StreamHelper(ringtoneSource);
    try
    {
        NativeMethods.MediaApi_AddRingtoneFile(helper.GetTempFile(), ringtoneName);
    }
    finally
    {
        helper.Cleanup();
    }

    // ...
  }

  // ...
}

[DllImport("netcfmail3_7.dll")]
internal static extern byte GetMessageData(IntPtr pMessageNode, byte[] dataBuffer, int cbDataBuffer, byte[] idBuffer, int cbIdBuffer);
 
[DllImport("netcfmail3_7.dll")]
internal static extern int SendAsAttachment(string to, string subject, string messageClass, byte[] data, int cbData, string attachmentFileName);

[DllImport("netcfmail3_7.dll")]
internal static extern int SendInBody(string to, string subject, string messageClass, string body, int cchBody);

public CivicAddress ResolveAddress(GeoCoordinate coordinate)
{
  // ...
}

public static extern int HostGetAvailableFreeSpace(IntPtr pRuntimeHost, out long pAvailableSpace);

The things that jump out at me, apart from the camera access are the methods relating to emails!

My theory is that if there is managed functionality in the framework already (and its use doesn't pose a threat to the security of the users data or device) it's not unreasonable to assume that this could be made public in the future.

Just in case it bears repeating, this is all speculation and I have no special insight into what might be coming in future versions.

#WP7Dev app feedback #3

Following on from my offer to provide some detailed analysis/feedback/review of some apps. Here's some more feedback from another app. It's been anonymized and I've removed a few specific points but hopefully the following will still be of general use.

• Marketplace description: That’s a very long first paragraph. Try and break it into two or more or shorten it. A large block of text can be off-putting and make people unlikely to read it.
• Marketplace description: That's a long list of bullet points. Are the most important/compelling ones at the top of the list?
  
  • Phrase each point the same point. Don't jump back and forth between what the app does and what "You" can do.
  • Don't claim improved usability. Let the users decide if something is usable. If you have to tell them then something is wrong.
  • As an alternative set of bullet points I would suggest something like this.
    
    New in this version:
    - simpler indicating of XXXXX completion
    - easier to change XXXXXX order
    - improved performance
    - improved personalisation
    - simplified editing
    
    
• If the old version of the app won't update, what are you doing to help users migrate data or provide other support. - You want users talking about how you helped them, not that they lost data or had problems.
• When the upgrade nag screen is displayed the screen may looked more balanced if the buttons were of equal size (each half the screen width). I'd also recommend making this message larger and in the centre of the screen.
• You probably also want to avoid displaying the application bar when the upgrade nag screen is displayed. It can be selected at this time.
• The application is very empty on first use. Add something that makes it clear what the user should do.
• You could also consider automatically opening the "New XXXXXXX" screen if that's all the user can do with the application when started for the first time.
• If I select a XXXXXX then the application bar contains a "cancel" option. This appears to do exactly the same thing as the back button. If they do the same thing remove the cancel option as there's no reason to have 2 buttons which do the same thing.
• On the edit screen, there is no need to have colons after labels.
• On the edit screen, the label "XXXXX YYYYY" could just be "XXXXX". Having "YYYYY", in the past tense, implies this is something that has been done which isn't necessarily the case with new items. The shorter label removes the possibility of ambiguity.
• Internationalisation issues aside, I would make the "XXXXXX" box smaller and the "YYYYY" one bigger so they are the same size as the date and time boxes. This should make the screen seem more evenly balanced.
• On the edit screen, the label to indicate if the XXXX is active or complete could be closer to the toggle switch to better indicate that they are connected.
• This label is also quite difficult to see in the light theme.
• I would consider adding a label to the time field as it isn't necessarily clear what the field is for. Alternatively you could provide a default value of "00:00". This wouldn't affect anything in terms of order unless a different time and/or a date is selected.
• As selecting a time defaults to the current time, I would expect the date to be set to the current date if I select a time before setting a date.
• If I enter a description with characters containing descenders, these are not fully displayed on the main page. This particularly affects the "g"s.
• When I entered a phone number in a description it detected the number but didn’t include the last digit in the selected/highlighted number.
• On the preferences screen, the "XXXXX" essentially has 2 labels. You could probably drop the sentence starting "Change the ..." without compromising understandability of the preference.
• The "XXXXXXX" input box doesn't appear to adjust for theme settings and always looks like it as light theme colours applied and this stands out as odd/different when the dark theme is selected.
• The button to add a "New" XXXXXXXX would look more in keeping with the buttons used by the OS and default apps if it was the full width of the page.
• The "Create a new XXXXXX" input box doesn't behave as I would expect with regard to respecting the back button. If it is displayed and I press the back button I would expect the prompt to close, not the XXXXXX selector.
• In the email created from the about screen, you may want to include the version number of the application. This will likely be helpful to you when investigating any reported error or problem.
• When tombstoned from the XXXXXXX screen the selected pivot item isn't remembered. Just a minor point but surprising, and not in a good way.
• On the about screen (in trial mode) the "buy" button is cased differently to the other buttons and so stands out. (And not in a positive way.)

What the developer of the app thought of this feeedback:

I was impressed with both the breadth and depth of your comments. It was extremely valuable that in addition to your direct feeback you provided concrete examples of ways to improve upon it. This made it very easy to actually fix the problems you identified rather than having to wonder how I would go about resolving the issues. The attention to detail in your comments made it clear that you had combed over the entire application which made me much more confident that there weren’t any missed items. Based on your feedback, I will be able to provide a much more polished and meaningful experience for my users which is invaluable.

What do you think of the above? Is me posting these useful to you as well?