Ok, I’ve now submitted an app (shh, under NDA) on Playbook (NDK, not Air/etc) and here are some tips.  Most of this is Windows-centric.

1.  Use their special version of Eclipse

It’s actually pretty good and coming from an old school MSVC’er that’s saying something.   It makes setting up your RIM dev account, certificates, device debug token, simulator, etc very easy.

The Simulator, run through VMWare is very quick (1000+ fps for a simple gl app) and Eclipse does full debugging with it.

I wasn’t able to get debugging working on the real device, but I didn’t try very hard and it might have been because I think I only tried it with wifi and not usb.  No biggie because the Simulator was very good and the bugs were already gone.

Although, one thing to note is you know how in the simulator, you see the wrong gl surface when thumb-nailing the app?  The real device doesn’t have that problem, so don’t waste time trying to fix it.. like I did.

2.  You can include a folder of assets

Just something that’s good to know – put your assets in a folder tree and you won’t have to worry about adding/removing stuff as you work on your app.  iOS’s xcode can do the same thing, for instance.  You can hand edit the bar-descriptor.xml or use the editor built-into Eclipse which makes it easy.

3.  OpenAL won’t work on the 1.X sim or device unless you manually include the libraries with your app.

Yeah, weird.   You can add those libraries as assets by doing something like this in your bar-descriptor.xml:

<asset path="${QNX_TARGET}\..\target-override\armle-v7\usr\lib\libOpenAL.so.1" type="Qnx/Elf">lib/libOpenAL.so.1</asset>
<asset path="${QNX_TARGET}\..\target-override\armle-v7\usr\lib\libalut.so.1" type="Qnx/Elf">lib/libalut.so.1</asset>

You can check their BelligerentBlocks example if you grab it with git, they do it there.  So what happens if OS 2.x comes with new libs and… uhh.. gotta run.

(Huh, sorry about the bad formatting above, just cut and paste somewhere if you can’t see the text right..)

4.  How to fix:  Error: Unable to resolve path variable “QNX_TARGET”

Sorry, but if you did what I said above, you’ll get this error if you try to package your app from the command line, which I found for the final “signed” build I had to do as I couldn’t figure out how to get the IDE to not add -debugMode.

Anyway, there actually IS a QNX_TARGET defined in windows (it’s set in bbndk-env.bat) which might confuse you – it’s not talking about that, it’s talking about the ${QNX_TARGET} we used above.  The IDE has this defined but on the command line it isn’t.  I tried the -env parm to no avail..  so as a work around, you can replace it with the actual path.  (You know a better way?  Let me know, I don’t want hardcoded paths in my bar-descriptor.xml!)

5.  How to sign your NDK app for final publishing

Currently, most of the docs about publishing on App World assume you are an Air or WebWorks app and have confusing differences.  (Like, I don’t think you can use BlackBerryGraphicalAid) To do your final build, just use the command line.  Here is an example .bat of how to do it, assuming you’ve already built your app with Eclipse or a makefile:

call c:\pro\bbndk\bbndk-env.bat
<note: Next two lines should be one line..>
call blackberry-nativepackager.bat -configuration com.qnx.qcc.configuration.exe.release.1153117490
  -package Device-Release/MyAppName.bar bar-descriptor.xml
call blackberry-signer -storepass <yourpassword> Device-Release/MyAppName.bar
call blackberry-signer -verify Device-Release/MyAppName.bar
pause

Ok, see that crazy “com.qnx.qcc.configuration.exe.release.1153117490” up there?  I pulled that out of the bar-descriptor.xml file, this is how you control which build type to package.

If you get a “this has already been signed” error, you need to edit the bar-descriptor.xml file and increment your version #.  (Note from peter9477: there is an option in the packager that will increment it for you .. so if you have 1.0.0, it will make 1.0.0.27 if you do -buildld 27)

6.  Playbook support is coming to Proton!

Well, it’s actually already on the svn but I’d like to further clean it up before declaring it done.   What’s Proton?  It’s my open source C++ framework that lets you target iOS/Android/Win/OS X/webOS and now Playbook with the same code.

And that’s it.

Thanks to the guys from #playbook-dev on freenode for helping me out.