Software Archive
Read-only legacy content
17061 Discussions

Debug and viewport

Brandt__Lars
New Contributor I
485 Views

I'm having a little problem with fonts being way to small on my Android phone when using debug via USB. 

The viewport meta tag seems to be ignored when using debug, and adding Intel Device plugin to use the "useViewport" method, results in an error when building the project debug module:

-compile:
    [javac] Compiling 38 source files to .../appanalyzer/platforms/android/bin/classes
    [javac] .../appanalyzer/platforms/android/src/com/intel/xdk/device/Device.java:179: error: cannot find symbol
    [javac]         final ViewGroup parent = (ViewGroup) webView.getEngine().getView().getParent();
    [javac]                                                     ^
    [javac]   symbol:   method getEngine()
    [javac]   location: variable webView of type CordovaWebView
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -Xlint:deprecation for details.
    [javac] Note: .../appanalyzer/platforms/android/src/org/apache/cordova/file/AssetFilesystem.java uses unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.
    [javac] 1 error

Is there a fix/workaround for this problem?

0 Kudos
7 Replies
PaulF_IntelCorp
Employee
485 Views

Take a look at the "Blank Cordova Starter App" for some comments in the index.html file regarding viewport settings. Do not use the intel.xdk plugins, those are being retired. Choose CLI 5.1.1 and Crosswalk 15 in your build settings.

0 Kudos
Brandt__Lars
New Contributor I
485 Views

Hi Paul F.

I have done some further testing and I' having a hard time reproducing the problem in a blank project, so maybe viewport is not the problem.

The fact is as follows:

 

Here is what it looks like if I make a build and install on the Android phone:

normal.png

 

Here is what it looks like if I debug via USB and App Preview:

small.png

The items are so small that they are hard to "click".

I don't know if I'm doing something wrong, but I do know that there must be some differences in the app container in the build system, and the app container in App Preview, and that the first mentioned works best for me (so keep it that way :-)

0 Kudos
PaulF_IntelCorp
Employee
485 Views

Can you send me a private message with a ZIP of the ENTIRE project? I'd like to see how it is setup. You can start a PM by clicking the "Send Author a Message" link on one of my posts in this thread. Attach files using the "attach media" button under the edit window, when you are writing the PM, or send me a link to a dropbox or onedrive, etc. location to download the ZIP.

0 Kudos
PaulF_IntelCorp
Employee
485 Views

Lars -- there is something goofy going on with regard to the viewport dimensions. Change this line in your additions.xml file to true:

  • <preference name="debuggable" value="true" />

And you can debug using Chrome and your USB and compare an app built for Android with an app built for Crosswalk (see this page for details on how to do that > https://software.intel.com/en-us/xdk/docs/intel-xdk-debug-and-test-overview#RemoteChromeDevTools <).

I'm having trouble figuring out what is causing this to happen, but if you inspect this line in your index.html file:

  • <div id="afui" class="android">

using remote CDT, after the app starts, you'll see what I mean. Compare the Android app to the Crosswalk app. You can also see the differences at the JavaScript console by checking the output of the following properties:

  • window.screen
  • document.documentElement.clientWidth and document.documentElement.clientHeight
  • window.innerWidth and window.innerHeight

and comparing the results between the Android build and the Crosswalk build. If you change the App ID for the Crosswalk build (for example, add .crosswalk to the end of it) you can build both versions (Android and Crosswalk) and install and run them simultaneously on your device and open up a remote CDT to each of them, so you can do side-by-side comparisons.

I'm suspecting either App Framework is doing something or one of your third-party plugins is doing something to cause this. So you could try removing your third-party plugins and changing the code so your initial screen does not depend on them, to see if that makes a difference. When I check those numbers inside of a Crosswalk app (for example, the hello cordova sample app) they come out as I would expect them to, so that leads me to believe it's either something about App Framework or something about the plugins, or some strange interaction between the two...

0 Kudos
PaulF_IntelCorp
Employee
485 Views

Lars -- I just tried with our new build system, which builds Crosswalk apps using a substantially different technique, and it is still failing but is no longer allowing me to see the starting screen, I'm getting an error due to a missing file (page.picture.inc.js) and a white screen. When I inspect the height and width values, I'm still not seeing the right values...

Are you delaying all interaction with the plugin APIs until after either the "deviceready" or "app.Ready" event? There's a lot of code there, and no easy way for me to confirm this. What I would suggest is that you build a very simple version of your app, using your plugins, to determine what is going on. There's too much there right now to clearly figure out what is causing the problem.

0 Kudos
PaulF_IntelCorp
Employee
485 Views

Lars -- here are some sample screens showing what you an do with remote CDT and two different versions of your built app on the same device. Both were open at the same time using the technique I pointed to in an earlier post.

First image shows the significant difference when built as Android, second shows same app, but built for Crosswalk, both are running on my phone. That > style="height: ###px" < attribute is being added to the <div> at runtime, and that is a symptom of the problem. Whatever is adding that attribute is getting bad values from the webview. You can check those numbers using the info from one of my previous posts. Why these numbers are being reported incorrectly is what is not clear to me. It could be related to what this user was experiencing with Firefox, where this needs to be delayed until a resize event is issued (see http://stackoverflow.com/questions/28402100/wrong-value-for-window-innerwidth-during-onload-event-in-firefox-for-android).

Screen Shot 2016-03-18 at 3.19.41 PM.png

Screen Shot 2016-03-18 at 3.21.57 PM.png

 

0 Kudos
PaulF_IntelCorp
Employee
485 Views

One clue, based on my observations from the images above, is that the width being reported, when hovering over that <div>, is 980px. This is the typical width of the "default viewport canvas" that is used to render pages that are assumed to be designed for a desktop, as opposed to those meant for a mobile screen. On some devices that "default viewport canvas" width might be reported as 800 (see http://tripleodeon.com/2011/12/first-understand-your-screen/). This implies to me that the <!DOCTYPE html> and/or <meta name="viewport" ...> tags are either getting overwritten or being ignored.

One thing to note is that you should not be using that target-densitydpi attribute, but removing it does not fix the problem (at least on my test device).

0 Kudos
Reply