On June 6^th, more than 500 developers across China attended the long-awaited Qt China Developer Day 2013 in Beijing. It’s extremely exciting to see how familiar Qt developers are with BlackBerry 10 platform. As soon as registration started, the BlackBerry booth was flooded with developers!

Mike Zhou from our Developer Relations team presented on overview of the recent developments in Qt on BlackBerry 10 and discussed future plans. Coming all the way from Europe, our very own Qt Expert Vladimir Minenko also joined Mike on stage to co-present the technical session on “Developing with Qt for BlackBerry 10”.  The room was packed to the brim with eager developers wanting to learn how to build a BlackBerry 10 Cascades app using Qt.

Vlad and Mike showcased really cool Qt apps on BlackBerry 10 smartphones developed with Qt 5.0. Not only that, they showed the developers how easy it was by porting apps live on stage! Think converting from Qt to a BlackBerry 10 native app would be hard? Not at all when you joined the onsite coding demo session on how to easily convert their existing Qt app to Cascades based applications.  Developers were very excited about BlackBerry 10 supporting the Qt framework and how easy the porting process is.

When Mike and Vlad announced “Bring your Qt app source code to BlackBerry booth to win a BlackBerry smartphone” challenge, the developers went wild! So they came forward, and so easily, they ported into BlackBerry 10.

Jonah Lin, BlackBerry Elite from China joined BlackBerry experts on stage to showcase 2 of his apps developed on Qt, and also shared his experience on commercialization and internalization.

Up to this release, the BlackBerry 10 SDK was supported using a pre-release version of the Titanium SDK which added a both few extra steps and downloads in order to start testing/building your application for BlackBerry. Now the BlackBerry 10 SDK is officially supported in the public version of the Titanium SDK 3.1.1 and can be installed just like any of the other supported platform SDKs.

For those of you familiar with Appcelerator and the Titanium platform, this release brings the BlackBerry 10 SDK to about 90% coverage of the core Titanium APIs, including supporting the Alloy framework. This is a great time to start taking your existing applications and testing to see how great they look, feel and run on the BlackBerry 10 platform. The way Titanium builds for BlackBerry is using the Cascades framework, meaning you will receive native, intuitive applications with solid and fluent user experience out of the box. With just a few keystrokes you can have your existing application compiled and tested on a BlackBerry 10 device or simulator, then just a few more steps to get it signed and uploaded to BlackBerry World.

On the other hand, if you have heard of Appcelerator but are not really sure what they offer, allow me to break it down very simply: Appcelerator’s Titanium IDE allows you to create full featured cross-platform applications using JavaScript. Titanium also recently added support for a new UI framework dubbed “Alloy” which allows developers to define all application UI using a mixture of XML and CSS. “JavaScript” and “XML” may make Titanium sound like it creates web applications, however the applications are actually bundled with a JavaScript engine that interprets the code and displays it in the native UI of the platform for which the application was compiled. The result is an application that can be created very quickly to support multiple platforms (ex BlackBerry 10, iOS, Android) but with the performance, look and feel of a native application.

Existing Titanium developers can get the 3.1.1 SDK update which includes the BlackBerry 10 SDK using the Titanium SDK’s built-in update mechanism. Anyone that needs to download the full IDE can grab it from here.

For more details on all that 3.1.1 has to offer please check out this Appcelerator blog post.

The updates to the run-times have been ones that have had a lot of anticipation. Adobe AIR 3.5 brings with it Stage3D for accelerated OpenGL graphics and the Android run-time upgrade brings it up to Android 4.2 (Jelly Bean) compatibility. As with any beta, this is a work in progress as we work our way towards the gold release of the BlackBerry 10.2 SDK. Known issues will be outlined in the release notes for each run-time.

There are also BlackBerry 10.2 SDK OS updates for BlackBerry 10 Dev Alpha B and C testing devices as well as the BlackBerry 10.2 SDK OS updates available for those who have BlackBerry Z10 and BlackBerry Q10 smartphones. All updates can be performed via the autoloader tool. Again, this is an SDK OS beta that is a trimmed down version of the BlackBerry 10.2 Operating System and is meant to provide a testing environment for you to try out the new SDK and experiment with the added capabilities that have been released. We have also released BlackBerry 10.2 SDK OS updates for the simulator. For this first release, Android 4.2 Jelly Bean testing is not yet supported in the simulator.

If you run into any issues or find bugs, please be sure to report them in the forums and the Developer Issue Tracker to make sure that we have them logged and ensure they are fixed for the BlackBerry 10.2 Gold SDK.We value your feedback as we continue to build the best mobile platform for our users.

