Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Q1. You've taken this out of context (no joke intended :)</p> <p>If you see the original article, the leak actually occurs in the next fragment of code where the Bitmap field is introduced. Roman then clearly explains why it leaks. The code you have shown will NOT leak.</p> <p><a href="http://www.curious-creature.org/2008/12/18/avoid-memory-leaks-on-android/">http://www.curious-creature.org/2008/12/18/avoid-memory-leaks-on-android/</a></p> <p>Q2. Use Activity context only where there is no other choice and NEVER allow a reference to it in something with a scope greater than the scope of the Activity it references. The code you've shown doesn't leak as far as I can see since nothing has a context reference with a scope greater than your Activity. Do you suspect that it does?</p> <p>Q3. When using Bitmaps, static references or not, I am in the habit of unbinding Bitamps from Views in onPause() (remember onDestroy() is not guaranteed but it's kind of irrelevant as if you're being destroyed, your process is killed so GC isn't a concern). The linked article also explains how to do this. I have made it a template pattern for any of my Activities handling Bitmaps.</p> <p>[EDIT]</p> <p>Sorry, I just checked. The article does not show how to unbind. Here's the pattern I use:</p> <pre><code>@Override protected void onPause() { super.onPause(); unbindDrawables(findViewById(R.id.mainLayout)); System.gc(); } @Override protected void onDestroy() { super.onDestroy(); unbindDrawables(findViewById(R.id.mainLayout)); System.gc(); } private void unbindDrawables(View view) { if (view.getBackground() != null) { view.getBackground().setCallback(null); } if (view instanceof ViewGroup &amp;&amp; !(view instanceof AdapterView)) { for (int i = 0; i &lt; ((ViewGroup) view).getChildCount(); i++) { unbindDrawables(((ViewGroup) view).getChildAt(i)); } ((ViewGroup) view).removeAllViews(); } } </code></pre> <p><code>mainLayout</code> is the root view of the Activity layout.</p> <p>I include onDestroy() since I might manually finish() my Activity.</p> <p>Note. Calling system.gc() is a complex subject and you <strong>might</strong> want to omit it. There are some good discussions on here why it might not be a good thing to do, principally concerned with performance. However, in my view, when an activity is being destroyed, hinting that now is a good time to perform GC can do no harm. The inefficiency of calling it unnecessarily will be lost in the overheads of destroying an activity.</p>
    singulars
    1. This table or related slice is empty.
    1. POProper onDestroy() / How to avoid memory leaks
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSimon
    1. USSimon
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POProper onDestroy() / How to avoid memory leaks
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COYou say the process is killed, but how can there be memory-leaks at all in that case? Is the object-graph preserved somehow? And what's the benefit of unbinding Drawables?
      singulars
      1. PO
      1. USFabian Zeindl
    2. COOf course there are no leaks if your process is killed, which is fine if Android kills your process but not if you destroy by for example an orientation change in which case your activity instance is destroyed but since the bitmap is static, it is not. The bitmap now has a reference to the (no longer existant) context and all of it's resources preventing the GC from freeing them. The key here is static so, yes, you only need to do this if you have static references but I use it anyway, since it does no harm and I will never make the mistake.
      singulars
      1. PO
      1. USSimon
    3. COwill this routine descend through Fragments?
      singulars
      1. PO
      1. USrupps
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload