Matt Lacey: Awesome with Windows Phone

Want to build an app, but don't know what?

2013-05-21T11:48:00.000+01:00

I've spoken with a number of people recently who want to build an[other] app but they don't know what.

Does this sound like you?

If so, check out IdeasProject.

Officially:

IdeasProject is an online global community of people who have a passion for brainstorming and creating innovation. The community enables the exchange of ideas among mobile enthusiasts, designers, developers and incubators. IdeasProject is based on co-creation through Open Innovation and has delivered consumer inspired applications and mobile technologies.

What that means is it's a place where people with ideas go when they want help to help with developing an app.

If you're stuck for ideas it could be just the palce for you.

Also, if you're a member of DVLUP then some of the suggestions from IdeasProject become challenges there, which can help you earn extra XP which in turn can be exchanged for "fabulous" goodies.

Champions, Ambassadors and MVPs

2013-05-14T02:07:00.000+01:00

Nokia and Microsoft use these titles to identify certain people and reward certain community members. Quite what the different terms mean can be confusing though. Let me clarify.

Nokia Developer Champion
Someone who does not work for Nokia but is recognised by them as an exceptional member of the developer community.

Nokia Developer Ambassador
Someone who works (usually part-time) for Nokia with a responsibility for helping people create apps.

Microsoft Valuable Professional (MVP)
Someone who does not work for Microsoft but is recognised by them as an exceptional member of the developer community

Microsoft Windows Phone Champion
Originally this term referred to people who work for Microsoft who could serve as a point of contact for people wanting help with Windows Phone development. This term is also now includes Windows Phone developer MVPs too.

I hope that's clear now.

Windows Phone app submission "signing failed"

2013-04-22T22:28:00.001+01:00

If you ever get a submission report like this (above) it can be quite disconcerting. It's realisitic to think that you may have done something wrong or missed something that caused this.

If you get this it can also be hard to know what to do next. The dev center will provide no more information and there isn't a lot in the forums either.

If this happens to you though, fear not. If you've run the xap through the store test kit and verified capabilities and requirements there could be another reason for this status.

Simply try uploading the XAP again. You may get this if there was a problem (corruption?) during the upload process.

It worked for me :)

I'm speaking at MobDevCon in July - Tickets on sale now

2013-04-22T21:08:00.004+01:00

On July 3rd, Naked Element will be hosting Norfolk's first ever Mobile Developer Conference. I'll be there to speak about Windows Phone and application pricing.

Early bird tickets are now on sale from http://mobdevcon2013.eventbrite.co.uk/#.
You can find out more about the conference at http://mobdevcon.com/

Why Windows Phone isn't more popular - the view from the phone shop

2013-04-03T19:40:00.001+01:00

I know there are lots of people developing apps for Windows Phone who bemoan it's small marketshare. There are lots of opinions on the success (or lack of-depending on your perspective) and these are often informed based on the perspective of the person talking. That is, developers typically think from a development perspective, etc.

Last week I had the opportunity to talk with a number of people who have a very different perspective to me and a different view of the mobile marketplace. I got to speak with a number of people who work in the operator, and independently owned, stores where a large number of people get their phones. They advise people on what phones people should get and know exactly what people are after when they choose a phone.

When asked about Windows Phone they were generally positive about the platform and spoke highly of the cheaper devices (Lumia 610, 620 & Ascend W1) and have seen some of these sell faster than they can stock them. It's when I talked about apps that things got interesting though.

