Post is pinned.Post has shared content
Preaching to the choir I guess, but in case you missed it ;)
The talk I did at Droidcon UK on Cupboard was recorded and is now available at +Skills Matter. The talk gives an introduction to Cupboard with some history, goals and examples. Check it out here:

If you like what you see you might also want to join the Cupboard Google+ community here: 

Learn more about Cupboard from the project site and the documentation at


Post has attachment
Hey Cupboarders!

Cupboard 2.2.0 introduces an abstraction to make it easier to work with alternative SQLite implementations such as SQLCipher aside from a couple of bug fixes.

Also, cupboard-tools is more modular now and deployed to Maven Central.

The content provider also supports alternative SQLite implementations, but you do need to bring your own SQLiteOpenHelper in that case. That might be a topic for a future blogpost still.

Both projects now have change logs as well. 

That moment the API of your app decides to suddenly switch to https (great!) without any notie in advance (😲😠😡)...

Post has attachment
For those using Cupboard with RxJava via my wrapper lib, I just pushed to GitHub and Maven Central version 2.0-rc1 of RxCupboard. Upgrades to RxJava2 and brushes up the API a bit. Feedback very much welcome! 

Post has attachment
I have some questions regarding to design of this library.

They are
1. Why primary keys named "_id" and are always autoincrement?
2. Why primary keys are Long, why can't be long with <0 values by default?
3. Why reflection is on by default?

I wonder around three points, which if clear can be great update on otherwise great library.

Here are where taking care of these issues be advantageous to android development and development in general.
1. Naming _id is fine but what if I want to name it something else, also Autoincrement is not beneficial in 99% of cases [1].

2. Working with Long will involve autoboxing with will be costly with one extra operation. Keeping long with a negative value will give us 2 benifits 1. No autoboxing 2. Null check can be replaced with negative values, Which I think only reason Long (Object type) is there.

3. Reflection is used in default entity converter, and very less options available. I may create my custom entity converter but requirement of Long _id really kills the purpose. Also, using reflection by force means we must exclude our models in proguard, which again is not a good thing to do.Quoting Jake Wharton from 360|AnDev talk [2] Don’t use overly matchy rules. If you ever see * * in a ProGuard rules file, that is wrong 100% of the time.

+Hugo Visser what are your thoughts about these? How we can we address these points in future versions of Cupboard?


how can someone use raw query with cupboard, and apply triggers

I have base class User which registered in cupboard as database table. I have also 3 classes which extends User and they contains only fields with @Ignore annotations.
I want to store in User table objects of those 3 extandable classes but I have such an exception:
java.lang.IllegalArgumentException: Entity is not registered: LocalTeacher

Should I convert such object to User interface or is there any annotation  or other fix for this issue?

I've got an issue when create new Cupboard instance

static {
CupboardFactory.setCupboard(new CupboardBuilder().useAnnotations().build());

and log

java.lang.IllegalArgumentException: teacher is not a constant in
at java.lang.Enum.valueOf(

AccountType is enum, it's a field in POJO

What should I do to fix this issue?

I wanna delete my database table by query:

int result = this.getDB.delete(DbDefines.RoomAssignmentTable, "...");
How to do it by cupboards :(

I have a question about cupboard db,
I want run sql: "delete * from table_name"
how to run it, I used code cupboard().withDatabase(getDB()).delete(Model.class); but it get error.
plz help me.
Wait while more posts are being loaded