[TIMOB-15769] Android: Add new 'render' event that fires when a window actually shows
GitHub Issue | n/a |
---|---|
Type | New Feature |
Priority | Medium |
Status | Closed |
Resolution | Won't Fix |
Resolution Date | 2014-04-22T21:11:04.000+0000 |
Affected Version/s | n/a |
Fix Version/s | 2014 Sprint 08, 2014 Sprint 08 SDK, Release 3.3.0 |
Components | Android |
Labels | activity, android, axe, events, triage, windows |
Reporter | Fokke Zandbergen |
Assignee | Hieu Pham |
Created | 2013-11-16T12:56:48.000+0000 |
Updated | 2017-03-29T19:29:03.000+0000 |
Description
Following the discussion in TIMOB-15105 I want to request a new
render
(or whatever we name it) event for Ti.UI.Window
objects that would fire when the window is (first) visible/rendered.
As discussed the open
event fires when the (on Android) activity is created and proxy element(s) are set up. If you listen to this event and then create another window, this will create a new activity, pausing the activity of the first window, causing it never to be visible at all.
If we would have a render
event and wait for that to fire, this would solve the problem and make the windows behave like expected.
*Use case:* Windows used as loading indicators not showing because they are paused by the next window/activity created.
Priority
None
? Without this event it is now impossible the actually do something *after* a windows shows without running the risk of the user not seeing the window at all because its activity is paused by following operations.Now I am experiencing this as well.
[~fokke] We do not immediately assign a priority to all new tickets, especially ones that fall under the "New Feature" category. We will discuss this in triage.
[~ingo], just consider my comment a contribution to triage then ;) By the way, I see it is labeled Android, but I would like to have this event on all platforms, even if this means it is fired at the exact same moment as
open
is for those platforms. Otherwise you will have ugly platform switch-code everywhere:This is not necessary. 'postLayout' event does the same thing for Android.
[~hpham] Have you ever used
postlayout
yourself? It fires for every layout change in the hierarchy, so if you listen to that event on the window the events pile up while you only need it once. It requires bloated code to remove the event listener on its first call and then still leaves you with a polluted bridge. I think **that** shouldn't be necessary :)Closing ticket as "Won't Fix", with reference to previous comments.
[~lmorris] does this mean you are closing the ticket based on the previous comments that show the 'postLayout' does NOT achieve the objective? So you have chosen not to fix something that is still 'broken' and has no current work-around noted by anyone and certainly not in 'the comments'. If you do NOT WANT to fix that is one thing - but it is improper to suggest that the decision is based on ANYTHING noted in this ticket. Honesty is a great policy I am told.