CODEWITHSUNDEEP
androiddomain-driven-designrepository-patternandroid-contentprovider
Eric Anastas
Eric Anastas

Reputation: 22213

Where do application logic and constraints go when creating ContentProviders?

I'm starting to learn Android development, and also have been trying to follow the DDD design patterns. One thing that has me confused is where application logic goes with respect to ContentProviders.

ContentProviders look a lot like repositories to me, but a lot of times I don't want to expose my repositories directly. There may be some additional application logic inside a Service which the repositories/database.

Most of the examples of ContentProviders I find show them accessing the database directly. Is it wrong to have a Service or Application object in between the ContentProviders and database?

For example I'm trying to create a personal finance/budget app (e.g Mint/Quicken etc..). I'm going to have a database of transactions and a corresponding TransactionProvider. In most cases transactions are independent from one another. Yet if two transactions are marked as part of the same "Transfer" there there will be some fields that I will want to keep in sync between the two transactions. If someone changes the category or amount of one transaction, I want to make sure the same values are updated for the transaction for the other account of the transfer.

Upvotes: 2

Views: 163

Answers (1)

matiash
matiash

Reputation: 55350

A ContentProvider can execute arbitrary code on its insert(), update(), delete() and query() methods. They are not necessarily mapped one-to-one with the corresponding database operations, and neither do the structure definitions (i.e. fields) themselves. You could, for example:

  • Update more than one table when you insert, update or delete.
  • Keep normalized tables in SQLite, but present a non-normalized interface for querying.
  • Not store data in a database at all (for example to expose/manipulate the files available in your application's private storage).
  • &c.

So you can, indeed, include whatever business logic you want in the "backend" of the ContentProvider. In your case that would mean updating associated records to keep them in sync.

Just to clarify, since you're starting Android development, it's not necessary to build a ContentProvider if you just want to store data in SQLite -- you can use SQLiteDatabase directly for that. A ContentProvider is generally to expose your own data to other applications, or for specialized cases such as search suggestions.

From Creating a Content Provider:

Decide if you need a content provider. You need to build a content provider if you want to provide one or more of the following features:

  • You want to offer complex data or files to other applications.
  • You want to allow users to copy complex data from your app into other apps.
  • You want to provide custom search suggestions using the search framework.

You don't need a provider to use an SQLite database if the use is entirely within your own application.

If you're building a financial data app, you probably don't need one. Do you want other applications to be able to access that data?

Upvotes: 1

Related Questions