[TIMOB-1304] Android: Strange wrapping in TableView on Higher Res Screens

I vote +1 for fixing this!
Another example, KS -> Controls -> "Butto" with "n" wrapped

I think this is to do with auto-detecting the width. As a workaround, you can explicitly set a large enough width and the text won't wrap. Obviously, this is not ideal, though.

This is being worked on. It's a rounding error having to do with scaling and having int's instead of float in the API.

Thanks for the note, Don.
Another workaround is to change the fontsize. Increasing/decreasing by just one point can correct the problem

Sorry, mistake - I should not have re-assigned. Reassigning back to Marshall

(from [82d1161f123fb7a31699e07c8c76240471e46a4e]) grow the content area / auto generated label for tables, this fixes the text cutoff problem in higher-density devices [#1304 state:resolved] http://github.com/appcelerator/titanium_mobile/commit/82d1161f123fb7a31699e07c8c76240471e46a4e"> http://github.com/appcelerator/titanium_mobile/commit/82d1161f123fb...

Note: Using the latest Android build at http://builds.appcelerator.com.s3.amazonaws.com/mobile/mobilesdk-1.3.3-20100722034659-linux.zip"> http://builds.appcelerator.com.s3.amazonaws.com/mobile/mobilesdk-1....

Marshall
I'm afraid this bug is not completely fixed.

If you update the Kitchen Sink/Resources/examples/table_view_api_basic.js with the following code, you will see what I mean:
http://gist.github.com/485832">http://gist.github.com/485832

Cheers

Verified hal's test case.. The workaround I posted only really works in the "default" table view case, because it involves growing the content area of the default TableViewRow layout + The default label we create. AFAICT, This is still related to how fonts are measured when application scale is enabled, and looks very much like an actual Android bug.

Marshall, setting a static width for the container label could still cause the text to wrap in some cases where the margin between the text and the edge of the container is small. I feel when percentages for widths is working properly, it will allow a little bit of flexibility and flux to prevent this happening. Do you agree? Are percentages scheduled for the 1.5 release?

Full fix won't be ready in 1.4

Please, also have a look at labels within views. I have this issue there, too.

Jick

Marshall, the personable guy that he is, kindly explained to me via IRC that the issue of auto-sizing views within a tableviewrow is not so simple to resolve. Now I have some background, the reasons are more understandable. Here's the transcript:

    2010-07-22 16:01:12 <marshall_law>  hal: i'm not sure if there's a way to solve this one, other than forcing the label to be a larger size
    2010-07-22 16:01:36 <marshall_law>  in this case it's actually android that has the bug.. i worked around it by auto-growing the content area for default table views
    2010-07-22 16:01:55 <marshall_law>  the problem is when you start adding your own widgets, Titanium no longer controls the view group
    2010-07-22 16:02:14 <marshall_law>  so i could hack it, and force it to grow, but that isn't what you want either
    2010-07-22 16:02:21 <marshall_law>  because then it's the entire size of the row
    2010-07-22 16:02:27 <marshall_law>  you just want it to be the size of the text right?
    2010-07-22 16:02:42 <hal>   yes, I'd imagine so
    2010-07-22 16:04:29 <hal>   marshall_law: can the width of the label just depend on the size of the text?
    2010-07-22 16:05:04 <marshall_law>  hal: that's what it's trying to do already, the problem is the app scaling
    2010-07-22 16:04:47 <hal>   marshall_law: surely it already does that at the moment, with the height?
    2010-07-22 16:05:09 <marshall_law>  it's a bug in the scaling code
    2010-07-22 16:05:15 <marshall_law>  deep inside android, not public to me
    2010-07-22 16:05:24 <marshall_law>  i have to hack to even see the values they're playing with
    2010-07-22 16:04:42 <marshall_law>  so for now your best bet is to just manually size it.. there's a _ton_ of custom logic in TextView.layout that I'm afraid I won't be able to circumvent
    2010-07-22 16:05:42 <marshall_law>  hal: i wrote a mini blog post about it actually lol
    2010-07-22 16:05:43 <marshall_law>  http://www.arcaner.com/2010/07/20/querying-applicationscale-in-android/
    2010-07-22 16:05:46 <hal>   marshall_law: then the next course of action surely should be to escalate it to google. Does appcelerator have a direct support contact with them?
    2010-07-22 16:06:29 <marshall_law>  we have some contacts i'm not sure about support though. they don't support android like we do titanium that i'm aware of. we can open a bug though
    2010-07-22 16:06:50 <marshall_law>  i'd need to boil down the example to pure java / android
    2010-07-22 16:06:55 <marshall_law>  it might take me some time
    

Bearing in mind that there may not me a resolution soon, I think when dimensions in percentages work throughout the environment, they will provide a workaround to this in most situations.

The workaround for this is to use static sizes for now, with some supporting code to fix it in most cases. The root cause is android scaling (which can also be solved by setting anyDensity="false", and using Platform.displayCaps). Our new JSS support should also help alleviate density / resolution specific issues