Breaking Cyclical References in RubyMotion with Proc#weak

I recently wrote a blog post illustrating the memory management limitations in RubyMotion. More specifically, I illustrated how easy it was to introduce cyclical references by creating strongly referenced lambdas where the lambdas implicitly have a strong reference back to self.

Unfortunately, at the time of the blog post, it was not possible to break the cyclical reference. Which meant that doing something as innocuous as… Read more on Breaking Cyclical References in RubyMotion with Proc#weak…

Working around RubyMotion’s Memory Management Limitations

During my time using RubyMotion and ReactiveCocoa, I ran into a couple of pitfalls related to memory management. It should noted that these are not bugs in RubyMotion or ReactiveCocoa but are instead just the reality of working in a runtime that is built on Automatic Reference Counting.

Read more on Working around RubyMotion’s Memory Management Limitations…

Unit Testing with ReactiveCocoa and RubyMotion

Karlin Fox and I have been using RubyMotion and ReactiveCocoa to build an iPad application for our current project. We’ve enjoyed the different paradigm and the way we’re able to stream data through our application. Adapting TouchDB live queries to ReactiveCocoa signals has been particularly rewarding.

But what about unit testing our iOS app? Unit testing in iOS has matured a lot in the past few years, and RubyMotion brings testing along from the start of a new project. However, development paradigms like FRP have a dramatic effect on how we test, what we test, and what tools we choose to build our tests.

Mocking vs. Real Objects

We’ve been alternating between mocking out signals and creating real signals we can instrument in our unit tests. Each method has its advantages.

Read more on Unit Testing with ReactiveCocoa and RubyMotion…

ReactiveCocoa & RubyMotion: The Setup

RubyMotion promises to bring the clarity and concise syntax of Ruby to iOS and OS X development. ReactiveCocoa’s aim is to help reduce complexity by deriving state instead of declaring it. Sounds like a great combination, right?

There are some complications. First, the documentation and examples almost all use the RAC and RACAble macros provided by ReactiveCocoa, something we can’t use from RubyMotion. Bummer. And RubyMotion’s bridgesupport doesn’t allow us to call Objective-C methods that take blocks typed as id. Rats. Fortunately these can be overcome, thanks to some helpful folks on the internet, so let’s get started.
Read more on ReactiveCocoa & RubyMotion: The Setup…

ReactiveCocoa: The Future of Cocoa Programming

Last year at around this time, Github announced ReactiveCocoa. I was excited to see a Functional Reactive Programming framework made for Objective-C and found an immediate use for it in an iOS project. Since its release, there’s been a tremendous amount of activity, documentation, and blog posts around it.

The point being, there isn’t an excuse not to use it anymore, and I’d argue that it is (excuse the reference) the Rearden Metal of Objective-C frameworks. It will significantly improve the structure and reduce the complexity of your code. It removes the need for the delegate pattern, continuation-passing style programming, and (most importantly) keeping track of state.
Read more on ReactiveCocoa: The Future of Cocoa Programming…

Using Nimbus with UITableViews in RubyMotion: An Example

Recently, I was looking for an example of using the Nimbus library to help manage a UITableView and its respective cells. Their documentation covers a lot of the details, but I was having a difficult time seeing exactly how all the pieces of the puzzle fit together. I couldn’t find a good, simple example, so I made one. You can find it on github.

Read more on Using Nimbus with UITableViews in RubyMotion: An Example…

iOS Keychain Entitlements for Using RedLaser in RubyMotion

I was recently tasked with exploring the RedLaser SDK and getting it to function in a RubyMotion application. While using a newly-created RubyMotion project I found that the function call RL_CheckReadyStatus() (which does a number of hardware and license checks) was consistently failing with a -3 return value, which represents a bad license file. Because I was experimenting with evaluation mode, which limits a device to 25 scans, and because there wasn’t a presence of a license file, this error code was erroneous on multiple levels.

Read more on iOS Keychain Entitlements for Using RedLaser in RubyMotion…