Thursday, January 28, 2010

iPhone developers, welcome to some new headaches courtesy of the iPad

A, hopefully, slighlty different take on the bandwagon jumping and hype that is the iPad:

For a long time I (and many others) have been saying that developing for the iPhone is not the same as developing for what's commonly referred to as "mobile".

By creating something (app or website) that specifically targets the iPhone developers do not have to deal with many of the problems and challenges experienced when creating applications or websites which run on a wide variety of mobile devices.

Arguably the number of iPhones in use has meant that by targeting the iPhone you can still have the same number of potential users as if you targetted a number of different devices but without some of those headaches.

Of course, I'm not saying that developing an app that works on the various generations of iPhone and iPod Touch is without challenges due to variations in functionality available from the SDK or the actual device. e.g. not including 'phone' or camera related functionality on the iPod Touch.  It's just that as of today those challenges just got a lot bigger.

I'm not going to go into great detail here as I'm working on a larger, more complete discussion of the issues you may face. However, here are a few questions to get you thinking:

  • Do you dectect visitors to your web site using an iPhone and show them something different?
    Do you show them an optimised version? How will that optimised version cope with being displayed at 1024x768 (or 768x1024)? Are you sure that your detction can tell the iPhone and iPad apart? does it matter?
  • Do you not show some information on screen because of the limited available real estate? Could you redesign your pages/views to make better use of the increased space available on the iPad?
  • Can you display information in a better/clearer way with more space available?
  • With more space do you want to change what is displayed based on orientation? Possibly similar to the way the iPad email client does.
  • More space on screen means you can show larger, more detailed images. But how are you going to show an image of appropriate detail for different size screens? Can you afford just to let the browser resize larger images for you?  Is that what's best for the user?  What if the difference is in the resolution of dowloaded video? Does the increased time (and cost) of always downloading the larger file matter?
  • Can you do somethign new with the iPad which you weren't able to do on the iPhone? Maybe something that you considered for the iPhone but wasn't practical based on a restriction or limitation that doesn't apply to the iPad.
  • Does the size of the iPad mean it's likely to be used in differeent places/ways that the iPhone typically is? It's propbably to early to say for sure, but does this change in context mean that you wish to design your application or web site to be better suited to this different context?  This may mean making different features or options available.
And many more questions....

Can you afford to do nothing?
Despite what you may think of my opinion, what does the fact that Apple have redesigned all their apps for the iPad say?

If you are an iPhone developer the very next thing you should do is read Apple's "Introducing Universal Applications for iPhone OS" and start preparing for the new wave of challenges ahead.


I'm not in a position to pass judgement or share an opinion on the iPad at the moment as I haven't used one.  It sure looks interesting and I'd be keen to try one out though.

Wednesday, January 20, 2010

Code Offsets for bugs

I've written about code offsets previously and I think it's a noble idea.  In reality I don't find the idea of paying on a per Lines Of Code written basis practical.  Instead I'm keeping track of reported bugs I've introduced and offsetting each bug for a credit.
I see it as giving something back without going bankrupt.

Thursday, January 14, 2010

I don't know da time

Bad puns FTW!

When Jon Skeet announced his intention to port JodaTime to .NET I said I would be interested in helping in the process.

NodaTime was born and I have carefully following the discussions in the groups and seeing contributed code as it's checked in.

Unfortunately a number of other commitments and the realisation that I actually have only about 8 hours a week free time (for all my interests - not just writing my own code) have so far prevented me from making any kind of contribution to the project.

Despite my lack of involvement I've learnt some interesting and hopefully valuable things from looking at the code already contributed to the project and from reading the discussions around it's development.

Based on this experience I'd recommend that any developer follows the discussion and looks at the code from new open source projects.  It's a great way to see how other people work and solve problems. Of course if you have the time and opportunity to contribute also then all the better.

Tuesday, January 12, 2010

In my last project at work I used:

Technologies used in last project, in no particular order:
  • ASP.NET MVC (2.0)
  • SubSonic (3.0)
  • MvcContrib
  • Castle Windsor (for IoC)
  • PostSharp (1.5)
  • jQuery
  • NUnit (for unit testing)
  • T4MVC
  • T4 (for lots of things including managing multiple configurations)
  • m.spec (for integration testing)
  • fit.net (for acceptance testing)
  • dotLess
  • RhinoMocks
  • Yahoo YUI Compressor (for javascript compression)
  • Hudson (CI Server)
  • VMWare (for hosting CI & Test machines) SysAdmins choice

Technologies considered/evaluated but not used:
  • Spark View Engine (for ASP.NET MVC) - Some initial configuration options and hard for web designers to work with.
  • MongoDB (as an alternative database) - not used as deemed unsuitable for highly transactional nature of data used by system.
  • Visual Studio 2010 & .NET 4 - Reluctant to commit to using unstable betas. Didn't want to have to make a change part way through a relatively short and pressured development cycle.
This was all to produce:
  • Websites
  • Web Services
  • WinForms Apps
  • CF WinForms Apps
  • WPF Apps