With the release of the BlackBerry® Native SDK Beta 2 comes the Cascades™ Camera API. If you want to see it in action, check out the spiffy Photobomber sample app available in the BlackBerry Jam Zone and on GitHub. You can just import it, compile it, install it on your BlackBerry® 10 Dev Alpha and go.

However, there are a couple of set-up gotchas in the current beta you are going to run into if you are just trying to add Camera functionality to your own app. Luckily, they are pretty simple to get past, especially with me here telling you exactly what to do! Let’s quickly run through them.

1. QML Imports

In your QML file, right underneath the default:

import bb.cascades 1.0

you want to also add:

import bb.cascades.multimedia 1.0

This will let the QML editor know about the camera components so it doesn’t complain at you.

2. Include the Camera headers

This is pretty standard C++ stuff, but don’t forget to also import the headers into your C++ code. In your default app.cpp you will want to import at least this:

#include <bb/cascades/multimedia/Camera>

You may also end up needing a few others if you are doing more involved camera work in C++, like this:

#include <bb/cascades/multimedia/CameraSettings.hpp>

#include <bb/cascades/multimedia/CameraTypes.hpp>

3. Register the Camera in C++

In your default app.cpp file, right before the call to:

	QmlDocument *qml = QmlDocument::create("main.qml");

Add:

	bb::cascades::multimedia::Camera::registerQmlTypes();

If you don’t do this, the Camera components won’t actually get loaded and you’ll get an error. This is also why you imported the Camera header file, if you are doing the rest of the camera work in QML.

4. Link to the Multimedia Libraries

Right now the linker isn’t quite set up properly to connect your app to some of the new libraries added in R6. For now, you’ll want to manually open the <appname>.pro file and add the following line:

LIBS   += -lcamapi -lscreen  -lbbsystem  -lbbcascadesmultimedia –lzxing

Not all of those are strictly necessary (for example, the zxing library will only be helpful if you want to connect to ZXing to do some custom barcode scanning. We’ll talk about how to do that in a future blog post), but it’s not going to hurt, and the names of the libraries are not terribly discoverable on your own.

You’ll note there is no LIBS line by default in your .pro file. I like to add mine below the CONFIG line, though I’m not sure it really matters.

5. Done!

That’s it, you’re all set up! Now you can use the Camera API to your heart’s content. If doing so results in your app taking a lot of pictures, don’t forget you can use the Invoke Framework to let your users easily share them. It’s a snap.

Our first task was to establish whether or not we could read the content of the tags any way at all and if so, to determine just what that content was.

Now, an NFC tag is a smart card and it responds to ISO 7816-4 APDUs, so it’s possible to work with it at a lower level than would be the case when using the BlackBerry NDEFMessageListener Java® interface – which is how we’d normally seek to read an NFC tag from a BlackBerry® smartphone application. As such, armed with the NFC Forum specifications for NDEF tags types 1-4 in one hand, the ISO 7816-4 specs in the other, and a contactless card reader in errrrr…the other, we set to work.

Our investigation proceeded on two fronts: John had been looking at a Python API for smart card developers called “pyscard” for a while and thought we could do something with that. We also contacted our own NFC product development team for advice, and they provided a BlackBerry smartphone app that they use to dump the content of tags to the device screen.

While sitting in the hotel bar drinking coffee and huddled around my laptop, it wasn’t long before John and I had a Python script running which was able to dump and decode the content of the tag. Through trial and error, we determined that we were dealing with a Type 2, tag and the decoded data produced by our script agreed with the data produced by the app our development team had provided. On examining the details carefully, we could see the problem with the tags as plain as day. Here’s part of what our script produced. Can you see the issue?

NDEF data:

TNF : 3 RFC 3986 ABSOLUTE URI
Type Length : 1
MB (Message Begin) : 1
ME (Message End) : 1
CF (Chunk Flag) : 0
SR (Short Record) : 1
IL (ID Length) : 0
Payload Length (SR): 34
Type : U
Payload (hex) : 68 74 74 70 3A 2F 2F 6F 6E 2D 74 61 70 2E 6E 65 74 3F 74 3D 30 69 38
34 76 69 65 71 38 7A 65 73 31 6E

