Live data from Hacker News

RubyMotion 3.0 Sneak Peek: Android Support

blog.rubymotion.com

21–30 of 80 posts

Re: RubyMotion 3.0 Sneak Peek: Android Support

#22
post #4

"RubyMotion for Android features a completely new Ruby runtime specifically designed and implemented for Android development." 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).

How does this differ from Ruboto http://ruboto.org/?

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.

Re: RubyMotion 3.0 Sneak Peek: Android Support

#23
post #6

"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." 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 the…

"Runtime" generally refers to the library routines that handle the creating and keeping track of objects, adding methods and/or ivars to those objects, and calling methods. How you call those library routines can vary.

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?

Re: RubyMotion 3.0 Sneak Peek: Android Support

#24
post #7

I'm curious if the XML views will remain the same?

Presumably yes if it uses native APIs. On iOS, although .nib files are supported, people tend to prefer Ruby DSLs to define interfaces though. I imagine that something similar will happen on Android.

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.

Re: RubyMotion 3.0 Sneak Peek: Android Support

#25
Maybe it's petty but I've lost confidence in Ruby Motion since I've had a pull request open against it for whole year because they don't support enterprise deployment out of box. The fix is pretty damn simple too https://github.com/HipByte/RubyMotion/pull/64/files

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.

Re: RubyMotion 3.0 Sneak Peek: Android Support

#26
post #4

"RubyMotion for Android features a completely new Ruby runtime specifically designed and implemented for Android development." 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).

How does this differ from Ruboto http://ruboto.org/ ? 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.

Ruboto uses JRuby which has a long start up time.

Re: RubyMotion 3.0 Sneak Peek: Android Support

#27
post #4

"RubyMotion for Android features a completely new Ruby runtime specifically designed and implemented for Android development." 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).

> I would love being able to write ruby instead of java

You can do that with InfraRuby (http://infraruby.com/) if you don't mind writing type annotations.

Re: RubyMotion 3.0 Sneak Peek: Android Support

#28

Are mobile apps written with RubyMotion on par with the native equivalent? For example, I've heard a lot of people dislike PhoneGap, AppAccelerator, etc because the final app isn't as polished as something that is built natively.

I would assume that the process for Android is much different than iOS or OS X. In the latter cases, the ruby is compiled to the same "stuff" that objective-C is compiled into. As for Android, I'm not totally sure. My experience with some apps written using rubymotion (http://www.rubymotion.com/apps/) they seem to run very fluid on my iphone 5s. The original product was macruby which was exclusively for writing OS X apps using ruby. My understanding is that that framework produced great results which spurred the continuation to iOS and now Android.

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.

Re: RubyMotion 3.0 Sneak Peek: Android Support

#29

Earlier quoted context omitted.

How does this differ from Ruboto http://ruboto.org/ ? 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.

Ruboto uses JRuby which has a long start up time.

[deleted]

Re: RubyMotion 3.0 Sneak Peek: Android Support

#30
post #6

"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." 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 the…

That jumped out to me too. There is a significant performance hit when you make JNI calls. Last I looked not all of Android's API are easily exposed to native code. Constantly context switching from native to managed can be beastly. I'd be curious on how often and when it is doing these JNI calls, what is native and what is java.
Post reply on HN