BlackBerry OS 10.2.1 introduced headless applications, which allowed an application process to run in the background without any user interface. There are multiple ways headless applications can be started. A popular choice is to start the headless part when the device starts using the bb.action.system.STARTED trigger. That trigger also starts the application when it is first installed. This is useful for applications that always need to be running in the background, but can lead to inefficiencies and a poor user experience. If you want to jump straight to a sample application, have a look at the DeferredAutoStart sample on Github. Otherwise let’s take a look at a couple of scenarios where this isn’t ideal.

Example Scenarios We Can Improve

Headless Applications that Require Credentials from the User

The first scenario applies to applications that require credentials that the user has to supply using the GUI part of the application. If the headless application isn’t able to do anything useful without those credentials, all it can do is run, check if the credentials are present and exit if they are not. Starting it every time the device boots means wasted battery and CPU resources.

Corporate Applications Pushed from a BlackBerry Enterprise Server

Applications that use the system started trigger are also started when they are installed. The prompt for the user to grant the required permissions to an application is shown when the application runs for the first time. This means that the permission prompt is shown to the user when the application is installed. That can confuse a user when such an application is pushed out from a BlackBerry Enterprise Server because the user might be prompted without any context on what triggered the prompt.

The Solution

The solution to both of these scenarios is to defer the auto run on startup feature until the user has launched the GUI part of the application. When they launch the GUI they can approve the permission prompt they expect to see. They can also enter credentials required by the headless application. Once one, or both – depending on the application’s requirements – of these requirements are met the application can configure itself so that the headless part is auto run on startup.

How We Solve It

The first step is to remove the bb.action.system.STARTED filter from the bar-descriptor.xml of the application like this:

<invoke-target id="com.example.DeferredAutoStartService">
<invoke-target-type>application.headless</invoke-target-type>
<invoke-target-name>DeferredAutoStart Service</invoke-target-name>
<entry-point-id>DeferredAutoStartService</entry-point-id>
<!-- Removed the filter to prevent auto run on startup.
This is added back at runtime once we want to enable auto run on startup.
<filter>
<action>bb.action.system.STARTED</action>
<mime-type>application/vnd.blackberry.system.event.STARTED</mime-type>
<property var="uris" value="data://local" />
</filter>
-->
</invoke-target>

The invoke-target id is still defined and we will modify that later. Removing the filter prevents the bb.action.system.STARTED headless trigger from firing, preventing the headless application from running when installed and on startup.

The next step is to update the GUI application to add that filter back once all requirements (permissions accepted and/or credentials entered) for the headless application to function are met. To do that you create an InvokeTargetFilter that matches the one that was removed from your bar-descriptor.xml. An InvokeTargetFilter that matches the example bar-descriptor.xml code above would look like this:

The Sample

You can download a complete sample application that implements this technique from our Github site here: DeferredAutoStart

]]>http://devblog.blackberry.com/2014/12/deferred-autorun-headless-app/feed/0BurnoutmsohmImage Source: http://commons.wikimedia.org/wiki/File:Rolling_burn_out.JPGLaunch Your Apps with Keyboard Shortcutshttp://devblog.blackberry.com/2014/12/launch-your-apps-with-keyboard-shortcuts/
http://devblog.blackberry.com/2014/12/launch-your-apps-with-keyboard-shortcuts/#commentsMon, 01 Dec 2014 19:19:20 +0000http://devblog.blackberry.com/?p=19071/ Read More]]>With the launch of Blackberry Passport and soon to be launched BlackBerry Classic, one thing is clear; (physical) keyboards are not dead, far from it. For power and productive users like me (nice plug, eh?), I cannot imagine five minutes of my day without keyboard shortcuts. So without further ado, let me introduce one subtle, innovative and mighty feature of BlackBerry OS 10.3.1 – keyboard launch shortcuts for your apps.

The first of the two ways a user can launch your app using keyboard shortcuts is by assigning a key for your app as an App Launch Shortcut. This, by the way, comes for free as in you don’t have to do a thing in your app for this.

