As usual, the mapping between the data and the view is done with an
adapter - an ExpandableListAdapter or subclass.
http://developer.android.com/reference/android/widget/ExpandableListAdapter.html
It has to implement a handful of methods to get the number of groups,
the number of children in each group, create group and child views, etc.
The backing data structure and the logic behind these methods can be
anything.
Now if you are looking at SimpleExpandableListAdapter, that's different
in that it has very specific requirements about how the data is structured.
If your data isn't organized the way the SimpleExpandableListAdapter
expects, I think it's easier to subclass ExpandableListAdapter and write
those few methods yourself, rather than trying to massage your data for
the Simple class.
-- Kostya
14.07.2011 11:56, Jim Graham пишет:
> On Thu, Jul 14, 2011 at 01:53:17AM -0500, TreKing wrote:
>> On Wed, Jul 13, 2011 at 6:16 PM, Jim Graham<spooky130u@gmail.com> wrote:
>>
>> First, I think that's asking for trouble. If this data is related it
>> should be in some common object or structure.
> I started off heading that way, using SQLite. I was advised here, and
> not much later followed said advice, to use XML instead. What took me
> literally a few lines of code in Tcl, to open the database, query the
> database, and print the results, started to take multiple screens of
> Java code. Once this started, I KNEW I was doing something seriously
> wrong on the Java side, and abandoned that and went with the advice I'd
> gotten here.
>
>> Maybe - I, for one, am not really following. An ExpandableList has a
>> Parent->List<Children> type relationship. So if I'm following your
>> example, you'd have a list of brands as the top level list, then within
>> each of those *each* would have a list of grains, or whatever the
>> "children" are.
> Thanks---that answered the question I was asking---what the docs in the
> developer's guide and the examples in the API demos left me wondering
> about.
>
>> I think you'd have a maintenance headache if you start doing some kind
>> of crazy indexing into a giant array to determine the sub-lists.
> And normally, I'd agree, but with Tcl code being the original source,
> it's a simple matter of letting a Tcl script grab the data, and then
> split it out into the appropriate structure(s), first into their own
> files, and then while editing strings.xml, just do a quick ":r foo"
> for each of the resulting files and that's it...done. The data could
> either be in a SQLite database or in a structured Tcl script, where each
> line would call a proc[1], where the args would be the data for each list.
>
> In fact, as long as the data is in a standard format, it's trivial to
> write a script to "read" it. For JStrack, I was still a relative
> beginner with Tcl (ca. 1996) when I wrote the script that "reads"
> the NHC's FORECAST/ADVISORY (aka Marine Forecast) product and extracts
> the data for JStrack's use. To this day, the only significant changes
> to that script have been to make it recognize storm types that weren't
> in there (extratropical storm, subtropical storm, etc.). That file,
> (read_fc.tcl), including lots of LONG blocks of comments, blank lines,
> etc., is 358 lines long (according to a quick wc -l). Given what I know
> now, I could probably cut that in half...but as the old saying goes,
> poor grammar and all, "don't fix it if it ain't broke". :-)
>
> So no, in this case, re-formatting the data, re-structuring it, etc.,
> is not an issue. Nor is keeping it maintained. Just a couple of days
> ago, I nearly doubled the size of the data, from about 162 entries to
> 286. It took FAR longer to do the research (hunting is more like it)
> to find the data for the "new" malting companies, and then find their
> typical analysis data, than the few minutes it took to add it all to
> the master list. :-)
>
> Thanks for the info,
> --jim
>
> [1] The script that sorts the data out looks something like this:
>
> # run these bits before the procedure to open files, etc.
>
> set nf [open namesfile.xml w] ;# repeat for other data, merge later
> puts $nf<string-array name="nameslist"> ;# again, repeat...
> set allf [list $nf $v1f $v2f] ;# except with more readable var names
>
>
> # the actual proc, obviously, has more args.... In this short
> # example, iv value2 is not specified, it's an empty string.
>
> proc addfoo {name value1 {value2 ""}} {
> puts $nf "<item>$name</item>"
> puts $v1f "<item>$value1</item>"
> puts $v2f "<item>$value2</item>"
> # and so on.....
> }
>
> # run after the script to close the files
> foreach f $allf { puts $f</string-array> ; close $f }
>
> # If I wanted to, from here, I could append all of these to
> # strings.tcl from this script. I do that manually, though.
>
>
--
Kostya Vasilyev
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment