Native Development

[kavita038]

Hello Everyone,

I would like to know if background applications are possible in playbook or not? I need that my application should be running, even if UI is not there or it is closed.

Response would be highly appreciated.

Thanks in advance.

[kavita038]

Hello Everyone,

I would like to know if background applications are possible in playbook or not? I need that my application should be running, even if UI is not there or it is closed.

Response would be highly appreciated.

Thanks in advance.

[abibik]

I am also would really like to get some information on the background apps.

Due to some confirmed bugs in the AIR runtime our large (500+ PB's) enterprise client is in dire need of some workaround. A background application (service) could allow us to address his problems, but I can not find any information on the topic.

So, the questions are:

1. Is it possible to run an app without any UI (like service in Windows world)?

If not,

2. Is it possible to prevent an app to be closed by a user's action? Basically the idea is to have a standart app with UI, but not allow a user to close it - only deactivate.

[smcveigh]

This has been answered many times already. 

The answer to both questions is currently no.  A model for background applications has yet to be developed.

That is not to say that other workarounds to your current problem are not achievable.

Cheers,

Sean

[abibik]

>That is not to say that other workarounds to your current problem are not achievable.

Finding workarounds for OS problems is no fun even in more "open" OS's. In regards for PB OS I have heard blunt "No, you can't do it" way too often...

My problem is that the AIR API call

QNXSystem.system.requestResource(QNXSystemResource.GEOLOCATION);

does not work starting from OS v 2.0 (worked fine in v 1.X), hence we stop collecting GPS data when the device going to sleep mode. This is unacceptable behavior for our client.

And now we are looking for a workaround.

The first idea was to create a background (or even foreground) native app which would collect GPS data non-stop. Ok, this one we can't do.

Now the second idea:

If we create a native extension for AIR, can we make following call from that extension:

int idle_mode = SCREEN_IDLE_MODE_KEEP_AWAKE;

screen_set_window_property_iv(screen_win, SCREEN_PROPERTY_IDLE_MODE, &idle_mode);

There is a thread which points that this piece of API seems to work more-less for a native app, but what about AIR Extension?

http://supportforums.blackberry.com/t5/Native-SDK-for-BlackBerry-Tablet/Running-app-while-in-standby...

And how do I get  screen_win for the AIR extension?

[smcveigh]

Oh right, this problem.

A quick search brings up this link:

http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/How-to-Keep-the-Screen-On/ta-p/10...

You do not need to resort to native extensions to keep the screen awake.

As for getting GPS readings in standby, I have been trying to determine what the intent is going forward.  Will provide more info as it becomes available.

It sounds like the bug does lie with how AIR is communicating the desire to receive 'background' readings.  If you spawn a native extension to poll the GPS data, that may solve your problem, however I am being told that the API does not yet have the published ability to request "background" updates.

Sounds like the only solution currently, without going directly to PPS objects, which are undocumented and unsupported, is to keep the screen on.

Cheers,

Sean

[rmisk]

I am trying to do the same thing in native and I cannot get the recommended solution:

int idle_mode = SCREEN_IDLE_MODE_KEEP_AWAKE;
int rc;
rc = screen_set_window_property_iv(screen_win, SCREEN_PROPERTY_IDLE_MODE, &idle_mode);
if (rc != 0)
{
fprintf(stderr, "Screen error setting SCREEN_IDLE_MODE_KEEP_AWAKE: %d\n", rc);
// return EXIT_FAILURE;
}

to work reliably.  

I get no error from the above so I assume it is supposed to work.

In one application based on the geolocation example it sort of works.  It does not work if I call it before the main loop in main(), it does work if in the main loop but if the geolocation_period is 1 if set to 5 it won't work.

In another application based on HelloWorld(Display) although again I get no error when compiling and executing the above code I can't get it to work at all.

I have addressed this in a related post and reported it as a bug but no one seems particularly interested as I have yet to receive a response.

Roger

[smcveigh]

Please post the rest of your code.

How are you creating your window, etc?

Cheers,

Sean

[abibik]

---

smcveigh wrote:

Oh right, this problem.

A quick search brings up this link:

http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/How-to-Keep-the-Screen-On/ta-p/10...

You do not need to resort to native extensions to keep the screen awake.

Cheers,

Sean

---

Thanks, really appreciated, I will give it a try. While keeping the screen on will obviously drain the battery, it might work as a temporary solution. I need to test it.

Thanks!

[abibik]

---

abibik wrote:

I need to test it.

---

The suggested code worked as expected, and I was able to collect GPS data non-stop, but this workaround brings up another problem.

I have created a new forum thread since the new question has nothing to do with background applications.

http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/How-to-force-Playbook-to-prompt-f...

[peter9477]

Note that the previous functionality that allowed AIR apps to get GPS info in standby, but which was broken in the 2.0 betas and the 2.0.0 final release, has apparently now been restored in 2.0.1.358.  See http://supportforums.blackberry.com/t5/Adobe-AIR-Development/Beta-2-0-bug-QNXSystemResource-GEOLOCAT...

For Native SDK users, that means the functionality really is there, just not exposed yet in the NDK.