[TIMOB-20461] iPad: Events fired by Slide Over and Split Window not clear/documented
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2016-03-05T15:13:45.000+0000 |
Affected Version/s | Release 5.2.0 |
Fix Version/s | Release 5.4.0 |
Components | iOS |
Labels | qe-5.4.0, splitview |
Reporter | Fokke Zandbergen |
Assignee | Angel Petkov |
Created | 2016-02-25T11:21:48.000+0000 |
Updated | 2016-08-09T20:47:28.000+0000 |
Description
With TIMOB-19691 we have added support for Split View and Slide Over.
When the app Slides Over or changes to/from Split View, the
Ti.App:resumed
and in one occasion Ti.App:resume
events are fired. We have not documented this, but I'm filing this in TIMOB because we might want to find out if there are ways/reasons we should split this out into specific events for Split View and Slide Over.
For a list of events in which resume
and resumed
are fired see the 5.2.0 Sample Source:
https://github.com/appcelerator-developer-relations/appc-sample-ti520/blob/master/app/alloy.js#L37-L55
The resumed
event actually covers pretty much all scenarios, except for one AFAIK. When your app is on the left side of a Split View and moves back to fullscreen because the other app closes or switches to Slide Over you will not get notified. It would be great if we can somehow detect this as well.
/cc [~bimmel]
Also see http://www.appcelerator.com/blog/2016/02/titanium-5-2-0-launch-files-ipad-pro-slide-over-and-split-view/
I'm not even sure if we can split this out into specific events. If not, we should open a docs ticket to document the current behavior. [~apetkov] can you investigate please?
[~fokkezb] The resumed event will get fired every time we modify the application, be it from sliding it left to right or any other instance where we are invoking it.We could check if we can add a message to the event to display what caused the event to get fired ? Other than that I'm not quite sure what you mean. Could you elaborate please ? Thanks!
[~apetkov] It does except for one: > The resumed event actually covers pretty much all scenarios, except for one AFAIK. When your app is on the left side of a Split View and moves back to fullscreen because the other app closes or switches to Slide Over you will not get notified. It would be great if we can somehow detect this as well. Can we catch that case as well? Then I don't think we need much else then documenting the
resumed
event is indeed what you need to listen for.[~fokkezb] Hey Fokke I'm not able to re-produce a way to miss the resumed event. I tried opening the app from the right side while contacts is open , dragging it backwards and forwards which causes the event to be called.Dragging it all the way to the left to gain all focus. Then while the app is now full screened pulled contacts from the right, backwards and forwards the event was still being called. I slided the contacts all the way to the right until the app gained full screen again in which the resumed was called again. Updated docs, PR :https://github.com/appcelerator/titanium_mobile/pull/7799. [~bimmel] Could you please review the PR.
[~apetkov] to see the missed event: 1. Open the test app 2. Open contacts as slide over 3. Tap the devider to switch to split view (you get resumed event) 4. Tap the devider to switch contacts back to slide over (you don't get resumed event) This can be problematic because with step 4 your app *does* resize, so when you have no event to listen to you can not undo any UI changes you did to accommodate split view.
[~fokkezb] Ah yeah was able to re-produce it now , thanks for the instructions! The reason the resumed event doesn't get called in that case is because the app is paused , it hasn't resumed yet which is why is darked out. Its running in the background effectively on pause. If you listen for the *pause* event , it gets called soon as the app gets put in the background , ones you tap or slide the application the resumed event will be called straight away. Updated PR by adding documentation to the pause event.
Thanks [~apetkov], you right. I updated the sample to describe the role of pause and paused: https://github.com/appcelerator-developer-relations/appc-sample-ti520/blob/master/app/controllers/index.js#L133-L139 I also left some notes on the PR. I think we need to add
paused
and clarifypause
a bit more using what I have at the above URL.I've updated the PR to match your feedback , ill add the more clear description to match the one in your sample app. For both paused and pause so one can better differentiate from the other.
PR approved! Anyway, I agree with Fokke that we should think about specific events for splitviews to ease the client-side handling of those different events. [~fokkezb], naming suggestions, maybe in a new ticket for further discussions?
As [~cng] mentioned, it's unlikely that we can detect the reason of the resume(d) or pause(d).
Verified as fixed, documentation has been updated accordingly. Tested On: iPad Pro (9.3.1) Mac OSX El Capitan 10.11.6 Ti SDK: 5.4.0.v20160809033140 Appc Studio: 4.7.0.201607250649 Appc NPM: 4.2.7 App CLI: 5.4.0-40 Xcode 7.3.1 Node v4.4.7 *Closing ticket.*