I have an app up and running in Play store,i have an issue where android OS kills my app.
Scenario/Steps :
1) Open app, move to any screen.
2) Minimise the app by clicking HOME button.
3) Open several other apps.(say 14 to 15 apps).
4) And now launch my app it CRASHES!!!!.
What i have noticed is instead of app starting from Splash screen it starts from where it was left of and since all my data is lost it gives me NULL POINTER EXCEPTIONS.
Ideally my app should start from the Splash Screen since i am loading all my data there and passing it other activities.
How do i check if my app is killed and load from splash screen ?
I have Application class extended as well but i am not sure how to use that.
I think you might be using static variable(s) , just a hunch. Anyway can you try this in your mainActivity onCreate or onResume:
if (isTaskRoot()) {
// This activity is at root of task, so launch main splash screen
} else {
// This activity isn't at root of task, so continue
}
But thats getting away from the real problem i think: instead i'd look into onSaveInstanceState in Activity class:
#Override
public void onSaveInstanceState(Bundle savedInstanceState) {
// Save the user's current state
savedInstanceState.putString("myStaticVariable", sStaticVariableAreBad);
// Always call the superclass so it can save the view hierarchy state
super.onSaveInstanceState(savedInstanceState);
}
then in onCreate check if the activity was previously destroyed:
// Check whether we're recreating a previously destroyed instance
if (savedInstanceState != null) {
// Restore value of members from saved state
sStaticVariableAreBad = savedInstanceState.getString("myStaticVariable");
}
Related
I have an application with basically a list of items and a detail screen for each items.
When initially started, we show the list of items. If the user switches to another app when viewing a details screen, when he comes back to the app, the details screen is shown.
All that is the standard, and working well. However, my client needs the user to come back to the list screen instead of the details screen each time the app is resumed.
My first idea would be to remember the time at which the details activity got paused, and when started, if the time is greater than X seconds, finish and launch list activity instead of resuming.
Any more reliable way to do that?
PS: I know we should not do that, I already explained that to my client, decision is not mine.
Use SharedPreference to save the time of your paused detail activity in onPause and when it resume check the saved time with current time whether it has passed your threshold if it is passed then close it otherwise remain it opened.
Implement this solution and it definitely helps.
Basically, the app is not actually restarting completely, but your launch Activity is being started and added to the top of the Activity stack when the app is being resumed by the launcher. You can confirm this is the case by clicking the back button when you resume the app and are shown the launch Activity. You should then be brought to the Activity that you expected to be shown when you resumed the app.
The workaround I chose to implement to resolve this issue is to check for the Intent.CATEGORY_LAUNCHER category and Intent.ACTION_MAIN action in the intent that starts the initial Activity. If those two flags are present and the Activity is not at the root of the task (meaning the app was already running), then I call finish() on the initial Activity. That exact solution may not work for you, but something similar should.
Here is what I do in onCreate() of the initial/launch Activity:
if (!isTaskRoot()
&& getIntent().hasCategory(Intent.CATEGORY_LAUNCHER)
&& getIntent().getAction() != null
&& getIntent().getAction().equals(Intent.ACTION_MAIN)) {
finish();
return;
}
for more details on isTaskRoot()method reference.
You have to provide the following onPause() method to all the activity classes except your list_item activity(Initial Activity).
#Override
protected void onPause() {
super.onPause();
Intent i = new Intent(getApplicationContext(), list_item_activity.class);
startActivity(i);
}
I might understand your problem incorrectly but why you do all the timing stuff? I mean, assuming you've fragments for your list and detail views, just put a a flag to monitor your activity has stopped and listen to catch your activity resume ( via onResume or onWindowFocusChanged ). If it's stopped and resumed then transition to list fragment if it's not already visible.
You can you a broadcast receiver here.
And on activity OnResume method use a call to broadcast receiver and perform whatever you need like this.
#Override
protected void onResume() {
super.onResume();
sendBroadcast(new Intent("YourActionHere"));
}
My app requires people to log in with Facebook. Once they have done so, the Facebook token is checked each time they open the app so that we do not ask them to sign in again - we redirect them straight to the MainActivity.
Note that this is an 'empty view' activity - I have not used setContentView to set it to a view, it is purely there for decision making.
public class DecisionActivity extends Activity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
FacebookSdk.sdkInitialize(getApplicationContext());
if (AccessToken.getCurrentAccessToken() != null) {
Intent intent = new Intent(this, MainActivity.class);
startActivity(intent);
} else {
Intent startIntent = new Intent(this, SignUpActivity.class);
startActivity(startIntent);
finish();
};
}
}
This is my MainActivity code. Notice that I call my network operations in onCreate because I do not want to call them each time I minimize my app and maximize my app when the activity onResumes. It must be called once when I create my activity.
public class MainActivity extends AppCompatActivity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//show my progress bar
//CALL MY API TO GET SOME DATA FROM THE SERVER
//hide my progress bar after data is received.
}
}
This works perfectly. If the user has signed in, he is redirected to my MainActivity everytime. If the user hasn't signed in, he goes to SignUpActivity.
However, there is one nasty side effect from this code that I discovered today. Scenario 1 on onResuming my app works the way I want it to work.
Scenario 2 on onResuming my app does not work the way I want it to work.
Scenario 1:
If you are in your MainActivity and you minimize your app and press the square button, find your app and maximize again, the MainActivity onCreate method will not be called as the activity simply onResumes therefore no network operations is performed, progress bar is not shown, which is what I want.
Scenario 2:
However, if you minimize your app and decide to click on the app icon on your phone, DecisionActivity will be launched which will decide that MainActivity needs to be launch as the user has logged in already and the token exists. Because MainActivity is relaunched, onCreate is called and network activities are performed and the progress bar is shown, which is not what I want.
How do I stop this from happening when I click on my app icon on my phone?
I checked popular apps like Facebook now to see if they have the same issue by testing Scenario 1 and Scenario 2 on them and they don't seem to encounter this problem which makes me think whether the setup I have used to check whether someone has logged into my app under DecisionActivity can be done in a better way.
I'm sure a more elegant way exists, but this is what I have off the top of my head:
Try using SharedPreferences. So, when your app is minimized, the onPause() method is called. In this method, set the SharedPreference to false, which means that you don't wanna run the progress bar right now. Check for that SharedPreference in your MainActivity's onCreate() method. When the app is resumed, set the SharedPreference to true.
So this means that whenever the user went through the onPause() method, the progress bar won't run either if he goes through the Scenario 1 (because then he will hit onResume(), which won't show the progress bar) or if he goes through Scenario 2 (because your SharedPreference is false, and you check for its value beforehand in MainActivity's onCreate()).
But, now you also have to use the onFinish() or the onDestroy() method, and change the value of your SharedPreference to true, which will make the progress bar to appear when the app is launched next time.
The only flaw I can think of is that I'm not sure whether the onDestroy() method would be called if the user closes the app from the Recents Menu, or if Android mamory cleaner closes the app to free up memory, so do try it and tell me if it works.
And I agree this is but more of a hack and not a proper solution, but if it works, it is good enough ;)
basically my app has 2 activities.Say "A" and "B"
.
A launches B.
Activity B plays music and also has a notification.
Case 1:when the view is still on activity B` i press home button and then i click on the the notification, activity B is opened with its view intact and with its music playing (because in the manifest i am using android:launchMode= "singleTop" and hence another instance of the activity is not created) this part is as desired......
but
Case 2:when the view is on activity B and i press back button ,activity A appears and then i click on the the notification, activity B is opened with the view lost and music also stops(not desired)......i am making a guess that it happens because when i press the back button the activity is destroyed ,so i have to progamatically restore its view right??so to restore its view i override two methods .....
#Override
public void onSaveInstanceState(Bundle savedInstanceState) {
// Save UI state changes to the savedInstanceState.
// This bundle will be passed to onCreate if the process is
// killed and restarted.
savedInstanceState.putBoolean("boolMusicPlaying", boolMusicPlaying);
savedInstanceState.putInt("swapnumber", swapnumber);
savedInstanceState.putString("seekbarprogress", progress2);
savedInstanceState.putInt("position.seekbar",seekbar.getProgress());
savedInstanceState.putString("seekmaxString", max2);
savedInstanceState.putInt("seekmaxInt",seekMax);
savedInstanceState.putParcelableArrayList("songfetails",songdetails);
super.onSaveInstanceState(savedInstanceState);
}
//make a note ....even if i don't override onDestroy() and don't call on SaveInstanceState explicitly, then too i am not getting any desired effect.......
#Override
public void onDestroy()
{ Bundle savedState = new Bundle();
onSaveInstanceState(savedState);//because of this line....the app is crashing......
super.onDestroy();
}
but it didn't help.....
and in on create i am putting a check if saved instances is null or not....create view accordingly...(i.e from saved instances or from fresh) but it didn't help...
also this line is giving a crash ...onSaveInstanceState(savedState);
even if i don't override ondestroy() and kill the app manually from task killer,and then try to open activity B,then too the saved instances thing should work right,because the method OnSaveInstanceState will be automatically called then,right???please help
Basically if you have pressed a back button,restoration of activity should be done using shared preferences/or a database but if you haven't pressed the back button and then you want to restore the state of the activity (because the activity was destroyed by the system ) then the bundle savedinstances can be used ...
From Android documentation:
When your activity is destroyed because the user presses Back or the activity finishes itself, the system's concept of that Activity instance is gone forever because the behavior indicates the activity is no longer needed. However, if the system destroys the activity due to system constraints (rather than normal app behavior), then although the actual Activity instance is gone, the system remembers that it existed such that if the user navigates back to it, the system creates a new instance of the activity using a set of saved data that describes the state of the activity when it was destroyed. The saved data that the system uses to restore the previous state is called the "instance state" and is a collection of key-value pairs stored in a Bundle object.
To fix second problem you must restore data form some other source (service that plays music, restore info from application context or singleton, etc.)
For more info check this.
I have a small problem with a webview I'm using. I'm trying to use the webview to allow the user to fill out a registration form. This works fine when the user completes the form in one session but should the user lock their phone, the webview activity is destroyed.
I have two activities in memory, one of which is quite memory intensive. The problem I believe I'm having is that because this other activity requires more memory than the webview, the webview is destroyed.
I'm fine with this to a degree, but I would really like to be able to save the current state of the web page so the user doesn't have to submit all of their details again. Is there anyway I can do this.
Thanks
try it :-
You can use WebView method saveState()/restoreState() and save it to activity onRestore bundle and use saved value in onCreate method if the previous Activity will be destroyed.
You can use similar method which is described here (but used for only configuration change):
http://www.devahead.com/blog/2012/01/preserving-the-state-of-an-android-webview-on-screen-orientation-change/
We have run into a similar issue. We have an activity with a webview.
We want the user to input 3 fields on a form in the web view, then launch a new activity (camera) to take a picture. When we get the picture back, and using javascript we insert the picture into the currently active webview form. It all works great 99.9% of the time. However, in some odd scenarios which are difficult to reproduce, while the camera activity is active, the webview activity behind it gets destoryed. saveState / restoreState only partially restores the webview. The 3 form fields that the user had inputted but not submitted when we launched the camera are now lost. They do not get saved by webview.saveState. Also, some javascript state on the page is lost too.
To work around this we added a javascript method to the page and invoke it from the app on saveInstanceState. Then after we restore the state, we invoke another javascript method on the webview page to put the state back. It is a pain in the but and requires work for each form you need to do that to, but it works.
I hope future versions of Android webview.saveState save it exactly as it was before the activity gets destroyed. Alternatively it would be great if you mark an activity as critical to your app and only allow that activity to be destroyed if your app is not the current app the user is working with.
try WebView.addJavascriptInterface, when Activity.onPause, call javascript method in page by loadUrl("javascript:..."), and in web page, call native method that provided by WebView.addJavascriptInterface to save data. is this what you want?
An activity can be destroyed when back key is pressed; when the screen is rotated (is faster destroy the activity and recreate that resort all the graphic elements); or when is posible that it will not active in a few time (lock the phone, press home key or other application is started).
You need to do that #Ixx suggest in his comment : Android webView saveState
Save the data of your application with something like
#Override
public void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
/// save your things, e.g.
outState.putString("name", name);
}
And recover, it exists, in the method onCreate
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// if it is a new activity
if (savedInstanceState == null) {
// initialize vars, e.g.
name = "Unknown";
}
// if is a call after detroy the activity
else {
// recover vars, e.g.
name = savedInstanceState.getString("name");
}
}
The books I have are abysmal at explaining how to work with the lifecycle, there's a lot I'm missing that I'm hoping somebody can fill in.
My app structure is that when it's first started, it starts an activity full of legalbabble that the user has to accept. When he says 'ok', I start my main activity and then I call finish like this:
public void onClick(View view) { //as a result of "I accept"
Intent mainIntent = new Intent(mParent, EtMain.class);
startActivity(mainIntent); // Start the main program
finish();
}
Then in EtMain in the onCreate method, I've got some tabs and I instantiate some classes:
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
mTabHost = (TabHost)findViewById(android.R.id.tabhost);
SetupTabs.setMyTabs(mTabHost, this);
mComData = new ComFields(this); // Create the objects
mDepWx = new WxFields(this, DepArr.Departure);
mArrWx = new WxFields(this, DepArr.Arrival);
mDepVs = new DepFields(this);
mArrVs = new ArrFields(this);
mTabHost.setOnTabChangedListener(new OnTabChangeListener(){
}
Questions:
The 'finish' in the first fragment should terminate the legalbabble activity so it'll never be restarted, right? And the EtMain one will remain forever (until killed externally), even if my app gets pushed to the background, right?
The way it is now, when EtMain gets pushed and later brought to the foreground (by tapping on the icon), it goes through the legalbabble screen as though it's a complete start - that's what I'd like to prevent - going thru the legalbabble screen again.
It would seem that I'd want to override onRestart in the second code fragment and put something in there to restart the app, right? That's the part I'm unclear about.
My question then is what needs to be done in onRestart. Do I have to recreate all the tabs and data in the tabs and all my object instantiations? Or is the memory state of the app saved someplace and then is restored back to the state that it was in before something else was brought to the foreground in which case not much needs to be done because all the objects and listeners will still be there?
Yes after the first activity has ended you shouldn't have to view that activity again. You could also write to the shared preferences that the user has previously seen legal info.
If you're UI object creation is in the onCreate method, this should only be called once. Pausing or resuming will not call the onCreate method again.
Unless you explicitly remove your objects and tabChangedListeners in the onPause method, you should not have to touch them in the onRestart method.
Correct, the state of the app is saved automatically. You shouldn't have to touch the onRestart method.
Hope this helps!
I think the problem is that the launch activity in your manifest is the legalbabble activity, so when you click on the icon, the system launches another one. A better architecture would be to launch the legalbabble activity it from your EtMain activity in the onCreate method of the latter, using startActivityForResult. From the docs:
As a special case, if you call startActivityForResult() with a requestCode >= 0 during the initial onCreate(Bundle savedInstanceState)/onResume() of your activity, then your window will not be displayed until a result is returned back from the started activity.
When you get the result in onActivityResult, you can call finish() if the legal stuff was declined; otherwise everything will proceed normally.
This avoids the problem that the launch activity defined in your manifest finishes when the legal stuff is accepted.
EtMain will not remain forever, if the user backs out (by pressing the BACK key) the Activity will be finished (onPause, then onStop, then onDestroy will be called).
In general you can ignore onRestore until you are doing something complicated.
Once the user has exited your application and re-enters (or presses the icon on the Homescreen), onCreate (followed by onStart and onResume) will be called for your first activity, so you do not need any logic in onRestart, your code in onCreate will do the setting up for you as it did the first time. Because of this your legal babble will appear again when the user starts the app after exiting unless you store a preference (in SharedPreferences or a database or file) to indicate you have already displayed it - in which case finish it straight away and start the main activity.
onRestart is only called when the application goes from the stopped state (onStop has been called but not onDestroy) to the started state (onStart is called but onResume has not yet).
For saving data - some components save their state automatically (e.g. EditTexts remember the text in them, TabHosts remember the currently selected tab etc). Some components will not. If you wish to save extra data then make use of onSaveInstanceState and onRestoreInstanceState. You should only use these methods to restore the state of your application or temporary data, not important things, e.g. the id of the resource what the user was looking at, what zoom level they were at etc. For things like contacts or actual data you should commit these changes to a database, SharedPreferences or other permanent storage (e.g. file) when onPause is called.
I recommend taking a look at the Android Activity lifecycle if you are confused. Or ask more questions!