Ch 3: Applications, Activities and Fragments

Question 1

Major Building Blocks

of

Android Applications

Answer 1

• Activities
• Services
• Intents
• Broadcast Receivers
• Content Providers
• Notifications

Question 2

Application Components:

Activities Overview

Answer 2

The presentation layer of an Application.

The UI is built around one or more extensions of the Activity class.

Activities use Fragments and Views to lay out and display information, and to respond to user actions.

Question 3

Application Components:

Services Overview

Answer 3

Service components run without a UI.

Used to perform long-running tasks, or tasks that require no user interaction (such as tasks that continue when Activities are not active or visible)

Common uses:

• updating data sources
• triggering Notifications
• broadcasting Intents

Question 4

Application Components:

Intents Overview

Answer 4

A powerful inter-application message-passing framework.

Used extensively throughout Android.

Types:

• Explicit
• Implicit
• Broadcast

Uses:

• Start and Stop Activities and Services
• Broadcast messages system-wide
• Broadcast message to a specific Activity, Service, or Broadcast Receiver
• Request an action be performed on a particular piece of data

Question 5

Application Components:

Broadcast Receivers Overview

Answer 5

Used to receive broadcast Intents.

Enables an application to listen for Intents that match some specified criteria.

• Broadcast Receivers start the application to react to any received Intent
• Perfect for creating event-driven applications

Question 6

Application Components:

Content Providers Overview

Answer 6

The preferred means to share data across application boundaries.

• An Application’s Content Providers can be configured to allow access from other applications
• Can access CPs exposed by others
• Android devices include several native Content Providers that expose useful databases such as the media store and contacts.

Question 7

Application Components:

Notifications Overview

Answer 7

Enable you to alert users to application events without stealing focus or interrupting their current Activity.

• Preferred technique for getting a user’s attention when app is not visible or active
• Typically triggered from within a Service or Broadcast Receiver
• Example:
  
  • User alerted via Notification when a text message arrives

Question 8

Overview of how Applications run

Answer 8

• Limited control over their own life cycle
  
  • App components must listen for changes in application state and react accordingly
• Each app runs in its own process, running a separate instance of the Android Run Time
  
  • Memory and process management is handled exclusively by the run time
• Android constantly and aggressively manages its resources to ensure a smooth and stable user experience
  
  • Apps may be asked to release some resources
  • Low priority apps may be terminated

Question 9

Application Priority:

Basic Priority Rules

Answer 9

• The order in which processes are killed to reclaim resources is determined by priority of their hosted applications
• An application’s priority is equal to that of its highest-priority component
• If two apps have the same priority,
  
  • the process which has been at that priority the longest will typically be killed first
• Interprocess dependencies:
  
  • If an app has a dependency on a Service or Content Provider from a second app, the secondary app is assigned AT LEAST as high a priority as the application it supports
• The state/visibility of an app mostly determine its priority level
• Android selects apps to kill using a last-seen-first-killed pattern
• Processes consuming more memory are more likely to be killed

Question 10

Application Priority:

Priority Levels

Answer 10

• Critical Priority:
  
  • Active Process
• High Priority:
  
  • Visible Process
• Medium Priority:
  
  • Started Background Service
• Low Priority:
  
  • Background Process

Question 11

Application Priority:

Priority Levels:

Critical Priority

Answer 11

Active(foreground) processes that have application components the user is interacting with.

• Generally very few of these processes
• Active processes include one or more of the following components:
  
  • Activities in an active state
  • Broadcast receivers executing “onReceive” event handlers
  • Services executing “onStart”, “onCreate” or “onDestroy” event handlers

Question 12

Application Priority:

Priority Levels:

High Priority

Answer 12

Visible Processes

• Visible but inactive processes
  
  • host “visible” Activities or foreground services
  • Visible, but not in the foreground or responding to user input
• Happens when:
  
  • Activity is only partially obscured( by a non-full screen or transparent Activity)
  • Non-active window in a multi-window environment

Question 13

Application Priority:

Priority Levels:

Medium Priority

Answer 13

Processes hosting background Services that have been started.

These services don’t interact directly with the user, so they receive a lower priority than visible Activities or foreground Services.

Question 14

Application Priority:

Priority Levels:

Low Priority

Answer 14

Background Processes

Processes hosting Activities that aren’t visible and that don’t have any running services.

• When a user switches applications, the previous application goes to the background
• Generally a large number of background apps

Question 15

Application Class:

Overview

Answer 15

