Add 'restoreSystemUIOverlays' to SystemChrome to allow simple UI restore after System force changes. #22221
Conversation
There was a problem hiding this comment.
necessary.
Though I'd be tempted to phrase These settings may be overridden by the platform at runtime.
There was a problem hiding this comment.
enable the navigation bar
There was a problem hiding this comment.
Unless the Android docs specify this explicitly, I'd leave out the rationale for this behaviour from our docs.
There was a problem hiding this comment.
Maybe: to the last settings provided via [setEnabledSystemUIOverlays].
There was a problem hiding this comment.
I'd drop the second sentence, which mostly repeats the one-line summary above, then merge into the paragraph below.
There was a problem hiding this comment.
Maybe lead with: Note: On Android ...
Similar comment to above about commenting on the rationale for this behaviour.
There was a problem hiding this comment.
Ah, I just gave the opposite comment!
We try to avoid "Note" and "Note that" and so on in the docs, since it doesn't add anything.
GaryQian
force-pushed
the
restoreoverlays
branch
3 times, most recently
from
b9b3a3d to
8a1056b
Compare
|
Should we be calling this API automatically from our keyboard logic? |
|
So the current native behavior is that once the overlays are forced to appear by the keyboard, the overlays stay until manually disabled again. In addition, we would have to delay roughly one second before calling this API, and that may cause unexpected behavior when the view readjusts itself without the developer asking it to. This would probably lead to developer surprise, especially if they are testing on some of the android versions that have slightly different keyboard-appearing behavior (eg, android 27 does not force the status bar from appearing) Also, the PR for the engine side: flutter/engine#6322 |
This will not be active on the Framework until flutter/flutter#22221 lands.
…ore after System force changes.
GaryQian
force-pushed
the
restoreoverlays
branch
from
8a1056b to
fcfb960
Compare
|
@Hixie Is this API addition ok to go? |
| /// | ||
| /// On Android, the system UI cannot be changed until 1 second after the previous | ||
| /// change. This is to prevent malware from permanently hiding navigation buttons. | ||
| static Future<Null> restoreSystemUIOverlays() async { |
There was a problem hiding this comment.
we should use Future<void> rather than Future<Null>. (I believe you can make this change without it being a breaking API change, too.)
There was a problem hiding this comment.
Does this apply for the setSystemUIOverlays() also?
There was a problem hiding this comment.
Actually there seems to be many Future<Null> returns around here, I'll put it in as a separate PR.
|
tests? |
|
|
|
(How) Can we hook to the onHideEvent of the keyboard to call |
6 participants
We should both inform users that SystemChrome system UI elements may be force changed by the platform as well as provide a way to regain the desired UI overlays.
This adds the restoreSystemUIOverlays method to SystemChrome.
Pending changes on the engine side to implement functionality.