Previously, I talked about how to use the MapView APIs to embed your own layers on top of it. While that was nice and very flexible, it still required some work to get basic pins and bubbles going. In BlackBerry 10.1 we have updated the APIs to support push pins and bubbles out of the box. This means you can now use the native APIs such as GeoLocation and MapData to create and manage push pins with custom icons as well as assign a name and description to each that shows up in the bubble.

MapView with pins and bubbles

The bubbles can contain a title, a description as well as an action button. Signals are emitted when the text or the action button is tapped by the user so that applications can carry out the right action in that context. Typical actions would be to show more details about the location or starting a turn-by-turn navigation to that location. Oh and before I forget, did I mention that the title and description supports html tags? Yes it does. You can use html tags to format the text or even insert hyperlinks to open webpages.

A bubble with an HTML hyperlink

I guess I have been saving the best for last. One feature that I am really excited about is the ability to set the MapView to follow a specific pin. This is extremely useful if you want to track friends on a map or keep the user always centered on the map. Simply update the coordinates of the followed pin and watch the map automatically move with it. A full sample app can be downloaded from here.

Finally, a big shout-out to our maps team for their hard work – the MapView now has much better performance, faster tile loading and packs the features most of us need. Let’s get to work and put some more maps in our apps. If you missed the session at BlackBerry Jam Americas 2013, please check out the content on-demand – JAM69 - Maps in your Apps.

Just wanted to quickly remind everyone that we are going to have great contents on how to achieve deep system integration via invocation framework including the rise of the headless apps. If you are attending BlackBerry Jam Americas 2013, please check out the following sessions. Otherwise, please change your mind and attend. J

JAM06 – Built for BlackBerry: System Integration with Invocation Framework

• Larry McDonough – Principal Evangelist, BlackBerry
• Shadid Haque – Sr. Application Development Consultant, BlackBerry

To qualify for Built for BlackBerry®, your application must integrate with a BlackBerry® 10 service. One of the innovation features of BlackBerry 10 is the invocation framework. Through the invocation framework your application or game can request another application to perform a specific task. Also, your application can register as a target in the invocation framework to provide your specific function to other applications. Join us to see why and how you can effortlessly integrate with this framework.

JAM47 – Background Services – Event Driven Processing for your Application

• Russell Andrade – Product Manager, Native SDK, BlackBerry
• Shadid Haque – Sr. Application Development Consultant, BlackBerry

The session will discuss the brand new Background Services framework which allows developers to bundle a separate process with their application to run in the background without a UI.  Learn the basics of how this framework works, learn some guidelines about when to use it and when not to, and learn about the experiences of existing app partners that successfully deployed a background service and lessons learned from their projects.

JAM56 – CaseStudy: InvocationFramework – The heart of your business apps

• Ekke Gentz – Independent Software Architect, ekkes-corner UG
• Shadid Haque – Sr. Application Development Consultant, BlackBerry

Invocation Framework is the driving force behind BlackBerry Flow. Experience first-hand how Ekke’s OpenDataSpace, Conference2Go and SerCar10 app leverages Invocation and Flow for media playback, recording, sharing app and content with social networks such as BBM and foursquare, turn by turn navigation with BlackBerry Maps, in app System Settings, adding event reminders and much more. Ekke also provides his own targets so others can invoke his apps.

MapView provides out of the box elegance with beautiful map tiles and all the basic interactions such as pinch-to-zoom and drag-n-pan. You can also drop push pins for POIs and show bubbles to present more details about a POI. Better yet, both the pin and the bubble can be fully customized to represent your own branding. Although these cover the basic needs for most of us, anything with Cascades has to be a bit more special, right? So where is the moment of charm in MapView? You just have to continue reading (or watch the video above).

I know 2D maps are nice and they do their job, but they are also yesterday’s news. The MapView takes that to the next level with APIs for tilting and rotating the map in a 3D space. Hook those two up with the gyroscope and the compass and you’ve got augmented reality in your app with zero effort. In fact, that’s exactly what I did in the CustomMapView sample app. The sample demonstrates the full power of MapView as of today and will be kept up to date as we add more features to our SDK. Please feel free to fork this in GitHub and contribute back!

I am really happy for how the MapView is coming together in Cascades, and more importantly the potential it has among developers. Please let me (@shadidhaque) know what you plan to do with it and what we can do for you.

Developing for BlackBerry® has never been faster or easier.  We have been working hard to give you the same experience when incorporating sensors into your game or application.  With the release of Beta 3, we have added complete support for sensors in Cascades™, leveraging the power of Qt Sensors from Qt Mobility.  QML gives you the unparalleled flexibility and simplicity of adding a sensor to your app in as little as 4 lines of code!

   Compass {
      active: true
      onReadingChanged: {
          console.log("Azimuth" + reading.azimuth);
      }
   }