• The Application object remains instantiated whenever the application is running
  
  • Unlike Activities, it is not restarted as a result of configuration changes
• Extending the Application class enables you to respond to application-level events broadcast by the Android Run Time
  
  • such as low memory conditions
• Instantiated when the application process is created.
• It is by nature a Singleton

Question 16

Activities:

Activity Basics

Answer 16

• Each Activity represents a screen that can be presented to users
• The more complex the app, the more screens will likely be needed
• Typically includes at least:
  
  • a “main Activity”
    
    • primary interface screen
    • handles the main UI functionality of the application
  • Secondary Activities
• To move between screens, a new Activity is started or the current Activity is returned from

Question 17

Creating Activities:

General Steps

Answer 17

1. Extend the Activity class (or one of it’s subclasses)
   
   • Probable subclass: AppCompatActivity
2. Register the Activity in the manifest
   
   • This is necessary to use the Activity within an application
3. Assign a UI
   
   • Use Fragments, layouts and Views
   • Perform in “onCreate” event handler
   • Use the setContentView method to assign View to the Activity
   • Generally, assign a layout that is defined in your res/layouts folder:
     
     • setContentView( R.layout.myLayout )
   • Alternatively, create views programmatically
4. Implement Functionality

Question 18

Creating Activities:

Registering an Activity in the Manifest

Answer 18

• To use an Activity in an app, it must be registered in the AndroidManifest.xml file
• Add a new <activity></activity> tag within the <application></application> node of the manifest
• The <activity></activity> tag includes attributes for metadata, including:
  
  • label, icon, required permissions, themes used
• Also includes a “name” attribute
• Can also add <intent-filter></intent-filter> nodes
  
  • Specify the Intents that can be used to start an activity
  • For an activity to be available from the application launcher, it must include an Intent Filter listening for the MAIN action and the LAUNCHER category

Question 19

AppCompatActivity:

Overview

Answer 19

• An Activity subclass available from the Android Support Library
• Provides ongoing backward compatibility for features added to the Activity class in each new platform release
• It is considered best practice to use AppCompatActivity instead of the Activity class

Question 20

Activity Life Cycle:

Important Terms and Ideas

Answer 20

• Activity Stack
  
  • Also called “Back Stack”
• Android Memory Manager
• Least-Recently Used (LRU) list
• Activity States
• Major Activity events + handlers
• State transitions
• Full Lifetime
• Visible Lifetime
• Active Lifetime
  *

Question 21

Activity Life Cycle:

Activity Stack

Overview

Answer 21

• Also called the “back stack”
• A last-in, first-out collection of all the currently running activities
• The position of an Activity within the Activity stack determines its State
• New foreground Activities are added to the top of the stack
• The next Activity moves up and becomes active when:
  
  • User presses the “back” button
  • The current foreground Activity closes

Question 22

Activity Life Cycle:

Least Recently Used (LRU) list:

Summary

Answer 22

Used to track the time since an Application was used.

When none of an Application’s Activities are visible, the App itself moves onto the LRU list.

The LRU list determines the order in which applications will be terminated to free resources.

Question 23

Activity Life Cycle:

Activity States:

list the states

Answer 23

• Active
• Paused
• Stopped
• Inactive

Question 24

Activity Life Cycle:

Activity States:

Active

Answer 24

• Activity is visible, focused, in the foreground and receiving user input
• It is at the top of the Activity stack
• Android attempts to keep it alive at all costs
  
  • kills applications that own Activities further down the stack as need to ensure this Activity has the resources it needs
• Transitions:
  
  • Paused when another Activity becomes active
  • Stopped when no longer visible

Question 25

Activity Life Cycle:

Activity States:

Paused

Answer 25

• Activity is visible but does not have focus
• May also be paused when the application is being used in a multi-window environment
  
  • Only the Activity that the user last interacted with is considered Active
• Activity is treated as if it were active, but doesn’t receive user input events
• Only killed for resources in extreme cases
• Transitions:
  
  • Stopped when the Activity is totally obscured
  • All Activities transition through the Paused state before becoming Stopped

Question 26

Activity Life Cycle:

Activity States:

Stopped

Answer 26

• When an Activity isn’t visible, it “stops”
• Remains in memory, retaining all state information
• Now a likely candidate for termination when system needs more memory
• Once in a Stopped State, it is important to:
  
  • save data
  • save current UI state
  • stop any non-critical operations
• Transitions:
  
  • becomes Inactive once Activity has exited or closed

Question 27

Activity Life Cycle:

Activity States:

Inactive

