The RubyMotion Way | Hacker News Reader

The RubyMotion Way

clayallsopp.com

82 points10char33 comments

> Rubyists get a lot of flak for the kind of DSLs and black magic method_missing tricks the above libraries use; but you know what, maybe that attitude is just what Objective-C has been missing.

I politely disagree. Objective-C hasn't been missing risky and error-prone approaches that merely attempt to save a few characters at the cost of correctness. Extensions like 'when' are vague, and could just as easily be co-opted for KVO as they could for UIControl event handling.

Also, the example is not accurate. In Objective-C, you'd control-drag from the button to your action method, using Interface Builder.

I think the value add of a `when` style isn't saving keystrokes but improving readability. What happens when the event fires is right there in-line with the button, not somewhere else on the page. Yeah there are editor tricks to command+click to it and such, but that's still some overhead.

TBH I think it really is a matter of preference at this point. There could be a killer, must-use RubyMotion framework in the future, but for now I simply feel more productive and flexible in Ruby.

In fact, the most impactful change of RubyMotion (and I somehow neglected this when I wrote it) is testing. It ships with a really powerful port of Bacon which is lightyears better than UIAutomation, KIF, and every other iOS testing framework I've tried. `rake spec` is a seamless, regular part of my workflow in a way that Xcode failed to achieve.

> I think the value add of a `when` style isn't saving keystrokes but improving readability. What happens when the event fires is right there in-line with the button, not somewhere else on the page. Yeah there are editor tricks to command+click to it and such, but that's still some overhead.

With Interface Builder, there is no "right there in-line with the button", because the button (and the entire remainder of the layout) is instantiated and fully laid out in a nice WYSIWYG editor.

That said, as the you noted, you can do this in Objective-C. However, due to the propensity for conflicts, it's bad form to insert un-prefixed category methods into system classes.

This is an appeal to emotion, but I must be honest: I'm concerned about the day that I'm asked to take over maintenance of a Ruby Motion project, especially if it's likely to diverge significantly and arbitrarily from our community's existing best practices.

Risky, error-prone and not correct? If you're going to throw out that kind of slander, you ought to back it up or it's just FUD. People used to say the same thing about Cocoa's "black magic" like the responder chain, undo support and Interface Builder. I didn't buy it from them then, and I don't buy this now.

Monkey patching from a library in a namespace shared with the vendor and all other code within your process.

People add categories with un-prefixed function names all the time in Objective C and get in trouble too. It's not unique to Ruby.

" If you've tried projects in Ruby and just didn't like it, RubyMotion probably won't change your mind. But if you've ever wanted to make iOS or Mac apps but didn't want to get over the hump that is Objective-C, maybe this will get you going."

Can RubyMotion itself be used to create Mac apps in addition to iOS apps?

