Tuesday, November 21, 2017

Real-world native mobile development. From ObjC to Swift and from Java to Kotlin

My team is responsible for our Company's Mobile Apps - Our biggest app is a reasonably sized one (39 ViewControllers at the current time of writing, with about a dozen significant "service" components) with both iOS and Android versions which goes back a few years. The first version was released in about 2013 off the top of my head.

Historical iOS Development in Objective-C

We originally developed the App in question for iOS only, targeting Objective-C (This was before Swift existed.) Later on we built up an Android version using Java (again, predating Kotlin which is only a "stable" option for Android development in the last 6 months or so).

We were quite excited when Apple announced Swift, and immediately played around with it, but we didn't consider it seriously until Swift 2 - We started to port small parts of our iOS app over to Swift 2 in mid 2016 - probably about 4 months before Swift 3 was released. Swift 2 / Xcode 7 was definitely unstable, however we found Swift 3 / Xcode 8 to be pretty stable and nice to work with, and I definitely feel like with Swift 4 and Xcode 9 is mature and reliable now.

Why port Objective-C to Swift?

We felt that we would very much like the benefits of Swift (strong typing, null safety, nicer syntax, etc). As such, we have an informal policy that all new code should be written in Swift (within reason).

While there's a strong argument to be made that old code isn't broken and should be left alone, nobody on the team really wants to have old stuff sticking around forever, and everyone's in agreement that in a perfect world, the entire app would be Swift. Porting everything in one go would be an enormous time investment and generate a huge pile of bugs, so we're not doing that at all. Instead the policy is (informally)

  1. If you're doing new code, do it in Swift
  2. If you're between tasks, and you feel like you want to port some code to Swift, go forth and just do it.
  3. If you're working on some old Objective-C code, you should seriously consider porting it to swift while you're at it

Between 2 and 3, I've found that over the last year or so the app is slowly but surely transitioning it's way over to more and more Swift. We'll still have Objective-C for at least another year or maybe two, but I can definitely see it going away eventually.

Thoughts on Swift

  • Null-safety is fantastic, however there is definitely a learning curve. I found everyone on the team had no problems dealing with the concept of null safety, it's just a bit of a job to learn all the syntax and rules and how they apply everywhere (i.e. nullable generic types and stuff like that)
  • Swift's more concise syntax is great, compared to Objective-C. It's hands down nicer than Java or C# or anything else (except maybe Kotlin, see below)
  • Swift protocols with associated types are weird and very complex. I feel like I understand what's going on and why they're done that way, but I find this very hard to explain to anyone else in a satisfactory manner. The only saving grace is that you tend not to have to use PAT's very much
  • Having programmed C# and C++ for a long time too, I very much like having generics and strong typing available in Swift (Compared to Objective-C)
  • Supporting "mixed projects" where you can have Swift and Objective-C files side by side in the same binary really is a killer feature for porting and upgrading.
    Our company has huge amounts of C++ and C# code, and if Microsoft had somehow pulled off same-project-different-language-per-file compatibility like Apple has here, the world would be a truly different place. It's quite likely all our C++ would have been replaced by C# years ago, rather than hanging around forever. (Now, since C++11 has revitalised the C++ world, it's no longer in danger of going away, but in the mid to late 2000's things were indeed looking dire for C++ for us)
  • Overall, I find Swift nicer to work in than Objective-C, Java or C#, however it is absolutely a much more complicated language. The upside of Swift borrowing lots of features from lots of other languages is that it offers many great, modern options for problem solving and development of safe and high quality code. The downside is there's a boatload of stuff that you have to learn, which has caused basically every developer on my team who's encountered it to feel incompetent for the first few months.

Android Development

As mentioned previously, we'd done our Android stuff entirely in Java. I personally am not a fan of Java, as I find it more verbose and clunky when compared to other languages, however I must say it hasn't been nearly as bad as I thought it would before we started it. A lot of this comes down to the fact that the language itself is really only about 30-40% of the development experience. The rest comes down to platform API's, and while I find Android definitely lags behind iOS in this area, it's still a darn sight better than the standard Java stuff I'd done in the past.

When Google announced that Kotlin was going to be officially supported in Android Studio 3.0, like with swift, I was quite excited. I'd seen kotlin before, but never really taken it seriously, and I'd lumped it in with other "experimental" languages like Groovy, Scala and Clojure that look awesome on paper, but don't look stable/widely supported/used enough to use for "real" development. Google promising official support immediately catapulted kotlin out of this group and into the "big league" - at least that was my feeling anyway.

Since Android Studio 3.0 has released, we've started porting parts of our app over to kotlin, following a similar process to what we did with Swift. As with our Swift port, we had pretty much the same reasons - wanting to take advantage of the nicer syntax, strongly safety guarantees and stuff like that. Refer to the "Why port to swift" section above.

Thoughts on Kotlin

  • As with swift, null safety is great. We had been extensively using @NonNull attributes all over our Java already, but Kotlin's support for working with nullable types with smart casting and the ? operator really make a big difference.
  • I definitely appreciate Kotlin's more concise syntax as compared to Java. Type inference is great.
  • Kotlin supports the same-project-different-language-per-file which (as with Swift) a killer feature for porting code. While the auto-converter is certainly far from perfect, it provides an enormous head-start when porting code.
  • I'm stunned by how good Android Studio (IntelliJ) is when dealing with Kotlin. I was expecting it to be like Xcode/Swift were, and have lots of bugs and missing features for the first year or two, but my experience has been pretty much since the Android Studio 3.0 release that it's of equal quality to the Java support. Hat's off to JetBrains here
  • Kotlin has some weird stuff though.
    - WTF Companion Object?
    - Wherefore art thou ternary operator? (Yeah you can use inline if/else, but that looks weird, and even Java has a ternary operator)
    - Returns from lambdas are bonkers. return in a lambda should return from the lambda as that's the common and usual case - the wonky return@thing syntax should be reserved for explicit non-local returns which are out-of-the-ordinary. I feel like they got this entirely backwards
  • Kotlin gets burned by it's extensive Java compatibility a bit - mostly because it inherits the same broken type-erased generics that Java has, which kind of sucks

Kotlin vs Swift

