Surface Duo Reports Wrong Value For GetWindowVisibleDisplayFrame

Question

Surface Duo Reports Wrong Value For GetWindowVisibleDisplayFrame

Nathan Sokalski 4,111

I have an app in which I need to know the height of the visible usable area. To do this, I use the following code:

Rect visiblebounds = new Rect();  
this.dlRoot.GetWindowVisibleDisplayFrame(visiblebounds);

I debugged my app on the following:

Emulator in Visual Studio (API 29)
Samsung Galaxy S10e (API 30)
Surface Duo Emulator (API 29)
Surface Duo (API 29)

Here are screenshots from the first three of these (the physical Surface Duo did the same as the emulator, so I did not bother with a screenshot from that, I also cropped off the second screen from the Surface Duo Emulator screenshot since the app is only running on one screen):

166942-screenshot-20220120-142151-golf-scorekeeper-experi.jpg

Notice that the Emulator in Visual Studio & Samsung Galaxy S10e have API 29 & API 30, so this shows that the problem is not the API. Why is the Surface Duo giving an incorrect value for GetWindowVisibleDisplayFrame?

JarvanZhang 23,971 Reputation points

2022-01-21T06:33:03.187+00:00

Surface Duo Reports Wrong Value For GetWindowVisibleDisplayFrame... I have an app in which I need to know the height of the visible usable area.

Hi, njsokalski. When building the project on devices with different sizes, the result of GetWindowVisibleDisplayFrame command will be different. I created a basic page layout to get the frame on three emulators, the value are not the same.
Nathan Sokalski 4,111 Reputation points

2022-01-21T18:27:56.967+00:00
I understand that the value will not be the same, which is why we get the value from the method (rather than a constant). I calculate the height of the RecyclerView using the following:

this.rvPlayerNamesInput.LayoutParameters.Height = visiblebounds.Height() - this.tbNavigation.Height - this.txtPlayerNames.Height - (this.txtPlayerNames.LayoutParameters as GridLayout.LayoutParams).BottomMargin;

