Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I've submitted another answer instead because after clarification, the issue is definitely different from what I initially believed. The techniques in the previous answer should not be forgotten, however, and are a great resource for other related issues, so I'm keeping it there.</p> <p><strong>Problem:</strong></p> <p>The GridView now draws (kinda), but is repeating the same images over and over again, resulting in horrible artifacts. The resulting artifacts are so bad, that it doesn't really give a good indication as to whether the other views are even present. This issue is actually caused by an issue with "too much transparency". </p> <p><strong>Android and Transparency</strong></p> <p>Android does a wonderful job handling transparency, allowing objects <em>below</em> the current view to be drawn while the <em>top</em> view is in focus. However, if all of the Views are transparent, then there is nothing for Android to draw behind everything when it needs to refresh. Ordinarily, this is not an issue. </p> <p>Generally, developers use the tools provided us and just try and make some neat things happen with them. (YAY!) And as long as we use them, Android says (pretty much) "I know what to do!!" When we begin with custom Views, however, Android can get a little freaked out, especially when it comes to drawing appropriately.</p> <p>Your GridView is not actually a <code>GridView</code>. It is an <em>extended</em> <code>GridView</code>. As an extension of an Android View, Android makes no assumptions about how it should be drawn, soooo.... As a result, the normal opaque background for your GridView does not exist. One would think, <em>"but I have it in a <code>RelativeLayout</code>. Isn't that enough?"</em> The answer is no. Layout objects are Layout objects. They have no background unless we specify them. </p> <p>This becomes exacerbated when you do Scrolling and other similar movements or animations. In these cases, Android tries to cache. The caching happens kind of below <strong>all</strong> of the Views, but the result is that since it is all transparent, you see the whole process. And it doesn't reset until it needs to clear the cache. This is why is gets uglier and uglier.</p> <p>In other words, the "Window" may appear black, but is not actually black...</p> <p><strong>Solution (Part I):</strong></p> <p>So the answer is to set an opaque background to either the extended <code>GridView</code> or to one of its parent Views. This should resolve the artifacts you are seeing when you scroll. And it should allow you to see properly how and if the other views are rendering. Ultimately, you want to try and apply the background to the topmost View that encompasses all Views. The background can be as simple as setting the background color (as it creates an opaque drawable).</p> <p><strong>Next Steps:</strong></p> <p>I've noticed you have omitted some pertinent code. I really need to know what kind of <code>Adapter</code> your <code>TileAdapter</code> extends and how it gets its base information. This can have an impact on how it is gaining and appropriating the draw events. Once we know that, we can work on fixing the rest. </p> <p>I also need to know how you are positioning the Tiles (there is no positioning code). Since there is not positioning code, there is no way to know whether the Views are actually being added. The default behavior for ImageViews is that if at least some part of them aren't visible, they don't get added to the hierarchy until they are. We want to force that issue</p> <p>The end result may still require adjusting layout, measures or draws, but we won't know until we get an accurate representation of what is happening.</p> <p><strong>An Alternative Result</strong></p> <p>Something, I wish happened with scrolling games more often is if they <em>started</em> with a zoomed out position and we could "move" to the zoomed in position.. This could easily resolve your ChildCount, as you said if it fits neatly on the screen, they all draw. And the initial zooming in could happen after everything is all loaded. Then you have a nice graphical effect indicating load is complete. A Zoom out is just a normal animation, so easy to implement. and you know all of your children are loaded. Additionally, it may limit the code you have to enter in order to get it working correctly. Finally, it can all be done with the same GameGrid object. :)</p> <p>I don't know if you thought about this, but I figured, "hey, this seems like the easy way to kill more than 2 birds with one stone."</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. This table or related slice is empty.
 

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