android-lifecycle

Why are the lifeCycle methods in android have access specifiers as protected ? what i understand about Access-specifiers is as below :: But why should we need to make all the life-cycle methods as protected I notice this when i override the lifecycle methods I know over-riding the methods of Activity class as methods in Activity class are defined protected But why are they defined as protected Sam They are protected for encapsulation within the framework package android.app and subclasses. They are to be called by android.app.ActivityManager (same package) only. Depending on the method

I need to know inside my app whether bluetooth is on or off. Or if bluetooth was turned on or off e.g. from the OS settings pulldown menu. I thought I could do this in the Activity's onResume() . But it turns out that the activity is not paused when the Android OS's settings "pulldown menu" (the one that is accessed by pulling down with a finger from the top edge of the screen) is opened. I need to update my UI when bluetooth becomes available or unavailable. Can I register for a callback (e.g. a BroadcastReceiver ) or any other callback to let the system tell me when Bluetooth availability

I'm having a very strange problem with my app, which consists of an Activity and 2 Fragments (android.support.v4.app.Fragment). The problem is when I rotate my tablet : the app crashes right away. A few days before, everything was working fine, but I had to change packages name, that threw a few errors but I manage to correct them. Problem appeared right after that, but I just can't find where is the error. Here is the Logcat I get right after the app is destroyed, restarted, resumed and created : 10-08 17:00:14.930: D/dalvikvm(18155): GC_CONCURRENT freed 394K, 8% free 7792K/8455K, paused 1ms

In my current application the onResume function is triggered when I load an Activity for the first time . I looked into the Activity Lifecycle , but I didn't find a way to prevent this from happening. Can I prevent the onResume() function from loading when an Activity is loaded for the first time, without using SharedPreferences? Firstly, as RvdK says, you should not modify the Android Activity lifecycle, you probably have to re-design your activity behavior in order to be compliant with it. Anyway, this is the best way that I see: 1.Create a boolean variable inside your Activity public class

The docs concerning Activity recreation state: 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. The docs for View.setTag(Object) state: Sets the tag associated with this view. A tag can be used to mark a view in its hierarchy and does not have to be unique within the hierarchy. Tags can also be used to store data within a

I have a project for HoneyComb and I get an error after use recreate() method at onResum() method in my main Activity. 11-10 22:05:42.090: E/ActivityThread(1917): Performing pause of activity that is not resumed: {com.blogspot.honeyapp/com.blogspot.honeyapp.Main} 11-10 22:05:42.090: E/ActivityThread(1917): java.lang.RuntimeException: Performing pause of activity that is not resumed: {com.blogspot.honeyapp/com.blogspot.honeyapp.Main} 11-10 22:05:42.090: E/ActivityThread(1917): at android.app.ActivityThread.performPauseActivity(ActivityThread.java:2517) 11-10 22:05:42.090: E/ActivityThread(1917)

I have a Fragment which sets up a ListView and creates a Handler to update the Listview periodically. However, it looks like the Handler still runs after the Fragment has been destroyed. The following is the code. @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { //boilerplate code final Handler handler = new Handler(); handler.post(new Runnable() { @Override public void run() { assignAdapter(); handler.postDelayed(this, 15000); } }); return v; } Updating the ListView after the destruction of the Fragment causes the app to crash. How

I know that it is not recomended to use system.exit(0) in an Android application, but I was wondering if it would be ok to use it in onDestroy() since the application is allowed to be killed at that point? The reason I am asking is in relation to this question. Do not rely that onDestroy will be called. There are situations where the OS will kill your application without calling your onDestroy . Just a word of advice, of course, as it does not directly apply to your scenario. If system.exit(0) was not called because the app is already killed, I'd say you're OK. ;-) If your Activity.onDestroy

From the table at this link: http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle we can see that an Android Activity is not killable until after onStop() has been called (for Honeycomb and beyond). Do we have the same (documented) guarantee for Fragments? Would greatly appreciate someone pointing me at documentation where it is clearly stated. Edit: As has been pointed out [Fragment.onStop] is generally tied to Activity.onStop of the containing Activity's lifecycle. http://developer.android.com/reference/android/app/Fragment.html#onStop() But this doesn't tell me

I have three activity: - SplashActivity - MainActivity - PlayerActivity Of course the app starts with SplashActivity, then it starts MainActivity and closes. MainActivity in some moment starts PlayerActivity and goes to backstack. (MainActivity is alive but is onStop) Then I need open MainActivity and set PlayerActivity to background (PlayerActivity is alive but is onStop). Then I need open PlayerActivity again and set MainActivity to background. So PlayerActivity and MainActivity often gets onPause() and onStop() without onDestroy when app switch one to another and back. I need finish all