Skip to content
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

Support for camera cutouts #2264

Closed
wants to merge 9 commits into from

Conversation

@fercarcedo
Copy link
Contributor

@fercarcedo fercarcedo commented Mar 8, 2018

This PR fixes content overlapping with the status bar on devices with a camera cutout.

The fix consists of replacing the hardcoded 25dp values with the actual status bar height via the WindowInsets API.

Below you can find screenshots of before and after the change was made (taken from an Android P emulator thanks to P's notch simulation feature).

Before:
focus_cameracutout_before_1
focus_cameracutout_before_2
focus_cameracutout_before_3
focus_cameracutout_before_4

After:
focus_cameracuout_after_1
focus_cameracutout_after_2
focus_cameracutout_after_3
focus_cameracutout_after_4

#2047

@pocmo
Copy link
Contributor

@pocmo pocmo commented Mar 8, 2018

@pocmo
Copy link
Contributor

@pocmo pocmo commented Mar 8, 2018

I noticed two things while testing the patch:

  • The search hint seems to depend on the height too and is off now:

search-hint

  • When clicking on the URL to edit it, the input field is at the top first and then moves to the correct position with a delay. Is this something we can change? Maybe we need to delay the animation here until we know the height?

@pocmo
Copy link
Contributor

@pocmo pocmo commented Mar 8, 2018

Maybe we need to delay the animation here until we know the height?

Or pass the height to the other fragment (like we do with other coordinates for the animation)

Copy link
Contributor

@pocmo pocmo left a comment

See above

@pocmo
Copy link
Contributor

@pocmo pocmo commented Mar 8, 2018

ktlint found two issues:

/opt/focus-android/app/src/main/java/org/mozilla/focus/fragment/UrlInputFragment.kt:186:88: Unnecessary semicolon
/opt/focus-android/app/src/main/java/org/mozilla/focus/fragment/UrlInputFragment.kt:187:19: Unnecessary semicolon

@pocmo
Copy link
Contributor

@pocmo pocmo commented Mar 8, 2018

Other than that this looks pretty sweet! Thank you so far! :)

@fercarcedo
Copy link
Contributor Author

@fercarcedo fercarcedo commented Mar 8, 2018

I have solved both problems. For the second one (input field first at the top and then moves to the correct position) I have created a new class StatusBarUtils which caches the status bar height so that it isn't necessary to wait for the listener every time we need that value

@mozilla-mobile mozilla-mobile deleted a comment from fercarcedo Mar 8, 2018
pocmo
pocmo approved these changes Mar 8, 2018
/**
* Created by Fer on 08/03/2018.
*/

Copy link
Contributor

@pocmo pocmo Mar 8, 2018

Please remove this auto-generated comment :)

Copy link
Contributor Author

@fercarcedo fercarcedo Mar 8, 2018

Done

@@ -0,0 +1,31 @@
package org.mozilla.focus.utils;
Copy link
Contributor

@pocmo pocmo Mar 8, 2018

Please add our license header at the top of the file:

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

Copy link
Contributor Author

@fercarcedo fercarcedo Mar 8, 2018

Done

public WindowInsets onApplyWindowInsets(View v, WindowInsets insets) {
STATUS_BAR_SIZE = insets.getSystemWindowInsetTop();
listener.onStatusBarHeightFetched(STATUS_BAR_SIZE);
return insets;
Copy link
Contributor

@pocmo pocmo Mar 8, 2018

Is it required to remove the listener here again?

Copy link
Contributor Author

@fercarcedo fercarcedo Mar 8, 2018

I'm not sure if I'm understanding the question correctly, what this code does is if we don't have the status bar height cached it registers a listener and when it gets the status bar height saves it for later usage and sends it back to the caller.

Copy link
Contributor

@pocmo pocmo Mar 9, 2018

What I mean is: Should we call view.setOnApplyWindowInsetsListener(null) here once we got a value or do we need to stay subscribed?

Copy link
Contributor

@pocmo pocmo Mar 9, 2018

I was thinking of things like OnPreDrawListener where you explicitly clear the listener after receiving what you want. To avoid keeping strong references in memory.

Copy link
Contributor Author

@fercarcedo fercarcedo Mar 9, 2018

Yes, after all it's no longer needed, so why keep references to the listener (and thus to the Activity). Added on latest commit

pocmo
pocmo approved these changes Mar 9, 2018
Copy link
Contributor

@pocmo pocmo left a comment

This looks good! I'll give it a last try and land this.

@pocmo
Copy link
Contributor

@pocmo pocmo commented Mar 9, 2018

Thank you @fercarcedo! I landed this as a squashed commit: ba97314

@pocmo pocmo closed this Mar 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants