Xblaze

Update 4/12/10

The behaviour described in this post, if implemented in an iOS app, would result in a rejection from Apple.

Even though the described behaviour occurrs, it is a rule of the review process that all apps exit and clean up their networking sockets when the user backgrounds the app if the app is not allowed to run in the background. This means that even though Xblaze supports fast app switching, it still needs to close it’s connection to Xfire and cease any background communication.

End Update

So, after my last post about iOS4 and multitasking, I have noticed some very surprising and interesting observations about iOS4.

I’m no expert, and I’m only describing what I’ve seen actually happening, so here goes.

In normal circumstances, I expected an app that didn’t explicitly request to run in the background to become suspended and as a result,its network connections closed.

It appears that this isn’t the whole truth. In my testing when I suspended Xblaze into the background, it’s socket was not immediately closed. At first, I thought this was because the suspension hadn’t triggered Xblaze’s disconnect function, and that it would simply be disconnected when Xfire closed the connection after not receiving the keep-alive heart beat. Again, this wasn’t the case. It seemed that the connection stayed open, even after the expected period of time after which Xfire would normally close the connection.

I waited for 10 mins with Xblaze suspended in the background, sending a message to the account every minute. Sure enough, after I opened Xblaze again, bringing it back into the foreground, sly of those messages were suddenly received.

There is one caveat to this test – I had “auto lock” disabled, so my iPhone would not lock itself and go to sleep. I did notice that if I suspended Xblaze and then locked the iPhone, the connection was immediately closed.

So what’s happening here!?

My theory is that regardless of what Apple and their documentation says, it seems that while the phone is still awake and not locked, the OS will look after the socket and the connection, effectively queuing the incoming data, ready to be received when the app is brought back into the foreground.

This sounds great, right? Isn’t this multitasking?

Well no. There are a few compromises.

1. The connection is only kept alive while the iPhone is awake. As soon as the phone sleeps or is locked manually, the connection gets closed.

2. There’s still no way to notify the user that messages have arrived while Xblaze is suspended. The messages are only queued until the app is brought back into focus. As far as Xblaze is concerned, all those messages have just arrived this very second when it’s woken up.

But hey! Its not the end of the world, its better than nothing, right? At least you now have SOME way of getting messages while the app is in the background. Its better than not getting those messages at all, even if you do have to go check for them…