Observations, stories, projects, photos.

In English and Russian.

Ctrl + ↑ Later

1500 lines

Jan 5, 2016, 19:24

That's how many it takes for Xcode (with XVim installed) to become slow on a file.

As you may have guessed, that is a symptom of a Massive View Controller which is begging to be refactored :) When I started that controller just a few months ago, it was a really thin wrapper about a hundred lines long.

Swift single-file compilation

Nov 27, 2015, 2:11

There comes a time during the life of your Swift project when the compile times just don't cut it. There are some tweaks and knob twirling you can do to improve them, but honestly, it doesn't make that much of a difference.

I started looking around and found the deck “Swift compile time is so slow” by Masato Oshima where he claims that concatenating all the files together improved his build time sevenfold, from 6 minutes 55 seconds to a bit under a minute. “Impressive!” I thought and decided to test this approach for our project.

Now, concatenating all files to help the compiler out is not a new method, I know for certain that some game developers use it for C++ and the results are no less staggering, so this is a legitimate thing to try.

Let's get to the test results. At the time of writing our project is about 40k lines of Swift code and a dozen of external frameworks. I used the slightly modified concatenate_swift_files.sh from keychain-swift, their version disposed of the newlines we used in some of our strings so I had to edit the script to handle that. Otherwise, no changes.

The time is from tapping on Run in Xcode to the Simulator appearing.

Concatenated files: 2 minutes 8 seconds.
Normal source files (around 300 of them): 2 minutes 32 seconds.

Result: a measly 16% improvement. Not worth pursuing for our project. On top of that, the logger we use (XCGLogger) showed all debug prints originating in the concatenated file (versus a specific source file), which is logical and expected, but annoying and unhelpful.

YKProgressBar

Jan 17, 2015, 14:17

Another small piece of software I'm sharing with you. This time it's an actual visible control!

YKProgressBar is a simple drop-in progress bar control with rounded edges all-around (ha-ha). Just copy the files YKProgressBar.[hm] into your project and you're good to go.

Here's a demo of YKProgressBar. The floating things on top are scrolled collection view cards.

If you've missed the link in the beginning, it's up on GitHub.

“Life Is Short And So Is This Book” by Peter Atkins

Jan 10, 2015, 14:13

This is a nice little book expressing the age-old truths in a concise and accessible way. Some reviewers on Amazon say that the book is shallow and the author just regurgitates on plain truths. But aren't people simple creatures? The behavior that brings happiness won't change, no matter how many times it's repeated.

Here's the freely available table of contents, which is also the list of things you should (or shouldn't) do to fulfill your potential:

  1. Create space.
  2. Try not to worry.
  3. Don't do really dumb things.
  4. Build character and make friends.
  5. Care for yourself and others.
  6. Laugh.
  7. Do what you love.
  8. Embrace change.
  9. Learn from experience.
  10. Have dreams and work towards them.

To put it even more tersely, it's “be calm, be kind and be curious about the future.” Seems a lot like what Buddhism is all about, isn't it?

There's another similar book, also by a CEO, the founder of Panasonic Konosuke Matsushita, which is called “Principles of Success.” It's an even shorter book and even more terse, compressing everything into three groups: management, work and life. All or most of what Peter Atkins offers is in Matsushita's book, and vice versa. They may be plain truths, yet simple principles are easier to remember and easier to act on, than a bunch of convoluted tactics which won't fit everyone.

Throughout the book, Atkins shares some brilliantly formulated principles, that I have been thinking about myself but haven't been able to articulate.

Overall, it's a treat to read and I'll be sure to come back to this book.

Life is Short And So Is This Book” on Amazon.

Common-format NSLog

Jan 8, 2015, 23:57

It's often inconvenient to use the full-blown debugger: longer cycles, blocks, whatever. When there's no concern for performance, I just throw in an NSLog.

NSLog, though, is a chore when there is anything but strings involved. I do remember the format syntax but boy is it annoying to put all those %ld, %lu, %g and everything else (which would also complain on architecture change) instead of a simple %@!

So recently I started using an NSNumber literal notation for any ints and floats:

NSLog(@"%@", @(var));

Nothing to remember, no warnings, and gets the job done.

NSString+Ordinal

Dec 15, 2014, 21:55

I put up this little category on GitHub. Feel free to use it — if you find any use for it. Below is a copy of the README file.

NSString+Ordinal

NSString+Ordinal is an NSString category for spelling numbers as words. Specifically, it's intended for Russian ordinal numbers, for which, as far as I know, there is no direct iOS support. The category is tailored to work with numbers 0—200 in Russian and provides sensible defaults for any other number and locale.

What it does is it spells 1, 2, 3 as первый, второй, третий (first, second, third) in Russian and one, two, three in English, which is by design to be used in a phrase like «день первый» (the first day) in Russian and “day one” in English.

The category is a single method which accepts an integer:

+ (NSString *)ordinalRepresentationWithNumber:(NSInteger)ordinal;

This is probably reinventing the wheel, but I strongly believe in bootstrapped, self-written, simple solutions first. It works well for me because I know exactly how it works.

Non-breaking space in NSString

Oct 10, 2014, 16:47

A recent project I worked on had a focus on typography, so kerning, line spacing and spacing were all important. One of the necessary steps to achieve this was to use non-breaking spaces in strings.

Turns out, it's pretty easy, just use the Unicode representation \u00a0, which looks like this in Objective-C code:

@"This is a non-breaking\u00a0space"

Kerning, line spacing, hyphenation and other typographic features are also really interesting to implement, but they demand a longer post and illustrations, so I'll write about them later.

When Xcode goes bad

Oct 6, 2014, 23:19

Sometimes Xcode would not compile your project in its latest state. This is most obvious when you move files around: rename images or remove .xib files. Your app would crash randomly for some weird reason, because Xcode is still using that .xib file you just deleted and tries to initialize it.

In order to fix these caching kind of bugs in Xcode, you have to go to the Derived Data folder and delete everything that's inside (but not the folder itself). In Finder, just use Go ? Go to Folder... and enter:

~/Library/Developer/Xcode/DerivedData

Close Xcode and clear this folder. That's it, after reindexing your project will be good to go.

P.S. This happened most often with Xcode 5, now that 6 is out, maybe that's fixed, but it's still useful to remember that just in case.

Pattern with image: UIKit and Core Graphics

Oct 6, 2014, 2:28

This is fun.

The other day I've been working on a project that uses controls with patterned textures. I've used the texture on one button, then another, and finally on a different control. When I started the app, for some reason the texture on the different control was backwards.

Have a look. The first button's background is set as:

[view setBackgroundColor:[UIColor colorWithPatternImage:[UIImage imageNamed:@"some-image.png"]]];

And the second:

[view.layer setBackgroundColor:[UIColor colorWithPatternImage:[UIImage imageNamed:@"some-image.png"]].CGColor];

And here's how both of these actually look like. The UIKit one represents the “correct” orientation of the background texture.

Notice the difference: in the latter case I'm using the view's layer to set the background color, and I'm using a CGColor reference for that — where CG stands for Core Graphics. UIKit, of course, uses a coordinate system where (0,0) is at the top left. Not so for Core Graphics:

Some iOS technologies define default coordinate systems whose origin point and orientation differ from those used by UIKit. For example, Core Graphics and OpenGL ES use a coordinate system whose origin lies in the lower-left corner of the view or window and whose y-axis points upward relative to the screen.

If we look at things this way, then the texture in the latter case is positioned exactly right, if we mentally rotate it 90 degrees counter-clockwise.

There's a function to flip the coordinate system used by Core Graphics for use within UIKit, but it's usually applied only to the current context, which is not always convenient, as in this case. So bear this in mind every time you deal with Core Graphics within UIKit.

A scroll view instead of a table view

Jul 4, 2014, 0:32

One of the projects I'm working on at the moment is Workie, an offline viewer for Behance, Dribbble and 500px projects. The Behance project view looks like this:

Behance projects are basically a bunch of image and HTML blocks with an occasional video embed. As they are rectilinear and are usually just stacked on top of each other, at first I started to use a UITableView to display the blocks. It worked... okay, until it didn't.