Now here's the best part of any programming blog! Comparing things so we can say which is better. Alas it's not so simple, as they both have ups and downs relative to each other. Here's some things in no particular order.

Syntax

I would personally give a very close win to Swift, but you could go either way here. Both are close (see Swift is like kotlin). Kotlin just has slightly more things which are weird for no seeming purpose. My pet peeve is the val keyword. It's visually incredibly similar to var, and there was strong precedent from many other languages to use let like Swift did, but Kotlin's just made a weird call here. On the other hand, Kotlin does have a lot more 'syntactic-sugar' things built in, which is nice.

Backward Compatibility/Interop

Clear win to Kotlin. One thing which surprised me is how close Kotlin actually is to Java. Not syntactically, but at runtime the majority of Kotlin types are just projections or wrappers around pre-existing Java types like String, HashMap, ArrayList or whatever, which I've found makes Java interop seamless and obvious in 99.9% of cases. Swift on the other hand departs significantly from the Objective-C runtime, defining it's own String, Array and Dictionary types, amongst other things, which can sometimes make things tricky. As evidence of this, the latest version of the Kotlin standard library which you must bundle with your app is 861KB, whereas the Swift 4 stdlib is something like 20+ MB. It's not a fair comparison, as Swift is native code and not JVM bytecode, and also a lot of the Swift std lib is stripped out of your app if not needed, but it does clearly show the point that comparatively, Swift needs a lot more stuff over and above the baseline platform to function.

Modern features/New Paradigms

