Develop Reference

why using android:configChanges is a bad practice

I have gone through different posts and questions for handling rotation and AsyncTask. In each post it is mentioned that using android:configChanges
is a bad practice. But i didn't find the actual reason why it is discouraged and why it is a bad practice. What are the disadvantage if we use android:configChanges to handle orientation.
Note:
I know it is already answered how to handle orientation and AsyncTask. but I want to know reason behind not using android:configChanges.

Well, you need to remember that an Activity can be restarted for multiple reasons.
For example, one of these reasons is when your app is in the background and the OS decides to kill it (with your Activity, of course) to reclaim memory.
When you return to your app, the OS will try to recreate your Activity as you left it, but will fail to do so, because you decided not to bother with it, just used android:configChanges in your Manifest.
If you make sure your app can recover properly from a restart, android:configChanges might not be necessary at all. Because of this, the need to use android:configChanges might indicate some flaw in your app, that may worth to take a look at.
It's not bad practice to use android:configChanges, but it pretty easily can be, if you don't understand exactly what you're doing.

To sum up all what i got form #user13 answer and other stackoverflow questions and blog posts i would like to share my finding to clear some very important aspects.
(user13) It's not bad practice to use android:configChanges, but it pretty easily can be, if you don't understand exactly what you're doing
Using this technique prevents you from easily using configuration specific resources. For instance, if you want your layout or drawables or strings or whatever to be different in portrait and landscapes, you have to manage it yourself if you use android:configChanges.
You need to override and use onConfigurationChanged() method to perform specific action if you decide to use android:configChanges
As user13 mentioned Activity is recreated not just due to orientation change but there are multiple reasons due to which activity can be restarted. Therefor activity restart should be handled for all causes. using android:configChanges only handles one case and there will be unhandled cases of activity restart which will cause a potential bug.
There are multiple and better ways to handle activity restart and plenty of help is also available on stactoverflow so android:configChanges should be used as a last resort according to documentation.

Using android:configChanges is good practice if you know what you are doing.
Just always test how your application how it behaves when it is restarted by system to stay comfortable for user so some state has to be saved all the time but not all.
With config changes like this:
android:configChanges="locale|keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize"
Your application will restart rather rarely on new devices that have a lot of memory. If it restarts it's not so unexpected for user anyway, as user had attention elsewhere and came back to app. User don't have to be in exact same state after restart if it happens by manual killing of application or application restart because of some other heavy tasks (playing game) user is doing, the user experience is important here.
If you need to refresh List just for different layouts for orientations changes or you need to hide some view elements you can call:
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
_list.reloadData();
_editorButton.visible(isPortrait());
}
(I use my custom classes but you get the point)

Multiple Activites in one class on Android

I was wondering if instead of having to create a new class for each activity is it possible to create mulitiple activities within one class?
So define various layout xml for various activities within one class, instead of having to create new classes for each activity.
Thanks

No, you should put each activity in seperate class. Take a look at this question. Someone is wondering just the same thing as you.

Ricky,
Yes, you may have multiple "Activities" defined inside a single class. But there are a lot of obstacles and issues with doing so. Before I answer this question, two things must be understood:
What you are asking goes against the Android guidelines for development, and those guidelines are enforced in as many ways as they can be during the compilation process, so nothing I say here is insured to work across any or all API versions of the Android SDK.
Different development environments do their own checks and compile in slightly different ways. I will be speaking from the Eclipse side of development.
Techniques listed here are for education, but introduce a lot of issues. For self education and theory, it is a wonderful practice to explore. However, the goal of this answer is to educate you as to why the guideline should be followed rather than sidestepped.
Requirements for an Activity
The first thing to understand is that Android has specific points that must be met for an Activity to be run. It must: a) be declared in the manifest; b) have an intent-filter describing how it is to be used; c) be a public class; d) be a top-level class.
Multiple Activities, Same Parent Class
This means that you may create an Activity inside of another class (an inner Activity, so to speak), but it must be declared static and public. This limits your Activity in a huge number of ways. Calls to methods or members that are instance-related (not static) to the parent class are not possible. So you lose a lot of time and code hacking around this.
Second, it affects your Android XML declaration for your Activity. This is where the real trouble comes in, because while it can be done, it is very specific and there is not any supporting documentation to make that happen. But that's okay, you wanted to know if you could make ONE class for your Activities.
Multiple Activities, Same Class
Well, Android determines which Activity to run based on its Intent. You could declare the same class multiple times, but with different Names and Intent-filters. If this is the case, then you would have to determine what to do based on the Intent and the extras included. This would be done in your onCreate() method.
Doing things in this manner would mean that you would have to code for two Activities in every place that you would normally deal with one. This would make it much harder to track down bugs to support your product. It would also make every routine operation take longer as you would have to decide which method to perform. For instance, if you overrode onDraw(), you would have to know which Activity you were drawing. Its ultimately just a big schmorgasborg (sp? does anyone know how to spell that word?) of "what do I do?!"
The Real Question
Why would you want to do this anyway?
1. If the answer is to save yourself time navigating your own project, believe me... That won't really happen. Your code will be harder to read, interpret and debug.
If the answer is that you want to save file space, I would reconsider your project's priorities.
If the answer is that you want to share functionality, consider extending Activity and then extending your new sub class. How do you think they made the ListActivity or TabActivity to begin with?
If you want to save state, you can place state in SharedPreferences or your Application object (if you have extended it).
As you can see, no matter your needs, there are many other ways to go about it in a way that doesn't cause you or anyone else a hassle.
Hope this helps,
FuzzicalLogic

