Build a Grid View Controller

[jverkoey]

A general-purpose grid view controller can be used to present information in grid form. A good example of such a controller would be a photo album thumbnail viewer that shows a grid of photos that can be tapped to view the larger photo.

Some thought should be given as to whether a grid view controller should be an implementation of a table view controller or a completely new implementation. There are benefits to implementing a table view controller such as: section headers, the index scrubber, and a well-tested implementation. The benefit of writing a new grid view controller is mostly in simplicity, as there are some features of a table view controller which don't apply very well to a grid view controller (accessory indicators, editing).

[rogchap]

I've used DTGridView in the past which is based on the same ideas as a UITableView which may help:

https://github.com/danielctull/DTGridView

[bmeurer]

I need a grid view myself, so I may look into this. I already have a basic grid view, but it's rather messy and I gotta clean up that thing anyway.

[bmeurer]

For the reference, here is a list of (mostly) working grid views for iOS. Neither of them is in really good shape, tho, IMHO.

• https://github.com/danielctull/DTGridView
• https://github.com/pppoe/OmniGridView
• http://code.google.com/p/pf-gridview/
• https://github.com/kolinkrewinkel/KKGridView/

[schubter]

here's another one:

https://github.com/kolinkrewinkel/KKGridView/

[jverkoey]

Oh my, there are quite a few.

[jverkoey]

Looks like DT and KK both provide the most comprehensive feature set.

[bmeurer]

From a quick look, the KK API seems to be the best one (and cleanest). A port of the KK stuff to non-ARC and without Objective-C++ would be a nice addition to Nimbus, IMHO.

[rogchap]

Was just looking at KK...

They clame that it has support for non-ARC applications:

"Remember that your project need not use ARC to include KKGridView."

But I don't see how this is achieved!?

They seem to get rid of define blocks for ARC: https://github.com/kolinkrewinkel/KKGridView/commit/257d7985cbf82ebe064b046ca65d17e7a20a06c2#KKGridView/KKGridViewCell.h

[bmeurer]

You can of course use KKGridView in a non-ARC application, but the KKGridView (sub)project has to be build with an ARC-enabled compiler, which means Xcode 4.2 and above.

[jverkoey]

Hm. It's fishy to me that performance was a problem at all, and that arc apparently fixed the performance issues. From what I understand of ARC, if you're doing sensible memory management in the first place then the only difference should be the amount of code you write. I haven't buried myself in ARC yet fully though, so I may be completely off.

[bmeurer]

Nevertheless the API looks really cool. There should be no need to reinvent NSIndexPath, but aside from that, it's well designed.

[rogchap]

That makes sense, thanks @bmeurer

[rogchap]

@jverkoey I think you are right. If your memory management is right in the first place then performance should be exactly the same. ARC only adds the retains/releases at compile time in the places you should have done if you do MM manually; runtime should be the same.

I'm wondering if it handles autorelease more efficiently and that is where the performance increase is?

[bmeurer]

Yes autorelease pool push/pop is slightly faster with ARC, but that shouldn't really matter unless your code does nothing but pushing/popping autorelease pools.

[AquaGeek]

@rogchap ARC also gets rid of redundant retains/[auto-]releases.

@bmeurer Your whole app is wrapped in an autorelease pool, so unless you never use methods that return an autoreleased value (e.g. [NSArray arrayWithObjects:...]) this is going to affect your apps a lot (in a good way).

[jverkoey]

Sweet, good to know @AquaGeek. Looks like it may be worth seriously considering support for ARC in Nimbus then.

Related: #40.

[bmeurer]

@AquaGeek As said, the performance improvements are about pushing/popping autorelease pools (not autoreleasing objects!). That is, if you create/drain autorelease pools A LOT, then you will sure benefit. But why should anyone create/drain autorelease pools all the time? Most people will not even create a single autorelease pool on their own.

[AquaGeek]

@bmeurer I completely agree that most people will not create a single autorelease pool on their own, but let me expand on my earlier comment. Per the Memory Management Programming Guide:

The AppKit and UIKit frameworks automatically create a pool at the beginning of each event-loop iteration, such as a mouse down event or a tap, and drain it at the end.

So while you may not be pushing and popping autorelease pools in your code, UIKit is - each time through the event loop. However, I don't think your app/library would need to use ARC to gain this improvement if it's been done in the underlying event loop code.

[bmeurer]

That's right, but the autorelease pools used within AppKit and UIKit are not affected by the ARC settings of your project. That said, there's no difference in performance here by switching your project to use ARC.

As mentioned by @jverkoey, it's rather fishy that performance was an issue at all. And even then it is highly unlikely that the performance issues would be related to memory management.

[dbarden]

@bmeurer : Are you working on this issue? I'm planning to use a Grid View Controller to display some thumbnails for a Photo Album.

The reason why I'm asking is that if you are not currently working on it, I'll give it a try and see if I can implement the suggestions (port the KKGridView without the special NSIndexPath).

[bmeurer]

I did some initial work, but it's not in a usable state. So feel free to give it a try.

[dbarden]

OK, I'll start working on it.

I found yet another implementation of a GridView, for reference: https://github.com/AlanQuatermain/AQGridView

[rogchap]

I've looked at AQGridView before and it is not as "polished" as DTGridView or KKGridView

[jverkoey]

Awesome. Thanks @dbarden.

[NukemHill]

Has any progress been made on this? I was just looking at the nimbus photo example, and was thinking the grid view would be useful as an alternative interface.

[kolinkrewinkel]

C++ structs are being due to the 20% increase in performance from not unpacking/packing NSNumbers in any of the NS* classes. ARC's helpful because 1) no memory management 2) 1/4 of the time spent in objc_cmd is eliminated 3) Returns and method calls are automatically evaluated, cached, sped up, etc. Glad you guys like the project. :)

[steipete]

SSCollectionView is also worth listing. It's well documented and even supports animations.

https://github.com/samsoffes/sstoolkit/blob/master/SSToolkit/SSCollectionView.h

[steipete]

I've now reviewed pretty much all of them; GMGridView (which is not on the list here) looks the most promising one.

https://github.com/gmoledina/GMGridView

[jverkoey]

Kinda glad this got punted on forever. Yay iOS 6!

[kolinkrewinkel]

Yep, awesome.

Sent from my iPhone

On Jun 19, 2012, at 7:00 PM, Jeff Verkoeyen reply@reply.github.com wrote:

Kinda glad this got punted on forever. Yay iOS 6!

---

Reply to this email directly or view it on GitHub: https://github.com/jverkoey/nimbus/issues/26#issuecomment-6443358

[NukemHill]

What does iOS 6 bring to the table wrt grids?

[NukemHill]

Ah. Collection Views. Hadn't realized that grids were a part of that.

Kewl.

[kolinkrewinkel]

Today Jon informed me that Spotify used KKGridView in their app. Glad to know it helped someone out before Apple came in and set the standard.. and made every developer's life easier. :)