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.

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.

Download the sample app

So this is it folks — no more hair-pulling to figure out how to talk to social networks directly. There are already apps for them, so let’s learn how to leverage those apps from ours instead of reinventing it.

The first step is to create the data or context we would like to share. This context is simply a JSON object that encapsulates our data. Here is an example:

JSONObject context = new JSONObject();
try {
context.put(SendCommandContextKeys.TEXT, "Your Text");
context.put(SendCommandContextKeys.SUBJECT, "Your Text");
// context.put(SendCommandContextKeys.PATH, "file:///.....");
} catch (JSONException e) {
System.out.println(e.toString());
}

I intentionally commented out the PATH type data because we cannot use PATH data in a context that also has TEXT or SUBJECT types. But I still wanted to highlight that we can also share a file path (e.g. a photo).

Once we have our data context nicely wrapped up in a JSONObject, we need to create SendCommand objects that point to specific apps with a specific context. So how do we get these SendCommands? Easy peasy — we simply query the Send Command Framework with our context data. Here’s how:

SendCommand[] commandsAll =
SendCommandRepository.getInstance().get(SendCommand.TYPE_TEXT, context, true);

Notice that the 3rd parameter above is a Boolean. If true, the query returns all commands regardless if their associated applications can be opened; if false, it returns only commands whose associated applications can be opened. Ideally we would set it to false; however, in this post we will see how we can get them all and filter them in our own application logic.

Each SendCommand object has an ID that uniquely identifies the target app and the context. Note that the IDs are not documented as there could be so many of them, but it is fairly easy to figure them out by experimentation. Since our target is the Facebook app and the Twitter app, let me save you the work by telling you what their IDs are.

Now let’s filter:

for (int i = 0; i < commandsAll.length; i++) {
if (commandsAll[i].getId().equals("Twitter_text")) {
commands[0] = commandsAll[i];
}
if (commandsAll[i].getId().equals("Facebook_text")) {
commands[1] = commandsAll[i];
}
}

…and we are done. We have our SendCommand objects and we are free to call their run() method anywhere in our app. Be it a Button click or a Menu selection, knock yourself out!

Giddy-up! We just launched new microsites to better serve the BlackBerry® developer community and have given BlackBerry Jam Zone a facelift to make it easy to navigate to the tools you want.

We wanted to re-build the main page to bring you the answers you’re looking for:

• How do I make money?
• What are the development platform options and which one is right for me?
• How do I participate in the community and collaborate with others?

Now new sites have been introduced for Adobe® AIR® and BlackBerry Java. Oh, and a BlackBerry Theme Studio website is on the way as well, so stay tuned…

Starting back at DevCon Americas we launched Native C/C++, Android Runtime and HTML5/WebWorks microsites designed to bring a targeted experience for these development audiences. These were just the beginning steps in updating our online tools to help you build for BlackBerry and PlayBook.

We built these microsites to:

• Bring all of the documentation, samples, tutorials, downloads and API references into one convenient, integrated location
• Ensure that the information is presented and organized in a way that makes sense for the community who is using the technology
• Keep it simple! We’ve been working with the design groups from TAT to create a streamlined design to get you the information you’re looking for FAST!

These microsites will continually evolve based on your feedback, what’s important to you, and how you approach developing apps. You’ll see lots of improvements to all of our websites as we continue to focus on getting you the information you want, the way you want it. So, don’t be shy. Let us know what you would like to see.