Creating a common header for an android app

I am looking to create a common header for an android activity and have 3 possible ways to solve the same. I would like to know which is the best solution in terms of performance and memory usage.
Copy the XML across all XML Layouts : I believe this is the least impressive solution which uses a lot of memory
Create a custom HeaderView , which I can then use where needed. Drawbacks : it still creates a lot of instances.
Use <include > to include an XML component , not sure how it helps performance and reduces memory usage.
So which method is the best , or is there a better way?

I think you are worrying about the wrong thing. Pick the one that's best for your project with regards to development or maintainability. Remember that Views are all part of ONE activity which would be visible to the user at any time, per the Android activity lifecycle. Its the framework's responsibility to clean up non-visible activities if there is a need to garbage collect. If you are concerned about View performance, look into using Hierarchy Viewer which comes with the SDK to flatten your views.

The third way looks like a good candidate... the performance difference among all ways of doing it is not big. On the other hand, the maintainability difference it's. So, the third options allows a cleaner solution since you won't have boilerplate code, and will allow you to easily change the header in the future without having to modify the other views.
The second solution is nice, but it introduces unnecessary complexity. Are you going to use more than three activities with that header? Are you going to share that HeaderView or reuse it in other project? If no... then it's not worthy. Even worse, it will make you write Java code, which is less maintainable than a few lines of XML.

In my opinion I would go for the 3rd one although its make no difference in terms of memory but it will make the code more cleaner at-least for xml. I might be wrong but thats just my opinion

I ended up using step 2 and setting my header object to null in onPause and resetting it in onResume , that way the garbage collector could free up the resource. Thanks #Morrison Chang :-)

Managing an Activity with many states

I have an activity that has possibly many different states.
For example
no internet
no license
logged in
not logged in
pending
error
restricted
deprecated
At the moment I have if statements that determine the appropriate state of the application and enable or disable views as required. I was thinking that some sore of STATE pattern might be better.
Can someone give me some idea of how I might do this with an Activity like this? Or in this case is an if statement like this a better option as the views are tightly coupled to the Activity anyway.

I wouldn't disable the views for some of thise things ie no internet. Just let the user try to interact and give relevant error messages.
A good rule of thumb is that if you're changing the views significantly from one state to the other, maybe it should be a different activity? There should be very little reason to change the LAYOUT of views based on state.

This question is as old as the internet now, but the OP should really check out Stateless4J.
It provides lightweight Finite State Machines with easy syntax. I use it in all my Java projects.

Is it acceptable practice to use Singleton Objects to save state or share data between Activities?

It would be nice if StackOverflow had a section where we could post tutorials like mine so that I can answer literally hundreds of questions that have been asked here with a single blow. See... every day I read questions about how to pass complex objects between activities, how to save state so that your app can resume after orientation change, how to update listviews when the data changes, etc, etc.
Here is the second part of a tutorial series I posted on my blog... I hope that you actually read it... because I haven't seen any examples like it anywhere... and it has changed how I think about developing for Android across the board. The question is... is there a downside or negative affect of developing like this?
Beyond Smart Lists – How Observable Singletons change the game.
Please read through both of these tutorials carefully... I will answer any questions about it here that I can... I really want to know what you think about this and if it might solve issues for you.
NOTE TO MODERATORS: there are no advertisements of any kind on my blog.. so don't just close this because you think I am spamming somehow... I am not going to duplicate my post here. And... really I want to know if there is a flaw in this approach.

Have you read about Android's Application class?
Application's javadoc
sharing-domain-objects-between-activities.