RubyMotion Blog

ShowKit Now Supports RubyMotion

ShowKit is an SDK for mobile devices to enable audio/video conferencing and screen/gesture sharing. Check out the demo video!

We are glad to report that ShowKit’s newest release now supports RubyMotion! Embedding the ShowKit SDK into your RubyMotion app is as easy as vendoring it, you can refer to the documentation for instructions.

MotionBundler: Good Old Fashioned Requirements for RubyMotion

(This is a guest post from Paul Engel, creator and maintainer of MotionBundler)

When I started writing my first RubyMotion application, I almost immediately wanted to use a Ruby gem to accomplish a certain goal. After setting up my Gemfile, running bundle and rake in the Terminal, I soon discovered that it wasn’t possible to just require any random gem I wanted to: it had to be aware of it being required in a RubyMotion app.

Suddenly, my next open source project became a fact. I wanted to create a gem which allowed you to require any Ruby gem in a RubyMotion application. My first attempt was the LockOMotion project. It gets the job done but it wasn’t test-driven enough and the code wasn’t well structured. Enter MotionBundler, a complete rewrite with a 100% test-coverage.

I am a big fan of using and writing libraries and gems that are as unobtrusive as possible. I did not want to force the developer to follow special conventions (e.g. using another method than require to load up code). And MotionBundler does just that.

Setup and Usage

MotionBundler is intended to be easy in installation and usage. You need to setup your Gemfile by separating RubyMotion-aware Ruby gems from the ones that are not. Put the RubyMotion-unaware gems in the :motion Bundler group, as shown here.

source "http://rubygems.org"

# RubyMotion aware gems
gem "motion-bundler"

# RubyMotion unaware gems
group :motion do
  gem "slot_machine"
end

[...]
require "motion/project"

# Require and prepare Bundler
require "bundler"
Bundler.require

Motion::Project::App.setup do |app|
  # Use `rake config' to see complete project settings.
  app.name = "SampleApp"
end

# Track and specify files and their mutual dependencies within the :motion 
# Bundler group
MotionBundler.setup

Finally, you can just run the bundle command then the default rake task to build and run the application. And that’s all about it!

Requiring non-Gem Sources

Just like a regular Ruby project, you are now able to require source files. It can either be a relative path on the file system or a Ruby standard library source file. As an example, let’s require the cgi Ruby standard library file and use the CGI.escape_html method in a RubyMotion controller.

require "cgi"

class AppController < UIViewController
  def viewDidLoad
    puts CGI.escape_html('foo "bar" ')
  end
end

Looks familiar, right?

How Does MotionBundler Work?

MotionBundler traces require, require_relative, load and autoload method calls in your code when invoking MotionBundler.setup. All four methods eventually are delegated to the require method which MotionBundler hooks into. MotionBundler calls MotionBundler::Require::Tracer::Log#register which traces the calling Ruby source and registers the source file being loaded.

When MotionBundler.setup invokes Bundler.require :motion, all required files and their mutual dependencies are registered. Aside from the Ruby gems defined in the :motion Bundler group, MotionBundler also uses Ripper::SexpBuilder to scan for require statements (like motion-require does) in the Ruby sources defined in ./app/**/*.rb so it can trace requirements using MotionBundler::Require::Tracer::Log.

Console Warnings

When I was writing LockOMotion it was very difficult to debug certain errors. I have been able to override certain core methods to print warnings which contain useful debug information.

These are only printed in the iOS simulator console. When running from the device, MotionBundler does not interfere when an error gets raised. As an example, let’s check out a warning printed in the console when dealing with a runtime require statement.

[...]
   Warning Called `require "base64"`
           Add within setup block: app.require "base64"
2013-05-21 13:45:26.851 SampleApp[17300:c07] app_controller.rb:48:in `viewDidLoad': uninitialized constant AppController::Base64 (NameError)
    from app_delegate.rb:5:in `application:didFinishLaunchingWithOptions:'