While just being able to launch an app may make some users productive, it doesn’t quite satisfy me. What would be truly productive is if I could shortcut to a specific task in an app. If you compare launching the BlackBerry Hub vs launching the composer screen of BlackBerry Hub, you definitely know what I mean. Fortunately, we have also built that in to 10.3.1 for you. But this requires a few lines in your bar-descriptor.

Defining an invoke filter with bb.action.SHORTCUT action and application/vnd.blackberry.shortcut as the MIME type, your custom shortcut becomes available for the user to pick from the Other Shortcut category. However, please note that you MUST give the target a meaningful icon and a name for the task it performs as shown in the example above.

You can define as many such shortcut candidates as you wish in your app – each performing a specific task. But wait, it gets better. For some shortcut tasks such as muting device notifications, invoking a UI app does not make any sense. With that in mind, we also enabled the capability to launch headless invoke targets in your apps. So feel free to create such headless shortcut targets but please make sure that you provide the user some feedback after the headless app is done with the task. Otherwise, as a user, I would find it pretty annoying and will have no idea if the task was successful or not. Even flashing the LED or vibrating the device can go a long way but depending on your use case, think about other options such as notification dialogs or instant previews.

BlackBerry users have always been and will always be pushing the boundaries of productivity. I think adding shortcuts to your app is one way of respecting your users as a developer. That’s all folks. Hope this was an awesome read. You now know which apps I am going to purchase for my BlackBerry Classic come 10.3.1. Just let me know when you got one @shadidhaque.

Since the introduction of headless apps in BlackBerry OS 10.2.0, many of our fellow developers have built fantastic apps that run in the background. Thank you. However, there is one thing we all are anxiously waiting for – debugging those headless apps.

So far we have relied on QDebug()s and printfs. But if you haven’t guessed already from the title, let me say it again – headless app debugging is finally here with Momentics 2.1. Since this is the most anticipated enhancement to our developer tools, we made sure that it’s one of the easiest things to use in the IDE.

Without further ado, let’s have a look at how I just debugged a headless app today. First and foremost, add some break points in your headless project’s source code.

On the toolbar, in the Launch mode drop-down list, select Debug.

In the Launch configuration drop-down list, select the UI part of your headless app.

Click beside the launch configuration drop-down list.

In the Edit Configuration dialog box, change the Entry-Point to the service part of your headless app.

Click Apply and then click OK.

In the Launch target drop-down list, select a device or simulator.

Click to debug your headless app.

8. Voilà! The Momentics IDE changes to the Debug perspective, installs the app on your simulator or device, and starts the app under the control of the debugging tool.

The support for headless debugging completes the developer experience with headless apps, and I have no doubt that this will help us all design and build even better headless apps. Until next time, have a blast with this, and feel free to yell @ShadidHaque any time.

With the launch of the 10.3 Gold SDK, I am very excited to announce several improvements to our Phone APIs. With user’s direct permission, these APIs will provide better control over a phone call, access to call logs, and access to the phone audio channel for call recording.

When it comes to call control, previously we had the ability to only initiate and end calls. To provide better control over ongoing, incoming and outgoing phone calls, the Phone class is now equipped with several new functions. If you need to put a call on hold, you can now use holdCall and to resume a call you can use resumeCall. You can also split a conference call into two calls with splitCall as well as merge two calls by calling mergeCall. Combining previous APIs such as initiateCall, encCall and sendDTMFTones, I think this pretty much completes the Phone APIs when it comes to controlling phone calls. Oh, and before I forget, 10.3 also introduces initiateVideoCall to start a video call such as BBM Video.

Next up are APIs for call details and call logs. Remember that callUpdated signal which gave you a Call object but didn’t actually provide the number of the party on the other end? The wait is over; the call object now has a convenient function called phoneNumber that lets you read the phone number of the calling party. Problem solved! I know a lot of us, including myself, are super excited about this; so call blockers, please go nuts. But we did not quite stop there. In 10.3, we are also introducing a CallHistoryService for reading call logs. Remember, you can only read the call log with this service. The CallHistoryService also comes with useful signals for when a call is added or deleted from the call log.

