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…

The new iPhone 4 was announced last week, and alongside it, the release date of the newly renamed iOS.

Some of you may be fortunate enough to have access to the iOS 4 beta software and may have tried out Xblaze on iOS 4. Those that have will know that it’s not exactly what one would call “stable”.

I have been testing Xblaze on iOS 4 and its going to take some work, but I hope to get a compatible update out soon.

In other news some of you have been asking how much of the new APIs Xblaze will be taking advantage of with the new release. The answer to this question isn’t as exciting as you probably hope it will be.

Multitasking.

In April, at their unveiling of iOS4, Apple announced multitasking support for the iPhone. My initial reaction was one of relief, thinking I’d be able to escape the never ending requests for push notifications, and instead just allow Xblaze to run in the background. Unfortunately, the way Apple has implemented multitasking means that there are a number of restrictions surrounding what types of apps can use it and what those apps can do while in the background.

First of all, only VoIP, navigation and audio streaming type apps are allowed to actually run in the background. Any other type of app is ‘suspended’. Even those apps that can run in the background become very limited while there.

Suspension is when an app is literally ‘paused’ and sent to the background. The current state of the app is saved to memory. When the app is brought to the foreground it is “defrosted” and returns to the exact same state as you left it.

Apps that are allowed to run in the background will suspend most of their functionality but keep the core services that it requires running.

For instance, the popular VoIP app Skype will be able to receive calls while in the background, and close the app while a Skype call is in progress, because it keeps it’s socket connections to the Skype server open when it is sent to the background. But while its in the background all the Instant Messaging features of Skype are suspended and do not run meaning instant messaging does not work while Skype is in the background.

This was very bad news for Xblaze when I found out. I had some contacts at WWDC this year and they were able to confirm that instant messaging apps will *not* be allowed to run in the background. When you couple this with the fact that Xfire requires a constant connection to its server, kept alive by a ping of around 5 minutes, it means that Xblaze won’t even be able to take advantage of being suspended. This is because after those 5 minutes are up, Xfire closes the connection, effectively kicking you off the server, disconnecting you. When you return to the app after suspending it, you’ll find that you have been logged out and will have to reconnect, just like you do now.

The experience with Xblaze on iOS4 is likely going to be exactly the same as it is now – having to keep the app in the foreground in order to be able to send and receive messages to and from friends. And I’ll say it again – the way Xfire works just doesn’t allow a sensible way to support Push Notifications.

This saddens me in some respects and in and effort to change things I have raised a feature request with Apple and made my voice heard on the developer forums, but I fear that nothing is going to be done about it. It’s the way things are and that is that.

It puts a sour taste on something that could have been such a great feature…