Answer 27

• Activity doesn’t really “exist”
• In this state after being killed, and before it is launched
• Inactive Activities have been removed from the Activity Stack
• Transitions:
  
  • To be displayed or used, the Activity must be restarted(this puts it into the Active state)

Question 28

Activity Life Cycle:

Activity States:

Notes about Transitions

Answer 28

• Transitions between states should be invisible to the user
  
  • No difference between an activity moving from paused, stopped or inactive state back to active
  • It is important to save all UI state and persist all data when stopped
• Best Practice:
  
  • Any time consuming state persistence operations should be performed when an Activity transitions to the stopped state( onStop() handler)
• Activities may transition between Paused and Active very frequently - So this transition should execute very quickly

Question 29

Activity Life Cycle:

Activity States:

How does an App control its State Transitions?

Answer 29

It doesn’t.

State Transitions occur through User and System actions.

Similarly, the Android Memory Manager handles application termination.

Question 30

Activity Life Cycle:

The Full Lifetime:

When it occurs

Answer 30

​

Between the first call to onCreate() and when the Activity is destroyed

onDestroy() is not necessarily called when the Activity is destroyed

Question 31

Activity Life Cycle:

The Visible Lifetime:

When it occurs

Answer 31

The Visible Lifetime is the time between

starting an Activity - onStart()

and

stopping an Activity - onStop()

An Activity can have many Visible Lifetimes within one Full Lifetime

Question 32

Activity Life Cycle:

The Active Lifetime:

When it occurs

Answer 32

The Active Lifetime

starts when Activity is resumed - onResume()

and

ends when Activity is paused - onPause()

An Activity is likely to go through MANY active lifetimes before it is destroyed

Question 33

Activity Life Cycle:

Full Lifetime:

Important Event Handlers

Answer 33

• onCreate()
  
  • Initializes Activity and all components
  • Objects should be created here
  • If recreating a terminated Activity, receives a Bundle object containing state saved with onSaveInstanceState()
• onDestroy()
  
  • Clean up any resources created in onCreate(), ensure all external connections are closed
  • Not guaranteed to be called when Activity destroyed

Question 34

Activity Life Cycle:

Visible Lifetime:

Important Event Handlers

Answer 34

• onRestart()
  
  • Called before onStart(except for the first call)
  • Implement special processing only needed when Activity restarts within its full lifetime
• onStart()
  
  • Register Broadcast Receivers for UI
  • First Call: Start required UI updating processes
  • else, resume processes stopped in the onStop() handler
• onRestoreInstanceState(Bundle savedInstanceState)
  
  • called when Activity is started after having been destroyed
  • Restores previous UI state using the passed in savedState Bundle
• onStop()
  
  • unregister Broadcast Recievers for UI
  • pause or stop:
    
    • animations
    • threads
    • Sensor listeners
    • GPS lookups
    • Timers
    • Services
    • other processes used only for updating UI

Question 35

Activity Life Cycle:

Active Lifetime:

Important Event Handlers

Answer 35

• onResume()
  
  • Resume any paused UI updates, threads or processes required by the Activity while it is active
• onPause()
  
  • Suspend UI updates, threads or processes not needed when Activity is not Active
• onSaveInstanceState(Bundle savedInstanceState)
  
  • Called when appropriate to save UI state changes at the end of the active lifecycle
  • UI state is saved to savedInstanceState bundle
  • savedInstanceState can be used in the onCreate() and onRestoreInstanceState() handlers in the future to restore the current UI state

Question 36

Activity Life Cycle:

Important

Activity State

Event Handlers

Answer 36

• onCreate(Bundle savedInstanceState)
• onRestart()
• onStart()
• onRestoreInstanceState(Bundle savedInstanceState)
• onResume()
• onPause()
• onSaveInstanceState(Bundle savedInstanceState)
• onStop()
• onDestroy()

Question 37

Memory Pressure:

Event used by the system to

request reduced memory usage

Answer 37

TrimMemory

individual components handle this by overriding the onTrimMemory() handler

Question 38

Memory Pressure:

Overview

Answer 38

• The Android system will terminate apps without warning to free resources for active and visible apps
• It is ideal to retain as many background apps as possible, to improve experience of switching between apps
• The order of termination is determined by:
  
  • Position on LRU list
  • Amount of memory that would be freed
• App components are given a chance to free additional memory, making termination less likely, by implementing the onTrimMemory() handler

Question 39

Memory Pressure:

onTrimMemory()

Level Parameters

Answer 39