The problem is that there’s a mismatch between the value provided for TNF (Type Name Format) and the data in the Type field.

TNF=0×03 means the tag contains an “absolute URI” as defined in RFC 3986. When this value is specified, then the Type field should contain a valid URI and the payload should be empty. As we can see, however, the Type field contains “U” in this case.

Of the other values which TNF could take, a value of 0×01 means the tag contains an “NFC Well Known Type”. Well known types are pre-defined record types and formats which the NFC Forum devised to support common use cases. When TNF=0×01, the Type field contains a short code which indicates which of those well known types the payload represents. Values include “Sp” for smart poster, “T” for Text and “U” for URI. So as you can see, there are two ways of encoding a URI; either with TNF=0×03 and an empty Type field or with TNF=0×01 and Type=”U”. Clearly whatever tool was used to write the tags on the flyers has a bug, since these two distinct cases seem to have been mixed up so that we have the invalid combination of TNF=0×03 and Type=’U’.

So, the mystery of the unreadable tag was solved! Hopefully this account provides some insight into a real-world issue and the activities involved in investigating such a problem.

Have fun with NFC!

BlackBerry DevCon Europe in Amsterdam was my first BlackBerry conference and I have to say, I thoroughly enjoyed the experience. It was a great pleasure to meet developers who I’ve been working with by email but have never actually met in person.

Judging by the feedback received from attendees, the presentation I gave with John Murray, “DEV311 – How to develop an NFC enabled app,” was extremely popular. NFC is really a very large topic, especially when you start to move away from the simple use cases such as tag reading and into more technically-involved use cases, such as payment. It was a shame we were limited to a mere one hour. We could have talked about NFC all day!

However, there was an “incident” in the first of two NFC sessions which we presented, and it’s that incident that I want to write about here.