Of course we still also support the C++ Qt Sensor API for those hardcore developers out there.  For more information on including and using sensors in your project check out the newly updated documentation here.

The device movement alarm is a great example on leveraging some of RIM®’s exclusive API extensions.  Use them to differentiate your app.  Look for the following APIs:

• axesOrientationMode
• accelerationMode
• alwaysOn
• skipDuplicates

By now you are probably screaming “Show me the code!”.  We have you covered and have created several examples that we want you to copy, paste, and mash up into your applications.  Show us what you can do!

• Sensor Examples: https://github.com/blackberry/Cascades-Samples
• User documentation: http://blackberry.github.com/Cascades-Samples

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.

About a month ago, I took the plunge and started a Cascades™ project for BlackBerry® 10.

Initially I was in a state of shock. This is an entirely different world compared to legacy BlackBerry Java® development – including the language (C++), the framework (Qt/Cascades), and a declarative language to build the UI (QML). Slowly and surely things started coming together. Fortunately, I had done a lot of C++ programming in my distant past, and somewhere in the back of my brain most of that old knowledge was still there. Nonetheless, I found myself staring at compiler error messages in bewilderment when I attempted to make a static function member call using dot syntax (Java) instead of using :: (C++).

After a couple of days the state of shock wore off and I found myself getting excited about this new way of writing BlackBerry applications. So what’s so great?

RIM® has been spotlighting Cascades with its cool controls and animation as a great framework for a new generation of apps. This is all true, but to me, what really makes the difference is the Qt foundation on which Cascades is built. It is Qt that enables rapid and solid development with a clean separation of the UI from the code behind.

In an attempt to summarize what I like about Qt, here’s a short list of the things that have made me smile so far. No doubt as I progress, the list will grow.

QML

Defining a UI via markup is more intuitive than defining it via code. The markup clearly expresses the hierarchical structure of the UI. Such a hierarchy is almost impossible to see when looking at the equivalent in code. Furthermore, the structure can be expressed with minimal lines of markup in contrast to hundreds of lines of code without any loss of functionality. Needless to say, tweaking the UI and finding and fixing bugs via markup are all a breeze. QML also supports components. This means that I can define QML fragments in separate files and refer to these components from other QML files. I have already found myself defining re-usable pieces of QML. Of course, QML isn’t the only markup language in use today for writing non-HTML applications (e.g., XAML), so it’s great to see this “tried and proven” concept come to the world of BlackBerry development.

Code Behind

QML wouldn’t be very useful if it didn’t connect well with C++ code. Qt’s support for named properties and invocable methods in C++ makes it really easy to put code behind the UI. The UI can easily be configured to read values from a C++ object exposed via “properties”. In fact, when configured as such, a control’s property is “bound” to an object’s property. This means that as the value of the object’s property changes, the UI automatically updates to reflect these changes. C++ objects can also expose “methods” which can be invoked directly from QML.

Qt Threading

Qt expands on the basic notion of a thread by providing a built-in event loop for any thread. Qt allows an object to be “associated” with a thread. Via dynamic method invocation, a method can be invoked on an object associated with another thread. When such invoked, Qt transparently wraps the method invocation in an event and places it in the appropriate thread’s event queue. As such, the method will be ultimately invoked on the object’s thread. I found this to be extremely helpful when dealing with a particular object type, containing long-running methods. If used correctly, one can use this technique to gain the benefits of multi-threading without the dangers of concurrency.

Signals and Slots

Qt uses a mechanism known as signals and slots to allow objects to “listen” to events triggered by other objects. I have found this mechanism to be much more flexible than the Java listener paradigm (i.e., implementing interfaces). Any object can be eligible to listen to “signals” of any other object, simply by implementing a method “slot” with the correct signature. Needless to say, should the receiving object be associated with a different thread, the invocation of the “slot” will be invoked on the object’s thread.

Maturity and Community Support

Qt is not new. That’s good! It’s good because it means that it is stable and mature. It means that it contains hundreds of classes providing everything from a basic string wrapper (QString) to XML processing (QDomDocument). It is also very well documented. Both officially on the Qt site and unofficially by the zillions of posts on various forums.

In short, I’m enjoying the ride. Qt is a great foundation for writing apps. Coupled with Cascades, I can definitely say that we have a strong framework for building the next generation of BlackBerry apps.

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!

LBS nation, we have good news! The Wi-Fi® geolocation service officially launched on September 9th, 2011. This in-house technology at Research In Motion® (RIM®) uses Wi-Fi Access Point data that’s been collected anonymously by your BlackBerry® smartphone to provide a quick and accurate location fix to location-aware applications globally. This service is a further enhancement to our Cell-site geolocation service, which has been in service globally for more than a year.

