I'd be interested to see how an SQLite implementation could work - you could define each SVG document in a table, and then each shape from that document in a second table, but where it would start to get complicated would be that each shape each shape type has unique properties. For instance, for the SVG Path shape, it can be made up of any number of instructions, along with other meta data. For the SVG Circle shape, there are no instructions, but different meta data fields.
Essentially you'd need to have something like: Document (1toM) -> Shapes (1to1) -> (Path (1toM) -> Instructions | Circle | Line | etc etc for all shapes) A simpler layout would be just: Document (1toM) -> Shapes Where you store the raw XML that defines each shape in the Shapes table, but then you still need to parse that XML, leaving the same issue. Any suggestions? On Apr 14, 8:22 pm, lbendlin <[email protected]> wrote: > Is a SQLite database not appropriate in such a scenario? You'd get the > conversion for free... -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
