Native Development

[Ry_Fi]

Hi Martin, Jo and all.

I'm doing some development research trying to proof-of-concept the transferring of data between an Android device (Galaxy Nexus - 4.0.1) and the BB10 Dev Alpha via NFC's P2P/SNEP.  I grabbed your NfcTool and was able to transfer a vCard from the Alpha to the Android without a hitch - running the Send vCard (SNEP) in the Tool results in the Nexus receiving the vCard and saving it as a contact.  It's the other direction that I'm having problems with...

I created a new task in the NfcTool by duplicating the framework of the Send vCard task, stripping it out and giving myself a sandbox to play in.  On the Android side, I wrote a trivial little Activity to use the 

setNdefPushMessageCallback() method to send a TNF_WELL_KNOWN RTD_URI message. 

In my NfcWorker:: prepareToTestSnep() I've called nfc_register_ndef_push(), and in my NfcWorker::handleTestSnepEvent() I'm successfully getting an NFC_NDEF_PUSH_EVENT code whenever I put the devices back to back and tap the Android's screen.

The problem is, as far as I can tell, there are no methods supporting the reading side of the SNEP operation (!).  

The nfc_get_ndef_message_count() call in parseNdefMessage() returns 0, so there appears to be no message to actually receive at this point, without doing something else... I don't know what method to call or how to react to actually receive the message from the Android.  

As far as I can tell, the nfc_register_ndef_push() call only sets you up to be able to make a nfc_create_ndef_message() to send, but does not do the right thing to set you up to make a reception. 

Can someone please shed some light on how the receiving side of the SNEP transaction is performed on BB10, or whether that is even possible yet??

I've tried everything I can think of, swimming around in this as of yet undocumented NFC platform service, to no avail.  I've set up nfc_register_ndef_reader(), nfc_register_tag_readerwriter(), nfc_llcp_register_connection_listener(), but no matter what, I'm only getting the NFC_NDEF_PUSH_EVENT code when the devices are in range, and it seems like there's no way to actually receive the data.

Please educate me!  Thank you!

Ryan

[mwoolley]

Hi

receiving a pushed SNEP message is the same at a code level as reading an NDEF tag. So duplicate the tag read function not te snep push function and register for the appropriate NDEF or MIME type (depending on what exactly you are trying to transfer) and this should solve your problem.

All the best

Martin

[Ry_Fi]

Thank you for clarifying that, Martin!  The fact that this is indeed the solution for handling the receiving side of the SNEP push transaction was not at all clear and definitive to me, but maybe that's just me...

I certainly DID try this, however, and in fact the NfcTool should already work correctly using the Read task as it's configured to read Rtd URI records and that's what my Android app is sending, but this did not work.  Since I didn't know if this was the correct way or not, though, I didn't spend much time troubleshooting this, so I'll reexamine this approach.

Thanks again for clearing that up, and hopefully I can find out where my problem lies!

Ryan

[Ry_Fi]

Hi again Martin,

As I anticipated, I'm getting absolutely nowhere.  Since my Android app is pushing an RTD URI record, the NfcTool should be able to receive it using the existing Read task, correct?  This task calls nfc_register_ndef_reader() for 3 different record types, including RTD URI, and then should receive a corresponding NFC_NDEF_READ_EVENT when the sending device sends a correctly formatted record that falls under one of these 3 types.  (I'm just being thoroughly clear - I realize you already know this because YOU wrote the tool ;-))

However, I'm receiving no indication on either device that a SNEP transaction is occurring.  The Android device doesn't make its usual sound, and the Dev Alpha makes no sound and doesn't receive any NFC_NDEF_READ_EVENT, not even one with an incorrect record type.

You make it sound like I only need to call nfc_register_ndef_reader() on the Dev Alpha, and not nfc_register_ndef_push(), yet it's only when I call the latter that I can even get some sign that the devices are seeing each other.  What am I doing wrong?  Which device is failing to implement the SNEP protocol correctly?  

If you can guarantee me that the Dev Alpha is correctly implementing the SNEP protocol and that I'm doing everything correctly, then I'll have to accept that the problem lies with the Android...  But by all accounts, the Android supports SNEP and my trivial code is doing exactly what it needs to be doing. :-S

Do you know anything I don't know about NFC/SNEP issues between Android 4.0.1 and BB10?  Do you know if they are confirmed to work together, or confirmed to NOT work together, by more knowledgeable folks than me?

I'm seriously looking forward to some further guidance on the issue - I'm getting quite frustrated and not having much fun!  Thanks again for your time and effort.

Ryan

[mwoolley]

Hello Ryan

I just wrote a quick app for BB7 which uses SNEP to deliver an NDEF message with well known type TNF 01 and Type U. I downloaded and installed from GitHub, V2 of NfcTool, ran it on my DevAlpha and selected the Read function. I then presented my BB7 device running the SNEP URI app to the Dev Alpha. The NDEF message was delivered correctly and details displayed as expected on the Dev Alpha screen.

From this I conclude that the DevAlpha is working correctly.

I don't have much to go on here but my guess (and it's just a guess) is that the Android device is presenting a TNF 3 Absolute URI message not a TNF 1 well known type U. See http://devblog.blackberry.com/2012/03/nfc-troubleshooting-part-2/ for a little adventure I had with this issue and Android on a previous occassion.

