1.Why "Architecture" Components?
2.what does architecture components include?
{
Room //a robust SQL object mapping library
ViewModel //provide data for UI components and survive configuration changes
LiveData //monitor changes,database observer and also lifecycle observer
Lifecycle //lifecycle aware component
}
3.how to use Room component?
3.1 define a Plain Old Java Object,or a POJO.
then mark this POJO with the @Entity annotation and create an ID market with the @PrimaryKey annotation.
@Entity
public class Trail{
public @PrimaryKey String id;
public String name;
public double kilometers;
public int difficulty;
}
3.2 Now for each POJO,you need to define a DAO,or a Database.
The annotated methods represent the SQLite,commands that you need to interact with your POJO‘s data.
Room also verifies your SQLite at compile time.So if you spell something a little bit wrong int the database,it will throw a helpful error.
TrailDao.java
@Dao
public interface TrailDao{
//Create,read,update,delete examples
@Insert(onConflict=IGNORE)
void insertTrail(Trail trail)
@Query("SELECT * FROM Trail")
public List<Trail> findAllTrails();
@Update(onConflict = REPLACE)
void updateTrail(Trail trail)
@Query("DELETE FROM Trail")
void deleteAll();
}
LiveData is an observable data holder.It notifies obervers when data changes so that you can update the UI,or,for simple cases,you can use the MutableLiveData class.
MutableLiveData<String> dayOfWeek = new MutableLiveData<>();
dayOfWeek.observe(this,data->{
mTextView.setText(dayOfWeek.getValue()+"Thursday is a good day for a hike.");});
dayOfWeek.setValue("Friday");
If you update the value of the MutableLiveData with a call to set value,it could then trigger and update in your UI.What‘s even more powerful though,is that Room is built to support LiveData.
To use them together,you just modify your DAO class.
TrailDao.java
@Dao
public interface TrailDao{
//Create,read,update,delete examples
@Insert(onConflict=IGNORE)
void insertTrail(Trail trail)
@Query("SELECT * FROM Trail")
public LiveData<List<Trail>> findAllTrails();
@Update(onConflict = REPLACE)
void updateTrail(Trail trail)
@Query("DELETE FROM Trail")
void deleteAll();
}
Then you could write code like this to update your UI.
trailsLiveData.observe(this,trails->{
//Update UI,in this case a RecyclerView
mTrailsRecyclerAdapter.replaceItems(trails);
mTrailsRecyclerAdapter.notifyDataSetChanged();
});
The end result is that if your Room database updates,it changes the data in your LiveData object,which automatically triggers UI updates
3.3 LiveData is an obervable data holder.It notifies observers when data changes so that you can update the UI.It is also lifecycle aware.
Lifecycle Aware Component?
LiveData knows when your activity is on screen,off screen,or destroyed,so that is doesn‘t send database updates to a non-active UI.
There are two interfaces for this:
LifecycleOwners are objects with lifecycles,like Acitivies and Fragments.
LifecycleObservers observe LifecycleOwners and are notified of lifecycle changes.
Here‘s a quick peek at the simplified:code for LiveData,which is also a Lifecycle Observer.
LiveData.java
abstract public class LiveData<T> implements LifecycleObserver{
@OnLifecycleEvent(Lifecycle.Event.ON_START)
void startup(){...}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
void cleanup(){...}
}
Observing Flow:
As a side note to all you Android library designers out there,you can use this exact same lifecycle obervation code to call setup and tear down functions automatically.
Your Library
MyLibraryClass implements LifecycleObserver{
@OnLifecycleEvent(Lifecycle.Event.ON_START)
void startup(){...}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
void cleanup(){...}
}
4.Avoid a lot of needlessly re-executed code.associated with the UI in a ViewModel instead.
ViewModel:View models are objects that provide data for UI components and survive configuration changes.
TrailListViewModel.java
public class TrailListViewModel extends AndroidViewModel{
private AppDatabase mDatabase;
private LiveData<<List<Trail>>> trails;
public TrailListViewModel(Application application){
super(application);
mDatabase=AppDatabase.getDb(getApplication());
trails=mDatabase.trailModel().findAllTrails();
}
}
Then,when you are creating your activity or fragment,you can get a reference to the ViewModel
and use it.
RecommendedTrailsActivity.java
//In onCreate
trailListViewModel=ViewModelProviders.of(this)
.get(TrailViewModel.class);
//Code to set up the RecyclerView omitted
trailListViewModel.getTrails().observe(this,trails->{
mTrailsRecyclerAdapter.replaceItems(trails);
mTrailsRecyclerAdapter.notifyDataSetChanged();
);
The first time you get a ViewModel,it is generated for your activity.When you request a ViewModel again,your activity receives the original ViewModel,no more useless database calls.
5. In Summary
Altogether,they make up a set of architecture components for writing modular,testable,and robust Android apps.
