Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

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

GitHub Issuen/a
Resolution Date2011-04-17T01:55:48.000+0000
Affected Version/sn/a
Fix Version/sRelease 1.5.0
Labelsandroid, defect
ReporterDon Thorp
AssigneeMarshall Culpepper


On the N1 the controls tab exhibits the problem.

See http://developer.appcelerator.com/question/38981/wrap-bug-in-labels--tableview"> Q&A for more information.


base UI>Views>Table Views (Go to P and see Pari with s on next line)


  1. hal 2011-04-15

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

  2. hal 2011-04-15

    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.

  3. Don Thorp 2011-04-15

    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.

  4. hal 2011-04-15

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

  5. hal 2011-04-15

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

  6. Marshall Culpepper 2011-04-15

    (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...

  7. hal 2011-04-15

    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....

    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:


  8. Marshall Culpepper 2011-04-15

    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.

  9. hal 2011-04-15

    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?

  10. Don Thorp 2011-04-15

    Full fix won't be ready in 1.4

  11. Jick Steen 2011-04-15

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

  12. hal 2011-04-15


    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.

  13. Marshall Culpepper 2011-04-15

    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

JSON Source