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!

To wrap up the 2011 BlackBerry® Developer Challenge, Research In Motion® (RIM®) and the BlackBerry Partners Fund have announced the final round of Recognition Award winners at BlackBerry DevCon Europe. Overall, we were very excited to see all the apps that were submitted to the developer challenge from around the world – they showcase the creativity of the BlackBerry developer community and your amazing talents. Keep these great apps coming in 2012 and remember to #BeBold!

Congratulations to these Recognition Award recipients! They receive a package with prizes consisting of tickets to the now sold-out BlackBerry DevCon Europe, a BlackBerry® PlayBook™ tablet, BlackBerry® smartphones and more.

• Best B2C app developed for a customer by an agency or ISV – Yemeksepeti by tmob
• Most useful enterprise application – MDC Mobile Data Collection by Gulliver
• Best website conversion using the BlackBerry WebWorks platform – Salzburger Nachrichten Mobil by Salzburger Nachrichten
• Most creative implementation of Super App characteristics – InStyle.de by ISEC7
• Top performers – Most innovative use of Payment Service and/or Advertising Service – Bellshare
• Academic – Most compelling app created by a student or faculty member – Polar Slide by Dustyroom

For more information on the BlackBerry developer challenge and to read the press release visit: http://www.blackberrypartnersfund.com/challenge.

In May at the BlackBerry World™ conference 2011, we announced the launch of the first ever BlackBerry® DevCon Europe and the second BlackBerry® DevCon Asia. We are now pleased to tell you the dates and location of these events – BlackBerry DevCon Asia will be held in December in Bangkok, Thailand with specific dates to be announced shortly. BlackBerry DevCon Europe will follow in Amsterdam, February 7 & 8, 2012.

We are excited to expand these events as this gives us an opportunity to talk to you about the latest in BlackBerry development, as well as giving you the opportunity to share your experiences and showcase your applications with your community. As such, there is no better way to share your story than to answer the Call for Papers. If you haven’t submitted a paper yet, we want to hear from you – in fact, we are extending the deadline to Friday July 15th for BlackBerry DevCon Asia and Friday September 16th for BlackBerry DevCon Europe. Stay tuned for details on registration and pricing for both of these events.

Remember to visit the BlackBerry DevCon website to learn about these events and to register for the upcoming BlackBerry DevCon Americas!