Strings are wrappers around a char[]; String.substring will create a
new String object with the *same* char[] from the original String.
Your first snippet causes OutOfMemory because you're retaining the
10 char Strings in someStringList even when you call substring. I
don't have the Android im
Yep, substring MAY (or may not) decide to avoid copying the characters
and simply keep a reference to the char array in the source String. A
smart substring implementation wouldn't do this if the result string
were quite short or the source string quite long, but apparently the
Android implementat
Thanks a lot, working with StringBuffer and it's impelemention of
substring did the trick! As a C# developer, I'm not used to think of
such things ... ;-)
Thanks!
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send
The UNconditional behavior of referencing the original String's array
is UNreasonable when you take into account the storage effects.
Situations like the OP's are rare, but the technique also negatively
impacts cache locality, garbage collection, etc. Modifying the
technique can significantly impr
You just need to get rid of that lousy Android and get an iPhone. ;)
(Then you wouldn't have connectivity in the first place, and hence no
problem.)
On Oct 7, 4:00 am, Daniel Drozdzewski
wrote:
> Sorry guys for sending it 3 times - I have been on the train and was
> writing from my Android phone
On Oct 7, 12:46 am, Alex wrote:
> Thanks a lot, working with StringBuffer and it's impelemention of
> substring did the trick!
Also consider that StringBuilder would be more efficient than
StringBuffer
--
You received this message because you are subscribed to the Google
Groups "Android Devel
Right. The main difference is that StringBuffer is threadsafe, and
nothing else in Android is threadsafe, so little point in using
StringBuffer.
(That said, the performance edge of StringBuilder over StringBuffer is
unlikely to be noticed.)
On Oct 7, 11:48 am, jotobjects wrote:
> On Oct 7, 12:4
Well, I would hope that the Java threadsafe classes are still
threadsafe. But essentially none of the UI is, and the structure of
the system greatly discourages sharing data between threads.
On Oct 8, 5:00 am, Daniel Drozdzewski
wrote:
> On Thu, Oct 7, 2010 at 6:40 PM, DanH wrote:
> > Right. T
On Oct 8, 3:57 am, DanH wrote:
> Well, I would hope that the Java threadsafe classes are still
> threadsafe. But essentially none of the UI is, and the structure of
> the system greatly discourages sharing data between threads.
Allowing multiple threads direct access to UI state causes a lot of
> "Greatly discourages sharing" seems like a bit of an over-statement.
> The Java programming language provides well-defined methods of sharing
> data between threads, and the Java memory model rigorously defines
> what is and isn't expected to work. (Or were you referring to
> something else?)
I
Sorry guys for sending it 3 times - I have been on the train and was
writing from my Android phone and phone kept loosing GRPS/EDGE.
Anyway, here is an article that explains few points about String and
StringBuffer:
http://www.precisejava.com/javaperf/j2se/StringAndStringBuffer.htm
Daniel
On
On Thu, Oct 7, 2010 at 6:40 PM, DanH wrote:
> Right. The main difference is that StringBuffer is threadsafe, and
> nothing else in Android is threadsafe, so little point in using
> StringBuffer.
Well,
there are few places, where Java (Android) are thread safe (Vector,
Stack, few classes in javax
12 matches
Mail list logo