• TRIM_MEMORY_RUNNING_MODERATE
• TRIM_MEMORY_RUNNING_LOW
• TRIM_MEMORY_RUNNING_CRITICAL
• TRIM_MEMORY_UI_HIDDEN
• TRIM_MEMORY_BACKGROUND
• TRIM_MEMORY_MODERATE
• TRIM_MEMORY_COMPLETE

Question 40

Memory Pressure:

onTrimMemory levels meaning:

TRIM_MEMORY_RUNNING_MODERATE

Answer 40

App is running and not being considered for termination,

but the system is beginning to feel memory pressure

Question 41

Memory Pressure:

onTrimMemory levels meaning:

TRIM_MEMORY_RUNNING_LOW

Answer 41

• App is running and not being considered for termination,
• System is running extremely low on memory
• System will now begin killing background processes if apps don’t free resources
• By releasing non-critical resources now, this app can prevent performance degradation and reduce the chance of other apps being terminated

Question 42

Memory Pressure:

onTrimMemory levels meaning:

TRIM_MEMORY_UI_HIDDEN

Answer 42

• Application is no longer displaying a visible UI
• Good opportunity to release large resources that are only used by the UI
• It is considered good practice to release these resources here, rather than within the onStop handler
  
  • Avoids purging/reloading UI resources if the UI quickly switches from hidden to visible

Question 43

Memory Pressure:

onTrimMemory levels meaning:

TRIM_MEMORY_BACKGROUND

Answer 43

• Application is no longer visible and has been added to the least-recently used (LRU) list
• App is now a low-risk candidate for termination
• System is running low on memory and may already be killing other apps on the LRU list
• Release resources that are easy to recover now, to reduce system pressure and make application less likely to be terminated

Question 44

Memory Pressure:

onTrimMemory levels meaning:

TRIM_MEMORY_MODERATE

Answer 44

• Application is in the middle of the LRU list
• The system is running low on memory
• If the system becomes further constrained for memory, there is a good chance your process will be killed

Question 45

Memory Pressure:

onTrimMemory levels meaning:

TRIM_MEMORY_COMPLETE

Answer 45

• This app is one of, if not THE, most likely candidates for termination if the system does not recover memory immediately.
• Release absolutely everything that isn’t critical to resuming the application state

Question 46

Fragments:

Overview

Answer 46

Fragments enable you to divide Activities into fully encapsulated, resusable components that each have their own lifecycle and state.

• Each Fragment is an independent module
• Loosely coupled, but tightly bound to the Activity
• A Fragment can be used in multiple activitities
• Can be added to, removed from, and exchanged within a running Activity

Question 47

Fragments:

Creating a Fragment

Answer 47

• If the Fragment contains a UI, create an XML file to define the layout
• Create a new class that extends the Fragment class
• Note: The Fragment DOES NOT have to be registered in your manifest
• For Fragments that require a UI:
  
  • Override the onCreateView method
    
    • Inflate the layout
    • or define programmatically
  • onCreateView includes a parameter for the ViewGroup that will contain the Fragment, called “container”

Question 48

Fragment Lifecycle:

Basics

Answer 48

• Lifecycle events of Fragment mostly mirror those of its parent Activity
• When the Activity is active, a Fragment can still be added or removed, independently affecting its life cycle
• Most Fragment lifecycle events correspond to equivalents in the Activity class

Question 49

Fragment Lifecycle:

Events that are specific to Fragments

Answer 49

• Attaching
  
  • Fragment is bound to it’s parent’s Context
  • onAttach handler
• Detaching
  
  • Remove a Fragment from its parents
  • or containing component destroyed
  • onDetach handler
• Create View
  
  • Initializes/inflates the UI of the Fragment, gets references and binds data to the Views in the Fragment
  • onCreateView handler
• Destroy View
  
  • Destroy the UI of the Fragment
  • onDestroyView handler

Question 50

Fragment Lifecycle:

Major Event Handlers

(12)

Answer 50

• onAttach()
• onCreate()
• onCreateView()
• onActivityCreated()
• onStart()
• onResume()
• onPause()
• onSaveInstanceState()
• onStop()
• onDestroyView()
• onDestroy()
• onDetach()

Question 51

Fragment Lifecycle:

Major Event Handlers:

onAttach()

Answer 51

onAttach( Context context )

• Called when the Fragment is attached to its parent Activity
• Use to get a reference to a Context representing the parent component

Question 52

Fragment Lifecycle:

Major Event Handlers:

onCreate()

Answer 52