There’s a bunch of new functionality that’s available in the beta and I encourage you to check out the roadmap pages and release notes for your favorite run-time to find out what all has been made available in this release. We have a lot more functionality scheduled to arrive in the BlackBerry 10.2 Gold SDK release as well, so I encourage you to check back often with the roadmap pages to find out more on timing and details.

So with all that said… grab the latest SDKs and development OS and have some fun coding!

There are several different options available to Cascades developers who want to integrate their app with Facebook.  The Share Framework allows users to post pictures and status updates  to Facebook directly from any application.  Developers can invoke the native BlackBerry 10 Facebook application from their app in order to show a Facebook profile page.  Or developers can use OAuth to interact with the Facebook Graph API to display Facebook data right in their application.

The development team at QuickBlox has provided an easy way for developers to connect their app to the Facebook Graph API.  The QuickBlox Facebook Connect framework is built upon the public OAuth library contributed by Kyle Fowler.  Dozens of Facebook Graph calls are provided, and the framework can be easily extended to add more.  The QuickBlox framework helps developers load a user’s profile and newsfeed, integrate with Facebook Places, create a post, and much more!  Check out the QuickBlox Facebook Connect framework on GitHub, and the Liverpool Connect app for BB10 which implements it.

Do you have an application built using BlackBerry Java that makes use of the Payment Service APIs? You’ll be happy to know that Cascades support the exact same digital goods types meaning you can provide the same monetization model in BlackBerry 10; you can even use the same digital goods already in your vendor portal. This means less time planning how to monetize your app and less time creating and managing digital goods giving you more time and freedom to develop the rest of the app or letting you finish a few days earlier.

BlackBerry World Client

In BlackBerry OS 7 and lower the Payment Service was included as a separate library which was heavily dependent on the version of BlackBerry World that was installed on the device. This meant that your application would need to query what version of BlackBerry World was installed and, if not at the version required by the library, prompt the user to upgrade the client to a newer version.

In BlackBerry 10 the Payment Service libraries are integrated directly into the OS and the tight coupling with the BlackBerry World client has been removed; meaning you only need to worry about developing.

Vendor Portal

As mentioned above the same digital goods used for BlackBerry OS 7 app releases can be used against any device/OS including BlackBerry 10. To make use of the existing digital goods you simply need to create a new BlackBerry 10 release that references the SKUs of the existing goods. If you are creating a new app altogether then you only need to create the digital goods in the same manner done for your Java apps:

http://docs.blackberry.com/en/developers/deliverables/47831/1278466.jsp

If your BlackBerry Java application has a good user base then I would recommend the above approach, it will allow existing users to download your new BlackBerry 10 version as soon as they upgrade, being visible right in the “My World” section of their BlackBerry World client app when they start up their new BlackBerry 10 device. You will, however, want to upload separate metadata for each platform you are targeting (screenshots, descriptions, keywords etc):

http://devblog.blackberry.com/2012/11/blackberry-app-world-success/

Environment Setup:

Both BlackBerry OS 7 and 10 require an additional library to be added to the project, the difference is that in BlackBerry 7 you need to download and add the library (JAR) to your project, whereas in BlackBerry 10 you only need to reference the library that is integrated with the SDK and OS meaning less work for you and a library that stays updated as you change SDK versions.

Java:

Add the JAR to your project

http://docs.blackberry.com/en/developers/deliverables/40131/Add_Payment_Service_library_to_build_path_1316204_11.jsp

Cascades:

Add the LIB reference to your .PRO file

https://developer.blackberry.com/cascades/documentation/device_platform/paymentservice/selling.html#pat1339516868668

Initializing the Payment Engine/Manager:

The “brains” of the payment service, where all calls are initiated, stems from one object which needs to be instantiated before any further calls can be made. Below are code snippets that show how this instantiation occurs in BlackBerry OS 7 in Java followed by BlackBerry OS 10 using Cascades APIs:

Java:

A prerequisite to using the payment service is to verify that the version of BlackBerry World client on the device is at a sufficient level and, if not, prompting for the update to be installed prior to making any payment calls.

try {
 PaymentEngine.isAppWorldInstalledAndAtCorrectVersion();
} catch (AppWorldUpdateRequired e) {
 PaymentEngine.upDateAppWorld();
 System.exit(0);
}
PaymentEngine engine = PaymentEngine.getInstance();

Cascades:

The payment service in Cascades requires information on which window group the app is using so the payment prompts can be properly drawn overtop.

bb::platform::PaymentManager *m_paymentManager = new PaymentManager();
 bb::cascades::Application::instance()->mainWindow()->groupId();
m_paymentManager->setWindowGroupId(windowGroupId);

The PaymentManager lets you define properties that will be displayed to the user in all purchase requests, specifically the application name and the URL of a custom icon if desired.

m_paymentManager->setApplicationName("The Awesome Store");
m_paymentManager->setApplicationIconUrl(QUrl("http:///mycompany.com/100x100.png"));

