On Thu, Jul 14, 2011 at 01:53:17AM -0500, TreKing wrote: > On Wed, Jul 13, 2011 at 6:16 PM, Jim Graham <spooky1...@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. -- 73 DE N5IAL (/4) MiSTie #49997 < Running FreeBSD 7.0 > spooky1...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W Point Lobos Photography Set 1 (Photo-posters): http://jdgapps.com "Someone ever tries to kill you, you try to kill 'em right back!" --Mal (Firefly, 1x03, Our Mrs. Reynolds) -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en