Chris' Blog.

After working extensively with ReactiveSwift (formerly known as ReactiveCocoa) and RxSwift for the last year and a half, hopefully I can shed some light on what works when it comes to getting down and dirty with real projects.

Some jargon to help get started, feel free to skip this:

• Observable (RxSwift): this is a stream of values. It may or may not give you a value immediately on subscription, and it might or might not be hot or cold. It's a bit vague.
• Signal (ReactiveSwift): This is a 'hot' stream of values. This means that subscription doesn't affect the stream. Imagine a car with the engine already running (hot) before you get in (subscribe).
• SignalProducer (ReactiveSwift): This is a 'cold' stream. This means subscribing affects the stream. Typically this means that when you subscribe, it starts the thing that you're observing, e.g. a network request. Imagine a car with a cold engine that starts up when you get in.
• Variable (both Rx and Reactive): A handy bridge between the reactive and imperative worlds. Basically it's a wrapper around a plain old variable, and lets all subscribers know whenever the variable changes. It also lets subscribers know of the current value immediately upon subscription. If you're overusing this, it may be considered a code smell. Having said that, pragmatically, you should use it judiciously to get things done - it's unrealistic to make your codebase 100% reactive when you're dealing with UIKit.
• BehaviorSubject (Rx): RxSwift 4 will be deprecating Variable because they think it is a sop to imperative programming - you must use BehaviorSubject instead at some point going forwards.

Alright, let's jump right in!

Observables/Signals vs Variables

Oftentimes, when facing a problem to solve, the question will be: to create an Observable or Variable? The observable will be more pure-functional, which is laudable. And a variable introduces extra state, which is something we wish to minimise. Rather than having too much state, it is better to have a minimal 'source of truth' state, and pure-functional observables derived from said source of truth. This way, you cannot fall into the trap of updating, say, your user account in one class but forgetting to update it in another class.

State

To this end, I recommend taking a leaf out of Redux's book, and follow the philosophy of having a single source of truth. For instance, I recommend one app singleton named State, which in turn contains an instance of each category of state required, such as User for login/logout state. Since, by nature, state is required to be stored here, I recommend using a Variable. Accessing would then look like so: State.shared.user.state.

Example of state:

class State {
    static let shared = State()
    let user = UserState()
}

class UserState {
    let isLoggedIn = Variable<Bool>(false)
    let name = Variable<String?>(nil)
}

Alternatives proposed include having your individual state objects (such as UserState above) be individual singletons in their own right. However the approach in the example above has one advantage: it exposes a single convenient chokepoint at which you can substitute your mocks for testing: State.shared.

View Models

Many ViewControllers will do well to be backed by a view model. The view model is responsible for deriving a subset of the application's state in a way that is simpler to apply to the appropriate screen. For instance, say you have a screen where the current user state is to be displayed in the navigation bar title: the view model is responsible for combining the State.shared.user.isLoggedIn and the user.name variables into one title observable. I recommend that these view models be structs, and contain only observables that are derived from the state singletons' variables.

Example of a view model:

struct UserDetailsViewModel {
    let title: Observable<String> = Observable
        .combineLatest(
            State.shared.user.isLoggedIn,
            State.shared.user.name)
        .map({ (isLoggedIn, name) -> String in
            if isLoggedIn {
                return name
            } else {
                return "Logged out"
            }
        })
}

Wherever reasonable: Use Variable for a source of truth, and Observable/Signal for a derived truth. Where 'source of truth' means your state singleton, and 'derived truth' means your view models.

On the other hand: Sometimes it is simply unworkable to have only observables in your view models. Sometimes you just need the value 'now' rather than binding it and trusting that it will be there later. Sometimes it just isn't practical to refactor your app to be Rx the whole way through. In these cases, my team has agreed on a pragmatic compromise: your view model will create pure-functional observables for all its fields, and then bind that observable to a Variable, and expose the Variable. As part of this, you'll want to change to using a class, so variable state and disposal is easier to reason about. For example:

class UserDetailsViewModel {
    let title = Variable<String?>()
    let disposeBag = DisposeBag()