There were 4 key points that I think developers should take note of (even if there is one that they probably can't do anything about themselves.)

1. The number of apps on a platform doesn't matter to people buying phones
700,000, 500,000, 130,000 - they're just big numbers and don't really impact purchasing decisions. I suspected this was the case. They're just a useful metric for journalists to compare platforms. I suspect changes in the rate of new submissions and updates is a more useful metric for platform health but harder to obtain than number of apps in store.

2. Having certain apps on a platform matters
While the total number of apps isn't seen as important, there are certain apps which are seen as essential. These fall into two categories: communication and flavour of the month.
Apps which enable communication between users on different devices (be that text based messaging, voice calls, picture calling or anythign else) need to be on the platform. If a person choosing a phone used a certain app on their old phone and all their friends/contacts use that app too (on other platforms). They won't choose a phone which doesn't have it. It'd mean being unable to communicate with their friends/contacts and isn't that the primary purpose of a phone anyway-communication?
"Flavour of the month" apps are those that everyone is talking about and using right now. Be that a game (usually it's a game) that allows you to throw animals, guess words or draw pictures, if "everyone" you know is talking about and using such an app you risk being left out if you can't get that app too. Coming to a platform 6 months after everyone elase has stopped talking about or even using the app doesn't help.
These may seem trivial issues and you could argue that there are alternatives available, but these are things that affect the phone people choose!

3. Feature parity matters
If an app is on multiple platforms but doesn't have the same features users can feel tricked. Say, for instance, you and your friends use a certain app for group messaging of texts and photos. If you get a new phone and have been told that it supports that app, it'll reflect badly on both the app and the phone if you get home to discover that the app on your phone only supports text messaging and not picture messaging as you'd suddenly be excluded from certain conversations. Not something you or the people using your apps want.
If an app is missing key features it would be better, in some peoples eyes, if it wasn't there at all!

4. Quality matters
While the number of apps doesn't really matter, the quality of the apps that people do choose to use does.
Windows Phone apps are generally perceived as being of a lower quality than apps on other platforms - people you need to raise your game!

What can we, as developers, take from this?
Three things:

Focus on quality, not just quantity.
Support multiple platforms. Especially if there's a social aspect to your app.
Aim for feature parity (especially core features) when moving to multiple platforms

Where to get icons for your app?

2013-03-30T21:07:00.000Z

So, you need some icons for use in your app.

If you just need icons for the application bar buttons, then start with the ones that come with the SDK. You'll find them at "C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Icons\Dark\" and these are also the ones that Blend can add for you.

If you need more then there are a numberof free resources available:

Metro Studio 2 (By SyncFusion)

It's a downloadable app that comes with 1700 FREE icon templates that can be sized and modified as required. You can see all the icons at http://www.syncfusion.com/downloads/IconPackagePopup/Application

The Noun Project

Loads and loads of icons that you can search online. Download what you want in vector formats. Most are creative commons licensed and/or very cheap to license. (I've never paid more than $1.99 for an icon there.)

Modern UI Icons

A collection of almost 1000 free icons. They're availabel sized for the application bar and in vector formats.

iconmonstr

1300+ icons thast are free to use in personal and commercial projects. They're also helpfully categorized to make it easy to find what you're after.

There are also other sources and you could always make your own or commission an icon if you needed something special.

As an extrs tip, it's usually best, as far as possible, to get all your icons for an app from the same source. This helps make it look like they all belong together. If you have small/subtle differences between icons (e.g. differing line weights or the radius on rounded corners) then some people will spot this and will think it looks bad. Remember, the little details matter.

Microsoft's advice about Panoramas is wrong!

2013-03-28T13:45:00.000Z

The advice Microsoft's designers will tell you (23:30 into the video) about a page hosting a Panorama control is that the page should not also include the System Tray.

This is wrong!

Let me tell you why.

Consider this scenario:

A person launches your app and upon starting it attempts to load the latest data from a web server or other external source. - Hopefully you'll agree that so far this is a reasonable and common scenario.

After a few seconds no data is displayed and the app still indicates that it is "Loading...". - Again, a common occurrence.

Now what?

Well, the person wonders if the delay is due to not having a connection or maybe they've only got 1 bar on a 2G network. - I hope you still think this is a not unreasonable scenario.

So, having wondered about connectivity, what does our person do?

Well, they swipe down from the top of the screen to reveal the network connectivity indicators that are included in the System Tray.

And it's at this step that we reach the crux of my argument.

If the page includes the System Tray the person will be able to see the state of their connectivity. If they have a connection they'll probably wait a little longer. If not they can, hopefully, do something about it.

But if the page doesn't include the System Tray what can they do?

They can do 1 of two things.

1. They can wait longer, but with the uncertainty of not knowing if the connection is there and if they'll ever get a response (at least until the connection times out.)

2. They can leave the app and check connectivity there.

If 1, you're forcing the person using your app into a situation of uncertainty with your app that can't be a good thing. Uncertainty in what your app will do, or when, is not a feeling you want to instil in people.

If 2, you're forcing people to leave your app when they want to use it. You're also increasing the likelihood that they won't come back. I'd be amazed if you want the people who have downloaded and installed your app to not be using it when they have wanted to.

My advice:

Include the System Tray on any page that has content that comes from a remote source.

Microsoft doesn’t even follow their own advice!

Checking on the WP8.0 device in my pocket I can see that:

While the store, music and video hub, games hub, photos hub and wallet don't include the system tray, the People hub and the Office hub DO include the System Tray

The exception when this isn't true.

My reasoning above is based on a Panorama with dynamic content that is obtained from an external source. Obviously there are apps which use a Panorama control but don't use external content. (I've even written some.) In this scenario there is, potentially, very little value to the including the System Tray and so there may be an argument for not including it.

Yes there is potentially an argument for including a System Tray even if the Panorama uses entirely local content so that it's possible to see things like the clock and battery status. Include it at your discretion in these scenarios.

Disclaimer. Yes the title of this post is quite broad-brush and I'm only talking about a potentially minor issue here. I understand that but small details matter.

tl;dr: DO include the System Tray on Panoramas. Even though Microsoft tell you not to.

10 Tips for designing your mobile APIs

2013-03-22T09:15:00.000Z

It's common for a mobile application to need to communicate with a web/cloud based service. At its simplest this will be just to retrieve data but it could also include sending data and user authorisation and management.
If you have to build the API that your application will use the following tips may be useful:

1. Version your API (from the very beginning)
At some point in the future the API will need to change. This may be to add, remove or change functionality. When this happens you may have to stop the use of part of the API or allow the consuming application to be clear about which behaviour, and type of response, it is expecting to be returned.
Your API is like a contract between your backend and the apps that use it. Without proper versioning you are risking the situation where one party can change the contract without the other even knowing. Having support for multiple versions of the API you can also continue to support users of your application who haven't been able to upgrade to the latest version of your app that uses the latest version of the app that knows all about the latest API changes.
Without versioning of the API you make it much easier to, inadvertently, stop applications working when changes are made to the API.

2. Don't return more data than you need to
The amount of data that is sent between the application and the server will, to some extent, impact the time it takes for the request to be made and the response to be received. Not only does this impact the amount of time a person spends staring at a loading animation, it may also impact the amount they spend on data charges.

3. Compress the data that is sent and received
In addition to not returning more data than is necessary, by compressing the data that is sent you can experience further benefits in speed and cost of data transfer.

4. Don't require unnecessary steps/requests
It's very common for APIs to be designed to provide separate discrete steps that reflect how the service is intended to be used. Quite often though, such discrete steps aren't the most efficient way of implementing a mobile application.
Let's take a simple example. Imagine the situation where a user has to log in (provide valid credentials) before being able to request data. It would be perfectly reasonable and understandable to think of this as two separate steps:
Step 1: The credentials are provided and, if valid, the API responds with a session token.
Step 2: The session token is passed when the request is made for the data.
That's probably unnecessary though. It would be much better if a single request could be made, passing credentials and the details of the data that is desired and, assuming valid credentials, both the data and a session token, for use in future requests, are returned.
The benefit of this is that fewer requests are faster and cheaper for the person using the app and may also (depending on how it's implemented) lead to simpler application code, which can lower development and support costs.
This may mean that you have to build the API to support both types of usage. This may lead to higher costs to support, document and maintain. But, if you're building your API just (or primarily) for your own use this may be more acceptable.

5. Combine requests (and responses)
In addition to multiple requests being made as part of an authentication or app start up process, it can also be common for multiple requests to be made to retrieve all the data for a single page or view in an application. Making a single request for all the data that a page requires, will be faster and cheaper than making multiple calls. Both factors that will be seen positively by the people using the application.
Again, this can also make the application code simpler. Especially with regard to handling the situations where multiple calls are made and not all of them are successful. If it becomes an all or nothing scenario the exception cases become much simpler.

6. Consider security from the beginning
Security is a massive and potentially complicated subject. This makes it particularly difficult to add on in a hurry in response to a security issue.
Remember to consider: securing data in transit; securing your data at rest; inappropriate or unauthorised use of the API; and potentially malicious or unexpected data having unintended consequences.

7. Plan and implement your caching policy carefully
If the data your API returns doesn't change very often be sure to implement appropriate caching strategies. This could involve keeping data in memory, rather than repeatedly reading it from disk. This should almost certainly involve the caching capabilities that are part of HTTP (assuming that that's the protocol you're communicating over).

If you do implement caching on your server, be sure to offer a way to forcibly invalidate it though.
Also make sure that you implement appropriate caching in the client application that consumes the API. You save time and resources if you can make a call and be told to keep using the data that was returned last time. You save more time and resources if you can avoid making that call in the first place.

8. Integrate analytics
Analytics are an essential part of understanding how an application is used. It's common for calls to an analytics service to be made in addition to the requests for data that are made during normal use of an app. For instance, if the app will attempt to call the server to refresh the displayed data on a page every time that the user navigates to that page then there is redundancy in adding a separate tracking/analytics call to track navigating to that page as well.
At its most primitive, the use of the API can serve as an indication of how and when the application is used. At the other end of the scale there are rich analytics tools and frameworks which can provide very detailed information about how users interact with the app. If you're somewhere in between then think carefully about how or if you're making additional/unnecessary calls purely for the purpose of tracking usage when you could get this from the calls made as part of the usage of the app.

9. Consider names carefully

The names you give the methods, objects, properties and parameters of your API will greatly impact the way those who are using the API understand it. It can be very tempting to use whatever terms or wording first come to mind when creating the API. As with all code though, the words you use play a great part in how the API is understood and expected to behave. Poorly named APIs can be a great source of confusion. Confusion leads to mistakes, mistakes lead to bugs, bugs lead to delays and support costs. Spend time on naming.

10. Don't forget your privacy policy and responsibilities
If you're capturing user data (and if you have logging on your server to record requests then you are) you need to have a privacy policy that details how you'll use the data. You'll also need to think about how you store and protect that data. Especially if it's personal and/or belongs or relates to children.

Debugging binding issues is hard. Having simpler code makes it easier.

2013-03-20T23:28:00.000Z

Recently I had to deal with a strange bug.
Sometimes the menu option to create a secondary tile was not being enabled when it should be.
After analysis I was able to get the most consistent reproduction of the issue on a lower spec device (a Lumia 620). Obviously this isn't acceptable so a solution had to be found.

I tracked the most likely candidate to the `CanPin()` method. You can see the "before" version below.
You'll notice that it "smells" of all sorts of issues. It's also not something that can be debugged or instrumented easily.
It also isn't immediately obvious how it works because it's not easy to read.

There's definitely the possibility for something funny to be going on there.
Could all those checks be being made in an order differently to how they're listed?
Could there be a bug in the logic?
Could the time it takes for them to be run be taking longer than is available to trigger the binding to update?

The only option available is to refactor to make the method clear about what it does and in what order.

And, as if by magic the problem went away.

So what was the problem?
I can't be 100% certain.
But I'm not sure that matters.
That well written, easily understandable code doesn't display unexpected, unintended consequences--that's a good thing. Why badly written, hard to undertand code has certain unintended consequences--isn't a priority for me just now.

This leads me to be reminded of three important lessons:
- Debugging binding issues is hard (Bind to simple properties to help avoid binding issues.)
- Simple code is better (both to debug and to maintain)
- Be sure to test on real devices (both low and high spec)

TL-DR:
Bind to simple properties to help avoid binding issues.
Write code that is easy to read so it's easier to maintain in the future.

3 MiFi topup fail

2013-03-20T20:41:00.002Z

One of the devices I have to keep me and my devices connected to the Internet is a MiFi unit (portable access point) for (UK network) 3.

I don't use it very often but sometimes I can't use Wi-Fi or Internet sharing from another device. Today was one of those times so I got out the unit and, as I have it on PAYG (because I don't use it enough to justify a contract) I attempted to top up.

I turned on the MiFi unit and paired with a device, a Nokia Lumia 620. All good so far, then I opened the browser to be automatically redirected to the top up site.

1st problem - I was given the full site, as I'd expect on a PC or other large screen device. This meant I had to wait ages for the page to download (over HSDPA) and render on a device which wasn't suited to displaying all that content and wasn't related to the task I was trying to achieve.

2nd problem - I had to go through lots of unnecessary steps/pages to achieve what I wanted. The page I was initially taken to had what looked like 4 big buttons for each of the available top up options. The only problem was they weren't buttons - just images. There was actually a text link to top up but I had to zoom into the page to see it. Clicking the "I want to top up" link redirected me to the account overview page. From there I had to click another I want to top up link. This took me to a page that provided a drop down list for each of the top up options. Selecting from this list caused the page to reload. There were then separate pages for selecting to use my preconfigured credit card and entering the card security code (CVV number). This finally led to another page for...

3rd problem - the 3D secure step in the payment process tried to open a page which had a mime type or other content that the phone couldn't display and so prompted me to visit the store to download an app to view the content. Of course, the problem here is that I couldn't connect to the store as I had no Internet connection. Even if I could connect to the store I doubt my credit card provider has an app that could allow me to complete the in browser transaction. In fact I don't just doubt it - I know it's not possible, at least not without having some Microsoft implemented changes to the browser and as the bank and card provider have nothing in the way of apps in the windows phone store, what are the chances that Microsoft have built something into the OS for them?

Ok, that's a partial HSBC/MasterCard and Microsoft/Internet Explorer failure but still, it's left me a very frustrated and disappointed customer. :(

I ended up getting out my iPad to top up.

So, rather than just moan about the situation, what can we learn from it?

Be smart about the content you serve to devices. Especially ones with small screens.
Remove unnecessary steps, page reloads and redirects from processes. Especially sign up and payment processes.
Provide, simple, easily identifiable short cuts to do often repeated tasks.

Yes these are all obvious and often repeated recommendations. I hope by repeating them again here it'll help someone remember them next time it's appropriate.

Online privacy when building apps for kids

2013-03-18T14:03:00.001Z

This weekend just gone I was at the Windows Phone 8 Lock-in organised by Dev4Good, so issues around apps for children and young people is on my mind at the moment. That's probably why this caught my eye:

http://momswithapps.com/category/online-privacy/

It's a set of resources relating to online privacy curated specifically for people creating educational apps for children. If you're building apps for this audience they're an invaluable read.

Azure Mobile Services error: "The request could not be completed. ()"

2013-03-17T09:13:00.000Z

Having just published my first (Windows Phone - obviously) app using Azure Mobile Services, I thought I'd share something I learnt in the process. When first testing on an actual device (always test on actual devices!) I hit an issue where the MobileServicesClient was failing with the following message being intercepted by the Application level UnhandledExceptionHandler:

"The request could not be completed. ()"

Notice the empty brackets at the end. In most cases (based on similar exceptions that others have reported and Google helped me find) these would include an indicator of the issue. Such as "(Internal Server Error)" or "(Send failure)".

The call stack wasn't much help either:

   at Microsoft.WindowsAzure.MobileServices.MobileServiceClient.CreateMobileServiceException(String errorMessage, IServiceFilterRequest request, IServiceFilterResponse response)
   at Microsoft.WindowsAzure.MobileServices.MobileServiceClient.ThrowInvalidResponse(IServiceFilterRequest request, IServiceFilterResponse response, JToken body)
   at Microsoft.WindowsAzure.MobileServices.MobileServiceClient.<RequestAsync>d__f.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Microsoft.WindowsAzure.MobileServices.MobileServiceTable.<SendInsertAsync>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Microsoft.WindowsAzure.MobileServices.MobileServiceTable`1.<InsertAsync>d__21.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
   at RadioNow.MainPage.<OnNavigatedTo>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__0(Object state)

Even when I wrapped all my uses of the client in try..catch blocks this exception was still only getting caught at the application level unhandled exception handler.

Anyway, the issue came down to the devicenot having Wi-Fi enabled and for some reason it wasn't using 3G ro USB passthrough to connect instead.

So, 2 lessons:
1. The WP8 AMS client might throw errors, based on connectivity, that you'll have to catch and deal with at an application level.
2. Be sure to check/test Wi-Fi connections on devices when tethered.

AccentComplimentBrush v2.0

2013-03-13T20:34:00.000Z

Yesterday I showed my new AccentComplimentBrush as a way of having a second color that can be used within an app and will work with whatever accent color has been chosen.

There was one big issue though. It only worked with the default accent colors in Windows Phone 8.

I've just pushed a new version to GitHub that is both forwards and backwards compatible.

It now works on both Windows Phone 7.X and Windows Phone 8.
It also works with operator and manufacturer defined accent colors. In fact it will work with any accent color whatsoever (yes, even for the people who've hacked in their own colors) as it now determines the compliment on the fly, rather than relying on a precomputed list of compliments.

Please enjoy.

Using a complimentary accent color

2013-03-12T21:38:00.000Z

Sometimes you may want to use two colors in an app. If it was just one then I'm sure you'd just go with the Accent color.
The acccent colors all work well when on Black or White.
The problem though is that there is no single other color that can be combined well with any accent color and you probably want black and white elsewhere on the page. What you really want to avoid is a design that looks bad with one (or more) accent color(s).

If only there was a way to have another brush resource available that would adjust to the selected accent color and work in compliment to it.

Introducing the AccentComplimentBrush
It lets you have another SolidColorBrush available via a an Application wide resource that will work with any of the default accent colors. The complimentary color is based on the exact opposite position on the color wheel. See how the two pairs all go together:

The accent color above and it's compliment below.

How do you use it?
Just 2 simple steps

1. Add the resource.
Get the file, add it to your project and then reference it. (Either at the application level or on a specific page.)

    <phone:PhoneApplicationPage.Resources>
        <mrlacey:AccentComplimentBrush x:Key="MustBeSetButCanBeAnything" />
    </phone:PhoneApplicationPage.Resources>

Note the key value I've used above. Resources must have a key, but we don't actually ever use it. Because of this, ReSharper (or equivelent) might try and tell you that the resource isn't used. It is. Usage just can't automatically be detected at design time it because it's implemented with some run time trickery.

2. Use it!
Just refer to it in the XAML.

    <TextBlock Text="accent"
                Foreground="{StaticResource PhoneAccentBrush}" />
    <TextBlock Text="compliment"
                Foreground="{StaticResource AccentComplimentBrush}" />

or in code:

(SolidColorBrush)Application.Current.Resources["AccentComplimentBrush"];

Important!
1. It currently only works with the default accent colors, not any added by the operator or OEM. If you use this and want some help with adding support for any accent color let me know.
2. Because it uses "run time trickery" it doesn't work with the designer (in Visual Studio or Blend). If you know a way that would allow design time support I'd love to hear it.

What do you think? Useful?

Update I've now made a version 2.0 of this code which supports 7.X too and will even work with OEM/MO defined accent colors.

Telford: done! Next it's Bristol.

2013-03-11T20:31:00.000Z

Last month I talked about Windows Phone 8 development at the university in Telford. Next week it's the UWE in Bristol.

The feedback from Telford was very positive.
There were 3 questions on the feedback form and each was marked on a scale of 1 to 10.

The talk was well delivered and I could understand the concepts discussed: 9.1 / 10
I got something out of this that I could use in a project, either in work or as a hobby project: 8.5 / 10
I would attend one of your talks again: 8.9 / 10

I'm particularly proud of those results considering only 1 person in the room with a Windows Phone 8 device and no one there had any previous experience developing for Windows Phone.

If you're in the Bristol area next Tuesday and are interested in hearing about Windows Phone 8 development,why not come along. More details, registration, etc.

NCLDR on Windows Phone 8

2013-03-08T12:00:00.000Z

Earlier this week, uber-UK-community-bod and I18n expert, Guy Smith-Ferrier announced the alpha launch of NCLDR.

If you're not familiar with CLDR you can think of it as being like a version of the Globalization parts of the .net framework with lots of added extras. NCLDR is a .net port that allows access to all these lovely goodies.

As is my way and because I was interested if I could use the data in a phone app so I attempted a port/conversion to Windows Phone 8. It's just a POC at the moment, but look, I can get a regex for validating postcodes for each (well most) supported culture(s). If you're capturing a postal or zip code in your app this would allow you to validate it on the device, regardless of which country it was in.

I'll be honest, it wasn't as simple as I'd hoped. There was a lot more work and work arounds needed to get it to work than I would have liked and if Windows Phone support was to be officially added it would be better to add it in early and maybe remove use of some of the types and methods which are not supported on the phone, to aid greater cross platform code reuse.

Here's the changes I had to make to get it to work:

Biggest issue: WP doesn't support BinaryFormatter.
Second but related issue: By switching to using a JSON serializer I was potentially making the data file even bigger. I countered this by only including the minimum I needed in the generated file. This no only made the data file smaller but meant I had to load less and so save on precious memory consumption.

Add missing System elements:

CultureTypes
DigitShapes
ICloneable
SerializableAttribute

Replace use of HashTable with Dictionary<string, string>. In:

Culture.cs
Numbers.cs

Replace verison of string.Compare that was used with a WindowsPhone supported version. In:

Calendar.cs
CultureData.cs
Currency.cs
CurrencyPeriod.cs
Language.cs
MessageSet.cs
NumberingSystem.cs
NumberingSystemType.cs
Numbers.cs
PluralRule.cs
Region.cs
RegionMeasuringSystem.cs
CultureInfoExtensions.cs
RegionInfoExtensions.cs

Added some null exception handling/wrapping/suppressing to the following (but didn't really look into why it was needed):

Language.cs
Calendar.cs
Region.cs
CurrencyPeriod.cs
NumberingSystem.cs
Script.cs

Hopefully unnecessary disclaimer: This is a quickly hacked together proof of concept on top of alpha code. Use at your own risk...

Why and what I blog about here

2013-02-26T20:59:00.000Z

I've been blogging here since August 2006. That's a long time (well it feels like it sometimes) but also shows I was late to the blogging party.
In that time I've used this blog for various things and covered a variety of subjects.
While there are still some exceptions, I mostly now write about Windows Phone related topics. Hence the current title of this blog. Yes it may sound a bit big-headed (but what is the web if not for self promotion ;) ) but the real aim is to help other people to be awesome with Windows Phone. Yes it's sometimes nice to blog things as a memory aid but I primarily write for others to read. Yes, it's nice when people (especially those I deem cleverer or most expert than me) let me know they found the answer to an question/issue/problem on my blog.

Why don't I blog more frequently?
Time. I just don't have enough of it and writing takes me ages. In fact one of the reasons for initially starting a blog was to encourage me to write more, in the hope of getting faster at it.

How do I pick content?
If we just consider the Windows Phone related content I post you'll notice something about it. That content isn't anywhere else online. I'm deliberately only adding to the cumulative knowledge of the internet. I'm not trying to duplicate it.
There are already lots of tutorials on getting started with Windows Phone development. The MSDN documentation is very comprehensive. I don't have the time to and see no real value in creating yet another set of getting started or beginner instructions. I see no value in reposting what is already on MSDN (Yes, I'm looking at a few certain people here!).
What I want to do is document what isn't documented elsewhere.

Who for?
I see two main audiences for my WP related content.
Primarily I write for the long tail. I hope that at some point when someone hits the same problem or reached the same undocumented issue they'll find my site (thank you Google) and information that can help.
The secondary audience for my content is those few keen Windows Phone developers (like myself) who want to know everything they can. By sharing what I learn and discover I hope I can contribute knowledge that helps them with their apps and let them know new things or edge cases which aren't documented elsewhere.

Personally, I want to be awesome at making awesome apps. But I know I can't change the world, and its apps, by myself. So I'm also trying to help others become better at making better apps. This is why I blog, answer questions on StackOverflow and organise user groups.
I want everyone to be building better software that helps create a better tomorrow. My first responsibility is to myself and the software I create but I also want to reach out to others and help them too.

CV tips

2013-02-26T13:26:00.000Z

A few tips for your CV:

Include your name in the file name - So it's easy to identify who's CV is who's when there are lots saved to a disk.
Include your contact details - Agencies may remove them before forwarding to companies but if you're sending direct to a company you need it there.
Spell check!
Give it to someone else to spell check! - Seriously. There should be no spelling mistakes in it. Especially in titles/subheadings (I just saw someone list their "KILLS", when I sincerely hope they menat "SKILLS"). Technical jobs demand attention to detail. Be sure you display some when selling yourself.
Put your work experience in order - Don't jump around in time. If the most relevant work experience you have is many years ago call it out separately and indicate clearly why it is still relevant. Don't put it between the work you did two years ago and three years ago when applying time headings.

Talking WP8 in Telford

2013-02-25T14:04:00.000Z

On Wednesday I'll be speaking at ShropshireDevNet. If you're in the Telford area why not pop along and say hello.

This will be the same as (or very similar to) the talk I gave in Southampton last week.

Here's what some of the people who came last week said:

"Really great presentation. Good tempo. Dry humour worked well. Well executed and useful examples. Inspired."

"Excellent. So much to learn and explore!"

"Excellent look at the features available for windows 8 phone."

"Great session. Learnt a lot of useful nuggets of information. I realy want to push ahead with some app ideas now."

"Good speaker. Whistlestop tour but useful. Speaker mentioned issues and problems as well as good features. "

"A lot covered, in short time. The constant questioning and boucing around actually worked really well"

"Great session, fast paced and good atmosphere"

"very fast presentation but liked the examples"

SD cards on WP8 - not good for much more than just storing music and video

2013-02-13T21:07:00.001Z

Today I was asked how to read office documents from an SD card on Windows Phone 8.

It turns out that the Office app (hub) doesn't support reading from SD cards. :(

I then wondered if it was possible programatically.
A quick check of the file extensions that are reserved and not available to 3rd party apps did not include any of the ones I was interested in: .doc; .docx; .xls; & .xlsx.

It seems that MSDN wasn't telling the whole truth. There is no 3rd party access to file with those extensions either. :(

A live tile is more than just a square (or rectangle)

2013-02-07T14:56:00.000Z

The clue is in the name really but just because something is square (or rectangle) that doesn't make it a live tile. At best it's just a tile.

The "live" part of the name is there to imply IT'S ALIVE!

It moves
It changes
It updates (all by itself - seemingly)

This is where the added value is.
If it just sits there and doesn't do anything it's probably just an icon.
Having icons may not be a bad thing. Just know the difference and that live tiles are like icons on steroids (but without the negative connotations). :)

<rant state="over" />

Pivot and Panorama have moved AND changed in WP8

2013-01-30T08:35:00.000Z

This post contains content from a talk I gave at WPUG on Jan 29th.

As a Windows Phone developer you're, no doubt, intimately familiar with the Pivot and Panorama controls. If you've looked at porting an app that uses them from WP7.x to WP8.0 then you're probably aware that they've moved.
They used to be in the Windows.Phone.Controls.dll assembly that you had to distribute with your app.
They're now in the Windows.Phone.dll assembly and are already on the device.

The plus side to this is that it means your XAPs can be smaller (due to not needing to include a 102k file) and that the pages which use these controls can load that little bit faster (due to use of a native control)

The downside to this is that you cannot use the same XAML in a WP7.x and a WP8.0 application. If you're targeting both platforms this means duplication and that in turn leads to more work. :(

On WP7.x you do this:

xmlns:controls="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls"

But on WP8.0 you do this:

xmlns:controls="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"

That is all relatively well documented and easy to address if you've discovered it yourself. What isn't so well documented is how the controls themselves have changed.

Let's start with the Panorama

Here you can see the default instances of the two versions of the Panorama. WP7.x on the left and WP8.0 on the right.
Notice in particular the differences in the headers.

Not clear? Let me make it a bit more obvious:

Yes, the layout (template) for the PanningTileLayer has changed in WP8.0.

Here's how it looks in WP7.x (obtained via Reflector)

And, this is it in WP8.0

The item headers have been changed too.
WP7.x:

WP8.0:

Does this matter? Why might you care?

Well, if you've got a background image for your Panorama that was designed with the WP7.x layout in mind it may look wrong or out of alignment on WP8.0. If this is the case then you probably want to change the WP8.0 template to match the 7.x one that was being used previously.
This is also probably easier than creating a new version of the background image.
The WP8.0 template also gives more space over to the header. This means you lose some content space.
In that the contents of the PanoramaItems are probably more important than the header you may want to give them more of the available screen real-estate.

How to roll it back?

Fortunately it's quite simple to add your own template to the WP8.0 version and "undo" the changes:

Yes some of these values may look odd at first look but this will enable the title and header to be displayed in exactly the same position as it would on WP7. (This was tested thoroughly by a designer with a very keen eye for pixel differences. ;)

You can then apply them like this:



    
 ...
    
...

And what about the Pivot control?

Well, this has changed in a much subtler way and, fortunately, is less likely to impact you.

Something that is quite commonly done is to take a Pivot control and retemplate it to hide the header by removing the PivotHeadersControl from the template, to create a simple swiping control.

If this is missing in WP8.0 then the page with this on will cause the app to crash when opened.
You have been warned.
There are also other ways of hiding the item header if you so wish.

lorem ipsum in Windows Phone 8 calendar

2013-01-21T18:55:00.000Z

Here's a screenshot of my calendar on my phone.

No, I'm not scared of you seeing my personal data as Window Phone won't even show it to me!
See (Zoomed 150%)

That's right, in the month view they just show placeholder text.
The number of entries corresponds to the number of items each day but the displayed text does not.

I assume this is just for some performance optimization (probably when animating) but it looks lazy :(

Googles advice to those building Android tablet apps is also useful when porting from Windows Phone to Windows 8

2012-12-20T12:02:00.000Z

Goolgle has a tablet app quality checklist recommended for anyone wanting to publish an app for Android tablets in the Play store.

It's no doubt useful for anyone porting their first Android app to run on a tablet (from a phone) but most of the points apply regardless of the OS being used and so could apply to those of you making the transition from Windows Phone to Windows 8.

As an idea of how it is relevant, see this partial* list of section headings:

1. Test for Core App Quality
2. Optimize your layouts for larger screens
3. Take advantage of extra screen area available on tablets
4. Use Icons and other assets that are designed for tablet screens
5. Adjust font sizes and touch targets for tablet screens
7. Offer the app's full feature set to tablet users
8. Don’t require hardware features that might not be available on tablets

* Android specific sections ommitted.

Check out the full details: http://developer.android.com/distribute/googleplay/quality/tablet.html

Let me know if you find this useful.

Security and access to SMS

2012-12-17T12:23:00.000Z

Lots of Windows Phone developers want access to SMS*. It's an interesting data source and can allow the creation of lots of useful, helpful and interesting apps. There are security implications of allowing such access though and, unfortunately, most developers seem happy to ignore this or not take it seriously.

Today I heard about a scam that was only possible due to SMS access and "stole an estimated 36+ million Euros from more than 30,000 bank customers from multiple banks" (emphasis mine).

You can read more about the Eurograbber attack here but I think the important takeaway for developers is to focus on security and not easily dismiss or criticise platform limitations and restrictions that are there to protect the person who's phone it is.

And for everyone entering passwords or security information on a website. Always type in the domain for a website directly. Avoid following links, especially if it's a shortened or redirect link.

* If you don't know, Windows Phone does not allow developers of third party apps to access a phone's SMS history as part of it's strategy for protecting data security.

Found via Simon Judge.