BlackBerry 10's Invocation Framework: ingenuity at work

BlackBerry 10
By Kevin Michaluk on 1 Oct 2012 11:16 am EDT

BlackBerry 10's ability to "embed an app within an app" using the Invocation Framework creates a mobile computing App World full of possibilities

[ Editor's Note: This post was written by Kevin Cheung. We bumped into Kevin at BBJAM last week, and when we asked him if he was learning anything in the sessions, he passionately began talking about the invocation framework. We asked him to write it up, and he did. Thanks Kevin! ] 

As an educator and a developer, I am thrilled by what I saw at the JAM20 session on the invocation framework. It was no exaggeration when presenter Shadid Haque told us to buckle up before giving the invocation cards demo.

In one sentence, the invocation framework can be seen as the architectural foundation for powering the last two elements of flow, connect, and extend. Invocation comes in two flavours: invoke as application or invoke as card. The former can be thought of as simply shoving a job to another app and not worrying about what the results. The latter can be thought of as embedding another app within an app.

The ability to call on other apps to perform certain tasks is certainly not new in the computing world. In fact, it has been already available on desktops and workstations for decades. But in the mobile space, its use has been quite limited. The challenge is in finding the right between flexibility, security, and simplicity.

It seems to me that the invocation framework in BlackBerry 10 has achieved the right balance. I will not be getting into the technical details of the mechanism because I am still learning. Besides, such details might turn this article into an uninspiring read. Instead, I will describe some usage scenarios to help readers get a sense of what the ramifications are. To this end, let us focus on an area that I am familiar with: education.

Most teachers and students will need a dictionary app and a word processing app. It is common for word processing apps to have features that require a dictionary. With the invocation framework, the word processing app no longer needs to implement a dictionary. It can simply invoke a dictionary app that has registered as a target. And if you want to build a classroom messaging app that provides some sort of word check against a dictionary, you won't have to package in your own dictionary. You can focus on the core features of your messaging app and let the dictionary app developers worry about building the best ever dictionary. In short, with the invocation framework, you won't need to have the three apps (dictionary app, word processing app, and messaging app) overlap in one big feature--the dictionary. This is a huge resource saver.

What this means for developers is that they can spend time innovating and build upon the bricks laid out by others. In turn, their apps can become bricks on which other great apps can be built. Viewed in this light, one can gradually obtain a tower of apps providing an experience that cannot be rivalled by any collection of isolated apps. This is pure ingenuity at work.

With the invocation framework, I believe that a new wave for mobile computing is coming and BB10 will be at the forefront. #bb10believe

Reader comments

BlackBerry 10's Invocation Framework: ingenuity at work


This is the natural evolution of the SuperApp :) Go RIM :D

Just wish BB10 had a more scalable approach to viewing and managing running apps.

True real time multitasking has the potential to be amazing. Apps "piggy backing" on apps. A map app that doesn't require gps in itself but incorporates a native gps app for example and a weather app and a road condition app. All run in real time and those that need not be constantly updated remain off until a request from the top layer app. It would be like building a civilization where a business doesn't need to build infrastructure to produce and deliver its goods as roads, ports, etc. already exist and the business utilizes them.

True...completely agree...there is a lot of potential in this architecture if done in the right direction...other wise apps will crash with cascading effects

In my understanding of QNX, cascading failures are not possible. On QNX, every process runs self contained. Should a process fail, it is simply shut down. This might affect the usefulness of another app using that particular process but the app and other apps will remain running.

That was the original design philosophy of Unix, but it got lost sight of when Gnome and KDE came along and it all turned into linked libraries rather than linked applications.

This is awesome...just one thing...I hope RIM already filed a patent on this because you know the competition will want this.

~I am BlackBerry by choice~

They have patented it. It's called QNX. Unless competitors develop a micro kernel real time OS, they won't be able to provide similar functionality.

Let's not get over enthusiastic here... There is no requirement for a micro-kernel here... it is simply a predefined standard for getting information to other applications much like Windows 3.1 did with DDE way back when and Windows could never be considered a micro-kernel (or an advanced OS at all). iOS and Android could implement something like this... it would just take some time to develop.

A micro kernel system makes this far more "doable" in mobile devices where processing power and corresponding battery power are limited. Processes can simply be added to QNX and it doesn't require a complete OS revision because of the way processes are handled by the micro kernel. Processes can be triggered when required are are given whatever desired priority is required or available. I'm still getting my head around this after seeing ads for the Cadillac "Cue" system. It is described as a Linux program but it appears that such programs with the proper "skin" can be run by QNX.

QNX is better than Linux...but I like Linux, with the exception of android, which is poorly designed and a complete security risk.

I hope they don't. Software patents are a Bad Thing that hold back innovation. Look at the Apple/Samsung/Motorola patent wars. How much of RIM's development cost is going into having patent attorneys check that BB 10 won't infringe some ludicrous bit of software obviousness?
BB10, if it is to succeed, should do so because it is a better implementation, not because RIM is blocking competitors from doing something "on a phone" which was already present in minicomputers in the 1980s.

I think a good example is the Blaq on the PlayBook.

It is a Twitter app. Within it, there is a Web browser. So I can quickly see the link. Expand it to full screen if I want to. Then one swype, I can minimize the full screen browser and back to reading my Twitter.

Happy I picked it up while it was on sales.

+1 Blaq is AWESOME!

I can't wait to have it on my BB10 device, I just hope I can add multiple accounts with ease (wait, can I do that now???)*runs off to check*

