RubyMotion 3.0 Sneak Peek: Android Support
blog.rubymotion.com
blog.rubymotion.com
You'd think enterprise would be a prime use case here. Sucks to have to keep your own fork up to date.
Moral of the story, if you have a Github repo please accept pulls; and if you don't you loose customers.
Is the alternative PhoneGap, and the hypothesis that they're more responsible with taking ownership of your pet features? Just curious.
It's just such a stupid thing with their rake command, it checks to see if your device is provisioned to save you an unsavory error message. Since I have an Apple Enterprise account I am not subject to the 100 device limit and having to provision the device's UDID; so they're checking a non-existent array in the provisioning profile.
Less a pet feature, more an edge case with "rake device" that they missed. It's like they're completely oblivious to an entire class of provisioning profiles in their tooling.
Which doesn't speak well to the maturity of the tool, have they seriously never dealt with an enterprise customer or for that matter an app that had more than 100 devices beta testing it? Almost every iOS development firm I know uses the enterprise provisioning profiles since it's a more simple process than having to juggle UDIDs.
It's one thing that my pull hasn't been accepted, the other bigger concern is the nature of the unpatched code that says to me that no one serious has used Ruby Motion. We aren't talking a hobbyist open-source project here, this is a partially open-source commercial offering.
Source: I am a Ruby developer who has to develop native on occasion... and I run a company who's job it is to deploy beta/in-house applications to mobile devices. I just ran a quick sql query and 43.7% of the hundreds of thousands of applications we host are deployed with enterprise provisioning. I wouldn't call this a personal edge case.
Source: Work for government, not entirely sane, have had Apple reps brought in to discuss in house dev, written in house application, ruby, C#, C, Obj-C, JS, C++ developer in order of preference.
unless App.config.provisions_all_devices? || App.config.provisioned_devices.include?(device_id)
App.fail "Device ID `#{device_id}' not provisioned in profile `#{App.config.provisioning_profile}'"
end
Almost every dev shop that is more than two guys I know uses this.
There must be a better way to keep the lawyers on their leashes?
Not pull requests, because not Git, but they do take contributions on some stuff.
That being said, it does depend on the area (some are totally in AOSP, some move fast internally and only get AOSP drops occasionally), and bug fixes are a far easier than features to get merged.
But then later it says "The runtime uses the Java Native Interface (JNI) in order to integrate with Java".
And then later it says, "RubyMotion Android apps are fully compiled into optimized machine code, exactly like their iOS and OS X counterparts."
Does any of this make any sense? They seem to be contradicting themselves left and right on the same page.
In a traditional JVM implementation, a class-file will compile down to bytecode, and the bytecode interpreter turns the relevant ops into calls to the runtime routines.
JNI provides another way to call the runtime routines (using C++ calling conventions), and for the runtime to call back into your code.
So, for example, if you have a method that adds two numbers together defined on the Foo class, then you want to instantiate that class and call that method from your app, you would compile the "add two numbers" method down to machine code. You'd pass the location of the compiled method to the runtime, registering it with the Foo class, using JNI. Then you'd compile your app code (that will instantiate the class and call the method) to machine code with instructions to set up the stack and jump to the JNI routines to instantiate the class and finally call the method.
Make sense?
This most likely makes the same assumption that you are using a similar kind of project management as in RubyMotion for iOS and using RM specific libraries.
And when they start off with "Ruby classes are Java classes", then later say "everything is compiled to native" that seems like more double-speak.
That is huge, very excited to check this out!
I would love being able to write ruby instead of java (whereas objc doesn't bother me that much).
You can do that with InfraRuby (http://infraruby.com/) if you don't mind writing type annotations.
InfraRuby compiles Ruby with type annotations to ordinary Java classfiles.
I've only just started playing with Rubymotion and it does seem very nice. I'm excited its going to support Android too but Ruboto is another piece of technology that also looks exciting.
Somebody that doesn't want to spend $200 on a product with a complete-satisfaction guarantee probably won't be a very good long-term customer. The RubyMotion guys are filtering out the low-end of the market, which from a business perspective, is a good move.
Besides, every crappy product advertised on TV ever offers a "money back guarantee", and some cursory googling should show that those often aren't worth the electrons used to transmit the image to the screen.
This is the internet age, and we're talking about software. You get paid after I see what you're selling, and not before. Code samples and writeups are nice, but it's no substitute for getting one's hands on the tool.
I'd also like to call out the rather annoying trend of any criticism of pricing being met with the "keeping out the low end market" dismissal. Sometimes, your product is just overpriced and your sales methods leave a lot to be desired.
Many developers have no problem whatsoever spending $200 on a tool like rubymotion, in fact I think it's a bargain. A money back guarantee is a bonus, and no-one has any reasonable doubt as to its legitimacy. I agree completely with the GP that this makes good business sense.
I do not. But apparently personal principles are unwelcome here.
If excellent customer reviews and a real money-back guarantee don't convince you, then I'm not sure a free trial will either.
Do you see the contradiction here? I am happy, delighted even, to pay $200 (and then $100/yr) precisely because I know it is going to keep the company afloat for version 4, and 5, and 6. If anything I worry they are charging too little.
You want good things to exist, someone has to pay for them! Why is this so hard to understand?
> @paths.each { |path, paint| canvas.drawPath(path, paint) } if @paths
From: https://github.com/HipByte/RubyMotionSamples/blob/master/and...
And: @activity.handler.post -> { @activity.updateTimer }
From: https://github.com/HipByte/RubyMotionSamples/blob/master/and...
These things take a lot of lines in Java for Android where we don't have lambdas and function references yet and often have to define anonymous classes just to pass a method in to a handle to be run later.
Yes.
> do you only get them for one year?
Yes, though license renewal costs $100, not $200.
Finally I have a reason to give RubyMotion a try. I'm curious how much productivity gain can one achieve with a language like Ruby once it is compiled (which will ensure the speed of the resulting application).
Workflow is one thing, but then writing Ruby code is so fluid. Notice that there's not a lot of preamble (imports and such) that you need to take care of in the Ruby code, I think that's great. But, again, language and workflow are very personal, and I think every tends to "think they're right" ;-)
I'm a "full-stack" web developer using mostly rails these days. I've only begun to try out rubymotion but it seems fantastic for someone like myself. In my nights and weekends , I am continually working on my own startup. Releasing any sort of mobile app was daunting, particularly on iOS. I have some Android experience but zero Objective-C. Phonegap and "the like" just didn't seem to deliver a product which would even satisfy my definition of "MVP". I could be wrong but that is just my impression. In fact, Phonegap turned out to be significantly more complex to figure out than I expected. When I found rubymotion, I had some basic apps written, which were hitting live API's I had created. They aren't simple but they are legitimately native, so they have the ability to run smooth and fast.
My hope is that a lot of what I write will be usable on both iOS and Android but at first blush, that might be difficult to pull off. Maybe someone will create a framework which sits on top of rubymotion which allows you to create one app which compiles down to both an .apk and whatever iOS needs? hahahah. I laugh but someone probably already is working on it.
> The object model of RubyMotion for Android is based on Java. Ruby classes, objects, methods and exceptions are Java classes, objects, methods and exceptions, and vice-versa. No bridge is involved.
You're still coding to the same native APIs, but you're doing it in Ruby. That's how RubyMotion works on iOS/OSX as well as Android now.
Anyone have feedbacks coming from what I do to something like RubyMotion or Xamarin? These solutions sound very interesting, but I've yet to try them. I think I'm too attached to my Objective-c and workflow.
Also, is there peoples who originally used RubyMotion or Xamarin and went to use OC and Java?
RubyMotion supports xib files, storyboards, xcdatamodel files, and Android XML files (and localization files, etc), so if you ARE interested in switching, you don't have to stop using those if you're already used to them.
[1] http://www.tidesdk.org/ [2] https://github.com/TideSDK/TideSDK [3] http://www.tidesdk.org/blog/
Expect that it won't be long before somebody comes out with a cross-platform wrapper for native UI elements similar to Xamarin 3.0.
And to chrisdevereux's point, we've already got some Android support in MotionKit.