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.

@colinta I definitely share the concern of making it too hard to access the Cocoa/Cocoa Touch side of things, I guess I didn't express though that things like RMRailsController::Base wouldn't completely abstract everything away, it would be fairly lightweight and just be a subclass of UIViewController/NSWindowController, and you could define the viewDidLoad methods and such as normal.

On the topic of Three20, I want to avoid the "make it web-server like" path, and just make it easier to mentally define what an object relates to in Rails, vs actually making it exactly like Rails, no need for a router or other actors, it doesn't make sense outside of web servers.

@kemiller convention over configuration is something I had in mind, but hadn't thought through too much on how it would surface in the code, but @andyjeffries had a great point of making that view, delegate, and stylesheet stuff something like that where there is a sensible default from naming conventions.

I have an idea, but would like to know exactly what you're thinking, could you elaborate further on points 2 and 5?

I've coded up a VERY quick example using the idea @colinta put forward of creating a blogging app. So not even close to production ready, but it's a good starting point.

https://github.com/FluffyJack/RMRailsBlog

I've implemented the basics and started a gem, except no navigate_to yet, just what we're talking about above, so everything can be included as modules if need be, and there is some convention over configuration stuff.

https://github.com/FluffyJack/motion-momentum
https://rubygems.org/gems/motion-momentum

When I started learning RubyMotion the biggest change was understanding MVC in RubyMotion world. We use the same terminology in Rails world but MVC in RubyMotion has much different meaning.

I guess a good video/resource explaining the responsibilities of controller in RubyMotion world will help a bit.

Overall I like the direction of https://github.com/FluffyJack/RMRailsBlog . Nice work.

What Ken and Colin said makes sense to me.

Some random thoughts:

I would not do OS X and iOS, that seems like you'd have to dive to the lowest common denominator. IMO do iOS, then fork OS X later.

I think you can get a lot of what Rails originally had by just choosing the libraries, sensible defaults, and generators.

I personally don't see a problem with how controllers and views are in the SDK. For Rails developers, they just need to be educated a little. When I'm teaching people, once I explain how controllers and views are different from Rails they "get" it pretty fast. I wish they were named "screens" and "controls" which would remove some of the confusion, as they are not analogous.

Modules are nice if you want to separate your behavior from your controller. Some people also like to separate their layouts from their stylesheets or controllers. People like to get fancy with their libraries, but really classes and modules can do a lot.

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.