Is there any reason not to call setIntent when overriding onNewIntent?

Question

While experiencing a problem similar to this question, I began to wonder why we explicitly have to call setIntent when overriding onNewIntent, and

Answer 1

The docs for onNewIntent state: "Note that getIntent() still returns the original Intent. You can use setIntent(Intent) to update it to this new Intent." My guess is that onNewIntent exists so that your activity can be notified and the super probably does nothing.

Answer 2

I've just removed the setIntent(intent) code from my onNewIntent(Intent intent) implementation.

The reason: My MainActivity is single top. While my app runs it launches other activities like the camera activity. When the app returns to the MainActivity, in onResume() the (last) intent returned by getIntent() would be re-processed even if it would already have been processed before.

My new implementation (working so far): Store the intent from onNewIntent(Intent intent) in a private instance field. In onResume check this field for not null and reset it immediately to null, processing the intent once and only once.

See also https://groups.google.com/forum/#!topic/android-developers/vrLdM5mKeoY

Answer 3

Intent objects are persistently attached to the Activity, Service and other components for as long as those components are running. They don't simply go away because you moved off to another application. The reason for this is because Android may kill the process at any time, but the user may still want to go back and continue what they were doing. This makes Intents ideal for storing or transmitting small (and sometimes large) bits of information, via the Extras.

The onNewIntent() method is specifically for handling application components that are more persistent and hence may be called more than once during its LifeCycle but needs to keep track of the reasons why it was called (and hence the data it was called with). Whether you call setIntent() or not depends on what you need to do.

If you don't care why it was subsequently called, you may keep the original Intent by not calling setIntent(). This is particularly useful when your Activity (or some other component) does the same thing no matter who called it and what data it provides.

If you have a need to respond to each event individually, then you must at least store the new Intent's information. This means you may avoid setIntent(), however, then none of the components it links to will have any of the Intent information unless you send it to them directly. This may be the desired behavior for an application that cannot insure the original Intent was completely handled.

If you need to respond to each Intent individually and the original Intent does not matter, then you use setIntent(). This discards the original Intent, which is still in there... and places the new Intent so that if the user moves away (yet again), they will come back to the same place.

The reason why super.onNewIntent() does not handle this is because the core component classes cannot determine whether or not the new Intent is more important than the old one. All it cares is that it has an Intent, not what it is. This is why we override methods like these, so that we determine what is important and what is not. The general feeling is that base classes like Activity can use whatever data we have, in whatever ways it wants to (unless we override and tell it otherwise). However, they should not (and often cannot) get rid of our data unless we tell them to specifically. This is an argument you really don't want to have with some programmers. hehe

Hope this helps.