Adding an item to a list and scrolling it into view #wp7dev

For reasons can't explain rightly explain, it was a bit tricky to add an item to a list (in a Windows Phone 7 application - unsurprisingly) and then scroll the list so the new item was displayed.

I eventually got this working by forcing the call to scroll the new item into view on the UI thread.

Consider this in a default DataBound application:

  private void ApplicationBarIconButton_Click(object sender, EventArgs e)
  {
    App.ViewModel.Items.Add(new ItemViewModel
                                {
                                  LineOne = "new L1",
                                  LineTwo = "new L2",
                                  LineThree = "new L3"
                                });
 
    Dispatcher.BeginInvoke(() =>
      MainListBox.ScrollIntoView(MainListBox.Items.Last()));
  }

Without doing this, the list will scroll to the item which was previously the last on the list.

Rolling your own cut and paste is acceptable in the marketplace #wp7dev

I'm sure you'll be thrilled to know that my Scratch Pad app is now available in the Marketplace. More important than creating a custom cut and paste implementation, this proves that it's possible to store data on the device and share it between applications.

In time, I'll explain how I did this. And, also, why you, probably shouldn't!

Until then please feel free to tweet about my app and be sure to use the hashcode #wp7comp or post your comments here.

Cut and Paste with the current #WP7Dev tools

For a lot of people the lack of native Cut & Paste support in the current (initial) version of Windows Phone 7 is a big deal.

I've heard a surprisingly large amount of people tell me that it's essential that they can copy and paste text* on a phone. Personally I hardly ever used this feature when I was using a phone which had it though.

I've pointed out to a few people that it's possible to implement the cutting, copying and pasting of text within an application quite easily. (It actually only take a handful of lines of code.) But no-one (AFAIK) has taken the initiative to do this. Before now...

The issue isn't really being able to cut and paste text though. What people really want is a way to easily share data between applications. When people say "cut and paste" they, typcially, mean they want to take (copy) some data (text) from one application and then use (paste) it in another application.

As native functionality, this isn't currently possible.
However this will be coming in an remote update early next year.

So if we want copy and paste in our apps we have to either wait or try and do it ourselves.

Surprisingly, the sandboxed nature of 3rd party applications on the phone has lead many (most?) to assume that this isn't possible.

I beg to differ!

Take a lok at this video of 3 apps I wrote. 2 accept the entry of text and support methods of multiple word selection (also not currently available natively) and cutting, copying and pasting text. The third app just shows what is in the "Shared Clipboard". Yes. These apps all have access to the same clipboard. And, no, this isn't done by sending the data to a remote web server or anything like that. It's also not using anything not publically available and only uses public, authorized API methods.



