Getting Started with ActiveAndroid
Scott Carson | 09/22/2016
All code for this series is located here.
In my last post I gave a short intro to Object-Relational Mapping (ORM) and the ActiveAndroid library. This post will focus on how to hit the ground running with ActiveAndroid. We will look at the different ways to instantiate ActiveAndroid in your application and go over the reasons why you might choose one way over another.
All code for this tutorial series is available here. Throughout this series, as the application evolves, I will link to repository tags that represent the application at each stage.
ActiveAndroid is easy to integrate with your app and can be done by directly adding the JAR file to your project, installing via Maven, or installing via Gradle. I chose to install using Gradle since that is how I manage most of my application dependencies. Add the following highlighted lines to your apps build.gradle file:
build.gradle
`… repositories { mavenCentral() maven { url “https://oss.sonatype.org/content/repositories/snapshots/” } } …
dependencies { … ‘com.michaelpardo:activeandroid:3.1.0-SNAPSHOT’ … }`
Next we have to configure ActiveAndroid in our applications AndroidManifest.xml file. There are a few optional parameters here:
- AA_DB_NAME (optional) – The name of your SQLite database
- AA_DB_VERSION (optional) – The version of your SQLite database
I always recommend naming your database as well as setting a version number. The version is what is used by ActiveAndroid to determine if there has been a schema update. Also, note that the application name points to the ActiveAndroid application class – this is required for ActiveAndroid to work properly. More customizations will be added to the AndroidManifest.xml as we cover their related features. For now your AndroidManifest should resemble this:
AndroidManifest.xml `<manifest
…
<application
...
android:name="com.activeandroid.app.Application">
<meta-data android:name="AA_DB_NAME" android:value="tutorial.db" />
<meta-data android:name="AA_DB_VERSION" android:value="1" />
...
</application>
</manifest>`
There are three different ways that ActiveAndroid can be initialized in an application.
In my opinion the easiest is to write a custom Application class that extends com.activeandroid.app.Application. As long as your AndroidManifest.xml file has the meta-data mentioned above, ActiveAndroid will take care of everything from database initialization to database upgrades all without writing a line of code. This is how we will be utilizing ActiveAndroid in this series.
CarBuilderApplication.java `package com.rscottcarson.activeandroid_tutorial;
import com.activeandroid.app.Application;
…
public class CarBuilderApplication extends Application {
...
@Override
public void onCreate(){
super.onCreate();
...
} }`
But what if your app is already extending another library’s Application class? Then it is simply a matter of calling ActiveAndroid.initialize() in the Application onCreate() method:
`public class CarBuilderApplication extends OtherLibraryApplication {
@Override
public void onCreate(){
super.onCreate();
ActiveAndroid.initialize(this);
} }`
Finally, for those of you that want more control of your ActiveAndroid instance, there is a Configuration class that can be used to set up your database. This is useful if, say, you want to drop your old database on database upgrades instead of writing migration scripts (a topic we will touch later), or you want a dynamic naming scheme. Using the Configuration classes Builder you are able to customize ActiveAndroid by setting the database name, version, cache size, TypeSerializers, and even what SQL parser to use. After configuring your database you then call the overloaded ActiveAndroid.initialize() method in your applications onCreate():
`public class CarBuilderApplication extends OtherLibraryApplication {
private static final int DB_VERSION = 1;
@Override
public void onCreate(){
super.onCreate();
Configuration dbConfig =
new Configuration
.Builder(this)
.setDatabaseName("dbName")
.setDatabaseVersion(DB_VERSION)
.create();
ActiveAndroid.initialize(dbConfig);
} }`
What is next?
The next post will look at defining your first Models.