Category Archives: Blocks

KirKos: App Development under 24h


κίρκος :  circle, mostly in form κρίκος (q.v.): hence, ring, IG11 (2).161B49 (Delos, iii B.C.): poet. for Prose κρίκος acc. to Poll.1.94:—neut. pl. κίρκα ἢ καταδέσματα PMag.Lond.121.299.

 I want to be able to add a blur effect around a picture (with a circle shape), and then save it or share it.

The idea/concept came from Rui Barroca. So, after an initial assessment at a Nando’s restaurant, we reached the following:

  • There were no applications doing this, or doing it how we wanted it to be (on a Business PoV).
  • Blur is a design trend that iOS 7 brought with it, so doing some work on that area is interesting (on a Dev & Designer PoV).
  • Doing so in less than 24hours, was a challenge that I happily embrace.

The concept, design, development and submission, started on a Thursday, 17/10 @ 21:00 and was finished on Monday, 21/10 @ 00:05. It took around 23 hours.


Must Have

  • Take Picture from camera.
  • Pick a photo from the gallery.
  • After selecting/taking the picture, be able to add a blur, with a circle shape, around a picture.
  • Be able to define the blur’s radius.
  • Save the picture with the blur effect on the Phone’s Gallery.

Could Have

  • Share the picture on the most common social networks.
  • Be able to use Instagram’s URL scheme and open the picture on Instagram, so it can be edited. 

Nice to Have

  • About Screen.
  • Pan Gesture, to resize the circle.
  • One finger gesture, to change the circle’s center. 

As you might expect, the “Nice to Have” section is out from the first version of the app. In our opinion, it will make sense, if we have enough people using it.  The “Must Have” was kept: even though we don’t bring a lot of features with KirKos, we wanted to make sure that what it does, does well, so we made sure the core functionality was there, from day one. Because we still had some time, the “Share the picture on the most common social networks.” is an integral part of the first version.  In the end, adding and removing features is hard, but you should focus on what’s the purpose of your application and that it delivers it seamlessly.


This is the Design version 1.0. With the Selection of the photo on the left, and the edition on the right:

1.0_KirKos_CaptureScreenv_v0.1                             1.1_KirKos_EditShareScreenv_v0.1

This is version 2.0:

1.0_KirKos_CaptureScreen_v0.2                             1.1_KirKos_EditShareScreen_v0.2

On a first look, the difference is not that big. But  take into consideration that  version 1, just doesn’t work  with 3.5′ iPhone, due to the menu where you have the flash &  switch front/rear camera, you couldn’t accomodate that in 3.5′. So on version 2.0, we pushed the flash and “switch front/back camera” to the camera area.  This gave us a bit more room for the 4′ version, and decent UI for the 3.5′. We also decided to separate the “Share Button” and the “Save Button”. The initial purpose was to be able to save the image on the phone, but sharing it, on the long run, is more important, so we keep the Share button on the mid. You are also able to save it on your gallery by pressing the “Share Button”, but for the time being we will keep as it is.


The first question that popped into my mind was how could I create the Blur? Fortunately, in that matter, we have quite a lot to choose from. The initial design of the app, was to allow the user to apply the filter while the camera was on, this is very important to decide which 3rd party lib you are going to use. After knowing that FXBlurView wouldn’t work as I wanted, I gave GPUImage  a try. Not sure why, I wasn’t able to put it to work on my first try, so I decided to use the same workflow as Instagram:

Pick/Take Photo -> Apply Filter -> Share 

On the long run, this brings a couple of advantages:

  • Better performance for older devices. I am confident that live camera + effect, would translate into low fps.
  • A single place for editing the picture. With this I have more space to show editing controls, and remove the ones used for taking the picture

Since Business side was ok with this change, we move forward with it.  For this kind of flow, FXBlurView proved to be more than enough.  Some facts about the development and the code:

  • One of the places where I lost  a lot of time (and wasn’t really expecting to), was trying to put a UIImagePickerController's root UIView as a subview of my UIViewController's root UIView and keep the Status Bar visible.
  • The total amount of line of codes is  around 650. The biggest class is 298 lines.
  • I am using two nibs, one for 4′ and another 3.5′, with Auto Layout. This approach revealed to be more practical to maintain.
  • The size of the project is 4.3mb.
  • I made one question on stackoverflow regarding the creation of the app,  which I answered myself.
  • Used three 3rd party libs: FXBlurView, UIImage+Orientation, UIColor+Hex. The last two, are classes I created but with other people’s code.


