Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Contributor
bezineb
Posts: 17
Registered: ‎01-08-2012
My Device: BlackBerry Playbook - developer
Accepted Solution

Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

Hello,

 

I've tried to access the gyroscope for an AIR Native Extension, using the NDK 2.0 Beta 3, Flash Builder 4.6 and Tablet OS 2.0.0.7111

 

I managed to do a simple C library I can call from AIR (so that I'm sure all the settings are correct) but as soon as I add a reference to the sensor.h the library no longer loads. I get the following error in AIR:

 

ArgumentError: Error #3500: The extension context does not have a method with the name init.
at flash.external::ExtensionContext/_call()
at flash.external::ExtensionContext/call()
at com.adobe.nativeExtensions::Gyroscope$/get isSupported()[/Users/airqe/Users/sbhave/Gyroscope/AS/src/com/adobe/nativeExtensions/Gyroscope.as:106]

...

 

My hypothesis is that I'm using a library wich contains the sensor functions which cannot be found, hence it can't load my library. But I can perfectly be another issue.

 

Anyone has managed to make this work? Any help would be welcome.

 

Thanks!

Please use plain text.
BlackBerry Development Advisor
twindsor
Posts: 832
Registered: ‎07-15-2008
My Device: Passport
My Carrier: Bell

Re: Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

If I am understanding what you are doing correctly, you're working with code from here:

http://www.adobe.com/devnet/air/native-extensions-for-air/extensions/gyroscope.html

 

That seems to include extensions for iOS and perhaps Android, but I see no mention of PlayBook.

 

I would recommend taking a look at this code and setting it up in an ANE:

 

https://bdsc.webapps.blackberry.com/native/beta/documentation/recipe_accelerometer_1935321_11.html

Tim Windsor
Open Source Technical Lead
Please use plain text.
Contributor
bezineb
Posts: 17
Registered: ‎01-08-2012
My Device: BlackBerry Playbook - developer

Re: Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

My goal was to extend the Adobe ANE for the gyroscope to the playbook, on top of the already provided implementations for iOS and Android.

 

My problem doesn't seem to be at code level, as it's quite simple, but rather at library dependency. As soon as I had sensor method calls in my native C code, the library won't load (and the code isn't even executed). When I comment those lines, the library gets loaded correctly and I can call the ANE methods.

 

Any idea?

 

Thanks,

Benjamin

 

Please use plain text.
Developer
alopix
Posts: 416
Registered: ‎04-10-2011
My Device: Z10 LE & PlayBook

Re: Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

Did you already try using the Accelerometer sensro that comes with AIR? I'm not sure but I would say it gives you exactly the data you need.
http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/flash/sensors/Accelerometer....
-----------------------------------------------------------------------------
Check out my apps in the BlackBerry World
Visit my developer blogs /dev/alopix and /home/alopix
BBM Channel: C0047B612
Please use plain text.
Contributor
bezineb
Posts: 17
Registered: ‎01-08-2012
My Device: BlackBerry Playbook - developer

Re: Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

Unfortunately no, AIR only exposes the accelerometer data, and I'm looking for the gyroscope sensor.

 

I managed to get the log file on the device:

In air-log, I get:

err: extension: failed to load /accounts/1000/appdata/net.thingsfactory.sandbox.debug.testDev_ndbox_debug1ef1592_/app/air/META-INF/AIR/extensions/com.adobe.gyroscope/META-INF/ANE/QNX-ARM/libGyroscope-arm.so: Unresolved symbols (tid:1)

 

In log:

err: config: Failed to open file (): No such file or directory (tid:1)
unknown symbol: sensor_set_rate
unknown symbol: sensor_info
unknown symbol: sensor_info_get_delay_mininum
unknown symbol: sensor_info_destroy

 

I searched this forum and found this answer:

http://supportforums.blackberry.com/t5/Native-SDK-for-BlackBerry-Tablet/OpenGL-rendering-from-ANE-Po...

 

Apparently, there are limitations in ANE and I could use the libraries I want. Plus, I need to use bps to get the sensor events, and the thread above suggests it's not possible.

 

Are those limitations still true with BB OS 2.0, AIR 3.1 and the Native SDK 2.0?

 

Thanks!

Benjamin

Please use plain text.
BlackBerry Development Advisor
elena_laskavaia
Posts: 417
Registered: ‎10-27-2010
My Device: PlayBook

Re: Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

Where are these functions defined? You if they defined somewhere in library on the device, you need

to link your ANE .so to the this library, so it be dynamically linked at runtime and will load these symbols.

 

Please use plain text.
Contributor
bezineb
Posts: 17
Registered: ‎01-08-2012
My Device: BlackBerry Playbook - developer

Re: Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

I just added bps in the libraries (-l) settings of the GCC linker and it works.

 

Thanks for the explanation!

Please use plain text.
Developer
greg209
Posts: 70
Registered: ‎12-13-2010
My Device: Playbook 16Gb

Re: Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

Hi,

 

I'm having similar problems getting sensors to work correctly through an ANE using the NDK 2.0. I've succesfully managed to compile and run my test app and ANE on my Playbook and can see the stdout traces I'm making during the ANE calls. So all is good, including calls to set up the sensor rates, etc.

 

My problems are with accessing the data from the sensors. Currently, all the examples I've seen for accessing the sensors have been fully native apps (e.g. https://bdsc.webapps.blackberry.com/native/beta/documentation/recipe_accelerometer_1935321_11.html) rather through an ANE. As such they tend to call the bps_initialise, setup the sensors and then continue with something like ....

 

while {!shutdown) {
.... process the events forever until the app closes
}

 

Unfortunately, applying the same principle in an ANE doesn't work. When the ANE call is made, the ANE just sits there waiting and processing events and never returns to AIR.

 

In the iOS Gyroscope example, a handler is created to manage the despatching of sensor information, allowing the 'start' function call to end nicely and enable the AIR app to continue processing the despatched events. Is there a mechanism available on the PlayBook to create a handler/manager/thread to despatch sensor information separately, so again the AIR app can continue to consume the ANE despatched sensor events.

 

This problem may be part of what's described in the thread above (http://supportforums.blackberry.com/t5/Native-SDK-for-BlackBerry-Tablet/OpenGL-rendering-from-ANE-Po...). Can we use bps in an ANE? If not, how can we access those 'bps' based features through an ANE as that's one of it's main purposes. If we can, how do we manage the ANE despatching events without it going into while loop forever?

 

Any help on this would be greatly appreciated.

 

Cheers

 

Greg209

Please use plain text.
BlackBerry Development Advisor
smcveigh
Posts: 668
Registered: ‎11-29-2011
My Device: developer

Re: Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

Can you launch a thread when you call a "start sensor readings" function in your ANE?  The pthreads library is widely documented.

From that point on, you should be able to run the event loop asynchronously and push events to the AIR app by dispatching an AIR event.

Alternately your "get readings" function could simply return the last reading cached by your event monitoring thread.

 

Cheers,

Sean

Please use plain text.
Developer
greg209
Posts: 70
Registered: ‎12-13-2010
My Device: Playbook 16Gb

Re: Use sensor APIs of the NDK 2.0 in an AIR Native Extension (ANE)

That sounds exactly like what I'm trying to achieve.

 

Thanks for pointing me in the right direction - I'll take a look into pthreads when I get chance, but sounds promising. 

 

Cheers

 

Greg209 

Please use plain text.