Properly save battery Life Throughout App’s lifecycle

-

On every Google IO, many advocates for the Android platform demonstrate and teach us how to build great apps. The term “Great Apps” consists of many aspects – user experience, performance, saving battery life, not wasting expensive 3G quota and more..in this post i’ll try to demonstrate a simple way to not waste battery life in an Animation oriented activity.

Let’s say that after displaying a nifty splash screen, your main activity consists of some animations which act in some sort of an infinite loop, to change pictures, articles, maybe polling data from a web service (asynctask of some sort). needless to say, that all of these processes take a lot of juice from the battery, so why worry about it?

well, if we are focused in that activity, there’s not much we can do because it’s in the foreground and the user probably has some interactions with the current activity. but what happens once it’s not focused anymore? all these tasks don’t just stop themselves, it’s in our responsibility to manage them via the lifecycle of the current activity.

Basically, the Activity class has some built in callback functions which are fired by the OS itself, you are all probably familiar with onCreate() which sis fired at the beginning of an Activity.
For example, I’ll discuss an Activity which displays some images in a fade in / fade out transition infinitely.
we want to stop these animations once we:

1. start a different Activity
onPause() is called
2. push the home button to return to the application/desktop
onStop() is called
lets assume we have a Handler which posts an animation loop message to the Messages queue of the UI thread:

   1:   
   2:  private Runnable dayTitlesRunnable = new Runnable()
   3:  {
   4:      @Override
   5:      public void run(){                
   6:      if (SdpApp.getDays().size()>0){
   7:      pbDayTitles.clearAnimation();
   8:      pbDayTitles.setVisibility(View.GONE);
   9:      tvRotatingdayTitle.setVisibility(View.VISIBLE);
  10:      if (indexOfDay < SdpApp.getDays().size()-1){                        
  11:      indexOfDay++;
  12:      }else {                        
  13:      indexOfDay = 0;                                
  14:      }
  15:      tvRotatingdayTitle.setText("text");
  16:      }            
  17:      dayTitilesHandler.postDelayed(this, 5000);
  18:      }
  19:  };



ok, we have a runnable which we can post to the UI thread, for this we need to define a Handler:

   1:  private Handler dayTitilesHandler  
   2:                 = new Handler();



in out onCreate() method we’ll call:"

   1:  private void animateDayTitles() {                
   2:          dayTitilesHandler.post(dayTitlesRunnable);
   3:      }



this function will add the Runnable we’ve defined to the UI Thread’s Message queue.

now, once we lost the focus in the current activity and would like to stop this battery/quota consuming process we need to add some code to the onPause(), onStop(), onResume() callbacks:

   1:  @Override
   2:  protected void onPause() {
   3:        super.onPause();
   4:        dayTitilesHandler.removeCallbacks
   5:             (dayTitlesRunnable);
   6:  }



The removeCallbacks(runnable) is a method of the handler which removes all of it’s callbacks.

   1:  @Override
   2:  protected void onResume() {
   3:      super.onResume();        
   4:      dayTitilesHandler.post(dayTitlesRunnable);
   5:  }




in the onResume() we post the same runnable to the UI' Thread’s message queue to start the animations again.

so it’s important to remember the the SDK offers us with all the hooks required to build great apps and it’s a great idea to use them in order to manage all the important aspects of application development as mentioned at the beginning of the post.

Comments

Post a Comment

Popular posts from this blog

Spinner VS AutoCompleteTextView

-
Image
       We’ve all been in a situation where we needed to show a list of some sort, a list which should be triggered by a user interaction (click, tap, etc..) A list is simple enough, probably even a spinner if we don’t want to spend that much screen real-estate on showing a list which the user clicks once and probably doesn’t need to see it after that. A spinner can be a real bug once there are too much entries for the user to choose from, how much is too much? that’s a good question – probably it differs from user to user, and probably this will have some performance issues with areal large number of entries, you cannot scroll forever to find what you’re looking for. A simple solutions for the problems mentioned above is an AutoCompleteTextView. it’s a control which is basically a combination of a TextView, EditText, and a Spinner all wrapped up in a single easy to use and configurable control. let’s see how it’s done:   first, in the layout file, create an AutoCompleteTextView
Read more

How to update UI from a different thread

-
     Google has set it’s tone on some tough guidelines for developing android apps, basically there aren’t any strict rules but one very easy to misunderstand. there is a single Thread which is called the “main” thread, or “UI thread” on some places. this is the thread which is in charge on the views and interaction with the users gestures. based on the guidelines of any mobile platform at the moment, all the work that shouldn’t be done on the main thread should be done on background thread. this can be achieved in many ways, you can use AsyncTask, Or A Handler, Or a simple thread with an implementation of the   run() method within the declaration of the runnable. ok, so if I’m pulling some server data, or performing long calculations, pulling stuff from or to the Sqlite database I’ll probably use an AsyncTask. but let’s say for instance that I want to simply update the UI once every couple of seconds (update a TextView or an ImageView’s content etc..), here’s a simple example of i
Read more

Utilizing Http response cache

-
     A typical mobile application will probably consume some resources from a web server using http requests. This repeated task has some drawbacks: Bandwidth has a cost, polling the same data over and over again results in a waste of user’s quota. the responsiveness and user experience is compromised once the user keeps waiting for data. If the requested data hasn’t changed on the server, then there’s no reason for us to fetch it. Of course, local caching of data is a must, but we also need to be able to refresh the data if it has changed on the server. A simple solution which comes out of the box for API 4+ is http response caching. Http response caching is a mechanism which enables us as developers to save a footprint of the response utilizing the abilities of the Http protocol. Basically, is holds a simple cache of the response which can be defined and enabled in code, and it prevents from fetching unchanged data from the server which was already fetched and processed into t
Read more