Having two persons, in this case me and Rui, wanting the same thing, really paid of. The fact of being able to ask him an asset, or an approach on something, and being able to receive feedback immediately proved to work (even while working remotely). Without this, it would be impossible to finish it in such a short period of time. I have to say this was a very fun experience and I will definitely repeat it. Finally, the application can be downloaded here.

Note: The source code is available here: If you like it, please Star it.


Tagged , , , , , , , , , ,

Architecting with Blocks part 2

(Note: This is part 2 of a series of posts about Architecting an application using blocks in objective-c. By no means I am an expert on using blocks, and also it’s not the intention of this series to teach you how to use blocks. You can check this for that. To finalise, I am sure there are better ways to use blocks while architecting an app: use this at your own risk. :))

This is the final post from a 2 parts series that I start a long ago. In this case I won’t show any snippet of code, I will give away an entire sample. My approach about this matter, change in the meantime, nonetheless hope you enjoy it. You can find it here .

Tagged , , , , , , ,

Item 2, Minimize Importing Headers in Headers

Note: This post is part 2 of a series of posts I will do about the new book of Matt Galloway.

Minimize Importing Headers in Headers

The second item, unfortunately a short one, talks about importing classes: the where and the how. One should be careful when importing things he doesn’t need on the .h file. Most of the time, specifying @class (forward declaration) instead of an #import is  the best choice. Importing creates dependences between classes that should be avoided (when possible). So what does this @class actually means?

“The @class directive minimizes the amount of code seen by the compiler and linker, and is therefore the simplest way to give a forward declaration of a class name. Being simple, it avoids potential problems that may come with importing files that import still other files. For example, if one class declares a statically typed instance variable of another class, and their two interface files import each other, neither class may compile correctly.” – Abizern,

So in a nutshell (from Mr. PeyloW,

  • Only #import the super class, and adopted protocols, in header files.
  • #import all classes, and protocols, you send messages to in implementation.
  • Forward declarations for everything else.

And a quick example:

“The reasoning behind forward declarations in header files is that it avoids unnecessary dependencies. i.e. Imagine B.h forward declares A and B.m imports A.h. Then imagine C.m, D.m, E.m and F.m import B.h. After all this is done, A.h changes. Since A is only forward declared in B.h, only B.m needs to rebuild. Without forward declarations, C.m, D.m, E.m and F.m would all need to be rebuild if A changes” – Jacob Relkin,

Hope you enjoyed this quick reference to how to import in objective-c.

Tagged , , , , , , , ,

Item 1, Familiarize Yourself with Objective-C’s Roots

Note: This post is part 1 of a series of posts I will do about the new book of Matt Galloway.

Familiarize Yourself with Objective-C’s Roots

Dynamic language

In this item, the author starts by delving into how Objective-c send messages as opposed of function calling (in this case comparing to C++)  and when one should be used instead of the other (you can still use function calling in objective-c).  The dynamic nature of objective-c, binds the messaging to the corresponding piece of code that will be called, at runtime; as opposed to C++ (for example) that is done at compile time.

Memory Management

One should understand how related objective-c is to c (it’s a superset) and how/where the allocations are made:

NSString *aString = @"BlahBlah";

In this case “aString” is a pointer to a piece of memory allocated on the heap. Although this is mostly true for allocating objects in objective-c, blocks for example are allocated on the stack, but can be  passed to the heap (block_copy()).  An excellent post by Mike Ashe explains this as well.  Plus when you alloc, new, retain or copy an object, you are responsible for them.  It’s important as well to know how the memory is managed in objective-c:

 ” (..) that any single object can have multiple “owners”, and the system won’t allow the object to be destroyed until all owners have relinquished ownership.” – Mike Ashe,  Stack and Heap Objects in Objective-C

In one hand with manual memory management, you are responsible for cleaning the house, with ARC the cleanup is being made for you. Do remember, that ARC is not a Garbage collector, so you should need to understand when you have to do something (circular references for example) and when you don’t.

You will find plenty of variables that will be create on the stack, for example:

CGPoint point = CGPointMake(12.0f,10.0f);

CGPoint is a structure and it’s defined like this on CGGeometry.h from CoreGraphycs.framework:

struct CGPoint {

CGFloat x;

CGFloat y;

typedef struct CGPoint CGPoint;

It’s important to measure if you are going to use objects (vars that point to something that has being allocated on the heap) and, in this case, structures (vars that might be using stack space), or non-objects int,float, char, etc. Allocating objects  can incur on an unnecessary overhead, so chose the right tool for the job in hand.

The first item, is a very well written intro into how objective-c works internally versus other languages, and how you can take advantage of the C language . As it is build upon it, some time should be taken to understand it.

Tagged , , , , , , ,

iOS Testing

I started a new project recently, and wanted to make sure that the Testing part would be covered, yes some of my projects have been lacking that. So in my demand to find a proper way of doing this, I found Kiwi. I already had used the default framework for testing in iOS (SenTestingKit), but I have to say that it doesn’t really feel right. The whole mindset in TDD, and the way you start to actually doing things that way is hard. Plus, implementing SenTestingKit on top of that, just starts to touch the boundaries of masochism. So, below you can find a list of resources I gathered last night, and that will serve as reference to you (and to me):

In the end I choose Kiwi, mainly because of the clarity you write the tests, and also for easily allowing the test of blocks.

Tagged , , , , , ,

Architecting with Blocks part 1

(Note: This is part 1 of a series of posts about Architecting an application using blocks in objective-c. By no means I am an expert on using blocks, and also it’s not the intention of this series to teach you how to use blocks. You can check this for that. To finalise, I am sure there are better ways to use blocks while architecting an app: use this at your own risk. :))

On most of the applications out there ( I would say 60%, not counting with games), a normal application follows the same pattern:

  •  Server Request
  •  Handle Response
  •  Parse it
  •  Show to the user
  • Handle any error that might appear

What I have been using, so far, to handle this typical problem is:

  • ViewController complying to a protocol
  • Pass reference to the Server Requester Class (normally like this @property(weak,nonatomic) id <myProtocol> delegate)
  • Request Data
  • Take care of data (Parsing usually)
  • Using the reference passed before, call the most appropriate method from the protocol (normally either success or failure)

It’s the usual pattern, but it can become a bit verbose, if you happen to have a lot of different UIViewControllers, requesting and expecting different things. So, on my last project I tried to rely mostly on blocks.

I had three different kind of resources to get from the server, one of them would rely on the other two (to make the 3rd request I would need that the user had choose the other two). I started by creating a typedef enum:

// Used to know which request we are using
typedef enum



} kRequest;

