Supercharge your Android Application-2(Views).

In first installment we have checked how to optimise our listview so that we can leverage the fragments to easily complete our tasks. In this part we will check how we can optimise our views to avoid lagging and inconsistency across states.

Unlike first part where we talked about only one trick, here I will share more tricks with you. Keeping continuity with first post, here is our second tip.

2.Mind your method.

a.k.a. when your method returns a view, make sure it returns as soon as possible.

Usually when we deal with fragments or lists, we have two methods which returns the view. For Fragments its onCreateView() and for lists its getView() methods. Theses methods are responsible to define view for a fragment or list view. Sooner they return, more faster your user will see that fragment, or scrolling of that list will be less leggy.

For fragments, onCreateView() is crucial. Many of us not only inflate our layout xml in this method, but also assign the widgets so we can use them later. That increases the time for onCreateView() to return the view. We also tend to populate our views same time. This habbit not only increases the time to load view, but it can also generate the exception. And chances are high that due to this exception, our view does not load at all, and all we see a blank view instead of fully (or partially) populated fragments.

Instead of doing all these things in onCreateView() it’s better to rely more in other methods, mostly on onViewCreated() method. This method calls immidietly after onCreateView() is returned. And it’s safe to assign widget variables and populate them here. In case of exception, what you see is your fragment view populated with no value at all. If you want to do something with your activity, like getting some property stored from activity. You can rely on onAttach() method where you can get your activity.

On list adapter, getView() method is responsible to generate and re-generate the view of the row. If you are closely following ViewHolder pattern, you may not face any issue when scrolling and viewing. If I can summarise it properly, what we usually do is to assign a view and it’s widget variables to a ViewHolder class, get the model for the values, and populate the widget according to model’s values.

This approach works when our model has all the values we need in single class, in proper manner. But it can give problems easily when none of them in present. Consider an app where we show places and top two check-ins in a list. Our model has all the information about the places and user ids for top two checkins. We have to show their names. What do we do in this case? Get the usernames for the ids, either by webservice or from database. And our getView() method waits for the values to be populated. Problems are seen when list scrolls, it’s too leggy.

The wise approach in this case is to populate all the values in model at once. Get the usernames in the model itself before it’s passed to populate the listview. And if you think your value can be null always populate with default values- a blank string, 0 digit or false. You face less hurdles in showing views.

remember The list view scrolls very smoothly when our getView() method has less conditions and less exceptions. But what should we do when our view has to show some states depends on the values? Won’t it have many if-else conditions?

That (somehow) leads to our third trick

3. Make your view-xmls slim and trim

Even if you are sure you are applying our second trick properly, your views won’t be smooth unless your xml has reduced it’s weight. Here are some mini-tricks that makes your xmls slim and trim.

1. If a text always has an image around it and it’s related to text, use android:drawableX attribute where X can be top,bottom,left or right it will inflate only one view in xml. In java, you can use setCompoundDrawable methods.

2. If your drawable is always in drawable folders, passing integer ids will reduce chances of crash when context can be null.

3. If your view responds to a state always have a state drawable attached to it. That will not reduce no of conditions, but will reduce work to redraw the views according to certain conditions. If you are already doing this, Kudos.

4. Populate as less textviews as possible, if you are having two textviews when one is for key and one is for value. Using Key: %1$S approach will reduce one textview for each key-value pair you have to show. It will also help to get proper translations.

5. Continuing #3. If you are having two or more textviews to show different texts with different styles, you can still merge them into one. Either with spannables, or with html styling.

6. When a parent view is not needed, remove it as long as it doesn’t affect the view and it’s desired arrangements.

These tips and many others to come, can be easily shown when you run inspections in your android studio project.

This is it folks. I hope it will get your app closer to smoothness and reliability. In next part We will help you to reduce your bugs and exceptions.