Skip to main content

View decoration in Swift

View decoration in Swift

This article is for developers, iOS enthusiasts, and anyone who encountered the challenge of ensuring visual coherence in a mobile app.
Let me explain. At times different types of elements in your mobile app have the same look and feel, right? They are coherent. Often, achieving this comes at a price: you end up writing many lines of repetitive code, wishing this wouldn’t make everything less maintainable and difficult to change if need be.
One possible solution: constants.
Grouped and used correctly, constants might solve inconsistency issues, but maintainability and code simplicity won’t increase significantly. There must be another way …
While trying to find a simple, elegant solution to the problem, I came up with an interface which defines a single point of entry for customizing the UIKit element throughout the application. The concept is called ViewDecorator.
The core of the pattern is defined with the following protocol, describing how a decorator object should behave:
It has a single method, called decorate and takes a single parameter, for the component instance which we intend to decorate.
To make the decoration easier, I created an extension over UIView. With this extension a list of decorators can be passed to the view, without having to call decorate multiple times over it.
Let’s see this in action.
In the following example a decorator was defined to apply corner radius (CornerRadiusViewDecorator) and another to give a mild drop shadow (ShadowViewDecorator) to our views.
Now let’s say we want to apply both decorators at the same time in our app to achieve a card like appearance. We can use composition and define a new object with the same protocol.
We can use these structs to decorate different kinds of UIKit elements:
UIImageView without shadow (left), UIButton subclasses (middle), UIView (right)
By keeping the look and feel contained in these separator objects, maintainability and readability increases, the lines of repetitive code decreases. Imagine how easy is to modify the style of your components in case of a rebranding. 😄
You might face an issue while trying to customize a specific UIView subclass attribute since the protocol takes a specific UIView type.
One possible solution might be to cast the view instance to the expected type inside the decorate(_ view: UIView) but that would mess up the single responsibility principle and make it behave differently with different kinds of instances.
Associated Types to the rescue!
Let’s see how the decorator object changes:
Quite neat, right?
I’d be happy to hear your opinion about this solution and interesting use cases I might not have thought of.
You can also head over to my blog for further articles.

Comments

Post a Comment

Popular posts from this blog

Swift GCD part 1: Thread safe singletons

Preview Singletons are entities, referenced to the same instance of a class from everywhere in your code. It doesn't matter if you like them or not, you will definitely meet them, so it's better to understand how they work. Constructing and handling a set of data doesn't seem to be a big challenge at first glance. The problems appear when you try to optimise the user experience with background work and your app starts acting weird. ??‍♂️ After decades of watching your display mostly with a blank face, you finally realize that your data isn't handled consistently by the manager because you're accessing it (running tasks on it) from multiple threads at the same time. So you really do have to deal with making your singletons thread safe. This article series is dedicated to thread handling using Swift. In the first part below you will get a comprehensive insight into som...
Post a Comment
Read more

Thread safe singleton’s in Swift

What are singletons? — Singleton is design patterns which says that there should be only one instance of the class for the lifetime of the application. One the best example of Singleton is AppDelegate . How to write a singleton class ? class DefaultDict{ private var dict:[String:Any] = [:] public static let sharedManager = DefaultDict() private init(){ } public func set(value:Any,key:String){ dict[key] = value } public func object(key:String) -> Any?{ dict[key] } public func reset(){ dict.removeAll() } }   Testing singleton class under concurrent circumstances. We are going to write an example where we will set values in dict from various threads and even try to access some with different threads. When we do this we will encounter a crash. If you look closely it will be because of race condition and the crash will be on line set(value:Any,key:String) . class ViewController: UIViewController { ...
Post a Comment
Read more

Frame vs Bounds in iOS

This article is a repost of an answer I wrote on Stack Overflow . Short description frame = a view’s location and size using the parent view’s coordinate system ( important for placing the view in the parent) bounds = a view’s location and size using its own coordinate system (important for placing the view’s content or subviews within itself) Details To help me remember frame , I think of a picture frame on a wall . The picture frame is like the border of a view. I can hang the picture anywhere I want on the wall. In the same way, I can put a view anywhere I want inside a parent view (also called a superview). The parent view is like the wall. The origin of the coordinate system in iOS is the top left. We can put our view at the origin of the superview by setting the view frame’s x-y coordinates to (0, 0), which is like hanging our picture in the very top left corner of the wall. To move it right, increase x, to move it down increase y. To help me remember bound...
Post a Comment
Read more