Force gridview to draw all tiles

Question

I have an android gridview which i'm using some custom scrolling going on in, to let it scroll in two dimensions - this means that the default scrolling isn't called.

I suspect this may be the reason that the rows that are off-screen are invisible. I know they're there, they affect the layout and everything, but they never draw.

So my question is this - is there any way to force the gridview to draw all of its tiles when it's loaded, and not just the visible ones?

Thanks.

Edit: To clarify - In my tileadapter, i set the child count to exactly 225. In my gridview, a call to getChildCount() returns 165.

Edit again: This only happens when the height of the gridview is greater than that of the screen - the children that are off-screen on the y axis are simply subtracted from the childcount - setting the size of the children to a number where they all fit snugly on screen removes the problem, but kills the purpose of scrolling.

Code!

XML Layout of activity:

  <LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:orientation="vertical"
  android:theme="@style/Theme.Custom"
  android:layout_width="match_parent"
  android:layout_height="match_parent">

  <TextView android:id="@+id/logmessage"
  android:theme="@style/Theme.Custom"
  android:layout_width="fill_parent"
  android:layout_height="25dip"
  android:text="LogMessage"/>

  <RelativeLayout android:id="@+id/boardwrap"
  android:layout_weight="1"
  android:layout_height="fill_parent"
  android:layout_width="fill_parent"
  android:gravity="center_vertical">
  <com.MyProject.GameGrid 
    android:id="@+id/board"
    android:theme="@style/Theme.Custom"
    android:layout_width="wrap_content" 
    android:layout_height="wrap_content"
    android:numColumns="15"
    android:stretchMode="none"
    android:verticalSpacing="0dip"
    android:horizontalSpacing="0dip"
    android:padding="0dip"
    android:columnWidth="20dip"
    android:scrollbars="none"/>
</RelativeLayout>
<RelativeLayout 
    android:id="@+id/toolbar"
    android:layout_width="fill_parent"
    android:layout_height="60dip"
    android:background="#FFFFFFFF"/>
</LinearLayout>

Activity:

public class GameBoardActivity extends Activity {

    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.gameboard);

        GameGrid Board = (GameGrid)findViewById(R.id.board);
        Board.setAdapter(new TileAdapter(this));
    }
}

GameGrid:

public GameGrid(Context context, AttributeSet attrs) {
        super(context, attrs);
        this.setNumColumns(15);

        DisplayMetrics metrics = new DisplayMetrics();
        ((Activity) getContext()).getWindowManager().getDefaultDisplay().getMetrics(metrics);
        scale = metrics.density;
        smallSize = Math.round(20 * scale);
        largeSize = Math.round(40 * scale);

        columnwidth = largeSize;
        this.setColumnWidth(columnwidth);
        Common.DebugMessage(Float.toString(columnwidth));

    }

You may notice i'm defining a small and a large size here - double tapping the screen allows you to switch between the two.

Scrolling (what you helped me with earlier)

if (myState == TOUCH_STATE_SCROLLING) {
                    final int deltaX = (int) (mLastX - x);
                    final int deltaY = (int) (mLastY - y);
                    mLastX = x;
                    mLastY = y;

                    int xpos = this.getScrollX();
                    int ypos = this.getScrollY();

                    int maxX = (columnwidth * 15) - super.getWidth();
                    int maxY = (columnwidth * 15) - super.getHeight();

                    if (xpos + deltaX >= 0 && xpos + deltaX <= maxX && ypos + deltaY >= 0 && ypos + deltaY <= maxY )
                    {
                        this.scrollBy(deltaX, deltaY);
                    }
                    else {
                        this.scrollTo(xpos + deltaX <= 0 ? 0 : xpos + deltaX >= maxX ? maxX : xpos + deltaX,
                                      ypos + deltaY <= 0 ? 0 : ypos + deltaY >= maxY ? maxY : ypos + deltaY);
                    }
                    Common.DebugMessage(this.getChildCount());

                }

Common.DebugMessage is just a helper method for printing debug messages to LogCat

