agi18n agimagechecker amazonaws android arc autolayout blog building cache calabash certificates clean code cocoa cocoapods data binding debugging deployment target drm ebs ec2 errors facebook fix git i18n images instruments interface builder ios iosx enterpise summit ipad iphone iphone5 kotlin libraries like button linking links llvm memory management method swizzling mobile model mvc mvvm nil objective-c optimizations patch patterns performance presentation provisioning profiles restkit runtime rxjava rxswift security shadows streaming svn swift testing tools tutorials uikit uistackview video view xcode

Subscribe to this blog

Latest posts

ARC (III) - ARC Optimizations

Angel G. Olloqui 02 November, 2012

In my previous two posts about ARC (post I and post II) I have talked about the optimizations and how ARC can perform as fast (or even faster) as manual memory management. This is quite clear when working with simple alloc/retain/release examples because it is exactly equivalent to manual memory management but using C calls (which are faster). However, I haven’t explain how it does it when dealing with methods that return autoreleased memory. So, it is time to have some fun.
First, lets copy again the resulting ARC compiled code seen in the first post:

Tags: arc, memory management, objective-c, xcode, optimizations


ARC (II) - Advantages, drawbacks and false myths

Angel G. Olloqui 26 October, 2012

In my previous post I analyzed the fundamentals of ARC. Today, I am going to write a quick post about some general advantages, problems and myths around it. I warn you that I will not enter in details, but it will be useful as an introduction to the next (and probably last) post of the series. 


There are many advantages of using it, but I would summarize them on the following:
  • It Keeps it Simple Stupid (KISS)! Working with ARC makes your code easier to write, read and maintain. Therefore, your code will be less error prone and you could actually save some time writing (specially in dealloc methods).
  • Safer: Do you think your code is secure without ARC? Yes, you know how to retain your instance variables, but, let me ask you if you always retain your temporal variables. Probably not always, right? In the end, if it is a temporal variable there is little point on retaining a variable and releasing it a few lines later right? Well, then check out the last example exposed in my previous post! You can never be absolutely sure if an autoreleased returned value will be available the full variable life time, so you should retain always autoreleased variables to be 100% sure it will work. ARC variables by default are strong, which means that they will be retained, and the compiler never forgets :). Besides that, the introduction of weak references can also help a lot in solving problems with released pointed objects (usually delegates).
  • Less leaks: If you are a master of iOS development you probably have few memory leaks or even not at all. However, even if that is the case is common to work with different people who might not be as experienced as you are. The use of ARC ensures that there is no leak due to an incorrect use of retain/release. However, be careful with the memory retain cycles! they are still there. 
  • Reduces autorelease pools: This one is pretty interesting because I thought that ARC would make heavy use of autoreleasing pools. However, that’s part of a false myth and we will take a look to it later. For now, all you need to know is that it actually reduces the amount of autoreleases in your code (if everything is ARC compatible though), which could make your apps to actually execute faster if your code produces heavy memory pools.

Tags: arc, memory management, objective-c, xcode


ARC (I) - Introduction to ARC and how it works internally

Angel G. Olloqui 11 October, 2012

It has been about a year since Apple released ARC, and even if there is a lot of good information out there I still see some misconceptions, false myths and reluctances to adopt it . Because of that, I am going to write a set of posts about it, but focusing in explaining how it works under the hood and why some of the myths out there are not really true.
So today, lets start by presenting ARC.

Tags: arc, memory management, objective-c, xcode


iPhone5 -568h image loading

Angel G. Olloqui 28 September, 2012

With the introduction of the retina displays, Apple implemented a few changes when loading images that allowed the SDK to look for the corresponding retina image (named with a @2x convention) automatically. This was a relief for developers, as they do not needed to change the code in their apps. All an iOS developer needs to do is provide the corresponding @2x images of the non-retina ones.
Nowadays, with the introduction of iPhone5 and its bigger display, some images such as backgrounds should also be loaded from a different file or otherwise the image will be stretched. I expected that Apple would make a similar trick, this time with the -568h convention that they imposed for the Default screen. However, in this case, they do not seem to do that. WTF! Why? well, I don't know exactly why but if I try to guess I would say that it is because checking so many paths on runtime introduces a considerable lag, and in contrast with the retina version, the 568 counterparts are used rarely. They will only be applied in backgrounds and similar images, but not in small images such as icons. 

Tags: images, iphone5, method swizzling, runtime


Oddities working with images in iOS

Angel G. Olloqui 14 September, 2012

For the last 10 days I have been working in a new library to check iOS images on runtime. I will make another post to explain it in a future, but today I wanted to remark some oddities that I found when working so tightly with the UIImageView class (it is funny that I haven’t realized on most these oddities after almost 3 years working with them)


UIImageView, as any other view in iOS, extends UIView. This characteristic would make everyone think that UIImageView have all the functionality and behave as any other view. However, there are some interesting considerations when working with this component:

Tags: ios, interface builder, images, agimagechecker, debugging, runtime