These enhancements to our existing Phone APIs line up quite well with our renewed focus on enterprise solutions. In fact, we built these with pure enterprise use cases in mind. Solutions such as enterprise call recording via a proxy server or call blocking will greatly benefit from this, but please do not hesitate to contact me if you have any questions @ShadidHaque.

]]>http://devblog.blackberry.com/2014/07/phone-api-ten-three/feed/0Phone API featureshadidhaqueBetaSDKv_2blackberry-passport-call-screen1Developing Headless Applications with WebWorkshttp://devblog.blackberry.com/2014/07/headless-webworks/
http://devblog.blackberry.com/2014/07/headless-webworks/#commentsTue, 22 Jul 2014 18:30:43 +0000http://devblog.blackberry.com/?p=18599/ Read More]]>A Headless application is native code that can run without any UI, with minimal memory and CPU cycles. However, developing a WebWorks application that works together with a headless service is relatively easy. Using this approach means you can still leverage WebWorks for all the main application development, while augmenting the app with a small piece of code that responds to any of the headless triggers, or runs constantly in the background. For me this is really taking advantage of the best of each development approach.

Using the latest WebWorks 2.1 SDK, you can create a new project from a template which includes a headless portion. This will set up an application that you can easily edit to suit your needs. Run this command to do so:

webworks create-headless

This command will create a WebWorks 2 application with some extra parts to the config.xml file, and a native application project in the HeadlessService folder. The compiled version of this code will be in the www/assets folder, where the config.xml file knows to launch it from.

If you look at the config.xml, you’ll see the definition of two entry points:

Another part of the config.xml sets up the headless application to run when the system starts:

There are lots of different triggers that you can use, and each one is configured through the Invocation API similar to the example. Visit this page on Triggers to see the other options.

I won’t get too much into the sample native code. The project created by the create-headless command can be imported into Momentics so you can edit it. Follow our guide for making headless applications to see what features you can take advantage of.

In this blog post, I’d like to focus on communication between your headless app, and the UI portion. There are really a lot of different ways you might come up with to do this, but a couple nice simple ways are provided for you to start with. The template project uses the Notification API – so it creates a notification in the hub which, when launched, invokes the UI portion.

Another approach is to use the file system. Both the headless and UI parts have access to the same sandbox, making it easy to have the headless app store data there, which can be read by the UI. Our other sample in GitHub uses this approach. The headless portion listens to the accounts on the device and logs message changes in a text file. The UI portion uses the standard HTML5 File API and the blackberry.io plugin to read that file and display the contents.

Headless applications are not able to invoke the UI portion directly, so how you connect the two parts depends on how you need to interact with the user. Notification will allow you to get their attention if you need it, while using the file system will allow you to have content ready for the user as soon as they open the application.

To learn more about creating WebWorks applications with headless components see the documentation on our developer site. Whole new categories of applications should be possible now.

Many of you have already been enjoying BlackBerry WebWorks SDK version 2.0, which included our new GUI tool and a whole bunch of Apache Cordova goodness. Since the 2.0 release, we have been hard at work addressing your feedback and building some new features specifically targeted at our Enterprise development community.

Last week Tim Neil announced the release of BlackBerry WebWorks SDK version 2.1, so let’s take a closer look at what’s new.

Native Services

Developers using the BlackBerry 10 Native SDK have been able to leverage background and headless applications for a while now. With this release of WebWorks, we added an additional command line option for creating new projects that include a headless native service. For more information from the command line, type “webworks help create-headless”. Once you run the “webworks create-headless” command and create a new project, you will notice a new HeadlessService directory in the root of the project, which containsthe native service code.

