You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A 'alternative' way to print out dictionaries and arrays in Swift if you don't like the default output
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Example of displaying an NSDate in different timezones
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A protocol I like to use in my apps anywhere something like NSUserDefaults or KeyChain is normally used... allows for easy swapping of implementation. Also provided is StringDictionary() which can be used when testing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
UIControl.swift - Adds a closure based target/action support to all UIControl based components, including basic lifecycle handling
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
UIView.move(_:to) concept - a thought about a what a 'swifty' api might look like
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Don't let your UIViewController think for itself...
Don't let your UIViewController think for itself...
Last time I showed you one strategy for trimming the fat from our view controller by seperating out protocols. In part 2 of this 3 part series we are going to use an architecture known as MVVM to dumb down our view controller. View controllers are usually filled with business rules, this is a problem for a number of reasons, two of which being:
It makes the code harder to reason about; let the view controller worry about appearance and the business objects worry about the logic, we don't want them thinking for themselves ;)
It makes your view controller bloated; business rules don't belong in your view controller
MVVM ?
MVVM stands for Model View ViewModel and is just a way of describing how to break up your interface, business rules and data so that they flow together in a logical, but seperated, way.
I hate to say it but our view controllers have gotten fat, and it's our fault! We feed them protocol after protocol, business rule after business rule. They don't know any better and they just gobble them all up...
This will be a 3 part "Tune up your table view" series in which we will take an old fat view controller, slim it down with some refactoring, freshen it up with some MVVM and then make it fly with some better asynchronous operation management!
In part 1 using refactoring and a couple of Interface Builder tricks hopefully I can provide some motivation to start your journey towards getting your view controllers back in fighting shape!
The current state of things...
UITableViews are pretty integral to most iOS apps so I'm going to use it as an example of how to change a 'fat' view controller into a 'slim' one.
Welcome back for the conclusion of this 3 part series! In part 1 we learnt how to slim down our view controllers to a manageable size. In part 2 we learnt how to strip out all the non-ui related logic. This time we are going to focus solely on the UITableView and how we can properly handle multiple asynchronous operations in its cells for maximum performance!
As always we will be starting with our project from last time.
What's making our table's scrolling so bad?
Our current implementation is very bad... our UITableViewCells are performing an expensive operation, and on the main thread no less!
The following code is currently in the setup method of our cell: