Android and/or HTC Sense Wonkiness

[Cameron Perry]

How many people have experienced strange behavior in their Android apps? Specifically, I'm seeing all sorts of weird behaviors with form fields on my HTC Incredible (Froyo/2.2) where form fields show up twice on the screen - one where they're supposed to, and one somewhere above & overlaying other content. My issues are occurring on a Sencha Touch app, but even using native HTML forms in the Sencha app I still see problems.

I'm wondering if anyone has any insights on fixing this problem.

-- OR --

Is there a way to prevent the PhoneGap app from running on specific devices or versions of Android. You know, "Sorry, this device does not meet the requirements for this app" type thing.

Thanks,
Cameron

[Michael Herger]

> How many people have experienced strange behavior in their Android apps?
> Specifically, I'm seeing all sorts of weird behaviors with form fields
> on my HTC Incredible (Froyo/2.2) where form fields show up twice on the
> screen - one where they're supposed to, and one somewhere above &
> overlaying other content. My issues are occurring on a Sencha Touch app,
> but even using native HTML forms in the Sencha app I still see problems.

I think I've seen similar issues in the past, but not recently. Are you
using a Sencha layout & form?

One of their devs at some point mentioned HTC to be the most webapp
unfriendly Android phones available, as HTC did a lot of customization to
that code. In the beginning it was so bad that even the Kitchen Sink would
totally lock up on my HTC Desire. It has improved a lot in 1.0+ though.

> Is there a way to prevent the PhoneGap app from running on specific
> devices or versions of Android.

I'm not sure about the granularity of this approach. You can filter by
Android _version_. But in my experience there can be a Galaxy S running
Android 2.1 which runs fine, and another one with the same name and OS
version which is reporting bad screen resolution parameters, causing all
kinds of oddities. Steve J. is a crazy control freak. But it comes with
certain advantages.

--

Michael

[Cameron Perry]

I've tried both Sencha-generated forms as well as sticking plain HTML forms in panel content { html : '<form...> ... </form>' } with more or less duplicate results. Further detective work didn't produce anything useful. Coloring the form container divs and form element backgrounds produced expected results, but text entry appeared white, which as one of the devs (same guy?) put it - is outside of the browser's scope. It's pretty hideous.

I also had the same problems with Kitchen Sink as you did, and yeah - thankfully it's a lot better on about 99% of the code. It's just the 1% that will get you and a vast number of Android users.

I'm not bothered by most of Apple's control freak behavior. I mean, iOS runs UIWebView apps beautifully, which can't be said for Android as a whole. Heck - it's not even a WebView thing as much as it's an overall user experience. It's my experience that iOS apps are generally better than Android apps, and a lot has to do with the OS. Reminds me of the 90's when software had all sorts of specific hardware & driver requirements. Only now you can't do anything about it but ditch the phone for a different one.

Anyway, we're going to be handing over the code to some clients this week, so we'll see what they say. We preempted the whole project knowing that Android didn't quite have the same support as iOS and some features might be missing. I just never thought the app login form would be not just the first users see, but the one thing keeping people from using it. 

Thanks for confirming what I already suspected :)

~Cameron

--
You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to
phonegap+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en

For more info on PhoneGap or to download the code go to www.phonegap.com

-------

Cameron Perry

Co-founder

Pivotal Action, Inc.

www.PivotalAction.com

[Robert Fletcher]

If i publish or target my app for 2.2 and let's say I get my app published to the Android Market and then let's say someone has an Android phone that is running v2.1 (an earlier version of android that i have targeted) -- when they go to the Android Market, will they see my app if they search for it?

I would think that the Android Market would filter out apps that aren't for your version of the OS.

I hope that is how it works because I am not planning on going too far back. probably to 2.1 update 1.

Rob 

[Michael Herger]

> I would think that the Android Market would filter out apps that aren't
> for your version of the OS.

Yes, that's true. But unfortunately Android 2.1/Vendor A != Android
2.1/Vendor B.

We have one particular case (Galaxy/Android 2.1/Sprint) which does report
its native resolution with a devicePixelRatio of 1.5. That's wrong, and
I've only seen this on this particular device. And it's causing all kinds
of layout issues. All other devices (Android 2.1/2.2/2.3) report the
native resolution divided by the devicePixelRatio. It'll be interesting to
get a handle on that phone. Don't know yet whether it's Android,
PhoneGap, Sencha or whatever else which is wrong there...

--

Michael

[Horst]

I had the same problems. Double input fields with my HTC Desire and a
very, very slow app on a ZTE Blade. I think because 2.1 (on the Blade)
has a very slow javascript engine.
Both phones have 800x480 Pixel display, but different density values.
So i had funny effects.

