|Shopping list items view layout, issue 340||aap||12/4/11 9:24 PM|
GCI student Shuhao is working on issue 340, and suggests that we revisit our complete reliance on RelativeLayout for the list item rows. I should have redirected our discussion to this forum hours ago, but better late then never I guess. Shuhao is considering using a LinearLayout within the RelativeLayout for the items which appear mostly on the first row of the RelativeLayout, meaning (I think) priority, quantity, item name, and has_note.
The general consensus in various blog postings seems to be that putting LinearLayouts inside RelativeLayouts may not give the best performance. On the other hand it seems that our RelativeLayout is too complicated, leading to the note problem described in issue 340 but also some overlapping fields sometimes. There is a chance that the complexity of our RelativeLayout may be just as bad performance-wise as nesting a single LinearLayout would be. So Shuhao is going to give the LinearLayout a try and we will see whether the performance impact is an issue or not. If it does make things slow we might have to think some more about whether there is a way to fix the RelativeLayout without nesting a LinearLayout.
The discussion so far can be found on the GCI task here.
(As an aside, the complexity of the RelativeLayout is one reason I haven't added due date support yet, along with date import from HandyShopper in OI Convert CSV.)
|Re: Shopping list items view layout, issue 340||Peli||12/5/11 1:53 AM|
I agree with you - RelativeLayout does not really work well if some of
the items' visibility are set to GONE.
I could throw in one more possible solution:
The main advantage is that this will work in all cases (because it can
The downside of this approach is that this does not scale well at all,
Devices get faster and faster, so I'd opt for the slower but more
(Anyway the performance impact by changing layouts should scale with
On Dec 5, 6:24 am, aap <aa...@peromsik.net> wrote:
> The discussion so far can be found on the GCI task here<http://www.google-melange.com/gci/task/view/google/gci2011/7137283>
|Re: Shopping list items view layout, issue 340||Shuhao||12/6/11 4:42 PM|
> one RelativeLayout when there is priority, text, and note
That causes the original problem. As when text wraps, notes gets pushed off the screen.
|Re: Shopping list items view layout, issue 340||aap||12/6/11 4:48 PM|
The difference would be that if we knew that flavor of the layout would be used only when all those fields were really active, we might assign the dependencies in such a way that the note would be sure to appear. Your original approach probably would have worked if we carried it further and considered all the fields... the only reason we didn't try, if I understand correctly, is because of the View.GONE problem.
Maintaining separate flavors of the layout would be a pain, but we could achieve the same thing with more upfront work by building the layout in the code instead of XML.
Hopefully we won't have to go there, if your LinearLayout approach turns out to be fast enough.
On Tue, Dec 6, 2011 at 7:42 PM, Shuhao <ad...@thekks.net> wrote:
|Re: Shopping list items view layout, issue 340||Shuhao||12/7/11 3:01 PM|
What should the shopping list look like with the all the options filled? I'm getting something like this. Doesn't seem like the correct way to display it, also having trouble positioning the elements as well.
God I hate Android UI
|Re: Shopping list items view layout, issue 340||aap||12/7/11 4:44 PM|
That doesn't look so terrible, relative to the existing display anyway. I could upload some existing screenshots when I get home, or perhaps you could just download the official build into a separate emulator instance and see how it behaves with the same data.
Did you add any priorities on these items? I don't see them in the display. Also, does the "some item that has a long name" item have a note? If not, you might add one to see if the icon shows up now.
|Re: Shopping list items view layout, issue 340||Shuhao||12/7/11 4:46 PM|
I tried to add priority, same thing, it also has notes
|Re: Shopping list items view layout, issue 340||aap||12/7/11 5:09 PM|
In that case, it seems that either the layout or the code needs to be fixed to show priority, and it also seems like this approach didn't yet help with the original goal of keeping the note on the screen when the item description is long.
|Re: Shopping list items view layout, issue 340||Shuhao||12/7/11 5:09 PM|
What about scrolling, when the item gets too big?
|Re: Shopping list items view layout, issue 340||aap||12/7/11 6:33 PM|
Are you suggesting that the item should still take up one line, but the item description should scroll through the available space like an animated sign? Sounds distracting.
If you were suggesting something else, please clarify.
I would expect a normal user who had long items like that would abbreviate somewhat and use a smaller font size. It would not be normal to have a list with many items that occupy five or six lines. But wrapping onto a second line for some items is normal enough, and it would be nice not to lose the note icon in that case.
|Re: Shopping list items view layout, issue 340||Peli||12/10/11 2:26 AM|
To add another possible solution to the problem of long item names:
In some previous version of OI Shopping List, "quantity+unit+item" were concatenated and printed in a single TextView. This solves the problem of wrapping, because the wraped text would fill the whole width for all lines.
The problem is that currently tapping on "quantity" or "unit" opens the quick edit mode or the edit dialog with focus on those fields, so this functionality should not be lost.
One way out could be to "measure" (using something like Paint.measureText())  the text size of the quantity and unit strings, and manually intercept any clicks within the TextView to test whether one of those fields was clicked. I think in this way, both advantages could be combined (word wrapping and individual click targets).
|Re: Shopping list items view layout, issue 340||aap||12/11/11 6:05 PM|
Trying to compute which word was clicked within a single TextView sounds like it could probably work, but it probably would be difficult to get it exactly right. Also that approach does not help with the note indicator, unless we find some glyph to take the place of the current icon and make sure it is defined in all the fonts we use for different themes.
Perhaps a similar effect could be achieved by positioning the item name TextView as if the priority, quantity, and units were not there, but inserting some number of spaces in the beginning of the text of the TextView to leave space for them. Then we could position those views relative to each other and the TextView.
As far as the note icon goes, it should be relatively straightforward to apply similar logic to show it on the right of the space reserved for the item name, perhaps adding a few spaces to the end of the TextView to leave room for the note. (Would that make the TextView expand to a second line when necessary?) It would be more complicated to make the note's view show up near the end of the text on the last line of the item name TextView-- but perhaps not impossible. Perhaps the has_note view could be positioned at the lower right of the item name TextView, and then at runtime we might consider adding padding to the right of the has_note view based on what getLineBounds() returns for the last line.
|Re: Shopping list items view layout, issue 340||Shuhao||12/12/11 9:08 PM|
Alright I now have time to work on this. Ill try the measure text tomorrow.
|Re: Shopping list items view layout, issue 340||Shuhao||12/13/11 1:22 PM|
I don't think this note thing will work with a text view.. everytime it wraps.. everything disappears according to a couple of different tries.
|Re: Shopping list items view layout, issue 340||Friedger Müffke||12/13/11 2:18 PM|
What about ClickableSpan
2011/12/13 Shuhao <ad...@thekks.net>:
> --> https://groups.google.com/d/msg/openintents/-/ki69i46mAmkJ.
Vertretungsberechtigter Geschäftsführer: Friedger Müffke
|Re: Shopping list items view layout, issue 340||aap||12/14/11 5:39 AM|
|Re: Shopping list items view layout, issue 340||Shuhao||12/16/11 9:33 PM|
I don't think that will work .... The original issue is about how the has_note icon is pushed off screen. All these methods will still result in that problem.
|Re: Shopping list items view layout, issue 340||Peli||12/17/11 11:25 AM|
To solve this issue of the note being pushed off screen, what about the following brute-force solution:
The note is right-aligned, and the right-most element with fixed width, centered within the whole height of a line. This should also be easier to touch by finger.
The disadvantage is that prices would not be aligned anymore if some items have notes and some don't. But prices currently have a similar issue that prices and item name can overlap if they are too long, so that the note would not fit in between.
|Re: Shopping list items view layout, issue 340||Shuhao||12/17/11 11:26 AM|
That's kind of what I did.
--You received this message because you are subscribed to the Google Groups "OpenIntents" group.To view this discussion on the web visit https://groups.google.com/d/msg/openintents/-/9xsmeYtiPwcJ.
|Re: Shopping list items view layout, issue 340||aap||1/22/12 3:01 PM|
Another approach might be to subclass RelativeLayout and add some layout parameters and rules. We could keep things in separate views but have the views wrap as though they were text... or maybe just have an alternative set of parameters to use if the main set would result in a view moving off the screen.