|
|
Post by fnllc on Jul 24, 2017 15:20:21 GMT
I see that the android:targetSdkVersion is hard coded to API level 12 in AndroidManifest.erb.
Does it have to be 12 for Rhomobile to work? I would expect to be able to increase it by now.
<!-- Android SDK -->
<uses-sdk android:minSdkVersion='<%= @minSdkVer %>' android:targetSdkVersion='12'
<% if @maxSdkVer %>
android:maxSdkVersion='<%= @maxSdkVer %>'
<% end %>
/>
|
|
|
|
Post by Alex Epifanov on Jul 24, 2017 23:51:58 GMT
it is default minimum value. You can override it with your custom manifest. Some extensions increase minSdk as well.
|
|
|
|
Post by fnllc on Jul 25, 2017 20:07:02 GMT
I tried to change it to API level 23, the same as minSdkVer, but the jquery mobile interface became very small.
|
|
|
|
Post by Alex Epifanov on Jul 26, 2017 17:36:52 GMT
can you pls provide an app sample to reproduce this.
|
|
|
|
Post by jontara on Jul 26, 2017 20:07:03 GMT
I have observed the same problem, though I don't use jQuery Mobile. I've been using a work-around.
I just did some experiments. The problem occurs if you set android:targetSdkVersion > 18. I had been setting it to 23.
In that case, the WebView pixels are mapped 1:1 with real device pixels. If you set targetSdkVersion to 18 or less, you will get the expected behavior where the WebView uses virtual pixels which are some divisor of real pixels.
I guess that there was some change in the default behavior of the WebView introduced in SDK version 19.
While 1:1 mapping of WebView pixels to real device pixels might actually be desirable in some ways, the vast majority of existing CSS and JS code written for web browsers would likely be broken by it.
So, I think the default behavior for Rhodes should be to use virtual pixels rather than real for the WebView.
But, of course, it is still fine, so long as you don't monkey with targetSdkVersion!
I don't have a complete understanding of targetSdkVersion vs. minSdkVer. But I gather that minSdkVer determines whether the app can even be installed or not. targetSdkVersion determines whether Android enables compatibility features, in order to allow apps written for older versions to run without behavior changes.
So, one of the compatibility features must be to maintain the virtual pixel mapping for webviews.
Hopefully, it is just a change of default, so that perhaps Rhodes could still set the WebView in virtual pixel mode. It would be nice if there were a setting to control this, as some developers may have already written code that depends on the new behavior (or that works-around it).
As a work-around, I've been using this in AppApplication.rb (note that I run my Ruby source files through Mustache before build. The ^android? is included for non-android builds, the #android? is included for Android builds...)
def self.rootFontSize
{{^android?}}
root_font_percent = 100.0
{{/android?}}
{{#android?}}
is_portrait = System.screenOrientation == Rho::System::SCREEN_PORTRAIT
# on some Android devices, portrait height might not equal
# landscape width! So, always use pixel ratio across the
# short axis. (No we don't check for length of axis... just making an assumption)
if System.screenOrientation == Rho::System::SCREEN_PORTRAIT
pixel_ratio = System.realScreenWidth.to_f / System.screenWidth.to_f
else
pixel_ratio = System.realScreenHeight.to_f / System.screenHeight.to_f
end
root_font_percent = pixel_ratio * 100.0
{{/android?}}
return "#{root_font_percent}%"
end
Then:
<html style='font-size:#{AppApplication.rootFontSize};'>
in layout.erb.
But that is an ugly work-around, and I think it has some undesirable side-effects. (I am going to do some testing now with the targetSdkVersion lowered.)
|
|
|
|
Post by jontara on Jul 26, 2017 20:47:30 GMT
See: developer.android.com/guide/webapps/migrating.htmlIn particular: At first glance, this seems backward to observed behavior. But I would guess that Rhodes is assuming Android < 19, and makes adjustments itself to WebView parameters so that the WebView works in CSS pixels. In fact, I recall from a long time ago (years!) that this was a bug that was corrected. That is, Rhodes had 1:1 mapping to device pixels, and there was some commit that corrected that. But now if you set targetSdkVersion to 19 or higher, it takes the WebView out of quirks mode, and now the Rhodes "correction" is inappropriate. I think generally, for the vast majority of Rhodes apps being created to day, it would be best to be able to take the WebView out of quirks mode! I think Rhodes should look at t argetSdkVersion and adjust it's setup of the WebView accordingly. |
|
|
|
Post by jontara on Nov 3, 2017 19:04:08 GMT
This has been fixed in current 6-0-stable branch. Not sure if this is in a released version yet.
The problem with the device pixel scaling has been fixed. And there is a new entry in build.yml. These are my current settings:
minSDK: '23' # Note: minimum possible SDK is 14 for Rhodes 5.1
#maxSDK: '26'
targetSDK: '25'
I had previously been setting targetSDK to 19 as a work-around to the scaling issue.
You will have to change AndroidManifest.erb:
<uses-sdk android:minSdkVersion='<%= @minsdkver %>' android:targetSdkVersion='<%= @targetsdkver %>'
minSDK and maxSDK are the min and max SDK the OS will allow the app to install on.
targetSDK is meant as "highest SDK level you have tested at". So, the OS will use adaptive behavior if installed on a higher version.
I checked the source code, and the above build.yml keys are correct as shown above (and have tested this). It might be confusing looking at AndroidManifest, as there are somewhat different key names both in the XML key and the Ruby instance variables used to populate them...
|
|
|
|
Post by fnllc on Nov 6, 2017 20:41:57 GMT
Thanks for the tip. Wath out, the @targetsdkver is case sensitive. It would not work for me using @targetsdkver.
FYI: If you are still on JQM 1.4, setting targetSdkVer > 18 introduces weird artifacts on page transitions.
|
|
|
|
Post by jontara on Nov 8, 2017 3:55:00 GMT
Unfortunately, JQM is seriously in need of an update! It only supports through iOS 9. So, it is surely just as out of date for Android. Don't know about 1.5 alpha.
Setting a lower targetSdkVer puts the webview in quirks mode and makes it compatible.
I just use Bootstrap now (4.0 beta).
|
|
|
|
Post by fnllc on Nov 10, 2017 0:30:33 GMT
I know JQM is outdated sadly. I'm considering giving OnsenUI a try.
|
|
