-
-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(web): inactive banner management 🎏 #9988
Conversation
User Test ResultsTest specification and instructions
Test Artifacts
|
alwaysShow: false, | ||
imagePath: "" | ||
} | ||
private _inactiveBanner: Banner; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the opposite of activeBanner
? The terms active and inactive here seem really ambiguous
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... yeah, I bumped up against that for a bit. Kind of makes me want to change the .activeBanner
to .currentBanner
.
It might be clearer if I also split BannerView
and BannerController
into separate files in the predecessor PR; .activeBanner
is only in the former, while .inactiveBanner
is only in the latter.
Of course, there's also the timeless classic question of "... why not both?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of the newly-pushed commits, I've implemented both thoughts from my comment above.
* Builds a banner for use when predictions are not active, supporting a more generalized | ||
* content pattern than ImageBanner via `innerHTML` specifications. | ||
*/ | ||
public readonly HTMLBanner = HTMLBanner; | ||
|
||
constructor(bannerView: BannerView, hostDevice: DeviceSpec, predictionContext?: PredictionContext) { | ||
// Step 1 - establish the container element. Must come before this.setOptions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this.setOptions
is now gone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. That paradigm started to feel really messy once I started adding in the HTML banner, especially since it obfuscates what properties are needed for which banner. Direct use of banner constructors is far, far clearer in that regard.
Note: once the Android "image banner" work is done, we should absolutely test it against Android 5.0 just to be sure everything does work as intended. That work isn't available here, hence the lack of test for it. |
Changes in this pull request will be available for download in Keyman version 17.0.212-alpha |
Accomplishes two goals:
HTMLBanner
type, which allows specifying banner contents to be injected viainnerHTML
property. For devices that support it, this will take place within an attached "shadow" for the banner in order to facilitate styling isolation.To set the new banner type in motion...
Once KeymanWeb has initialized, make a call like this:
(I used that in the Developer console of the "Predictive Text: robust testing" test page.)
Results:
The same banner will be continuously reused for the lifetime of the page unless replaced with a different assignment to
keyman.osk.bannerController.inactiveBanner
. (Except when predictive-text is active, of course.)User Testing
TEST_IOS_ALWAYS_SHOW: Using the iOS-based Keyman app, verify that the image banner still works as expected.
Note that step 7, then 8 is necessary due to #9990. That bug is not addressed by this PR; I just happened to discover it when writing this user test.