01-07-2013 12:27 PM
I've been working on converting an exisiting BB5/6/7 app to BlackBerry 10 environment (mix of Cascades & C++) and have been getting to know and explore how to do things but I've come up with what looks like a fundemental stumbling block for any app that used to utilise background (service) running with autostart.
As with many apps on the BB5/6/7 framework my app was auto-started and ran in the background and responded to events using "listeners" as well as using a gui front-end for user interaction when needed .. now I understand that currently the 10 framework does not support (at least for third-party apps!) either auto-start apps or running in background invisibly (as a service) with the arguement being that there shouldn't be any need for background running as they can be resource hog etc., and besides one should be able to do everything without the need for that for instance using signals/slots etc.
The question I have though is that my app for instance could do what it used to by utilising the signals provided by the native o/s apps api, namely the PIM api .. so for instance I can connect slots in my app to the signals provided by Contacts Service, Calendar Service etc., like contactsAdded, contactsChanged, calendersChanged, etc.
.. BUT ..
.. for this to work my app must be running so the user would have to remember both to start the app everytime they turn on the device and must remember never to close it when minimised in the thumbnail view .. if they do accidently close it then the signals will get lost and the app becomes useless.
So the question is .. without background/service type apps, how do we write apps that utilise the provided signals from the o/s apps that we know will be open and running and not be useless as the user can easily accidently close them?
Whilst I can understand the need to ensure background apps don't become a resouce hog surely there could at least be a way to have an app "suspended" (not using resouces) but present and invokable using signals/slots as the whole o/s seems to be based.
There's a big push to get us developers to provide lots of apps for the new o/s release which makes sense but then preventing a fair number of background type apps from being ported/developed seems by not providing a way to do the above somehow seems rather counterproductive?
01-07-2013 01:20 PM
01-07-2013 02:45 PM
Thanks for the feedback, much appreciated.
I do agree signals/slots are for a running app, I guess I was meaning they're ideal for running app in the background which of course is not as you say currently possible.
It seems a shame that we'll have to wait until sometime after launch (and how long????) of o/s 10 before any of these sorts of app (that utilise background) will be possible as a great number of them were part of making the os 5/6/7 a success and it would help to get 10 off and running.
I guess one possible semi "workaround" is to use the current minimised/thumbnail approach if there was just a way of making it less easy for the user to accidentally close the app .. so is there any way perhaps of at least prompting the user, when in the thumbnail view, to confirm the close by say prompting with a "Are you sure you wish to close this app" type of dialog maybe? Either for all thumbnails or preferably for the specific app? I.e. if set to run in background is there a signal/slot that gets used when a user closes the thumbnail that could prompt?
thanks & regards,
01-07-2013 05:04 PM
01-08-2013 06:25 AM
Thanks for the suggestion on setClosePrompt, works a treat!
So now there's a sort of workaround to background app until that becomes available by at least making it less easy to accidently closing an app ..
.. now if there was just a way currently to auto-start an app on power up ..
Thanks & regards,