Hi,
I saw recently I could take out an insurance policy that had unlimited
cover amount, I guess the premium has unlimited cost as well ;-)
Regards
On Tuesday, July 31, 2012 10:51:11 AM UTC+10, Dianne Hackborn wrote:
Btw, I love how more and more I see people dragging out this quote every
An insurance policy that covers out of memory exceptions?
2012/7/31 gjs garyjamessi...@gmail.com
Hi,
I saw recently I could take out an insurance policy that had unlimited
cover amount, I guess the premium has unlimited cost as well ;-)
Regards
On Tuesday, July 31, 2012 10:51:11 AM
There's your problem Kostya - your paying for the wrong thing - you need
insurance for/against out of memory errors, not exceptions.
On Tuesday, July 31, 2012 5:34:19 AM UTC-4, Kostya Vasilyev wrote:
An insurance policy that covers out of memory exceptions?
2012/7/31 gjs
On Tue, Jul 31, 2012 at 2:51 AM, Dianne Hackborn hack...@android.com wrote:
Btw, I love how more and more I see people dragging out this quote every
time they encounter some limit that they have to deal with, as if there
should just not be limits on the resources they can use.
There should not
On Tuesday, July 31, 2012 5:28:19 PM UTC+1, Latimerius wrote:
On Tue, Jul 31, 2012 at 2:51 AM, Dianne Hackborn hack...@android.com
wrote:
Btw, I love how more and more I see people dragging out this quote every
time they encounter some limit that they have to deal with, as if there
On Sun, Jul 29, 2012 at 5:45 PM, bob b...@coolfone.comze.com wrote:
Worried about memory? Try this:
application android:largeHeap=true
No.
First of all, this only helps you on higher-end devices that have lots of
memory to give you. So you still need to look at the memory available and
*“640K ought to be enough for anyone”*
On Monday, July 30, 2012 1:30:46 AM UTC-5, Dianne Hackborn wrote:
On Sun, Jul 29, 2012 at 5:45 PM, bob b...@coolfone.comze.com wrote:
Worried about memory? Try this:
application android:largeHeap=true
No.
First of all, this only helps you on
On Mon, Jul 30, 2012 at 10:59 AM, bob b...@coolfone.comze.com wrote:
*“640K ought to be enough for anyone”*
Um, no. There is nothing similar to these two things.
Our limit is: devices don't have an infinite amount of RAM, applications
must be written to live within the available RAM on the
Btw, I love how more and more I see people dragging out this quote every
time they encounter some limit that they have to deal with, as if there
should just not be limits on the resources they can use.
On Mon, Jul 30, 2012 at 5:50 PM, Dianne Hackborn hack...@android.comwrote:
On Mon, Jul 30,
I've written a simple test where I have:
FragmentManager fm = getSupportFragmentManager();
FragmentTransaction ft = fm.beginTransaction();
ft.hide(_sv);
ft.commit();
When the fragment gets hidden - onPause doesn't get fired. However, system
fires a chain of callbacks up to onDestroyView when I
Worried about memory? Try this:
application android:largeHeap=true
On Sunday, July 29, 2012 4:11:55 AM UTC-5, Dmitriy F wrote:
I've written a simple test where I have:
FragmentManager fm = getSupportFragmentManager();
FragmentTransaction ft = fm.beginTransaction();
ft.hide(_sv);
Hi, I'm developing an app which uses ViewPager(holds 4 fragments) and a
layout that hosts single-page fragments. I haven't populated my fragments
with bitmap data but I'm already anxious about memory management.
Because of the bogus design I can't extract ViewPager to a separate
activity
1) Does ImageView.SetImageResource applied against the same id twice or
thrice consumes memory for the same bitmap or uses a separate range for
every imageview element ?
I don't quite understand your question. When a Bitmap is loaded as a
Drawable (which is what ImageView does), it gets
Thanks for the answers! Would you mind to suggest on the part about
fragments and memory management ? I decided to implement the app with 3
activities and about 8 fragments. The activity number might slightly
increase yet I think it's not the fragments but their bitmaps that gonna
cause
Thanks for the answers! Would you mind to suggest on the part about
fragments, bitmaps and memory management ? I decided to implement the app
with 3 activities and about 8 fragments. The fragment number might slightly
increase yet I think it's not the fragments but their bitmaps that gonna
If you have a fragment that holds on to a lot of memory in its view
hierarchy and are concerned about this, then use
FragmentTransaction.remove() to make it no longer visible -- that will
remove it from its parent view and destroy its view hierarchy, so it
doesn't hold on to any references. (If
16 matches
Mail list logo
