Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Choosing the Right Abstractions for In-Memory Storage of Data

Data returned from a database query or read in from a file must be held in memory so that it can be viewed and manipulated. There are two basic ways to work with this data in memory:

Use a general-purpose abstract model.
Many programming frameworks offer an abstract model for working with data returned from databases. ADO.NET is the model supported by the .NET Compact Framework, and its use is described later in this chapter; other frameworks have different models. An abstract model has the virtue of being very flexible. Data that is returned from a database is stored in generic tables and rows of objects. Each row contains fields corresponding to column definitions. The grid of rows and columns forms a table. Tables can be grouped together in sets with additional tables describing the relationships between the columns in different tables. When you do a generic query of a database and do not know in advance what kind of data you are going to get back, storing it in this kind of abstract format is a necessity. Today's advanced data access models can also track changes made to the data locally. These changes can later be rejected, committed, or otherwise reconciled with the data in the database. In addition, the various data access frameworks can aid in the execution of transactions and can offer flexible views onto the data locally. Generic data-binding models also exist to allow the binding of data in the tables to user interface elements. These general-purpose data access programming models are flexible, can respond robustly to changes in the database formats, and offer abstractions for looking at the types of the data being worked with at runtime. This flexibility comes at the cost of additional objects. These objects are used to contain meta data (meta data = information about the information), hold relationships between the various data elements, and track changes to the data. When using these higher-level in-memory data access technologies, your application is effectively creating an in-memory database of the data; this is powerful but can be expensive in computational and memory requirements.

Use a custom model tailored to your data.
In contrast to the abstract model for working with data is the bare-bones approach of building a custom implementation that contains only what is required to hold and use the data. When using a custom data access strategy, your mobile application dispenses with the abstractions offered by an in-memory database of generic rows, columns, tables, and relationships and chooses to store the data in the most efficient format possible for the problem being solved. Usually this means an array of simple types that contain the data. In this custom-built model, your application loses a lot of the flexibility of a general-purpose approach and takes on the burden of keeping track of updates and managing data relationships. The benefit is that the application can potentially save a significant amount of in-memory state by using only what is absolutely required. If the data being worked with can easily be represented in a single table and does not have complicated interrelationships, a custom tailored format can be a great choice.

The most appropriate model to choose is determined by the size and complexity of the data being used. Building your own data model is a fool's errand if your data has many interrelationships that need to be managed and represented in the mobile application's memory. On the other hand, if your data consists of a few simple fields in a single database table and the data is read-only, it is equally foolish to choose a complex and stateful data model when a simple array of data would accomplish the desired end. It is likely your mobile application's data needs will fall somewhere in between these extremes, and you will have to try out different models and choose the most appropriate for your needs. As described above, this choice is similar to the technology decision mobile application developers need to make when working with XML data. The developer must choose between potential design and implementation simplicity versus runtime efficiency.