I recently spent some time working through ways to automate running an Android test suite on my MacBook Pro. I found helpful bits and pieces all over the place—from Stack Overflow answers to blog posts talking about how to get Android into various CI servers (Travis, Jenkins, etc.)—but the information was scattered. In this post, I’m going to document what I learned while writing an Android test script.
A while back, I wrote a post comparing replay, replayLast, and replayLazily. Thanks to some investigating by Brian Vanderwal, I recently learned that one needs to be careful when using a replay operator (or multicast/connect directly) with an infinite signal as its source.
This blog post refers to the older ReactiveCocoa 2.x Objective-C library. I’m guessing that the newer Swift versions have the same behavior, but I don’t actually know for sure.
Read more on ReactiveCocoa – Cleaning Up after replay, replayLast, and replayLazily…
In my previous post, I talked about using Value Objects in Objective-C projects. I gave an example of a Ruby DSL that could be used to specify the object’s properties so the code could be generated.
In this post, I’ll go through some Ruby code that can turn that DSL into an Objective-C header and implementation file. Read more on Objective-C Value Objects: Code Generation…
I’ve come to the conclusion that regardless of how “functional” a programming language is, the best way to handle state is with immutable value objects.
Wikipedia defines a value object as follows:
“In computer science, a value object is a small object that represents a simple entity whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object.
Value objects should be immutable: this is required for the implicit contract that two value objects created equal, should remain equal. It is also useful for value objects to be immutable, as client code cannot put the value object in an invalid state or introduce buggy behaviour after instantiation.”
I’ve found that immutable value objects are particularly well suited for passing data around when using one of the Reactive Extensions libraries. While not a direct port, I lump ReactiveCocoa into the same category, and it benefits just as much by sending Objective-C value objects on its signals/streams.
Read more on Simplifying Objective-C Value Objects with Mantle and the Builder Pattern…
August 2015 marked the completion of my tenth year at Atomic Object. Inspired by Shawn Crowley’s recent post, Consultancies: The Smart First Job for Software Developers, I’m going to take a look back at the wide array of industries and technologies I’ve worked in while at Atomic. How might those 10 years have been different working for a non-consultancy, like a product company?
Imagine a scenario where you need to create an
Observable sequence that will acquire a resource, do some processing, and release the resource when unsubscribed from. An example of something like this might be an
Observable that acquires a lock and releases it when unsubscribed from. That “lock” signal could be merged with a second signal that does some work that should only be done after the lock has been acquired.
In his Easy Asynchronous Operations in iOS with ReactiveCocoa post, John Fisher described how to use
-flattenMap to chain together signals that wrap asynchronous operations. He also described a technique for serializing those chains of operations by executing the chain on a serial
If an app performs a task that needs to complete even if the app is moved to the background, iOS provides a way to request a little more time to complete the task. You just need to let iOS know when you’ve started the task and when it has ended. If the app is moved to the background while the task is still in progress, iOS will allow the app to keep running (up to 3 minutes in iOS 7 and 8) to try to give the task a chance to complete.
One of the many useful things I’ve found in ReactiveCocoa (a functional reactive programming library for iOS) is the way that it can abstract away the asynchronous callback nature of some iOS core frameworks. And, by making use of RACDisposables, it’s easy to take care of cleanup work like closing connections or stopping a service.
When developing an iOS app, one needs to watch out for retain cycles that prevent objects from being deallocated. We’re using ReactiveCocoa heavily on my current project, which means we have a lot of blocks in our code, and thus ample opportunity to introduce a retain cycle (see ReactiveCocoa’s Memory Management documentation for more info). Read more on Automated iOS Retain Cycle Testing in Objective-C…