One of the highlights of our 10.2 Gold SDK was the introduction of headless applications. I want to explain what headless apps are, and what you need to get started. A headless application is one that runs in the background without a visible UI. The most common use case for running a headless app is when the application needs to monitor events in the background such as incoming phone calls, emails, push messages, location updates, and even changes in sensor input. If the user experience is improved by not seeing active frames, you probably need to go headless.
Note that, just like any other app, headless applications will still be installed via BlackBerry World and will still have an icon on the home screen. However, they will have two entry points − one for the headless service and the other for the UI portion, which would launch when the user clicks on the app icon.
The biggest concern regarding headless apps is that the user cannot see them, as they take up device resources such as memory and CPU cycles. So we came up with a way that provides some out-of-the-box optimization of these apps to keep impact on the system to a minimum. This resulted in two different kinds of headless apps: triggered headless apps and long-running headless apps.
Triggered Headless Apps
While evaluating third-party use cases, we identified that most apps really do not need to run all the time – they only need to perform small amounts of processing on certain system events. Hence, the trigger-based model was born. As a triggered headless application, your application remains as dead as an app that’s not running. However, when something happens in the system that is relevant to your application, it will be invoked with the relevant data in the background without any visible UI. Once invoked, it will only be allowed to run for 20 seconds − so please make sure your headless entry point is as light as it can possibly be, and can finish the task within that time. It is also worth mentioning that headless applications can only use 7 to 25 percent of CPU at any given time and can take up to 3MB of memory. The goal of these restrictions is to minimize the impact of these apps on the overall user experience.
For a trigger-based model to work, we also need to make sure that we have enough triggers to satisfy most application needs. In 10.2, we are launching with the four most important triggers, but please expect many more in our future releases. The current triggers are: Push Notifications, Device Start-up, Port Directed SMS and Geofence. If you have a trigger in mind, please let me know at @shadidhaque.
Long-Running Headless Apps
While the idea of trigger-based headless app sounds really great (it is!), there are applications out there that simply cannot work within this framework and they truly need to run all the time. We get it, and that’s why we also have an option for apps to always run in the background. We are calling them long running headless apps. These apps will still be restricted by the same 3MB memory and 7 to 25 percent CPU rules, but there is no time limit imposed. You can probably understand the risk here, as these apps are processing continuously, potentially consuming battery and memory.
Before developing long-running headless apps, you will have to apply for signing permissions through the App Permissions Request portal we launched with 10.2. Please do not hesitate to apply, as we want to make sure every app that really needs long-running headless gets the permission to do so. Once you get the signing permissions, you can start building the app and submit it to BlackBerry World. Upon submission to BlackBerry World, your application will go through a rigorous technical vetting process that will check for efficiency, CPU usage, memory footprint and battery life. It is very important to ensure that your long-running headless application is efficient and a good citizen of the platform.
Lastly, there are times when you may need to bring the UI entry point to the foreground. You can do so when your headless application is running. However, we can’t just pop up the application on top of what the user is doing – that would just be rude! Hence, every foreground request will go through a user confirmation, keeping the user in control.
That’s all for now, but you can start reading the documentation here on headless apps today. Stay tuned for a follow-up post on this topic soon, with more docs and complete sample applications!