Going back to the roots

As Roy Marmelstein said in his recent presentation at dotSwift - "We love to be excited". Can not agree more. When we read a blog post that describes the concept or architectural pattern that is somewhat new for us and feels exciting we tend to accept it as something good. We can go really far away this rote and sometimes we don't notice that we already have all the tools to solve the problems they address. For iOS developers this tool is a framework that we inevitably use every day - UIKit. That's what I was thinking about »

Freehand drawing

This post is a part of the series about shapes recognition. This post is also available as a part of a playground. Naive implementation of rendering user's freehand drawing is strait forward. We need to listen to touch events from view and construct the path appending lines to each subsequent point. public class LineDrawing: Drawing { public var canvas: DrawableView? public var path = UIBezierPath() public init() {} public func touchesBegan(at point: CGPoint) { path.removeAllPoints() path.moveToPoint(point) } public func touchesMoved(to point: CGPoint) { path.addLineToPoint(point) } public func touchesEnded(at point: CGPoint) { path.addLineToPoint(point) } public func touchesCancelled(at point: CGPoint) »

Intermediate action segues

Storyboards segues are very cool. They are very easy yet powerful. They help to incapsulate presentation logic and move it out from view controllers. And adaptive segues are state of the art. There is only one thing (almost) left if view controller - managing segue performance using those two commonly used methods: func shouldPerformSegueWithIdentifier(identifier: String, sender: AnyObject?) -> Bool func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) And those methods are the place where we usually screw up everything with our custom logic based on tons of if or switch statements. Then we introduce different routers, coordinators and God knows »

View controller thinning. Behaviors and Interface Builder.

In previous post I showed how you can move some presentation logic from view controller to view. Now view controller is responsible only for business logic, in this case making login request and handling its result. But now you would say: "You just moved presentation logic from controller to view. Now you have Massive View!" And you will be right. Though view is a perfect place for presentation logic that leads to that view should know everything about its subviews and it will probably change when we change something in its subviews. So in this post I will »

View themes

In my previous post you could see that I've used ColorTheme and ThemedView protocol to easily customize view appearance. Though that solution works I was not satisfied with it from very beginning. Here I try to find another solution. What I really didn't like about my that solution was a check of tag type (if let tag = tag as? FormTextField.ThemeColorTag). Usually I try to avoid any kind of type checking. But here I have nothing to do but to check the type of tag. The problem is that I tried to define some base protocol for color them. That »