Android activities & views
- 1. Activities and Views Ilio Catallo, Eleonora Ciceri – Politecnico di Milano ilio.catallo@polimi.it, eleonora.ciceri@polimi.it 1
- 2. Androidinterface 2 Recent button Jump instantly from one task to another by navigating a list of recently opened apps Home button Visualize the Android home screen Back button Move backward through the history of screens users previously visited
- 4. Activities and Views ¤ The activity is a single, focused thing that the user can do ¤ Each activity is associated with a window in which to draw the user interface ¤ The view is the basic building block for user interface components ¤ Responsible for drawing and event handling ¤ Examples: button, textbox 4
- 5. Applicationbuilding blocks:UIcomponents 5 View View The Activity is the task that can be performed by interacting with the user interface
- 6. Analogy: web pages and activities Website Application 6 Home page Main activity Navigation among various pages Navigation among various activities
- 7. Activities and use case diagrams ¤ Roughly, each activity corresponds to a use case ¤ As such, the use case diagram could also serve as the graph of connected activities 7 User Use case 1 Use case 2 Use case 3 <includes> Use case 4<includes>
- 9. Activity lifecycle ¤ The activity lifecycle: ¤ Begins with instantiation ¤ Ends with destruction ¤ Includes many states in between ¤ Whenever a state change is required, the activity: ¤ is notified of the impending state change ¤ is allowed to execute the code in order to adapt itself to that change 9
- 10. Activity lifecycle ¤ The state of each Activity is determined by its position on the Activity stack ¤ The Activity stack is a last-in-first-out collection of all the currently running activities ¤ When a new Activity starts, it becomes active and is moved to the top of the stack ¤ If the user navigates back (using the Back button) or the foreground Activity is closed, the next Activity down on the stack moves up and becomes active 10
- 11. Activity lifecycle ¤ As Activities are created and destroyed, they transition through four possible states: ¤ Active (running) ¤ Paused ¤ Stopped ¤ Inactive (destroyed) 11 FrontBack
- 12. Activity lifecycle ¤ Active (running) Activity ¤ Visible, focused, foreground activity that is receiving user input ¤ At the top of the stack ¤ Kept alive at all costs! ¤ If it does not have the resources it needs, other Activities will be killed 12 FrontBack
- 13. Activity lifecycle ¤ Paused Activity ¤ Visible but not focused ¤ This state is reached if a transparent or non-full- screen Activity is active in front of it ¤ Treated as if it were active, but without user input events 13 FrontBack
- 14. Activity lifecycle ¤ Stopped Activity ¤ Not visible ¤ It remains in memory, retaining all state information ¤ It is a candidate for termination when the system requires memory elsewhere 14 FrontBack
- 15. Activity lifecycle ¤ Inactive (destroyed) Activity ¤ Removed from the Activity stack ¤ Needs to be restarted before it can be displayed and used 15 FrontBack
- 16. Activitylifecycle ¤ The activity lifecycle is implemented as a collection of methods the OS calls throughout the lifecycle of an activity 16 onCreate() onStart() onResume() onPause() onResume() onStop() onRestart() onStart() onDestroy()
- 17. Activitylifecycle ¤ The activity lifecycle is implemented as a collection of methods the OS calls throughout the lifecycle of an activity 17 The activity does not exist in memory
- 18. Activitylifecycle ¤ The activity lifecycle is implemented as a collection of methods the OS calls throughout the lifecycle of an activity 18 onCreate() onStart() onResume() The activity is currently on the screen and interacting with the user Create views, initialize variables Actions performed at the end of onCreate(), right before displaying the activity Start animations, listen from GPS/camera updates
- 19. Activitylifecycle ¤ The activity lifecycle is implemented as a collection of methods the OS calls throughout the lifecycle of an activity 19 onPause() The activity is not in focus but still visible on the screen
- 20. Activitylifecycle ¤ The activity lifecycle is implemented as a collection of methods the OS calls throughout the lifecycle of an activity 20 onResume() A paused activity is resumed when it returns visible on the screen
- 21. Activitylifecycle ¤ The activity lifecycle is implemented as a collection of methods the OS calls throughout the lifecycle of an activity 21 onStop() The activity is not visible but in memory, waiting for the user to restart it soon
- 22. Activitylifecycle ¤ The activity lifecycle is implemented as a collection of methods the OS calls throughout the lifecycle of an activity 22 onRestart() onStart() When the user requires an interaction with a stopped activity, it is restarted
- 23. Activitylifecycle ¤ The activity lifecycle is implemented as a collection of methods the OS calls throughout the lifecycle of an activity 23 onDestroy() A destroyed activity is no longer in memory. Before the activity is destroyed, it can perform some actions
- 24. Differences between Home and Back ¤ When user presses Back ¤ The activity is destroyed ¤ Operations: onPause() – onStop() – onDestroy() ¤ When user presses Home ¤ The foreground activity is NOT destroyed ¤ Operations: onPause() – onStop() ¤ Note: the behavior in the emulator may differ 24
- 25. Configuration changes ¤ Configuration changes are rapid activity destruction/re- creation cycles that occur when the configuration of an activity changes ¤ Examples ¤ Device rotation: the activity needs to be rebuilt ¤ Keyboard is displayed: the activity is resized 25
- 26. Implementing lifecycle methods ¤ It is extremely important for the application developer to: ¤ analyze the requirements of each activity ¤ determine which methods need to be implemented ¤ Failure to do this can result in ¤ Application instability and crashes ¤ Resource bloat ¤ Underlying OS instability ¤ You should never call any lifecycle methods yourself! 26
- 27. TakeNotes v1: ToDoListActivity.java ¤ Created as a default (blank) activity ¤ In Android Studio: File > New > Other… > Android > Android Activity 27 public class ToDoListActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_to_do_list); } } The file res/layout/activity_to_do_list.xml defines the structure of the activity that is loaded when the activity is created
- 29. User interface ¤ Each Activity in the app is associated with a user interface (UI) 29 User interface activity
- 30. User interface: View and ViewGroup ¤ User interfaces are built using View’s and ViewGroup’s: ¤ A View is a widget that has an appearance on the screen ¤ A ViewGroup is a special View that contains other Views in order to define the layout of the interface ¤ In other words, each ViewGroup is an invisible container that organizes child Views, and Views are any widget that draws some part of the UI 30
- 31. User interface: View and ViewGroup ¤ The UI for each component of the app is defined using a hierarchy of View and ViewGroup objects 31
- 32. User interface: View and ViewGroup ¤ The UI for each component of the app is defined using a hierarchy of View and ViewGroup objects 32
- 33. User interface layout ¤ Each subclass of ViewGroup defines the layout, i.e., the arrangement, of its child views on the screen 33 LinearLayout RelativeLayout
- 34. User interface layout: LinearLayout ¤ A LinearLayout organizes its children into: ¤ Either a single horizontal row ¤ Or a single vertical row 34
- 35. User interface layout: RelativeLayout ¤ A RelativeLayout enables you to specify the location of child objects: ¤ either relative to each other ¤ or relative to the parent 35
- 36. User interface: View and ViewGroup ¤ Android provides a collection of View and ViewGroup subclasses that cover most common situations: ¤ Views: input controls, e.g., TextView class, Button class, CheckBox class ¤ ViewGroup: layout models, e.g., LinearLayout class, RelativeLayout class ¤ However, if your app has unique need that is not covered by the built-in views, it is possible to create a custom View by extending the View class 36
- 37. LinearLayout ViewGroup ¤ The LinearLayout arranges views in a single column or a single row ¤ Attributes ¤ layout_width: specifies the width of the ViewGroup ¤ layout_height: specifies the height of the ViewGroup ¤ orientation: vertical or horizontal ¤ Default values for attributes ¤ fill_parent: makes the component expand to match the size of its parent view ¤ wrap_content: the width or height of the view is set to the minimum size necessary to fit the content within that view 37
- 38. ScrollView ViewGroup ¤ The ScrollView enables users to scroll through a list of views that occupy more space than the physical display ¤ You should place one child in it containing the entire contents to scroll ¤ A child that is often used is LinearLayout, which in turn contains some other views ¤ By doing so, the content of the LinearLayout will be scrollable 38
- 39. ScrollView ViewGroup 39 Screen ScrollView width: fill_parent height: fill_parent LinearLayout width: fill_parent height: wrap_content orientation: vertical
- 40. TakeNotes v1: activity_to_do_list.xml 40 Add a static checkbox to the checkbox list A new string in the resource file specifies the content of the default checkbox: <string name="first_checkbox_text"> Conclude the implementation of TakeNotes </string> <ScrollView xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:layout_width="fill_parent" android:layout_height="fill_parent" tools:context=".ToDoListActivity"> <LinearLayout android:layout_width="fill_parent" android:layout_height="wrap_content" android:orientation="vertical"> <CheckBox android:id="@+id/checkBox1" android:layout_width="fill_parent" android:layout_height="wrap_content" android:layout_marginTop="32dp" android:text="@string/first_checkbox_text"/> </LinearLayout> </ScrollView>
- 41. TakeNotes v1: the result 41 Resource @drawable/ic_launcher Resource @string/app_name View Checkbox Resource @string/first_checkbox_text Activity ToDoListActivity.jav a
- 42. Android vs. MVC
- 43. Patterns ¤ Patterns are distilled commonality that you find in programs ¤ They provide a general solution to a class of problems ¤ Patterns allow developers to deconstruct a complex system into smaller, simpler parts 43
- 44. Architectural vs. design patterns ¤ Software goes through a series of deconstruction at different levels ¤ Architectural patterns pertain to the structural organization of software system ¤ Design patterns are associated with code level commonalities, and can be influenced by the specific programming language at use 44
- 45. Model-View-Controller pattern ¤ In the late seventies, software architects saw applications as having three major parts: ¤ The part that manages the data (Model) ¤ The part that creates screens and reports (View) ¤ The part that handles interactions between the user and the other subsystems (Controller) 45
- 47. MVC is a concept ¤ Remember: there is no universal MVC pattern. MVC is a concept rather than a solid pattern ¤ In fact, it is not even clear whether MVC is a design pattern or an architectural pattern 47
- 48. Many MVC declinations ¤ As a rule of thumb, you are adopting the MVC pattern if the application includes: ¤ A set of classes containing what to render (Model) ¤ A set of classes that know how to render those data (View) ¤ A set of classes that contains the interaction logic (Controller) 48
- 49. Android vs. MVC ¤ Android does not explicitly embrace MVC ¤ Still, some developers prefer to frame Android app development within the precepts of the MVC pattern 49
- 50. Android MVC declination 50 User input View Controller User interacts with view object View sends message to controller Model controller updates model objects controller takes from model objects data needed by the views controller updates view with changes in the model objects
- 51. TakeNotesvs.MVC 51 TextView Button Checkbox Checkbox Checkbox ToDoListActivity Todo Todo Todo Model Controller View The model objects hold the data and the business logic of the app the controller responds to the events triggered by view objects and manage the flow of data to and from model objects View objects know how to draw themselves on the screen and how to respond to user input
- 52. References 52
- 53. References ¤ Android API Guides, UI Overview http://developer.android.com/guide/topics/ui/overview. html ¤ Android API Guides, Layoutshttp://developer.android.com/guide/topics/ui/d eclaring-layout.html ¤ Google I/O 2013 - Structure in Android App Design https://www.youtube.com/watch?v=XpqyiBR0lJ4 ¤ The Big Nerd Ranch Guide to Android Programming, B. Phillips, B. Hardy 53