I don't know how you're creating the SNEP message on the Android device but if you have control over the details, check the TNF and Type fields. If not, try sending a TNF 01, type T (Text) message to the DevAlpha, just to prove that at least that case works.

Regards

Martin

[HorizonXP]

I've been working with the Dev Alpha's NFC for the last month or so. I need to get things prepared for some travelling that I'm doing, but I'm replying just to let you know that I'll chime in when I get the chance.

[Ry_Fi · Accepted solution]

Hey again Martin,

I very much appreciate the effort that you spent on writing another tool and testing/confirming the SNEP functionality in the Dev Alpha.  Your confirmation that it works gave me encouragement to keep trying to get this working - and I finally did!  As a result, I have some big results to share:

The problem was not with the format of the URI record, which was totally valid (TNF type 1, totally adhering to the NFC Forum RTD-URI 1.0 URI Record Type Definition).  The problem was not resolved by trying a Text record type instead.  The problem did not manifest itself between two Android Galaxy Nexuses, which had no problems exchanging URI's, text records, etc.

The problem was this: The NFC on my Dev Alpha does NOT work properly when the device is attached to the computer via USB!

This is a consistently reproducible finding.  When I reboot the Dev Alpha and never connect it to the computer, I can run the NFCTool and successfully read valid TNF_WELL_KNOWN URI and Text records sent from the Android device.  If at any point I connect it to the computer, this functionality ceases functioning entirely and will only resume working if I power off the device and again reboot it without connecting it to the computer.  I can't just unplug it without rebooting, as this does not remedy the issue.

Well, then!  Is this a known fault??  Has this been documented anywhere?  Is this a fault with all Dev Alphas or just the one we received?  Is there a workaround to remedy the state of the NFC system without the need for the lengthy reboot of the device?  I'm really intrigued to hear what you/RIM have to say about this.

I'm not thrilled about the time wasted spinning my wheels with a configuration that was destined to never function properly... but on the other hand, I'm incredibly relieved that I have figured out the problems and can begin moving forward with development.  I certainly hope others can benefit from my troubles!

Thanks for your assistance Martin - I'm glad I had someone to bear with me through this fiasco.  Ciao for now.

Ryan

[HorizonXP]

Ryan,

I'm on a bus right now, so I can't pull up code examples or anything. I can however, describe my own experiences.

I've worked with NFC SNEP push on BBOS, Android and now the Dev Alpha. In my use case, all of the devices are pushing custom NDEF messages (ie. TNF_EXTERNAL) to a PC with a USB NFC reader. Over the course of my testing, I did use URI and Text types to ensure that communication occured correctly.

I have developed code to push NFC data from the Dev Alpha, using Martin and John's sample as a template, in both Python and C++. I have found that when NFC works, it works fairly reliably.

I seemed to have narrowed down the issues such that I can reproduce them reliably.

First, when your app starts, it needs to start a BPS event loop and request NFC events. When it ends, it needs to unregister for those events and shutdown the BPS loop. If you don't, you will crash the NFC subsystem, requiring a full device restart. This can also occur if/when your app crashes, thus resulting in the unregister code never being called. While I agree that no app shouldn't be able to crash a system-level service, please realize that this is an alpha device with alpha software. Also realize that the NFC libraries are currently unsupported. While the commented header files are there, along with a community sample, there is nothing officially published on the developer's site. So, while you and I can use NFC for now, we'll have to go through early adopter headaches.

The other issue I encountered with my C++ code is that it doesn't receive NFC events on every other application start. The community sample suffers from the same issue, but our code is quite similar, which could very well be a culprit. I have yet to narrow done precisely where it's occuring, but I will file a JIRA bug describing the behaviour. I don't know if it's BPS, Qt, or threading that's causing the strange behaviour.

Anyway, hope that helps shed some light on the situation. I haven't encountered any differences in NFC functionality with USB connected or not, but I'll confess that I do everything over Wifi.

Post here if you have more questions or concerns. I'll see if I can help you with them. If anything, it's good to document it so that others can avoid duplicating efforts. Ultimately, I will file all of these issues in a bug report so we can see them resolved in R6 or R7.

[mwoolley]

Ryan, you're welcome.

I have encountered the occassional issue which seemed to related to being connected to USB myself but not consistently in the way you seem to have. You're probably right.

One thing though Ryan; please bear in mind that you are running very early stage software. As we've pointed out when presenting at BlackBerry 10 Jam, what you have is not BlackBerry 10 and critically... it's not finished yet so you should expect there to be some issues and factor that into your plans.

Updates to your DevAlpha OS will be issued at intervals. Watch the developer.blackberry.com site for news on the next release which hopefully will address this issue.

Regards

Martin

[Ry_Fi]

Thanks for chiming into the discussion, HorizonXP.  

I as well noticed that there are issues with reliability of the NFCTool app and its ability to put the NFC subsystem into an irreparable state, requiring a reboot.  Since I've spent so much time messing around and not accomplishing much, it's pretty hard to rationalize spending the time trying to figure out exactly where and why the problem is happening, so I plan to just keep rebooting the device when that happens, for the time being at least.

I'm hoping a Dev Alpha OS update that improves the device's NFC stability is coming sooner rather than later, and hey, if you want to keep investigating this and possibly even nail it down and file a report with RIM, good on ya!

Best of luck in your NFC development efforts, and I'll probably see you around and maybe even be in touch again down the road.

Peace!

Ryan