Tag: ios

With iOS9, Apple introduced a new container view called UIStackView. Stack views can be seen as the iOS equivalent for the LinearLayout in Android. Likewise, the usage is pretty straightforward, especially if you from Interface Builder, and when used properly can save the developers lots of time.

However, this special view comes with its own set of gotchas that are hard to find at first, and that can complicate your life hugely. With this post I want to cover the main issues and tricks that I have found while using stack views for a few months. Note that I am not going to cover the basic usage of UIStackView, there are plenty of references on Internet for that (check references below). Let’s get started!

Where is the drawing phase?

One of my first issues with Stack Views was setting up some basic properties like background color or borders. An interesting aspect of this views is that they do not have a normal render phase. Instead, they are container views, and any code you place in the drawRect method drawing into the current context will actually output nothing. This is what the documentation says:

Today I am going to write about a pretty uncommon but very useful pattern in iOS apps, called Chain of Responsibility, exploring how we can take advantage of some Cocoa methods to implement it easily and how/when to use it in your iOS apps to reduce dependencies in modular apps.

But before starting, I want to acknowledge Saul Mora because it was on one of his presentations (about a year ago) where I first saw this pattern in action. He applied it for the Model layer, while I do it for the Controller flow mostly, but the main idea behind the whole post is basically the same and you could apply it for either case. I suggest you spend some time checking his presentation about this pattern, very inline with this post.

Introduction

It is very common to see shadows in different apps. In many occasions shadows are just rendered by using an image with the shadow predrawn, which basically performs as any other UIImageView. However, sometimes you may need to draw the shadow from code. When this time comes you will face performance problems that in case of heavy use (especially in iPad in combination with table or collection views) it can slow down you UI.

It might seem negligible, but if your view is a composition of multiple views applying shadows then you will actually experience a very big UI performance degradation. For example, in my latest project where I had a grid view with shaded cells like this:

Localizing iOS apps with the standard tools is tedious, especially when you use Interface Builder files. To resolve that, I have created a new tool called AGi18n that makes it extremely easy. But let’s first start by analyzing the existing approaches for it together with their problems, to later introduce the library and all the goodies that you get from it.

NOTE: I am receiving feedback from readers that this solution is not always working. Please, have in mind that this post is old and the content might be outdated.

Introduction

This week I have been delighted with a very attractive (and quite new) acceptance testing framework called “Calabash”. My experience in acceptance testing is limited, but Calabash quickly took my attention for a few reasons:

It uses Cucumber for defining tests. Cucumber is a “language” that is very close to real English, making tests very easy to write and read. Lot better than other alternatives, especially if you have to work with non-technical QA.

It is multiplatform. The same tests can be run both in iOS and Android! How cool is that? write tests once and run in multiple platforms.

It runs on real devices. Nothing else to say, tests should always be run in simulator and real devices. Even more, there are some interesting services in the Internet that allow you to run your Calabash app tests in hundreds of real devices, which can be very helpful for Android apps.

However, integrating the framework in a project with CocoaPods was not as straightforward as I thought. In this article, we are going to see why and how to fix it.