Test Mode:

Not available in BBOS

Cascades:

PaymentManager::setConnectionMode(PaymentConnectionMode::Test);

Initiating a Purchase

Java:

PurchaseArgumentsBuilder arguments = new PurchaseArgumentsBuilder()
     .withDigitalGoodId( "1234" )
     .withDigitalGoodName( "My Product" )
     .withDigitalGoodSku( "Ab34t2eC" )
     .withPurchasingAppIcon( bitmapIconImageVariable ); 
     .withPurchasingAppName( "My Application" ); 
     .withMetadada( "Extra info for consumable goods" );
 try 
 {
     PurchaseResult result = engine.purchase(arguments.build());
 }
 …

Cascades:

const PurchaseReply *reply = m_paymentManager->requestPurchase("1234", "Ab34t2eC", "My Product", "Extra info for consumable goods");
connect(reply, SIGNAL(finished()), SLOT(handlePurchase()));

Restoring Past Purchases

Java:

try
 {
     ExistingPurchasesResult result = engine.getExistingPurchases(false/true);
     Purchase[] resultPurchases = result.getPurchases();
 }
 catch (PaymentException e)
 { 
 }

Cascades:

const ExistingPurchasesReply *reply = paymentManager->requestExistingPurchases(false/true);
connect(reply, SIGNAL(finished()), SLOT(handleExistingPurchases()));

If you happen to be new to C++ and would still like to monetize your Cascades application then you will be happy to know that our Payment Services developers have created a nice sample which takes the bulk of the payment calls needed and exposes then through to QML, allowing you to make payment calls without writing a single line of C++ yourself, just copy the important parts from the sample into your own application. This sample can be gitted from here:

https://github.com/blackberry/Cascades-Samples/tree/master/paymentservice

Of course there are a few more calls available through the Payment Service in both Java and Cascades, but the above set provides a solid baseline for the main functions developers using the Payment Service should be aware of. If there is anything else you would like to know about the Payment Service, or have trouble porting the pieces from Java to Cascades, there are a few great options for support:

1)      Support forums: http://supportforums.blackberry.com/t5/Payment-Service/bd-p/pay_serv

2)      BlackBerry Developer Twitter account: @BlackBerryDev

3)      Garett B (Developer Relations Payment Service Expert): @garettBeuk

Happy porting!

http://blackberry.webtrends.com

This provides a great option for devs that need analytics for only BlackBerry applications (the dashboard was sandboxed to display only BlackBerry provided data) however with the mobile ecosystem bursting at the seams we want to ensure that when moving forward to BlackBerry 10 developers have as much flexibility as possible. “Flexibility” meaning choice of analytics providers as well as the ability to use one dashboard to display data from across multiple platforms; knowing that many BlackBerry 10 developers may also be developing for other platforms in tandem and may have strong preference to a specific provider makes flexibility all the more important. This shift in end goals of an Analytics service for developers also shifts the approach when presenting a solution to the community. The approach that was decided on fits in with the general model of BlackBerry 10 openness: rather than create an Analytics service specific to BlackBerry 10 we will focus on partnering with existing Analytics services to help them add support for BlackBerry 10 to their offerings.

The partnering approach offers tons of key benefits: Developers can continue using the analytics provider they choose. Any updates made to the SDK at the service level will be immediately available to all users. Analytics from multiple platforms can be visible under a single dashboard. Familiar API calls. There are many more benefits as well, and all while still keeping the application integration as smooth and easy as possible. At BlackBerry Jam I actually added Flurry Analytics to a Cascades application in well under 2 minutes.

As you can read from the above synopsis, moving from BlackBerry 7 to BlackBerry 10 there has been an entire shift in how Analytics will be provided. At present there are already options for Cascades, Native and WebWorks/HTML5 developers:

100% free industry leading service. Support for C/Native and Cascades application from one SDK.

Fully open sourced client and server offerings as well as a hosted solution. Support for Cascades and WebWorks/HTML5.

Localytics is the most recent service to join the list; now officially supporting for WebWorks/HTML5 and Cascades applications on BlackBerry 10. This service provides near real-time Analytics data.

And we are making it as easy as possible for Analytics providers to bring over their services for BlackBerry 10 by creating a porting guide for both Native and HTML5 solutions. The guide is set to cover all the common information typical analytics frameworks would need to know such as determine the Time Zone, unique identifiers and lifecycle of the BlackBerry 10 devices. This porting guide should be published in the near future will be available from the Analytics Services page:

https://developer.blackberry.com/develop/platform_services/platform_analytics.html

