Views, or as some one calls them Rich Views, are simple tool for working with one activity lifecycle. They are light weight and can take care for most of the work, not bothering with the activity livecycle, because the Views, or Rich Views are binded with the activity livecycle scope, or simply as long as the activity is alive, the view is also alive.
But here comes the next obvious question: Why just not use Fragments instead? Well here comes the deal, Fragments have theyr own livecycle with 12 methods that we need to overwrite, and with view we need to care about only one thing, the inflatement of the layout of the View, and thats it. Fragments are used, and were more fancy, with the tablets, wich have much more unused display space, to fill with separate functionalities like camera fragment split vertically and GPS fragment wit inner fragment map. But all of that is heavy lifting behind the screens, worrying about life-cycles of all fragments called. As is mentioned before, Views comes for the rescue. Simple, lightweight and functional. Imagine Views as layers above the Activity, and as far the Activity is alive, the Views are alive too, they are like headless activities.
In the next code example we will see how to implement several Rich Views.

I’m using ButterKnife library for binding the buttons, texts, edit texts, and ect

In this example we use Navigation Drawer, so I can visually represent the functionality of the Rich Views. This Navigation Drawer was explained in one of my previous blog posts.

They are all VIEWS, but im am referring as Reach Views in our example so I can distinct them from the other Views, like Text View, and something like that.

After the Navigation Drawer implementation, we must declare where to handle the Rich View chooser, as navigation drawer items:
The magic happens in onNavigationSelected(), or in another words, when we click on an item on the navigation drawer menu, correct Reach View appears on the screen.
The Views are initialized in the container that we import in our layout for the HomeActivity which is match_parent for width and height. We pass the container new object from our Rich View class, witch have inflater implemented in the View constructor, so the View is displayed when the Rich View object is created. The container is declared as Frame Layout, to hold our Rich View.

Here is the XML code for the HomeActivity layout, and only element that we care about for now is the FrameLayout declared with id as container. That container is initialized in our HomeActivity:

Here is our second Reach View with some buttons inside:

… and the layout code.

When we use Rich Views, this cannot be applyed because is activity special command, but we can use getContext() method, which takes the context from the activity which the Rich View is called.

Spread the love

Leave a Reply

Your email address will not be published.