Bright Inventions

PureLayout vs NSLayoutAnchor - Great confrontation

Last week I’ve made basic comparison between two libraries that will help you layout your interfaces - PureLayout and SnapKit. You can find this comparison here. Today I’d lake to take the same examples and see how they work with NSLayoutAnchor. NSLayoutAnchor is available to us since iOS 9 and provides us with a new way of creating your constraints. If you do not like creating NSLayoutConstraints using it’s initializers or visual format, and do not want any external dependencies for your layout, then NSLayoutAnchor is for you!

PureLayout vs SnapKit - Great confrontation

At first, let me clear something out. I’m heavy PureLayout user. I’ve been creating my UIs in code for some time now and it’s not looking like I’m going back to Interface Builder any time soon. I’m not saying IB is bad, but it’s just not the way that I do things. I started working with PureLayout back in Objective-C days and I kept on using it in Swift as well. However, recently I’ve been interested in a framework called SnapKit, that offers a nice “swifty” way of building views in your application. This post is my way of getting into SnapKit. Below, you can find some UI examples, that I’ve written using both PureLayout and SnapKit.

ReactiveSwift - Manage your memory!

Memory management is a pretty important issue when talking about any kind of system. You can’t pretend that your resources are unlimited, and give them out no matter what. When working with ReactiveSwift it’s really easy to fall into the pit of wasted resources if you don’t follow simple rules.

ReactiveCocoa UI bindings with Rex

Today, we will take a closer look at Rex - ReactiveCocoa extensions. I find Rex pretty helpful when working with ReactiveCocoa, especially creating UI bindings.

ReactiveCocoa 4 - CocoaActions

CocoaAction is a wrapper around Action type that is available in ReactiveCocoa. (Here you can read more about Action). We use CocoaAction to bind our Actions to GUI controls. Let’s see a quick example of how it works.

ReactiveCocoa 4 - Events

Understanding signal events in ReactiveCocoa is a must. We can’t effectively use signals and signal producers if we don’t know what will happen after certain event is received. We distinguish two kinds of events that you can send through signals - terminating and non-terminating. There are three kinds of terminating events: Failed, Interrupted, Completed, and one non-terminating - Next.

Open source by default

Using open source code in projects is a common thing. I do it. Most of us do. But what is “open source” by default? Well, I’ve heard about this for the first time at MCE Conf 2016 - “Open by default” panel. It’s an idea to make software open by default and close it only if needed. There are many reasons to close it of course, but sometimes we do it unnecessarily.