Just prior to BlackBerry Jam Americas, I was speaking with Adam Stanley about analytics services for our BlackBerry 10 HTML5 developers. Adam had been looking into Localytics and found that they have an analytics service written entirely in HTML5; BlackBerry has an entire development approach based on HTML5, so he decided to try his hand at plugging it in to a WebWorks application on his BlackBerry Z10. Without much delay he found that almost the entire service worked as-is out of the box (web standards are a thing of beauty!).

After the above discovery Adam quickly fired off an email to the Localytics folks to see about getting some official documentation posted for BlackBerry 10. Normally using this approach, without having an “in”, it takes time; with Localytics we were put in touch with their VP of Strategy and Business Development, Brian Suthoff, right away, and were on a call with him within a few days. Localytics was excited to know just how easy it was to use their service with BlackBerry 10.SDK Dev Lead Randy Dailey jumped right to working on SDK tweaks to further support BlackBerry 10 and official documentation.

Today, just a couple of weeks from our first engagement with Localytics, I am happy to say that Localytics is now officially supported on BlackBerry 10. All you WebWorks developers can go ahead and add a few simple lines of JavaScript to your existing applications and start tracking usage of your application. But wait, there’s more! If you use Cascades and want to use Localytics then you’ll be happy to know that there is also a QML interface for the service making it available to you as well! Check the Localytics blog for the official announcement:
http://www.localytics.com/blog/2013/localytics-releases-blackberry-10-sdk/

I have already created my first Cascades application using Localytics; the entire process was a breeze. From account creation, to getting the files and docs needed to start, to the point where I had analytics actually displaying in my dashboard was all of about 30 minutes.

The service plans begin completely free for developers and indie publishers and scale up from there depending on your needs.

Ready to get started? If you’ve read this far then of course you are! Chad Tetreault has gone ahead and written the first WebWorks sample application with Localytics implemented, you can get it right now: https://github.com/blackberry/BB10-WebWorks-Samples/tree/master/Localytics

For more info check out the main Localytics site and the following resources for more information:

• http://www.localytics.com
• http://www.localytics.com/docs/blackberry-10-integration/
• http://developer.blackberry.com/html5/
• http://developer.blackberry.com/cascades/

1. Register to receive push messages with the device
2. Register with the BlackBerry Push Service in the cloud to allow push messages for the app to begin being delivered
3. Register with your server side app so it knows there’s a new subscriber
4. Be ready to receive push messages at any time
5. Process pushes in a quick and efficient manner

The server-side portion of consumer push is identical between all BlackBerry smartphone versions, meaning you can use your current server-side app and push service credentials.

