Oh CRUD, it's Time to Manage Data

Other than "batch job", I'm hard pressed to come up with an IT term as long in the tooth as CRUD. For most IT professionals, CRUD does not mean "dirt, filth or waste, or something of poor quality". Instead, it's an acronym for Create, Read, Update, and Delete. These are the four core actions that can be performed on data.

Interestingly, Wikipedia cites a 1983 book by the recently passed James Martin as the first use of the term ( http://en.wikipedia.org/wiki/Create,_read,_update_and_delete ). But even though the term may have come from the 80s, the underlying functionality has been a part of computing from the start.

As mentioned in the wikipedia article, the example used to demonstrate CRUD is usually something like a contact entry in an address book. At a minimum, you should be able to:

  • Add a new entry (create)
  • View an entry in the address book (read)
  • Change some of the details of an entry (update)
  • Remove an entry from the address book (delete)

In addition to these four operations, two additional operations are usually cited:

  • Search across a collection of entries for something
  • List a subset of the entries (and potentially use pagination to manage the presently displayed list.)

When adding these two additional operations, I guess you get "SCRUDL". (I'm not really even sure how to pronounce that.)

Since this term is so well known, most people see it as a "boring" problem to solve. When it comes to mobile development, I don't see it that way. Why? Because things usually aren't so simple. Take the example of the address book: What if you've got information in the address book about related to the contact. If you try to delete the contact, should you warn the user? Or, if you have a similar phone number, should you suggest a relationship between one contact and another? My point is this: Once you start to examine data with interesting relationships, the CRUD operations become nontrivial.

Still not convinced? Then you may want to give this article a reading:
( http://msdn.microsoft.com/en-us/library/ms978509.aspx ). It's not groundbreaking, but it does help highlight that things aren't really as simple as the four operations.

Even with a basic set of data, the mobile environment presents some interesting challenges. Some examples:

  • If you're not on a network, how do you save changes?
  • How should transactions be handled when data is spread across multiple servers?
  • How can the basic four operations best be presented to a user on a small screen?

In future articles, I'll explore some of these questions. However, before proceeding to some of the more esoteric issues, it's important to get the basics right. Accordingly, this article will use the fishing spot business object as a basic data element that needs to be managed.

And with that, I'll now dive in to managing location data…