This is awesome stuff...but I have a question of how it would work (and I may be misunderstanding some of this...i'm not a developer). So...if I build a word processing app (for example), and there are 2 dictionary apps on the market...could I then tie into either of those, and then give the user the ability to choose which dictionary app they want to tie to, based on their preference?

Yes. You can query to see what apps are available to fulfill your request - and present the user with a choice. You could remember the choice after the first time and automatically attempt to use that same dictionary app the next time.

Or you can allow the system to choose the best match for you.

Or you can designate a specific dictionary app that you require.

I *think* the system can also prompt the user (instead of requiring you to do it), but I'd have to double-check my notes from that session.

It gives a good amount of flexibility to developers.

You would have three options for implementing this.

First (the least optimal approach), you could directly link to a known dictionary app, and always use that app for your invocations.

Secondly, you could get a list of existing dictionary apps on the devices, and select (or allow the user to select) the one you want to use.

Thirdly (the best approach), you can use whatever dictionary app is currently the default on the device (with no need for the developer to even know which app is the default dictionary on the device).

The user buys the spell checker (SC) app they like. It registers with the invocation framework (IF) as a spell-checker utility. My word processor asks the IF to send this chunk of text to the SC which it does. As a WP app dev, I don't know or care which speller the user has.

There are a few ways to do this technically, Here is one:

The WP sends the SC a memory location where the text is. The SC fixes the spelling and returns a new memory location with the corrected text. That is the best way as you don't have to send big messages between the apps. The IF takes care of memory housekeeping as needed.

In this case, the SC is NOT really running inside the WP. Each utility can be left sleeping until the IF calls it to do some work. That saves battery and CPU cycles.

This is not really new in some ways. For example: Evernote can embed the sound recorder in it to allow saving voice notes. That is similar. The difference here is the IF will manage everything instead of the OS. That leaves the OS to handle low-level tasks such as hardware interfaces and file systems. And if the IF and/or apps crash, they don't take the OS down.

Great write up and I appreciate the easy-to-read explanations. The idea of invocation framework sounds a lot like what RIM has been trying to explain with their BlackBerry Flow idea. Definitely too in-depth for consumer consumption right now, but I hope they take credit for leading the charge in this area. Thanks Kevin & Kevin!

this is like when you want to map something using POYNT it let's you choose to use blackberry maps or google maps. They didn't have to waste their resources building an inferior map service. Except in bb10 it will apply to a lot more things seamlessly and you won't have to choose things.

Improved resource management is the one thing I look forward too in BB10! The similar framework in BB7 is okay with the apps that I use, but it usually leads to a cluttered BB menu of sorts giving you all the different options from the apps you have installed.

Well - with all respect (as it was already mentioned by 'Bold_until_Hybrid_Comes') - On the classic BlackBerry Java Platform we had already multiple ways of an "Invocation"-Framework - Apps like QuickLaunch would be nearly impossible without it...

The so called "CHAPI" is present since OS 4.0 (when I can remember correctly) - this functionality is essential since years on the BlackBerry Java Platform...

But it depends from the fact that the app you want to call needs to support it... Unfortunately RIM has often restricted the use of key apps & functionality for internal use only...

We will see if this will be different on BB10...

Great read. Its nice to feel such enthusiasm coming from a BB10 developer. I can see why though, this concept seems so neat and efficient.
Patiently waiting.

@ Kevin,
I question(it might be silly for few) the new BB 10 phones have BB CASUAL as one of their fonts too . As Iam so used to this font guess will be very difficult if it is not there.Like i only type in the portray mode never through landscape mode....i mean im so used to seeing two letters in a box too.
Nevertheless , i had to ask this.
Pls if someone apart from kevin blaze or adam knows about it shall be grateful.
BB by choice.

This is really interesting stuff! And I can't wait to get using/developing with this system!

What does sort of.. concern me, is how this data that's being pulled and shared between apps can be standardised. For example, how would a Word Processing app use a Dictionary app developed by someone else if the way the Dictionary app passes the String data is different to what the Word Processing app is expecting?

The "X" in QNX stands for the "X" in POSIX which is a convention/standard for thread handling. This is how, for example, a Linux program can be run on QNX. I'm certainly no expert on this but the reading I have done seems to indicate it. Remember, a Linux program can be run self contained on QNX.

Yes, but you will still need a data dictionary and some way of declaring services, assuming that the framework is the service broker. And unlike libraries it all has to link together at run time.
That said, if the tools support it there is a huge gain there for developers, being able to extend and combine other people's applications. I like the idea of people building server side applications with an efficient data management client, and then other people building new services on top. This is the true "bazaar" model of development, unlike the present system with iOS and Android in which everybody is building little islands of automation.
The big iron equivalent is Tivoli, in which many IT and ITIL management applications are built on top of the Tivoli framework.

The stuff QNX is doing in cars should allay any concerns about interoperability. BB10 is sort of a miniaturized version of the car system. QNX is uncannily versatile.

There are some resemblances, but the real question is the extent to which Android developers are making use of it for anything other than basic services.

True. These frameworks usually look good on paper but end up for nothing more than opening URLs or sharing simple data types like text/images.

Except that Android doesn't.

While the Intent system on Android has some similarities, the technical details are very different. Android's existing system doesn't do anything that BlackBerry Invoke has done since 4.0. This new framework is far more powerful (and with a better UI).

I'm just here listening to a local radio program on the playbook using the nobex radio app and wondering how can I use 'invocation' to schedule the launching of the app for the time my program comes on.