We Keep Coding

Why using putExtra() instead of direct property invocation?

When we need to pass data to other activities in android, we use putExtra().
My question is why we do this instead of declaring public properties and access it as we do in Java and other programming language when we are developing desktop or we applications, what is the pros of this, or this approach was chosen because of some limitations?

as we do in Java android is using Java.
instead of declaring public properties and access it That is done because you should not have an instance of an activity anywhere except this activity. You should not create instances of any activity on your own using constructors. Only system should create activities. What you should do is to ask the system to create it (using startActivity()). That is done because if you have an instance of activity anywhere, this will result in memory leak.
You should develop you app the way that it doesn't need to access methods or fields of other activities.

Accessing strings.xml from different contexts

Does it matter whether I access strings from strings.xml file from different contexts?
I accessed it in many ways such as: getApplicationContext().getString(R.string.name), this.getString(R.string.name),MainActivity.this.getApplicationContext().getString(R.string.name), or simply getString(R.string.name).
I understand that the application context lasts the whole application lifetime, but I honestly do not know when I should use it. Also, I cannot understand what is the difference between using this and MainActivity.this.
Please explain how I should access strings from both activities and Java classes.

The key argument for using the Application Context or the Activity Context is the dependency to the lifecycle of the whole App or a component (Activity in this case). If you wanna access the strings.xml it doesn't really matter which of both you use. Because you just use the Context get a reference to the ressource, which goes away when the Activity will be destroyed. A more importent case would be if you pass the Context to another class f.e. Because then there is a dependency to this specific Context and can lead to memory leaks if you don't clean it. There is a nice explanation about this with the usage of a BroadcastReceiver in the docs.
There is no difference between this and AnyClass.this because it points to the same class object. But you have to use AnyClass.this if you wanna access the outer class in an inner class. Or if you have an anonymous class and need to access fields of the outer class. You could see it as more strict because you refer to a specific class.

Creating GoogleApiClient for multiple activities

I am developing an android app with Google+ API. I am having multiple activities which each require one instance of GoogleApiClient.
As I understand from this post it is possible to call the same instance of GoogleApiClient for each activity. My question is how do we create copies of the GoogleApiClient specifically?
Do we build one again with the .addApi(), .addscope() and implement onConnected method and OnConnectedFailedListener method again? Because it seems repetitive and inefficient. And wouldn't implementing these methods override the same methods from other activities too?

It's not expensive to create multiple instances of GoogleApiClient. In fact it will help with efficiency if you use more than just one API. Only the services you specifically request will be spooled up. So if one activity uses Plus and another uses Drive, the Plus service doesn't have to be spooled up when you're on the Drive activity.
To be clear, it is recommended that you create a separate instance of GoogleApiClient for each Activity, Fragment, Loader, Service, or Application that you create (maybe even some others that I forgot too).
If you really don't want to do that, use the application context instead of an activity or fragment to create the GoogleApiClient and hold a reference to it in an Application object.

I have just had this same dilema. To get round this I used the BaseGameUtil... not sure if your using that but if you are then it is simple you can just have each activity extend the BaseGameActivity, add the required methods and then create a GoogleApiClient obj and getApiClient which will then give you the means to use the GoogleApiClient in your second activity.
mGoogleApiClient = getApiClient();
If your not using the BaseGameUtil then i think you would have to create it like you do above which is a pain, at least the basegameutil does it for you, plus you can always change whats in the BGU as they are more examples than libraries.
Hope this helps.

Is putExtra the only way of passing data to a new Activity?

I have created a SettingsActivity for my app. In this Activity I am using the SharedPreferences class to do handle the user editable preferences.
While setting up the SharedPreferences, I have to load them in the onCreate of my main activity and then again in the SettingsActivity. The probably was that both calls to the getXXXX() methods require defaults and I figured that it would not be good to hard-code the default values into both places because I would imagine it would be problematic in the future if I ever changed them.
Which is the best/most popular (or accepted standard) of doing this?
Create a global variables class in which I import into each activity and define my default constants in there?
Use putExtra and getExtra to pass the data from the main activity to the settings activity?
Any other suggestions?

I think Squonk has a good answer, but if you're looking for an alternative, consider creating a Settings class with all of your settings as members. It could have a static method like loadFromPreferences(Context) that would return a Settings object constructed from SharedPreferences, using whatever defaults you need. It could also have a saveSettings(Context) method to save your edits. Hope that helps.

