Archive for the 'Design' Category

Die, Native Apps, Die!

Recently, I’ve been telling anyone who will listen that you should consider writing an HTML5 web app rather than a native mobile app.  The advantages are many and the list of things you can’t do grows smaller by the day.

I spoke on the topic at DDD Sydney earlier in the year, and more recently at Web Directions “What Do You Know” in Brisbane.  If you’d like the slides, they’re available at http://www.damianbrady.com.au/dyrnaa and http://www.devnewsreader.com/about.html respectively; complete with demos.  Check them out – I’d love your comments.

Why choose web apps over native apps?

There are a lot of reasons, and most are obvious.

  1. Users are always on the latest version – no support of old versions
  2. You only have to implement it once, in one language (counting HTML, CSS, and JS as one language of course)
  3. You can choose what to charge and how to charge it
  4. Done properly, web apps work on all devices – even those that don’t exist yet

But they’re slow!

Well no, not necessarily.  I blame Facebook for this misconception.

Facebook famously released an HTML5-based app for iOS and then ditched it in favour of a native app to squeeze more performance out. After all the reporting, the emergent mainstream view was that HTML5 apps simply couldn’t perform.  In reality, the new release was a refresh using a technology closer to the metal as a reaction to consumers screaming out for performance above all else.  Let’s face it, Facebook is not a trivial app in terms of bandwidth and content. There’s a fair bit going on with photos, chat, notifications, etc.

Could Facebook have made the app faster while still using HTML5? Almost certainly, and if they’d leveraged newer HTML5 capabilities as they became available, there definitely would have been improvements.

But would it have appeased the masses? Maybe, but we’ll never really know.

But web apps can’t do X!

Quite possibly not, no.

Well… unless you’re talking about using touch events, orientation, geolocation, hardware-accelerated graphics, local data storage, offline operation, home-screen icons, audio and video, sending emails or making phone calls. So probably yes… yes they can.

Sure, there’s gaps in there. A web app can’t use your phone contacts, it can’t play your music, and it can’t (quite) use the camera.

…Yet

Yet?

There’s a very definite trend in the world of HTML and browsers.  Each new browser or mobile OS version slowly chips away a bit more at the list of things a web app can’t do.  Surprisingly, Apple seems to be leading the way to a degree in the mobile space; enabling more and more HTML5 features in Safari with each release.

I say “surprisingly” because Apple has a very captive market in terms of native apps. True or not, the perception exists that neither Android nor Windows Phone have the same quality of apps available in their stores. Certainly they don’t have the quantity. Why then would Apple implement functions in Safari that pave the way for native-quality web apps?  It’s a good question, and I’m not sure I have the answer. Maybe it’s just the constant drive to stay in front.

Grooveshark

Very recently, Grooveshark rolled out a fully-functional HTML5 version of their site that works beautifully on mobile devices.  They’ve been plagued by problems getting native apps into the official app stores, and this option allows them to bypass the problem altogether.

It’s a truly impressive piece of engineering. If you have a … well… anything… I strongly suggest you go and try it out.  There are some amazing features. For example, (On iOS at least) you don’t even have to keep the browser window open for the music to keep playing.

One small thing… I’d love to see them implement some of the meta and link tags that Apple has made available for iOS devices.  For an example, try adding http://www.devnewsreader.com to your home screen on an iPhone or iPad (warning, it’s quick-demo quality).

Despite being a company that focuses on something not traditionally offered via a web page (streaming music), Grooveshark has chosen HTML5 as the right way to go.  Before sinking time and money into developing native apps for multiple platforms, it’s worth considering whether your app might be a good candidate for a web app as well.

Grooveshark may not be the first high-profile name to try to escape the walled-garden of native apps, but moves like this definitely show the blood in the water (pun totally intended and awesome).

A Generic Repository and Unit of Work Implementation for Entity Framework