My solution was buying a mac and develop for this. ;-)
Ohh, and i have changed my apps. No input fields are used now.

I would prefer if i can filter my apps in the market. I dont want run
it on screens smaller than 320x480. But this is not possible. You can
set small_screens to false, but there also bigger screens with lower
resolution.

best regards
Horst

[Cameron Perry]

Horst,

What JS library were you using? (I don't know if that even matters)

~Cameron

--
You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to
phonegap+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en

For more info on PhoneGap or to download the code go to www.phonegap.com

[Michael Herger]

> I had the same problems. Double input fields with my HTC Desire and a
> very, very slow app on a ZTE Blade. I think because 2.1 (on the Blade)
> has a very slow javascript engine.
> Both phones have 800x480 Pixel display, but different density values.
> So i had funny effects.

Heh... that's exactly the issue I'm seeing on that other phone. Did one of
them report native 800x480 with a ratio of 1.5? If so which one? Is the
HTC running 2.2?

--

Michael

[Horst]

@Cameron:
No JS library.

@Michael:
Yes, the HTC runs 2.2. One report 1 and the other 1.5. Sorry, i cant
test which was which at the moment. I have used window.innerHeight and
window.innerWidth to get absolute pixel values and placed all stuff
depending on this.

Sometimes i had the feeling that the HTC remembers the position of the
elements at creation time and paints the highlighting (when touching
or use trackball) at this position and dont check, that the element
has an other position when ready with rendering. But this is more a
feeling. With the ZTE this was no problem. I think this is some
special from sense, because the highlighting on the HTC is green
instead of yellow android default.

I had some similar issues with the admob ad code. But this is because
it admob use some funny methods to find the place for rendering.

best regards
Horst

[Michael Herger]

Horst,

> Yes, the HTC runs 2.2. One report 1 and the other 1.5. Sorry, i cant
> test which was which at the moment.

Would be great if you could tell me later. I should investigate a related
issue which we've only seen on a device by the US' Sprint operator. If the
ZTE was exposing the same issue I could get one for cheap over here
(Switzerland) to play with.

--

Michael

[B. K.]

> How many people have experienced strange behavior in their Android apps? Specifically, I'm seeing all sorts of weird behaviors with form fields on my HTC Incredible (Froyo/2.2) where form fields show up twice on the screen - one where they're supposed to, and one somewhere above & overlaying other content. My issues are occurring on a Sencha Touch app, but even using native HTML forms in the Sencha app I still see problems.
>
> I'm wondering if anyone has any insights on fixing this problem.
>

I ran in this problem with HTC devices too. I have developed an App
with PhoneGap and jQueryMobile alpha.
My input fields was placed in an popup.

The solution:
Popup container has position absolute and is not visible on page
start. I have positioned this container to top: -500px.
The position of the popup will be computed on show:
$(input).css("top", ((screen.height - this.oWindow.outerHeight()) / (3
* 2)) + "px")

As Horst wrote: it seems, that HTC remembers the position of rendered
(and not visible too!) inputs and does not recalculate it on focus
given to those fields. Unless the particular filed's position was
outer visible space.

Now HTC generates his own field duplicates on the correct position.
To bad, that it is allways white with dark blue borders - this
"design" does not fit my CSS...

--
Borys

[Valtteri Virtanen]

Setting input-element's css property display to block fixed the issue.

- Valtteri

[Andi]

Hi all,
I am also having probs with the default style of Sencha (or Android)
for the text inputs and password fields, it works ok on iOS devices
and on some android devices, but HTC and others put their awful
default style which i can nohow change. Because of that all the layout
looks very awful.... see please the link http://clip2net.com/s/1ICId
Please if any of you has any suggestion how it is possible to hide i
would be very grateful!!
here is all i have tried for that
input {
background: transparent !important;
border: 0 transparent !important;
-webkit-appearance: none;
}
input[type=text] {
background: transparent !important;
border: 0 transparent !important;
-webkit-appearance: none;
}
input:-webkit-autofill {
color: transparent !important;
background-color: transparent !important;
}
input:focus{
outline:none;
background: transparent !important;
border-color: transparent !important;
-webkit-focus-ring-color: transparent;
}

[Kerri Shotts]

How are you getting that to compile? The documentation I've found doesn't indicate adjustNothing is even valid; you have adjustPan and adjustResize.

adjustPan might do what we're after, though in my app, it freaks out big time on a full-screen textarea.

HTC Sense is annoying.... *sigh*

On Wednesday, July 4, 2012 11:35:43 AM UTC-5, Eldaoron wrote:

In case someone else is still having the problem, I find out that in my case the line

android:windowSoftInputMode="adjustNothing"

on my activity fixed all the problems I was having

The problem is due a misscalculation between where the element was when the page loaded and where it is now.