Android Programming: Lecture 03


Published on

1) Android GUIs
2) Dynamic GUI Adjustment
3) Relative Layouts and Tabular Layouts
5) Application and Activity Lifetime
6) Screencasts and source code for
7) Class home page is at

Published in: Software, Technology, Art & Photos
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Android Programming: Lecture 03

  1. 1. Android Programming Lecture 03 Vladimir Kulyukin Department of Computer Science Utah State
  2. 2. Resources Source code and screencasts for this lecture are available at
  3. 3. Outline ● Q&A ● User Interfaces – Dynamic GUI adjustment – Relative Layouts – Tabular Layouts ● Application and Activity Lifetimes ● Managing Multiple Activities within an
  4. 4. Should I Verify Input Correctness? ● In the context of SE best practices, the answer is yes ● In the context of this class, the answer is: it is up to you ● Remember the constant tradeoff b/w conceptual clarity and industry best standards/practices ● Since this is a university course, given the choice b/w the two, I always chose conceptual clarity ● In practical terms, your submissions will be tested on valid inputs unless it is explicitly stated in the text of the assignment that you have to validate user
  5. 5. Graphical User Interfaces Dynamic GUI Adjustment, Relative and Tabular
  6. 6. Dynamic GUI Adjustment ● We have learned that there are two ways of GUI layout: programmatic and declarative ● There is no right way: programmatic excludes XML, increases code base, harder to maintain and debug; declarative relies on XML, decreases code base, easier to maintain and debug ● However, if dynamic GUI updates are a must, programmatic GUI manipulation is the only
  7. 7. Dynamic Linear Layout ● Let us create an application that allows us to manipulate with two properties of a linear layout: orientation and padding ● The user will be able to control through a GUI ● We will also learn how to use a radio group, another container object that consists of radio
  8. 8. GUI XML Tree LinearLayout LinearLayout RadioGroup RadioGroup TextView RadioButton RadioButton TextView RadioButton RadioButton Controls for layouts orientation RadioButton TextView Controls layouts padding This is the layout we will dynamically
  9. 9. GUI on Android RadioGroup RadioButton
  10. 10. DynamicLinearLayout Application ● DynamicLinearLayout Project can be downloaded from ● XML Source ● Java
  11. 11. Relative and Table
  12. 12. Relative Layout ● Relative layout (RelativeLayout) organizes views in terms of their relationships with each other and/or with their parent container ● If you use a relative layout, you should always assign IDs to your views in the XML layout file for easy of reference ● In a relative layout, you can place view X above/below view Y, align Xs top edge with the parent containers top edge,
  13. 13. Relative Layout: Relations with Containers ● There are many true/false properties to control a views relation with its parent container ● Two caveats: beware of deprecation, always test ● Here are some examples: – android:layout_alignParentTop – align views top with containers top – android:layout_alignParentBottom – align views bottom with containers bottom – android:layout_centerHorizontal – position view horizontally at containers center – android:layout_centerVertical – postion view vertical at containers
  14. 14. Relative Layout: Relations with Other Views ● If you want to position a view with respect to other views in a container, you need to do two things in XML: – Naming: assign explicit identifiers to all necessary elements using “@+id/...” notation – Referencing: Use “@id/...” notation (without the plus sign!) to reference other views while defining a given views position ● Here are some properties that specify a views position with respect to other views: android:layout_above, android:layout_below, android:layout_toLeftOf, android:layout_toRightOf,
  15. 15. Run Sum with Relative Layout LinearLayout Design RelativeLayout
  16. 16. XML of RelativeLayout
  17. 17. Table Layout ● Table layout is the Android GUI equivalent of HTML tables and Excel/OpenOffice spreadsheets ● Rows are controlled by the GUI designer ● Columns are controlled by Anroid ● The GUI designer can control the number of columns through properties like android:layout_span which indicates the number of columns a view should
  18. 18. Run Sum with Table Layout LinearLayout Design TableLayout
  19. 19. Application and Activity
  20. 20. Applications and Activities ● An application can be thought of as a set of GUIs/UIs and a set of back end modules ● An activity can be thought of as one GUI/UI screen of an application ● A typical application consists of several activities ● Activities and applications have their life cycles ● Bottom line: Android applications and activities do not control their own lifetimes; Android OS manages each applications process and, by extension, all activities within that
  21. 21. Android Application Class ● Extending the Android Application class ( should be considered under three scenarios: – Maintain application state – Transfer data among application components – Manage shared resources ● Application lifetime is determined by four events: creation, termination, low memory, and changes in
  22. 22. Applications Life Cycle Events ● Creation: override onCreate() to initialize state variables and shared resources ● Termination: override onTerminate() to customize the situation when the application is terminated; if the application is terminated by the kernel, the process is terminated w/o a call to onTerminate() ● Low Memory: override onLowMemory() to customize the situation when Android OS is running low on memory: clear caches, close files, etc ● Configuration Change: override onConfigurationChanged(): screen rotations, keyboard availability, locale change,
  23. 23. Activity Class ● Base Activity class is an empty screen (not too useful) ● Base Activity is extended to layout a screen, populate it with views, and attach the back end event handlers with some of the views ● Android Run Time manages each activitys application process and uses the activitys state to determine the parent applications priority ● The applications priority affects the likelihood that the Run Time will terminate it and all the activities running within
  24. 24. Activity States ● As activities are pushed and popped off the Activity Stack, they transition through four states: ● Active – activity is on top of the stack, visible, focused, foreground, receiving user input – Android Run Time keeps it alive at all costs terminating activities down the stack if necessary – If another activity becomes active, this activity is paused ● Paused – visible, not in focus, not receiving user input – if a paused activity becomes invisible, it is
  25. 25. Activity States ● Stopped – activity is not visible, remains in memory, candidate for termination – stopped activities should save its UI states and data – stopped activities that are closed or exited become inactive ● Inactive – not on the Activity Stack, must be restarted, prime candidate for
  26. 26. State Transitions ● State transitions are non-deterministic in the sense that it is all handled by the Android Run Time ● Android Run Time closes applications that contain inactive activities, followed by those that contain stopped activities, and, if absolutely necessary, those with paused activities ● Transitions b/w states should be invisible to the user: save all UI states and persist all data if activity is paused or
  27. 27. Activity State Event
  28. 28. Activity State Event Handlers public class MyActivity extends Activity { // Called when the Activity is first created public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); } }
  29. 29. Activity.onCreate() public class MyActivity extends Activity { // Called after onCreate() has finished, used to restore UI state public void onRestoreInstanceState(Bundle savedInstanceState) { super.onRestoreInstanceState(savedInstanceState); } }
  30. 30. Activity.onRestart() public class MyActivity extends Activity { // Called if the activity has been stopped and must be restarted public void onRestart() { super.onRestart(); // load changes if any because the activity has been visible // within this application } }
  31. 31. Activity.onStart() public class MyActivity extends Activity { // Called before the activity becomes visible (start of visible life time) public void onStart() { super.onStart(); // load changes if any because the activity has been visible // within this application } }
  32. 32. Activity.onResume() public class MyActivity extends Activity { // Called at the start of active life time public void onResume() { super.onResume(); // resume paused UI updates, threads, processes suspended // when the activity was inactive } }
  33. 33. Activity.onSaveInstanceState() public class MyActivity extends Activity { // Called at the end of active life time public void onSaveInstanceState(Bundle savedInstanceState) { super.onSaveInstanceState(savedInstanceState); // save UI state changes to this Bundle; this Bundle will be // passed to onCreate() if the process is killed and restarted } }
  34. 34. Activity.onPause() public class MyActivity extends Activity { // Called when the activity is paused public void onPause() { super.onPause(); // suspend UI updates, threads, processes } }
  35. 35. Activity.onStop() public class MyActivity extends Activity { // Called at the end of visible life time public void onStop() { super.onStop(); // persist all that remains to be persisted, the process is // likely to be terminated soon } }
  36. 36. Activity.onDestroy() public class MyActivity extends Activity { // Called at the end of full life time public void onDestroy() { super.onStop(); // clean up resources, ending threads, close db connections } }
  37. 37. Activitys Full Lifetime ● The full lifetime is b/w the call to onCreate() and the call to onDestroy() ● There is no guarantee that onDestroy() will be called ● onCreate() method is passed the Bundle object saved in the last call to onSaveInstanceState() ● Bundle object can be used to restore the UI state ● If you need to create objects, onCreate() is the method to create
  38. 38. Activitys Visible Lifetime ● The visible lifetime is b/w the call to onStart() and the call to onStop() ● The activity will be visible to the user but may or may not be in focus, may be partially obscured ● Activities are likely to go through several visible lifetimes in their full lifetime, because they may go from foreground to background and back several times ● onRestart() method is called immediately prior to all but the very first call to onStart()
  39. 39. Activitys Active Lifetime ● The active lifetime is b/w the call to onResume() and the call to onPause() ● The activity is in the foreground and receiving user input ● Activities are likely to go through several active lifetimes as they may be visible but not receiving user input ● onSaveInstanceState() is called immediately before onPause(); this method should save the UI state ● Safe assumption: onSaveInstanceState() and onPause() will be called before the process is
  40. 40. Multi-Activity Application ● Let us create an Application that will have three activities ● Objective 1 is to learn how to launch activities through Intents ● Objective 2 is to learn how to share data among activities within one application ● Objective 3 is to learn how to modify AndroidManifest.xml to handle multi-activity applications ● Objective 4 is to have more practice of XML GUI
  41. 41. ActivityInfoSharing Application ● ActivityInfoSharing Project can be downloaded from ● XML Source ● Java
  42. 42. Reading Suggestions ● ● Chapters 3 in Rito Meiers Professional Android 2 Application
  43. 43. Feedback Bugs, comments to vladimir dot kulyukin at gmail dot