This is a current proposal that I'd like your feedback on for how we can clean up how we write RubyMotion applications. It's purely conceptual at the moment, and there would have to be some framework development to make this work the way described here.
Please submit your feedback, as a joint effort we can clean up our RubyMotion applications and make it easier for Rails developers to expand their skills into RubyMotion development.
The main points of this are:
- Find a RubyMotion project structure where parts of the projects can be related to similar Rails parts
- Build a framework to support this that works for both iOS and OS X
- Take advantage of helper libraries where possible, likely RMQ, CDQ, and/or BubbleWrap
- Come up with new conceptual design patterns if need be
- Abstract some of the differences between iOS and OS X applications
The difference between controllers in Rails where they handle mutliple different actions versues in iOS and OS X where controllers are focused solely on one screen/window/set of views can trip developers up a lot. I don't suggest a move to the Rails way of doing things completely, but maybe we can really focus the controller's responsibilities on bringing in model data and getting the view ready for display.
class MainViewController < RMRailsController::Base
view MainView
delegate MainDelegate
stylesheet MainStylesheet
def setup
delegate.data[:posts] = Post.all
end
endIn this setup, view will create an instance of MainView in the loadView method and assign it to self.view, and style it using the stylesheet assigned with stylesheet. The view would then have it's delegate assigned to be an instance of the class assigned by delegate. The delegate would basically act like the JavaScript in a web application handling interaction, of course some helpers would need to be provided for being able to access to controllers things happen in so that it doesn't have to hold references to it.
In the setup method would go the kinds of things you would find in index, show, or any of the other Rails controller method defintions, though data would have to be assigned to the delegate so that it has access to it.
This setup reflects basic Rails app structures:
- Controller = Controller
- View = View (already well defined)
- Stylesheet = Stylesheet (already well defined)
- Delegate = Scripts
- Model = Model (already well defined)
class MainDelegate < RMRailsDelegate::Base
def myView(myView, viewForSomePostition:position)
SectionView.style do |v|
v.title = self.data[:posts][position].title
v.content = self.data[:posts][position].content
end
end
def myView(myView, sectionSelectedAtPosition:position)
navigate_to(DetailViewController, post: self.data[:posts][position])
end
endThis is just early days for this so far, I'd love to hear your ideas. Currently the proposed solution would likely only handle VERY simple applications, and would likely have trouble working well on OS X too. Please share your thoughts.
This is, indeed, a very different direction from what I've been taking these days, as far as wrappers and controller design are concerned. I see a lot of "ProMotion"-style ideas in here, but I think ProMotion remains more similar to plain Cocoa code.
And while OSX is VERY similar, it also has a feeling of being VERY different. It's a much older system, lots of legacy there. Hard to describe why/how, but it's a different beast, so heads up there.
Anyway, my worry in taking this approach - and it's just a worry, I'm not saying it can't be done! - is that by making the controller more "rails" like you could inadvertently put up an impediment to learning the CocoaTouch frameworks. ProMotion gets dangerously close to this line, but like I said I think it leans towards behaving much like a plain UIViewController.
On a positive note, there is a huge advantage to having a more "rails like" system, just for familiarity if nothing else. But something like this was attempted long ago, with the "Three20" project, which was ultimately abandoned. It had a Router and things to make the app feel "web server like", but in the end people banged their heads against it in frustration and gave up on it.
So I would approach the problem like this:
indexmethod, theBlogmodel, the template, and any javascript on the front end.Models are models, and views are pretty much views, but that index method that fetches the list of blogs? That doesn't belong in a view-controller! You should use a Storage class for that, which keeps your controller light and testable.
I propose that the JavaScript code on a webpage is the actor that is most similar to a UIViewController. It deals with state changes in much the same way a UIViewController does.
I don't have a conclusion per se, but I hope these ramblings are helpful! Take em with a grain of salt; it's just MY take on things. 😃