onCreate( Bundle savedInstanceState )

• Called to do the initial creation of the Fragment
• Good practice to create any class-scoped objects here to ensure they are only created once during the Fragment’s lifetime
• Unlike Activity, Fragment UI is NOT inflated here, that is saved for onCreateView

Question 53

Fragment Lifecycle:

Major Event Handlers:

onCreateView

Answer 53

onCreateView( LayoutInflater inflator,

ViewGroup container,

Bundle savedInstanceState)

• Called once the Fragment has been created in order for it to create is user interface
• Create, or inflate the Fragment UI, returning the View
• If Fragment has no UI, returns null

Question 54

Fragment Lifecycle:

Major Event Handlers:

onActivityCreated()

Answer 54

onActivityCreated( Bundle savedInstanceState)

• Called once the parent Activity and the Fragment’s UI have been created
• Complete the Fragment initialization, particularly:
  
  • anything that requires the parent Activity to be initialized
  • or requires the Fragment’s View to be fully inflated

Question 55

Fragment Lifecycle:

Major Event Handlers:

onStart()

Answer 55

onStart()

• Called at the start of the visible lifetime
• Apply any required UI change now that the Fragment is visible

Question 56

Fragment Lifecycle:

Major Event Handlers:

onResume()

Answer 56

onResume()

• Called at the start of the active lifetime
• Resume any paused UI updates, threads, or processes required by the Fragment but suspended when it became inactive

Question 57

Fragment Lifecycle:

Major Event Handlers:

onPause()

Answer 57

onPause()

• Called at the end of the active lifetime
• Suspend UI updates, threads or CPU intensive processes that don’t need to be updated when Activity is not the active foreground activity
• Persist all edits or state changes
• After this call, process is likely to be killed

Question 58

Fragment Lifecycle:

Major Event Handlers:

onSaveInstanceState()

Answer 58

onSaveInstanceState(

Bundle savedInstanceState)

• Called to save UI state changes at the end of the active lifecycle
• Save UI state changes to the savedInstanceState
• This bundle will be passed to onCreate(), onCreateView(), and onActivityCreated() if the parent Activity is killed and restarted

Question 59

Fragment Lifecycle:

Major Event Handlers:

onStop()

Answer 59

onStop()

• Called at the end of the visible lifetime
• Suspend remaining UI updates, threads, or processing that are not required when the Fragment isn’t visible

Question 60

Fragment Lifecycle:

Major Event Handlers:

onDestroyView

Answer 60

onDestroyView()

• Called when the Fragment’s View has been detached
• Clean up resources related to the View

Question 61

Fragment Lifecycle:

Major Event Handlers:

onDestroy()

Answer 61

onDestroy()

• Called at the end of the full lifetime
• Clean up any resources, including ending threads, closing database connections, etc

Question 62

Fragment Lifecycle:

Major Event Handlers:

onDetach()

Answer 62

onDetach()

• Called when the Fragment has been detached from the parent Activity
• Clean up any references to the parent Activity
  
  • including references to its Views or classes, typically setting those references to null

Question 63

Fragment Manager:

Basics

Answer 63

• Each Activity includes a Fragment Manager
  
  • Accessed using the method:
    
    • getSupportFragmentManager()
• It provides the methods used to access the Fragments that are currently added to the Activity
• Also provides methods to perform Fragment Transactions to add, remove and replace Fragments

Question 64

How to Add Fragments to Activities

Answer 64

Two Basic Ways:

• Include the Fragment within the parent Activity’s layout, using the <fragment> tag
  </fragment><ul>
  <li>When layout is inflated, the fragment becomes a View Group within the view hierarchy</li>
  <li>Works well for static layouts based on various screen sizes</li>
  </ul></fragment>

or

• Create layouts that use container Views, then place Fragments into them at run time
  
  • This allows you to dynamically modify the layout by adding,removing and replacing fragments based on the application state

Question 65

Fragment Transactions:

Basics

Answer 65

• Used to add, remove and replace Fragments within an Activity at run time
• Allows for dynamic layouts
• Can include any combination of supported actions:
  
  • adding, removing, or replacing Fragments
• Support transition animations
• Obtained from Fragment Manager, has actions added to it, then committed to perform the Transaction

Question 66

Fragment Transactions:

Replacing a Fragment

Answer 66

• Get new Fragment Transaction:
  
  • FragmentTransaction trans = fragmentManager.beginTransaction();
