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.
