Out of Memory problem?

I am downloading files from the internet (yea still working on that ebook app) and it keeps crashing.  It runs fine in the emulator. 

Right now I do this....

  OpenFunc()
      cc = (ContentConnection)Connector.open(URLString);
      is = cc.openInputStream();
      filelen = (int) cc.getLength();

The I call this func below in the background thread until the book is reeled in and concatenated into its final String....

  Read_CallMeUntilDone()
           int av = is.available();
           filebuffer = new byte[av];
           int actual = is.read(filebuffer);
           runninglen +=actual;

           if (runninglen==filelen) {
                bookstr += new String(filebuffer);//,"ISO8859_1" /*"utf-8"*/);
                filebuffer = null;
                // YOU ARE DONE
           } else {
               if (actual>0) bookstr += new String(filebuffer);
              // CALL THIS FUNC AGAIN AND AGAIN UNTIL runninglen==filelen
           }

What I am doing is reading the incoming buffer without locking to get the available bytes and then moving those to the big "bookstr" String that holds the entire book.  I put in some .gc's in the futile hope that would.  In the emulator I am getting 8192 byte chunks (no surprise with TCP/IP I am sure) of available data each loop thru.  What available might I be getting in the phone each 100mS loop?

What am I probably seeing on the phone?  I get an unhandled exception and the app dies.  Both funcs have IOException try/catch protection for the above code.

Instead of using String concatenation, you should consider using a StringBuffer.   It is much more memory efficient.

Remember that Strings are immutable.   Everytime you perform a String concat, you are allocating an entirely new String.   It doesn't actually add to the previous String.   In your above code, if you are reading 320k single byte characters in 8k blocks, then you'll end up allocating about 14MB of Strings.   Almost all of that will be eligible for garbage collection, but almost all of that will be avoided by using a StringBuffer instead.

Also, just reminder... StringBuffer's default starts you off with a relatively small number of characters... and each time it has to grow it only grows by 2*old_length + 2... so this will cost you time if you use the regular StringBuffer() constructor and will be reading in a lot.

if you have the content size (ie. your filelen var) then it may be optimal to do something like
that is, assuming filelen is the # of characters, i don't know what getLength() returns.

oh forgot to say thanks for the ideas...and for probably pointing out another bad move on my part. 

I really need to go buy a good Java ME book and read the whole thing.  BUt then that would be doing things the right way!  Either got any recommendations?

I tried byte by byte (or really char by char) but its just too slow.  I think, and its only ametuer phone coders opinion,,,I think I did it right to put it in a background thread that polls for available bytes and does reads by bigger blocks for thruput with some 100mS sleeps.  I tried char by char and it took 5-10 minutes to work.  With this method I get it done in 20 seconds and I have the chapters up in a ListFrame in a few seconds.

Yes I did.  Thanks to you guys!

I am working on test spec to make sure I got all bases covered.  I am making some test files first....spent too much time coding for Uncle Sam to not have a million tests and benchmarks and of course ...a formal looking spec.