I'm using greenDAO in my android app to display a list of objects in a
protected void onCreate(Bundle savedInstanceState)
mLayoutManager = new LinearLayoutManager(this, LinearLayoutManager.VERTICAL, false);
mListAdapter = new MyRecyclerAdapter(null);
public void refreshItems()
AsyncSession asyncSession = ((App)getApplication()).getDaoSession().startAsyncSession();
public void onAsyncOperationCompleted(final AsyncOperation operation)
What you're doing is completely valid and you don't need to save the queried data in
onSaveInstanceState(), use in-memory cache, or any other optimization (even if GreenDAO wouldn't have internal cache).
In fact, you're more than all-right because you perform the query asynchronously - GreenDAO's creators kind of claim that the queries can be executed on UI thread in most cases (which I find hard to agree with).
I would also suggest that you perform data query in
onStart() instead of
onCreate(). I personally think that
onCreate() should be used only for operations you would otherwise perform in the constructor (e.g. fields initializations). Another reason to perform this query in
onStart() is that if the user leaves your application for a long time and then gets back to it, the data might get outdated (e.g. due to background syncs by
SyncAdapter) and you'll want to refresh it.
The last piece that you might want to add is "data change notifications". You will want this mechanism to be in place if the data that you query and display to the user can change without user's interaction (e.g. due to background syncs by
SyncAdapter). The concept is simple -
Activity registers for notifications about data change in
onCreate(), and if notification received you perform re-query in order to make sure that the user sees an up-to-date data.
I can't claim that the above are "best practices", but they are good practices that work well.
As @pskink suggested in his comment, you could also employ
LazyList. Be aware, though, that it doesn't obviate a need for async query of data. Usage of
LazyList allows you to perform the query as usual, but load the results into memory in on-demand way. This might be useful if you expect the query to produce lots of data.
In my opinion, however, one should optimize the code only if actual performance problem is being observed. So, unless you know ahead of time that a particular query produces thousands of results, I say you don't need