(NOTE: In case you couldn't figure it out, tbNavigation is the green area, and txtPlayerNames is the text.) This worked for the first two (Emulator in Visual Studio & Samsung Galaxy S10e), even though they are different sizes, so why not Surface Duo? Do I need to do something else to include the size of the status bar (I noticed that the first two have much bigger status bars than the Surface Duo)?
JarvanZhang 23,971 Reputation points

2022-01-24T08:36:48.213+00:00
Do I need to do something else to include the size of the status bar (I noticed that the first two have much bigger status bars than the Surface Duo)

The height value of the status bar is the same on Android devices, the value is 24 dp. It will be different if converting the value to pixels. Here is the following code, you could test to check it.

int idStatusBarHeight = Resources.GetIdentifier("status_bar_height", "dimen", "android"); var statusHeight = idStatusBarHeight > 0 ? Resources.GetDimensionPixelSize(idStatusBarHeight) / Resources.DisplayMetrics.Density : 0;

I calculate the height of the RecyclerView using the following

The result of the code is in pixel, the value will be different on different devices. How do you define the size of these controls like 'tbNavigation'? Do you set the height proportionally? If so, try converting the resulting value to dp units and compare.
Nathan Sokalski 4,111 Reputation points

2022-01-24T17:32:13.827+00:00
The size of tbNavigation is defined as follows:

android:layout_width="match_parent" android:layout_height="48dp"

I also now noticed something very strange that happens when scrolling. If I do the following:

Tap one of the EditText(s) to select it (this opens the keyboard and incorrectly resizes the RecyclerView)

Scroll until the selected EditText is offscreen (this causes the top row of the keyboard (the numbers) to disappear)

Tap one of the visible EditText(s) (this correctly resizes the RecyclerView)

Start typing or tap another visible EditText (this incorrectly resizes the RecyclerView)

Also, at certain points the keyboard shows or hides the top row of keys (the numbers). I am wondering if the problem has something to do with Swiftkey changing the keyboard height (showing & hiding the numbers, or maybe even something else) and causing that to report incorrect values for GetWindowVisibleDisplayFrame. It is very interesting that the top row of keys changes at all, since all the EditText(s) would display the same keyboard options (they all come from the same item layout in the RecyclerView). Is it possible that Swiftkey is causing the problem?
JarvanZhang 23,971 Reputation points

2022-01-25T08:17:45.527+00:00

Is it possible that Swiftkey is causing the problem

GetWindowVisibleDisplayFrame method retrieves the overall visible display size in which the window this view is attached to has been positioned in. The value will be different if the keyboard pops up. You could close the keyboard and then get the value. However, the result may still not be the same on the three devices.

Your answer

JarvanZhang 23,971 Reputation points

2022-01-21T06:33:03.187+00:00

Surface Duo Reports Wrong Value For GetWindowVisibleDisplayFrame... I have an app in which I need to know the height of the visible usable area.

Hi, njsokalski. When building the project on devices with different sizes, the result of GetWindowVisibleDisplayFrame command will be different. I created a basic page layout to get the frame on three emulators, the value are not the same.
Nathan Sokalski 4,111 Reputation points

2022-01-21T18:27:56.967+00:00

I understand that the value will not be the same, which is why we get the value from the method (rather than a constant). I calculate the height of the RecyclerView using the following:

this.rvPlayerNamesInput.LayoutParameters.Height = visiblebounds.Height() - this.tbNavigation.Height - this.txtPlayerNames.Height - (this.txtPlayerNames.LayoutParameters as GridLayout.LayoutParams).BottomMargin;

(NOTE: In case you couldn't figure it out, tbNavigation is the green area, and txtPlayerNames is the text.) This worked for the first two (Emulator in Visual Studio & Samsung Galaxy S10e), even though they are different sizes, so why not Surface Duo? Do I need to do something else to include the size of the status bar (I noticed that the first two have much bigger status bars than the Surface Duo)?
JarvanZhang 23,971 Reputation points

2022-01-24T08:36:48.213+00:00

Do I need to do something else to include the size of the status bar (I noticed that the first two have much bigger status bars than the Surface Duo)

The height value of the status bar is the same on Android devices, the value is 24 dp. It will be different if converting the value to pixels. Here is the following code, you could test to check it.

int idStatusBarHeight = Resources.GetIdentifier("status_bar_height", "dimen", "android"); var statusHeight = idStatusBarHeight > 0 ? Resources.GetDimensionPixelSize(idStatusBarHeight) / Resources.DisplayMetrics.Density : 0;

I calculate the height of the RecyclerView using the following

The result of the code is in pixel, the value will be different on different devices. How do you define the size of these controls like 'tbNavigation'? Do you set the height proportionally? If so, try converting the resulting value to dp units and compare.
Nathan Sokalski 4,111 Reputation points

2022-01-24T17:32:13.827+00:00

The size of tbNavigation is defined as follows:

android:layout_width="match_parent" android:layout_height="48dp"

I also now noticed something very strange that happens when scrolling. If I do the following:

Tap one of the EditText(s) to select it (this opens the keyboard and incorrectly resizes the RecyclerView)

Scroll until the selected EditText is offscreen (this causes the top row of the keyboard (the numbers) to disappear)

Tap one of the visible EditText(s) (this correctly resizes the RecyclerView)

Start typing or tap another visible EditText (this incorrectly resizes the RecyclerView)

Also, at certain points the keyboard shows or hides the top row of keys (the numbers). I am wondering if the problem has something to do with Swiftkey changing the keyboard height (showing & hiding the numbers, or maybe even something else) and causing that to report incorrect values for GetWindowVisibleDisplayFrame. It is very interesting that the top row of keys changes at all, since all the EditText(s) would display the same keyboard options (they all come from the same item layout in the RecyclerView). Is it possible that Swiftkey is causing the problem?
JarvanZhang 23,971 Reputation points

2022-01-25T08:17:45.527+00:00

Is it possible that Swiftkey is causing the problem

GetWindowVisibleDisplayFrame method retrieves the overall visible display size in which the window this view is attached to has been positioned in. The value will be different if the keyboard pops up. You could close the keyboard and then get the value. However, the result may still not be the same on the three devices.

Share via

Surface Duo Reports Wrong Value For GetWindowVisibleDisplayFrame

Your answer