TileAdapter:

public TileAdapter(Context c) {
        mContext = c;
    }

    @Override
    public int getCount() {
        return 225;
    }

    @Override
    public Object getItem(int position) {
        return null;
    }

    @Override
    public long getItemId(int position) {
        return position;
    }

    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        ImageView imageView;
        int colWidth = ((GameGrid)parent).getColumnWidth();
        if (convertView == null) {
            imageView = new ImageView(mContext);
            imageView.setLayoutParams(new GridView.LayoutParams(colWidth , colWidth));
            imageView.setScaleType(ImageView.ScaleType.CENTER_CROP);
            imageView.setPadding(0, 0, 0, 0);
        }
        else {
            imageView = (ImageView)convertView;
        }
        imageView.setImageResource(R.drawable.tile);
        return imageView;
    }

Answer 1

override getCount() of your adapter and return the length of underlying array for your adapter.And then use mAdapter.getCount instead of mGrid.getChildCount. getChildCount returns only the visible children whereas, getCount would give you total children in your dataset.

Answer 2

Honestly, my suggestion is to stop whacking on a platform API in a way that it is clearly not intended to be used. Even if through some contortions you managed to play enough games with the base GridView code to make it do what you want to do... how confident are you that your code will continue to work with the slightly changes to the GridView implementation as the platform evolves.

And really there is just no need to play these kinds of games. There is nothing special about GridView -- it is just an implementation of a view that puts things in a grid that you can scroll horizontally through?

If GridView's behavior is not what you want, the solution is to write your own view that does what you want. And with Android this is even easier because you can just go and take the GridView code from the open-source platform as a basis, get that compiling in your app (you will probably need to tweak a few things because the code as it stands takes doesn't need to be written purely against the SDK so probably isn't... but there is nothing it is doing that you can't do in a regular app build against the SDK), and then modify that code in your app to your heart's content, to make it do what want. Without fighting with a built-in widget that doesn't actually do what you want. And without fear of your carefully constructed house of cards collapsing on you if the underlying GridView implementation changes in the future.

Answer 3

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.

Problem:

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".

Android and Transparency

Android does a wonderful job handling transparency, allowing objects below the current view to be drawn while the top 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.

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.

Your GridView is not actually a GridView. It is an extended GridView. 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, "but I have it in a RelativeLayout. Isn't that enough?" The answer is no. Layout objects are Layout objects. They have no background unless we specify them.

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 all 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.

In other words, the "Window" may appear black, but is not actually black...

Solution (Part I):

So the answer is to set an opaque background to either the extended GridView 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).

Next Steps:

I've noticed you have omitted some pertinent code. I really need to know what kind of Adapter your TileAdapter 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.

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

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.

An Alternative Result

Something, I wish happened with scrolling games more often is if they started 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. :)

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."

Answer 4

Andreas,

If your issue is simply an onDraw() issue. You may do so quite easily with an overridden Draw(canvas) in your GridView. 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:

 //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 >= 0; )
        {   View _child = (View)myGridView.getChildAt(_i);
            if (_child != null)
                _child.draw(canvas);
        }
    }

An Additional Technique (EDIT)

Sometimes overriding the draw() can have adverse effects. What we're really trying to do is trigger the objects to draw when they are available to. Overriding invalidate() 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 draw(), this seems to be the next course of action.

//This definitely goes in your GridView
public void invalidate()
{   int _num = myGridView.getChildCount();
    for (int _i = _num; --_i >= 0; )
    {   View _child = (View)myGridView.getChildAt(_i);
        if (_child != null)
            _child.invalidate();
    }
}

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 View tree, if your ImageViews are nested deeper than the GridView you will have to adjust. This can be used in conjunction with the draw() or independantly. Additionally, when used with the appropriate placement of an invalidate() statement, may lower response but should help to keep your images drawn.

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 this site. It is tailored for a GridView, as well.

Deemed Not Applicable (but may be useful for others)

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).

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!!].)

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).

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 draw() and onMeasure() and onLayout() and maybe some other details.