To try and prove that this is really possible I've submitted Scratch Pad to the marketplace. When it's accepted you can try it for yourself. Plus acceptance will show it's not using anything it shouldn't (or you couldn't) and that it doesn't require a data connection.

With native support for cut and paste coming in early 2011 (most people are assuming in January) I'm not planning on sharing the clipboard code as there is a small side effect to using it that it's probably best not to burden users with. But, I assume that you're smart enough to work out how I did this if you really wanted to. ;)

* It's always text that people want to copy and paste. I haven't, yet, heard anyone give a case for wanting this for any other data type on a phone.

[WP7Dev] Gotchas when detecting network connectivity

When developing for an occassionaly connected device it's useful to know if there's a connection currently available.

The Windows Phone 7 SDK makes this very easy with the GetIsNetworkAvailable() method on the NetworkInterface class.

There are, however, two gotchas you need to be aware of when debugging.

1. If you call this method in code running in the emulator it will always return true.

2. If you call this method in code running on a tethered device (as you may have connected when debugging on a real device) it will always return true.

In both instances you'll need to code around the issue. (Or set break points and move the next/current executing line.)

You should also write code to handle the situation where a network connection is available but your specific web service/site isn't.

Hope this saves someone some head scratching.

PhoneGap for WP7Dev and the RTM version of the SDK

For anyone interested, I've just pushed a new version of my WP7 PhoneGap implementation up to GitHub.
The code can be found at https://github.com/mrlacey/phonegap-wp7/tree/master/rtm/.

Please note that this doesn't do anything special. It's basically just the old code slightly restructured, with the mobile spec tests removed and using the latest project formatting.The only real difference is that it works with the RTM version of the SDK.
I've tested it with VS2010 Ultimate & Express.

Important! This still does not handle tombstoning!
Until it does, this should be considered proof of concept only and is definitely not production ready.
Unfortunately support for tombstoning is going to require a very big change to the structure of the existing code and will impact all the JS/C# interop.
However, as I've found the time to fix the code referenced above that shows I'm working through my to-do list and getting closer to finding/having the time to make the big change.

Learning, not moaning.

If you follow me on Twitter you may have noticed that I have a tendency to complain about poor service and badly produced apps quite a bit. In an attempt to be a bit more positive I thought I'd see what I can learn from these issues rather than just moan.

Here's what I've learnt in the last few days.


Issue:
If you have an Orange Broadband account and have set up an online account to look at bills, etc. You'll discover there isn't a way to change your password and if you forget it you have to call a phone number to speak to "tehnical support" and have them tell you it. If you then ask to change the password they will tell you not to. Presumably because it's a non-trivial task for them.

Lesson learned:
Understand security. Make sure "technical staff" understand security. Make it easy to change passwords.


Issue:
When trying to speak to someone at Direct Line I had to go through their automated phone system which presented options I had to select by pressing numbers.

Lesson learned:
Make things easy to navigate and test navigation routes.


Issue:
When trying to log in to a website (mentioning no names), I eventually discovered why my password wasn't working. - It was because I had CAPS LOCK on. But I had no way of seeing this as the entered characters were masked. (The username/email had been saved by the browser so I didn't see the upper case characters being entered there as I didn't have to type anything else.)

Lesson learned:
Indicate if CAPS LOCK is on when the user is entering text which isn't displayed - like with a password entry box when characters are starred out.
Or, write a password checking system which accepts either correctly cased passwords or passwords entered with case inversion. This means storing 2 hashes of the password (& salt) but is only a very small amount of work which could save a lot of frustration for any user who can't see why their password isn't being accepted.
I'm holding off on ignoring case entirely in passwords though. That seems like a step to far and would be more of a compromise in security and invalidate the user's attempts to use a strong password.


Issue:
I just installed some of the apps in Windows Live Essentials but it also installed some of the apps I asked it not to install.

Lesson learned:
Thoroughly test installers!
and, in case this is a dependency issue - be sure to indicate dependencies and other things which must be installed as well, clearly.


Issue:
It took 2 phone calls taking over 25 minutes to stop Orange from taking payments from my account which they should not be - due to a mistake that they made. When this was finally sorted no-one said sorry and I haven't been given anything for the trouble (of them taking payments they weren't due or for the inconvenience and time taken for me to identify the issue and get them to sort it out.).

Lesson learned:
Say sorry and provide compensation (of some appropriate sort) when you make a mistake.


Yes that's a lot of issues for two days but I think about these things a lot because I want to make awesome apps (and services) which don't frustrate the user or contain stupid decisions or do anything apart from make it easy on the user and get out of their way.

PhoneGap at LDNUG

On Wednesday I gave my first talk at the London .Net User Group.
I gave a brief introduction to PhoneGap and briefly showed how to use it to create an app for Windows Phone 7.

The main place to go for all things PhoneGap is http://www.phonegap.com/ but if you're after the Windows Phone 7 version this is currently at http://github.com/mrlacey/phonegap-wp7. (Please note that the WP7 version on GitHub doesn't work with the RTM tools. I hope to upload the fix for that tonight. Lots more excciting functionality will be coming shortly too.)

View more presentations from Matt Lacey.

[WP7Dev] Attention to detail is VITAL!

Take a look at this screenshot of some of the apps already in the marketplace, as shown in the Zune desktop client.

Notice how some of the images look very odd. They look very much like they've been created as white images with a transparent background on the intention/assumption that they will always be displayed on a black background. Yes, that assumption was wrong.

Remember, Windows Phone 7 is a platform where quality is essential. How you do something is more important than what you do.

The marketplace is like your store front and the icon is like your packaging. Would you think twice about something with poorly printed packaging? Would it make you question the attention to detail paid in the rest of the production process? And, would you even reconsider buying from a store where products were poorly packaged?


Please don't make this same mistake with your apps.

Bad apps don't just hurt the developers, they hurt all developers as they hurt the platform. If it was up to me apps with images like that shown above would have failed the submission process.

WP7Dev at VBUG London

Yesterday I gave an introduction to developing for Windows Phone 7 at VBUG in London.
A great bunch of people were there and they asked a lot of good questions and seemed excited about the platform and the opportunities it affords. Respect also goes to the people who travelled down from Stafford for the event.

As lots of people asked for them, my slides are below and (most of) the sample code can be downloaded here.

Introducing Windows Phone 7 Development

View more presentations from Matt Lacey.

Windows Phone 7 - How? Not what?

This afternoon (in the UK & jointly in the US at the same time) there is a press conference where Windows Phone 7 will be launched. (We assume.) Unfortunately, I won't be there.

