Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Andreas,</p> <p>If your issue is simply an <code>onDraw()</code> issue. You may do so quite easily with an overridden <code>Draw(canvas)</code> in your <code>GridView</code>. This has the side effect of increasing processor requirement while your Activity is loaded, but can create the desired effect. Such an override would be as follows:</p> <pre><code> //This may be used in your GridView or Activity -- whichever provides the best result. public void draw(Canvas canvas) { int _num = myGridView.getChildCount(); for (int _i = _num; --_i &gt;= 0; ) { View _child = (View)myGridView.getChildAt(_i); if (_child != null) _child.draw(canvas); } } </code></pre> <p><strong>An Additional Technique (EDIT)</strong></p> <p>Sometimes overriding the <code>draw()</code> can have adverse effects. What we're really trying to do is trigger the objects to draw when they are available to. Overriding <code>invalidate()</code> in a similar manner can often have an effect depending on where the issue lies. Since we've established that we are getting strange results with overriding <code>draw()</code>, this seems to be the next course of action.</p> <pre><code>//This definitely goes in your GridView public void invalidate() { int _num = myGridView.getChildCount(); for (int _i = _num; --_i &gt;= 0; ) { View _child = (View)myGridView.getChildAt(_i); if (_child != null) _child.invalidate(); } } </code></pre> <p>It has to be understood that this technique may not force a draw when you want, but merely lets the OS know that it is ready to be redrawn when it is available. Because invalidation does not automatically cascade down the <code>View</code> tree, if your <code>ImageView</code>s are nested deeper than the <code>GridView</code> you will have to adjust. This can be used in conjunction with the <code>draw()</code> or independantly. Additionally, when used with the appropriate placement of an <code>invalidate()</code> statement, may lower response but should help to keep your images drawn.</p> <p>The issue may simply be a delayed layout or draw issue. If that is the case, a Lazy Loading solution might be best. A lazy loader is a way to load the content when it is needed, so that it typically uses less memory, and processing, and shows what is needed, when it is needed. Now I'm not awesome at Lazy Loading because I rarely have the need. But there is a GREAT example of code at <a href="http://blog.jamesbaca.net/?p=67" rel="nofollow">this site</a>. It is tailored for a GridView, as well.</p> <p><strong>Deemed Not Applicable (but may be useful for others)</strong></p> <p>The only other kind of issue that I think it may be is an Out of Memory issue that isn't causing a Force Close (and yes, they do exist). These are especially elusive and painful to take care of. The only way to spot these is in your LogCat during the load or scroll, with the error view selected. Or you can go through an entire LogCat dump (I recommend clearing the Log before you run your app first).</p> <p>With this kind of issue, it becomes important to know how the lifecycle of an image works. If your images are being shrunk to thumbnail size in order to display, I would consider making real thumbnails alongside the fullsize images. Because shrinking an image in runtime temporarily requires more memory than keeping it the original size. Since this is all happening in one fell sweep, this may be a temporary problem, exhibiting itself permanently. This will dramatically lower memory requirements. (As a for instance, a 2x2 image requires 16 Bytes plus the Header, whereas a 4x4 image requires 64 Bytes plus the Header [400% for double the size!!].)</p> <p>Additionally, adding System.gc() to critical places in your code will force a garbage collection, freeing up more memory, more often. (This is not a guarantee to free memory, but works more often than it doesn't).</p> <p>The BEST solution would probably be a combination of all three, but would require a little more information than what we have with this question. For instance, we would need to see if you have overridden <code>draw()</code> and <code>onMeasure()</code> and <code>onLayout()</code> and maybe some other details.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COGood man, i'll try all of your suggestions out. I know for sure the problem isn't an out-of-memory exception. I have tried the program on a plethora of android devices, and the problem is always the same - the rows that are not visible when the gridview is first loaded does not draw, doesn't matter how many of them are off-screen. I'll upload an illustration shortly.
      singulars
    2. COAs for the other things - i haven't overriden draw, onMeasure or onLayout. I am however doing my coding in a subclass of GridView, and not the activity, if that makes any difference. I also just tried out the overridden draw-method you supplied, with to say the least interesting results - this.getChildCount() returns 165 (consistent with the number of children on screen at loadtime), when the actual number is 225. Also it only draws the first tile when overridden, for some reason, even though it does call draw on all the children.
      singulars
    3. COThat is indeed interesting... It should draw ALL of the children (with no regard to viewport). OK, so its not Out of Memory. It is definitely a drawing issue. That's good to know... Since your code is largely in your `GridView`, I need to ask... was the `draw()` code in the `GridView` or the `Activity`? I ask because WHERE your draw() can have a large impact on WHAT is drawn. I was surprised to learn that a child `View` is not invalidated when a parent `View` is like in some other languages, for instance. *P.S. I hate draw issues... ROFL*
      singulars
 

Querying!

 
Guidance

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