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…

Just a quick bug fix. 1.1.2 fixes an issue that would cause friends that were both a friend and a clan member to fall out of the Xfire group when a new friend was added.

Just posted up Xblaze for Mac 1.1.1.

• Fixes the issue where friends of friends would be moved to the offline group when they stop playing instead of removed from the list.
• Fixes the issue where offline clan members were nowhere to be seen. Offline clan members can be found in the offline group now.

Go grab it from the XBlaze for Mac OS X page.

Please read this post that I made previously:

Why Push Notifications Are Unlikely To Be Added

The long story short is:

• It is probably against Xfire’s Terms and Conditions
• I don’t have the resources to commit to a relay server, which includes:
  • Development time
  • Maintenance time
  • Development /maintenance costs
  • Hardware / hosting costs

For this reason I will not commit to push notifications unless a solution that overrides all above reasons appears.

Hot on the heels of Xblaze iPhone 1.1 is Xblaze for Mac 1.1.

That’s right folks, again, I promised you that I would merge the changes I made to the Xblaze iPhone source back into the Mac version. That is now done and you can download Xblaze for Mac with clan support and less crashes than ever!

Head on over to the Xblaze for Mac OS X page and hit up the download link!

So last week, I promised all Xblaze iPhone users Communities (clans/guilds) support.

Those waiting will be happy to know that today I submitted Xblaze 1.1 to the App Store reviewers. Xblaze 1.1 contains the communities support that I promised, and it’s working really nicely, if I do say so myself.

I’m hoping that the update won’t get held up too long being reviewed, and that you can all get hold of it soon.

Meanwhile, check out the screenshorts of clan Xblaze’s communities support:

Also in this update is

• Manage your Xfire preferences
  • Turn nicknames on and off
  • Hide/show offline friends
  • Hide/show friends of friends
  • Hide/show timestamps in chats
• Numerous bug fixes
  • Prevent a crash when a friend logs off while you’re chatting to them
  • Corrected ability to add friends of friends or clan mates to your friend list
  • Corrected the behaviour that allowed a user to attempt to delete a Friend of Friend from the FoF group (which also prevents a crash)
• Spruced up the Xblaze icon somewhat, looks a little flashier.

So I hope you all enjoy this eagerly anticipated update. And thank you all for your continued support for Xblaze!

One of the biggest features requested so far has been Push Notification support for Xblaze iPhone. The premise:

When a user quits the app, instead of being logged out of Xfire right then, the user would stay logged in and receive push notifications when new messages arrive.

There are a few problems with implementing this feature, some technical, some legal.

First the technical limitations.

Some people may not fully understand how push notifications work. So here’s a quick overview.

There are 5 major components:

1. The provider (In this case, Xfire)
2. The notification (The new message)
3. Apple’s Push Notification Service
4. The user’s unique iPhone
5. The Client Application (Xblaze)

For push notifications to work, the provider needs to know about the iPhone, and it’s UDID (Unique Device Identifier). Without knowing the UDID of the iPhone, there’s no way to get a notification from the server to the iPhone. If the Xfire could know your iPhones UDID, it would be able to create a notification and ‘push’ it to your device. But there is no way for Xfire to know your iPhone’s UDID.

So, the first technical difficulty is that there is absolutely no way to get Xfire to generate a push notification from its root server or no way to get it from the sercver to your iPhone. They’re not going to implement it, and we don’t have any access or control to make one ourselves. To get around this, we could set up a relay server that would maintain the Xfire Session and communicate between the Xfire server and the Client, and register the iPhone for push notifications (using its UDID).

Something like this (I don’t have time to make a pretty diagram):

Xblaze Sends UDID to relay server,
Relay Server receives message from Xfire,
Relay Server forwards message to Xblaze via push notification.

Unfortunately it’s not quite as simple as just setting up the relay server and carrying on. The relay server would require that all of the communication between Xblaze and Xfire go through this server. That includes logging in, sending/receiving messages, adding friends, retrieving game info, etc.,  etc.

It would be a massive undertaking and would probably require writing a complete implementation of the Xfire server itself so that it could proxy everything that the Xfire server does.

Once again, this is very unlikely to occur as the entire Xfire protocol is still yet to be documented, which large chunks still being undefined. In order to implement the entire server, we’d need to know exactly how everything worked…

