0

I'm writing an Android application that reads and presents data from legacy devices. The data consists of over 100 different 16-bit enumerations, each with thousands of possible values that represent things like device information, status, errors, etc...

Historically, the user would look up returned values in a large binder of tables. Let's say the device returns an error enum value of 0xFE04. The user would look through the error table to find something like this...

+---------+-------------+----------+
|  Error  | Description | Solution | 
+---------+-------------+----------+
| 0xFE04  | blah blah   | blah     |
+---------+-------------+----------+

Each enumeration has a table like this with hundreds or thousands of rows. These tables never change based upon user input, but will probably change with updates that provide wider support.

How can I store these tables in code so that I can return the appropriate information to the user efficiently & effectively? Language-independent solutions are preferred, as this app may be ported to iOS and Windows in the future.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
firyice
  • 527
  • 7
  • 24
  • possible duplicate of [Persisting data suited for enums](http://stackoverflow.com/questions/492096/persisting-data-suited-for-enums) – FThompson Apr 29 '13 at 03:34
  • 1
    Ah, I misunderstood the scope of data you are working with. Some sort of indexed file like SQLite would indeed be a good choice. – erickson Apr 29 '13 at 17:05

1 Answers1

3

SQLite? I'm actually being serious.

SQLite provides easy access from different platforms (support in Android, iOS, .NET, etc), separates concerns and keeps messages out of code (yay!), and is easily updatable and patchable. It also supports efficient lookups by means of indices (and for fun, it can query along unexpected lines, such as the description).

Using SQLite may actually reduce memory pressure as, presumably, only some subset of the data needs to be loaded.

user2246674
  • 7,621
  • 25
  • 28