Develop Reference

getReference() vs. getChild()

I was wondering what the difference between database.getReference("foo/bar/123") and database.getReference("foo").child("bar").child("123") is?
I'm assuming that the later one will load the complete "foo" object whereas database.getReference("foo/bar/123") just loads the "123" object?
Is my assumption correct or what is the correct / most efficient way to only load data of "123"?

The two are equivalent. You can inspect this manually this by printing the toString() format for both References.
References are cheap - there's nothing inefficient about either solution. Neither one has yet loaded any data. A Reference is just a pointer to a location in the database.

It should not make a difference, a reference is not actually accessed when instantiated. This is the most relevant document I can find,
https://firebase.google.com/docs/reference/node/firebase.database.Reference
The docs don't say it explicitly, but requests are only performed when using the .set() or .on() methods

parse trigger beforeSave when using object as pointer

i have some code like this:
ParseObject firstObject = ParseObject.create("oneClass");
//ParseObject secondObject = already exist on cloude - AnotherClass;
firstObject.put("pointer",secondObject);
firstObject.saveInBackground();
SecondClass beforeSave & afterSave triggered from some reason...
any idea?

When you save an object that has pointers attached to it, those pointers are also saved. This can be useful, or it can cause problems where your saves time out because you're calling extra beforeSave triggers. You just have to be aware of it and plan accordingly.
Also, FYI, when you query for objects that have fields that contain pointers, the pointers that are returned are empty pointers, i.e. they just contain the objectId. If you want to access them, use the include method of your query so that those objects are fetched as well.

Storing a method inside a String and executing the method

I'm storing a full method in a String (actually reading it from a file as a String). Now I need to execute the method which is in the String. I mean, in the MainActivity I have to execute this method inside the String. Is there any possible way to do it?
Thanks in Advance.
The method which is stored in the String is:
public void showTheText()
{
System.out.println("Hi There...");
}

Before doing this, if you are trying to execute code dynamically, keep in mind that guys on Google Play might not like it, as it can be use for remote execution of code, or code that wasn't analyzed by them.
That being said, in java there is no proper way of evaluating expressions in strings. But you can always embed some interpreter and make it execute the code (i.e. https://code.google.com/p/android-scripting/wiki/FAQ).
If your methods are present on some class of your application, you would only need the name of the method you want to execute and then use reflection to invoke it.

What is the most efficient way to process a multiple value method return?

I have a method that returns Point:
private Point getDisplayWH() {
Display display = this.getWindowManager().getDefaultDisplay();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB_MR2) {
Point realWH = new Point();
display.getSize(realWH);
return realWH;
}
return new Point(display.getWidth(), display.getHeight());
}
Now, when receiving this result, I can't decide which of these two is more efficient.
Number 1:
Point displayWH = getDisplayWH();
layoutPreviewDim = calcCamPrevDimensions(displayWH.x, displayWH.y));
Number 2:
layoutPreviewDim = calcCamPrevDimensions(getDisplayWH().x, getDisplayWH().y));
In this article it is said that:
If you have a method returning a string, and you know that its result will always be appended to a StringBuffer anyway, change your signature and implementation so that the function does the append directly, instead of creating a short-lived temporary object.
But should I follow these instructions even if I have to call the method more than once to get the return? What about display variable in my getDisplayWH() method? Is it more efficient approach than accessing Display methods directly this.getWindowManager().getDefaultDisplay().xxxx?
And my second side question: Is there a general way to check/compare code efficiency other than with system time difference before and after method call? Or the time difference is the ultimate tool?

Calling a method twice rather than storing the return value is going to be inefficient.
One way to test for efficiency is to write a unit test and perhaps use the two approaches, call them 10k times in a loop, and see what happens.
But, regardless, try to minimize calling methods multiple times, if they return the same value on each call.
The point about the string is that strings have to be garbage collected, as they are not appended to. So you create extra objects that will need to be collected. So, appending it directly to the StringBuffer just makes sense to limit how long the garbage collector runs.
If you go with the unit test approach, you can also monitor garbage collection to see what the difference is.
One way to monitor garbage collection is to follow this article:
http://www.raizlabs.com/dev/2014/04/hunting-your-leaks-memory-management-in-android-part-2-of-2/
Once way is to use DDMS and cause a garbage collection to see how much memory has been allocated, but there are other approaches.

what is an immutable reference?

hi i have found Uri as immutable reference i dont know what it is the exact meaning of immutable reference... can anyone help me?

It's a variable that cannot be changed once set. Very useful when you have multithreaded code since being able to change a variable's value might be a source of many hard to find problems in your code.
If it's immutable, it's usually good.

A good example of an immutable class within the .NET Framework is System.String. Once you create a String object, you can’t ever change it. There’s no way around it; that’s the way the class is designed. You can create copies, and those copies can be modified forms of the original, but you simply cannot change the original instance for as long as it lives, without resorting to unsafe code. If you understand that, you’re probably starting to get the gist of where I’m going here: For a referencebased object to be passed into a method, such that the client can be guaranteed that it won’t change during the method call, it must itself be immutable.
In a world such as the CLR where objects are held by reference by default, this notion of immutability becomes very important. Let’s suppose that System.String was mutable, and let’s suppose you could write a method such as the following fictitious method:
public void PrintString( string theString )
{
// Assuming following line does not create a new
// instance of String but modifies theString
theString += ": there, I printed it!";
Console.WriteLine( theString );
}
Imagine the callers’ dismay when they get further along in the code that called this method and now their string has this extra stuff appended onto the end of it. That’s what could happen if System. String were mutable. You can see that String’s immutability exists for a reason, and maybe you should consider adding the same capability to your design.

EX: string is immutable...
if u have for ex string s =" whatever" and u output it with uppercase letter..for ex
Console.Write(s.ToUpper())the console will print u WHATEVER...but the string s will still be whatever... unlike the mutable type which will change the string from whatever to WHATEVER

"immutable" means "can't change the value"
"mutable" == "changeable"
"immutable" == "not changeable"

In java , every thing is treated as String and object , Now try to think that if have created a program of 10000 lines and in this there you have added "public" 100 times so do you think that every time this public is created in storage . else what we can do , we can created something like that when ever we find something like this we will fetch it from there there ( String pool )