Friday, May 30, 2014

The future is...

... already here - it's just not evenly distributed. - William Gibson

It's certainly not evenly distributed if it's just in our heads.

It's certainly not evenly distributed if it only exists in proof of concept form on a few devices and just used by the creators.

Plus it's going to include this great looking new film:

How can we make the future better?

Thursday, May 22, 2014

Universal apps are confusing because they're not apps...

... they're solution templates.

"Universal app" is a nice term though, isn't it? It speaks to the idea of a single app that can run everywhere. We know that's not the reality but it seems like what a lot of people want to aspire to.
iOS already has "universal apps". These are a single packaged application that can be deployed to both iPhone and iPad and the app will adjust its UI (and behaviour) as appropriate to provide an optimised experience on both types of device. Anecdotally I've heard from people within Microsoft who speak to developers, who develop for platforms other than Windows, who are amazed that despite all this talk of "One Microsoft" and a common design language across all platforms it is still necessary to build separate apps for each platform.

Maybe talking about something with the same name as a type of application on iOS will make some people think that "universal apps" on Windows work just the same...

So, what of these templates if they're not apps?
"Universal apps", in the Windows sense, are a solution that contains 3 projects: One is the Windows apps; one is the Windows Phone app; and one is a new, special kind of shared project that contains files and resources that are auto-magically included in the other 2 projects when they are built.

So, yes, a universal app is a way of building 2 apps - one for each platform. The bit that is universal is the code and resources that are used in each app.

In Microsoft's defence, they have done a lot of work to be able to use the same UI and code files in the projects for both type of app.

What about using the "same" app on "big Windows" and on the phone?

If you're using Windows [Phone] 8.1 and view the store you may see the above image next to some apps. This means the Windows and Windows Phone versions of the apps are linked. If you buy it on one platform then you'll also get it on the other. The same goes for In-App-Purchases and settings (as appropriate) within the app. You should get a seamless experience when using the same app on both platforms.

So, in conclusion:

  1. The term "universal app" is confusing and means something different to what it does on iOS.
  2. "Universal apps" on Windows are a way of reusing code and assets to easily build versions of an app for both Windows and Windows Phone.

Tuesday, May 20, 2014

Universal apps and manipulating statistics

The new Universal apps, apparently, support sharing approximately 90% of code between Windows Phone and Windows.
By "code" I mean XAML controls and WinRT APIs.

Now, 90% is a high proportion and the assumption therefore is that it should be really easy to use the same code on both and most apps should be able to reuse almost everything.

But what if I'm playing devils advocate?
Surely we can look at that 90% differently.
Let's work on the basis that it means that 9 in every 10 items can be used on both platforms.
This means that 1 in every 10 items doesn't work.
Do you have 10 (or more) controls in your app or use 10 or more of the APIs in the SDK?
If so, then you'll have something that can't be shared across both platforms. At least in part.

Isn't it only the smallest, simplest apps that contain less than 10 controls or use less than 10 APIs.

Two points then:

1. Statistics can be manipulated to skew opinions and support different arguments.
2. Don't assume that creating code that can be used in both a Windows and a Phone app is straight forward and everything will just work the same on both platforms.

Are you really still thinking "desktop first"?

There are still some people who still think of "mobile" as an afterthought. Here are 2 statistics (from last year) that highlight how, world wide, there are far more people using mobiles (smartphones & feature/dumb phones) than are using PCs (including tablets).
Click through on both statistics for more details.

When should you check that your app has the latest data?

This post was inspired by a question on Stack Overflow:

What a great question: When should you update data on the client to ensure that it's always up to date for the person using the app?

Unfortunately, there is no absolute answer to this question that will cover all scenarios for everybody.

It's easiest to handle this situation if price changes happen on a predictable basis, such as overnight or at certain times, and/or on certain days of the week.

If we know that prices only change at certain times of day (or week) we can limit unnecessary network traffic (and therefore delays in using the app) by just checking if we haven't checked since the last time that prices may have changed.

If building an app using Silverlight technologies (which will be the case if targeting 7.X, 8.0 & possibly 8.1) then you should check on app start up when either the Launching or Activated events are fired.
Of course the price may be changed while the app is in use. In this situation you could send a push notification to the app while it is running to tell it to update the data. You may also need to handle the situation where a purchase is attempted but such a notification hasn't been received or yet been acted upon. More on that below.
It is not possible to send a message to such an app when it is not running to have it automatically trigger getting the latest data.

If you want to check in the background (when the app is not running) then you'll need to use a Periodic Background Agent which can download the latest data ready for when the app is next used.

If building an app for Windows Phone 8.1 and using the new application framework (i.e. not Silverlight) then it is possible to trigger a background task to download the latest data from a notification message. You may also want to trigger checking on device starting in case any notifications were missed when the device was not on.
On app start-up you should check for the latest data after an activated or resuming event to check when navigating to (starting) the app.

