- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Tags:
- HTML5
- Intel® XDK
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
Here is what it looks like if I debug via USB and App Preview:
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 :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
![](/skins/images/7B0AB6865064EAE32B30EC9A4E94B48A/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page