On calling back my first activity ,it should call onResume.It is calling the same in android version 2.2.But when I checked in for android 4.1 it is calling onCreate method that calls splashscreen and hence it looks like the app is restarting.How could I make sure that onResume is called for every version of android?
Thanks
As Henry said, you can't guarantee that onCreate won't get called again - you're not in charge of that lifecycle. If the system decides to get rid of your activity while it isn't in the foreground, then when you return to it it will be recreated. If you want to make sure that you don't show the splash screen again you will need to save state to say that it has been shown (e.g. using onSaveInstanceState). As an aside, splash screens generally aren't a great idea on android, partly for this reason. It's better to view your app as a loose collection of activities that can be entered and reentered somewhat randomly, as the android system basically does. Where you see splash screens used on android, it's common to see them slightly misbehave.
If you want to keep track of your application lifecycle, to which a splash screen might correspond, then you can subclass the Application object and put a flag there. However, android may leave your app running for weeks, so the user won't necessarily see that splash screen very often.
Keep in mind that the true purpose of a splash screen is supposed to be to show the user something nice while a long loading process is happening, and not to put your branding in their face. If you use the approach with onSaveInstanceState (and often onRetainNonConfigurationInstance too) then the cases where you show the splash screen would indeed be those where you need to redo that loading process, so that would be correct. However, it's generally better to rethink the design and bring up a minimal UI quickly, then show that some data is loading.
Finally, here's someone who goes into great depth on this subject: http://android.cyrilmottier.com/?p=632
If the system has removed your activity while it was unused, it will receive an onCreate thats normal behavior.
You could make the splash screen part of a separate activity to avoid the problem.
Related
Well the question is that I have an app with multiple activities. The main activity runs several animations and the problem is that if I run the app and stay in the main activity everything is all right but if I go to another activity (the setting activity, for example) and come back to the main one, after some time the hole app begins to lag.
Any clue about why is this happenning? May the other activities keep running in background or something like that?
Thank you all.
As far as your scenario is concerned, try following
Set up proper navigation within your app.
If you keep closing and opening your activities (when your activity is still holding on resources), your memory usage keeps piling up. So make sure you release all resources like camera, or finish an animation before calling finish();
Try different android:launchMode options for your Main Activity /Home screen activity. (this depends on your app design)
In order to find who is calling your app to use more memory, try https://developer.android.com/studio/profile/investigate-ram.html
PS. You could've given more details like #Michiyo mentioned.
I'm just getting to know Fragments in Android.
When you create a new blank project, by default a Fragment is included as well, although it's not really used. My impression is that Google wants you to use Fragments all the time no matter how simple the app is. Would that be a true assessment or can you think of any reasons not to use Fragments?
What I also find strange is that the documentation indicates that Fragments can also be used for stuff that is not UI related. Can you give me an example of an app that would use a Fragment but doesn't provide any UI?
Google introduced fragments when they lunched Honeycomb (3.0).
As you may know, Honeycomb was the first Android version to support tablets out-of-the-box and they use fragments to better arrange UI layouts on the screen.
With Fragments you can utilize screen property way better then with activities. One activity can run and "command" many different fragments that share same screen real-estate and the fragments can be swapped on the fly.
So yes, Google WANTS you to use fragments and it is the right way to write most scale-able applications.
As for the second question:
Fragments can persist across configuration changes - like screen orientation changes for instance. Activities gets killed and recreated when you change screen orientation and any work they might do will have to be recreated again.
If you use fragments right, then when you change screen orientation the activity might get killed but the fragment can persist its state and then re-attach itself to the newly created activity and continue where it left.
Basically, if you have an AsyncTask running from an activity and the activity gets killed because of orientation change (for example), you AsyncTask is useless now. But if you hold the AsyncTask through a fragment then it will continue because the fragment isn't destroyed.
Hope this helps
It all depends on what you're developing and how. I don't think EVERY app needs to have fragments, but they are in many cases easier to work with as they can be swapped on the fly, managed by a single activity, etc.
For instance, imagine your app has some background task running, and you want it to keep running while the user is still "Free to roam" around the app. Running that task in the activity and having the UI in fragments would be a very simple way to do this. The activity can also manage and send messages and data to its "children" fragments at any point, including communication between the fragments themselves.
As for fragments with no UI at all, I don't recall coming across something like this, but you can definitely implement background tasks and other methods that are not directly related to the UI in a fragment. Again, it all depends what you're developing and how. There's really no "right or wrong" here...
To keep me busy during the holidays, I decided to learn about Android Development.
So I'm following the tutorial about an Activity's lifecycle. In the linked article, it says:
During normal app use, the foreground activity is sometimes obstructed
by other visual components that cause the activity to pause. For
example, when a semi-transparent activity opens (such as one in the
style of a dialog), the previous activity pauses. As long as the
activity is still partially visible but currently not the activity in
focus, it remains paused.
However, once the activity is fully-obstructed and not visible, it
stops (which is discussed in the next lesson).
I downloaded the sample app. The sample app has 3 activities, each with buttons that launches the other activity from an Intent. When I clicked "Start B", I expected that Activity A's state should be "Stopped" since it is now fully-obstructed with Activity B's layout. However, it was set to "Paused".
The only time that Activity A's state turns to Stopped is when I click "Start C" from Activity B's layout.
Why is this happening? Is it because of some optimization that is present on newer Android versions or am I misunderstanding the article?
Here's something I learned the hard way - Google's Android docs are not exactly accurate about everything!
Sometimes, The system optimizes certain behaviors which seem to deviate from the docs. The only way to know exactly how something works is by the hard way - by digging through the source!.
If your app depends on certain system level behaviors such as stopping and pausing to work exactly in a particular sequence as advertised then you will have a hard time. This behavior is controlled by the system and offers no guarantees.
The best way I have found to deal with this is to find out the contract that Google promises the developers and stick to it. For example, In this case, the contract says that if you follow the rules, implementing the required lifecycle callbacks when they are needed, then it will work, and you do not need to know exactly under what circumstances onStop(), onSaveInstanceState(), onPause(),onDestroy() etc are called.
In other words, If you do what is needed to be done when your app is paused by implementing onPause() , Then you don't need to know exactly when your activity will be paused. The pausing/resuming is controlled by the system and is subject to change from version to version (or maybe even from manufacturer to manufacturer if they choose to customize this behavior).
Wish someone had told me this when I had started. It would have saved me a lot of time and frustration. Hope this helps.
Under some circumstances I need to be able to tear down all my activities that are in my application stack and recreate them all due to configuration changes. I have accomplished this by first calling finish for each activity and then recreating the stack.
To recreate, I relauch my root activity. And within its onStart I have it create my second activity. Within my second activities onStart I have it create my third Activity. This does work but the problem that I am having is that when watching the screen you see each of the three activities created and animate into the next activity. I want to have this rebuilding invisible to the user and hide these transitions. Does anyone know how to accomplish this?
Android already takes care of restarting activities when there is a configuration change.
If you are saying you want all of your activities to be restarted, even if they aren't currently visible (Android will do this lazily as the user returns them and they become visible, if the configuration is still different at that point), then no there is no simple way to do this. I can't imagine you coming up with anything that isn't going to be hideously ugly, because to get the platform to restart your activity you will need to make it visible, and then you are going to have flicker up the wazoo.
Things just aren't intended to work that way. This isn't how pretty much any other application you run on Android will operate, so if you deeply feel like it is something you need to do then it will be useful to explain why that is so we can tell you a better way to accomplish what you want. :) For example, if you have a bunch of activities whose state is fundamentally tied together to require this, consider using fragments instead (or cleaning that up).
On the other hand, if you just have some internal concept of a configuration and want to get your activity to be restarted (say for example to switch between themes), there is an API for this but it only was added in Android 3.0: http://developer.android.com/reference/android/app/Activity.html#recreate()
I don't want my Activity to be re-created every time the device is rotated, so I've put the android:configChanges="keyboardHidden|orientation" tags in my manifest file.
Is there any disadvantage to this approach? The screen seems to re-layout automatically upon rotation, and everything works well, with the advantage that i don't need to re-initialize all the objects in my activity every time the screen rotates.
Thanks!
Not sure if you still want an answer, but I'm guessing the disadvantage is that it doesn't really let you know your applications works correctly if, say, the user answers the phone and puts your app in the background. In other words, if your app can survive orientation change with minimum difference in state, then it should be able to handle a dialer taking focus away.
Additionally, if you have any changes in resources depending on orientation or keyword (for example, if you have a dashboard screen and you want to change the position of your home buttons), Android won't automatically load those for you.
Looking at Google's design patterns, it seems Google uses both approaches. In the new Google+ app, for instance, they are not relying on the configChanges option because LogCat shows the unexpected resume of activity message, which for me shows only when an activity is destroyed and re-created. Google does use the option in other places, such as the Calendar application to edit appointments, and the Browser I think.
So it'd be a good idea to design your application without configChanges and add it later once everything works if there are some things that are inviable to restore (like whether the context menu is showing).