Data Layer

This page describes the datalayer implementation and considerations. It is work in progress and will be updated as the code matures. The content is intended to be a source of inspiration for the final report.

Data Layer Considerations

As the Android API restricts data access and management to it's own paradigm, we have to consider how to implement our solution to fit our needs and the Android paradigm.

The Android Paradigm

The Android API wraps file and database access, as well as access to ressources which comes with the application, such as logos, and other data files. (UA: Chapter 5)

This ensures security, no other application can access other applications data. The only way to provide access for other applications is via Content Providers, which is a paradigm presented by the Android API(GDG: Content Providers). Content Providers are also the strength of the framework, as they provide the right kind of data for any application interested. This makes it possible for an e-mail client to access the contacts list seamlessly.

File access

Files can only be accessed by the application which owns it. This makes it impossible to share data on the file system level, or even acccess files generated by other applications such as pictures, videos and database files. One has to use a Content Provider in order to provide data, and a Content Resolver in order to access data. (UA: Chapter 5.2)

Database access

Android implements the SQLite database, for use by it's applications. As the file access restrictions imply, there is no way to access other databases than the ones owned by the application itself. The Android API wraps access to the SQLite API in it's own helper classes(GAR: /docs/reference/android/database/sqlite/package-descr.html).

Content Providers

Content Providers can be reached from other applications and are the only way to share data beyond the same application.

The Data Layer

The Data Layer Pattern as described by Craig Larman is not as easily implemented using the Android paradigm as one should come to expect. The Android API puts an emphasis on using Content Providers as the prime way of providing data but never suggests using a layered architecture. In a system with multiple layers as described by Craig Larman(CUP: 30.2), the data layer is just above the technical layer and provides Ready To Go objects which are instanciated and deserialized. In the Android API, a Content Provider does not provide Ready To Go objects. It provides a Cursor to a table of raw data. Which one can use to fill objects with data. But the data is in no way tied to a class ready for instanciation and deserialization. This forces the Content Provider down to the technical layer, with siblings such as the logic behind handling the SQL transactions and database connections.

One has to wonder, what the main difference between a ContentProvider and a SQLiteDatabase class is.

The conclusion to the discussion is, unless you wish to provide your data to other applications there is no need to implement a ContentProvider subclass, as it doesn't add to the level of abstraction and provides no mentionable convenience from that of a SQLiteDatabase class. The interaction between the DAL and the Technical layer is in effect the same.

Notes

UA: Unlocking Android - A Developers' Guide, W. Frank Ableson, Charlie Collins, Robi Sen.
GDG: Google Android Developers Guide (Android 1.6 r1 - 03 Sep 2009 10:53)
GAR: Googlde Android API Reference (Android 1.6 r1 - 03 Sep 2009 10:53)
CUP: Craig Larman - Applying UML And Patterns 2nd ed.