Personally, in this situation, I'd put the default values in a resource file. In that way there's no need to use a global variables class or a helper class. Android resources already do that for you.
See:
Providing resources
More resource types

Instead of using a class with static values why dont you extend the Application class which will always live when the application's process lives. you can keep shared methods and variables in it

I would highly recommend opening the SharedPreference in the onCreate of both activities. Every time I've tried to use global variables, the values disappear in a way that's difficult to detect and fix. Activities are destroyed when they are closed. Services can be removed from memory at any time. The application context will be destroyed if your services are sleeping and don't have activities in memory.
That being said, putting a variable in the application context is probably the best place. Create a class that extends Application and set AndroidManifest.xml to use this. Just don't expect the value to be there if you try to use it from services or broadcast receivers.
Also, unless you're having problems with the activities loading too slowly, you're better off spending time on features than optimization.

You can declare objects as public static and reference them from another class. ActivityA:
public static int testIntegerA = 42;
Intent intentInteger = new Intent(getActivityContext(), ActivityB.class);
intentInteger.putExtra("INTENT_EXTRA", testIntegerA);
startActivity(intentInteger);
ActivityB:
public static int intentInt, staticInt;
staticInt = ActivityA.testIntegerA;
intentInt = getIntent().getExtras().getInt("INTENT_EXTRA");
Now both intentInt and staticInt equal 42;

Is it possible, and what is the best strategy, to pass objects by reference from one Activity to the next?

I have a simple Android application that uses an instance of a class, let's call it DataManager, to manage access to the domain classes in a Façade-like way. I initially designed it as a singleton which could be retrieved using static methods but I eventually got irritated with the messiness of my implementation and refactored to what I reckoned was a simpler and cleaner idea.
Now the idea is that for each file that is opened, one DataManager is created, which they handles both file I/O and modification of the domain classes (e.g. Book). When starting a new Activity, I pass this one instance as a Serializable extra (I haven't got on to using Parcelable yet, but expect I will when I have the basic concept working), and then I grab the DataManager from the Intent in the onCreate() method of the new Activity.
Yet comparison of the objects indicates that the object sent from one activity is not identical (different references) to the object retrieved from the Bundle in the second Activity. Reading up on Bundle (on StackOverflow, etc.) suggests that Bundles cannot do anything other than pass-by-value.
So what is likely to be the cleanest and safest strategy for passing an object between Activities? As I see it I could
Forget about passing by reference and live with each Activity having its own DataManager object. Pass back the new DataManager every time I close an activity so that the underlying activity can use it. (The simple solution, I think.)
Go back to using a singleton DataManager and use a static method to get it from each Activity. (Not keen on using singletons again.)
Extend Application to create a sort of global reference to DataManager. (Again, not keen on the idea of globals.)
Is that a fair summary? Is there some other healthy strategy I could use?

Another approach would be to create a service. The first activity would start the service and bind to it, when you launch a new intent, unbind the first activity and when second activity starts, bind to the service.
This way you don't have to ever stop the service or worry about passing data between activities.

Java does not have pass by reference so that option is out, I would suggest dependency injection for passing data between the activities. Otherwise definetely the singleton would be the way to go.

The prescribed one is Going by implementing Parcellable interface, thats the way to pass Objects between Activities.. and the 2nd and better choice is to make a Singleton to be sure its single Object.

Create your DataManager as a Singleton that implements Service. Bind the service to your application in the manifest xml (see the link), and you will have a persistent singleton your activities can access without issues.
Passing parcellable arguments can quickly get very messy if you need to get a lot of data. The singleton approach, although usually considered an anti-pattern, works like a charm in cases like these. Just remember to not create multiple singletons that interact with one another.

I would suggest using an Application Subclass. It allows you to hold a single reference to the DataManger class and is persistent as long as your app lives.
A singleton with a static field will also work, but there are some place in the documentation where it says that the content of static fields is not a safe place to store your data. As I understand static fields should persist as long as your ClassLoader stays in memory. Therefore a singleton should only vanish if the whole process leaves the memory and in that case the application class will also leave the memory, but it will call the onDestroy methods of the Application and that enables you to safely close your DataManager and persist important data to memory.
That said to your two variations.
The Android way to go would be to make your DataManager a ContentProvider. This will make it possible to access your Data from every Activity without holding a global reference. I'm not sure how you would build a caching Content Provider that stays in memory and is not reinstantiated too often.