Image blocks are pretty large images, and I used every trick in the book: height caching, background loading and whatnot to speed things up. Performance wasn't choppy per se, but perceptibly slow because of the cell reuse. When a user scrolls down a UITableView, new cells get allocated right at the time when they are about to appear from behind the edge of the screen. If the cell contained a fairly large image, I had to show it empty, even if its height had cached: the system just had no time to load the image up. Since most cells were scrolled into view for the first time, the images weren't in the memory cache, and it also took time to load them from disk. All in all, not a pleasant experience.

As an experiment, I decided to try replacing the table view with a simplistic UIScrollView which got filled with all the project modules (that's what they call them at Behance) dynamically.

Now my cell initialization looked like this, and all the magic was done behind the scenes in the class implementation:

BehanceProjectCell *cell = [cv dequeueReusableCellWithReuseIdentifier:kWPBehanceProjectCellReuseIdentifier forIndexPath:indexPath];
dispatch_async(dispatch_get_main_queue(), ^{
    cell.projectToOpen = project;
});
return cell;

The dispatch_async is necessary because most of the heavy lifting is done in the -setProjectToOpen: method, and we want to return the cell immediately, before it finishes. This buys a lot of time, which is usually enough to load the images and lay out the cell before it ever scrolls into view. Most of the time I see the cells already fully laid out when they scroll out. It's much better than watching a UITableView struggle with loading its cells one by one.

The projectToOpen is an instance of a class that has a modules array, each module having a type enum property. If it's an image, we load an image, if it's an HTML or an embed, we fire up a UIWebView.

The scroll view uses Auto Layout, but we want to do most of the things asynchronously. How to do that, if each module needs to have the previous one in place to set its constraints? If even one constraint is missing, the scroll view will collapse: for Auto Layout to work, we need consistent “pressure” from top to bottom and from side to side. So, how do we achieve that?

We set the basic constraints in the -initWithFrame: method of the UICollectionViewCell (which the scroll view is a part of), pinning the scroll view to the sides of the contentView, which is a container view of a UICollectionViewCell. These constraints will remain in place through the whole life of the cell. The scroll view width is constant and it is centered in the middle of the container view horizontally.

[self.contentView addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"H:|-(>=0)-[scrollview(==width)]-(>=0)-|" options:kNilOptions metrics:metrics views:views]];
[self.contentView addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"V:|[scrollview]|" options:kNilOptions metrics:nil views:views]];
[self.contentView addConstraint:[NSLayoutConstraint constraintWithItem:self.scrollView attribute:NSLayoutAttributeCenterX relatedBy:NSLayoutRelationEqual toItem:self.contentView attribute:NSLayoutAttributeCenterX multiplier:1.0f constant:0.0f]];

In the -initWithFrame: method, we also add an observer to the scrollView's contentSize property. This is necessary because of the asynchronous nature of loading the images and slow UIWebView HTML load times. At any time, we do not know whether all the images or web content have loaded or not, or if they ever will.

[self.scrollView addObserver:self forKeyPath:@"contentSize" options:NSKeyValueObservingOptionNew context:NULL];

Don't forget to deregister your KVO observer after you're done with it, otherwise the system will complain.

[self.scrollView removeObserver:self forKeyPath:@"contentSize"];

I forgot to say that Behance projects may have a background image, and it can be either tiling or not. Designers use background images a lot to display content while the project image module is just a transparent placeholder. So it is critical to give as much space to non-tiling background images as necessary, not depending on the size of project modules. In the -observeValueForKeyPath:ofObject:change:context: method we observe the contentSize property changes and adjust scroll view insets appropriately, so that the background image fits without clipping. The background image, if it isn't tiling, is a layer added to the scroll view sublayer hierarchy. There is only one background layer, an it's got a witty name “bgLayer”.