We’re also providing a number of sample applications that will demonstrate some highly demanded use cases that can only be addressed with a native service, such as automatic Push registration for a WebWorks application, as well as email and SMS listening and processing. Stay tuned for updates on the Samples page.

Work Perimeter Debugging

If you’ve been working on an app that’s deployed to the work perimeter, you’ve only been able to debug it over Wi-Fi. You also needed to have the BES administrator deploy the application through a software configuration.

With BlackBerry 10 OS version 10.2, an IT Policy was introduced to allow you to deploy applications directly to a device over USB. With the release of BlackBerry 10 OS version 10.3, things have become even simpler. For devices running BlackBerry 10.3, you’ll be able to debug an enterprise app deployed in the work perimeter using Web Inspector over USB.

Tool Enhancements

While the new GUI tool provides almost everything you need to configure, build and deploy your application, we added a few advanced items to this latest release. Particularly when dealing with enterprise apps, developers often need to transit through a proxy in order to communicate with BlackBerry’s signing services. The GUI tool now allows you to configure proxy settings.

In addition, for enterprise development shops that use a common developer signing certificate, you can now set a remote location for the developer certificate, for example, if it exists on a network drive.

We also added the ability to manage multiple deployment targets from within the GUI tool. You can now define targets for any number of simulators or devices and provide their IP addresses. This means you can now deploy over Wi-Fi to a device.

Once you have defined your targets, you can select which one you wish to use from the project build page. If you leave it on the auto-detect option, it will deploy to a USB-connected device or running simulator.

New APIs

We recently analyzed download and usage trends for Community APIs that are getting a lot of traction and decided to promote a couple of them to be fully supported in the SDK.

The Prevent Sleep community API allows you to prevent the screen from timing out and turning itself off. In promoting this to the full SDK, we moved this functionality into the com.blackberry.display API. A popular use case for applications that need to keep the screen on indefinitely is navigation. However, it’s important to be aware of the impact this may have on battery life, so use this judiciously and ensure you turn it off whenno longer required for the current operation of your application.

The com.blackberry.screenshotAPI allows you to take a screenshot of what is currently being displayed. Pretty self-explanatory!

So that is the high-level summary of the latest release of our BlackBerry WebWorks SDK. You can get started right now by downloading the new SDK here. We’d also love to hear feedback on the new features in the forums (using the new direct link in the GUI tool!) or on Twitter at @BlackBerryDev!

]]>http://devblog.blackberry.com/2014/05/blackberry-webworks-2-1-released/feed/0blackberry webworks 2.1kjwallisblackberry webworks 2.1_headerblackberry webworks 2.1_headlessserviceblackberry webworks 2.1_proxyconfigurationblackberry webworks 2.1_talentmanagementHeadless Apps 101http://devblog.blackberry.com/2013/11/headless-apps-101/
http://devblog.blackberry.com/2013/11/headless-apps-101/#commentsFri, 08 Nov 2013 15:30:19 +0000http://devblog.blackberry.com/?p=16581/ Read More]]>The recent introduction of headless apps in BlackBerry 10 has generated phenomenal interest among developers. You also had a lot of questions around headless apps that need to be answered, so as a follow up to my first article, Rise of the Headless Apps, I am back again to answer some popular questions and also to walk you through how to create a simple headless application.Types of Headless Applications

First off, there can be two types of headless applications – long running and short running. The type determines how long a headless application can run each time it gets launched (more on getting launched later). The life of a short running headless app is 20 seconds long, and a long running headless application is free to run indefinitely from the time it launches. Determinig whether your app should be long or short running is an important decision. Short running applications are ideal because the device can run more efficiently. However, if 20 seconds isn’t enough, then write a long running app; just be sure to apply for special permission via the App Permissions Request form. Otherwise, you will NOT be able to properly sign long running headless applications.

Structure of a Headless App

A headless application is a package of two separate application projects packaged in one bar file. One is responsible for the UI part of your application that gets launched when the user clicks the application icon on the homescreen. The other is responsible for the headless service (either short running or long running). Note that you MUST always have a UI entry point in your headless application package, because headless application packages will still have an icon on the home screen and the system needs a UI entry point to launch when that icon is clicked. That way, the user can always stay in control of the app.

