From Rails to RubyMotion: basic toolkit
Have you noticed the tendency that development is moving strongly towards mobile? There are more and more projects with mobile companion, there are a lot of just-mobile software houses, and there are even only-mobile projects. What if a company has only web developers specialized in Ruby, but want to be really full-stack? Doesn’t matter, with Ruby, it can still goes mobile!
What were the beginnings?
Yet some time ago, if Ruby developer wanted to experiment with Android or iOS, he have to dive into Java or Objective-C. That might have been cumbersome if he only want to play with it, because he had to learn a new language. For these more assiduous it worked - they learned it, used it, then went back do daily work and… forgot it. You know how is that - not used is being forgotten.
Let’s meet RubyMotion
Our adventure with RM started recently, so we don’t feel skilled enough to present here some advanced code yet. That will happen, for sure, in the next blog posts, so you won’t miss anything. For now we’d like to focus on our research done so far in that area.
As we are RoR developers, we usually depend on gems. They help us not to reinvent the wheel and speed up our development process. Sometimes they are deceptive, but it’s not the topic of this blogpost so let’s say that there are generally helpful. Before we started RM we made some research how does the 3rd party support looks like. What struck us the most is that RubyMotion has tremendous bunch of libraries, pods and gems to improve our productivity. So let’s talk about them.
- Libraries - have to be shipped with project, are distributed usually as a compressed packages that require to be extracted and included by developers manually.
- Pods - dependencies prepared especially for Objective-C. They were created before RM and are used in many Objective-C projects. Thanks to HipByte, they can be used from Ruby right now.
- Gems - they are rubygems prepared for RM and provide nifty solutions for many common problems in native environments.
I’m not sure if framework is the best word word for describing what I want do present now, but in RM world there are some tools that makes mobile platforms completely separate from their native languages end extremely easy to implement. They are essentially gems but this is analogy to Rails among other Ruby gems. Here’s the list:
Vanilla RubyMotion - this is RubyMotion itself, that allows to write the same methods taken form native platforms in ruby with just a little tweaks. It’s the closest implementation to Java or Objective-C.
ProMotion - it makes verbose Objective-C syntax more ruby-like by hiding native methods behind ruby-convention ones. PM also offers a bunch of ready classes to manipulate views without struggling with sometime complex implementation.
RMQ - this is the jQuery for Objective-C. It makes extremely easy to manipleulate views, traverse between components, animate and style whatever we want and handle events and user gestures.
Gether them all
- SugarCube - even better syntax for RubyMotion
- BubbleWrap - a lot of utilities for managing most common platform elements like persistency, global state, notifications and hardware
- AFMotion - best networking library with beautiful DSL and block callbacks
- MotionSupport - port of the parts of ActiveSupport that make sense for RubyMotion
Styling (with emphasize on SweetKit)
Frameworks (with preference to simpler for the beginning RMQ)
We encourage every ruby developer to try RubyMotion. It’s a great way to go into mobile even if you don’t know (and like) Java or Objective-C. We are impressed the RubyMotion great support, tools and community despite it’s a standard as befits the Ruby world.
For now, stay tuned for more mobile blogposts!