By włodi from London, UK (The Big Red Button Uploaded by Yarl) [CC-BY-SA-2.0 (http://creativecommons.org/licenses/by-sa/2.0)%5D, via Wikimedia Commons

BlackBerry 7

In BlackBerry 7 Java, there were two main ways to set up your application to receive push messages – open a port and begin listening indefinitely or register your port and application details with the device. The former basically required that your application begin a background process when the app was first installed, as well as every time the device started up. When the push arrived on the port opened by the app, the data could then be processed however required by the app, followed by the app once again listening on the open port for the next message. This method also required the app to perform “manual” registration, an HTTP POST, with the BlackBerry Push Service to allow devices to begin receiving push messages for your app.

https://github.com/blackberry/JDE-Samples/tree/master/com/rim/samples/device/httppushdemo (this sample shows Enterprise Push which is similar to the pre-5.0 Push API method through BIS)

The latter approach was introduced in BlackBerry 5 where new APIs were introduced that removed the need to keep an app thread running at all times. Instead, the app would register itself with the device by passing it the assigned port and push app ID, allowing the device to listen for push messages on behalf of the app and launch to pass the push message to be processed. This method provided a simple way to allow the app to perform the registration with the BlackBerry Push Service.

http://www.blackberry.com/developers/docs/7.0.0api/net/rim/blackberry/api/push/package-frame.html

BlackBerry 10

The approach used in BlackBerry 10 is most similar to the last approach mentioned for BlackBerry 7 and is arguably the simplest way to handle push messages yet. One simplification is that developers no longer need to worry about application ports, as the on-device service will now handle port selection directly with the BlackBerry Push Service. Another is that rather than needing to deal with reading network streams to receive the push payload, it is not delivered directly to the app fully available in the data portion of an invocation.

Application flow

The first thing your app will need is an entry in the bar-descriptor.xml file that registers the app to receive invocations from the device push notification service. Below is an example entry. The only thing you need to change is the invoke-target id value to a string unique to your app:

              <invoke-target id="com.unique.string.for.your.app">	
      <type>APPLICATION</type>
      <filter>
         <action>bb.action.PUSH</action>
         <mime-type>application/vnd.push</mime-type>
      </filter>
    </invoke-target>

The second thing to add to the bar-descriptor is the permission for consumer push (this can also be added through the GUI editor in the IDE):

<permission system=”true”>_sys_use_consumer_push</permission>

After the above entries exist, we are ready to start programming. Using the various Push APIs, the following flow needs to occur in the device app:

Create a Session

Frequency: Every time your app launches

This is where your app registers itself to receive push messages. Once your app passes the on-device service, it’s provided a push app ID as well as the invoke-target ID you specified in the bar-descriptor file. This basically tells the service, “If a push comes in with this push app ID, invoke my app using this invoke-target ID”.

PushService* m_pushService; //Member variable creation in header file

//In this case BLACKBERRY_INVOKE_TARGET_ID would be “com.unique.string.for.your.app” from above

m_pushService = new PushService(BLACKBERRY_PUSH_APPLICATION_ID, BLACKBERRY_INVOKE_TARGET_ID);
m_pushService->createSession();

Create a Channel

Frequency: Once for the lifetime of the app

After the session has been established on the device, the app then needs to register itself with the BlackBerry Push Service. This operation is referred to as “creating a channel”. The creation of a channel tells the BlackBerry Push Service, “If a push message arrives with this app ID and is addressed to my device, please let it through”. Without this step, pushes will never be delivered to the device.

m_pushService->createChannel(QUrl(BLACKBERRY_PUSH_URL));

Another important part of this step is that when the channel is created, it should return a “token” which currently is simply the value of the device PIN. This can be sent to your server once retrieved to let it know that a new device has subscribed.

Register to Launch

Frequency: Once for the lifetime of the app

Following the channel creation, your last step is to call the “register to launch” function. Unlike BlackBerry 7, BlackBerry 10 apps do not run all the time. When a push arrives however, the application can be launched into the tiled state to perform processing on the push it’s not already running. In order to be launched when a push arrives, the app must call the “register to launch” function. Otherwise if this function is not called and the application is closed, the push data will be lost.

m_pushService->registerToLaunch();

Once the above steps are completed, your app is ready to start receiving push messages. As push uses invocation, you can handle the messages in about the same way you would for a standard invocation of your app:
https://developer.blackberry.com/cascades/documentation/device_platform/
invocation/receiving_invocation.html

The one difference is that you need to use the PushPayload class to retrieve the push payload from the InvokeRequest’s data:
https://developer.blackberry.com/cascades/documentation/device_comm/push/
cs_receiving_a_push_message.html

Ready to get porting your BlackBerry Java push app over to BlackBerry 10? Here’s a great resource that walks through the entire service including lots of code snippets:
https://developer.blackberry.com/cascades/documentation/device_comm/push/index.html

Need a sample to test your current push credentials? Check our GitHub repositories:
https://github.com/blackberry/Cascades-Samples
https://github.com/blackberry/Cascades-Community-Samples

Never used Push before? Check out this overview of the service:
https://developer.blackberry.com/services/push/?CPID=PUSHAPI00

If you still have questions toss a post in the Push Development forums or send me a tweet:
http://supportforums.blackberry.com/t5/BlackBerry-Push-Development/bd-p/Applications_using_Push_Technology

@garettBeuk

That said there are…. apparently…. people in this world who have a bit more resolve than I do and take their sporting and fitness activities a bit more seriously. Not only do they manage to get out of the comfy chair, they even like to measure and analyse their performance so they can improve.

Now my colleague Martin (@mdwrim) has normal furniture in his house and seems more than capable of getting out of the comfy chair and down to the climbing wall or out on his bike. He and I (@jcmrim ) talked about the kind of technology available to sporty people, in particular cyclists. Martin had just come back from watching part of the Giro d’Italia and pointed out that all the pro cyclists have sensors on their bikes. BlackBerry 10, Bluetooth Low Energy and cycling! What a perfect combination of great technology, fun and exercise as well as a great opportunity for a new Blog post, video and sample app!

If you haven’t already done so, this is probably a good time to have a read of our previous blog posts and articles on the Internet of Things and Finding Car Keys since they cover the basic concepts needed in this blog post.

As before, the first thing we did was to do a little bit of research to see if the Bluetooth SIG had defined any standards in this area; no point in re-inventing the wheel [no pun intended] and the existence of a standard would mean that a vendor may have already implemented the technology in a product.

Whenever you have a requirement that may be solvable using Bluetooth LE the first place to look is here: http://developer.bluetooth.org/gatt/Pages/default.aspx.

Browsing through the GATT Profiles we came upon this one: Cycling Speed and Cadence (CSC)… this sounded promising, and the description looked like it was just what we needed.

“The Cycling Speed and Cadence Profile is used to enable a data collection device to obtain data from a Cycling Speed and Cadence Sensor (CSC Sensor) that exposes the Cycling Speed and Cadence Service.”

The key element of this profile is the Cycling Speed and Cadence Service (UUID 0×1816) which contains four really useful fields:

• “Cumulative Wheel Revolutions”
• “Cumulative Crank Revolutions”
• “Last Wheel Event Time”
• “Last Crank Event Time”

These are part of the “CSC Measurement” GATT Characteristic (UUID 0x2A5B). They are described in detail here: CSC Characteristics and outlined in Figure 1.

There are some other characteristics that allow configuration and control of the device but we’ll talk about these when we come across them.

Figure 1 Key GATT Characteristics for CSC

So, if you think about these characteristics they allow you to derive a number of key measurements:

1. Total distance travelled – using “Cumulative Wheel Revolutions” – all you need to know is the wheel circumference to calculate this, but if you combine this with a time and a geo-location measurement you can even derive sufficient information to plot your progress on a map.
2. Speed – using “Last Wheel Event Time” – you can figure out how fast the bike is going if you do a simple calculation involving the time between successive Last Wheel Event Time values and the number of wheel revolutions that occurred in that time. But if you combine this with a geo-location measurement you can derive sufficient information to plot your speed on the map as well.
3. Instantaneous effort – using ““Last Crank Event Time”” – this can help identify those times that you’re free-wheeling and not expending energy.

It’s at this point that the engineer in me begins to wonder how to instrument a bicycle to make use of this GATT profile. Martin’s a cyclist, so, after identifying a device that matched the requirements (Wahoo Fitness Blue SC[1] device), he attached it to his cycle as shown in Figure 2.

Figure 2 Attachment of cycle monitor

For those of you who are mechanically minded small magnets on both the crank and the rear wheel spokes activate the sensor strapped to the frame. The sensor maintains the counts and timings and will report them to a suitable Bluetooth LE device such as a BlackBerry 10 smartphone.

The application that we developed based on this is actually very similar in structure to the Heart Rate Monitor application that was described in a previous blog and article. The basic logic is the same:

1. Pair the Bluetooth LE device with the BlackBerry 10 handset before using the application.
2. Launch the application which:
   1. Discovers devices that support the CSC Service (UUID 0×1816)
   2. Connects to a discovered device selected by the user
   3. Requests the device to notify our application as changes are made to the CSC Measurement characteristic (UUID 0x2A5B) which contains the wheel and crank data that we’re interested in.
   4. Receive, parse and display in numerical (RPM) and historical graphical form the CSC Measurement data as they are received.

Here are some screenshots showing what the application looks like:

Figure 3 The CscMonitor Application

Instantaneous values of the wheel and crank readings in revolutions per minute (RPM) are shown in the upper part of the screen whilst historical RPM data are plotted on the lower half of the display. Wheel and crank historical data displays can be toggled by touching the screen. Mapping RPM values to distance or energy expended would require additional information to be provided, such as the wheel circumference or radius of the crank — we’ll leave this for a possible later iteration of the application and focus on the Bluetooth LE aspects for now.

If we inspect the GATT services the CSC device supports using a tool like BTool we can see (Figure 4) that the CSC Measurement Characteristic (UUID 0x2A5B) is exposed at handle 0×0023. Handles are the references to entries in the GATT that our application will discover and use to access the value associated with a characteristic. We’ve used handles before in both our previous examples.

Figure 4 GATT showing CSC Characteristics

Associated with the CSC Measurement Characteristic is a “Client Characteristic Configuration” characteristic (UUID 0×2902) exposed at handle 0×0024. The value of this field determines whether our application will receive Notifications or Indications for the CSC Measurement Characteristic. We’ve used these before as well in our previous examples. In this case this characteristic will be set to enable Notifications using the BlackBerry 10 Bluetooth LE API.

So, how do we manage the data that is notified to us from the CSC device? The CSC data received is managed by a class called “CscDataContainer” … here’s part of its definition:

class CscDataContainer: public QObject {
       Q_OBJECT
private:
       CscDataContainer();
...
       // notification data
       QQueue<csc_notification_t> _csc_notifications;
       // CSC values
       QQueue<csc_values_t> _csc_values;
       int _min_wheel_rpm;
       int _max_wheel_rpm;
       int _avg_wheel_rpm;
       long _total_wheel_rpm;
...
}

At its core are a couple of queues that maintain the data that is received. The queue has a maximum length that can accommodate one notification per second for an 8 hour period. A future version might persist these data in a database but this is sufficient to demonstrate the principle in this case.

Once again the excellent little JavaScript library called “Flot” is used to plot these data in a WebView component in QML.

As notifications are received by our application the addNotification() method of the CscDataContainer class is called with the CSC Measurement data passed as a (uint8_t *) and a length (uint16_t) — that is an array of bytes.

Parsing this data is the first task and it’s instructive to see how this works – the main points are highlighted in the code fragment below:

void CscDataContainer::addNotification(const uint8_t *val, uint16_t len) {
       // parse value, paying attention to the bit settings in the FLAGS field
       bool wheel_revolution_data_present = false; // bit 0 of Flags field
       bool crank_revolution_data_present = false; // bit 1 of Flags field
       uint32_t cumulative_wheel_revolutions = 0;
       uint16_t cumulative_crank_revolutions = 0;
       uint16_t last_wheel_event_time = 0;
       uint16_t last_crank_event_time = 0;
       int index = 0;
       uint8_t flags = val[index];
       wheel_revolution_data_present = ((
flags & WHEEL_REVOLUTION_DATA_PRESENT) == WHEEL_REVOLUTION_DATA_PRESENT);
       crank_revolution_data_present = ((
flags & CRANK_REVOLUTION_DATA_PRESENT) == CRANK_REVOLUTION_DATA_PRESENT);
       // Fields are in the order of LSO to MSO.
       // Where LSO = Least Significant Octet and MSO = Most Significant Octet.
       index++;
       if (wheel_revolution_data_present) {
              // Cumulative Wheel Revolutions, 4 bytes.
             // Field exists if the key of bit 0 of the Flags field is set to 1.
              cumulative_wheel_revolutions =
(val[index + 3] << 24) | (val[index + 2] << 16) |
(val[index + 1] << 8)  |  val[index];
index += 4;
              // Last Wheel Event Time, 2 bytes. 
              // Field exists if the key of bit 0 of the Flags field is set to 1.
              last_wheel_event_time = (val[index + 1] << 8) | val[index];
              index += 2;
...
}
       if (crank_revolution_data_present) {
// Cumulative Crank Revolutions, 2 bytes. 
// Field exists if the key of bit 1 of the Flags field is set to 1.
              cumulative_crank_revolutions =
(val[index + 1] << 8) | val[index];
              index += 2;
              // Last Crank Event Time, 2 bytes. 
              // Field exists if the key of bit 1 of the Flags field is set to 1.
              last_crank_event_time = (val[index + 1] << 8) | val[index];
              index += 2;
    ...
    }
...
}

The first byte of data contains an 8-bit flag field (see Figure 1 for details). This indicates whether crank or wheel data is present in the following data.  If these are present they are represented in Little-endian form and need to be extracted by shifting them out a byte at a time.

The rest of the application is more focussed on the display of this data using QML so I’ll leave that for you to look at yourself since the main learning points are to do with how to interface to the Bluetooth Low Energy device itself.

We made a video which has Martin (@mdwrim) showing the application in action and explaining the code. Here it is:

If you want to know more then check out the following resources:

• The complete source code for this application on Git Hub;
  • https://github.com/blackberry/Cascades-Community-Samples
• If you’re completely new to Bluetooth LE then we recommend you read our “BlackBerry 10 Bluetooth LE Primer for Developers”  which you’ll find in our knowledge base. This and all other Bluetooth LE related developer resources that we’ve created, are listed in a single resource index page:
  • http://supportforums.blackberry.com/t5/Native-Development/BlackBerry-10-Bluetooth-LE-resource-index/ta-p/2326147

I hope you’ve enjoyed this short note and hope it has piqued your interest to find out more about Bluetooth Low Energy and how it can be integrated into your BlackBerry 10 applications.

---

[1] This should not be regarded as an endorsement by BlackBerry, explicit or implied.

http://www.webrtc.org/reference/architecture

I would like take this opportunity and introduce you to our good friends at Hookflash who have successfully ported all major components of both WebRTC and Open Peer libraries to BlackBerry 10. To provide a brief overview, WebRTC is an open source multimedia & network stack that supports real-time audio & video. The value Open Peer delivers to WebRTC applications is peer-to-peer (P2P) signalling on the wire, Instant Messaging, Federated Identities and multiple mobile platform support.

So why is this so important?  Well, it enables developers to build rich, compelling, real-time communication applications integrating Social Identities with Voice, Video and Messaging using BlackBerry 10 Native SDK. Secondly, WebRTC is free to use if you decide to commercialize your application. What Hookflash has achieved on BlackBerry 10 really exemplifies the power of our BlackBerry 10 Native Platform to deliver the best communications experience.

I would like to further highlight Hookflash team’s experience in porting both WebRTC and Open Peer stack’s over to BlackBerry 10 platform. Check out my interview with Erik Lagerway (Co-founder) & Robin Raymond (Chief Architect) from Hookflash below:

What is Hookflash?

Hookflash is a globally distributed software development team building “Open Peer”, new “open” video, voice and messaging specification and software for mobile platforms and web browsers.  Open Peer enables an important new evolution of communications; Open, for developers and customers to create with. “Over-the-top” on the Internet, where users control their economics and quality of service. “Federated Identity” so user’s connections aren’t limited by service provider’s walled gardens and operating systems. “Integrated”, as communications become a native function in software and applications. Hookflash founders, lead developers and Advisors accomplishments include; creators of the world’s most popular softphones, built audio technology acquired and used by Skype, built GIPS technology acquired and open sourced by Google to create WebRTC, and engaged in WebRTC standards development in the IETF and W3C.

What is Open Peer SDK and how would this empower BlackBerry 10 developers?

Open Peer enables direct integration of social identities, video, voice and messaging communications for developers building native BlackBerry 10 (NDK) applications. Voice, video and messaging flow Over The Top (OTT) via the Internet.

These services are delivered peer-to-peer (P2P) providing extremely strong privacy, security and encryption. Open Peer enables federated identities and allows developers to leverage and integrate whatever identity model they currently have, so their users remain their users!

What features does Open Peer SDK support?

The Open Peer SDKs are built according to the Open Peer specification. Here are a few of the features we have built into the current SDKs…

• HD real-time video
• Wideband voice and messaging
• Peer-to peer signalling & media transport (greater efficiency, reliability & privacy)
• Federated identity for cross-platform communications (not to be confused with Single Sign-On)
• Encrypted & secure communications

Would HTML5/WebWorks developers be able to leverage this in BlackBerry 10?

Yes. The current SDK is for BB10 NDK developers at this time. However, we have an active “opjs” project under development that will allow interaction between a native BB10 application and an HTML5/WebRTC enabled browser thus allowing web applications to communicate directly with native BB10 applications.

Share your experience in cross compiling your code for BlackBerry 10

Like all platforms, there’s is a learning curve relative to what you are used to until you find yourself comfortable in a new environment, and BB10/QNX is no different. The richness to the platform experience is impressive on the BB10 and made iOS feel somewhat dated by comparison.

Since QNX is a POSIX compliant system, it was relatively easy to get a majority of open source code ported to BlackBerry 10. The QNX GCC-compliant mode has helped us as well.

There were a few wrinkles along the way. The documentation and NDK felt young compared to other more established platforms but that kind of level of documentation grows out of community support and interaction.

One major difference between this project and other platforms has been the phenomenal support that Blackberry has provided us as developers, especially as Hookflash is pushing the platform and technology harder than most with real time communications in audio and video. This was refreshing, We’ve never seen such incredible support for their developer community.

Have you ported over the entire webRTC engine to BlackBerry?

Yes, we have ported all major components of webRTC library to BlackBerry. We will be extending what is offered by WebRTC’s library as well.

How long did it take to port the WebRTC and Open Peer code to Blackberry 10?

When you consider the size of the code-base that had to be moved, and the fact we had not worked on QNX /  Blackberry 10 before, it went relatively quickly. The entire move took us approximately 90 days.

Are you going to commit this work back upstream to WebRTC project?

Yes, our code will migrate back to the WebRTC project. Hookflash is extremely busy on a number of fronts making Open Peer widely available with limited resources.  We appreciate help from other developers. Pushing the WebRTC codebase back upstream will be of tremendous value to the Blackberry developer community. Requests to join our Open Peer BB10 github project are always appreciated.

What APIs did you use to build your application on BlackBerry 10?

NDK’s audio, camera and rendering subsystems and Boost are the bulk of the components. We use Cascades/QT for the sample application.

Do you have VP8 Video working on BlackBerry 10?

Yes. We had some difficulty getting the assembly to compile properly but with Blackberry’s support we were successful in porting an optimized version of VP8 to the BB10 platform. Keep in mind we have tested this mostly on Z devices at this time with limited testing done on the Q devices.

How was your experience relative to working with other platforms and BlackBerry 10?

As mentioned earlier, Blackberry feels a bit new in the documentation area and there are still a few bugs to take care of in the platform. Having said that, the platform is forward thinking, flexible and impressively powerful. Blackberry’s support has been beyond anything we could have hoped and even expected.

As more developers are drawn to the platform, documentation and community involvement will improve the access to information on the platform and increase the samples available to draw upon.

For such a new entrant into the market, our team is thoroughly impressed.

How was your experience working with the RIM team?

Bar-none, the best support we’ve ever had from a major platform vendor directly into the project. Kudos to RIM / Blackberry for providing such a spectacular community outreach.

When is Open Peer SDK going to be available for BlackBerry 10?

Our SDK is ready now in beta, developers can get it on Github today. We continue to polish this and our other toolkits, we expect commercialization to begin later this year. Follow us on github and twitter to get the latest news on Hookflash and Open Peer development.

I hope you found this interview informative and useful.  If you have any questions or feedback please leave a comment below or reach out to me directly on Twitter _GurtejSandhu. Kudos to Hookflash team for making this all happen.