Ideas on how to write RubyMotion apps the "Rails" way

RubyMotionTheRailsWay.md

RubyMotion The "Rails" Way

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.

Goals

The main points of this are:

1. Find a RubyMotion project structure where parts of the projects can be related to similar Rails parts
2. Build a framework to support this that works for both iOS and OS X
3. Take advantage of helper libraries where possible, likely RMQ, CDQ, and/or BubbleWrap
4. Come up with new conceptual design patterns if need be
5. Abstract some of the differences between iOS and OS X applications

Concepts

Controllers

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
end

In 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)

Delegates

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
end

Further Ideas

This 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.

Ok, I'll put in my 2 cents worth. (And thanks to all for the thoughtful commentary thus far)

Web development vs mobile development vs desktop development are different enough to make me resist trying to find a "one framework fits all" solution. I've worked in all these areas over the years, and they really are different.

That said, the power of the Rails way remains very enticing. But we need to think about the reasons that Rails is so appealing. Now @kemiller broke it all down quite nicely, but let me sum it back up.

Rails is popular and powerful because it is OPINIONATED. There is "one true way" (sort of, I'll get back to that) to put Rails web apps together, using the supported bits and pieces. And, for better or worse, that is the way the majority of people build apps using Rails. Over time, those bits and pieces have changed, as new (perhaps) better ways of doing stuff are found. But at any one time, you could do a "rails new app", and generate a scaffold, and have a functional app up and running in very short order.

Even though there is "one true way", Steve Klabnick's article on the "two default stacks" demonstrates the flexibility of the Rails way, while pointing out that a second default stack exists, and is almost as opinionated as the first one:
http://words.steveklabnik.com/rails-has-two-default-stacks

So, IMO, what RubyMotion is lacking at the moment, is this well defined, relatively complete, opinionated stack. Or even two stacks. Something that is built right in to the "motion create" command, that lays out a nice set of gems that can be used to build a basic app, maybe even with some scaffolding.

I know all the creators of all the awesome gems we are using will now be getting nervous (will my precious be picked?), but I think there is room for all of the options, as long as we remain as flexible and pluggable as Rails has become. But I'd really like to see an opinionated stack emerge as the default. And I think the iOS stack will be different than the OSX stack.