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.
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.
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.
Using delegates in iOS and Cocoa is a very basic and fundamental part and we use them very frequently in our codes. As like in business, cocoa uses delegates as a formal way to pass work/data from one object to another one. 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 goes in cocoa, a class that wants to perform a task that depends on the response of another class acts asthe delegate to the later. The first class wants to be the contractor of the later one by signing a contract called protocols (as defined in cocoa).
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?
Ever felt the need to use a two dimensional array in you iOS project? Well, I have. So here is what I had done:
- Created a NSObject subclass.
- Taken two private NSMutableArray instances, one for row and one for column.
- Created a nested for loop to traverse those arrays, and fill them with NSNull objects.
- Created a method to insert value/object on the [row][column] index.
So this is fairly easy and straightforward. But wouldn’t it be nicer if you didn’t have to do all these steps and figure out how to write those monotonous codes all by yourself?
My good friend, I have good news for you! I have created a simple CocoaPod to minimize your task!
We all know the three basic principles of OOP: Encapsulation, Inheritance and Polymorphism. And there is also this fourth principle: Data Abstraction; though it’s not always mentioned as a standalone principle, as it is closely tied with encapsulation. Today I am going to discuss a simple case to display the power and necessity of Inheritance.
Let’s assume a scenario: you are working on an application, which has to perform a server call asynchronously and has no direct impact on the UI. But when the server returns a response, you have to make some modification to your application regardless of the present UI.