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
Developer
Developer
Posts: 46
Registered: ‎02-22-2012
My Device: Developer
My Carrier: Various

Application Lifecycle

Having read the 'docs' + experimented, there seem to be various things going on that dont really make much sense: Any clues which are bugs, features, or us doing something incorrectly from the following:

 

i) app:thumbnail signal

This appears to be emitted at the point you start to drag the app from bottom AND NOT when the app is actually thumbnailed. So you get 'thumbnail' signal immediately followed by a 'fullscreen' signal if you dont drag the bottom of the app up the scn very far + app pings back to full screen.  Not very useful as you are told the app is thumbnailed when it isnt.

 

ii) app:invisible

Its not at all clear when an app is 'invisible'. E,g, if you are thumbnailed and you drag down the top of screen (containing some system config stuff) so the thumbnail is covered, no invisible signal is received, despite thumbnail being hidden from view. If however you swipe left right to other icons you get the invisible.  So ignoring the English language defn of invisible - what does invisible actually mean for bb10 apps ?

 

For what its worth your app will be told its thumbnailled when you move from an 'invisible' state to your thumbnail being displayed on screen, depite the fact you were already thumbnailled.  So again thumbnailled does not appear to actually mean the transition into a thumbnail, in this case it means 'become visible'

 

iii) app:asleep/awake

It appears Cascades Apps are put to sleep when thumnailled. They are sent the awake when you exit from thumbnail, then sent a fullscreen. This is IRRESPECTIVE of whether you have a run_when_backgrounded permission set.

Infact run_when_backgrounded does not appear to work at all.

(The app has a single thread - the cascades UI thread - and it seems to be suspended regardless of setting of  run_when_backgrounded when thumbnailled).

 

So

Can anyone clarify whether what we are observing is what is supposed to be happening - e.g. being told you are thumbnailled when you are already thumbnailled

Similarly for the run_when_backgrounded permission

 

 

Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Application Lifecycle

Think of thumbnail as being "neither fullscreen nor hidden". When you begin the up-swipe, it immediately shrinks and is not fullscreen, so it's "thumbnailed". There are many possible sizes for the thumbnail, with "one pixel smaller than fullscreen" being, in effect, one of them...

There may be corner cases (which might get fixed) when some of these don't entirely fit... for example the case where the app's thumbnailed view is obscured by the top-swipe menu on the home page. Is it very important that these are addressed? I think it's fair to say there's no big problem caused by having the top two running apps not be told the swipe-down menu has hidden their windows.

I haven't finished exploring the run_when_backgrounded behaviour so I don't have an answer on that one.

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
Developer
Posts: 46
Registered: ‎02-22-2012
My Device: Developer
My Carrier: Various

Re: Application Lifecycle

Fixing Edge cases:

Really rather depends on what the system is attempting to do.

In general edge cases that dont obey the spec/defn should be fixed as usually they are bugs.

In our particular app at this particular time the observed edge effect does not have any adverse effect except being confusing as to what the app lifecycle actually is + what we should be doing + where

 

The pictures at

https://developer.blackberry.com/cascades/documentation/dev/fundamentals/index.html

strongly implies you are about to enter a Stopped state if you get the invisible signal. If thats the case invisibility does not really have much to do with being invisible and more to do with being stopped. Not being visible is one thing, not actually running at all is rather different.

 

Being 'stopped' just because a user has tasked to another app is not always the most reasonable behaviour for an app. Hence the requirement to understand what this really means is going on.

 

The docs then suggests that invisibility may have something to do with a phone backlight switching off/being off - but what has the phone backlight got to do with an app running or not...  Backlights are normally for viewing screens in the dark more easily. So maybe invisibility really is associated with the ability of a user to visually observe the app + not much to do with being stopped as previously implied.

 

In short its pretty hard to decipher exactly what is going on in the app lifecycle and consequently exactly what apps should be going when these states occur + indeed if its desirable or otherwise, for example, to have the run_when_backgrounded permission.