    init() {
     Observable
        .combineLatest(
            State.shared.user.isLoggedIn,
            State.shared.user.name)
        .map({...})
        .bind(to: title)
        .disposed(by: disposeBag)
    }
}

View Controllers

In your view controller, I recommend using bind to connect your view models to your fields. For instance:

class EditUserViewController: UIViewController {
    @IBOutlet var name: UITextField

    let disposeBag = DisposeBag()

    let viewModel: EditUserViewModel!

    override func viewDidLoad() {
        super.viewDidLoad()

        viewModel.name
            .bind(to: name.rx.text)
            .disposed(by: disposeBag)
    }
}

This will accomplish one direction of data flow: from the state model to the UI. For the reverse direction, e.g. when the user enters a new name and taps 'save', I recommend building a series of 'State Services' for persisting those back to the state singleton. Feel free to think of a better name than 'state service', by the way. For instance:

struct UserStateService {
    static func save(name: String) {
        State.shared.user.name.value = name
    }
}

This way, your state services are the only layer responsible for applying business logic and directly manipulating your state, keeping such code away from view controllers, which we'd like to keep as simple as possible:

extension EditUserViewController {
    func tapSave() {
        UserStateService.save(name.text)
    }
}

Closing thoughts

A grab-bag of ideas that I couldn't figure where to fit above:

• Bind things wherever possible, don't use imperative code. For instance, subscribing to a view model and using onNext to update a field feels very imperative. Rather, bind the view model to your fields. You want the code to read like 'this is what I want it to do' rather than 'this is how I'd like it done'.
• Use combineLatest upfront to grab everything you need for a given field in a view model, rather than referring to State.shared.foo.x in a map statement. Otherwise you run the risk that a change to X will not update your fields correctly.

Best of luck!

There's a lot of hype currently around React Native, so I recently decided to sink a good amount of time into it to give it a shot, and report back with my impressions. Admittedly, these are only a week's worth of impressions so keep that in mind.

I spent a couple week's worth of evenings developing a prototype for an app a friend and I wanted to run by a few businesses, see if there was any interesting in a full build-out. Long story short, we got market validation that the idea wasn't what the industry wanted. But i did learn a lot about React Native in the meantime which I'll now share.

Potential

There seems to be a lot of potential with React Native. It is an extraction rather than a framework. DHH, of rails fame, made this distinction years ago: good frameworks are extracted from things that are required to work, because many people's paycheques/families/mortgages depend upon it. I'll clarify: I assume it's an extraction - we can't know Facebook's internal strategy specifically, but it certainly points that way (eg they use it for their Groups app and now the core Facebook app). My point here is that React Native is battle-hardened and production-ready, unlike say other write-once-deploy-on-ios-and-android frameworks which decidedly weren't.

Working with Swift at scale is an exercise in frustration common to many teams - see Uber. Xcode cannot index, and compiles blow out exponentially once you hit ~20KLOC, depending largely on if you have many small files or fewer large ones. So the opportunity to change properties and see updates in an iOS simulator and an Android simulator on your computer within seconds is compelling. I can confirm that this aspect of React Native is productive.

Don't be scared off because it's Javascript. JS has come a long way since the 90s - ES6 really shines, with elegant syntax for classes, inheritance, avoiding var hoisting, and so on. Take full advantage of all this, because RN uses Babel to transpile your newest-style JS into whatever is necessary for iOS and Android's runtimes.

And, in short: it's not, well, terrible. Most other cross-mobile-platform JS frameworks like Titanium / Sencha Touch / PhoneGap / Cordova / Ionic, well, are. I think it's on par with Xamarin in terms of production-readiness, however its live updates make React Native more productive.

Thoughts

Here's a grab-bag of perspectives gained from my two weeks, in no particular order:

• Watch a lot of screencasts. There are a few at egghead.io. You'll notice that there are a few different styles for coding in RN, which appears to be a bit in flux. Hopefully this coalesces to one style in future.
• Watch the Youtube videos by Tal Kol, Wix is really doing well with RN.
• Check out Ignite and watch their Youtube videos. I think Ignite is like Rails scaffolding for RN, and pushes you in the direction of best practices - highly recommended.
• FlexBox (their CSS-based layout alternative to AutoLayout) is a bit limited. You'll often have to wrap things in a (few) view(s) to get the layout you want.
• The RN 'packager' is buggy, so get used to restarting it.
• I've seen layouts acting buggy, things positioning where the code clearly shouldn't allow, at which point I close and re-open the packager/simulator. There seem to be some kinks here.
• It's hard to find 'best practices' for some things, eg what do I do for a navigation controller? I find Wix or Ignite have great solutions for this particular case. It appears some things like this aren't 'batteries included' by Facebook so you often have to find a good library for things that really should be included.
• Learn the differences between Props and State. Roughly: props are for things passed into your components; state is for things your component changes about itself.
• Flexbox basic stuff here: facebook.github.io/react-native/docs/flexbox.html
• Flexbox advanced stuff here: facebook.github.io/yoga/docs/flex-direction
• TouchableHighlight must have only one child, but that child can have lots of children, so get used to grouping everything in a wrapper view.
• Logging is simple: console.log('foo'), then in the iOS sim, do Menu > Debug > Open system log.
• No type safety is hard to let go of after Swift: I sometimes call a prop 'isSelected' and in some places refer to it as 'selected' and get confused. Flow might help with this - I haven't tried. Also you can strong-ish-ly type your props like this: MyComponent.propTypes = { isSelected: React.PropTypes.bool, etc };
• You have to update a datasource instead of another state property if you want a list to rerender - this got me stuck a few hours.
• To make a button where the text dims on tap but the background stays the same, have a view (with background), containing a TouchableOpacity (no bg), containing a Text.
• Many of the builtin components are iOS only eg the action sheet, so watch out for that. Wix provide cross-platform solutions for most of these.
• When choosing components, choose the one with the most github stars, least github issues, and simplest example usage.
• Don't use var anymore, use 'let' instead. (let is like swift's 'var'; const is like swift's 'let'; var is js-hoisting-madness)
• There are lots of syntax changes re ES6 v ES5 vs classic JS to be aware of, eg use for of instead of for in.

Summary

I recommend at least becoming familiar with React Native. As our industry matures and rates begin to drop, I think it'll become increasingly compelling at job interviews to be able to say: I can deliver iOS and Android apps to the business for the price of one developer.

And here's the prototype that was the result of, say, 10 hours work:

I have a bit of a tale to tell regarding a homegrown Plex alternative which I've been working on for a year or two...

So, for years now, I've had a plex server in the garage, which I've used to entertain my girls and solve the problems of:

• My oh-so-well-behaved offspring scratching the hell out of every DVD we buy them.
• My did-I-mention-they're-well-behaved offspring screaming blue murder as I inch my way through DVD menus to get the damn things to play.

So far, so good: plex has helped keep the screaming-for-blue-murder down to a dull roar for years now. However, there have been many niggling issues with it that have driven me to think 'could I do better?', such as:

• It requires a decently powerful server...
• Which means it has a noisy fan...
• Which means it must go in the garage...
• Which gets awfully hot in the australian summer...
• So I walk in my garage most days and hear the server's fan going full-tilt and I freak out about it being a fire hazard.
• And other issues: Often it just fails for whatever reason and needs a server reboot
• New versions of the client ask me to sign up and in - I'm not doing that!
• If you try to seek in most movies, it spins forever and probably fails (i've never waited more than a minute).
• It doesn't simply figure things out if you drop new movies in, you need to remote into the server and kick off a re-scan.

So, armed with a trusty text editor, I mucked around with ffmpeg, and Go[lang], and so on, until I came up with Gondola, which I'm now releasing as an open-source project here:

splinter.com.au/gondola

Gondola is the full suite: A transcoding-ahead-of-time media server which works from a Raspberry Pi or a fanless laptop (I recommend the latter); a native client app for your Apple TV, iPhone, and iPad; and a web client which will work on any Android device. I've put a small price on the apps in the app store (due to the hassle of getting them approved!) but you can compile and install them yourselves if you like.

Hope you like it!