for (CALayer *layer in [self.scrollView.layer sublayers]) {
    if ([[layer name] isEqualToString:@"bgLayer"]) {
        CGSize newContentSize = [[change objectForKey:NSKeyValueChangeNewKey] CGSizeValue];
        if (newContentSize.height < layer.bounds.size.height) {
            [self.scrollView setContentInset:UIEdgeInsetsMake(0.0f, 0.0f, layer.bounds.size.height - newContentSize.height, 0.0f)];
        }
        break;
    }
}

Then comes the fun part, the -setProjectToOpen: method. All those dispatch_async look weird, we're already on the main queue, but believe me, I've tested it and it really helps to chop the process into smaller chunks, and the cells work really fast even with large images.

First off, we're setting the background color (not listed), and if there's a background image, spin off its execution to another function. Background images are huge, up to 6000px in height and more, so it's necessary to do that in another place.

After that, in a separate block we create all the views that we'll be using through the lifecycle of the cell until it is reused. Based on the type of the module, we create a UIImageView or a UIWebView, tag it for future reference—the very next function will retrieve them by tags—and after each view is created, we call another function to configure it, also asynchronously. It's all on the main thread anyway, because we're working with UIViews, but it is split into smaller parts, which don't block the UI. One of the reasons for that is that, for example, creating several UIWebViews takes about 70% of total method execution time according to Instruments. A UIWebView is one of the slowest components, yet we're stuck with using it because of HTML content and embeds.

It is necessary to create views in order before starting configuring them because each view depends on the previous one to “latch” to it with a constraint. If we don't create all the constraints, the scroll view will collapse, even if all the other constraints are in place.

if (_projectToOpen.backgroundImage) {
    dispatch_async(dispatch_get_main_queue(), ^{
        [self setBackgroundImageForProject:projectToOpen];
    });
}

dispatch_async(dispatch_get_main_queue(), ^{
    for (int i = 0; i < [projectToOpen.modules count]; i++) {
        BehanceModule *module = projectToOpen.modules[i];
        if (module.type == BehanceModuleTypeImage) {
            UIImageView *imageView = [[UIImageView alloc] init];
            imageView.tag = kWPModuleTag + i;
            [self.scrollView addSubview:imageView];
        } else {
            UIWebView *webView = [[UIWebView alloc] init];
            webView.tag = kWPModuleTag + i;
            [self.scrollView addSubview:webView];
        }
        dispatch_async(dispatch_get_main_queue(), ^{
            [self configureModuleAtIndex:i withProject:projectToOpen];
        });
    }
});

The -configureModuleAtIndex:withProject: is a bit longer method than that, mostly because of different logic for images and web views. Still, algorithmically these parts are the same.

First of all, we get the previously created views by their tags. kWPModuleTag is a constant with a semi-random number, with which we start our tag count. This is in order to avoid tag clashing with something else.

BehanceModule *module = projectToOpen.modules[i];
UIView *tempView = [self.scrollView viewWithTag:kWPModuleTag + i];

Establishing some metrics beforehand is also useful as they are used by all the modules. I have found out that even if you miss a scroll view constraint by a half-point, the scroll view will become wobbly: you'll be able to scroll it sideways about 50 points, though it should not be scrollable in a particular direction. So for margins, I use floorf() and ceilf() to even out this half-point difference. Module width is constant, just like project width. Still, the calculations everywhere are uniform and it wouldn't be difficult to implement a dynamic width scroll view with dynamic width modules.

NSDictionary *metrics = @{ @"width": [NSNumber numberWithInt:kWPBehanceModuleWidth], @"lmargin": [NSNumber numberWithFloat:floorf((kWPBehanceProjectWidth - kWPBehanceModuleWidth) / 2.0f)], @"rmargin": [NSNumber numberWithFloat:ceilf((kWPBehanceProjectWidth - kWPBehanceModuleWidth) / 2.0f)] };

