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.....
Wednesday, September 29, 2010
[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:
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.
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.
Tuesday, September 28, 2010
"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:
"Awesome"
"apps"
"that improve lives"
What does it mean to "improve lives"?
Simples.
But what does this mean?
Let's break it down into 3 parts:
- awesome
- apps
- 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:
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.
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
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
Thursday, September 23, 2010
[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:
Other requests:
And then the things that people didn't realise were already there:
I'll let you draw your own conclusions from the results...
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...
Thursday, September 16, 2010
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. ;)
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. ;)
Tuesday, September 07, 2010
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.
It seemed worth repeating. ;)
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. ;)