bobspryn

Ah yes. I see now that I totally missed the fact that the keyboard rect also needed to be converted. Well that was a painful point to miss!

Cool. I'll give that a whirl. Those rotation bits were a biatch. Thanks for the pointers.

Cool thanks! I'll look into those changes. I built this when I was learning iOS on the fly a year or so ago, so I'm sure things aren't all done in the absolute best fashion. I'll learn from your suggestions. Thanks!

Ah, and after re-reading your question. Yes this was a design decision, but I've had to use this same bit within a detail controller inside a split view when I've had more than one table view.

The reasoning here was that search results aren't going to come up that often, so we wanted the results out of the way most of the time to make a cleaner interface.

I believe I started to try that method but ran into issues. Wasn't aware of the scrollIndicatorInsets though, so maybe that was the issue.

Would that method have any significant advantages? Less code? Would it avoid all the crazy frame calculations depending on the rotation?

Per iOS standard design, only one ViewController is supposed to manage a full screen (iPhone) or region of a screen (iPad eg. split view controller). That's because you want to keep the view hierarchy pretty straightforward, instead of taking the view portions of other view controllers and inserting them as subviews of another VC. (Makes you feel dirty). Suggest watching the WWDC 2011 video on Customer Container VC's for an explanation.

Also it would be quite a bit of overkill and extra communication and code to back every table with a full blown view controller.

Yes, if the tableView is your main view. Otherwise you are left rolling your own solution. In the case of the iPad, the tableView is rarely my main view for my controller, so I needed a little more flexible solution.

Should be working now, although they don't seem to do the typical fullscreen thing. They should be able to with the file type and specs, but oh well.

Hmm.. It should have. I'll check it out.

Hopefully this is useful to someone. Obviously this could also just be a little display helper class (composition > inheritance) or even a category, but this was my original implementation. Might update it in the future. All the crazy coordinate stuff was the painful part.

Get them a decent GUI for git. SourceTree for one is very nice. Or get a manager that's willing to learn new things. :)

Actually I realized I can already do this even without plugin functionality. The Item object passed to the sorter has access to the element http://screencast.com/t/Z5uVYNtH8

I'd like that too. Would like to be able to sort on something stuck in a data attribute. https://github.com/javve/list/issues/35

I might take a crack at a patch if no one else does.

Sure, but if I only want certain pieces of the view to update when their corresponding model value changes, as opposed to re-rendering the whole view, I have to build an update method that does so. Not horrible in the scheme of things, but awful nice to not build manually. Is Amber.js essentially re-rendering views in their entirely, or is it more precise with its binding updates?

Another difference I suppose would be binding classnames and attributes to your model may require several lines of jQuery to manipulate, vs I believe in amber.js its done by naming convention and an options object (to use different class names).

What's the party line on one-way automatic data binding? Even that could save quite a bit of manual effort.

So I found Ashkenas full version of class inheritance in coffescript which simulates what I currently do with multiple crockford creates.

In my test case crockford's create is seemingly faster for this, but I'm sure I'm missing something. Someone mind educating me here?

http://jsperf.com/js-inheritance-test

I'm not fully following this. Explanation anywhere? Is this how you would do inheritance?

That's something I would definitely bet on (likely).