Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-27711] TiAPI: Add state querying methods to UI components

GitHub Issuen/a
TypeStory
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2020-08-25T00:39:14.000+0000
Affected Version/sn/a
Fix Version/sRelease 9.1.0
ComponentsTiAPI
LabelsengSchedule
ReporterChristopher Williams
AssigneeChristopher Williams
Created2020-01-08T15:40:38.000+0000
Updated2021-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()

Comments

  1. Christopher Williams 2020-01-14

    https://github.com/appcelerator/titanium_mobile/pull/11433
  2. Joshua Quick 2020-01-14

    [~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.
  3. Christopher Williams 2020-06-22

    Merged to master for 9.1.0 target

JSON Source