Better Architecture in iOS: Breaking down Massive View Controller using SOLID & MVP

MVC; the age old architectural pattern; has been trusted by developers around the world to separate responsibilities of a software program regardless of language and platform. Anyone working in iOS applications starts with this pattern and gets comfortable with it in a really short amount of time. But an iOS developer who has been in the industry for a while would be at least getting started to familiarize with the notorious Massive View Controller paradigm by now. This problem has been here like always, and there are a lot of great articles to understand the problem and how to reduce them. I’ll list some of them which I found really helpful at the end of this blog post.

Memory management in Swift: Strong Reference & Retain Cycle

Swift uses ARC (Automatic Reference Counting) similar to Objective-C to track and manage application memory. In most cases, we don’t need to bother about memory management by ourselves, the swift compiler will take care of it. But there are some cases where we need to deal with it  by ourselves. I am going to discuss some of the common cases from those.

Dealing with Telescopic Constructors: Anti-Pattern

We all have been through situations, where we had to create classes with multiple constructors or constructor with a lot of dependencies (parameters). These classes tend to get bloated quickly with the over used constructor methods and too many parameters and starts messing with the default properties values. Whenever you find yourself into this situation you; my friend; have been trapped by a notorious anti-pattern called Telescopic Constructors or, Telescopic Initializers. The initial intention of this pattern was to simplify the process of working with classes with a lot of initializer parameters.

Singletons: Pattern or Anti-pattern?

While talking about design patterns, most developers have fumbled upon this one; especially cocoa developers (both iOS and Mac application developers). Singletons are the most common design pattern you’ll come to see in Cocoa and CocoaTouch frameworks. They are literally everywhere; i.e. UIApplication.shared, UIScreen.main, NotificationCenter.default, UserDefaults.standard, FileManager.default, URLSession.shared, SKPaymentQueue.default() and many more. So, what are Singletons? And why are they so special?

Introduction to Strategy Pattern

In real life software development one particular challenge we developers constantly face is requirement changes. Anyone who is in the software business game knows how frequently and drastically software specification can change in any time. For this reason, in software engineering only one thing is considered as constant: CHANGE!

In object oriented world, we have some nice ways to deal with this, i.e. design patterns to the rescue. There are lots and lots of design patterns out there to help us, the developers. Amongst them the most common and widely used one is known as Strategy Pattern. Any developer with a few years of experience under his/her belt uses this quite frequently (sometimes even without knowing they are using it!).

In this post I am going to try to create a scenario, which we can solve using strategy pattern.

UITextView similar to rounded UITextField with dynamic height

Ever wanted to use an UITextView that looks like a rounded UITextFiled? Also, wished it will grow it’s height as you type your text? Well, you are in luck! Here is the swift file you will need.

Strong vs Weak Reference in Cocoa

In iOS we always end up defining our instance variables as  @property (strong) or @property(weak). But what does strong and weak mean, and when to use which one?

In cocoa, an objects memory is managed via a system called retain count. When an object is initialized, its retain count is increased by 1 from zero. And each time it is strongly referenced by someone, the retain count keeps increasing by 1. In ARC (a compile time feature of Apple’s version of automated memory management, acronym of Automatic Reference Counting), it only frees up memory for objects when there are zero strong references to them, or simply put, the retain count is zero.

Delegation in iOS and Cocoa: Decorator Pattern

Using delegates in iOS and Cocoa is a very basic and fundamental part and we use them quite frequently in our codes. As like in business, cocoa uses delegates as a formal way to pass data(job) from one object(client) to another(vendor). In business, you want to do make something but you need raw materials to do so. So you ask the supplier to give you raw materials and you sign a contract for that. Same thing goes in cocoa, a class that wants to perform a task that depends on the response of another class acts as the delegate to the later. The first class wants to be the vendor of the later one by signing a contract called protocols (as defined in cocoa).

SHViewPager: Android like view pager control for iOS Version 2.0 finally!

It has been almost or, more than 2 years I had created this controller called SHViewPager. And to my utmost surprise a lot of people actually got benefited from it. Some of them requested for the support for screen orientation and iPad. I was a bit busy (actually lazy! sorry guys, truly!)  to keep the request. Finally after a long wait, I was thinking, why am I not doing it?

Creating your own COCOAPOD

Now a days it is fairly common to use CocoaPods to your project as the dependency manager for your iOS and MacOs projects. I have been using it for quite some time now; and to my utter delight, oh boy, I am glad I got to know how to use this masterpiece!

Now to a fairly uncommon scenario, what if you want to create your own pod?