With any of the above techniques, you can't be sure that the app will have received a message to notify it to update the data, or run the background task to check for the latest data or even been able to get to the server to get the latest data when the app is not running. This is why it makes sense to check on start-up in addition to any checking that is done in the background.

Ultimately, if the price can be changed at any time and the latest price must be used/honored, it will be necessary to check that the values which are being used on the client with the latest server prices and products when a purchase is actually made. (In reality you'll probably be checking this anyway to make sure that a product that is discontinued or out of stock is not being ordered.)
This should be in addition to any other work that is done to synchronize data at other times.

Monday, May 19, 2014

The future of mobile applications

For a long time the conventional wisdom has been that mobile apps should be simple, do one thing and do it well.

I think things are changing.

I think that we're moving towards a place where people want greater sophistication from mobile apps.

We have these incredibly powerful devices that we carry around with us and yet most of the apps on them are only acting in the most basic of ways. They make no attempt at doing anything intelligent or at best rely on users to configure them (through complex settings pages) to do anything specifically tailored to the individuals needs.

With apps that retrieve data from a remote server, I'm sure the majority of them could be more advanced that having the most technically challenging thing they actually do is format the data the server returns.

Sophistication is not the same as complexity.

I am absolutely not arguing for complexity. Complexity is an enemy and is often the result of trivially simple apps that have not had the disciplined thought and effort applied to them to make them easy to use. Sophistication can even remove complexity.

I don't think the need and desire for simple applications will go away but these will be supplemented with powerful and more sophisticated apps.

There are some apps that will always be useful and don't need to be anything other than simple and straight forward.

What about Facebook? They recently removed the messaging capability from their app and created a separate app with just the messaging capabilities. Doesn't this contradict my idea?

Not at all.

Let's looking at the Facebook app. It's far from simple and so breaks away from the conventional wisdom of what a mobile app should be. Breaking out the messaging functionality into a separate app makes perfect sense for the reasons stated. If, as was claimed, there were a lot of people just using the messaging functionality in the old Facebook app, then there was an opportunity to provide a better, more tailored experience to those people by making it a separate app. The separate app can be made to start faster and be updated more frequently as it can be tested faster than worrying about the rest of the app.

Organising community events is a lot of work

This may turn into a rant. I won't be offended if you don't read it ;)

I've been organising (and helping organise) "community" events for about 6 years.
By "community" events I mean user groups or meet ups of/for developers who want to learn from and with each other. Most of these meetings have been related to "mobile" and the majority have focused on Windows Phone.

I've also spoken at a number of groups organised by other people.

I am frequently asked about what it takes to organise such a group and how to get started. I've been meaning to blog about this for some time. Here are some thoughts.

Sad fact #1 - It takes a lot more work than it may appear.

There are 4 basic tasks that a group organiser must do:

  1. Find & book a venue
  2. Get speakers/presenters
  3. Promote the event to attendees
  4. Make sure everything runs smoothly on the night

Find & book a venue

Depending on location and the size of the group this can be particularly complicated. Technical requirements (at the very least probably projector and Wi-Fi) and the desire for somewhere cheap, or even better free, mean that such locations are often in popular demand by other people too.

Get speakers/presenters
Most people when they start a group are also prepared to speak but this isn't a permanent solution to finding speakers.
I can talk for hours but think people would get bored and stop coming if it was me speaking each month. In fact, I consider it a failure when I have to speak because I couldn't find anyone else to do so.

It's really important to persuade attendees to speak up and share their knowledge and experience. This is often easier than getting an external speaker. Persuading people to come and travel to speak at a small group can be tricky based on the time and effort they put in to coming for probably, very little in return.

Logistically managing people who are interested in speaking, when you are able to meet and when the venue is available can be tricky. With one past speaker who was really keen to come at the first available opportunity, it still took over 2 years before we found a date which was suitable for all. But hey, I said none of this is easy.

Promote the event to attendees
Most people aren't looking for events to attend. Those that are will go to places like (so it's important to be discoverable there) but they are only a very small number.
In terms of promoting events it typically means finding people who may be interested to attend and persuading them on why they should come. This typically comes down to the speakers and the subject(s) they are going to talk about. - People come for the speaker but come regularly because of other attendees (the community). 
This takes lots of time and effort.
Of course, once you get someone to attend you need to get and keep their contact details so you can tell them about future events. It's much more successful to actively contact people and tell them about similar future events. Just hoping they'll see a tweet about it or happen to remember to check a website for possible events is not a good tactic for getting a full house.

Make sure everything runs smoothly on the night
Unfortunately, for an organiser the actual event is not a simple affair. It's mostly non-stop. Is everything ready for when people arrive? Are any and all issues and questions handled correctly during the evening? Does everyone get away all right and everything get packed up ok?

