Xblaze

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…

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!

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.

I’ve received a few emails asking why apps crash more often on Jailbroken iPhones. So I’ve collected my thoughts and written down a number of reasons why Jailbreaking is a pretty bad idea.

• Jailbreaking Allows Background Apps
  • Extra strain on the CPU
  • Extra drain on the battery
  • Heavy consumption of available RAM
  • Usage of your data connections (this might incur costs that you’re not aware of if you’re not on an unlimited data plan)
  • It’s impossible to know what the background apps are doing, if they request more resources and can’t get them because Xblaze is using the available RAM, maybe they’re written to kill other apps and take the memory for itself? No-one knows, except the developer of that app, and since Apple don’t approve these apps, they could be doing exactly that.

This reason alone is suspect enough to be a big cause of concern for people running Jailbroken iPhones. People forget that the iPhone is a mobile device, because it is so capable. It’s important to remember that the iPhone does have a very small amount of RAM compared to laptops and other computers. The iPhone was not designed to run many apps at the same time – this is why Apple restrict it to one 3rd part app at any time. They didn’t do it just to annoy people…

If there are several apps consuming vast amounts of RAM already running on the device (this include ssh servers, themes for springboard, notification apps, etc) then what hope does a legitimate app such as Xblaze have of surviving? Those not familiar with the iPhone SDK and how the iPhone works, may not know that the iPhone OS will kill an app if the device starts to run low on memory. Non official apps may be able to be coded in ways that ignore these warnings, forcing the OS to kill the legitimate apps that can’t ignore these warnings.

The result is that Xblaze will simply quit if there are low memory conditions on the iPhone it is running on, and since Xblaze only consumes a mere 4MB of RAM while running, the jailbroken iPhone would have to be using almost all the RAM before Xblaze is even started, which is actually quite likely considering some jailbroken apps such as themes that are rich in graphics and sounds.

• Modified Frameworks
  • Changes the expected behaviour of the iPhone so that a legitimate app will crash while trying to access a function or class that has been modified by anyone but Apple.
  • May cause the app to not even launch if the required APIs aren’t available at launch time.

When writing an iPhone app, a developer is given a set of Frameworks which allow them to access the iPhone’s functionalities, user interfaces, etc. Think of them as hand grips on a climbing wall. You need them to hold onto to be able to reach the top. If you tried to grab as hand grip and it wasn’t there, you’d fall. This is exactly the kind of thing that can happen to an application that relies on a framework being in the state that it was originally in when released by Apple. Changing these frameworks simply breaks any app that requires them. And once again, since it’s impossible to know which frameworks have been changed or how they’ve been changed, developers simply can’t program their app to work in that environment.

• Inter-Process Access
  • Jailbreaking an iPhone removes all restrictions. One app may be able to access the insides of another app.

If any malicious apps decide to snoop around the memory space of a legitimate app, anything could happen, ranging from the app crashing, due to memory corruption, to having something like your password and personal details stolen… Is that something you’re willing to risk? All restrictions are removed on a jailbroken iPhone – if you’re checking your online banking through Safari, what is stopping any malicious app from stealing your account details and forwarding them on to identity thieves? Are you happy with the possibility that your xfire password may not be safe when running Xblaze on a jailbroken iPhone, because there’s nothing I can do to protect it if it is. On a legitimate iPhone, Xblaze stores your password, encrypted using an SHA1 encryption algorithm, safely inside the iPhone’s Keychain (the same way passwords are stored safely on Mac OS X). The keychain can be accessed freely by any application when running on a jailbroken iPhone… Consider it carefully.

Unfortunately, due to the shady nature of jailbreaking iPhone devices, it is impossible to say whether any of this is 100% accurate, but I know I’d rather err on the side of safety, stability and security when it comes to my personal data, my entertainment and my overall mobile experience…

The truth to the question “Why does jailbreaking cause more crashes than normal?” is that I simply don’t know. If I knew, I’d be able to prevent it…

So Xblaze has been in the App store since the 12th of January, almost 2 weeks.