You use the typedef enum so you can better understand your code ( kFirstRequest, kSecondRequest and kFinalRequest are nothing more than integrals). Next, you define four blocks:

// Block that will be executed when the server's response has been received and parsed
// In theory, you won't need the typeOfRequest to be passed to the block, but you can use it as well
typedef void(^SuccessBlock)(NSArray *arrayObjects, kRequest typeOfRequest);

// Block that will be executed when we receive the server's response
typedef void(^ParsingBlock)(NSData *serverResponse);

// Block that will be executed if something goes wrong (Request, or Parsing)
typedef void(^ErrorBlock)(NSError *errorObject);

// Block that will be executed if something goes wrong (Request, or Parsing)
typedef void(^RequestBlock)(NSError *errorObject, kRequest typeOfRequest);

This is the base of our code. Instead of using a protocol and pass references between different objects, we will pass blocks. You should add this code to a file called Constants.h. On your prefix.pch file, you should import it. This way, you have access to the blocks and the typedef enum in any part of your application.

Tagged , , , , , , , , ,

Sorting results from CoreData Fetch

In this case, you want to compare a CLLocation from the user to the lat & long you have on your CoreData:

NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];

NSEntityDescription *entity = [NSEntityDescription entityForName:ENTITY_NAME inManagedObjectContext:self.managedObjectContext]

[fetchRequest setEntity:entity];

NSArray *arrayOfEntities = [self.managedObjectContext executeFetchRequest:fetchRequest error:nil];

arrayOfEntities = [arrayOfEntities sortedArrayWithOptions:NSSortStable usingComparator:^NSComparisonResult(id obj1, id obj2)
    CLLocation *obj1EntityLocation = [[CLLocation alloc] initWithLatitude:[(NSNumber*)[obj1 valueForKey:ENTITY_LAT_KEY] doubleValue]longitude:[(NSNumber*)[obj1 valueForKey:ENTITY_LONG_KEY] doubleValue]];

    CLLocation *obj2EntityLocation = [[CLLocation alloc] initWithLatitude:[(NSNumber*)[obj2 valueForKey:ENTITY_LAT_KEY] doubleValue]longitude:[(NSNumber*)[obj2 valueForKey:ENTITY_LONG_KEY] doubleValue]];

    CLLocationDistance dist1 = [obj1EntityLocation distanceFromLocation:userLocation];
    CLLocationDistance dist2 = [obj2EntityLocation distanceFromLocation:userLocation];

    return [[NSNumber numberWithDouble:dist1] compare:[NSNumber numberWithDouble:dist2]];

return arrayOfEntities;

The point is to be able to sort an array that comes from CoreData in a nonlinear way, by using Blocks.

Tagged , , , , , , , , , ,