The event organizers had placed flyers on the chairs in the room, advertising another event that John and I would be at. The event is a NFC Hackathon to be held in London the weekend of March 24th and which our carrier partner O2 is sponsoring. (We’d love to see you there. You can find details at the following web site: http://www.isobar.com/en/news/2012/2/3/create-london)

The flyers had NFC tags fixed to the back of them and John and I knew nothing about this, so we were somewhat surprised when a member of the audience – as the very first question in our first session – said, “So why can’t my BlackBerry® Bold™ 9900 smartphone read this tag?!”
As anyone who has ever presented or done live demos of anything will know, things do go wrong from time to time and that’s all part of the fun. But this one came out of nowhere and we were, to put it mildly, a little stumped by this question initially!

Problems tend to indicate opportunities though, so given that I was presenting on the topic of tag reading when the question was asked, whilst I couldn’t say anything definite at the time (issues like this need technical investigation, as you’ll see), it did give me the opportunity to talk about standards and degrees of compliance. It’s a fact that of the many makes and types of NFC tags that are out there in the world, some comply 100% with the relevant NFC Forum and ISO standards whilst some do not. We’ve worked hard at RIM to ensure our products comply with those standards since for a technology like NFC to gain wide spread adoption, inter-operability between tags and devices and between devices themselves is absolutely crucial. That said, even if a tag complies fully with the technical standards, it’s still possible to write non-standard content to it, so we all have a responsibility to comply with those standards, not just the device vendors.

Having made my small speech about standards, we moved on and completed the presentation. But the story didn’t end there because neither myself nor John are the kind of people to be satisfied with anything less than a complete and technically accurate answer to issues of this sort! So we collected samples of the flyers with their tags and took them back to the hotel where we proceeded to analyse their content. We call this “NFC Forensics!”

The second part of this story will be posted tomorrow; until then send us your thoughts about what you think happened!

With the recent launch of the BlackBerry® PlayBook™ tablet, there has been a lot of excitement and activity around developing Web content for the platform as well as using the BlackBerry® WebWorks™ SDK to produce fully-featured standalone BlackBerry® applications.

I wanted to share details about some of the available debugging and profiling tools that you can use to improve the quality of your content by troubleshooting bugs, tuning changes, and optimizing performance.

Web Inspector for the BlackBerry Tablet OS

The Web Inspector tool is a debugging and profiling development tool for web content that is included as part of the WebKit rendering engine. It is widely considered one of the most comprehensive and powerful utilities that web developers can use to troubleshoot and optimize their web content. It includes a variety of features and capabilities, such as inspection, profiling, console integration and more.

A common challenge that mobile web developers have historically experienced is that the Web Inspector tool is easily accessible for use with content loaded directly within WebKit-powered desktop browsers (such as Google® Chrome or Safari), but not necessarily for content loaded on a mobile device. I’m very happy to share that you can now use the Web Inspector tool to debug and profile live web content and/or BlackBerry WebWorks applications running on a BlackBerry PlayBook tablet or simulator. In fact, the Web Inspector tool for PlayBook is one of the only detailed ways to see inside a live mobile browser.

How do I enable the Web Inspector tool for content loaded in the BlackBerry Tablet OS browser?

1. Select the “Privacy & Security” tab from the “browser options” screen on your BlackBerry PlayBook tablet.
2. Switch the “Enable Web Inspector” to On.
3. When prompted, enter your BlackBerry PlayBook tablet device password.

How do I enable the Web Inspector tool for a BlackBerry WebWorks application?

1. Use the –d command line operator when using the bbwp.exe utility to build your application.

bbwp.exe c:\sandbox\myApp\myApp.zip –d

Tip: You can enable the Web Inspector flag while building a signed version of your application; however, it is not recommended. By using both of these command line arguments together, it may allow remote access to the production version of your application.

How do I use the Web Inspector tool to load live content from the BlackBerry Tablet OS?

1. Open a desktop web browser such as Chrome, Firefox, Safari or Internet Explorer.
2. In the address bar, enter the IP address of the target BlackBerry PlayBook tablet and port 1337 (e.g. http://198.168.1.7:1337).
3. You will be prompted with a list of page titles for content that has been loaded into memory by the Web Inspector tool (such as browser content or a BlackBerry WebWorks application).
4. Click on any of the page titles to begin using the Web Inspector tool to debug and profile your Web content.

What about BlackBerry Smartphones?

Beginning with BlackBerry 7 handheld software, all handheld software going forward will have support for Web Inspector.

There is also a variety of alternative debugging options available for you to choose from that can assist in the troubleshooting and tuning of application content running on existing BlackBerry smartphone device software.

Additional debugging options

Some additional utilities that can be used to debug and profile web or BlackBerry WebWorks content running on BlackBerry Device Software version 5.0 and BlackBerry® 6:

Weinre

Weinre (Web Inspector Remote) is a server-based solution created by Patrick Mueller that is very similar in function to WebKit Web Inspector, except you can view and modify live debug info running from your mobile web content using a desktop browser. This can be quite powerful as it is designed to allow you to invoke remote JavaScript® from the console, as well as dynamically modify page content at runtime such as HTML or CSS. You can even use Weinre to troubleshoot blackberry.* JavaScript APIs.

Firebug Lite

Similar to Firebug, a developer plug-in for the FireFox browser, Firebug Lite is a JavaScript framework that is designed to be used to add debugging & profiling capabilities to web applications, including those for BlackBerry WebWorks. Developer Levi DeHaan has posted in the BlackBerry Web Community Forums about using Firebug Lite as part of your BlackBerry WebWorks application development.

Jsconsole.com

JSConsole.com is a remote service created by Remy Sharp that can be used to configure your BlackBerry WebWorks content to load a remote JavaScript file that shares output from console.log(). By doing this, you can view console output generated by your BlackBerry WebWorks application from your desktop browser, and troubleshoot applications running on either a live device or simulator.

More Info

• Chrome Developer Tools (aka Web Inspector) Guide
• Measure Web Load Times with WebKit Inspector (YouTube video)
• BlackBerry WebWorks SDK for Tablet OS
• BlackBerry WebWorks SDK for Smartphones
• BlackBerry Browser manuals

Happy debugging!