You may be familiar with my previous posts describing the implementation of design patterns for Entity Framework.  It started with using generics for lookup tables, and followed with a generic CRUD repository.  This strategy follows along with our SSW rule, Do you use the Repository Pattern for data access.

In the lead up to SSW’s recent Enterprise MVC course, I had lots of discussions with Adam Stephensen and Eric Phan about whether we could do a better job with this pattern.  We’ve come up with what we think is a great solution that includes the Unit of Work pattern as well.

We felt it was really important to separate the domain models, the repositories, and the context; a separation that’s not made by Entity Framework. Doing so gave us some really important benefits.  Testing is made much easier.  For one, we can mock our context enabling us to test our repositories without going back to the database.  We can also mock the repositories to test the code that calls it.

A quick shout-out to Adrian Clark who suggested this separation in the comments last time.

We also used Inversion of Control to inject a context into the repository.  We could have had a reference to each of our repositories in our context, but inverting this relationship meant that we only needed to instantiate those repositories we were actually using.  It means less overhead and a looser coupling between the context and each repository.

First, we create our IUnitOfWork and our IGenericRepository.

public interface IUnitOfWork : IDisposable
{
    DbSet<TEntity> Set<TEntity>() where TEntity : class;

    int SaveChanges();
}
public interface IGenericRepository<TEntity>
  where TEntity : class
{
    IQueryable<TEntity> Select();

    IEnumerable<TEntity> GetAll();

    IEnumerable<TEntity> Where(Func<TEntity, bool> predicate);

    TEntity GetSingle(Func<TEntity, bool> predicate);

    TEntity GetFirst(Func<TEntity, bool> predicate);

    void Add(TEntity entity);

    void Delete(TEntity entity);

    void Attach(TEntity entity);

    void Dispose(bool disposing);

    void Dispose();
}

Then, we create an interface for our specific context. In this example, we have a context with a set of customers. This context is essentially a unit of work, so we’ll inherit that interface.

public interface ICustomerContext : IUnitOfWork
{
    DbSet<Customer> Customers { get; set; }
}

Next, we’ll create a concrete GenericRepository instance. This is very similar to the version in my previous post, but take note of the repository that takes a context. We use this to inject our Unit of Work.

