Problem with DeviceHeight on newer devices

Monkey Targets Forums/Android/Problem with DeviceHeight on newer devices

Xaron

(Posted 2014) [#1]

Dear all,

I stumbled across a strange problem. Look at the screenshot below:

You see the Admob ad is above the playfield but should be below. The problem is that the DeviceHeight returns a height which includes the soft (touch) buttons on the Android screen so it calculates the space for the banner wrong. But the banner view itself is at the correct place.

Any idea to solve that?

Gerry Quinn

(Posted 2014) [#2]

I wrote some code in another thread to get screen density, but it can get any default metrics for the app. Does this help?


'In diddy.externfunctions:
	#If TARGET="android" Then
		Function GetLogicalDensity:Float() = "diddy.getLogicalDensity"
	#End


// At top of diddy.android.java
import android.view.Display;
import android.view.Window;
import android.view.WindowManager;
import android.content.Context;
import android.util.DisplayMetrics;

// In diddy class of diddy.android.java
	static float getLogicalDensity()
	{
	 	   DisplayMetrics metrics = new DisplayMetrics();
 		   BBAndroidGame._androidGame._activity.getWindowManager().getDefaultDisplay().getMetrics( metrics );
		   return metrics.density;
	}

Of course, you may be about to post saying you forgot to subtract the ad height when calculating your app metrics ;-)

EDIT: a quick google suggests that getDefaultMetrics.getWidth() is deprecated and on newer devices you are supposed to use some sort of getSize function. Maybe that particular chicken has just come home to roost, in which case mojo will need to be modified to use the correct function depending on Android version.

Xaron

(Posted 2014) [#3]

Thanks, I'll check it out. Seems to be a common problem as you only get the physical size of the device but NOT the real one until the view itself is created.

A nice workaround might be this one: http://www.codeproject.com/Tips/313848/Get-actual-screen-size-for-the-application-layout

Xaron

(Posted 2014) [#4]

Thanks again Gerry,

you pointed me in the right direction.

The monkey interface:

Import "native/xutils.${TARGET}.${LANG}"

Extern

Function GetWindowHeight:Int() = "XUtils.getWindowHeight"

The native code (got quite complicated but works for BOTH old and new SDK):

import android.view.Display;
import android.view.Window;
import android.view.WindowManager;
import android.content.Context;
import android.util.DisplayMetrics;

class XUtils
{
  static int getWindowHeight()
  {
    Display display = BBAndroidGame._androidGame._activity.getWindowManager().getDefaultDisplay();
    DisplayMetrics metrics = new DisplayMetrics();
    display.getMetrics( metrics );
  
    int heightPixels = metrics.heightPixels;
    // includes window decorations (statusbar bar/menu bar)
    if( Build.VERSION.SDK_INT >= 14 && Build.VERSION.SDK_INT < 17 )
    {
      try
      {
        heightPixels = (Integer)Display.class.getMethod( "getRawHeight" ).invoke( display );
      }
      catch( Exception ignored )
      {
      }
    }
    // includes window decorations (statusbar bar/menu bar)
    else if( Build.VERSION.SDK_INT >= 17 )
    {
      try
      {
        Point realSize = new Point();
        Display.class.getMethod( "getRealSize", Point.class ).invoke( display, realSize );
        heightPixels = realSize.y;
      }
      catch( Exception ignored )
      {
      }
    }
    return heightPixels;
  }
}

dragon

(Posted 2014) [#5]

that should be fixed in monkey!

therevills

(Posted 2014) [#6]

Maybe raise a post in the bugs forum....

Xaron

(Posted 2014) [#7]

Well not necessarily as DeviceHeight() returns the physical screen size which is correct. But there should maybe an additional command ViewHeight() (and width) which returns the view size. On all other platforms this could just return DeviceHeight().

Anyway, posted a bug.

Gerry Quinn

(Posted 2014) [#8]

I agree it should be considered a bug. You can't get rid of the menu using Monkey anyway, so the effective height is the height without it.

Xaron's solution seems good.

If the behaviour is changing on new devices, I guess we'll soon be seeing complaints popping up everywhere Androids are programmed.

dragon

(Posted 2014) [#9]

is it possible to disable this virtual keys?

Xaron

(Posted 2014) [#10]

Ähm, wie meinen? (short translation: WTF?! :D virtual keys? How do you mean that?)

therevills

(Posted 2014) [#11]

I think he means the "soft" keys which are covering the display - if so, no... you can hide the icons somehow but you can not remove or disable them. As what would happen if you game hangs and the user wants to quit or move applications...

marksibly

(Posted 2014) [#12]

As far as I can tell, DeviceHeight() *is* returning view height - please see my reply to bug report.

Supertino

(Posted 2014) [#13]

Might be off topic but has anything changed in 4.4 due to 'immerse mode'? http://www.droid-life.com/2013/12/19/a-list-of-apps-that-support-android-4-4-kit-kat-immersive-mode/

Ironstorm

(Posted 2014) [#14]

is it possible to disable this virtual keys?

Yeah. Just set

android:targetSdkVersion="14"

to 14.
This is as far as I know the only way to deactivate the software menu buttons.

I've mentioned this a few times. For example here