Develop Reference

migrate Android app from OrmLite to Room

I have an Android app with a somewhat complex database (18 tables). The app currently uses OrmLite to map and manage database objects. I'd like to migrate the app incrementally to use Room. I've read about steps to migrate an existing SQLite app to Room, which involves replacing SQLiteOpenHelper with Room's SupportSQLiteOpenHelper. However, I don't think I could easily replace that within the OrmLite framework. Does anyone know if it's possible for OrmLite and Room to coexist in the same runtime, accessing the same SQLite database file? What steps would I need to take to ensure the database is not corrupted between the two frameworks, other than the obvious transfer of entity classes from OrmLite to Room?
Thank you.

Best way to store and retrieve data to and from database in android

I am currently developing a a project with multiple number of tables. So I created separate classes for storage and retrieval of data of each table.
Is there any better way so that I can reduce the number of classes? I am a beginner, so I am really uncertain about this.

Here is description of all basic storage techniques:
Which Android Data Storage Technique to use?
But as #345 mentioned, you should try Realm Db. Its way easier to store and manage your data with it, in comparison to some SQLight wrappers.

You can achieve this by making your code dynamic. Like you create some generalized methods and send the keys (table name, column name, row name) and values on real time when you are accessing those tables. But you have to do a-lot of work to do this, because all your tables will be different in structure. So you have to create methods for each table in that class or you can handle all possible scenarios through conditions (if/else or switch case).
Check this example, I hope it will help you.
http://www.androidhive.info/2013/09/android-sqlite-database-with-multiple-tables/

You must look around Room Persistence Library is an ORM between Java classes and SQLite:
Room provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite.
Documentation

How does Realm for Android actually store data?

I am looking at migrating a native Android project from an SQLite database to an ORM. I have considered what I believe to be the fastest current contenders - DBFlow (based on SQLite) and Realm.
Therefore, out of curiosity, does anyone know what sort of data format Realm is using? Having read their documentation, this is seems to be a pretty closed subject and I could not find anything on the matter.

From their site - Realm is not an ORM on top of SQLite. Instead it uses its own persistence engine and their source code is open for java.
https://github.com/realm/realm-java

GreenDao android Integration.

I want to integrate greenDAO – Android ORM for SQLite in my project. I am a bit of confused in between Schema and DaoMaster. Do I really need to create a Schema (creating new Module for creating Schema) beacuse what I understand the DaoMaster already implement the SQLiteOpenHelper class which is used to create table in Sqlite. Please explain the significance of creating Schema to integrate GreenDAO.

Everything you have to do its create DaoGenerator like here
http://greendao-orm.com/documentation/modelling-entities/ to generate all files you need.

The Schema is used to add the entities and generate automatically all the classes needed, like DaoMaster, DaoSession and the Dao and Object for each entity.
Technically, you should be able to use GreenDao without it, but It doesn't make sense for me, since one of the best things of GreenDao is this automatic generation.

Greendao doesn't use reflection to generate a mapping between your object model and your database-model by inspecting your entity-classes. Instead greendao hardcodes your mapping by generating your entity-classes, dao-classes and so on. This is what makes greendao faster than other ORM tools.
But somewhere you have to define your mapping and this is done by schema. To keep your app small the generation of the classes in done outside of your app, which means the logic to process any kind of schema and generate something out of it is not included in your app-code.
As #Jofre Mateu said it is technically possible to use greendao without generating schema, but it simply makes no sense: you'd throw away 99% of the features greendao offers and by implementing this yourself you'd introduce bugs into your app.

ORM performance: is greenDAO faster than ORMLite?

I've been using ORMLite in my application and I was considering whether to move to greenDAO.
Performance is a huge part of that decision, and greenDAO's Features page says:
For the same given entity, greenDAO inserts and updates entities over
2 times faster, and loads entities 4.5 times faster for loading
entities than ORMLite.
...
(Figures and chart updated 10-23-2011)
I thought ORMLite's config file generation step should remove the need for reflection at runtime.
The ORMLite changlog suggests that the greenDAO benchmark was done after the config file feature was released, but the greenDAO features page doesn't explicitly say if a static config file was generated for the test.
4.26: 9/26/2011 (svn r1978)
* ANDROID: Added field configuration utility to avoid Dao creation performance problems with annotations.
There have also been ORMLite performance fixes since then, e.g.
4.40: 4/16/2012 (svn r2516)
* ANDROID: Big performance bug fix when creating DAOs. Foreign fields always used reflection instead of table configs.
Can anybody confirm if there is still a big performance difference between greenDAO and ORMLite? Thanks!

We've just published a Github project that we used to compare the performance of ORMLite and GreenDao to raw SQLite:
https://github.com/daj/android-orm-benchmark
The project also allows you to compare the performance of an in-memory database to an on disk one.
The headline results are:
GreenDao is much faster than ORMLite. It is roughly:
3X faster at writing large numbers of objects.
50% faster at reading in all 10000 entries in a single table.
2X to 3X faster at an indexed read of a single row (though both were very fast).
15X faster at doing a LIKE search for 100 records in a 10000 entry table.
The project contains both a naive raw SQLite benchmark, and an optimized SQLite benchmark.
GreenDao vs unoptimized raw SQLite
GreenDao is 2X faster for the write benchmark.
GreenDao is 25% slower for the read benchmark.
GreenDao vs optimized raw SQLite
GreenDao is 50% slower for the read and write benchmarks.
For detailed results please see the Github repository above.
Of course we may have bugs in our benchmarking code...if you find any please fork, fix and submit a pull request! :-)
Disclaimer: make sure you do your own research before choosing GreenDao over ORMLite.