lukeredpath
Luke Redpath
In my quest for loosely coupled, reusable UITableViewController design, this is my #GOOS inspired design so far. http://t.co/pSggwg47
andrewa2
Andrew Sardone
@lukeredpath interested in “repository” vs MOC objects, & splitting apart datasource/delegate objs – I usually extract them into same object
@lukeredpath interested in “repository” vs MOC objects, & splitting apart datasource/delegate objs – I usually extract them into same object
lukeredpath
Luke Redpath
@andrewa2 I think the controller is quite suited to being the delegate as its largely to do with dealing with user interaction.
@andrewa2 I think the controller is quite suited to being the delegate as its largely to do with dealing with user interaction.
andrewa2
Andrew Sardone
@lukeredpath absolutely agree, just found the mapping from models/keypaths to index paths is usually shared between delegate & data source.
@lukeredpath absolutely agree, just found the mapping from models/keypaths to index paths is usually shared between delegate & data source.
lukeredpath
Luke Redpath
@andrewa2 my "data source" object encapsulates that, but provides a public objectForIndexPath: method, like my LRTableModel API does.
@andrewa2 my "data source" object encapsulates that, but provides a public objectForIndexPath: method, like my LRTableModel API does.
andrewa2
Andrew Sardone
@lukeredpath gothca. I usually have the same method privately, but it should be exposed publicly for delegate use. I like it – thanks!
@lukeredpath gothca. I usually have the same method privately, but it should be exposed publicly for delegate use. I like it – thanks!
lukeredpath
Luke Redpath
@andrewa2 this is what my controller code looks like so far (anonymised): gist.github.com/e3c9a65769efb9…
@andrewa2 this is what my controller code looks like so far (anonymised): gist.github.com/e3c9a65769efb9…
lukeredpath
Luke Redpath
@andrewa2 the great thing that the controller isn't coped to a concrete repository imp, just a protocol.
@andrewa2 the great thing that the controller isn't coped to a concrete repository imp, just a protocol.
lukeredpath
Luke Redpath
@andrewa2 so I can provide a "persistent" repository that uses Core Data, or a fake one for my tests.
@andrewa2 so I can provide a "persistent" repository that uses Core Data, or a fake one for my tests.
lukeredpath
Luke Redpath
@andrewa2 that in turn returns an simple, fixed result set imp. rather than a LRFetchedResultSet.
@andrewa2 that in turn returns an simple, fixed result set imp. rather than a LRFetchedResultSet.
lukeredpath
Luke Redpath
@andrewa2 its one of those designs that has just seemed to "click", if you know what I mean. It *feels* right, and tests well.
@andrewa2 its one of those designs that has just seemed to "click", if you know what I mean. It *feels* right, and tests well.
andrewa2
Andrew Sardone
@lukeredpath It feels quite right! The repository just gives your VC (and hence data source) what it wants, no hard CD dependency.
@lukeredpath It feels quite right! The repository just gives your VC (and hence data source) what it wants, no hard CD dependency.
lukeredpath
Luke Redpath
@andrewa2 yes, it means I can hide it from other details to, i.e. if I need to fire off a background HTTP request.
@andrewa2 yes, it means I can hide it from other details to, i.e. if I need to fire off a background HTTP request.
lukeredpath
Luke Redpath
@andrewa2 results from back from API, Core Data context is updated, result set picks up change automatically, controller updates - easy!
@andrewa2 results from back from API, Core Data context is updated, result set picks up change automatically, controller updates - easy!
andrewa2
Andrew Sardone
@lukeredpath yep! That’s *exactly* how my model works, but VC coordinates an NSFRC & a DataController (query remote API, update CD) – gross!
@lukeredpath yep! That’s *exactly* how my model works, but VC coordinates an NSFRC & a DataController (query remote API, update CD) – gross!
lukeredpath
Luke Redpath
@andrewa2 its good to hear somebody else say it sounds right though. I'm fed up with writing "typical" iOS controller code.
@andrewa2 its good to hear somebody else say it sounds right though. I'm fed up with writing "typical" iOS controller code.
andrewa2
Andrew Sardone
@lukeredpath same. A lot of my VCs had a warmUpEngine method, tells DataController to query remote API. The repository removes those details
@lukeredpath same. A lot of my VCs had a warmUpEngine method, tells DataController to query remote API. The repository removes those details
andrewa2
Andrew Sardone
@lukeredpath At first glance I’m also liking this more than hiding things behind an NSIncrementalStore.
@lukeredpath At first glance I’m also liking this more than hiding things behind an NSIncrementalStore.
lukeredpath
Luke Redpath
@andrewa2 I've made a simplification to that design that allows me to eliminate the "table model". Will revise soon.
@andrewa2 I've made a simplification to that design that allows me to eliminate the "table model". Will revise soon.
lukeredpath
Luke Redpath
@andrewa2 I've hit one hitch - if you use Storyboards and rely on prototype cells, its hard to test the controller without the storyboard.
@andrewa2 I've hit one hitch - if you use Storyboards and rely on prototype cells, its hard to test the controller without the storyboard.
lukeredpath
Luke Redpath
@andrewa2 the work I did the other day on LRFetchResultSet was key to getting "repository" objects working in a loosely coupled way.
@andrewa2 the work I did the other day on LRFetchResultSet was key to getting "repository" objects working in a loosely coupled way.