Today, I’m happy to tell you that LitePal has a new version.

By the way, the last version 1.6.1 was released six months ago, and I’ve been maintaining the entire open source project for four years since it was launched in 2014. Over the past four years, I’ve been refining LitePal’s code, fixing bugs and adding all sorts of nice new features. Today, after half a year, LitePal is finally getting a major release update, with version 2.0.0!

The jump from 1.6.1 to 2.0.0 shows that the upgrade is quite significant. In version 2.0.0, I rebuilt a lot of internal code, making LitePal’s overall architecture more reasonable and clear, API more scientific, and rewriting the database synchronization processing mechanism, to solve a lot of concurrent database operation problems. Most importantly, LitePal 2.0.0 now fully supports Kotlin! Isn’t it a little exciting that LitePal will be 100% compatible with Android regardless of whether you’re developing in Java or Kotlin? So let’s learn how to use the new version of LitePal.

Upgrade to 2.0.0

The upgrade is easy, if you are using Android Studio, just modify the configuration in build.gradle:

Dependencies {implementation 'org. Litepal. Android: core: 2.0.0'}Copy the code

If you still use Eclipse, click here to download the latest version of the JAR package.

New Version Changes

It should be noted that almost all of the API interfaces have been changed in 2.0.0. But don’t panic, version 2.0.0 is fully backward compatible, which means you don’t have to worry about a lot of errors after the upgrade. All of the previous code will still work, but the old API will be marked as obsolete to remind you to use the new API as soon as possible, as shown in the following figure:

Of course, you don’t need to panic when you hear that all apis have changed, but there is a regular pattern.

As we all know, the usage of LitePal itself is very simple, so the process of upgrading the new API is also very simple, so let’s take a look at it step by step.

The first thing to change is the inheritance of the entity class, which is how we used to write it:

As you can see, the DataSupport class has been deprecated. Although it works for now, it is not recommended to use it any more. Starting with LitePal 2.0.0, we recommend using LitePalSupport.

An implicit benefit of changing the entity class inheritance structure to LitePalSupport is that all instance CRUD methods, such as save(), Update (), Delete (), and so on, are automatically upgraded to version 2.0.0. Therefore, we store a piece of data and write it exactly as it should be written, for example:

Song song = new Song();
song.setName("hello");
song.setDuration("180");
song.save();
Copy the code

This saves a single piece of data to the database, unchanged but using the latest interface in LitePal 2.0.0, since the save() method comes from the LitePalSupport class.

The next step to upgrade is the static CRUD method. All static CRUD methods are wrapped in the DataSupport class. For example, you can query a database as follows:

Now, all the static CRUD methods have been moved to the LitePal class, so we just need to change the DataSupport to LitePal, and the rest of the usage is completely unchanged, as follows:

Yes, the upgrade process is that simple. If you’re using DataSupport in your inheritance structure, change it to LitePalSupport, and if you’re calling a static method in DataSupport, change it to LitePal.

One final thing to note, however, is that if obfuscated is enabled in your project code, the obfuscated configuration will need to be modified accordingly. The original obfuscated configuration looks like this:

-keep class org.litepal.** {
    *;
}

-keep class * extends org.litepal.crud.DataSupport {
    *;
}
Copy the code

The DataSupport class is deprecated, so change the DataSupport in the obfuscated file to LitePalSupport, as shown below:

-keep class org.litepal.** {
    *;
}

-keep class * extends org.litepal.crud.LitePalSupport{
    *;
}
Copy the code

Once you’ve done all that, congratulations, your code has been fully upgraded to LitePal 2.0.0.

Use LitePal in Kotlin

Kotlin has been in development for more than a year since it became a tier 1 Android language at Google IO last year, and is now officially Google’s son. As more and more people use Kotlin to write Android applications in the future, LitePal will follow suit and fully support Kotlin.

Let me give you a quick demonstration of how to use LitePal in Kotlin code.

The first step is to define an entity class. Let’s use the Book class as an example. Select * from LitePalSupport (id, name, page);

class Book(val name: String, val page: Int) : LitePalSupport() {
    val id: Long = 0
}
Copy the code

As you can see, defining entity classes in Kotlin is really easy. Note that if you need to define the id field in your entity class, do not put it in the constructor, because the id value is automatically assigned by LitePal and should not be specified by the user. So here we declare a read-only id inside the Book class.

Then we need to declare the entity class in litepal.xml, which is a general operation:

<list>
    <mapping class="org.litepal.litepalsample.model.Book" />
</list>
Copy the code

All right! Now we are ready for CRUD operations, so since this is the first time Kotlin is working with LitePal, I will demonstrate each operation separately here. The first is the store operation, which looks like this:

Val book = book (" first line of code ", 552) val result = book.save() log. d(TAG, "save result is $result, book id is ${book.id}")Copy the code

As you can see, we create an instance of Book, pass in the title and page number, and then call save() to store this data in the database. After the storage is complete, a print log is used to print the execution result, as follows:

D/MainActivity: save result is true , book id is 1
Copy the code

As you can see, the store succeeded and the book id has changed to 1, indicating that LitePal automatically assigned the id after the store succeeded.

Let’s go to the database and have a look, as shown in the figure below:

Verify again that the storage operation was successful.

Let’s demonstrate the modification, as shown below:

Val CV = ContentValues() CV. Put ("name", "第 一 行 ") CV. Put ("page", 570) LitePal. Update (Book::class.java, CV, 1)Copy the code

In fact, the usage of Kotlin will be familiar to everyone, because it is similar to Java, but the specific syntax may be a little different. For example, the first argument received by the update() method is a Class object. In Java we pass book.class, whereas in Kotlin we pass Book::class.java.

Execute the above code, and then check the database. The result should look like the following:

Yes, it means that our modification operation has been successfully completed.

Let’s take a look at the delete operation, which looks like this:

LitePal.delete(Book::class.java, 1)
Copy the code

Here we specify that we want to delete the record with ID 1. If you want to delete all books with more than 500 pages, you can delete them as follows:

LitePal.deleteAll(Book::class.java, "page > ?", "500")
Copy the code

Ok, now execute any of the above lines of code and go to the database to look at them as shown below:

There is no problem. You can see that the database has been emptied, indicating that our deletion operation did work.

Finally, I will show you the operation of the query. Since there is no more data available in the database, we add two pieces of data to the library and then perform the query as follows:

Book(" first line of code ", 552).save() Book(" second line of code ", 570).save() litepal.findall (Book::class.java).foreach {log.d (TAG, "book name is ${it.name} , book page is ${it.page}") }Copy the code

The findAll() method is called to query all the data in the Book table. The result of the query is a List collection, so we use Kotlin’s forEach loop to print out each record. The following information is displayed:

D/MainActivity: book name is 552 D/MainActivity: book name is 570Copy the code

Of course, in addition to calling the findAll() method, we can also use LitePal’s concatenated query to customize the query criteria arbitrarily:

LitePal.where("name like ?" , "page desc").order("page desc").limit(5).find(Book::class.java)Copy the code

Now that we’re done demonstrating CRUD operations using LitePal in Kotlin, does it feel as simple and convenient as it does in Java? Of course, in addition to these new features, I’ve also fixed a few known bugs and improved the overall stability of the framework, so if that’s what you need, go ahead and upgrade.

What if I never learned LitePal?

This article is for people who already know LitePal to help them quickly upgrade to LitePal 2.0. If you haven’t learned LitePal before, you can refer to Chapter 6 of Line 1, 2nd Edition for a very detailed explanation of how to use LitePal.

Pay attention to my technical public account “Guo Lin”, there are high-quality technical articles pushed every day.