• Use the replace() method of the transaction, specifying the container ID, a new Fragment to replace the old one, and optionally a Tag for the new Fragment:
  
  • trans.replace( R.id.details_container,

new DetailFragment(some_index),

FRAG_TAG);

• Commit the Transaction:
  
  • trans.commitNow();

Question 67

Fragment Transactions:

Removing a Fragment

Answer 67

• Get new Fragment Transaction:
  
  • FragmentTransaction trans = fragmentManager.beginTransaction();
• Get reference to the Fragment, through the Fragment Manager, using either method:
  
  • findFragmentById() or
  • findFragmentByTag()
• Pass the found Fragment instance as a parameter to the remove() method of a Fragment Transaction:
  
  • trans.remove(fragment)
• Commit the Transaction:
  
  • trans.commitNow();

Question 68

Fragment Transactions:

Adding a Fragment

Answer 68

• Create the Fragment Tag(optional):
  
  • String FRAG_TAG = “myTag”
• Have handle to FragmentManager ready
• Get new Fragment Transaction:
  
  • FragmentTransaction trans = fragmentManager.beginTransaction();
• Specify the “add” action with the container, fragment and tag:
  
  • trans.add(R.id.details_container, new DetailFragment(), FRAG_TAG);
• Commit the Transaction:
  
  • trans.commitNow();

Question 69

Fragments:

Finding Fragments

with the

Fragment Manager

Answer 69

Two basic methods:

• findFragmentById( int frag_id | container_id)
  
  • If Fragment was added in the layout, use the fragment’s own id ( R.id.MyFragment)
  • If Fragment dynamically added at runtim, use the id of the Container (R.id.my_container)
• • findFragmentByTag(**String tag**)
    
    • essential for dealing with non-UI Fragments, as they are not part of the View Hierarchy

Question 70

Fragments:

Populating Dynamic Layouts and

Dealing with Configuration Changes:

Tips and Best Practices

Answer 70

• Define only the parent containers with the XML layout
• Populate the parent containers exlusively using Fragment Transactions
  
  • This ensures consistency when configuration changes(such as screen rotations) cause the UI to be re-created
• Android persists the Fragment layout and associated back stack when an Activity is restarted due to configuration changes
  
  • Fragment Manager will attempt to restore the Fragments in each container after configuration changes
• Any view containers that are involved in any transactions should be included in all layout variations
  
  • If not, Fragment manager may attempt to restore Fragments in containers that no longer exist
• A Fragment container can be removed from a given orientation layout by marking its “visibility” attribute as “gone” in the layout definition

Question 71

Fragment Transactions:

Using the Back Stack

Answer 71

• Fragment Transactions can be added to the Back Stack
  
  • simply call the Fragment Transaction method
    
    • addToBackStack( BACKSTACK_TAG )
  • Prior to committing the Transaction
• Note: Must use the commit() method afterwards, cannot use commitNow()
• Pressing the back button will reverse the Transaction
  
  • If any removals or replacements occured, the previous fragments are restored from the backstack

Question 72

Fragment Transactions:

Animating Fragment Transactions

Answer 72

• Simply use the setTransition( Transition_ID ) method on a transaction prior to committing
• There are several default animations, defined by the set of constants in FragmentTransaction class:
  
  • TRANSIT_FRAGMENT_*
• Can also set custom animations
• Prior to add or remove methods, use the method:
  
  • setCustomAnimations( anim_in, anim_out )
• Accepts two Object Animator XML resources, one for fragments being added to the layout, one for fragments being removed

​

Question 73

Fragments:

Communicating between

Fragments and Activities

Answer 73

• A Fragment may need to share events with its parent Activity
  
  • Ex: Signaling UI selections
• Good practice is to create a callback interface within the Fragment
  
  • The host Activity must then implement this interface
  • In the onAttach() method, the Fragment adds the Context(Parent Activity) as a listener
  • Fragment can then call methods defined in the interface when it wants to
• Can also just use the getContext method to get a pointer to the host activity
• It is considered best practice for Fragments not to communicate directly with each other, but to go through the parent activity

Question 74

Fragments:

Fragments Without User Interfaces

Answer 74

• Useful for providing background behavior which persists across Activity restarts caused by configuration changes
• Added to the Activity ar runtime using a Fragment Transaction with the add method.
• Later found using a Tag
• Select a Fragment to retain its current instance using the setRetainInstance() method
  
  • The Fragment instance will be retained when the parent Activity is destroyed and re-created
  • When parent destroyed, receives the onDetach event
  • When new parent Activity is instantiated, receives onAttach, onCreateView and onActivityCreated events