Then, after spending the huge amount of time it would take to write and test the server, there’s the logistics of finding somewhere to host it, pay for it, maintain the health of the server, not to mention the cost of the server hardware. Also the server would have to be able to cope with accommodating thousands of Xfire users. This is not something that can be lightly thrown around as a “nice to have” feature.

Then even if someone did spend all the time, effort and money on writing this hypothetical relay server, they wouldn’t be allowed to use it anyway, which brings me on to the legality of this issue.

The Xfire Terms and Conditions specifically state (Emphasis mine):

You may not authorize any third party to access or use the Service on your behalf using any automated process such as a robot (or ‘bot’), a spider or periodic caching of information stored by the Service on your behalf, without a separate written agreement with Xfire.

It is against Xfire’s Terms and Conditions to implement such a server, and it would breach your agreement with Xfire if you used a service that relayed your connection.

Xblaze and other 3rd party Xfire clients are already treading a very fine line in terms of legality, because they’re only made possible by reverse engineering the Xfire protocol. If at any moment Xfire decided that they wanted to pursue the issue of reverse engineering, they could send a cease and desist order to all 3rd party Xfire clients, and make them stop working – or they could change the protocol and lock everyone out.

If Xblaze received a C&D order from Xfire, I would have no choice but to comply, as I am technically in breach of the Terms and Conditions, as is every other 3rd party Xfire client developer.

I’m hoping it will never come to that though, but I don’t think implementing any kind of push notification support is feasible. Possible: maybe, feasible: not right now.

The next version of Xblaze iPhone will contain a major new feature that has been asked about since its release. That ferature is Clan Support.

Clan support is definitely being worked on for Xblaze iPhone and is getting pretty close to being releasable. The current implementation is currently integrating the clan as a group within your friends list, kind of like a custom friend group, but not managed by you.

I have a better way to display the clan groups (and it’ll be sexy, I promise), so don’t get attached to this method, this screen shot is just to show that clans are working so far!

You may notice the “Communities” tab at the bottom-middle of the screen. If you don’t know, Xfire don’t call clans “clans” anymore. They’re called Communities now, so that’s the official title. And that’s where the better clan (community) interface is going to go.

Hope you’re excited!

PS. At some point – when I have time – I will merge all these new Xfire features that are in the iPhone version back into the Adium plugin. I’m sorry it’s taking so long, but all my time is being used up by the iPhone version and real life.

It seems to be some kind of trend – the hip, cool thing to do – to share your stats on your iPhone App. So I’m going to join in!

First of all, the amount of downloads received in 10 days is pretty impressive for an app with no marketing strategy and a fairly niche user base:

over 1,400 downloads in 10 days! Incredible.

From this we can see where the downloads spiked on Jan 20th when Xblaze 1.0.2 was released. Jan 21st is the latest data available for this graph, but there are even more downloads since then!

Next up is the usage stats. It seems that the majority of people are using Xblaze in 6-7 minute sessions which is exactly what I would expect from an app like this. It’s something you can just pull out of your pocket, sign in, tell someone that important tidbit you needed to, and then log off and not have to worry about not being able to tell someone what you needed to!

With 7,334 session, we can see proof that users are coming back to use Xblaze time and time again, which is the signature of a good app. Why would people keep using it if it wasn’t good?

Next is an interesting one. Of the 1,400 downloads mentioned earlier, it may appear that a majority of them were upgrades from 1.0 or 1.0.1 to 1.0.2. This would support the spike seen in the first graph. The number of active users (those that have used the app at least once every day) climbed quickly at the beginning of Xblaze’s release. It seems to be still growing, but also slowly levelling off at approximately 250. 250 people use Xblaze at least once every day for 10 days – that shows some loyalty right there.

The yellow spot and dotted line shows that the data for that period is not yet finished being collected, which means there’s still more to come before that spot turns white.

Finally, and I think most importantly are the reviews on the App Store. I think iPhone App Reviews are a huge part in whether or not an app does well on the App Store. Even one bad review amongst a sea of good reviews can have a negative impact on the applications downloads. However, it seems that people love the app so much that they just want to shout about it. Here’s a small sample of some of the reviews Xblaze has received over the past 10 days.

People all over the world are showing their appreciation for Xblaze, and I thank you all for your kind comments and excellent feedback!

Here’s to another excellent 10 days! Things can only get better!