public class GenericRepository<TContext, TEntity> : IGenericRepository<TEntity>
    where TContext : IUnitOfWork
    where TEntity : class
{
    protected TContext _context;
    /// <summary>
    /// Constructor that takes a context
    /// </summary>
    /// <param name="context">An established data context</param>
    public GenericRepository(TContext context)
    {
        _context = context;
    }

    public IQueryable<TEntity> Select()
    {
        return _context.Set<TEntity>().AsQueryable();
    }

    public IEnumerable<TEntity> GetAll()
    {
        return _context.Set<TEntity>().AsEnumerable();
    }

    public IEnumerable<TEntity> Where(Func<TEntity, bool> predicate)
    {
        return _context.Set<TEntity>().Where(predicate);
    }

    public TEntity GetSingle(Func<TEntity, bool> predicate)
    {
        return _context.Set<TEntity>().Single(predicate);
    }

    public TEntity GetFirst(Func<TEntity, bool> predicate)
    {
        return _context.Set<TEntity>().First(predicate);
    }

    public void Add(TEntity entity)
    {
        if (entity == null)
            throw new ArgumentException("Cannot add a null entity");

        _context.Set<TEntity>().Add(entity);
    }

    public void Delete(TEntity entity)
    {
        if (entity == null)
            throw new ArgumentException("Cannot delete a null entity");

        _context.Set<TEntity>().Remove(entity);
    }

    public void Attach(TEntity entity)
    {
        if (entity == null)
            throw new ArgumentException("Cannot attach a null entity");

        _context.Set<TEntity>().Attach(entity);
    }

    #region IDisposable implementation
    private bool disposedValue;

    public void Dispose(bool disposing)
    {
        if (!this.disposedValue)
        {
            if (disposing)
            {
                // dispose managed state here if required
            }
            // dispose unmanaged objects and set large fields to null
        }
        this.disposedValue = true;
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
    #endregion
}

Next, we’ll create a concretion for our context using Entity Framework. We’ll inherit DbContext as well as implementing ICustomerContext, and we’ll create both an empty constructor and one that takes a connection string so we can connect to a specific database.

public class CustomerContext : System.Data.Entity.DbContext, ICustomerContext
{
    public CustomerContext() { }

    public CustomerContext(string connectionString) : base(connectionString) { }
}

And that’s all we really need to do.

When we use it, we have to make sure we refer only to our interfaces so we can replace them later if need be.

private ICustomerContext _context;
private IGenericRepository<Customer> _customerRepository;

Ideally, we’d be using Dependency Injection to inject our concretions at runtime, but here’s an example of how you would do it.

_context = new CustomerContext();
_customerRepository = new GenericRepository<ICustomerContext,Customer>(_context);

From there, we can do whatever we need to do with the objects in our repository, and just call SaveChanges() on our context when we’re done. For example:

public ResetCustomerLastLoginDate(int customerId) {
    var customer = _customerRepository.GetSingle(c => c.CustomerId == customerId);
    customer.LastLoginDate = DateTime.Now;
    _context.SaveChanges();
}

Speaking at QMSDNUG on Tuesday 21st Feb

Just a quick post to let you know I’ll be presenting my “Building Mobile Websites with ASP.NET MVC 3 and 4″ talk at the Qld MSDN User Group meeting on Tuesday the 21st.

Previous versions of this talk have focused mainly on MVC 3 with a nod towards MVC 4. Now that the ASP.Net team have officially launched the beta of ASP.NET MVC 4, I’ll be shifting the focus to the new version.  Out with the old and in with the new!

If you saw the version of this talk I gave at DDD Brisbane last year, don’t be scared off – it’s gone through many, many iterations since then based on the feedback I’ve received.

So if you’re in Brisbane, I’d love for you to come along.  Just RSVP on EventBrite and I’ll see you there!

Horses for Courses (and Jockeys)

I’ve stumbled across a few blog posts lately that talk about why everyone should use one technology over another, or why someone is leaving a particular language for another. Obviously there’s no shortage of evangelical blog posts pushing the merits of one technology and lamenting the poor state of whatever-you-plebs-use.  But this latest spate got me thinking.

Most (good) developers talk about using the most appropriate technology for the job.  At its most basic level that means choosing Objective-C for a resource-hungry iPhone app, or writing your latest facebook-killer application for the web rather than the desktop.  That stuff’s obvious.  The more idealist polyglot programmers will take it further and push Ruby on Rails for web apps with a small budget, or they’ll suggest using RavenDB and deploying to AWS because all you need to do is store and retrieve documents across the web. If you’re in a Windows environment with a team running Scrum, choose TFS, C#, and SQL Server.

So “Horses for Courses” right?

The aim is valid and noble, and it’s certainly one I strive for.  But one thing frequently gets overlooked, and that’s the people on the team (or to stretch the metaphor – the jockeys).

If you have a team of programmers who are very used to writing software using certain technologies, think very carefully about advising them to move to something else. I’m not saying don’t do it (in some cases you really should), but there comes a point where the benefits to be gained by using language X on platform Y with source control Z just aren’t worth the trouble.

Unfortunately, most programmers write code in one way. They use one language, they know one data storage mechanism, and they’ve only ever written applications for one environment.  Maybe in a past life they tried out some other language, and maybe they dabble in HTML occasionally, but they’re only experts at one thing.

You, on the other hand, might look at a set of requirements and decide a NoSQL data store running behind RoR is the “best” solution for this project. Similarly, you recommend using git as the “best” source control system to use. Great. Unless you’re the only one who knows this stuff – then you’re dreaming.  If you have a team of C# developers, you’d want to have a pretty good reason for suggesting they program in a different language. If every other project they’re working on uses TFS, learning git is going to introduce a lot of overhead (initially).  Sometimes, the current way of doing things is the “best” way, even if the idealist in you disagrees.

Now, that’s not to say it’s never a good idea to force a shift within a team.  Consider a team of VB 6 developers who, for the last 15 years, have been dutifully writing VB windows applications with an Access back-end. At what point do you tell them it’s time to move on? (Ideally it would have been at least 5 years ago, but that’s clearly not an option). Assuming you don’t outsource or “refresh” the team, you should strongly suggest they change, but acknowledge that the extra effort they’ll have to put in will increase the work. Also be aware that you’re unlikely to get a quality solution from them if they don’t yet know what they’re doing.

My point is, when choosing the right technology for the job, consider everything, and that includes the skillset of the developers.

With that in mind, blog posts encouraging everybody to stop using .Net because it sucks, or telling them they should never use pure HTML and JS for business apps are just ridiculous. Yes, you might have had an overnight change of heart and now realise language X is the worst thing in the world, but you’re thinking about the specific situations you’ve been in, and developers with specific skills (usually just the individual author). If your whole team can just up and move to Ruby, then fantastic! Say hi to the rainbow coloured unicorns for me!

It’s always good to encourage teams to learn new technologies. It’s occasionally good to force a team to move on, but sometimes the “best” way isn’t the “ideal” way.

The Rise of Participative Software

Recently I gave a presentation at Ignite Brisbane where I spoke about “The Rise of Participative Software”.

You may remember me briefly talking about this topic in an earlier post, as it’s something that I’m fairly excited about.  The general idea is that most software just does exactly what the user asks.  You give it some explicit input, it gives you some output.  Participative Software is my name for software that makes suggestions and “participates” without explicit input.

Watch the video for more details.

The five minute time limit meant that I didn’t quite get my point across as well as I’d hoped.  I’d like to present the topic over 20 or 30 minutes so I can really drill down on the subject and include a bit more of a call-to-action.

As always, feedback is more than welcome – especially if you’d like to hear a 30min version!

Using the data you generate

I stumbled across an excellent article by Zachary Seward titled, “Everything the Internet Knows About Me (Because I Asked It To)”. It’s an great example of how much data can be collected about your every day activities.

While Zach gives some very interesting insights on what that data means to him, my immediate thoughts flew to, “what could an application do with this information?”

Using The Data:

Lately, I’ve been working on a presentation predicting the “rise of participative software”; software that actively participates in your life rather than standing idle waiting for instruction. As Zach hinted, data collection is prolific and the data ubiquitous.

Software is already capable of using swathes of data to actively push targeted advertisements your way, so why can’t it use its power for good and make suggestions to save you time or improve your life? Key to this concept is the idea that data-mining logs of your personal habits and activities can yield vastly useful useful information.

The Alarm Clock:

My go-to example of this kind of software is the humble alarm clock.

A stock (read: boring) alarm clock will sound an alarm wake you up at a certain time the next day. Extensions have included multiple alarms, repeating alarms, and technological marvels (like WakeMate and Sleep Cycle) that try to wake you up at the best possible time. Ultimately, they’re all just trying to wake you up before a certain time.

So what can all this public and personal data do for the alarm clock? It’s worth noting before I start that I use the alarm on my smartphone because it’s always on the bedside table at night. An alarm clock running on a device like this opens up a world of possibilities.

Let’s say my standard alarm is set to 7:30am on weekdays. That’s great most of the time, but there are a lot of exceptions to the rule. On public holidays I want to sleep in and if I have early meetings I need to wake up earlier. This is easy enough to do; the data is available. Public holidays are known well in advance, and my work calendar is already synced to my phone so that information is available as well.

Let’s take it a step further. My phone has GPS and knows about the wireless networks at my office and at home. In short, because I’m all but physically attached to my phone, it has the ability to track my movements.

If I leave work at 11pm on one particularly gruelling day, that data could feed back into the alarm clock. Wouldn’t it be nice if, when I finally went to bed that night, my phone asked me whether I wanted a sleep in the next day and adjusted the alarm accordingly?

Let’s take it even further, shall we? At 6:30am one Tuesday morning, my phone notices I have a 9am meeting at work. The phone turns on GPS or Wifi to check I’m at home, maps a driving route to my office (using Google or Bing Maps), and checks traffic data to see whether there are any accidents on the way. If there are, it might decide to wake me up early so I’ll make it to work on time.

Active Participation

I’m sure you can see where I’m going with this. The key point I’m trying to make is that I shouldn’t have to explicitly tell the software to behave this way for me. It knows my habits, has access to relevant data, and can therefore make predictions on what I want. It’s really just about combining and interpreting the huge amounts of data available and using it to actively participate in my life.

GPS data combined with bank account details and ATM localities could allow my phone to tell me I’ve been paid as I walk past an ATM.

Foursquare checkins combined with restaurant reviews and data from a coupon site could suggest places to go for dinner on the days I usually go out.

The possibilities really are endless.

The Skynet barrier

Whenever I talk about ideas like this with my fiancée, she blanches. She sees things very differently to me in this respect, almost certainly because she’s not an IT nerd. She doesn’t want her technology covertly collecting information on her or telling her what to do, and that’s probably the biggest barrier to this type of technology.

Just because you can do something doesn’t mean people will be comfortable with it. As Arthur C. Clarke famously wrote, “Any sufficiently advanced technology is indistinguishable from magic”, and while not everyone is scared of magic, it’s reasonable to be scared of the magician when it involves your private information.

Conclusion

With any product, it’s really up to the market whether applications like this will be deemed acceptable and ultimately popular. I may see opportunity while others see Skynet, but the opinion that matters is the one belonging to the consumers with the money.

If you want to share your opinion, or if you would like me to share all my ideas on this topic, let me know on Twitter, or by email.

Getting into ASP.NET MVC

It all started when I decided that I’d rewrite a partially-aborted PHP web app of mine in .Net. The PHP version was relatively functional, but PHP is not my strongest skill, so updating and improving it was hard. Combined with a lack of good quality free time, it meant that I didn’t have the inclination to update it much.

Much of the design work is already done. The database schema is solid and it isn’t trivial – it took me a number of iterations to get right. The UI flow has been decided, and at this point, I’m happy to reuse most of the layout, css and images.

At Tech.Ed this year, I heard a lot of great things about ASP.NET MVC. The Hands-On-Lab I did gave me just enough of it to get me interested, so when I decided I was going to rewrite this thing in .Net, MVC seemed like the way to go.

So I’m now attempting to learn how it all works, and it’s going really well. The secret? The NerdDinner tutorial courtesy of Rob Conery, Scott Guthrie, Scott Hanselman, and Phil Haack (actually I get the impression that Scott Guthrie wrote the tutorial, but the originating book is authored by all of them).

Seriously, if you’re looking at playing with ASP.NET MVC, run through this tutorial from start to finish. I guarantee by the end of it you’ll be all over the basics, and loving the way ASP.NET MVC is put together.

I’m looking forward to getting into some real development with this project.

Lessons Learned from Entity Framework

So I’m starting a new project, and we’ve made the decision to use the ADO.NET Entity Framework for talking to the database.

I actually found it quite difficult to get started. Examples on the web seemed to assume that I already had everything installed and ready to go. Step one was invariably “Add a new ADO.NET Entity Data Model”. That wasn’t available in my “Add New Item” dialog, so I set out to discover how to add the bits I was clearly missing.

After hunting for a while for a download, I found a CTP Preview 1 built on .Net 4.0 (I’m running 3.5), and some Entity Framework tools released as a CTP in 2007.

Lesson 1: Everything you need comes with the Microsoft .NET Framework 3.5 Service Pack 1.

Of course, when I try to find the misleading links now, I find the real one straight away. Hopefully your google-fu won’t fail you as mine obviously did.

I had a quick play with it and found that creating classes and relationships between them was mindblowingly easy. Build up your pretty diagrams or get the designer to build them from a database and suddenly your code can create objects, run LINQ queries against them, bind them to UI controls and keep track of changes as you go. Brilliant!

So I got to work building up a sample object tree for our new application. When I was done, I looked for the option to persist the changes to the database.

Lesson 2: You can update your models based on database changes, but not the other way around (it’s coming in 4.0 though).

Damn, database first. Back to the start.

No problem, I abandoned my design and started with the database. Once the tables were built, generating EF data models was a piece of cake.

Next step – dependency injection for testing. I don’t want to be bound to the database, particularly for testing. I want to be able to inject fake objects for my tests.

Lesson 3: EF creates concrete model classes and database contexts. Dependency Injection is not easy.

Honestly, we were prepared for this one based on some presentations we saw at Tech.Ed. We have come up with a solution for this, too. It looks good on paper and everything seems to compile and run ok, but we’re yet to see whether this holds true as we dig deeper.

Basically, we’re leaving the concrete models as they are, but we’re extracting an interface for the ObjectContext class that’s generated. Our proxy will provide a fake ObjectContext which doesn’t talk to the database, but it will mock out real model instances. If you have any better ideas for this problem though, let me know.

Pride in bad solutions

I solved a problem the other day.  It was a terrible solution. It works, but it’s difficult to be proud of how I solved it.

The problem was with MSMQ, but let me describe the problem with a needlessly overwrought metaphor.

Every week for the last 5 years, you’ve been sending a bill to one of your clients.  You have an infinite supply of envelopes and when Friday comes around, you print out an invoice, seal it in an envelope, send it by courier to your client, and a couple of days later, you get paid.  With me so far?

One day, you decide to start using a different invoice management software package – it’s much prettier and more stable than the old one.  You know, however, that the client doesn’t want anything in that invoice to change.  You’re not sure how they process it, but one time your printer smudged an invoice slightly and you didn’t get paid.  So everything in that invoice has to be exact.  Luckly, the new software is capable of printing a pixel-perfect version of the old invoice layout.  So far so good.

You also think you should start using a different courier.  Your existing courier company (COM+) is fine, but frankly they’re a bit behind the times.  The delivery drivers are about 80 and they’re driving some vans that are generations old.  So you set up a deal with a new company called C-Sharp 3.5 to do the delivery for you.

Still with me?  I told you it was overwrought.

So anyway, you give your new system a try.  You print out the invoice, compare it to the old one (spot-on, 100% the same), put it in an envelope, and send it off using the new courier company.

You don’t get paid.

You contact the customer but they don’t say much.  Just that they didn’t receive a valid invoice.  The new courier company swears they delivered it to the correct address and they provide proof.

You decide to try again next week and do some investigating.

The next week, you print out the invoice, compare it to the old ones (still the same), put it in an envelope, and organise for the new courier to pick it up.  This time though, you follow him.

He takes your letter, gets in his van, and drives to the client’s address.  He gets out, puts your letter in the mailbox and drives off.  Nothing wrong so far, as far as you can tell, so you wait to see what happens.

Soon, a guy comes out of the house (which by the way looks exactly like a big black box), opens the mailbox, picks the letter up, and takes it inside.

You go home, satisfied that the letter made its journey this time.  It must have been a once off.  But you still don’t get paid.

Again, you contact the client and all they’ll tell you is that they didn’t get a valid invoice.  You protest, telling them that you saw them pick it up but to no avail.

Over the next few weeks, you try everything you can think of to get this new system to work.  You try looking at the message again after it’s put in the letterbox and you try sending an invoice created by your old program.  Every time, the seemingly perfect letter gets picked up my the man in the black box, and nothing happens.

No matter how hard you try to work out what’s going on, nothing helps.  So, like any sensible person,  you give up and call the old courier company.  They turn up, pick up your invoice, and two days later, you get paid.  Despite the fact that they’re apparently doing exactly the same as the new guys, their deliveries get you paid, and the other deliveries don’t.  You resign yourself to using the old couriers until they or their vans all die.  It’s just a matter of time…

Fun story, huh?

So in case you’re a bit slow and didn’t work out what it was all about, I replaced an app that put a message in a Windows message queue for another (black box) program to pick up.  The old app was VB6 using a COM MSMQ library, and the new one was C# using the native .Net MSMQ library in the 3.5 version of the .Net Framework.

No matter how hard I looked, I couldn’t find ANYTHING different between the messages and where they got put.  I even dug up a copy of the black-box code and stepped it through a debugger.  When it got to the line saying Queue.Receive(), the message disappeared from the queue, and nothing came back.  There was no exception thrown!  I watched the message get picked up!  I did a binary comparison of the message contents from the old program and the new program!  No difference at all!  Inexplicable!

The fact that I was putting the message into the Windows Message Queue using a .Net library and picking it up using COM+ seemed to be all it took to break the thing.

This is the first time I can remember being absolutely, 100% stumped by what was going on.  I’d analysed what was going on as deeply as was practical and had come up with nothing.

So I did the logical thing and referenced the COM+ dll from my new app.  When I used this library to send the message, it all worked perfectly.

I really don’t like this fix. Despite the fact that everything works perfectly now, it’s still a failure in my eyes.  It’s like a brand new Merc with duct tape holding the wheels on.

However, given that I’d spent way too long already on something that really shouldn’t have been a problem, it was probably the right thing to do.  Cut my losses and take the easy way out.  I’m not proud.

iPhone and the small things

So I finally joined the dark side and I got myself an iPhone.

Now, if you’ve been following this blog for a while, you’ll know that often it’s the little things that interest me.  Small bits of functionality and the tiniest ideas sometimes make the biggest impression.

With that in mind, here are the top things that have impressed me about the iPhone.

1. UI during phone calls

When I’m on a call and I’m holding the phone up to my ear, there’s no need for the screen to be on… so it’s not.  If I take the phone away from my ear, the accelerometers in the phone notice this and I get a useable display again.

A tiny thing, but it shows that Apple is thinking.

2. Music in my car

I connect the iPhone to my car stereo using a standard 3.5mm headphone plug.  Great sound. It works perfectly. Not that impressive.

However when I get out of my car, I pull the cable out.  The music stops.  It could quite easily continue – there are speakers on the phone after all, but it’s smart enough to assume that having unplugged th speakers/headphones/whatever, I probably don’t want to listen to the music any more.

Again, it’s simple but intelligent.

3. Silent switch

My old phone was a Nokia E71 and I loved it.  It did everything I wanted it to, but I’m a sucker for stuff that’s nice to use (usually) so of course I wanted an iPhone.

One very slight annoyance I’ve had with every phone thus far (including the E71) is that to turn the phone to silent, it takes a few steps.  On the E71, you have to unlock it, press the power button at the top, scroll down to Silent, press the OK button, and lock the phone again.

On the iPhone, you flip the switch on the side.

4. Network connection switching

I’ve set up my iPhone with the details of my home wireless network and the network at my parents’ house.  I did each setup a grand total of once.

Now, whenever I’m at home or at Mum and Dad’s, any browsing I do uses those networks.  The phone never asks me, never checks to see whether I might actually want to pay for access, no.  It assumes I’ll want the fastest (and cheapest) connection available.

5. Application Installation

Hands down the cleanest installation for any software I’ve experienced.

Go to the app store and find something you want, touch the price button and then install, and you’re done.  There could be a couple of extra touches here and there and you might have to put a password in so your account gets charged too, but it’s incredibly easy.

It downloads in the background, there are no restarts, and you can immediately see it in your list of apps (“springboard” apparently).  Brilliant.

So that’s it – probably not the same list as anyone else, but like I said, it’s the small attention to detail that impresses me.

Next Page »