Seetharaman Venkatasamy wrote:thanks Bear. dont know where you get all these my lovable pictures
Bear Bibeault wrote:
Vishal Shaw wrote:Hi,
I did not get it, why do you want to work with 10,000+ String all at a time. If they are not going to be used all at once, try using a few ,work with them make the objects null, notify gc() , then take another bunch.
Still if you want to work with a huge bunch of String object, I would suggest you to use either StringBuffer / StringBuilder. For concat, you can use append() while for replace you can follow the given steps
1> convert the object to String using toString() ,
2> perform replace() on the converted String
3> reinitialize the Builder/Buffer object with the replaced String.
4> Make the String object/s null and notify gc().
Now you have to choose.
Vishal.
Steve Luke wrote:Are you asking if more memory is consumed by holding the value returned from a method (boolean bool = getABoolean();) versus not holding the value returned from the method (getABoolean();)?
If the answer is yes, the amount of memory being 'saved' would be so inconsequential as to not be worth thinking about. If you need the returned value, store it in a variable. If you don't care about the returned value and just call the method for another affect, then don't store the returned value in a variable. But the memory consideration shouldn't come into the picture.
William P O'Sullivan wrote:Start here for the tools ...
http://developer.android.com/tools/sdk/tools-notes.html
This also contains samples, emulators etc..
WP
Paul Clapham wrote:Well, anything in the Java API which needs to interface with features of the operating system ultimately has to involve native code. And since these features include basic things like working with threads and allocating memory, that means that Java programs couldn't run without using native methods.
Prasad prap wrote:Do have a look at this Stackoverflow
Chris Cudmore wrote:
Take a look at the java API, and you'll see many classes and interfaces with the same name in different packages.
For example:
java.lang.reflect.Array
java.sql.Array
So, if you import java.lang.reflect.* and java.sql.* you'll have a collision on the Array type, and have to fully qualify them in your code.
Importing specific classes instead will save you this hassle.
Campbell Ritchie wrote:I found that old thread confusing to read. Our FAQ is more helpful.