2013-05-21 13:45:26.855 SampleApp[17300:c07] *** Terminating app due to uncaught exception 'NameError', reason: 'app_controller.rb:48:in `viewDidLoad': uninitialized constant AppController::Base64 (NameError)
    from app_delegate.rb:5:in `application:didFinishLaunchingWithOptions:'
[...]

Here, the base64 file is missing from the build system. You can fix that problem by adding the following code in the Rakefile.

MotionBundler.setup do |app|
  app.require "base64"
end

RubyMotion Runtime Limitations

Unfortunately, you still cannot just require every file that works within a regular Ruby environment. You cannot require C extensions and you cannot evaluate Ruby code passed in a String (e.g. the eval method). This is why MotionBundler cannot ensure that you can require every Ruby gem out there. They have to be RubyMotion friendly, for example like SlotMachine.

But as a last resort, MotionBundler offers you to possibility to mock source requirements by loading drop-in replacements written in pure Ruby.

Mocking Sources

Let’s say you want to use a Ruby gem which requires the stringio extension. Because stringio is a Ruby C extension, and that RubyMotion doesn’t support Ruby C extensions, that Ruby gem will not load up in RubyMotion. However, as mentioned earlier, MotionBundler offers a possibility to bypass this problem by mocking the library.

Instead of requiring the stringio.bundle file, MotionBundler is able to mock it with a pure Ruby implementation of it, taken from MacRuby. At the moment, MotionBundler also mocks strscan, zlib and httparty (only its basic features).

Aside from mocks being defined within the MotionBundler gem, you can also define your own mocks within your RubyMotion application. Just add a directory called mocks within the root directory of the application and put the mock sources in it. The relative path of the mock source within that directory ensures a certain Ruby file being mocked during compile time.

Let’s say the root directory of your RubyMotion application is ~/Sources/sample_app. If you want to mock require "yaml", create a file at ~/Sources/sample_app/mocks/yaml.rb containing the mock code. If you want to mock require "net/http", create a file at ~/Sources/sample_app/mocks/net/http.rb.

You aren’t supposed to mock entire Ruby gems of course, that would be crazy. But you would rather mock fundamental Ruby standard library sources (like stringio.bundle) so you don’t have to dismiss a certain Ruby gem for use in your RubyMotion app on forehand.

Please Try MotionBundler!

MotionBundler is available on Github. The repository provides a sample application. You can clone the repository, navigate to the sample application directory, run bundle followed by rake. Please check out MotionBundler! Pull requests, remarks or requests are very welcome! You can also contact me on Twitter :-)

Finally, I would like to say thanks to Laurent, Nick Quaranto and Dave Lee for giving me some feedback and suggestions.

You can discuss this post on the RubyMotion google group.

Paul Engel is a software developer living in beautiful Amsterdam, Netherlands.

Introducing ProMotion, a Full-Featured RubyMotion Application Framework

(This is a guest post from Jamon Holmgren, creator and maintainer of ProMotion)

Last August I started working on a new RubyMotion app. I quickly realized that one of UIKit’s most frequent pain points is working with UINavigationControllers, UITabBarControllers, and UIViewControllers — it just took too many lines of code to move around in my app. That led to the idea behind ProMotion: abstracting the screen and navigation handling in a Ruby-like way.

It has been a great experience building it and I’m going to show you how ProMotion could make your next iOS project a lot easier (with lots of code examples!). The source is also available on GitHub.

ProMotion subclasses UIViewController and UITableViewController to provide a ton of new functionality and abstraction and calls them ProMotion::Screen. (You can also use ProMotion with Formotion or your own UIViewController).

Note: from now on I’ll refer to ProMotion by its shortcut alias, PM.

class HomeScreen < PM::Screen
  title "Home"
end

Pretty simple. What about viewWillAppear:animated and other Obj-C methods? We implement simpler versions of those for your use:

def on_init
# Fires right after the screen is initialized
end

def on_load
# Fires just before a screen is added to a view for the first time.
end

def will_appear
# Fires every time the screen will appear
end

def on_appear
# Fires just after the screen appears somewhere (after animations are complete)
end

def will_disappear
# Fires just before the screen will disappear
end

def on_disappear
# Fires after the screen is fully hidden
end

When you create a screen you can pass in attributes. One of these is nav_bar: true which creates a UINavigationController and pushes the screen onto it. You don’t have to manage the navigation controller at all.

open HomeScreen.new(nav_bar: true)

Within that screen you can open other screens and they’ll be pushed onto the UINavigationController automatically.

open SecondaryScreen

If you pass in a class instead of an instance, ProMotion will instantiate it for you.

Opening and managing a UITabBarController is a pain in Objective-C. ProMotion makes it very simple and natural.

class AppDelegate < PM::Delegate
  def on_load(app, options)
    open_tab_bar HomeScreen, AboutScreen, ContactScreen, HelpScreen
  end
end

# in app/screens/home_screen.rb

class HomeScreen < PM::Screen
  def open_another_tab
    # Switches to the AboutScreen created above if its tab title is “About”.
    open_tab “About”
  end

  def open_new_screen_in_another_tab
    # Programmatically switches to the HelpScreen
    # and pushes the SecondaryScreen onto its UINavigationController.
    open SecondaryScreen, in_tab: “Help”
  end
end

Split view controllers are as easy as tab bars.

open_split_screen MenuScreen, DetailScreen

From the left-hand part of the split screen it’s easy to open a child screen in the right. Just add in_detail: true to the open command:

open SomeDetailScreen, in_detail: true

This is ignored if there isn’t a split screen so it’s ideal for use in universal apps.

You can easily build list views (“tables”) in ProMotion. Formotion is excellent for building forms, but sometimes you just want a menu or list of information. That’s where ProMotion’s built-in TableScreen works well.

class HelpScreen < PM::GroupedTableScreen
  title "Help"

  def table_data
    @help_table_data ||= [{
      title: "Get Help",
      cells: [{
        title: "Email us", action: :email_us
      }]
    }]
  end

  def email_us
    mailto_link = NSURL.URLWithString("mailto:jamon@clearsightstudio.com")
    UIApplication.sharedApplication.openURL(mailto_link)
  end
end

When the Email us cell is tapped, ProMotion fires the email_us method.

For plain tables, you can add searchable and refreshable easily:

class StatesScreen < PM::TableScreen
  title “States”
  searchable
  refreshable

  def table_data
    # list of states
  end

  def on_refresh
    # refresh your data here, usually async
    some_async_call do
      # update your data
      stop_refreshing
      update_table_data
    end
  end
end

Everybody has their favorite iOS styling system and ProMotion works beautifully with all of them. Pixate, NUI, and of course RubyMotion’s Teacup are all very good choices.

For those who want a simple, Teacup-lite styling system, ProMotion comes with one built-in.

set_attributes self.view,
  background_color: UIColor.grayColor

add UILabel.alloc.initWithFrame([[10, 10], [300, 45]]),
  text: “Welcome to ProMotion!”,
  resize: [ :left, :right, :top ],
  background_color: UIColor.clearColor,
  text_color: UIColor.whiteColor,
  shadow_color: UIColor.blackColor,
  number_of_lines: 0,
  text_alignment: UITextAlignmentCenter,
  font: UIFont.boldSystemFontOfSize(18.0)

This UILabel is added to the view and all the attributes are set. Snake case is converted to camel case automatically when appropriate. There are also some nice helpers like the resize setting for UIViewAutoresizingMasks.

ProMotion is already being used in production apps around the world and is becoming quite stable. It’s likely that version 1.0 will be coming soon without major changes to the API.

Without RubyMotion, it’s very unlikely that a system like ProMotion would exist. There’s nothing like it in the Objective-C world and the community is a lot different there. It’s a testament to the RubyMotion community as well as Laurent and his team for making this possible.

This is just an intro to ProMotion — head over to the GitHub repo to learn more. I hope you take a look at it for your next project!

Jamon Holmgren (@jamonholmgren) is the owner of ClearSight Studio, a mobile app and web development studio located near Portland, OR.

RubyMotion Goes 2.0 And Gets OS X Support, Templates and Plugins

It has been exactly a year since we launched RubyMotion. Yep, this is right, RubyMotion is one year old!

We released over the year a total of 35 software updates fixing countless bugs reported by our beloved users. That’s almost 3 updates per month on average!

We shipped significant features such as creating static libraries, debugging support (on both simulator and device), API reference documentation browser, automatic file dependencies, and more. We also shipped support for iOS 6.0 and the new iPhone 5 architecture right after their announcements.

We did not expect the RubyMotion community to grow that fast. In just one year, we got exhaustive wrappers, professional screencasts, a couple books, and we even organized our very own conference!

We now believe it is time to focus on the second phase of our roadmap, which will essentially consist of introducing new innovative features on top of our toolchain as well as targeting other platforms.

Today, we are shipping our first 2.x release. We still have quite a bit of road to clear up our roadmap but we believe we are on the right path.

OS X Support

RubyMotion is now supporting Mac application development. You can create OS X apps using the same toolchain you already know. We ported our static compiler, command-line interface and interactive shell (REPL) for OS X application development!

RubyMotion OS X apps are statically compiled to Intel 32-bit and 64-bit architectures, include our custom ARC-inspired memory management system, weight less than two megabytes and do not require any 3rd-party dependency to run.

The build system also supports OS X v10.7 and v10.8 as deployment targets and includes an archive Rake task for distribution. 3rd-party projects can be vendored using the updated motion-cocoapods gem.

The documentation in our developer center has been updated for OS X. We have also been adding a few OS X samples to our sample code repository, check them out! We will be adding more samples soon, feel free to contribute some too.

Finally, we are also happy to report that popular RubyMotion libraries such as Bubblewrap, Teacup and Joybox have been ported to OS X. We hope that other libraries will also be gradually ported to this new platform.

As you may know, RubyMotion is an improved version of MacRuby, an implementation of Ruby for the Mac that we started in 2006 at Apple.

A lot of MacRuby enthusiasts supported us when we launched RubyMotion a year ago, and RubyMotion OS X support has been a consistent feature request over the year, since day 1.

Today, OS X support ships to all RubyMotion customers, for free. This is our birthday gift to you guys, thanks for your support!

Project Templates

RubyMotion now exposes functionality to let users chose a template when creating a new project, by passing a value to the —template argument of the motion create command.

RubyMotion comes with 3 builtin templates: ios (the default one), osx and gem, which will respectively create a RubyMotion iOS, OS X or RubyGem project.

For example, to create a new OS X project named Hello:

$ motion create --template=osx Hello
    Create Hello
    Create Hello/app/app_delegate.rb
    Create Hello/app/menu.rb
    Create Hello/Rakefile
    Create Hello/resources/Credits.rtf
    Create Hello/spec/main_spec.rb

 3rd-party templates can also be installed into the ~/Library/RubyMotion/template directory.

We expect certain RubyMotion gems to make use of the system to provide richer project templates that include specific integration code. As an example, the Joybox team is looking into making a template that includes a game skeletton.

Command-Line Plugins

Similarly to the template system, RubyMotion now exposes a way to add new commands to the motion command-line tool, using plugins.

Builtin commands, such as create, update, support and ri, have been extracted as plugins. 3rd-party commands can also be installed into the ~/Library/RubyMotion/command directory.

RubyMotion gems can now extend the motion command with their own actions, for example custom code generators.

Common Build Directory

The build system has been improved to use a common build directory when compiling external project files (ex. gems). 

This makes build times faster as gems will not be recompiled every time the project configuration changes, or when multiple RubyMotion projects are using the same gem.

Weak References

RubyMotion now exposes a way to let users create weak references. For convenience reasons, we implemented the WeakRef class which is also present in the standard Ruby library. 

Weak references can be used in order to prevent cyclic references. A good example is implementing the delegate pattern.

class MyController
  def initialize(delegate)
    @delegate = WeakRef.new(delegate)
  end

  def do_something
    # ...
    @delegate.did_something
  end
end

Objects passed to WeakRef.new will not be retained, and any message sent to a WeakRef object will be forwarded to the passed object.

For performance reasons, WeakRef objects are recognized early by the method dispatcher. The WeakRef class in RubyMotion cannot be subclassed.

We expect the RubyMotion memory management system to be able to deal with cyclic references in the future. In this case, the WeakRef class will be replaced by a no-op.

RubyMotion #inspect 2013 Wrap-Up

Just a few weeks ago the first RubyMotion conference was happening in our home town of Brussels, Belgium! And guess what, it was pretty awesome!

It was the first conference we ever organized. We would like to share our experience in this post as well as cover what happened!

The Venue

We wanted the first conference to be friendly, diverse and exclusive. We initially fixed the maximum number of attendees to 100 because we knew that over this limit it would have been difficult for everyone to meet up and chat. We eventually raised the limit to 130. Despite the fact that the majority of RubyMotion users are located in the United States, we also knew that we wanted the conference to happen in Belgium, for practical reasons.

It took us quite a bit of time to find the conference venue. We visited a few venues but they didn’t really match what we had in mind. We wanted the venue to be special, unusual, and at the same time professional and prestigious. We also wanted the venue to be in the historical center of Brussels, because the area is full of hotels, restaurants, bars, and tourist attractions. Organizing the conference in a hotel near the airport was therefore out of the question.  

The Grand Place is Brussels’ main square and also the center of its historical center. We started looking around for potential venues and we eventually figured out it was possible to rent a house on the Grand Place itself! We quickly jumped on the opportunity.

We got 130 visitors from every continent. A lot of different accents were heard, making the event very diverse. Most of the attendees were visiting Belgium for the first time, so they got to taste our awesome beers and chocolates!

The Schedule

The conference featured a single track over 2 days. We pre-selected 10 speakers for the announcement and opened a call-for-papers. We originally wanted 18 presentations.

Pre-selecting as many speakers was probably a mistake because we received close to 80 talk proposals. We didn’t expect to receive as many talk proposals and it was very tough to decide on the remaining selection. We had to reject a lot of very interesting talks.

We eventually decided to go with 20 presentations, which means we had to fit 10 talks each day, and still leave enough room for breaks and lunch. We took over the challenge and eventually managed to finish the conference on time!

We decided not to print the schedule on paper and preferred to have an iOS app instead. We teamed with the awesome folks at Epic, who already made the conference website, to create an iPhone app for the conference. The app was obviously written in RubyMotion, using the Teacup and Sugarcube libraries. You can find the full source code on GitHub.

The Food

Offering delicious food was extremely important to us. We did not want to give away dry sandwiches that you can find in most conferences.

We welcomed visitors with fresh pastries (cooked onsite), coffee, tea and juices. Each attendee also received chocolates from Benoit Nihant’s Haute Couture selection. Benoit is one of the remaining true chocolatiers of Belgium.

For lunch, our attendees had access to a full Belgian buffet which included cured meats, steak tartare, duck, various salads, fresh vegetables, salted waffles and more. A huge assortiment of homemade deserts was also available, including chocolate mousse, fruit tarts, tiramisu, and more. And we of course served beer!

Most attendees told us they had the best conference food experience ever.

The Shirt

We designed the conference shirts by ourselves. We didn’t want to go with a traditional “conference name + date” shirt, so we iterated quite a bit on the design.

We finally ended up choosing to represent a coat of arms. The logo we went with features two wyverns (an homage to the LLVM project) supporting the existing RubyMotion logo on a white shield, crowned with a sparkling ruby.

The motto is written on a white ruban and reads “#inspect RubyMotion 2013”.

The Presentations, 1st Day

A Brave New World: Learning iOS for the Ruby Refugee, by Nick Quaranto (slides available). Nick covered his experience using RubyMotion to write a couple sample projects (which eventually turned into the official Basecamp iPhone app) and talked about the motion-settings-bundle and motion-autolayout gems he extracted in the process. We later recorded an interview with Nick that you can also check out. 

Behaviour Driven Motion using Calabash, by Karl Krukow (slides available). Karl introduced the Calabash framework and how you can write acceptance tests for RubyMotion apps with it, using the motion-calabash gem. (Note: A few days later it was announced that LessPainful, Karl’s company, was acquired by Xamarin.)

Controlling the Real World with RubyMotion, by Rich Kilmer (slides available). Rich talked about the history of bluetooth, starting from the first specification up to the bluetooth4 standard, and described the APIs that you can use to interface from RubyMotion. And before you ask, yes, Rich was wearing white pants.

Elevate your Intent, by Matt Green (slides available). Matt talked about the complexity that can rise when designing iOS apps and offered a solution through his elevate gem that we recommend checking out.

Accessibility and RubyMotion, by Austin Seraphin (slides available). Austin, a blind developer, talked about accessibility and how RubyMotion makes it easier for blind people to develop apps. Undoubtedly one of the most acclaimed talks of the conference. Austin also covered his trip to the conference in 3 blog posts that we highly recommend: An Unexpected Journey, #inspect 2013, and The Journey Home.

CoreData For The Curious Rubyist, by Jonathan Penn (slides available). Jonathan introduced CoreData, Apple’s framework for data persistence. He covered what CoreData is, when to use it, and the builtin framework classes you will have to deal with when integrating it in your app. Demo code available.

The Life and Times of an Object, by Joshua Ballanco. Josh started with a simple app that was crashing and investigated the crash using low-level tools such as gdb and malloc-history. Eventually, it turned out that the bug was in the RubyMotion runtime!

Concurrency in RubyMotion: Use the Multicore Luke!, by Mateus Armando (slides available). Mateus talked about how it is necessary to use concurrency and the various approaches to it, such as GCD and NSOperationQueue.

Get More From RubyMotion with RubyMine, by Dennis Ushakov. Dennis didn’t have any slides, he simply started developing a RubyMotion app straight within RubyMine and demo’ed the excellent RubyMotion integration we (HipByte and JetBrains) have been working on together, featuring smart auto-completion, debugging on simulator and device, refactoring, documentation viewer, and more.

Crafting iOS Dev Tools in Redcar, by Delisa Mason (slides available). Delisa talked about Redcar, an open-source editor written in Ruby, and introduced its very extensible plugin infrastructure. She eventually showed how she managed to integrate RubyMotion in Redcar.

The Presentations, 2nd Day

NSRevolution: How Ruby hackers built the new Objective-C Open Source community, by Mattt Thompson (slides available). Mattt talked about the influence of the Ruby community on the younger iOS community. 

More Than You Need to Know About CocoaPods, by Eloy Duran (slides available + video 1 and video 2). Our hero Eloy talked about CocoaPods, the missing package manager for Objective-C libraries, and also featured a sneak-peak at their sister project, CocoaDocs.

Wrapping iOS in RubyMotion, by Clay Allsopp (slides available). Clay covered various techniques you can use to create elegant and nice Ruby wrappers on top of iOS API patterns, such as callbacks, delegates and enumerations.

Goodbye IB, Hello Teacup, by Colin Gray (slides available + video). Colin started talking about Teacup, a library to style user interfaces, and eventually announced motion-xray, a powerful iOS inspector running inside RubyMotion apps that can be opened using a device gesture.

Using BubbleWrap to Quickly Build RubyMotion Apps, by Marin Usalj (slides available). Marin gave a nice overview of the Bubblewrap project, which aims at becoming the ActiveSupport of RubyMotion.

Mixing CoffeeScript in RubyMotion apps, by Michael Erasmus (slides available). Michael talked about his experience building a cross-platform mobile app where CoffeeScript was used to build the common logic.

Building Interactive Data Visualization Charts, by Amit Kumar (slides available). Amit talked about the various libraries one can use to integrate interactive charts in an iOS app, and eventually announced the motion-plot gem, a nice RubyMotion wrapper sitting on top of the CorePlot framework.

Cocos2D, an Easier Way, by Juan Karam (slides available). Juan talked about his gaming experience, basic game programming concepts, and eventually announced Joybox, a RubyMotion gaming library integrating the popular Cocos2D and Box2D frameworks. He even wrote a simple game during his talk!

Let’s Move with CoreMotion, by Akshat Paul and Abhishek Nalwaya (slides available). The inseparable friends gave a speedy talk about CoreMotion, Apple’s framework for motion sensors integration. They talked about the core builtin classes and how you can use them from RubyMotion.

RubyMotion: Past, Present and Future, by Laurent Sansonetti. Laurent gave the final conference presentation. He talked about what made him create RubyMotion, the current state of the project, and what the future holds.

The Party

We concluded this wonderful conference with an awesome party! 

Our friends at GitHub graciously sponsored the party. We booked the entire Hoppy Loft room of the Delirium Cafe, one of Brussels’ legendary pubs, which features thousands of different beers.

Conference attendees were able to taste quite a lot of delicious Belgian beers. We ended the party at around 4AM!

The Sponsors

RubyMotion #inspect 2013 would not have been possible without the support of our great sponsors.

Our lead gold sponsor. Heroku is the first and best multi-language cloud application platform, or platform-as-a-service. Heroku allows developers to deploy, scale, and manage their apps without needing to think about servers or systems administration. Over one million applications have been deployed to Heroku.

One of our silver sponsors. JetBrains is a world leader in smart development tools that help software developers simplify their challenging tasks and automate the routine ones. RubyMine, the most powerful Ruby IDE, provides smart coding assistance and advanced testing and debugging features for all types of Ruby projects and cutting-edge technologies, including RubyMotion.

One of our silver sponsors. Here at Cyrus, our team of forward-thinking developers are continuously expanding their skillsets to incorporate the latest tools in software development. With RubyMotion, Cyrus is once again at the forefront of innovation helping our clients cut down both development time and costs.

One of our silver sponsors. Nedap is a manufacturer of intelligent technological solutions for relevant themes. Sufficient food for a growing population, clean drinking water throughout the world, smart networks for sustainable energy are just a couple of examples of themes Nedap is working on.

One of our silver sponsors. Boxcar is a push notification service. Boxcar provides real time push notifications for the services you love.

One of our bronze sponsors. At The Pragmatic Studio, we help programmers continually improve their skills and their careers through hands-on training courses.

One of our bronze sponsors. Founded in 2008, Belighted is a leader in the use of Ruby on Rails technologies and agile methodologies. 

Summary

Organizing a conference is hard. But we believe we did a pretty good job on this one! Nothing catastrophic happened, people enjoyed the event, the Wi-Fi didn’t work, and budget-wise we should break-even. 

RubyMotion #inspect 2013 would not have been possible without our helpers team: Stephanie Sansonetti, Stephane Wirtel, Yannick Schutz, Franck Verrot and Marc Lainez.

We published the official photos of the conference, check them out! Also, all presentations have been recorded, we will let you know once they are available.

Finally, we would like to announce that there will be a RubyMotion #inspect 2014 conference. We can already tell you it will happen on the other side of the Atlantic ocean and that it will be even more epic.

Stay thirsty, my friends!

Algolia Search Adds RubyMotion Support

Algolia Search is a product that lets you implement real-time instant search in your app, with features like type-ahead search, typo-tolerance, instant visual feedback and geosearch.

We are glad to report that they just announced that they will support RubyMotion!

We worked together with the folks at Algolia on a RubyMotion integration gem that lets you easily integrate their offline SDK.

The Algolia folks also graciously agreed to donate 5 White Label licenses (custom branding) to the firsts to email hey@algolia.com. Hurry up!

Announcing MotionMeetup: Monthly Online RubyMotion Meetups!

(This is a guest post from Gant Laborde)

While RubyMotion continues to build momentum, it’s obvious that not everyone can attend such endeavors as RubyMotion #inspect or the public RubyMotion training in the San Francisco Bay Area. Fear not! From the community of RubyMotion developers we’re happy to announce a new monthly online meetup for everyone, worldwide, called MotionMeetup.

This online meetup will spotlight a developer from the RubyMotion community or general RubyMotion ecosystem to interview and interact with the community.

Meetups will, as of now, occur once a month and consist of at least 30 minutes of live discussion via video conference. The discussions will cover a wide array of topics generally consisting of each spotlighted guest’s projects all the way to their opinions and philosophies.

You’ll also be able to ask your own questions in the #rubymotion IRC channel on freenode and interact with featured guests and fellow developers while the video conference is going on.

If you would like to be notified on updates please fill out the sign up form at MotionMeetup. If you’re interested in being a featured guest for a future meetup or would like to see a topic addressed, please contact the coordinators of MotionMeetup, the good people at Iconoclast Labs.

RubyMotion Success Story: Basecamp for iPhone

37signals released last month an official iPhone app for Basecamp, their flagship project management software. It is the first iOS app developed completely in-house at 37signals.

As you may have already heard, the Basecamp app is written in RubyMotion. Since Nick Quaranto was speaking at our conference last week, we decided to take advantage of the opportunity to record a quick interview with him about the experience. Check out the video and the transcript below! 

You just announced the motion-layout gem tonight, has it been a long time coming?

(Laughs). Kind of. When we wrote the Basecamp app at 37signals we didn’t really use Interface Builder at all.

There is a new API in iOS6+ that provides auto layout for views, and specifically there is an ASCII-art style format string. It’s really weird that Apple let programmers design ASCII-art languages. So, the gem wraps that kind of verbose API that Apple provides.

So I guess it’s kind of been a long time coming, it has been 2-3 months in the making, it’s really not complicated, it’s just a little gem.

Speaking of the Basecamp app, when did that get started? When did you put that into your bosses’ ears?

That’s kind of an evolution. I started using RubyMotion in June, and RubyMotion came out in May. I basically got that month – I was very lucky to get a whole month to just work on iOS.

I hadn’t done any iOS work before, I had only done Ruby and Rails, and before that, I had a Microsoft background. (Laughs)

You don’t have to admit that here (Laughs)

I feel bad now. (Laughs)

Anyway, the first app we worked on was kind of a prototype. It was to learn how iOS apps worked. That got rejected, we ended up not going forward with that.

How was that initial learning experience?

Good! I feel like I really got a lot from that whole month. I learned how to make an app, how to ship it on TestFlight, I learned gestures and how hard it is to write an app, images and all sorts of other stuff. The different layouts, and how things are supposed to work.

We didn’t go forward with that very specific idea, because we were kind of prototyping the idea, but we kind of merged together two ideas that were coming forward. I had an idea: in that little prototype app we used HTML inside a small part of the app, and it felt very native, and at the same time we were working on web views for Basecamp, so that if you were on Safari on iOS, or Android, or any other browser you could see your stuff in Basecamp, so we kind of decided that, wow this is really native, it felt very native on the phone even if it was HTML.

We had all these views, and we kind of combined these two into an app. It wasn’t Basecamp at the start, we actually started just by solving specific problems, for example just to get an update on your phone when something was happening on your projects.

The app was focused on that at first, then we realized it kind of stinks that this is all you have, and we wanted to jump between things in your projects, and see all your TODOs, or all your files, so it kind of evolved from there and eventually it became the Basecamp app. We didn’t start by saying “we are going to make a Basecamp app”, it was more started like we have these problems when we’re on the run with Basecamp, and we want to fix those.

What did your RubyMotion toolbox and workflow look like?

Pretty normal, we do use a mix of Cocoapods and gems, we use some URL caching, there is just a few others… date formatter stuff that we use as well.

On the Ruby side we use Bubblewrap which is a great resource for anyone that’s starting with RubyMotion, just for iOS development in general, it saves a ton of time.

There are a few gems that I extracted along the path like motion-layout, I also have another one to make settings-bundles, called motion-settings-bundle. So it’s kind of a mix of both, and I think that it’s very healthy that we can get all of these great libraries from the Objective-C world and use new Ruby stuff as well.

You are a very seasoned Rails and Ruby developer, what were the challenges working with RubyMotion? And Laurent won’t hear this. (Laughs)

(Laughs). I didn’t have any big problems with RubyMotion, the challenges were mostly iOS, and I think that’s… you can’t get around it, you have to learn the Apple APIs, you have to deal with that, you have to understand the patterns that are in Objective-C in Ruby, and that was a big source of conflict for me, because there is a conflict between the style we see in Ruby and the style in Objective-C, and they kind of butt heads all the time.

So I think that that was the hardest part for me, understanding and internalizing the patterns that are in Objective-C and all over Cocoa and libraries, such as delegates, the list goes on an on, like constants and enums, the list doesn’t end, you have to know all these things, you have to be fluent in both to be useful, but I did it (Laughs).

So I think it’s definitely possible to come from basically zero iOS knowledge and do an app with RubyMotion.

Is there anything that you learned along the way – I am sure there are some things! – so when you start you next app, what are the things you learned that will make you start quicker?

I am going to start testing more (Laughs). I need to admit that I didn’t do any good job at all and we are definitely going to fix that, because the Basecamp app is something that we care about and we need it to last for years. So that’s a big thing I wished I looked into sooner.

Another thing… I always learn this lesson again and again: test on the device sooner! Obviously if you are making a mobile app you should be, but it’s very easy to be tricked thinking that the simulator is the real thing, when it’s not. There are performance problems that you see on the device that aren’t in the simulator, and I feel like I got reminded of this on a weekly basis.

Was there anything from the conference that just finished that you were excited about? You mentioned testing…

Yeah there were lots of great testing talks, a lot of crazy things came out, people really showed stuff I was impressed by.

One of the later talks was about Cocos2d, which is a game wrapper called Joybox, and it’s really neat, the guy basically made an Angry Birds clone in like 10 minutes in front of us, it was kind of crazy!

There was a testing talk about Calabash, which is really neat. Despite using Cucumber (and I have written a lot of Cucumber code), so I understand how difficult it is and how people’s opinions vary on it, but the coolest thing was that internally you had this nice API to do testing. You could drag things, you could look inside of web views, which is a big deal for us, you can do all sorts of stuff, and it’s backed by cucumber but beneath it is this cool Ruby thing that I need to look into!

I was really impressed by the quality level of talks and the stuff people showed off.

If you were starting your next app, how would you convince your boss to use RubyMotion?

Well, that’s really a good question. (Laughs)

Luckily I didn’t have to do too much convincing. Showing them how much easier it is is always a good thing, like the before and after, here is how it is in Objective-C, and here is the much-improved-less-verbose version in Ruby.

Another thing, that I think is the biggest win, especially for people that are coming from Ruby and Rails background, that if you’ve already got a team of people who know Ruby on Rails, the jump is a lot smaller to this new brave world, right, because you can leverage all of the toolchain that they know, they can use whatever they have been using in Rails, it’s the same language, there are maybe a very little differences but it’s still Ruby, you get all of the awesomeness that is Ruby, but you can’t get around learning the iOS APIs.

So I guess that if you are coming from a Ruby and Rails side, that’s it. If you’re coming from an iOS team I guess it’s probably a bit of a harder sell. Since personally I don’t have experience with that it’s harder to speak on, but I hope that if you are an iOS developer looking at RubyMotion you get a solid look at the code, like the comparison, how much easier it would be, and especially all the new things that are coming along that help you make a RubyMotion app, and that you can’t really use in Objective-C. So I hope that you give that a look if you’re trying to convince your boss.

Are there any tools, any tricks that you would like to see come down the pipeline?

It would be really nice if every-gem-ever worked, that’s very unrealistic, but I like Ruby gems a lot, so it would be very cool, it’s also a hard problem and it’s definitely been an MVP-style thing for the RubyMotion team. Just the fact that already we can make these really awesome things without having the bulk of Ruby gems available is a really good sign.

Besides that, Laurent mentioned code reloading in the roadmap, if that worked that would be a huge win. I went through a lot of links with one of the first prototype apps I made, to completely reproduce my web workflow, to the point where I remapped shake device in the simulator to Command+R, to get a reload, so if there is a better workflow for that, where you can basically say, here is what you’re used to, and here is the awesome new way of doing this, that supports the same thing, because I run rake and reload my app countless times, I should’ve kept a count, that would make a huge difference, that would make me a lot faster. Because you don’t have to wait! It’s just there. That would be huge.

Thank you Nick!

RubyMotion Success Story: Inktera

Page Foundry created Inktera as a platform for authors, publishers and booksellers to take control of their online presence. More than just an ebook store, Inktera links the website, blogs, Facebook and Twitter profiles, and more - allowing you to build native Apple iOS and Android apps in just a few minutes!

We sat down with Dan McFarland to talk about Inktera and their experience using RubyMotion. 

What is Page Foundry’s goal?

Page Foundry was founded with a very simple vision: Deliver the most robust digital content platform available. Page Foundry has been able to empower global organizations like ASUS, local businesses (authors, publishers and local booksellers) and others to connect with their customers in really meaningful ways.

How does the Inktera platform accomplish this?

The vision for the Inktera platform was very simple: help businesses acquire customers by offering a suite of branded digital content services that extend our customer’s brands, services and core values. The platform has evolved into a very robust offering that includes the ability to quickly and easily launch ebookstore apps. By quickly and easily we’re talking days - possibly even hours in some cases - not weeks or months.

What unique features does Inktera provide?

The app is completely unique in that it offers in-app purchasing for ebooks. No apps, other than Apple’s own iBooks app, offer this feature. The Inktera iOS app connects directly to the Inktera cloud which manages the reader’s library, stores their bookmarks, notes, and personalization features.

The framework for the Inktera iOS app is completely customizable by Page Foundry customers via the Inktera platform. They can add social media features, select which types of books to offer, set featured items, etc.

How do you apply the different interface customizations on the device?

The only real difference we consider is iPad vs iPhone with the use of UISplitViewController in the former. BubbleWrap’s Device.ipad? is the only convenience method we use for the detection. All layouts are done programmatically without NIBs.

We made use of LayoutManagers-Fork to get over an initial learning curve and because we were familiar with Android’s LinearLayouts. After understanding iOS’s views more, we used it because it was a similar way to lay interface objects out without trying (or having) to use DSL’s for them.

What RubyMotion tools did you take advantage of? (gems? editors?)

We have been using RubyMine since version 4.0. The latest 5.0 version finally added code completion of iOS core methods/selectors/constants which saves us one trip to Xcode’s Docs. We made a decision to not over do gem usage to avoid using something we couldn’t understand/appreciate. Our gem list is:

gem 'cocoapods'
gem 'motion-cocoapods'
gem 'bubble-wrap'
gem 'motion-testflight'

SugarCube and TeaCup look very interesting and we’ll probably incorporate them now that we have our first app under our belts.

How did RubyMotion speed up your development?

After checking our SCM, our project went from first RubyMotion check-in to Ready for Sale in 10 man weeks. Considering we had no prior iOS, C, Objective-C experience, we project this would not have been possible without RubyMotion or a significant amount more in human resource / development investment dollars.

RubyMotion was not easier than Android mainly due to our prior experience with Java. Android ADT makes creating flexible layouts very intuitive and storing the layouts in XML makes understanding structures easier. That said, the RubyMotion and iOS networking libraries with caching blow Android out of the water. RubyMotion also makes doing network on the main thread almost impossible so keeping the application responsive was a non-issue. RubyMotion certainly makes iOS development easier if the developers have Ruby experience. For Java developers Android is hard to beat. $199.99 to avoid writing method calls like arrays is priceless.

How does the iOS app integrate with the rest of the Inktera platform?

The iOS app integrates through a private Restful API. All networking between the two uses ASIHTTPRequest.

What was the biggest challenge during development?

There’s a tie for the biggest challenge. The first challenge was the integration of Adobe’s RMSDK. The RMSDK project is composed of a dozen other projects and has a very specific build process. The first weeks were spent getting RubyMotion to be able to call into all of RMSDK. This is not a trivial task. The second challenge was memory management. The team was constantly stumbling on situations where retain cycles were getting created by trivial and routine code. Saving things in instance vars helped, but then we had to remember to unset them.

What is it like using RubyMotion on an application so complex?

Overall, we could not have built what we built without RubyMotion given our time constraints and desired investment. We are a Ruby shop so being able to stay in that mind set and leverage existing skills was critical to expediting the process. RubyMotion doesn’t magically remove crash logs or the need to understand iOS concepts, but having readable code that we could write from REPL console helped the project grow with confidence.

Announcing a RubyMotion Training in San Francisco

We are excited to announce that we will be giving a public RubyMotion training in the San Francisco Bay Area the 8-12 July of this year.

This is a 5-day class that will teach you everything you need to know about iOS and RubyMotion, from the very basic concepts to advanced topics. Experience with iOS is absolutely not required.

At the end of the training you should be able to start writing full-fledged apps for iPhone or iPad in Ruby.

This is a hands-on training. You will get to write a few iOS applications during the course. You will also be given printed material and access to a dedicated forum where you can discuss with the instructors and other students.

The full program can be read from our training page.

You can purchase a seat for the training today. If you have any question or need any help don’t hesitate to contact us. See you in San Francisco!