1.broadcast receivers can be either declared in the manifest or created dynamically in code (as objects) and registered with the system by calling.

2.Building an Intent-Component name:

When starting a , you shouldalways specify the component name. Otherwise, you cannot be certain what service will respond to the intent, and the user cannot see which service starts.

3.implicit intent:

It's possible that a user won't have anyapps that handle the implicit intent you send to . If that happens, the call will fail and your app will crash. To verify that an activity will receive the intent, call on your object. If the result is non-null, then there is at least one app that can handle the intent and it's safe to call. If the result is null, you should not use the intent and, if possible, you should disable the feature that issues the intent.

4.intent filters- :

In order to receive implicit intents, you  must include the  category in the intent filter. The methods  and  treat all intents  as if they declared the category.  If you do not declare this category in your intent filter, no implicit intents will resolve to  your activity.

tip: To avoid inadvertently running a different app's, always use an explicit intent to start your own service and do not declare intent filters for your service.

 5.Shutting Down an Activity-,:

Note: In most cases, you should not explicitly finish an activity using these methods.The Android system manages the life of an activity for you, so you do not need to finish your own activities. Calling these methods could adversely affect the expected user experience and should only be used when you absolutely do not want the user to return to this instance of the activity.

6.You should use to write crucial persistent data (such as user edits) to storage. However, you should be selective about what information must be retained during , because any blocking procedures in this method block the transition to the next activity and slow the user experience.

7.The system calls before making the activity vulnerable to destruction. The system passes this method a in which you can save  state information about the activity as name-value pairs, using methods such as and . Then, if the system kills your application process and the user navigates back to your activity, the system recreates the activity and passes the to both and . Using either of these methods, you can extract your saved state from the and restore the activity state. If there is no state information to restore, then the passed to you is null (which is the case when the activity is created for the first time).

8.Activity-Fragment-Transaction-commit():

You can commit a transaction using  only prior to the activity  (when the user leaves the activity). If you attempt to commit after that point, an exception will be thrown. This is because the state after the commit can be lost if the activity needs to be restored. For situations in which its okay that you lose the commit, use .

9.The most significant difference in lifecycle between an activity and a fragment is how one is stored in its respective back stack. An activity is placed into a back stack of activities that's managed by the system when it's stopped, by default (so that the user can navigate back to it with the Back button, as discussed in ). However, a fragment is placed into a back stack managed by the host activity only when you explicitly request that the instance be saved by calling  during a transaction that removes the fragment.

10.Loader tip:

the given  implementation is associated with the loader, and will be called when the loader state changes. If at the point of this call the caller is in its started state, and the requested loader already exists and has generated its data, then the system calls  immediately (during ), so you must be prepared for this to happen. See  for more discussion of this callback

11.