There are lots of things to be done in the days before, and after an event.
From confirmation of details to ordering catering, to sending out post event follow up emails. A lot more happens than just turning up at the advertised start time on the night.

If an event doesn't go well, why would people come back next month?

Sad fact #2 - Nothing comes from most of the people who offer to help. They either don't mean it, don't realise it will actually take effort, or don't have anything useful to offer.

At least this is my experience. If I don't do it it doesn't get done and then there is no event.

The cost of organising, attending, hosting and travelling to events has cost me £££££s.
In return it has helped me get a couple of interviews. While getting me in the door it's my knowledge of the subject (in a large part demonstrated by and gained from answering questions on Stack Overflow) that has got me jobs though.
At best the return on my investment on events breaks even.

While spending lots of time organising events I haven't been doing work that demonstrates my skills and abilities.

I've recently missed out on a highly financially rewarding opportunity due to my lack of ability to show what I have done and can do.

Organising lots of user group events has lead me to be good at organising such events. The result hasn't necessarily been that I can say I'm good at what the events are about.

Being able to say "I've helped build apps with a collective download total over 50 MILLION" is useless if you can't say what the apps are. Unfortunately most of my contracts stop me talking about the apps I'm helping ship. (Some don't but I easily muddle the ones I can and can't talk about - It's safer for me to not mention any of them.) Ironically people come to me because they want the best, but don't want me to talk about it because they feel it may reflect badly if they, as a large brand name company, were putting so much responsibility for their app(s) on an individual outsider.

Remembering the past advice I've received of:

"you get the work you do"

This shouldn't have been such a shock to me.

I spend my time trying to help other people build better apps - so I don't have time to build apps myself.
I spend my time building apps I can't talk about - so I don't have any apps to demonstrate what I do.

It's a vicious cycle.
Maybe as a community event organiser I need to find a way to balance helping others and managing my future job prospects and demonstrating my abilities beyond community events. I'm open to suggestions on ways other people have done this or how you think I could.

Sad fact #3 - most groups don't last more than a handful of meetings.

I organised 27 DevEvenings and my 42nd WPUG meeting is next week. I think that's pretty good going.

Here's the kicker though. Most potential employers aren't interested in the ability to organise meet ups.

Fortunately I'm not looking for work from most employers at the moment. But I do still need to pay the bills.

I'm not thinking of packing it all in just yet though. Despite everything I do still enjoy organising events.

Yes, this has all been a bit selfish.
Through organising and speaking at events I have done a bunch of things for other people:

  • Helped people learn about new technologies 
  • Helped people learn what makes a better app
  • Helped people build better apps
  • Helped people get better exposure for their apps
  • Helped people make friends, business contacts and jobs
  • Helped people get free phones

This is what's important to remember. I'm doing this to help other people build better apps.

Friday, May 16, 2014

Talking "community" on Channel 9

On Monday* I was interviewed for App Hack Monday as part of a conversation about "Guide to making the most of local app communities".

You can watch it at

Here's one comment to give you an idea of what's covered:
"This short interview actually tells a lot about ICT events, and how they have been changed over the years.Very good and entertaining yet informative, thanks, I am going to participate"

* It was actually recorded last week ;)

Monday, May 12, 2014

Microsoft & Cordova (PhoneGap) sitting in a tree...

An exciting announcement from the Microsoft Open Technologies group today as they announced integrated Visual Studio support for cross platform development.
At //BUILD/ it was announced that WinJS would add support for Windows Phone and is being open sourced to allow for support of Android and iOS too.
Of course, this left one massive question: How does this sit with PhoneGap?
Unfortunately I was unable to meet up with anyone from the team to find out more and see how the two can live together. Now we seem to have an answer though.

This is very exciting. - Especially considering my history ;)

You can read the full details of the announcement at

Friday, May 02, 2014

Where we write optimised code: then and now

It wasn't so long ago that code written to run on a mobile device was so constrained by memory and processing power that it was really important to take time to optimise that code for performance. Despite the physical and technical limitations of the device we still wanted a good experience from a seemingly fast and responsive application.
In contrast the code that was written for the back end server was running in an environment so, comparatively, rich in resources the performance of that code was rarely ever considered. It didn't matter that it was inefficient as it still executed really quickly.

Fast forward to today and things have reversed.
Portable devices now have specifications that put the laptops and PCs of a few years ago to shame. As long as code is written in a vaguely sensible fashion, performance issues due to the inefficiency of code now rarely need considering.
On the flip side though, the code that is now running as part of the back end services is no longer on our own powerful server somewhere. Instead it is running in the cloud where we pay for execution time and so performance again becomes an issue.

We used to optimise on devices for the user experience. Now we optimise the code running on the server (cloud) to reduce costs.
Both help the product/company and all that time we spent learning to write efficient code was well spent.