For each module I do five things. The image view here is just an example, the algorithm is the same.

  1. Add a fixed width constraint with margins and a fixed height of 0. We will change the height dynamically later, when the image loads. Until then, the height constraint is necessary to push scroll view contentSize, even though it's zero.
  2. If the view is the first module (its index is 0), add a top margin constraint to the top of the scroll view. The project's top margin is customized and is supplied earlier by the Behance API.
  3. This is the critical part. If the view is in the middle (not the first and not the last), we need to add a constraint from the view to the previous module, which should exist because we made sure to create it beforehand. This inter-module spacing is also customized and retrieved earlier from the Behance API.
  4. Final step for setting up the constraints, if the view is the last one, add a bottom margin constraint to the bottom of the scroll view, which is equal to inter-module spacing. The value of this constraint is not important, because we add ample space to contain the background image (if there is any) in the -observeValueForKeyPath:ofObject:change:context: method.
  5. All preliminary constraints are set up, start loading the data. For a UIImageView, it's an image, asynchronously loaded from the disk or memory cache and set with a completion handler; for a UIWebView, its a dynamically constructed HTML string: Behance API supplies background, paragraph and title styles, which I compile into a static CSS and use in a template with the HTML content of the module.
NSDictionary *views = @{ @"image": imageView };
[self.scrollView addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"H:|-(lmargin)-[image(==width)]-(rmargin)-|" options:kNilOptions metrics:metrics views:views]];
[self.scrollView addConstraint:[NSLayoutConstraint constraintWithItem:imageView attribute:NSLayoutAttributeHeight relatedBy:NSLayoutRelationEqual toItem:nil attribute:NSLayoutAttributeNotAnAttribute multiplier:1.0f constant:0.0f]];

// If the imageview is first module, add top margin constraint to scrollview top.
if (i == 0) {
    [self.scrollView addConstraint:[NSLayoutConstraint constraintWithItem:imageView attribute:NSLayoutAttributeTop relatedBy:NSLayoutRelationEqual toItem:self.scrollView attribute:NSLayoutAttributeTop multiplier:1.0f constant:topMargin]];
} else {
    // The imageview is in the middle or in the end, add constraint for previous view spacing, if it exists (it should)
    UIView *previousView = [self.scrollView viewWithTag:(kWPModuleTag + i - 1)];
    if (previousView) {
        [self.scrollView addConstraint:[NSLayoutConstraint constraintWithItem:imageView attribute:NSLayoutAttributeTop relatedBy:NSLayoutRelationEqual toItem:previousView attribute:NSLayoutAttributeBottom multiplier:1.0f constant:moduleSpacing]];
    }
}
// If the imageview is last module, also add bottom margin constraint to scrollview bottom.
if (i == ([projectToOpen.modules count] - 1)) {
    [self.scrollView addConstraint:[NSLayoutConstraint constraintWithItem:imageView attribute:NSLayoutAttributeBottom relatedBy:NSLayoutRelationEqual toItem:self.scrollView attribute:NSLayoutAttributeBottom multiplier:1.0f constant:-moduleSpacing]];
}

At this stage, even if nothing at all loads, we have a perfectly set up scroll view with Auto Layout. It consists of zero-height modules, but that's about to change.

When an image finishes loading from cache, it calls a completion block. I supply a __weak image view in it and check if it's still relevant when the image is loaded. After that, I iterate over the constraints and set the height constraint to a new value, if the image is of predefined width, if it isn't, I scale the image and set its width, height and margins anew. After that I call [self.scrollView setNeedsLayout] and get a notification in my -observeValueForKeyPath:ofObject:change:context: method when the scroll view's content size property changes, where I can adjust the bottom margin to accommodate the background image.

For a web view the process is the same, save that I'm using a delegate, not a completion block. I get the proper height of the web view like so:

CGFloat jsHeight = [[webView stringByEvaluatingJavaScriptFromString:@"document.height"] floatValue];

Again, that looks weird, but it works reliably even when the constraints are contradicting. For example, if I used something along the lines of intrinsicSize or sizeToFit, I would get zero — the value of the constraint that limits the web view's size. By using the JS contraption, I get true height with width being constrained at the same time.

And that's it. After all the content has been loaded, the scroll view now has all the necessary constraints to display all the images and HTML content that it needs, and it does, and it works surprisingly quick.

P.S. AFNetworking doesn't fold lines, and I won't too.

iOS   Tech
Ctrl + ↓ Earlier