While, I won't be there today, I was able to spend some time with Oded Ran (UK Head of Marketing for Windows Phone) the other week. While I didn't learn anything I hadn't heard before (because I already know loads - not because there wasn't anything interesting said) I did get to see a few more apps that will be available on launch.

The really interesting point that was raised though was that it's about how the phone does what it does and not about what it does.

This is an important distinction and one that has been seemingly overlooked in terms of a lot of what has so far been communicated to developers.

Lots has been said about a lack of third party background processes and cut and paste support (amongst other things). These things matter in small part to most and for those who they really matter to they will be available in time. Having these things is unlikley to be a deciding factor to a lot of people though. It's going to take something special to differentiate these phones such that people will want to buy them.

Let's talk about who those people are for a minute. Not everyone is going to buy a Windows Phone 7 device. That's Ok. Not everybody is the same. Not everyone wants, needs or can afford a smartphone.

So let's consider the people who want and can afford a "smartphone". As far as I'm concerned, in the UK smartphones mean iPhone, Android, Windows Phone 7, Blackberry, some Nokias & Palm (but nobody has one.)
Guess what? there's room for all of them. Despite what some people seem to think there won't be a single/company/platform which ends up being the only one.

Currently (before the WP7 launch/release) smartphones differentiate themselves on apps and features. Windows Phone 7 is different. It differentaites itself on execution and integration.

What does this mean?
It means it's not going to try and differentiate itself based on what you can do with the device. Afterall you can get a phone which will let you access Facebook for just a few pounds. What WP7 does is offer an amazing, integrated experience with Facebook that is a pleasure to use.
It doesn't stop there though:

The mail application is the best I've seen on any device.

Integrated XBox Live gaming is incredible.

The "authentically digital" interface is fast, responsive and beautiful.

It's simple to use and navigate around the different applications.

And it even makes and receives phone calls!

No, it doesn't do everything - yet. But what it does do it does with a level of style, polish and finish that people will love. Personally, I can't wait to get my hands on a final device.

I'm happy that I'm not going to convince you with words that you should consider Windows Phone when you're looking to get a new smartphone. What I will say is that I'm not aware of anyone who has tried using one and not found it great. Borrow one, or try one out in store (when available) and see what you think. Put any perceptions you have based on Microsoft's previous mobile offerings and prepare to be impressed!

Ok, rant over, lets see what the launch brings....

Me, StackOverflow and Windows Phone 7

I should probably file this under shameless self promotion but I felt in need of a bit of ego stroking.

I've been quite busy on StackOverflow.

This made me think of "Live Tiles"

Rethinking the mobile web

from

http://www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-yiibu

Project 52 - done

Back at the start of the year I signed up to Project 52.

The idea was that in making some kind of pledge to post once a week it may help me to write at least as many posts as I did in 2009 (53).

I've just realised that this will be my 55th post this year so I'm declaring job done.

I haven't tagged/labelled all the posts with project52 like I was supposed to but I don't think that really matters.

Here's to more posts!

The next step may looks like it will be to try some video blogging. Let's see what happens.....

[WP7Dev] Does large text in titles waste valuable screen real estate?

When it comes to a mobile user interfac, the top of the screen is the most valuable real estate. It should therefore be used for the most important information. It may, therefore, seem odd that the default Silverlight application templates fill the top of the screen with text that doesn't change. Just take a look at the top of the screen from a simple app.

 The top of the screen is filled with the the applicaiton name ("MY APPLICATION") and some text. In this case the "page name". While having this information occupy prime real estate may be good from a branding point of view, this could be seen as a waste.

Fortunately the UI guidelines give us a good reason for this behaviour:

Applications that expect user interaction during a phone call should have a minimum 75 pixel margin on the edge of the device that has the power button. No touchable UI elements should be placed within that margin.

 It's a phone! People will want to make phone calls with it. If they can do this while still using your app, let them.

"Awesome apps that improve lives"

This is all I want to make: "awesome apps that improve lives"!

But what does this mean?

Let's break it down into 3 parts:

1.    awesome
2.    apps
3.    that improve lives

"Awesome"

• Because mediocraty sucks.
• Because just doing enough isn't enough.
• Because expectations should be exceeded. I want to deliver more than was promised. Not be justifying why someone is getting less.
• Being awesome is easier than you might think. Because so few people do it.
• Hopefully being awesome will get harder.  Hopefully this will be because more people are also making awesome software.

"apps"

• Why apps? (By which I mean software.)
• Because that's what I know and have made, studied and continued to learn about for the last 15+ years.
• A few years ago I did some consultancy for a couple of mobile device manufacturers based on some prior work I had done on evaluating handheld computing devices.  Apart from that I've always focused far more on the 'soft' side of things.