I have been following the stats and feedback very closely, and so far the response to Xblaze for the iPhone has been great! Xblaze has over 20 reviews worldwide, most of which are 5 star ratings! I can’t thank the people who left these reviews enough, it’s these users that make Xblaze what it is, and without them, Xblaze would float away quietly…

However, there is always a downside. Unfortunately the downside here is that some people are running Xblaze on a Jailbroken iPhone, and leaving bad reviews when it crashes.

For those who may not know, Jailbreaking is the process of “hacking” the iPhone’s OS to allow open access to the entirety of the phone. It allows 3rd party developers to write applications that don’t need to be approved by Apple.

Since Apple aren’t approving these Applications, they could be doing anything from gathering your personal information, running in the background using up your battery and data connections, installing malicious software such as worms — literally anything is possible.

Jailbreaking also allows users to install pirated applications, and get apps for free when they would normally have to pay. It is important to note, however, that not all Jailbreakers are pirates. About 38% of the Jailbreaking community have used pirated Apps, which is approximately 1.5Million out of 4 Million.

But piracy is not a problem for free apps, and we all know that Xblaze is free. So what is the problem?

Jailbroken devices have had their software “tampered” with. The iPhone OS running on a jailbroken iPhone is not the same as that installed on regular iPhones. For this reason, it is impossible to know exactly what has been tampered with, or how it will affect how the phone works.

A study has been done, using data gathered via the Pinch Media Analytics framework that shows how jailbreaking an iPhone can negatively affect application performance.

Specifically, “all jailbroken phones (whether the application is pirated or not) suffer from increased application crash rates,”. ()

The very frustrating thing is that as a developer, I have no control over who runs Xblaze or what iPhone they run it on. And as a direct result, Xblaze will get run on Jailbroken iPhones, and the statistics show that it is likely to crash more often than if it was run on a normal, official iPhone OS.

It is impossible for me to code Xblaze to not crash on a jailbroken iPhone because it is written using the official iPhone SDK (software development kit), using the official APIs (application programming interfaces). In nearly ALL cases, jailbreaking an iPhone installs older APIs, or changes their behaviour to be more flexible and open, and in some cases, installs extra software at the system level that could affect how certain processes work.

Because of this fact, the application may expect an API to behave one way, but in fact comes up against an API that behaves completely differently to how it is programmed, and as a result, will crash. It is important to understand that this will not happen to every single application or on every single Jailbroken phone. It’s almost a “crash lottery”. You take your chances when you jailbreak and accept the risks.

It is also very important to understand that there is nothing I can do to fix it, because jailbreaking is not an officially supported development option.

At the end of all this, Xblaze suffers in the app store, receiving one star reviews for crashes that aren’t Xblaze’s fault.

You’re free to run Xblaze on any kind of iPhone you like – but please don’t leave a bad review if your device is jailbroken and the app crashes… If you want the most stable experience, don’t jailbreak your iPhone. If you don’t find that acceptable and you make the decision to jailbreak, please don’t make Xblaze suffer because of it.

It’s 5:08am. I’ve just committed the typing notifications code to SVN. Sleeeepy.

I’ll release an update tomorrow at some point that will include the typing notifications support.

The incoming typing notes, (those that tell you who’s typing), were simple. A few short lines of code and they were working. But the outgoing typing notes, (those that tell your friends when you’re typing), were a lot more involved. The MacFire library didn’t have a packet to represent a typing notification, so I had to write one before writing the logic to send it.

I also learned something a little odd about the way Xfire handles typing notifications. According to all the documentation I’ve read about the Xfire protocol, the typing notification packet is the same packet that contains messages and message acknowledgments. The difference between these packets is the data structure within, their IDs are all the same. With that said, the typing notification packet contains a field aptly named ‘typing’ which represents an integer.
The documentation says this is treated like a boolean, 1 for typing, 0 for not typing. So my initial inclination was to send the packet with a 1 when a user is typing, and then again with a 0 when they finish typing.
I was wrong. This caused the typing notification to keep being displayed even after a message was sent. My only guess is that Xfire (for Windows) ignores this boolean value, and just assumes that any typing note packet that arrives means that the user is typing… Either that, or the field isn’t intended to be used as a boolean. We shall most likely never know.

Good night.