Upcoming and OnDemand Webinars View full list

Peek a View

Mark Dalrymple

When I’m developing new code, my usual habit is to do a lot of small iterations. That gives me a little bit of success fairly often. I’m not as happy if I have to work for a long time until I can see something appearing on the screen.

When I’m writing a new NS- or UI-view, I used to write a pretty generic -drawRect: so that I could see that I’m actually drawing something on the screen:

- (void) drawRect: (CGRect) rect {
    CGRect bounds = self.bounds;
    
    [[UIColor whiteColor] set];
    UIRectFill (bounds);
    
    [[UIColor blackColor] set];
    UIRectFrame (bounds);
    
} // drawRect

This outlines the area of the view, like you can see in this simulator screenshot.

Peekaview plain

A typical development spin is: I need a view. Make the header and implementation files. Put in this placeholder drawRect. Build. Fix typos. Add the view to the xib. Run. Make sure the view is there. Then commit that version to svn or hg or git or whatever, and then start on the actual guts of the view.

Recently, though, I’ve been using a variant of this, where the view draws in a different color. This is proved to be useful in some unexpected situations. Here’s the complete view implementation, also available at this gist:

@interface BlahView : UIView
@end


@implementation BlahView

- (void) drawRect: (CGRect) rect {
    CGRect bounds = self.bounds;

    UIColor *color = [UIColor colorWithRed: (((int)self) & 0xFF) / 255.0
                              green: (((int)self >> 8) & 0xFF) / 255.0
                              blue: (((int)self >> 16) & 0xFF) / 255.0
                              alpha: 1.0];

    [color set];
    UIRectFill(bounds);

    [[UIColor blackColor] set];
    UIRectFrame(bounds);
} // drawRect

@end

Instead of white, it makes a new color based on the address of the object. This means that each object, because it lives at a different address, will get a different fill color:

Peekaview color

I’ve been using this for more than just fresh views. Lately I’ve inherited a project that uses Jim Dovey’s [AQGridView](https://github.com/AlanQuatermain/AQGridView). I wanted to explore the API before I did any surgery to the application, so I wrote some small tests. I needed some views to populate the grid view. It’d be nice to be able to tell of AQGridView was recycling views or making them fresh. I could tell by the colors in the resulting app what the behavior is:

Peekaview gridview

And in the same app, I was needing to add a breadcrumb view at the top of the screen. I wanted to make sure I was adding the view to the right place in the window, and the right place in the code. I just plopped the BlahView into a promising view controller file that looks like it’d be the one who would be best suited to create and update the breadcrumbs. (I don’t even bother having a distinct header and implementation file for the BlahView – its use is so transient, it just gets pasted in where it’s needed, used, then removed).

So the first thing I did was just create a new view and add it to the container:

Peekaview breadcrumb

Then I could figure out how its position works in the scroll view, when it appears and disappears, and all that kind of fun stuff you need to learn when you’re modifying an existing codebase. By looking for color changes, I could see if the breadcrumb view would be recycled or recreated. I could do a lot of the Necessary Work for this feature before actually designing and implementing the breadcrumbs.

And lastly, I needed to track down some weirdness I was seeing with a UIScrollView. Seemingly insane things were happening inside of the main application, things I wasn’t understanding. When I find myself thrashing around, I stop and make a fresh project. Kind of like creating a small test case for a bug before you file a Radar, I created a small test case that I could just play around in, and use the objects in question. That way I had a controlled environment to see if my problem is an issue with the application, with the UIScrollView itself, or I was just being dumb and misunderstanding something. (Nine times out of ten, it’s that last one.)

So, after making a test project, and plopping down a scroll view, I needed to put some views into it. What should I use? My little BlahView, of course. I can see easily that they’re positioned correctly in the scroll view and have the right sizes:

Peekaview scroller

I was able to figure out my problem (I was getting confused by the UIImageViews that are added to the UIScrollView if you have the scroll indicators turned on) without having to create a lot of elaborate scaffolding.

Sometimes, the most effective tools are the simplest.

Not Happy with Your Current App, or Digital Product?

Submit your event

Let's Discuss Your Project

Let's Discuss Your Project