2

An application background service updates sqlite database. Therefore my activities are becoming outdated. Activity intents also contain outdated params so onCreate, onResume will crash the application. An easiest solution is to restart whole application. I don't want to add IFs to all onCreate, onResume methods in all activities to handle one special case.

I noticed that ACRA has following code executed after an exception has been handled.

android.os.Process.killProcess(android.os.Process.myPid());
System.exit(10);

However many people discourage use of System.exit(0). Is System.exit(0) really that dangerous for an Android application data integrity? Of course my code will close the database before existing.

Update:

I known how to use finish(), content providers, send broadcasts, read many answers here on SO, etc. However each of these approaches requires additional thousands lines of code. I implemented solution with System.exit(0) in ten minutes. The restart is so fast that it is indistinguishable from ordinary startActivity action. The db update/restart is done after longer user inactivity so the app is already suspended by the system. My app doesn't require real time syncing. During tests the application behaves correctly. This is quick and dirty solution.

Therefore I asked the question about possible side effects of System.exit(0). Not how I can do the design differently. I know that current design is not perfect.

Greg Dan
  • 6,198
  • 3
  • 33
  • 53
  • possible duplicate of [Close application and launch home screen on Android](http://stackoverflow.com/questions/2042222/close-application-and-launch-home-screen-on-android) – auselen Sep 06 '13 at 12:58

5 Answers5

2

System.exit(0) is an artifact from Java runtime, it isn't meant for Android. So in any cases using it would be worst solution.

Why don't you use Activity.finish() gracefully?

If you terminate the process you are living in, you'll loose most of the caching and restart time (~resume in the eyes of the user) for it next time will be higher.

Read more in Activity Lifecycle documentation on Android Developers.

auselen
  • 27,577
  • 7
  • 73
  • 114
  • It was not me, but I believe this is because the OP wants a mechanism for closing the activity when an instance of the activity is not known. Arguably, the activity could handle a broadcast and be flagged for closing but the infrastructure for that is all wrong. – Gusdor Sep 06 '13 at 12:43
  • @Gusdor So do you think the answer should be like "nope, it won't burn the phone" ? :) – auselen Sep 06 '13 at 12:49
  • Because solution with `finish()` will require to add many `if` statements to all activities. Please read additional comments below the question. – Greg Dan Sep 06 '13 at 14:15
1

Killing the process will not clean up any registered resources from outside the process. BroadcastReceivers, for example. This is a leak and the device will tell you as much.

You really shouldn't be updating the database schema from a background service. Do it when your activities resume.

If you are just updating your data, resuming an activity should validate the data specified by the Intent and tell the user if, for example, Item X is no longer there.

Gusdor
  • 14,001
  • 2
  • 52
  • 64
0

No tool is that dangerous if used carefully and for a specific, well thought off purpose.

However, In your case I do not believe System.exit() is the right way to go. If your application depends on data from a database, create a background service (or a few, depending on what you need) that will inform your application of changes and update the data. It is, in my opinion the right way to handle changes.

As for scenarios when you want to use System.exit() I personally sometimes use it when I can't recover from a critical error and no graceful degradation is possible. In those cases it is better to force all resources associated with your application to cease rather than just leave loose ends tangling around. To clarify, you should always use error handling before doing anything radical. Proper error handling is often the way to go.

But this is a very delicate topic and you are likely to receive quite a few diverging answers.

Eric Tobias
  • 3,225
  • 4
  • 32
  • 50
  • Surely the same reasons apply to System.exit() that apply to killing threads arbitrarily. Cleanup. – Gusdor Sep 06 '13 at 12:44
  • Cleanup does not kill threads arbitrarily, at least it shouldn't. It should choose threads based on a set of parameters such as memory usage and activity. Of course, in some cases the best option could be to make a random choice. But even then, the decision should have been carefully made and with a purpose. I guess the bottom line is that you should never use `System.exit()` because you are lazy or engineered yourself into an impossible situation. – Eric Tobias Sep 06 '13 at 13:00
0

Therefore my activities are becoming outdated.

Use a ContentProvider and ContentObserver (or the Loader framework), or use a message bus (LocalBroadcastManager, Otto, etc.) to update the activities in situ.

Activity intents also contain outdated params so onCreate, onResume will crash the application

Copy the relevant "params" to data members of the activities. Update those data members as needed (e.g., from the handlers from the message bus-raised events). Hold onto that data as part of your instance state for configuration change (e.g., onSaveInstanceState()). Use this data from onCreate(), onResume(), etc.

An easiest solution is to restart whole application

It is not easiest, if you value your users, as your users will not appreciate your app spontaneously evaporating while they are using it. Do you think that Gmail crashes their own app every time an email comes in?

Next, you will propose writing a Web app that uses some exploit to crash the browser, because you cannot figure out how to update a Web page.

I noticed that ACRA has following code executed after an exception has been handled.

A top-level exception handler is about the only sensible place to have this sort of code, and even there, the objective is for this code to never run (i.e., do not have an unhandled exception).

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Please read the question update. None of my competitors have real time or background updates at all. Because they are not needed. These are other more important features I have to focus on. – Greg Dan Sep 06 '13 at 14:48
  • @GregDan: "However each of these approaches requires additional thousands lines of code" -- this should add a couple of dozen lines per activity/fragment that uses the database, plus a few lines at the point in time of doing the update itself. If you have an app with hundreds of activities/fragments, you have other issues. – CommonsWare Sep 06 '13 at 14:56
-1

There's an existing answer HERE that might give you some help as to why people say it's bad to use System.Exit().

Community
  • 1
  • 1
Brad Seman
  • 52
  • 4