Unlike GPS-based location fixes, this service offers a faster and more convenient way for developers to get location fixes via a secure connection with minimum bandwidth usage. Although the accuracy of this service is lower than GPS, it’s higher than Cell-site geolocation, and the speed is expected to be much faster than GPS. One advantage to Wi-Fi geolocation service is that it typically works even when GPS is not available. For example, when a user is indoors or when a user prefers not to turn their GPS on in order to preserve battery life, Wi-Fi geolocation service is still an option.

The APIs needed to acquire Wi-Fi geolocation fixes have been available since the BlackBerry® 6 OS release; therefore, all devices running the BlackBerry 6 OS and higher are able to leverage this service via existing APIs upon provisioning of this service. Please note that service provisioning may take up to a month from the launch date, so we’re asking for your patience and understanding if it doesn’t start working immediately. For APIs and other relevant technical details, please refer to the KB article Location APIs – Start to finish. You can also leverage Simple Location API if you want to get a head-start by skipping the full details.

I am really excited about this service as it opens up a lot of possibilities for innovation and great apps. Let us know when you integrate your app with this service, and let us know how it goes!

I have recently written an abstraction to the Location API that simplifies getting location fixes in different modes, as well as optimizes battery usage. Developers intending to quickly incorporate location technology to their apps can now use the Simple Location API to leverage both GPS and Geolocation-based location services in virtually no time.

Besides pure GPS or Geolocation mode, the Simple Location API comes equipped with an OPTIMAL mode that dynamically chooses between the Research In Motion® (RIM®) Locate Services and on-device GPS, depending on availability. Also, since location-based services can be battery intensive if not handled properly, this API optimizes power consumption by adding increasing breathing intervals between retries when location fixes are not available.

The Simple Location API is designed to include the following features:

• Simplified API with a focus on real world use cases.
• An API that leverages on-device GPS and RIM’s Locate Services.
• Dynamically detects available and supported location modes on the device before trying any of them.
• Has the ability to choose the best location mode based on the modes available on the smartphone.
• Built-in retry mechanism with dynamic delay (to save battery) based on a retry factor set by the API user.
• Performs both single and tracking location fixes.
• Simplified events via SimpleLocationListener interface.
• Capable of starting, stopping and restarting tracking sessions in a reliable thread-safe way.
• Designed to eliminate/reduce misuse of the API

There’s definitely room for improvement to the Simple Location API so, keeping that in mind, the source is fully open and can be downloaded here along with a full demo app. Feel free to integrate this in to your app today, and if you are a passionate BlackBerry® app developer, you know the drill – improve and share!

Hello developers – I have great news! As part of our continuous effort to improve our map client and the data services behind it, we have added some really exciting features to our BlackBerry® Maps offering. Whether your application uses an embedded MapField or simply invokes BlackBerry Maps to render map data, you can start taking advantage of these new features today!

First, the data coverage has been extended by adding 34 new countries, including Australia, Brazil, Argentina, Uruguay, New Zealand, The Philippines and Taiwan. I have no doubt that the addition of these new countries in our database will open up a lot of opportunities for app developers in those regions. The figure above shows the current coverage of the BlackBerry Maps service.

After carefully listening to your comments and feedback, we have also spent a significant amount of our efforts to optimize the visual appearance of the maps with a stronger rendering engine as well as with a new color scheme. New POI databases for hospitals, universities/colleges, police stations, train/subway stations, shopping centers, parking, parks and airports were also added wherever available, in order to make the maps as meaningful as possible to the end user. The screenshots below highlight a few of the many visual changes that went in as part of this update.

Please note that, in order to enable the extended coverage and visual optimization, you will first need to update your device as instructed below:

Updating BlackBerry Maps with BlackBerry® Device Software 4.7 or Lower

1. From the home screen, go to Maps.
2. Press the [Menu] key and select Options.
3. Press the [Menu] key and select Clear Cache.
4. Select Delete when prompted to delete cached entries.

Updating BlackBerry Maps with BlackBerry Device Software 5.0 before Bundle 1057

Update your BlackBerry Device Software to the latest version, available here. If you do not wish to update your software, you can follow the instructions below (for the BlackBerry Device Software 5.0 after Bundle 1057) to receive the additional map coverage and new map design. However, the new POI icons will not be available.

Updating BlackBerry Maps with BlackBerry Device Software 5.0 after Bundle 1057

1. From the home screen, go to Maps.

2. Press the [Menu] key and select Options.

3. Press the [Menu] key and select Clear Cache.

4. Select Delete when prompted to delete cached entries.

Updating BlackBerry Maps with BlackBerry Device Software 6.0

1. From the home screen, go to Maps.

2. Press the [Menu] key and select Options.

3. Press Global Map Options.

4. Press the [Menu] key and select Clear Cache.

While we try our best to support new features on all OS versions, it is important to note that some of these features are not available on legacy OS versions. Please use the table below to determine which features are available for the OS version you have.

I am very excited about these new features and am really looking forward to any comments you may have!