Web and WebWorks Development

[marcderosa]

Has anyone seen simulator messages like:

Require Error Can't find

/usr/bib/webplatform/plugins/mjnext/bp.so

Library cannot be found

when booting an html5 webworks app with a native extension. 

Although I am seeing this error,

1) I know that my deployment archive (*.bar file) has included my shared library because I can see it in the archive  under

/native/plugins/jnext/bp.so along with an expected auth.txt file,

2) I know that the deployment process in fine because I can copy the $SDK_DIR/Framework/ext/bbm.platform/simulator/bbm.so library to overwrite my bp.so library (also in a subdir of Framework/ext), do a rebuild and deploy. Then on booting my app, I get a message that bp.Memory can not be instantiated.. Which is fine, That tells me that my index.js file is loading the fake bp.so (good) but cant invoke the Memory class (expected, as it didnt  exist in bbm.so before the copy).

3) I know my C++ code is fine as I have an exact copy of the code in TEMPLATE (Memory) example C++ extension which I downloaded from github. 

4) I believe the shared library is fine as it built without issues in the IDE, downloaded from the C++ section of the developers tools. (Im using the Linux version and building with the default, device-debug settings). 

But, then, there has to be something wrong with the library because the system cant load it from the /native/plugins/jnext directory in the application folder. So, at the moment I'm suspecting that there is an integration issue somewhere between the various tools involved, the IDE, the SDK, the simulator.

Has anyone else had luck with native extensions for BB10 html5 webworks apps?

[marcderosa · Accepted solution]

I have had a little more time to play with this this morning and have been able to track down what is going on so...

For other developers who run into this. The reason this happens is that the Device-Debug or Device-Release profiles in the IDE produce a ELF 32 bit ARM shared libraries, while the Simulator-Debug or Simulator-Release profiles produce ELF 32 bit Intel 80368 shared libraries. Deponding on the target its important to therefore get the appropriate library.

For RIM, you have a somewhat unintegrated toolchain and I understand the limitations that you are under. On the other hand I have had to spend time reverse engineering that toolchain to figure out how it works. That reverse engineering work is not something that you generally are going to want to push downstream. Additionally, this thread is one but not the first usability issue I have run into with your tools . As a professional developer, wasted time on usability issues is very difficult to charge for (-ie: not cost effictive to develop for) nor is it pleasurable (-ie: it rots the brain). So I knowing what I do I would probably not take on work in the future related to BB development...

I think a fair estimation of where RIM stands in terms of development experience is  --- not on par with your competitors. I hope that can change as it really is in  the best interest of everyone that RIM is a successful part of the mobile market.