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.
I'm just smiling at the juxtaposition. It's amusing what in most circumstances would be a fact of life becomes a major sticking point. Apple doesn't take pull requests. I'm sure Google accepts patches, sometimes, but the process doesn't strike me as quite on the PR-level of ease.
Is the alternative PhoneGap, and the hypothesis that they're more responsible with taking ownership of your pet features? Just curious.
PhoneGap works well so does Xcode or anything that doesn't aim to replace the typical processes.
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 could be a bad sign, or it could speak to priorities, and your priorities are not their priorities it seems. Personally, I accept all pull requests that are solid, written to my standards, fix or extend a feature that is a priority, are accompanied with unit tests, and do not impact or impinge on another feature or future feature. I do not however accept all pull requests. Part of this is that if there is no demand and it's a single individuals edge case, then I'll very heavily scrutinize the patch. If I don't agree, don't understand exactly what every line is doing, or do not feel it will be used by a significant portion of the user base then I won't pull it. Because moving forward, I will have to maintain it, and that isn't free. And if people don't like that, they can fork it.
True, but if your business is alternative toolchains to Apple's own; and it's shown to me that you don't support something I know a great deal of iOS developers use then I lose a bit of faith in your marketing message that "lot's of important apps use us... and don't mind what all the naysayers say about our garbage collector, give us $200/year and give it a shot yourself".
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.
Enterprise and government comes with a lot of baggage that no sane developer would ever try to take on. You are manifesting your priorities on them, and that simply may not be the case. The $200 price point is likely that high in order to keep the client base low. I'm not saying you're wrong, but Apple itself barely supports enterprise with most of their enterprise management bits being third party. A laptop without a docking station??? Crazy, they might as well not sell computers...
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.
On iOS "enterprise provisioning" means less baggage. No UDIDs, which are deprecated in software BTW. To be clear this is a tiny patch that adds support for some 40%+ of dev shops and all enterprises. All we are talking about is this:
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
Where the provisions all devices is my bit supported by a single line helper, it's not scary. If you have more than 100 devices beta testing your app you use enterprise provisioning PERIOD, it doesn't have anything to do with classic "enterprise" except you need a DUNs and to pay Apple an extra $100/year.
Almost every dev shop that is more than two guys I know uses this.
I submitted a pull request to fix a dead link in the angularJS docs: I was told to fill a 20-text field form for the request to get processed. I was just trying to help, guys.
I've accepted and merged a fair number of patches. It's a matter of getting the right reviewers and working with the people involved in each of the areas to come up with a reasonable patch if it's anything other than a small bugfix.
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.
Hi James, it's mostly my fault that your PR hasn't been merged. We tend to focus a lot on the compiler, and less on the Rake commands, but I'll try and get these PRs taken care of soon.
"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 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.
"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.
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.
I believe you don't need to do anything along the lines of JRuby where you would sometimes need to bridge libraries from Java-land into Ruby.
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.
Thanks for the downvotes! In case it's not obvious, this is a free download (follow the "Installation" link). A major update will be released next week!
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.
Um.. no. Sorry. I haven't done that for desktop software since the early 2000s. You're asking for a lot of damn money on nothing but faith.
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.
I have to say I have trouble taking comments like this seriously. $200 is "a lot of damn money"? Are you kidding? This is a professional tool for software developers. You do know you'll need a $100/yr ADC membership to even run your software on an iOS device, right?
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 can attest, as a RubyMotion early adopter, the product and especially the customer service make the $200 entry point and $100 service renewal well worth it.
If excellent customer reviews and a real money-back guarantee don't convince you, then I'm not sure a free trial will either.
You've not experienced much of the high end market then. SAP / Oracle / many other enterprise apps cost thousands to tens / hundreds of thousands of dollars to license.
I agree, and the 30 day trial isn't enough. It would be side projects, so I may get to hack on it for a day and maybe a night or two. I can write Obj-C, and Java, they just aren't as intuitive or enjoyable to me. And lets face it, $200 is just too much to spend when RubyMotion may not exist for version 4, and then I have an entire application that needs to be ported into Obj-C and Java... And a promise of open sourcing it doesn't help, because there may be no maintainers. IronRuby, now that C# has dynamics, would be awesome. But it hasn't been updated in 3 years. I'd even drop $100 sight unseen. But $200... Noooope.
> $200 is just too much to spend when RubyMotion may not exist for version 4
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?
Um, because I don't know if it's a good thing. How hard is that for you to understand. Seriously, did you read my comment before deciding to lay on the snark.
I was impressed that even with all this translation and Java compatibility going on, the sample code still shows some situations where the nice clean, concise nature of Ruby is still up and running. E.g.:
> @paths.each { |path, paint| canvas.drawPath(path, paint) } if @paths
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.
I was just looking at the rubymotion licences [0]. does anyone know if you will get future releases with the licence? do you only get them for one year?
I just downloaded it and am impressed so far. Looks like it'll be an extra bonus since I won't have to also learn Ruboto to write Android apps with Ruby.
This is great news, it will boost the adoption of Ruby and RubyMotion in the huge Android market.
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).
I think the gains are huge, but it depends on your preferred workflow. I know some traditional Xcode developers who kick and scream at the idea of loosing their IDE, whereas I prefer to live in the terminal.
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" ;-)
Agreed, RubyMotion is appealing if you prefer a fast development cycle. I tend to use C++ for most of my programming projects but every time I've used a more "dynamic" language (Python or JavaScript in my case) I was amazed at how fast I can try/drop/improve on an idea and see the code running. The only problem I had with the "dynamic" languages was the speed of the resulting code, RubyMotion seems to be in the sweet spot between a statically typed language and a dynamic (usually interpreted) language.
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.
> 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.
Hey, when it comes to mobile, I develop them in pure Objective-c for iOS, and pure Java for Android. I use tools provided by both compagnies. So yeah, I do the jobs twice, but I think it's ok.
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?
If you already have a comfortable work flow, I would not encourage you to migrate just for the sake of it, but having the option to write a native app in Ruby is very compelling to a lot of people who might otherwise not be interested in writing a native mobile app.
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.
I've used a bit TideSDK [1]. I'm afraid the project might be on hold though since there has been no activity on their github repository [2]. Some explanations can be found on their blog [3]
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.
This is fantastic news. I love RubyMotion and can't wait to try it on Android. Especially want to learn how easy it will be to create wrapper objects to have a common API across platforms.
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.