Monday, September 30, 2013

Android Tutorial: Recreating an Activity

Probably I really should read this tutorial much earlier, while it's never too late to learn. The key knowledge in this tutorial confused me for a while.

  • By default, the system uses the Bundle instance state to save information about each View object in your activity layout (such as the text value entered into an EditText object). So, if your activity instance is destroyed and recreated, the state of the layout is restored to its previous state with no code required by you. However, your activity might have more state information that you'd like to restore, such as member variables that track the user's progress in the activity.
  • To save additional data about the activity state, you must override the onSaveInstanceState() callback method. The system calls this method when the user is leaving your activity and passes it the Bundle object that will be saved in the event that your activity is destroyed unexpectedly. If the system must recreate the activity instance later, it passes the same Bundle object to both the onRestoreInstanceState() and onCreate() methods.

To Save your Activity State, such as the text in EditText, the scroll position of ListView, etc.
  • Call onSaveInstanceState(), in this function, save state information like saving Preference for the App. The super function is call at the end of this override callback function. This function is called precisely right after onPause() being called. I have this confirmed with my customized demo code from tutorial.
To Restore your Activity State, two ways can be used:
  1. In onCreate() function, savedInstanceState has saved state information, but need to check if it's null or not before fetch any information from it.
  2. Call onRestoreInstanceState(), in this function, doesn't need to check the nullity, because this function would not be called unless there exists saved state information already. One thing to remember for using this function, this function is called between onStart() and onResume(). The super function is called at the beginning of this override callback function.

Saturday, September 28, 2013

Android Tutorial: Stopping and Restarting an Activity

When your activity is stopped, the Activity object is kept resident in memory and is recalled when the activity resumes. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state. The system also keeps track of the current state for each View in the layout, so if the user entered text into an EditText widget, that content is retained so you don't need to save and restore it.

Note: Even if the system destroys your activity while it's stopped, it still retains the state of the View objects (such as text in an EditText) in a Bundle (a blob of key-value pairs) and restores them if the user navigates back to the same instance of the activity (the next lesson talks more about using a Bundle to save other state data in case your activity is destroyed and recreated).

It's uncommon that an app needs to use onRestart() to restore the activity's state, so there aren't any guidelines for this method that apply to the general population of apps. However, because your onStop()method should essentially clean up all your activity's resources, you'll need to re-instantiate them when the activity restarts. Yet, you also need to instantiate them when your activity is created for the first time (when there's no existing instance of the activity). For this reason, you should usually use the onStart() callback method as the counterpart to the onStop() method, because the system calls onStart() both when it creates your activity and when it restarts the activity from the stopped state.

Because the user might have been away from your app for a long time before coming back it, the onStart() method is a good place to verify that required system features are enabled.

The tutorial also mentioned onPause() is a good place  to release BroadcaseReceiver.

Android Tutorial: Pausing and Resuming an Activity

On Google Android's Pausing and Resuming an Activity, things I learned could greatly improve or heal the performance of my current Android application. The most important things I learned are what should be done in onPause() and what should not be done in onPause(). These things will be listed below.

SHOULD Do in onPause():

  • Stop animations or other ongoing actions that could consume CPU.
  • Commit unsaved changes, but only if users expect such changes to be permanently saved when they leave (such as a draft email).
  • Release system resources, such as broadcast receivers, handles to sensors (like GPS), or any resources that may affect battery life while your activity is paused and the user does not need them.
SHOULD NOT Do in onPause():
  • NOT Store user changes (such as personal information entered into a form) to permanent storage, unless the auto-save function is needed to be implemented here.
  • NOT Perform CPU-intensive work, such as writing to a database. (This should be done in onStop()).
For onResume(), as the tutorial said, onResume() really depends on what are stopped in onPause() function, if anything is stopped or released in onPause(), then onResume() is the place to reinitialize and restart it if it's needed.

Friday, September 27, 2013

Android Tutorial: Starting an Activity

To rebuild my solid background of Android Development, I recently went through the whole tutorial provided from Google Android. Then, here comes the first lesson of "The Activity Lifecycle Management", to start an activity.

Though, most of staff on the page is known for me, there are still things I learned today here. Here follows a very important image which explains all the piece of Activity Lifecycle.

1st, onCreate() and onStart() function goes list a swift.

2nd, Most of UI and class member initialization work are done in onCreate() function.

3rd, Implementing your activity lifecycle methods properly ensures your app behaves well in several ways, including that it:
  • Does not crash if the user receives a phone call or switches to another app while using your app.
  • Does not consume valuable system resources when the user is not actively using it.
  • Does not lose the user's progress if they leave your app and return to it at a later time.
  • Does not crash or lose the user's progress when the screen rotates between landscape and portrait orientation.
4th, While stopped, the activity instance and all its state information such as member variables is retained, but it cannot execute any code.

5th, onDestroy(), this function is barely called in the code, unless the app has some background running thread, which might cause memory leak potentially.

6th, Note: The system calls onDestroy() after it has already called onPause() and onStop() in all situations except one: when you call finish() from within the onCreate() method. In some cases, such as when your activity operates as a temporary decision maker to launch another activity, you might call finish() from within onCreate() to destroy the activity. In this case, the system immediately calls onDestroy() without calling any of the other lifecycle methods.

Tuesday, September 3, 2013

Android Tutorial: Start Another Activity

For this section, I know most of the knowledge the author mentioned, but there are still 3 things I can learn.

1, Using Build Class to check the current version of SDK is very helpful.
2, These is a better implementation of action code when an activity's Action Bar go up button clicked.
     return true;
3, In Android Manifest.xml file, developer could easily set the parent activity (android:parentActivityName) of current activity class. The <meta-data> code is used for
android:parentActivityName="com.example.myfirstapp.MainActivity" >
            android:value="com.example.myfirstapp.MainActivity" />

Monday, September 2, 2013

Android Tutorial: Building a Simple User Interface

Today is the first day of my Android Tutorial Journey, I do believe the more I learn through Android Tutorial, the quicker I will leave my current company.

After Reading through this article, One thing caught my eyes, layout_weight.

I used this attributes a lot in my application, but I have never understood it well like I do today, now.

  1. The default weight for all views is 0.
  2. If you specify any weight value greater than 0 to only one view, then that view fills whatever space remains after all views are given the space they require.
So this could be the easiest way to have a button at the rightmost place of the screen, or have the button at the bottom of the view, while the ListView above it could have as much of space as it could take. In this case, developer do not need a RelativeLayout to implement this purpose.