"that improve lives"

What does it mean to "improve lives"?

• To make things easier.
• To make things faster.
• To make things cheaper.
• To make things a pleasure, not a chore.
• To allow people to focus on the important rather than the trivial or mundane.

Simples.

Alternatives to polling

Recently I blogged that "Polling is a smelly anti-pattern!".

I think it will be useful if I expand on this a bit.
I should probably also have been clearer that this is about polling on a timer. i.e. Every X seconds (or minutes) query the server to look for updated data,  new messages, current status, etc.

Avoiding polling in a mobile app is a rule.
While I don't subscribe to the idea that "rules are made to be broken", I do believe that rules can be broken when appropriate (It's laws that can't be broken and I'm don't know any laws of software development!) but only on the following basis:

• Firstly learn the rule.
• Secondly, learn the reason(s) the rule exists.
• Thirdly, learn the consequences of breaking the rule.
• Fourthly, do the same for the alternatives to the rule.

Only once you've been throught the above four steps should you consider breaking the rule.


Ok, back to basics, why is timer based polling a bad idea in mobile apps?

2 reasons:
1. It may (depending on the platform) prevent the device from going to sleep/standby. If the device is prevented from going in to standby means that the battery will drain faster. When the battery runs out the device is useless so it's in the interests of both the users and the person wanting the application to be used for the battery to last as long as possible. SOme platforms may even wake the device when the timer fires - almost completely avoiding the benefit to battery preservation which a standby mode can provide.

2. By making a request just to see if there is some new data on a server the application is using the devices data connection. While a request that only responds with a message that there are no new messages is likely (hopefully) to be a small message it still uses network bandwidth. For some users, the cost of network access can be very expensive. A few bytes every minute (or however frequently you check) can add up.

So, breaking the rule may mean you run the users battery down and push up their data charges. See, I told you polling could be bad!


What about the alternatives?

There are a number of alternatives but their usefulness and availability depends on the platform you are using and the particular scenario.

If the application needs to be notified when something changes remotely this could be pushed from the remote location. This could be done with true push messages or with in a cruder method such as HTTP long polling.

Some platforms offfer the ability to subscribe and respond to system level events. This may be a change in the time, network connectivity or something else. This can be a very effective alternative to polling when it's available.
Subscribing to the hour changing can put much lower demands on the resources of a device when compared to running a timer which will only fire once an hour.
Subscribing to notification of email or SMS being recieved can be a good time to also check for new messages, etc. as there is a much greater chance of a network conenction being avaialble (You hadn't forgotten that you need to account of occassional connectedness - I'm sure.) It's also more likley that user will be in a position to see any new message and react to it - as they've just responded to an email or SMS notification.

Or check when the device is woken from sleep (if the platform offers the ability to detect this). This avoids the need to update status or list of unread messages when the screen is off and the user won't see them.

There is of course another scenario which is important to remember: when you must used timer based polling because the platform does not provide any other way of implementing the functionality. Obviously in this scenario you have to use it. Just make sure that you are aware of the consequences.

If you must poll, reconsider how often you do it. You can probably do it less often than your users think you need to ;)

To summarise:
Use polling when you must. But, avoid it if you can. And see if you can do it less often.

[WP7Dev] in 7 minutes

msdev.com have posted a number of short videos (each around 7 minutes in length) about Windows Phone 7 development under the title of Windows Phone 7 in 7 minutes!


Introducing Windows Phone 7
Getting Started with Windows Phone 7
The Windows Phone 7 Application Architecture
Silverlight and Windows Phone 7
XNA and Windows Phone 7
Windows Phone 7 Controls

Connecting to Web Services

Windows Phone 7 and Data

Using Isolated Storage

The Application Bar

Developing for the Windows Phone 7 Web Browser

Globalization and Localization

Building a Location-aware Application

Push Notifications

Security and Windows Phone 7

Using the Accelerometer

Using Media in Windows Phone 7 Apps

Manipulations

SIP Layout

Using the Windows Phone 7 Cameras

[WP7Dev] What do developers still want?

The RTM version of the Windows Phone 7 development tools are now available for download. But what do the people who are using them think is still missing? What do developers really want added to the platform?

At the last WPUG meeting I asked some. Here are the results:

The most popular requests:

• Cut & paste / clipboard support x7
• Background processing / 3rd party multitasking x4
• Camera APIs x4
• Contact detail access (people hub integration) x3
• Built in barcode scanning x2

Other requests:

• A built in Physics engine
• A complete implementation of HttpWebRequest
• A personal details card that could be passed to apps to fill in my details
• Ability to change system wide background colour
• Access to tile sizing
• Dynamic language support
• Good twitter stuff
• Integrated security with user's Windows Live account
• Jump list silverlight control
• Managed Facebook wrapper
• More Metro integration from within XNA
• Peer comms
• Shared data between apps
• Built in animations
• SQL DB
• Swipe navigation elements
• VOIP
• XPath

And then the things that people didn't realise were already there:

• Bing Maps control x3
• Multiple calendars
• Pivot & Panorama controls
• Support for accelerometer in XNA
• OTA Updates

I'll let you draw your own conclusions from the results...

Thank you NEBytes

Yesterday I went up to NEBytes to talk about Windows Phone 7 development. (Were you expecting me to talk about something else?)

I had a really great time and the audience seemed engaged and had lots of questions. (Which I take as being a good thing.) Thank you to the NEBytes teams for inviting me and organising the event.

Looking forward to the other user group talks I'm doing in the next few months. ;)

Polling is a smelly anti-pattern!

 As someone who reads my blog I'm sure you're well aware of good practices around mobile development so this won't come as a surprise to you.
In response to a question on Stack Overflow, today, I wrote the following.

"Polling a server from a mobile device is at best a code smell but typically an anti-pattern as it has resource usage (and possibly performance) implications."

It seemed worth repeating. ;)

How all EULAs should be written!

I haven't even finished installing Geosense for Windows but I love it already. Why? Because of their "lengthy license agreement".
I've copied it below:

Geosense for Windows
(license agreement, last updated February 26, 2010)

You cannot:

• redistribute or transmit the software for profit purposes without permission. (We're nice people, so just ask.)

You can:

• use the software for personal and commercial purposes.
• make copies of software for backup or archival purposes. (We won't lose our copies, so don't worry too much.)
• redistribute or otherwise transmit the software for non-profit purposes.

(Sinofsky was here.)

The "I agree" checkbox is even labelled nicely: "I authorize you to slap me if I violate the terms above"

It's so nice to be treated like a real person and be given something I can understand without needing an army of lawyers and a complete lack of a sense of humour.

Why would you use PhoneGap for WP7Dev?

I've had more positive feedback about my PhoneGap code than I was expecting which is all very good, but a lot of people are still asking me "Why would you use PhoneGap to cerate a Windows Phone 7 application?"

There are two reasons:
1. You have a really, really good reason to want to develop with HTML & Javascript, rather than C# and XNA or Silverlight.
2. You want to create an application that will target multiple mobile platforms and you want to only write the code once.

It's this second option which PhoneGap was created for.

And for balance, here are some reasons for not using PhoneGap to create a Windows Phone 7 application:

• You want to use some functionality which isn't available in the PhoneGap implmentation (and plug in support doesn't exist yet)
• You want to use the power of Silverlight and XAML for creating your UI.
• You want to use the power of XNA to create rich 3D graphics.
• You want the benefits of using Visual Studio and Expression Blend.

[WP7Dev] PhoneGap and Windows Phone 7

For all my talk and activities around Windows Phone 7 I'm aware I've shown very little about what I've been working on. Here's where I start to address this.
As you may have guessed by the title of this post, I've been looking at adding Windows Phone 7 support to PhoneGap.
For those of you who aren't familiar with PhoneGap it is "an open source development framework for building cross-platform mobile apps". It works by enabling apllicaitons written using the universal languages of HTML, JavaScript & CSS and compiling them into native apps for each supported platform.
I first used PhoneGap early last year when I needed to produce some proof-of-concept apps for the iPhone and I didn't fancy spending the time moving code to objective-C which I already had in JavaScript. (For the project in question it just wasn't worth the effort.) In the intervening time I've kept an eye on the PhoneGap project but not done much with it. I looked at its Windows Mobile support but didn't feel particularly motivated to do much with it. With the release of WP7 I found new interest in the project and am keen that apps developed for other devices/platforms can (where possible) be migrated to WP7 also. I have therefore written some code to try and implement this.

For those that are interested, the code can be found at http://github.com/mrlacey/phonegap-wp7. I know that others have started some work on this also. (Most notably at http://github.com/filmaj/phonegap-winphone.) I thought I would share what I've been doing to help the project. I'd already got further than the version by filmaj when I became aware of and have solved some issues they haven't dealt with yet.

So what is implemented?
In theory the easiest way to show what is implmented is show some test results. So here we are:

It passes 76 of 98 tests. Not bad. (Even if I say so myself).
As it's a shorter list, the tests that fail are the ones which relate to: HTML5 Storage, Contacts, File IO, Maps and methods which require objects being passed in their callback functions.
Some of these could possibly be implemented (File IO and possibly maps) but others just can't, due to limitations of the web browser control and the available APIs. Due to the way that interop with the browser control is implemented it's only possible to pass strings between the JavaScript and the C# code, it's not possible to pass objects to callback functions directly. In my code I have other functions which act as a wrapper to the callback functions so that they are passed appropriate objects but the automated tests don't pick this up.

It's probably a good time to point out that all I've done has only been tested in the Beta emulator. (I'd love to have a real device to test this on. Hint, hint!) Because some functionality requires can't be tested in the emulator, some of it is untested (e.g. navigator.notification.vibrate()) while other code always returns the same default values in the emulator.


How much functionality is implemented?

The following functionality is documented as supported across all platforms which PhoneGap supports:
Accelerometer: GetCurrentAccelleration is implemented but the watcher functions are not as these cannot be tested in the emulator.
Camera: getPicture is implemented but currently doesn't work properly as tombstoning of the app currently means that we lose all javascript references and so we don't have access to the callback.

Supporting tombstoning is the biggest issue with the current code. This could probably be worked around by storing all relevant callback details natively so they could be kept in state across deactivation/activation but I'd like to get some feedback on what I've done so far before spending more time on this.

Device: All features are implemented in JS, but limitations of the WP7 API currently mean that not all details are populated. It should be possible to get theses details with the release version of the API.
Events: deviceReady is not implemented as I have been unable to find a way to create events in the browser. It seems this can't be done, so I have implemented the PhoneGap.available property as a test for confirming loading.
Geolocation: getCurrentPosition is implemented (but returning a hardcoded vallue in the emulator). The watcher functions are not implemented as these cannot be tested in the emulator.
Network: this is implemented
Notification: this is fully implemented.

Additionally, the following other features are also implemented:
DebugConsole: log, warn and error methods
Orientation: getCurrentLocation and the watcher functions (as these can be tested in the emulator)
SMS: Send - triggers the compose functionality
Telephony: Call - triggers the request to make a call


To enable demonstration and testing of the implemented functionality I've created a simple app which demonstrates all the implemented features.

What else?
Other points of note in the code:

• While it's possible to load a file included in the project (in the webbrowsercontrol) any files loaded this way can't reference other files (JS, CSS, image or ohter HTML files) A partial work around is to try and merge all content into a single file but this can't deal with images. The browser doesn't currenlty support the data protocol but will in the next version (according to an email I've had from the team) so we would have to live without images if we went that route. The alternative is to load all content into Isolated Storage and view it from there. This is what I've done. Also rather than specify all the files to load manually (I couldn't find a way to query these from the XAP) I'm using a T4 template to generate the list of files to load.
• I'm using a command pattern to handle the different feature implementations. I'm using an abstract base class (PhoneGapCommand) for the commands and two optional interfaces to manage the variations in types of command (IAsyncCommand & IWatcherCommand). This works pretty well but feels like it could be better. I'm keen to discuss/explore alternatives to this.
• I've implemented a custom back stack to support navigation between pages. This recreates the behaviour you'd see elsewhere if navigating between XAML pages or html pages in IE.
• Because of the time it can take to load all the files to Isolated Storage and to prevent the webbrowser control being shown before the content has all loaded correctly I've had to implement my own version of the splash screen image. To use this the image must be set to a resource. In my code I have renamed the sample image to make this more obvious.

What next?
Ideally I'd like to contribute this code to the core project but I guess that will depend on what else others have done in terms of WP7 support.
There is also the key issue of how to work with (not around) the application model and how it affects javascript which really needs addressing before this could be considered publicly usable.

Please feel free to leave any feedback in the comments below, or in the discussion I'm about to start in the Google Group.

4 touch points!

Just wanted to clarify something for a few people.

The Windows Phone 7 hardware specs state a MINIMUM of 4 concurrent multi-touch points. This is not a maximum as many people have being saying.

In theory OEMs could produce devices which support more than 4.

I just wanted to clear that up and warn anyone off hardcoding any support for a maximum number.

Will Windows Phone 7 be successful?

A few days back I posted a comment on this computerweekly.com article about Windows Phone 7. I had some positive feedback about my comments via twitter - including the following from the author of the article:

"how long have I been doing this - 15 years? Quite the longest & most powerful comment I have ever seen. Thanks VERY much!"

I thought I'd repost some of it here:

Is Windows Phone 7 going to be popular enough to be worth considering developing apps for?

Obviously no one knows the answer for sure yet, but as you've probably guessed, I think they will be popular enough to invest my time learning about and developing applications for.
But why?

• They are amazing devices. Please don't write them off till you've used one.
• Microsoft knows this industry. Windows Mobile was really good back in the day and while they've drifted off course in the last few years all the evidence seems to be that they've been carefully watching the market change around them and learning from it. And they've also been learning from their own experiences. (Arguably, while Android re-make a lot of the mistakes which were made with Windows Mobile.)
• Windows Phone is designed specifically for mobile use in a way that we've not seen on other devices before. Plus it's not trying to be something it isn't or shouldn't be - a PC on phone hardware.
• Microsoft has spent the last 5 months trying to convince developers to build apps for the phones. And developers have been responding. There will be a lot of high quality apps available in the marketplace when the devices launch.
• There are also a lot of desktop and web developers who are currently using Microsoft technologies who are keen to build for mobile as it
• The (fully transparent) marketplace policies Microsoft are putting in place will ensure the quality of applications and avoid data security issues which are notorious on some other platforms.
• Despite all the criticisms of a lack of hardware variations there are a lot of manufacturers signed up to produce devices. The fact they think they can make money selling devices which many think will be hard to differentiate from those of a different manufacturer should be seen as a string endorsement.
• The email and calendar integration puts almost all other devices to shame. I've heard lots of people who have used actual devices say that they'd get one for that reason alone.
• Xbox Live integration is a strong selling point for a lot of mobile gamers.
• Microsoft is not afraid to try new things. And learn from them and move on if not successful. (Cough-Kin-cough)
• Microsoft can't afford not to be successful. Mobile is the future and Microsoft needs to be there if they are to survive long term.
• Plus I've heard from trusted sources what the ballpark marketing budget is. (My lips are sealed though.)
• I've also noticed that a lot of the people who are panning the phone are the same people who said the iPad was pointless and no-one would ever buy one. ;)

WPUG: the first meeting

You may remember that previously I mentioned that I was looking at setting up a User Group focused on Windows Phone development.

The good news is that the group had it's first meeting last week. You can read all about it at
http://wpug.net/2010/07/31/the-first-meeting/

WP7 Panoramas are not the same as hubs

There seems to be some confusion about hubs and panoramas, in Windows Phone 7, as many people think they are the same thing. They're not, but let's see if I can clear things up a bit.

Firstly a panorama or panoramic tile. (Please don't further complicate this by confusing this with a live tile though.)

This is the very wide display (typically 4 screen widths wide) that the user can swipe from side to side to navigate. Vertical scrolling is not supported. The background is typically a single picture.

Sample/Example panorama from the UI Design and Interaction Guide for Windows Phone 7 v2.0

A built in control will be provided for developer use in the next/RTM version of the SDK. But, for now, a very good alternative (and very similar to what will actually be shipping) can be found at http://phone.codeplex.com/.

So that's a panorama. It's simply a display and list control for use within an application.

So what about hubs?
Hubs are special applications which come on the device and serve as a central point for collating content, information and applications which are all focused on a single area.
The phones come with 6 built in hubs:

• People: for contacts and social media update integration, etc.
• Pictures: for photos taken on the device and synced from facebook or live.com
• Office: for OneNote, Word, Excel & Powerpoint
• Games: for all games (unsurprisingly) and including XBox LIve integration.
• Music + Video: no prizes for guessing what goes here
• Marketplace: for buying lots of lovely apps, games, music, etc.

As an aside it may be useful to note that only the 'Pictures' and 'Music + Video' hubs offer any level of third party application integration.

So why the confusion?
Because all hubs use panoramas in their main screens.
I strongly suspect that as developers couldn't make their own hubs, nor have they been provided a panorama control, this has no doubt led to the grouping together of these two things in peoples minds.

Anything else?
Well yes. It seems that developers may be able to develop their own hubs in the future after all...
  Windows Phone 7: Developers can build their own hubs
  Windows Phone 7: Microsoft explains and expands hubs



Has that cleared things up now?

Phoebe!!!

If you haven't seen the photos posted on Facebook or elsewhere then here are a few:

[WP7Dev] Why there's no built in integration for Twitter and the people hub

Warning: This post is speculative and my own assumptions. It is not based on any inside knowledge.

When people hear that (in addition to live.com) Windows Phone 7 only currently supports Facebook as an integrated information store. They often wonder why there's no built in Twitter support/integration with the people hub.

I'm not aware of an official reason, but as the question seems to come up so frequently I thought I'd document my thoughts on possible reasons.

1.  To preserve battery life
This is the most obvious reason I can think of. If you're following hundreds of people all around the world and they're tweeting regularly that can be dozens of updates every minute. (If not more!)  All those updates will soon add up to lots of network traffic, processing to handle them and space to store them. Then there's the issue of propogating the most important ones to the users attention. These are issues that I think are better solved by third parties, thereby leaving Microsoft free to focus on other parts of the OS.

2. Because everyone else is doing it
My next thought is based on the fact that everyone and his dog seems to be building a twitter client themselves. For many this seems to have become the new "Hello World" app. With so many other apps already in existence and each offering different features, having something built in at best would lead to duplication or at worst could stifle innovation by causing people to not create something new when part of the functionality is already on the phone. Having to deal with the moving target that is the Twitter API can also be an issue.  If it introduced any new breaking changes or major changes it'd be tough


All that aside, I have heard reports that Microsoft are talking with Twitter about how integration could work in the future.

Silverlight effects and Windows Phone 7

Note: As Christian pointed out in the comments, effects were not included in the released version of the SDK.

Windows Phone 7 allows us to create the UI for an application in Silverlight. (Or in XNA but just now I'm focusing on Silverlight.) Silverlight is known for it's excellent visual capabilities and ability to easily create great graphical effects. Let's look at what's available to us in Windows Phone 7.

Windows Phone 7 supports 3 effects: BlurEffect, ShaderEffect and DropShadowEffect. Silverlight (on the PC/Web) also specifies a PixelShader but this is not supported on the phone.

Effects can be applied to any UIElement but lets see how the BlurEffect and DropShadowEffect can be applied to a TextBlock. (A ShaderEffect is a bit more complicated and there's an example in MSDN.)

Here's a TextBlock you may recognise from a new "Windows Phone Application"

<TextBlock Text="page title" x:Name="textBlockListTitle" Style="{StaticResource PhoneTextPageTitle2Style}" />

And it (in the designer and emulator) looks like this:

Adding a BlurEffect is as easy as this:

<TextBlock Text="page title" x:Name="textBlockListTitle" Style="{StaticResource PhoneTextPageTitle2Style}">
    <TextBlock.Effect>
        <BlurEffect Radius="10" /> 
    <TextBlock.Effect>

<TextBlock>

which creates the following effect:

Or we can add a DropShadowEffect thusly:

<TextBlock Text="page title" x:Name="textBlockListTitle" Style="{StaticResource PhoneTextPageTitle2Style}">
    <TextBlock.Effect>
        <DropShadowEffect BlurRadius="15" Color="Azure" Direction="325" ShadowDepth="10" />
    <TextBlock.Effect>
<TextBlock>

to create:

Both those effect images are from the designer. But if we look at them in the emulator we see this:

The effect isn't applied.
Don't be fooled. This isn't an error or limitation of the emulator. This is what gets rendered on the phone with the above code.
Fear not though. It's a simple fix. Simply set the CacheMode on the UIElement that the effect is being applied to to "BitmapCache".
Like this:

<TextBlock CacheMode="BitmapCache" 

Then in the emulator we see:

and

So why does this work?

I haven't been able to find out the official reason, but here's my educated guess. If I find out the official reason I'll update this.

Silverlight (on the web/PC) always runs in the UI thread (unless you create any others yourself obviously). On the Phone it's different. The phone has two "main" threads. The UI thread and the "Render" thread which is used by the GPU. (Non-phone Silverlight may not always have access to a GPU while the phone always has one.)
Because the phone runs in a constrained environment it's important for it to be small. It therefore doesn't make sense for things to be specified twice when they could only exist once. I suspect that the ability to generate the effects is one such thing.
As a visual effect it makes sense for it to be calculated/generated/processed by the GPU so having the ability to also produce the effect by the process generating the visuals on the UI thread (the CPU) would just be unnecessary duplication.
Setting the CacheMode to BitmapCache forces the UIElement to be rendered by the GPU (as only it can handle Bitmap caching).
Of course it would be nice if the framework could also realise that these effects can only be applied by the GPU and so automatically use it to render them. Maybe this will be addressed in the future. Until then, at least we now know the work around.

What about the display in the designer?
Well that's WPF running on the desktop and handles the applying of effects without the need to force their rendering by a special process(or).

DevEvening and DDDSW presentations on Windows Phone 7

Below is a version of my slide deck from the presentations I gave last week at DevEvening and at DDDSW. I appreciate that the slides aren't particularly informative as they are mostly just images but hopefully this will be useful as a reminder of what I said at least.
As some people have asked for the stats I used and some code examples I'll hopefully post those soon too.
Why care about mobile? And what is Windows Phone 7?


Some pics from DDDSW, courtesy of Craig Murphy.

These images from http://www.flickr.com/photos/craigmurphy/sets/72157624102207839/