Clear win to Swift. While I find Kotlin to be great to work with, it doesn't try to depart from Java nearly as much as Swift does from ObjC. As above this makes for much better interop and is easier to learn, BUT there's not as much opportunity to push things forward. Take for example Swift's value types. They can enable paradigms and ideas that you simply can't express in Kotlin. Likewise, Generics in Kotlin are held back by Java compatibility and so are half-assed like the Java ones. Swift makes the choice to break compatibility (Objective-C code literally can't see Swift generic code at all) in order to have "proper" generics without doing things halfway. I find swift to be a fundamentally different thing to Objective-C (or even C#/Java) whereas Kotlin doesn't seem to enable any fundamental new things that you couldn't already do in Java - everything's just much much nicer.

Learning curve

Java->Kotlin is way easier than Objc->Swift. See above. Even though Kotlin has more crazy stuff like companion object, the fact that there's not as much "distance" between it and Java outweighs it all.

App/Runtime stability

Both have been great so far.

IDE/Development Experience

Definite win to Kotlin. I think Swifth with Xcode 9 is definitely good, but the work JetBrains have done for IntelliJ/Android studio is simply fantastic (Around language support anyway. Some of the other things in IntelliJ like Build Configurations and the Git integration are awful, but it's unfair to penalise Kotlin for that)

Compilation Performance

Clear win to Kotlin. It seems a bit slower to compile than Java, but Swift compilation times are more in line with C++ (i.e. Ages)

Productivity

I'd probably say Swift here but you could go either way. They honestly both feel very good, and so much of productivity is subjective and down more to the platform API's than the language itself.

Runtime performance

Both are great. While in theory Swift should be slightly faster than Objective-C and Kotlin should be slightly slower than Java, in practice for all normal app-level stuff we do like rendering UI, network requests, JSON parsing and so forth, I can't tell the difference between code written in ObjC vs Swift or Kotlin vs Java. Because they both have great interop, if you did happen to have a piece of code which actually was performance sensitive, you could just write that one small piece in the other language anyway. If you're worried about performance issues from moving to Swift or Kotlin, don't be.

Porting code

A LANDSLIDE win for Kotlin here. It's relative closeness to Java, combined with the auto-converter in Android Studio make it fairly easy to port most things. The auto-converter screws things up quite a bit, but when it goes wrong I've found the problems tend to be quite easy to fix, once you've done it a few times and learn the patterns of how it goes wrong. Swift doesn't have an auto-converter, so you need to go through your objective-C code and manually port across things line by line. For example, I ported a significant chunk of code from Java to Kotlin in about a day. That same code would have taken me at least 2 days to do ObjC->Swift, most likely 4+.

I have an Objective-C app, should I port it to Swift?

Maybe, however it will be a fair bit of work spread out over a long time, and will bring about a lot of change. Most of the changes will improve your code and make it more readable, stable and maintainable, but some will not. In particular anywhere you depended on the dynamic behaviour of Objective-C. My team and I chose to port ultimately because we like the language better - mostly for the cleaner syntax and static typing. Compared to ObjC, it's more similar to C# (which everyone on the team had prior knowledge of), so that helps too. These reasons don't hold for everyone though. Porting to Swift seems more like a long term thing - Apple is pushing the community hard towards Swift, and it is following. There will come a time (if it hasn't already) where having objective-C code means it's harder to find developers, harder to find code samples, help and documentation online, and other such things, so it makes sense to move to swift for those reasons.

I have a Java app, should I port it to Kotlin?

Yes>. To me, it seems like a no brainer. Kotlin is better than java in many many ways, but doesn't seem to have really any downsides. You (like me) may not like some of the weird things it has like Companion Object, but in my experience those are all fairly superficial and you can get past them without much worry. The auto-converter makes porting your code take a lot less time, and it's actually quite fun.

Conclusion

If I had to sum it up, it goes back to my point before that Kotlin really does feel like super nice modern Java. I like it and it's great to work with but it doesn't bring any significant new paradigms to the table.

Swift on the other hand is a significant departure Objective-C, and with Structs, ARC, and in the future the Memory ownership model stuff, seems to be moving more into the space of Rust and things like that. Don't forget that Objective-C is a dynamic language and actually has more in common with Ruby or JavaScript than you might think.

What's my preference? Superficially Kotlin and Swift are very similar.
Assuming you could somehow magically eliminate all the platform specific differences between iOS and Android - say perhaps you were writing server-side software on linux or something - I think I'd chose Swift. There's a variety of reasons, but the thing that I guess I place the most weight on is the modern features/paradigms (see above). From that point of view, Kotlin and Swift are actually very different.

Tuesday, February 09, 2016

MiniRxSwift

I wanted to provide asynchronous networking for my StockFighterApiClient library, but I had 2 problems

  • Callback-based asynchronous programming is not nice. It quickly leads to nested callback hell
  • The Reactive Framework provides a much nicer async model, and RxSwift is great. I've used it in other projects and I much prefer it to ReactiveCococa, however RxSwift is a multi-megabyte download with dozens of source files, and I want to keep the ApiClient library as self contained as possible
So, I wrote a small miniaturised version of RxSwift which only contains a few of the core operators.

RxSwift and ReactiveCocoa get bloated by UI bindings and stuff like that which are completely unnecessary for the core Rx functionality, so it's great not to have any of those

It's a single file, approx 400 lines including comments and whitespace, and you can find it here:
https://github.com/borland/StockFighterApiClient/blob/master/MiniRxSwift.swift

It is missing a few things which might end up being important, but even if those get added it will still remain a single file and I doubt it'd ever get over 1000 LOC.

While this is silly wheel re-inventing, and in a serious project I'd just use RxSwift, I found that there were some benefits that came of it.

Protocol Associated Types

It was the first time I'd used protocols with associated types in Swift before. Implementing Observable/Observer as protocols in swift was an interesting journey learning about how associated types worked, and how they are different to generics.

Overall I found associated types to be profoundly strange compared to anything I'd used before in other languages.
I can appreciate that associated types can be more powerful and flexible than generics, but I couldn't help feeling that I didn't actually want or need that extra power/flexibility, and the cost and complexity it imposes (having to create type-erased wrappers such as Apple's AnySequence, or my Observer class) was annoying.
I can't help but think that this is going to be somewhat of a pain for people as they learn swift. I can imagine trying to explain to a new developer on my team why we have to write wrapper classes to bridge between protocols and generics, and I'm pretty sure that's going to be a very confusing and difficult to grasp situation for a newbie.
At any rate, I learned a fundamentally new (to me) concept. That doesn't happen very often once you get past your first few years of programming, so it's been well worth the effort.

Learning/Refreshing Rx knowledge

At work, we've got a lot of C# code that uses the Reactive extensions for .NET. I initially learned Rx way back when it was a pre-release binary dll that Microsoft shipped (I vaguely recall) privately as a helper library in some version of Silverlight or something like that.
I learned it primarily by reading the decompiled source code using Reflector, as there wasn't any documentation or even an official download of Rx for quite some time.

This ended up being great for me, as I got a deep understanding of exactly what is going on behind the scenes for each method and task. No matter how good the documentation for something is, there's no substitute for knowing that (for example) a method takes a lock just before it does some critical thing and when it releases it.

I was only really able to do this though, because Rx back then was much smaller and simpler. The Rx of today has gone through many years of Architecting, Refactoring, Indirecting, Abstracting and Organising. While I've no doubt that it's benefitted the project overall, the downside is that everything is now very hard to find and to learn.
For example, take a look at SelectMany - It's 1739 lines of code just for that class, and to understand it you also need to know how it's base class works.
In contrast, the old original code for SelectMany (known as flatMap in languages other than C#), was a single function, and looked a lot like the one in MiniRxSwift which is entirely self contained, has no classes, and is under 40 LOC including whitespace.
The real RxSwift has taken the approach of porting from C#, so it keeps mostly the same class hierarchy and complexity as the C# implementation, and is equally hard to find your way around.

Hopefully someone one day can look at MiniRxSwift and get a better understanding of Rx

P.S.

I wrote most of this from my understanding of how Rx works. I did look at the Rx documentation, and I definitely looked at the RxSwift source code along the way - not to copy it - but to learn how they were doing things with Protocol-Associated-Types. The swift compiler produces a lot of confusing error messages if you get your generics/PAT bridging code wrong and I wouldn't have been able to do it without some reference code to learn from.

Thanks RxSwift!


Thursday, January 28, 2016

StockFighterApiClient

TL;DR

I wrote a client library in Swift for StockFighter. It's on github at https://github.com/borland/StockFighterApiClient, feel free to use it or check it out!



If you're a programmer and you haven't heard of it, I'd recommend checking out StockFighter.
It's a "programming game" wherein you have to write code to perform some task in a correct/fast/clever/etc way. In this specific instance, the goal is to write bots to perform high-frequency stock trading (well, actually pretty slow frequency trading compared to real stock markets, but much faster than a human would).

I'm midway through the third level so far, but I've found it quite interesting and challenging to think about some of the strategies for solving some of the problems.

The way it works is you write some code to connect to their cloud servers via a REST api (and/or WebSockets) and have your bot buy and sell stocks on their fake stock exchanges. Different levels have different challenges.

I'm a big fan of Swift at the moment, so I wanted to use it for stockfighter. Swift has

  • Nice syntax and a nice high level - I find swift code to be mostly similar to C#, but with less semicolons and brackets which is always great, and it's often more concise. Code is roughly about the same size as it would be in Ruby or JavaScript.
  • Decent functional programming style support - It has nice lambda functions, things like map/filter over collections are built in and you can extend existing types to add more complicated methods as needed)
  • Null safety - The compiler can enforce that things may or may not be null which is a bit weird at first, but once you get used to it is very nice. I find on average my swift code has a much higher chance of "just working on the first run" primarily due to this.
  • An exception model which I like - I always found Java's explicit checked exceptions to cause too much code bloat, especially having to declare catch blocks for multiple different exception types all over the place. At the same time, I've sometimes found the "transparent" exceptions of C# or C++ aren't as nice because often you simply won't be aware that a method could throw an exception until you find out later in a crash report. The swift model strikes a middle ground, and while it has some shortcomings too, on balance I like it better than either of the other approaches
  • Good performance - It seems to be roughly in the ballpark of C# or Java, but uses less memory and starts up faster due to lack of a "runtime" and garbage collector, which is great
Anyway, I looked online and found one existing client library - RSStockFighter, however, I wanted to write my own client library from the ground up for fun, and for practice.

Additionally RSStockFighter uses a "command object" pattern, wherein you create different kinds of objects representing each different request you might want to make, then you submit them to the server. While such a pattern offers many benefits and is probably good OO design, I find it adds friction to the programming experience and is not what I'd like to use (at least for a project the size of a stock fighter client. It might make more sense when you have an API with hundreds of methods).

Rather than this:

let order = StockFighterOrder(symbol:SF_STOCK_SYMBOL, price:95.00,qty: 100,direction:SF_OrderDirection.Buy,orderType:SF_OrderTypes.Limit.rawValue)
       
StockFighterHelper.sendStockFighterTransaction(order, success: {
    (dict:NSDictionary!) -> Void in
        self.checkOrderResponse(dict)
}, failure: {(str: String) -> Void in
        print(str)
})


I'd much rather write this:

let response = try venue.placeOrderForStock(SYMBOL, price: 9500, qty: 100, direction: .Buy)

HTTP calls in my library are synchronous, and either return a result or throw an exception, which generally makes the code shorter and clearer.

Personally I prefer asynchronous I/O, however then you have to deal with callbacks. The Reactive frameworks - RxSwift in this case - provide a much nicer model than the nested-callbacks approach, so I think if I were to provide async methods I'd use RxSwift - however that means if anyone wants to use my Api they must also take a dependency on RxSwift, so I left it out for now.

My library also provides access to the StockFighter web socket API using SocketRocket behind the scenes. I embedded a copy of SocketRocket in my github repo so there's only one thing to download, but adding third party frameworks such as SocketRocket to a project in Xcode is a bit of a pain. I've documented the process in my README, but it's still not ideal.

I didn't want to use something like CocoaPods / Carthage because they are yet another barrier to entry. I don't want to ask people to go and cruft up their system and install some magical dependency manager which is going to do who-knows-what when I could offer people a simpler "copy some files" option instead. Perhaps that's a topic for another post in future.

Anyway. Head over to github and check it out if you're interested. It's on github at https://github.com/borland/StockFighterApiClient and I'd appreciate any feedback!

Wednesday, March 25, 2015

Using ReactiveCocoa from Swift

We're trying out swift at work, and have an existing app which makes quite a bit of use of ReactiveCocoa.
Looking online, I found MVVM, Swift and ReactiveCocoa - It's all good! from Colin Eberhardt. It's a good intro, but I found I had trouble when trying to use the tricker subscribe overloads.

Without further ado, here's my own take on the extensions.
Licensing wise I declare it to be public domain, do with it as you will.
(Note: Implemented on Xcode 6.2 with Swift 1.1)


import Foundation

extension RACSignal {

    // Subscribe with an on-next block
    // Equivalent of - (RACDisposable *)subscribeNext:(void (^)(id x))nextBlock {
    func subscribe(next nextClosure:(T)->Void) -> RACDisposable {
        return self.subscribeNext { (x: AnyObject!) -> () in nextClosure(x as T) }
    }
    
    // Subscribe with an on-next and on-completed block
    // Equivalent of - (RACDisposable *)subscribeNext:(void (^)(id x))nextBlock completed:(void (^)(void))completedBlock;
    func subscribe(next nextClosure:(T)->Void, completed completedClosure:()->Void) -> RACDisposable {
        return self.subscribeNext(
            { (x: AnyObject!) -> () in nextClosure(x as T) },
            completed:{ () in completedClosure() })
    }
    
    // Subscribe with an on-next and on-error block
    // Equivalent of - (RACDisposable *)subscribeNext:(void (^)(id x))nextBlock error:(void (^)(NSError *error))errorBlock {
    func subscribe(next nextClosure:(T)->Void, error errorClosure:(NSError)->Void) -> RACDisposable {
        return self.subscribeNext(
            { (x: AnyObject!) -> () in nextClosure(x as T) },
            error:{ (x:NSError!) in errorClosure(x) })
    }
    
    // Subscribe with an on-next, on-error and on-completed block
    // Equivalent of - (RACDisposable *)subscribeNext:(void (^)(id x))nextBlock error:(void (^)(NSError *error))errorBlock completed:(void (^)(void))completedBlock;
    func subscribe(next nextClosure:(T)->Void, error errorClosure:(NSError)->Void, completed completedClosure:()->Void) -> RACDisposable {
        return self.subscribeNext(
            { (x: AnyObject!) -> () in nextClosure(x as T) },
            error:{ (x:NSError!) in errorClosure(x) },
            completed:{ () in completedClosure() })
    }
    
    // Subscribe with an on-error block
    // Equivalent of - (RACDisposable *)subscribeError:(void (^)(NSError *error))errorBlock;
    func subscribe(error errorClosure:(NSError)->Void) -> RACDisposable {
        return self.subscribeError { (x: NSError!) -> () in errorClosure(x) }
    }
    
    // Subscribe with an on-error and on-completed block
    // Equivalent of - (RACDisposable *)subscribeError:(void (^)(NSError *error))errorBlock completed:(void (^)(void))completedBlock;
    func subscribe(error errorClosure:(NSError)->Void, completed completedClosure:()->Void) -> RACDisposable {
        return self.subscribeError(
            { (x: NSError!) -> () in errorClosure(x) },
            completed:{ () in completedClosure() })
    }
}

Now, how to use it (this can be a bit unclear sometimes in swift)

To subscribe for on-next notifications


someSignal.subscribe { (arg:Type) in .... }

e.g. with an RACSignal publishing strings it would be
someSignal.subscribe { (x:String) in doSomething(x) }
or
someSignal.subscribe(
    next:{ (x:String) in 
        doSomething(x) 
    })

To subscribe for on-error notifications


someSignal.subscribe(error:{ (e) in .... })
or
someSignal.subscribe(
    error:{ (e) in 
        logError(e) 
    })


e.g. with an RACSignal publishing strings it would be
someSignal.subscribe(error:{ (e) in logError(e) }

You don't need to specify (error:NSError) as the compiler is smart enough to infer that, however you do need to specify the explicit error: parameter name, so the compiler knows this is an error handler, not an on-next handler

To subscribe for on-next and on-completed notifications


someSignal.subscribe({ (arg:Type) in .... }, completed:{ ... })

e.g. with an RACSignal publishing strings it would be
someSignal.subscribe({ (x:String) in doSomething(x) }, completed:{ allDone() })
or
someSignal.subscribe(
    next:{ (x:String) in 
        doSomething(x) 
    }, 
    completed:{ 
       allDone() 
    })


Warning If the code in your completed block (e.g. the allDone function) doesn't return void, the compiler will infer it as the return type of the completed block, and you'll get a confusing-looking Extra argument 'completed' in call error. The fix is to insert an explicit return, e.g.

someSignal.subscribe(
    next:{ (x:String) in 
        doSomething(x) 
    }, 
    completed:{ 
       allDone() 
       return
    })


To subscribe for on-next and on-error notifications


someSignal.subscribe({ (arg:Type) in .... }, error:{ (e) in ... })

e.g. with an RACSignal publishing strings it would be
someSignal.subscribe({ (x:String) in doSomething(x) }, error:{ (e) in logError(e) })
or
someSignal.subscribe(
    next:{ (x:String) in 
        doSomething(x) 
    }, 
    error:{ (e) in
       logError(e) 
    })


To subscribe for all 3 - on-next, on-error and on-completed notifications


someSignal.subscribe({ (arg:Type) in .... }, error:{ (e) in ... }, completed:{ ... })

e.g. with an RACSignal publishing strings it would be
someSignal.subscribe({ (x:String) in doSomething(x) }, error:{ (e) in logError(e) }, completed:{ allDone() })
or
someSignal.subscribe(
    next:{ (x:String) in 
        doSomething(x) 
    }, 
    error:{ (e) in
       logError(e) 
    },
    completed:{
        allDone()
    })


The warning above (sometimes you might need an explicit return in the completed block) applies here too.

To subscribe for on-error and on-completed notifications


someSignal.subscribe(error:{ (e) in ... }, completed:{ ... })

e.g. with an RACSignal publishing strings it would be
someSignal.subscribe({ error:{ (e) in logError(e) }, completed:{ allDone() })
or
someSignal.subscribe(
    error:{ (e) in
       logError(e) 
    },
    completed: {
        allDone()
    })


The warning above (sometimes you might need an explicit return in the completed block) applies here too.

Wrap-up

I hope this helps!

P.S. - if you're wondering where the "on-completed only" version is - there isn't one, because ReactiveCocoa doesn't seem to provide one for some reason. If you want that behaviour, you can subscribe with an empty on-next or on-error callback.

Monday, May 05, 2014

Codemania 2014 Presentation

I gave a presentation at Codemania 2014 titled "Understanding C++ Templates".

The abstract is as follows (posted here for posterity, as codemania will take all the 2014 details down when the 2015 conference ramps up)

Understanding C++ templates

Templates are a key feature of C++. They enable you to write safer code with less duplication and better performance. Almost all C++ programmers have encountered them, but few know them well. Orion will show you how to think about and put to use some of the more advanced things you can do with templates, and show that they're simpler than you might think.

Even if you're not a C++ developer, understanding these concepts will give you a better perspective for programming in other languages.

The source code/examples I used in the presentation are available here on Github

The slides are available on here on iCloud

Monday, November 11, 2013

Integrating an automated iOS build with a Windows Team Foundation Server build environment

My current job is a "Microsoft shop" - our source control is Microsoft's Team Foundation Server, we primarily write applications for windows using C++ and C#, and all the developers use windows workstation PC's.

We'd like to develop an iOS app, but we'd like to set it up with a repeatable, automatable build process. Simply asking the guy with the mac on his desk to compile a new build and hope it works doesn't cut it.
All our existing build processes are using Team Foundation Server's build agents and build scripts, which have some very nice properties, and we'd like to be able to queue and publish iOS builds in the same way.

The problem is that we must build iOS apps on a Mac using Xcode, but the Team Foundation Server build agent only runs on Windows

How do we bridge this gap? Using SSH from a windows build agent to a remote mac.

  • The TFS build script uses putty (specifically the command line plink application) to tell the mac to remotely do things.
  • We queue a TFS build onto one of our windows TFS build agent PC's. It basically just runs plink, captures the output and waits for it to exit.
  • We get the files from the TFS repository onto the mac via SCP - the windows TFS build agent checks everything out, then runs pscp to copy it all over to the mac
  • The mac then uses xcodebuild and xcrun to compile and package the iOS app for ad-hoc distribution
  • The windows build agent then uses pscp to copy the packaged iOS app off the mac back onto the windows build agent, which then copies it into the appropriate drop folder alongside all the other windows builds.
  • We host a basic web server to serve the iOS application's .ipa package over HTTP, and everyone installs/upgrades our app by accessing this webpage using iOS' over the air beta testing facilities.

There are a lot of pieces to this, particularly given that we do not want to put secure data such as user account passwords in source control or have them hardcoded into build scripts. Here are the details, in the order that (for me) makes the most sense.

Setting up the Mac


Install Xcode

Obviously we need to install Xcode on the mac. The easiest way is just via the Mac app store, but you can also download a DMG from the apple developer centre for offline installs.

Install Team Explorer Everywhere

I did this by unzipping microsoft's zip file into /usr/local/bin. There is likely a better/more modular way to manage this than putting everything directly in /usr/local/bin, but this works fine on my isolated build machine.

User account

In the interests of keeping the build environment clean, and repeatable (so we can set up other mac build machines easily in the future), we want all of the builds to be performed by a dedicated user account. We do not ever want to use this account to do normal day to day development. Ideally we should never log into it interactively at all, only via SSH. This helps ensure that our builds really are clean and repeatable, and that we don't end up with accidental dependencies on random files/data in a normal person's user account.

Enabling passwordless SSH logins

We need the windows build agent PC to SSH into the mac, but we don't want the TFS build scripts to have the password of the mac's build account, we want to enable passwordless logins. To do this, I followed the instructions here: http://www.tonido.com/blog/index.php/2009/02/20/ssh-without-password-using-putty/

Once this has been set up, on the mac the /Users/buildaccount/.ssh/authorized_keys file will contain the details of the ssh key, and on the windows PC there will be the matching .ppk file. We can use plink to get the mac to run various scripts, as follows

plink -ssh -batch -l buildaccount -i buildaccountkey.ppk mac01.domain.local /Users/buildaccount/build_script.sh

Enabling our non-admin account to login using SSH

Apple's default SSH security settings are such that only users with Admin rights can login via SSH (At least this is the case on OSX 10.9, which I am using). We want our build account to be a non-admin user, so we'll have to edit the access control list that controls who can access ssh, and add our build user to it.

sudo dseditgroup -o edit -n . -a buildaccount -t user com.apple.access_ssh

Setting up the build process


Certificates and Provisioning Profiles

As we're setting up for Ad-hoc deployment of our app, we need an iOS Distribution Certificate, and an Ad-hoc provisioning profile. You generate both of these via the Apple Developer website's Member Centre. When building through the Xcode UI, it handles most of this for you, but as we want to be building via the command line, and via SSH into a clean user account, we have a few more hoops to jump through.

Putting the certificates in a custom keychain

By default Xcode and it's command line tools will look for your distribution certificate in the user default keychain (the login keychain). As we want our build account to be "clean", we don't want to have to put them in the build account's login keychain. To resolve this, we can create a custom keychain, and put the certificates/provisioning profile keys in there.

We can then decide to either check this custom keychain file into source control, or put it in some other special location.

I'm assuming that you've already created and loaded/installed a distribution certificate, and an ad-hoc provisioning profile.

  1. From your normal user account, run Keychain Access
  2. Right-click on the list of keychains in the top-left, and create a new keychain. Give it a meaningful filename and store it somewhere you can find later.
  3. From your login keychain, hold the option key (to copy) and drag your iPhone Distribution certificate, and the Ad-hoc distribution private key.

Using this custom keychain in the build script

To get the Xcode command line tools to use this custom keychain file, add the following before you invoke xcodebuild

keychain_file="$SCRIPTPATH/iOSCustomBuild.keychain"
keychain_pass=secretpassword
security list-keychains -s "$keychain_file" ~/Library/Keychains/login.keychain  # put the iOS keychain in ahead of the login keychain
security unlock-keychain -p "$keychain_pass" "$keychain_file"

The security list-keychains -s command sets the search order, telling the system first to look in our custom keychain, followed by the default login keychain. This command is persistent - I haven't worried about resetting it after our script completes, but you may want to

The security unlock-keychain command is required because keychains are locked by default when code is run in a remote SSH session. We must issue security unlock-keychain or else xcodebuild will not be able to read the keychain. This is another reason to use a custom keychain file - if we were using the user's login keychain, we would be required to hard code the user account's password into our build scripts.

Compiling and packaging the app

To build our iOS app, we'll need to run xcodebuild, which is xcode's command line build tool. This requires a number of flags, which we will create variables for and then re-use. Here's mine:

# hack to get the full path to the current directory
pushd `dirname $0` > /dev/null
SCRIPTPATH=`pwd`
popd > /dev/null

application_name=MyiOSApp # our app name - should correspond to MyiOSApp.xcodeproj
sdk="iphoneos7.0" # which version of iOS are we targeting

# Name of the distribution certificate. Get this by downloading the certificate from 
# the apple developer center, installing it, and then viewing it's name in keychain
codesign="iPhone Distribution: My Name (AAA12345ZZ)"

# build the project (must sign as xcode requires signing for all non-simulator bulds)
# CONFIGURATION_BUILD_DIR is only required for cordova/phonegap projects.
xcodebuild -project "$SCRIPTPATH/$application_name.xcodeproj" -target $application_name -configuration Release -sdk $sdk clean build CODE_SIGN_IDENTITY="$codesign" CONFIGURATION_BUILD_DIR="$SCRIPTPATH/build"

This only gets us halfway - xcodebuild will produce a .app package (a directory). This doesn't have the provisioning profile embedded in it, and we also need to package it up as a .ipa file to distribute it via the ad-hoc mechanisms. To do this step, we'll need to run xcrun. Here's my part of the script to do that:

# Get this by downloading it from the apple developer center
provisioning_profile_file="$SCRIPTPATH/My_Ad_Hoc_Provisioning_Profile.mobileprovision"
provisioning_profile_name="My Ad Hoc Provisioning Profile" # get this from the apple developer center when you download the file

# install the provisioning profile so xcode can use it 
provisioning_profile_uuid=`grep UUID -A1 -a "$provisioning_profile_file" | grep -o "[-A-Z0-9]\{36\}"`
cp "$provisioning_profile_file" ~/Library/MobileDevice/Provisioning\ Profiles/$provisioning_profile_uuid.mobileprovision
 
# this is where xcode will drop it's output, as a .app package
build_dir="$SCRIPTPATH/build"

# this is where we want the created .ipa file to be put
drop_dir="$SCRIPTPATH"

# package it and embed the provisioning profile (must re-sign as packaging alters the app)
/usr/bin/xcrun -sdk $sdk PackageApplication -v "${build_dir}/${application_name}.app" -o "${drop_dir}/${application_name}.ipa" --sign "$codesign" --embed "$provisioning_profile_file"

I chose to simply check my provisioning profile file into source control.

Also note that we have the extra step of "installing" the provisioning profile. This is because we're trying to run under a clean account. If we were running as a normal user account where someone had manually run Xcode, Xcode would have put the provisioning profile into the ~/Library/MobileDevice/Provisioning Profiles directory already for us and we wouldn't need to do this step.

The full build script


keychain_file="$SCRIPTPATH/iOSCustomBuild.keychain"
keychain_pass=secretpassword
security list-keychains -s "$keychain_file" ~/Library/Keychains/login.keychain  # put the iOS keychain in ahead of the login keychain
security unlock-keychain -p "$keychain_pass" "$keychain_file"

# hack to get the full path to the current directory
pushd `dirname $0` > /dev/null
SCRIPTPATH=`pwd`
popd > /dev/null

application_name=MyiOSApp # our app name - should correspond to MyiOSApp.xcodeproj
sdk="iphoneos7.0" # which version of iOS are we targeting

# Name of the distribution certificate. Get this by downloading the certificate from 
# the apple developer center, installing it, and then viewing it's name in keychain
codesign="iPhone Distribution: My Name (AAA12345ZZ)"

# build the project (must sign as xcode requires signing for all non-simulator bulds)
# CONFIGURATION_BUILD_DIR is only required for cordova/phonegap projects.
xcodebuild -project "$SCRIPTPATH/$application_name.xcodeproj" -target $application_name -configuration Release -sdk $sdk clean build CODE_SIGN_IDENTITY="$codesign" CONFIGURATION_BUILD_DIR="$SCRIPTPATH/build"

# Get this by downloading it from the apple developer center
provisioning_profile_file="$SCRIPTPATH/My_Ad_Hoc_Provisioning_Profile.mobileprovision"
provisioning_profile_name="My Ad Hoc Provisioning Profile" # get this from the apple developer center when you download the file

# install the provisioning profile so xcode can use it 
provisioning_profile_uuid=`grep UUID -A1 -a "$provisioning_profile_file" | grep -o "[-A-Z0-9]\{36\}"`
cp "$provisioning_profile_file" ~/Library/MobileDevice/Provisioning\ Profiles/$provisioning_profile_uuid.mobileprovision
 
# this is where xcode will drop it's output, as a .app package
build_dir="$SCRIPTPATH/build"

# this is where we want the created .ipa file to be put
drop_dir="$SCRIPTPATH"

# package it and embed the provisioning profile (must re-sign as packaging alters the app)
/usr/bin/xcrun -sdk $sdk PackageApplication -v "${build_dir}/${application_name}.app" -o "${drop_dir}/${application_name}.ipa" --sign "$codesign" --embed "$provisioning_profile_file"

Putting it all together

All we need to do now is create TFS build script which Exec's plink and pscp and asks the mac to run the various .sh scripts which do all the work. Here's some snippets which you could use


<PropertyGroup>
    <!-- general -->
    <IpaFileName>MyiOSApp.ipa</IpaFileName>
    
    <!--File locations on the windows build machine-->
    <Plink>pathtoPLINK.EXE</Plink>
    <Pscp>pathtoPSCP.EXE</Pscp>
    
    <!--SSH connection info-->
    <SshHost>mac.domain.local</SshHost>
    <SshKey>buildaccountkey.ppk</SshKey>
    <SshUser>buildaccount</SshUser>

    <!--File locations on the mac-->
    <RemoteiOSBuildPath>/Users/buildaccount/iOSBuild</RemoteiOSBuildPath>
    <RemoteBuildScriptPath>$(RemoteiOSBuildPath)/build.sh</RemoteBuildScriptPath>
    <RemoteIpaFilePath>$(RemoteiOSBuildPath)/$(IpaFileName)</RemoteIpaFilePath>
</PropertyGroup>

...

<!--this "echo y | exit" causes plink/putty to cache the remote host key in the registry for subsequent operations.-->
<Exec command="echo y | &quot;$(Plink)&quot; -ssh -l $(SshUser) -i $(SshKey) $(SshHost) exit"/>

<!--Wipe any old files-->
<Exec command="&quot;$(Plink)&quot; -ssh -batch -l $(SshUser) -i $(SshKey) $(SshHost) rm -rf $(RemoteiOSBuildPath)" />
<Exec command="&quot;$(Plink)&quot; -ssh -batch -l $(SshUser) -i $(SshKey) $(SshHost) mkdir -p $(RemoteiOSBuildPath)" />

<!-- copy the source over to the mac -->
<Exec command="&quot;$(Pscp)&quot; -sftp -batch -r -i $(SshKey) -l $(SshUser) &quot;$(SolutionRoot)*&quot; $(SshHost):$(RemoteiOSBuildPath)" />

<!--run the build script-->
<Exec command="&quot;$(Plink)&quot; -ssh -batch -l $(SshUser) -i $(SshKey) $(SshHost) chmod +x $(RemoteBuildScriptPath)"/>
<Exec command="&quot;$(Plink)&quot; -ssh -batch -l $(SshUser) -i $(SshKey) $(SshHost) $(RemoteBuildScriptPath)"/>

<!-- copy the packaged ipa file back -->
<Exec command="&quot;$(Pscp)&quot; -sftp -batch -i $(SshKey) -l $(SshUser) $(SshHost):$(RemoteIpaFilePath) ." />

Wednesday, October 02, 2013

Programmatically controlling Hyper-V Server 2012 R2 virtual machines from C#

Recently I've wanted to remote control some virtual machines on a Hyper-V server in aid of automated testing.
I've got a server set up running Hyper-V Server 2012 R2, so the code samples in this are likely to work against Server 2012 non-R2, but may not work against Server 2008.

All the virtual machines start off at a known clean snapshot, and have a startup script which runs on boot that goes and asks a central database for a testing job to execute. So, for our system to work, we need to accomplish the following:
  1. Roll back a VM to the last known snapshot / checkpoint
  2. Power it on
There are several other things we need to do for this to work at all, which are:
  1. Connect to the Hyper-V server (this includes authentication)
  2. List out or otherwise ask the server about it's VM's so that we can rollback the correct one

To achieve thisk I'm using Hyper-V's WMI provider (V2). I don't really know much about WMI, so these code samples are just things I've hacked together. They are NOT production quality and they don't handle errors well or anything else. Please use them as guidance, not for copy/pasting.

Pre-requisites

Using WMI from C# is done by the classes in the System.Management namespace. To access this you'll want using System.Management at the top of your C# file, as well as a reference to the System.Management assembly.

Connecting and Logging on


To do this we need to create a ManagementScope object set to use the appropriate server and using the Hyper-V virtualization v2 namespace, and we also need to supply the username and password of a windows account that has privileges to administer the Hyper-V server. I did it like this:

var connectionOptions = new ConnectionOptions(
    @"en-US",
    @"domain\user",
    @"password",
    null,
    ImpersonationLevel.Impersonate, // I don't know if this is correct, but it worked for me
    AuthenticationLevel.Default,
    false,
    null,
    TimeSpan.FromSeconds(5);

var scope = new ManagementScope(new ManagementPath { 
    Server = "hostnameOrIpAddress", 
    NamespacePath = @"root\virtualization\v2" }, connectionOptions);
scope.Connect();

Note: Most of the other documentation or sample code I found refers to the root\virtualization namespace. This didn't work at all for me in Server 2012 R2, and I had to use dotPeek to decompile the Hyper-V powershell commandlets to figure out to put \v2 on the end. Perhaps the non-v2 one is for Server 2008?

Note: If your PC and the target server are on the same domain, and your windows user account has privileges to administer the remote server, You don't need the ConnectionOptions object at all. WMI will use windows authentication, and it will magically work:

Listing out the VM's and finding the one we want

Virtual machines in Hyper-V get exposed via the Msvm_ComputerSystem WMI class. In order to list them out, we simply ask WMI to give us all the objects of that class in the virtualization namespace. To do this, I'm going to create two helper extension methods, that we'll use from hereon:

public static class WmiExtensionMethods
{
    public static ManagementObject GetObject(this ManagementScope scope, string serviceName)
    {
        return GetObjects(scope, serviceName).FirstOrDefault();
    }
    
    public static IEnumerable<ManagementObject> GetObjects(this ManagementScope scope, string serviceName)
    {
        return new ManagementClass(scope, new ManagementPath(serviceName), null)
            .GetInstances()
            .OfType<ManagementObject>();
    }
}

It turns out that the Host PC is also exposed via Msvm_ComputerSystem, so we need to filter out things that are not virtual machines. This helper method will return a list of all the virtual machines. Note: I like extension methods, so I'm using them a lot here:

public static IEnumerable<ManagementObject> GetVirtualMachines(this ManagementScope scope)
{
    return scope.GetObjects("Msvm_ComputerSystem").Where(x => "Virtual Machine" == (string)x["Caption"]);
}

You can use it to get a specific virtual machine as follows:

var vm = scope.GetVirtualMachines().First(vm => vm["ElementName"] as string == "myvmname");

Rolling the VM back to it's latest snapshot / checkpoint

In order to roll a Hyper-V VM back to a snapshot, we need to get a reference to the snapshot object itself.

There are ways to simply list all the snapshots for each VM, but there is also a special Msvm_MostCurrentSnapshotInBranch class which represents the "latest" snapshot. We can use it to create a helper method as follows:

public static ManagementObject GetLastSnapshot(this ManagementObject virtualMachine)
{
    return virtualMachine.GetRelated(
        "Msvm_VirtualSystemSettingData",
        "Msvm_MostCurrentSnapshotInBranch",
        null,
        null,
        "Dependent",
        "Antecedent",
        false,
        null).OfType<ManagementObject>().FirstOrDefault();
}

And use it like this:

var snapshot = vm.GetLastSnapshot();

Now, to actually roll the VM back, we need to call the ApplySnapshot method on the Msvm_VirtualSystemSnapshotService class.
Note: Logically I thought that the snapshot methods should be on the Virtual Machine object, but Hyper-V puts them all in their own service for some reason. There is also only one global Snapshot service - not a service per VM. I've no idea why they've designed it this way.

We can create a helper method:

public static uint ApplySnapshot(this ManagementScope scope, ManagementObject snapshot)
{
    var snapshotService = scope.GetObject("Msvm_VirtualSystemSnapshotService");

    var inParameters = snapshotService.GetMethodParameters("ApplySnapshot");
    inParameters["Snapshot"] = snapshot.Path.Path;
    var outParameters = snapshotService.InvokeMethod("ApplySnapshot", inParameters, null);
    return (uint)outParameters["ReturnValue"];
}

And use it like this:

scope.ApplySnapshot(snapshot);

When I execute this with valid parameters, the VM applied it's snapshot, and I always got a return value of 4096. According to the documentation, this indicates that there's a Job in progress to asynchronously track the actual snapshot applying and determine the final success or failure. We could fetch the job out of outParameters["Job"] and use it to determine when the apply completes, but I'm not going to worry about that here. Refer to the ApplySnapshot MSDN page for other possible return codes.

Note: If the VM is not powered off, you are likely to find the ApplySnapshot call fails. You must power the VM off (and wait for the Power Off job to complete) first.

Powering on the VM to boot it up


Turning on the VM is done by the RequestStateChange method on the Msvm_ComputerSystem class. We already have the Msvm_ComputerSystem object representing the virtual machine we found earlier, so we can create a helper method and enumeration like this:

public enum VmRequestedState : ushort
{
    Other = 1,
    Running = 2,
    Off = 3,
    Saved = 6,
    Paused = 9,
    Starting = 10,
    Reset = 11,
    Saving = 32773,
    Pausing = 32776,
    Resuming = 32777,
    FastSaved = 32779,
    FastSaving = 32780,
}

public static uint RequestStateChange(this ManagementObject virtualMachine, VmRequestedState targetState)
{
    var managementService = virtualMachine.Scope.GetObject("Msvm_VirtualSystemManagementService");

    var inParameters = managementService.GetMethodParameters("RequestStateChange");
    inParameters["RequestedState"] = (object)targetState;
    var outParameters = virtualMachine.InvokeMethod("RequestStateChange", inParameters, null);
    return (uint)outParameters["ReturnValue"];
}

And use it like this:

vm.RequestStateChange(VmRequestedState.Running);

As for ApplySnapshot, when things work, the return value is usually 4096, indicating there is a Job to asynchronously track the progress of the operation.

Note: Although we invoke the method on the Msvm_ComputerSystem object, we need to get the method parameters by asking the Msvm_VirtualSystemManagementService object (which represents the host server) instead. I've no idea why.

Final fixups


ApplySnapshot will fail if the virtual machine is running. To turn it off, we can simply call vm.RequestStateChange(VmRequestedState.Off); and wait a bit for Job to complete.

RequestStateChange will fail if the state doesn't make sense. For example, if you try and turn the vm Off when it's already Off, the method will fail. You can check the current state of a Vm by reading it's EnabledState property. Valid values for EnabledState are documented with the Msvm_ComputerSystem class. I created an enum, and used it as follows:

public enum VmState : ushort
{
    Unknown = 0,
    Other,
    Running, // Enabled
    Off, // Disabled
    ShuttingDown,
    NotApplicable,
    OnButOffline,
    InTest,
    Deferred,
    Quiesce,
    Starting
}

if ((VmState)vm["EnabledState"] != VmState.Off)
{
    vm.RequestStateChange(VmRequestedState.Off); // needs to be off to apply snapshot
    Thread.Sleep(2000); // todo wait for the state change properly
}

You can do many more things by using other methods and classes from the Hyper-V WMI API. Hopefully this gives you a decent starting point.

P.S. The Hyper-V powershell commandlets are all implemented on top of this WMI Api. Using a tool like .NET reflector or dotPeek is an interesting way to see how Microsoft calls the WMI API.