?? If you have verified this, please report it as a bug.
The way GC works, GC work should be triggered by any allocation that
needs more memory (incremental algorithms trigger some amount of GC
work on each allocation, non-incremental algorithms do ALL the work in
this situation). The allocation should BLOCK if completing GC work in
progress on another thread would possibly allow it to succeed. If it
throws an OOM exception, it should be already determined that a
System.gc() won't help.
BTW, in theory at least, you should be catching OutOfMemoryError, not
Exception. I can see using Exception here, in case lower-level code
mishandles the situation, and ends up, say, throwing a
NullPointerException instead -- something I've seen happen in some
environments. I'm just pointing out that it's usually a poor practice
for the sake of new Java programmers reading this... This
construction will obscure other possible problems, such as an invalid
resource ID, etc.
On Mar 3, 1:37 pm, Greg Donald <gdon...@gmail.com> wrote:
> try
> {
> bm = BitmapFactory.decodeResource( resources, R.drawable.my_bm );}
>
> catch( Exception e )
> {
> System.gc();
> bm = BitmapFactory.decodeResource( resources, R.drawable.my_bm );
>
> }
>
> I know it's not the prettiest, but I've never seen the second attempt
> (after GC) fail.
>
> --
> Greg Donald
> destiney.com | gregdonald.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