When do headless applications get launched?

A headless application can be launched in two ways. It can either get invoked by the system on certain system events (aka triggers), or by any UI application including the UI entry point of your headless application package. Essentially, you define invoke targets for your headless entry point that the system or a UI app can invoke.

Note that a headless process cannot invoke UI applications.

What system triggers are currently available?

If you choose to have your app launched by the system based on certain system events, we currently have four triggers available:

system.STARTED: Triggers your headless application on device startup, or as soon as the app gets installed. Common use cases are long running headless apps that run 24/7, or a short running headless app that needs to perform some initializations/registrations when the device starts up.

PORT_DIRECTED_SMS – Triggers your headless application when an SMS message arrives on a custom port that your app registered for. Note that this is not meant for SMS messages that appear in the regular sms inbox.

This is only the first batch of triggers that shipped with 10.2. We are actively tracking trigger requests based on their popularity and are committed to bring more triggers in the future.

Great! So how do I build a headless app?

While it is true that there are a number of steps involved in creating headless apps, I can assure you that it does not involve a lot of coding. Whether you are building a new app or you are converting an existing app to headless, the following steps should clearly show exactly what you need to do to create the skeleton for a headless application:

That’s it! For more details, head straight to our all new documentation page for headless apps. We also created templates for headless apps built right in to the IDE so that you don’t have to go through these steps manually, but for our deeper understanding, let’s go over what the template does for us.

Sample Applications

Reading documentations are great (assuming we do), but nothing comes close to real sample applications that we can download and run out-of-the-box. With that in mind, we created sample apps to demo different aspects and use cases of headless apps. The following samples are currently available in our github repository, and there are a few more on the way.

Create a long-running headless app that is launched on system startup.

Communicate between the UI and the headless process through local sockets. This is only one of many communication choices (ie. sockets, pps service, etc).

Respond to invocations by its UI counterpart.

Where are headless apps supported?

Short running headless applications are supported on all devices running 10.2. If you are planning to develop a long running headless app, you can do so using the latest 10.2 developer build posted here. However, we have decided to only approve long running headless application submissions on BlackBerry World for 10.2.1.

That’s all from me for the day and I hope I have answered a lot of the questions you had on this topic. If I missed anything, please hit me on the developer forums or @shadidhaque. Happy coding and let’s lose the heads!

]]>http://devblog.blackberry.com/2013/11/headless-apps-101/feed/0dev-headless-apps-101-featureshadidhaqueheadless apps 101Headless Apps Explainedhttp://devblog.blackberry.com/2013/09/headless-apps-explained/
http://devblog.blackberry.com/2013/09/headless-apps-explained/#commentsTue, 24 Sep 2013 19:00:23 +0000http://devblog.blackberry.com/?p=16267/ Read More]]>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.

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!

]]>http://devblog.blackberry.com/2013/08/rise-of-the-headless-apps/feed/0shadidhaquerise of the headless appsBlackBerry Jam Unplugged: Headless Appshttp://devblog.blackberry.com/2013/04/blackberry-jam-unplugged-headless-apps/
http://devblog.blackberry.com/2013/04/blackberry-jam-unplugged-headless-apps/#commentsFri, 19 Apr 2013 13:59:50 +0000http://devblog.blackberry.com/?p=14725/ Read More]]>You can now check out the latest video in the BlackBerry Jam Unplugged series, where we give some more insight around our considerations for upcoming headless applications on BlackBerry 10.

We’ll be continuing this video series leading up to BlackBerry Jam Americas in Orlando in order to give some more background surrounding the topics that we’ll be discussing in detail during the conference.

In this particular video, we’re joined by Geordie Ferguson to talk to us about the ins and outs of headless applications and the areas that we’re exploring to bring this type of functionality to an upcoming release of BlackBerry 10.