[TIMOB-27711] TiAPI: Add state querying methods to UI components
GitHub Issue | n/a |
---|---|
Type | Story |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2020-08-25T00:39:14.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 9.1.0 |
Components | TiAPI |
Labels | engSchedule |
Reporter | Christopher Williams |
Assignee | Christopher Williams |
Created | 2020-01-08T15:40:38.000+0000 |
Updated | 2021-02-08T18:58:38.000+0000 |
Description
This is a glaring issue when we look at our test suite and see the common
before
hooks we've written to clean up open windows/etc.
We have no means of telling if a Window is closed or open. So instead we fire off a 3-second setTimeout
fallback to handle the "isClosed" case, and then hang an event listener for the close event and try to close the window. So in the case where the test never opened the window (or already closed it), we basically do nothing for 3 seconds and assume since the close
event never fired that it must have been closed.
We have Ti.UI.View.visible
which should tell us if a view is hidden or visible.
Proposed APIs:
Ti.UI.Window.closed
- boolean
, true
or false
* tells us if the window is closed (do we need opened
equivalent? I assume they'd just be inversions of one another)
* Potential alternates? isClosed
, closed
, opened
, isOpened
(properties versus methods?)
* Note that JavaFX uses showing
as a roughly equivalent API here: https://openjfx.io/javadoc/13/javafx.graphics/javafx/stage/Window.html
* Android equivalent may be isActive
? https://developer.android.com/reference/android/view/Window.html#isActive()
Ti.UI.View.focused
- boolean
, true
or false
* Potential alternates? isFocused
, hasFocus
(properties versus methods?)
* https://developer.android.com/reference/android/view/View#hasFocus()
https://github.com/appcelerator/titanium_mobile/pull/11433
[~cwilliams], we should define what the focus behavior should be for a window when a dialog is displayed. Currently there is a parity issue as noted here: [TIMOB-26176] In my opinion, I agree with iOS' behavior. Window "focus" should be lost when a dialog appears. The dialog gets the "focus" instead and will receive user-input.
Merged to master for 9.1.0 target