I've spoken to many developers about the state of headless apps and much of their feedback was used to write this article. I chose to write this under my name and leave their names out of it as they some of the top developers on the BlackBerry platform and they don't want to stir the pot. I'm writing this because it needs to be said - sometimes BlackBerry needs tough love to get things done.

It was just over 5 weeks ago that BlackBerry released the Gold 10.2 SDK to developers which was to include support for headless apps. I had planned on writing this article right after the release to update everyone on how headless apps would work. However, I wasn't expecting to have to write a negative article about it which is why I held off until now, hoping that BlackBerry would release more information or updates.

For those not familiar with the term 'headless' they are apps that can run without an Active Frame. It was one of the most frequently requested features by both users and developers. Unfortunately BlackBerry didn't seem to hear us and have made headless apps into something neither practical or efficient for most developers to implement. In fact they've made it so difficult and complex to implement most of the developers I've spoken to about it aren't going add headless support to their apps.

So what went wrong? Lets start at the beginning.

There are 2 types of headless apps: triggered and non triggered long running.

Triggered headless apps can start based on a predefined event that occurs, there are 4 such events:

Push - which has always been there and requires the developers to set up a push server

- which has always been there and requires the developers to set up a push server SMS – received on a specific port (this is not normal SMS messages)

– received on a specific port (this is not normal SMS messages) Geofence – device enters/leaves a specific physical location

– device enters/leaves a specific physical location System start up – App can run when the system boots

So these could be useful in theory, but there's a catch. The app can only run for 20 seconds once triggered and then will be shut down by the OS. There are more caveats which I will explain later.

Long running headless apps sounds more like what every one was waiting for. The idea behind long run headless apps is that they can run in the background at all times and not be shut down by the OS after 20 seconds. There are restrictions on how much CPU the app can use when it is in the background and also memory limitations. Long run apps can use up to 3MB of RAM which severely cripples functionality developer can add. On top of that, long run headless need to be approved by BlackBerry. I applied for my app Wallpaper Changer HD to be a long run headless app. Wallpaper Changer doesn't need an Active Frame at all. Currently I have the option for a battery meter or weather in the frame but both those are displayed on the SuperBar on the home screen with my app so it's redundant. I was one of the first developers to apply 5 weeks ago when the form went live - I have yet to hear back.

Simply put headless apps require you to split your app into 2 apps

Diving a little further into the technical issues surrounding headless apps the biggest issue developers I've spoken to have is that headless apps require a major re-write of code. Simply put headless apps require you to split your app into 2 apps. The 'logic' portion of the app that needs to run in the background needs to be put into 1 app and the UI portion goes into another app. That alone poses a huge problem, firstly because as it stands headless apps can't be debugged properly and secondly because many apps have their logic and UI tightly bound together and splitting them would break many things. Not to mention any logic that is written in QML (Cascades) cannot be used in a headless app and would need to be re-written in C/C++. This creates even more work when a developer needs to continue support for OS 10.1, they would then have to maintain 2 completely separate code bases.

So lets say a developer is willing to jump through these hoops and split their app up, there is another issue. The headless portion and UI portion have no efficient way of communicating with each other. A couple of weeks ago BlackBerry released a Tic Tac Toe game as an example of a headless app to help developers learn. The way the headless portion of the app communicates with the UI is through a network socket. What this means is that the UI app opens a network connection and listens for incoming requests. The headless portion then sends information over the network connection to the UI. One word can describe this – terrible.

It seems that BlackBerry doesn't even want developers to use headless apps

Moving on from the technical nightmare it seems that BlackBerry doesn't even want developers to use headless apps. To me it feels like they released it like this just so that they could say headless apps exist fully knowing that most developers wouldn't touch it with a 10 foot pole. After the the Gold 10.2 SDK was release BlackBerry held a webcast for developers outlining the changes and improvements in 10.2. The webcast was 2 hours long and they literally spent a couple of minutes of that talking about headless apps. For being one of (if not the most) requested features, this immediately set off alarms for many, including myself, that headless was doomed from the beginning. BlackBerry has also released next to no documentation on implementing headless applications. I was hoping after 5 weeks would would have seen something more.

Now don't get me wrong - I understand the fundamental reason BlackBerry is trying to restrict background apps. They don't want apps running wild in the background sucking up battery. However I think they've gone about it completely the wrong way. To me and many other the choice should be the users.

One simple way to give everyone what they wanted we have been as simple as something like this:

When a user presses and holds on the X on an Active Frame a notification pops up asking if they user if they want to close the app or hide the Active Frame. If the user hides the Active Frame, add a new badge to the app icon to let the user know the app is still running. If the user clicks the icon the app opens back up. If the user was willing to let the app run in an active frame what is the difference if the frame is visible or not? If BlackBerry is still worried about apps sucking up battery then if an apps active frame is hidden and the OS detects that the app is using at lot of battery then notify the user and let the user decide to close the app or continue to let it run. What do you think of this idea? Let us know in the poll.

The problem has been and may always be that they do whatever they think we may need instead of just listening and giving us what we really need

So to summarize I really think BlackBerry needs to re-evaluate the state of headless apps. In the past their typical response to developers would be that its already great but they are working to improve things and changes will happen in the future. But this time around I think the right thing for them to do is step up and say they really screwed this one up. Scrap headless apps as they exist and start over – this time listening to what developers have to say. If I may quote a developer friend of mine, I think he summed up headless apps perfectly: “I gathered from the description on the DevBlog and my previous discussions with development that they would make it so useless that it would end up being a waste of time for everyone. The problem has been and may always be that they do whatever they think we may need instead of just listening and giving us what we really need.”