| /** | |
| * Helvetica Neue Normal (No Stretch) | |
| */ | |
| /* Helvetica Neue Black Font Stack */ | |
| .{font-family: "HelveticaNeueBlack", "HelveticaNeue-Black", "Helvetica Neue Black", "HelveticaNeue", "Helvetica Neue", 'TeXGyreHerosBold', "Arial Black", sans-serif; font-weight:800; font-stretch:normal;} | |
| /* Helvetica Neue Heavy Font Stack */ | |
| .{font-family: "HelveticaNeueHeavy", "HelveticaNeue-Heavy", "Helvetica Neue Heavy", "HelveticaNeue", "Helvetica Neue", 'TeXGyreHerosBold', "Arial Black", sans-serif; font-weight:700; font-stretch:normal;} |
On the Refinery29 Mobile Web Team, codenamed "Bicycle", all of our unit tests are written using Jasmine, an awesome BDD library written by Pivotal Labs. We recently switched how we set up data for tests from declaring and assigning to closures, to assigning properties to each test case's this object, and we've seen some awesome benefits from doing such.
Up until recently, a typical unit test for us looked something like this:
describe('views.Card', function() {
When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com, example2.com, and example1.com/images on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers
| /** | |
| * The following preprocessor macros can be used to adopt the new nullability annotations and generics | |
| * features available in Xcode 7, while maintaining backwards compatibility with earlier versions of | |
| * Xcode that do not support these features. | |
| */ | |
| #if __has_feature(nullability) | |
| # define __ASSUME_NONNULL_BEGIN NS_ASSUME_NONNULL_BEGIN | |
| # define __ASSUME_NONNULL_END NS_ASSUME_NONNULL_END | |
| # define __NULLABLE nullable |
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.
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:
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!
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.
| // 1. Add Bootstrap as a dependency in package.json | |
| { | |
| ... | |
| "dependencies": { | |
| ... | |
| "bootstrap": "~3.3.6" | |
| } | |
| } |
| module Editable exposing (..) | |
| type Editable ofType | |
| = NotEditing { value : ofType } | |
| | Editing { originalValue : ofType, buffer : ofType } | |
| value : Editable ofType -> ofType | |
| value editable = |