Tags

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

Tag: interface builder

Localization in iOS apps made simple

Angel G. Olloqui 17 March, 2013

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.

Tags: ios, libraries, agi18n, interface builder, method swizzling, i18n

    

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

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

    

LiberaciĆ³n de memoria en IBOutlets

Angel G. Olloqui 06 July, 2010

Hoy voy me he encontrado con un problema en el trabajo relacionado con la liberación de memoria y la convención Ownership. Bajo esta convención, las clases solo son responsables de liberar aquella memoria que reservan directamente (mediante alloc, retain o copy), pero resulta que no siempre es así.

Tags: interface builder, ios, ipad, iphone, memory management, objective-c