There’s been lots of discussion around the headless application topic lately and it’s also one of the most popular topics at BlackBerry Jam events. As usual, we want to be open, honest and clear with our community around the decisions we’re making and providing you the background to those decisions so that you can understand our thoughts on the topic.
The number one goal of providing headless app capability is to allow for behind-the-scenes services to provide value while not impacting the user’s current actions. This, while seeming like a simple statement, is a delicate balancing act.
On BlackBerry 10 we want to ensure that we find the right balance, and yes, that does mean we are being very cautious about how we expose the capability of background running apps as well as how we approve and test those who wish to take advantage of the capability.
Background and Research
I personally have lived through our history on the BlackBerry 5/6/7 OS where we have seen what an imbalance can cause when it comes to background running applications. UI stalls, hourglassing, typing lags and long reboot times all add up to a user experience that our customers made loud and clear was unacceptable.
Through our research into the headless use cases with our development community, it became very apparent that they needed to be running in order to listen for certain triggers that in turn made them take action. In many cases these applications were polling, or assigning constantly open listeners using up valuable CPU and memory resources of the device. In almost all of these cases, each time a trigger fired, the application actually took on small amounts of processing. So there was a ton of overhead going on in order to have small short bursts of action.
Funny enough, when we researched the memory usage of the headless components of our core applications on BlackBerry 10, they all fell beneath the 3MB limit we place on third party headless applications. As an example, the BBM headless portion uses 1772KB of memory. It goes to show that highly functional headless applications can be built staying within this cap. We even have the capability to bump the cap via permissions if a special use case arises.
These details were the basis of the implementation of the invocation framework and an ability to subscribe to different triggers in order to be invoked into action. This same publish/subscribe model was used in 10.2 when implementing the headless app capability. These triggers fire in order for a headless application to take action using short bursts, thus reducing the overall impact of the device CPU and memory usage. We also realized that we needed to be cautious and limit the first set of triggers as we continue to monitor the impact of headless applications on our operating system. The triggers chosen were ones where we had concrete use cases with key partners and carriers to put the system through its paces.
These short-running headless scenarios, with the right amount of triggers, can power a multitude of use case scenarios. When I say short-running, they are provided 20 seconds to execute, which in CPU cycles is something like a kajillion cycles. 
Known Limits to Triggers
We realize that these triggers only scratched the surface of what needs to be exposed. That was absolutely loud and clear from all of your great feedback during our developer events and through our online channels. There are lots of requests for chronos, device connectivity, PIM and other types of triggers. We decided to also provide special permissions for those who were approved to allow constant running in the background. With that said, our goal is to add all the required headless triggers to reduce the need for a constantly running headless application to nearly zero. We also have been improving our notification systems in order for you to create a notification to alert your user of a change and in turn have your application’s UI invoked.
I would also like to let everyone know that we are still continually improving the documentation [VO1] and samples around headless applications to make it easier for you to implement and understand how it all works.
Application Permission Process
So let’s talk about the application permissions process for these always running headless app scenarios. Because we are early in understanding the true impact of long running headless applications on the end-user experience, we need to limit how many applications get this capability. As I mentioned, we want to get to a point where we have enough triggers to negate the need for this capability, so we want to limit the amount of vendors who receive the capability.
Every request we receive for this permission is first scrutinized by the leads of the engineering groups who built the headless capability as the first pass for approval. Based on their recommendation on how impactful this could be on the user experience, the apps that are approved are then sent for VP approval both by Engineering and Product Management. Only then will the signing permission be granted to that vendor. We’ve seen a lot of requests coming from the community to get these permissions, and we’d like to note that it takes some time to get through this process.
I’d also like to take the opportunity to share that there isn’t a special process required for those distributing their application through BlackBerry Enterprise Server 10 via BlackBerry Balance to employees, as the enterprise is taking on the role of allowing/disallowing applications on the work-side of an employee’s device.
BlackBerry World Testing and Publishing
Constantly running headless applications submitted to BlackBerry World will undergo extra scrutiny during the testing process. This is to ensure that constantly running headless applications made available to the public for download do not impact the user experience of the device. We’ve provided the tooling, simulators and SDK OS versions for you to build and test your headless applications, so please take the extra time to ensure that your long running headless applications behave well on the OS.
Those who are providing trigger based short running headless applications will follow the usual testing and approval process in BlackBerry World.
We are currently accepting submissions of long-running headless applications to BlackBerry World for testing and review, and we will allow them to be published for download starting at the release of 10.2.1.
I know this will be disappointing to some of you, but we are making all necessary efforts to ensure that these submitted applications run in an optimized fashion on the operating system. We are thoroughly testing for user impact and want to ensure that published headless applications deliver an excellent experience to our customers. We require the extra time to test, observe and make any needed adjustments to BlackBerry 10 to ensure that end-users are not impacted by this capability and your desired application’s functionality.
We’ll be discussing more on headless applications at BlackBerry Jam Asia, and are always available through Twitter, email and our forums. So I invite you to engage in the conversation further both in person and online.