Want the app on your device? After you run through the iOS certificate/provisioning gauntlet on your machine, rake device makes it happen. Run one command, and it compiles the app and launches the simulator with it running. RubyMotion’s rake based workflow is wonderful. If there’s one way we can prove that RubyMotion can win in the long-term, it’s by showing how easily it can link to both battle-tested Objective-C libraries and the Ruby community’s favorite gems. We’re already using Ruby, so we should be able to tap into the RubyGems ecosystem properly from the start. It is also possible to package gems to use with RubyMotion via BubbleWrap, it just requires a bit of legwork to get set up. RubyMotion does support vendoring static libraries and Xcode projects directly into your app, so not all is lost. m files into your project” made my heart sink. Every README I browsed that said “Just drag the. There’s clearly no guidance or leadership from Apple on this issue, despite the amount of OSS projects written in Objective-C available. ![]() CocoaPods is making some serious inroads in creating reusable software packages, but I don’t feel like it’s enough. One thing I found out early on is that the state of external dependencies in the iOS/Cocoa world is in a sorry state compared to Ruby’s. I hope RubyMotion spawns more libraries like this: they’re extremely valuable to the community and provide a great foundation to build an app on. I’ve learned an immense amount by reading through BubbleWrap’s code, and I’d recommend any iOS developer to do the same. Quickly persist data locally without using CoreData or other custom wrappers.Listen for and post NSNotificationCenter messages.Firing almost every HTTP request to fetch pages, projects, and attachments.There’s a lot of great, well documented code inside this gem that has saved me many hours of poring over Apple’s guides and implementation time. If there’s any one thing you can do after starting a RubyMotion project, it’s immediately drop BubbleWrap into your repo. This approach is definitely a compromise, but it kept my brain at a constant level of sanity while jumping back and forth between Ruby and Objective-C. Methods on StackerController are in camelCase, and if they take more than one parameter they use Objective-C named parameters instead of Ruby-style parameters. RubyMotion allows us to use Ruby’s new to create objects, but usually you’ll see alloc.init in most Objective-C code, so we’re keeping that. ParentViewController.pushViewController(stacker, animated:false) Here’s a pretty typical method, from when the app summons our StackerController, a custom container controller that handles the “page stacking” animations and transitions: def stack(controller) All of the API calls you make into the various iOS frameworks need to be in that style, and seeing the different opinions of variable and method naming clashing ended up hurting my head. ![]() So far, I’ve ended up with staying in Objective-C style. I have struggled with my style of coding inside of the app from the start: Should I stick with the normal Ruby style of snake_case, short variable names, and multiple non-named parameters? Or, ditch it in favor of speaking the native tongue of Objective-C? ![]() The entire Apple docs for iOS have even been lovingly translated to Ruby, which makes it pretty clear that slapping Ruby’s normal style on top of the APIs is not easy. The iOS APIs stick out like sore thumbs amongst what is normal Ruby code: camelCase usage is pervasive and reallyFreakingLongParameterNames can’t be tuned out. RubyMotion is Ruby, which is normally succinct, short, and sweet. I’m planning to release a gem to help make Auto Layout even easier with RubyMotion soon. This is a far cry from CSS, but it’s definitely better than manually setting the size and origin for each element. You can add in specific numbers for measurements of either spacing or elements, and lock the size of elements to other ones already on the screen. The syntax is a little obtuse on first glance, but it’s pretty simple: brackets contain UI elements, pipes are the edges of the screen, dashes denote spacing between elements. These are the visual format language strings that describe this layout: # horizontal Here’s a simple example from the app, from our home screen: Using Auto Layout is almost like laying out interface elements in ASCII art. Luckily, iOS6 added a new API to make this easier: Auto Layout. Our hybrid web/native approach helped with this, since there isn’t that much native UI to hook up. I left that world years ago, and I don’t want to look back.Īvoiding Xcode means that we had to wire up the interface all in code. Working inside of Xcode and dealing with Interface Builder brought memories back of wiring up Visual Basic controls and suffering through Visual Studio crashes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |