11-09-2012 06:36 AM
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.
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'
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).
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
11-09-2012 10:09 AM
11-09-2012 12:20 PM
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
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.