Sorry, should have specified! As jballanc said, I was referring to MacRuby (http://macruby.org/). I'll add a link there for clarification.

RM and MR are both by Laurent Sansonetti, and the experience developing for them is identical. The Ruby code is just as portable as Objective-C between iOS and OS X. I'm working on something right now which uses both technologies and it's been a great experience.

There is, of course, one important different between MacRuby and Ruby Motion: the former is GPL compliant, and the latter is commercially licensed.

I think this is a shame, because I suspect lots of people would quite like to contribute back to the project, and that's currently not an option.

Of course it's a shame that Laurent needs to eat and of course this has everything to do about RM being able to build for Mac or not. Knowing him, I know he would prefer RM to be open source but it would be much harder for him to monetize his efforts.

I'm perfectly ok with paying a fee to get RM but I know that wouldn't pay for support (especially if the community handles it which is already the case).

Corporate sponsorship doesn't always works and often lacks security and stability for both the developer and the project as they are at the mercy of one entity.

He would make more money charging for support or for the tail end (e.g. codesigning).

There is still a lot that you can do to contribute back to the project. Much of the build system and various supporting libraries have been open-sourced. Furthermore, it is the stated goal of RubyMotion that development of higher-level abstraction libraries should be driven by the community.

I suspect that the number of people who would actually be interested in (or, indeed, even capable of) contributing back to the parts of RubyMotion that are closed source is rather small.

Probably true. But as an amateur developer, I'd like to try it out... yet I'm not in a spot where I can just drop $200 to see if I like something or not.

How similar is MacRuby?

Besides the obvious difference of target platforms, the biggest difference you'll run into IMO is that MacRuby is a full Ruby 1.9 implementation on top of Objective-C, whereas RubyMotion is more of a dialect of Ruby. i.e. eval doesn't exist in RubyMotion, you can't require gems at runtime, can't use MiniTest or RSpec, etc.

RubyMotion is descended from MacRuby, which can most definitely be used to create Mac apps (a number are already available in the Mac App store).

I sometimes wish rubymotion and macruby had named parameter with default value, something like

def functions(with, this: syntax="default value") end

but over all, I think rubmyotion rocks and I hope and brings some great Objective-c/Cocoa world into ruby-world and vice-versa.

You can setup your method to accept a hash, and then do something like this...

syntax = options[:syntax] || "default value"

...in the method body. Still, it would be nice to have it built in.

Ruby 2.0 will introduce this:

http://rosettacode.org/wiki/Named_parameters#Ruby.27s_future

I would expect MacRuby and RubyMotion to follow.

If you want a deeper dive into RubyMotion, the creator was just on The Changelog podcast - http://thechangelog.com/post/25928209107/episode-0-8-2-ruby-...

He actually left Apple to launch RubyMotion -- a commercial product, by the way -- after creating MacRuby and developing/maintaining it for several years.

iOS development is not only objective-c and Cocoa Touch. XCode, interface builder, instruments are also big helpers and sometimes there can be memory problems that you can only trace with instrument.

Definitely. I know RubyMotion currently supports XIBs and Storyboards, but yeah there's no integrated solution with Xcode or Instruments right now. I personally like the Rake-based approach, its more lightweight than booting up an IDE, but I would bet that better Xcode support is possible since MacRuby already does it pretty well.

Nitron has [slightly hacky] support for IB: https://github.com/mattgreen/nitron

Check the tutorial for an explanation of how to use it. Disclaimer: I'm the author. :)

That's if you like using interface builder. I personally dislike it and prefer to lay things out programmatically, but this probably has to do with the fact that I came to iOS development from the web development world.

I also try to not use IB most of the time, but especially if you are building not so custom designs, IB really increase the productivity and keep the code clean.

Why the tricky horizontal scrolling on this page? (In Chrome and Firefox, at least. Oddly, Safari presents it as a regular vertical page..)

It's because of a media query that responds to wider window sizes, strange that it didn't register in all your browsers (it does on my Safari when I fullscreen)

It's supposed to help readability while maximizing screen use in those cases (instead of either stretching out paragraphs to two lines or centering the body as to take up only a small percentage of the window). I'll change it to trigger on a wider dimension, sorry!

Aha, that would explain it. I almost never use Safari so its natural size is likely somewhat thinner than my day to day browser :-) I was just over your ~1300ish pixel width.

Are there examples of products that were developed with RubyMotion?

I don't know if theres a big list, but this blog post mentions some http://blog.rubymotion.com/post/24197887535/community-open-s...

This is a pretty mindblowing app example which is on it's way to the app store: http://clip.ignition.hk/

Lots of low-level stuff there, which is very very impressive.

That is a very cool app. Thanks for sharing the link!

> (after the code preview) Pretty nice right?

Yes, very nice. And also very annoying.

Using these little shortcuts everywhere is confusing. There is no order in things.

ObjC is beautiful. There are classes, instances, methods, blocks. And everything has its place.

This is a mess, Rails is a mess, most of Ruby code is a mess.

Proceed with the downvotes.

Proceed with the semicolons.

Reply on news.ycombinator.com