Get Your Invoke On: BlackBerry 10 Invocation Framework

How-to

BlackBerry® apps have always been known for their ability to deeply integrate with core applications as well as with other third-party apps. With BlackBerry® 10, we are taking that experience to the next level with our Invocation Framework. It enables one application to request another to perform a specific task. For example, BlackBerry® Messenger (BBM™) may request an app to open a .DOC file that it received in a chat session. But that’s just the tip of the iceberg – the framework streamlines the communication between apps and provides a consistently smooth and jitter-free user experience.

First and foremost, there are two kinds of invocations – unbound and bound. An unbound invocation is performed when an app does not specify a specific target app that should get invoked, and hence relies on the invocation framework to select the best target. For example, if there are three apps that can open .DOC files, the framework chooses the best one based on its own target selection logic. So, for unbound invocations, the framework provides automatic brokering to find the best-fit targets and also performs target selection to choose the best among the best. This is very powerful because the client application does not need to know any target applications at all, and yet it can discover and invoke them via the invocation framework.

TITLE_IMAGE

On the other hand, a bound invocation is performed when the target app is specified by the client application while sending an invocation request. For example, a client app may request that Docs to Go® should be invoked for opening a .doc file. In this case, the invocation framework does not provide any brokering (or target selection) and blindly invokes the specified target app with the request parameters. Extra care must be taken when performing a bound invocation because an app may be sending a request to a target that the target does not understand at all. One thing is clear — bound invocation assumes that the client knows the target well.

There are really two ways you can know a target. First, you might have had a conversation with the author of the target app and have an agreement on the invocation request parameters. In return, they have made you aware of their target ID that you can use to perform a bound invocation. Second, you can query the invocation framework with an invocation request to get a list of best-fit targets and programmatically parse their attributes (capabilities) including their target IDs and invoke one programmatically. Note that querying is another way to discover apps without knowing them and is even more powerful and flexible than unbound invocations. As long as you have a valid target ID, you can perform a bound invocation with the appropriate parameters.

So far so good, but how does the invocation framework know about all the target apps? It does because each target app is required to register with the framework if they wish to be considered by the framework. While registering with the framework, targets must specify a target id which alone makes them candidates for bound invocation. However if a target wants to make itself available for unbound invocations or invocation queries, it must define one or more invoke filters. Each filter is a combination of the following attributes.

  • Actions (e.g. bb.action.OPEN) that describes the action it can perform
  • MIME types (e.g. application/pdf) describing the content type it can perform the action on
  • URIs (e.g. http://, file://) specifying the protocols it can handle to retrieve the data
  • EXTs describing the file extensions it can handle if the URI scheme is file://

Note that at least one action and one MIME type is mandatory for each filter definition, and if the URI is file://, at least one EXT must be specified. Filters are what really allow the invocation framework to broker between clients and potential targets as well as target selection that lead to successful invocations.

Well, that’s a 30,000 feet overview of the invocation framework but as a developer I know your hands are itching for some real code. The good news is I have that covered — I have already uploaded a few sample applications on Github that you may find very (very) useful.

  • InvokeClient – An application that demos different ways to invoke and to query for targets
  • InvokeTarget1 – A dummy target app that can be used with InvokeClient
  • InvokeTarget2 – A second dummy target app that can also be used with InvokeClient

Samples are great, but so are documentations (if we read them) for a solid understanding. Please refer to our App Integration development guide for a comprehensive guide with code snippets for both invoke clients and targets.

I am more excited than ever before to introduce the invocation framework as part of the BlackBerry 10 Native SDK beta 2 and have no doubt that this will help most app developers out there to provide a deeply integrated user experience. Invocation is one of the core aspects of the BlackBerry 10 experience and come launch, it is going to be hard to find an app that does not invoke or get invoked. I will keep everyone posted on new features as we add them to this framework but more importantly, I am all ears to your feedbacks at shaque[at]rim[dot]com, @BlackBerryDev and @shadidhaque.

About Shadid

Application Development Consultant at Research In Motion (RIM), Shadid is a developer and more importantly a developer developer. He has been working closely with the dev community to help bring the best BlackBerry® experience to their applications. A key contributor in the Developer Relations team, Shadid is the lead contact for Location Bases Services, Sensors, Bluetooth and Deep Integration of Apps. Working with BlackBerry developers is not just his job but a passion he shares with the BlackBerry developer community.

Join the conversation

Show comments Hide comments
+ -
blog comments powered by Disqus