Android Tutorial: Learning How to CRUD
Hi all!
Today I’d like to share with you how we can create a CRUD design for our apps’ access to (local) database resources.
Let’s assume we’re going to implement this in an E-Commerce Marketplace app.
Details
This article’s valid for any database provider, but, for this exercise, we’re going to use ObjectBox. I’m using it in my MapCrumbs app and am quite happy with it because it fulfills the requirements I usually have for a database:
- Easy to implement and use
- Good performance
- Good support documentation
As for the coding part, we’re going to use Kotlin for this tutorial.
The first thing we need to do is to configure the project to include ObjectBox. To prevent deviating from this article’s aim, please follow the steps listed here.
For simplicity, let’s just consider records for the User and for the ShoppingCart.
Models
Our entities will represent each of the database tables considered for this exercise.
User
The UserEntity is responsible for representing the user information in our database.
Note: Read more about data classes and the Entity and Id annotations.
Shopping Cart
The ShoppingCartEntity is where we’ll register all the items saved by the user.
Database Manager
The database manager has two very important goals:
- To control the database’s initialization/configurations when launching the app.
- To serve as a middle layer for the controllers (activities or fragments) to access the database’s DAOs.
It’s useful to detach our Database Manager from specific database providers, using an abstraction for the behaviors it must have. Read more about this here.
For this exercise, we’ll use a singleton object for the ObjectBox’s implementation, that looks like this:
Note: Read about lateinit var here.
Data Access Objects (DAOs)
The aim when using DAOs is to provide the app with a single access point to a specific database collection.
For this exercise, we have two collections that work differently in how they should store data:
- The User collection should only allow for a single entry (the user’s, of course)
- The ShoppingCart allows for multiple entries (representing the items in the shopping cart)
To represent that, we’re going to create some capacities abstractions. Read more about this here.
Single-entry abstractions
Multiple-entries abstractions
Note: With ObjectBox, the put method will add a new entry or update an existing one, with the same ID. Hence, we’re using a single upsert method for that operation, instead of having different methods for insert/update.
Following on that, I like to compose a component abstraction, which is a representation of the combined capacities it should have.
UserDAO component abstraction
As stated before, the User collection will be a single-entry one, so its abstraction will look like this:
ShoppingCartDAO component abstraction
As for the ShoppingCart, it will have multiple-entries, so its abstraction will be:
Now, let’s implement our DAOs according to what they must do.
UserDAO
The repo read-only property (val) is the database collection (with ObjectBox, they call them boxes).
ShoppingCartDAO
Controllers
Last but not least, let’s take a look at how we should access our database resources from our controllers.
User registration
Note: For simplicity, there are no input validations and the business logic might seem random, but we’re just focused on the CRUD part.
Note 2: The UserFactory’s implementation is not relevant for this topic, but please read more on that here.
Adding/Updating an item to the Shopping Cart
That’s it for today. Feel free to ask any questions or add suggestions if you’d like!
Cheers!
