Category Archives: blog

Objective-C – Categories

Every developer, good or bad, at least those who have followed the programming courses at any university remembers some design patterns, MVC, Singleton and some of the also say Decorator.

In the iOS framework, Apple has used, and has guided the developers to use certain patterns, if we talk about the general architecture we most of the times find Model View Controller, if we want to use the notification system, we find out they used Observer pattern, and the list could go on.

Objective-C  is a hybrid language, which took, various parts for other languages, and evolved a lot in its over 32 years of existence. It has many great features, which helps you get your work done (eq. blocks), but it also has its lacks, you can NOT set the visibility of a a method as being private or protected because of the dynamism of the language.

Categories

In the beginning of this post, I’ve mentioned the Decorator pattern, and that is because this post should be about categories, Objective-C categories, and those two are somehow related.

With the Decorator pattern, you would add some new functionality to an existing class, that is the main purpose of Objective-C categories but with some constraints.

If you have started working in iOS you probably did already use categories, without knowing they are called like that, but enough talk lets jump to examples.

@interface HelloWorldObjC : NSObject

@property (strong, nonatomic) NSString *greeting;

- (void)saySomething;

@end

We declared an interface for a class which has one method, and one property, a greeting which is a string which will be printed by the say something method.

@interface HelloWorldObjC()

@property NSString *beforeGreetingString;

@end

@implementation HelloWorldObjC

#pragma mark - Lifecycle

- (id)init {

self = [super init];

if (self) {

self.beforeGreetingString = [NSStringstringWithFormat:@"%p", self];

self.greeting = @"Hello there!";

}

returnself;

}

#pragma mark - Public methods

- (void)saySomething {

NSLog(@"%@ says: %@", self.beforeGreetingString, self.greeting);

}

@end

As for the .m file, the implementation, as you can see there is another place where you could declare variables, making them “private”, that section @interface ClassName() is a special type of category called extensions. That is why I said in the beginning of this post that you might have used categories without knowing how they are called if you are new to ObjC. You can define an extension in the .m file of a certain class, where the @implementation of that class resides and create new properties which your class will be able to use. One thing to mention about this properties is the fact that they are synthesised, which means you get a getter, a setter and a backing ivar for your property. Moreover, you can also declare methods in the extension. Long story short, everything you declare here, can only be used in the @implementation section, if another class inherits or someone makes a category over this class, you will not be able to access anything defined inside the extension, and you will only have access to the things defined in the .h (@interface) file (without using some tricks at least.).

The initializer sets the greeting to a default one, in case someone forgets to set it when using the object and also sets the value of the interface defined property to the memory address of the current object.

The saySomething method only displays a string composed of the value of the address of the object in memory, and the defined greeting.

A real category

This is supposed to be about categories, but where are them? Ok lets see what a proper category looks like.

@interface HelloWorldObjC(Smile)

- (void)addSmileToGreeting;

@end

In another file usually named “HelloWorldObjC+Smile.h” we can add a new category, as you can see, the declaration is pretty straight forward, you declare it like any other class, without the inheritance and with a unique name in between parenthesis. What can we declare here? Well there are a few rules, you can define new methods and even properties, the compiler won’t complain if you provide the getters and setters in the implementation section your program won’t even crash. Basically what you can do here is add some new methods, some new functionalities to your original class, but you can not alloc new memory for it, that is why you can not add new properties backed by an ivar, because the categories are not new objects, they are the same object as the original class. To make it easier for you to understand, you can do an  category for every class you want (YES event for classes from Foundation, UIKit and so on), and you can use the methods you add to those classes using a category wherever you implement the header with the definition of the category. Now picture the following scenario, you are working with NSStrings all over the app, I come along and make a category over NSString and add new properties to it, what is suppose the system to do? Add those variables to all the objects, of NSStrings, wherever I import my header? The answer is NO, categories are not allowed to modify the size of the object in memory by adding some new values to it. That being said, you can not add properties, and ivars to a category. Another restriction is the fact that you can not overwrite methods on the base class, for obvious reasons.

@implementation HelloWorldObjC(WithSmile)

- (void)addSmileToGreeting {

[self.greeting stringByAppendingString:[NSStringstringWithFormat:@"%C", 0xe04f]];

}

@end

As for the implementation of the category in the “HelloWorldObjC+Smile.m” file, we only add an emoji to the current greeting message.

Well this doesn’t look like much, what can I use them for? Well there are many usages, for example you can use them to explicitly mark for the people in your team which methods are “private” or any other sort of example where you use a category in order to make your code more readable. But by far the most common usage is by adding some sort of functionality to a certain class, in my projects i usually make a category over UIColor so that i can initialize a colour from a hex string, you can put there all sorts of helpers on any class for the app you’re building.

Xcode run script

There always comes a time in the life of a iOS developer when it has to create a for various reasons a script to automate a certain task. For example, you can create a script on your production target that every time you make an production build your localisable files will be stripped of unused keys, this was a simple example but you can create more complex functionalities with this feature of Xcode.

How do you create an run script?

 

screen-shot-2016-09-24-at-13-04-19

 

 

screen-shot-2016-09-24-at-13-04-39

 

 

screen-shot-2016-09-24-at-13-05-16

 

 

 

 

 

Thats it, simple as that.

 

Now lets talk about what can we write in here.

What sort of scripting language can we use, we can use basically any type of scripting language that comes installed on macOS, a few example would be:

/bin/bash
/bin/csh
/bin/sh

Another great thing, which I found out from an Stackoverflow post, is the fact that we can specify input and output files. Basically we can tell Xcode which file we are going to read in our script so that the build script is run ONLY if one of those files has changed, if the files haven’t changed Xcode caches the result, so it won’t affect the build time. Output files are the files out script writes to, we specify those so that if they haven’t changed, Xcode can cache the build.

One specifically thing worth mentioning, is the fact that the order of the build phases, matters, so if you want your script to be run before the compile phase, you can do that by dragging it before the compile phase.

If you follow the 3 images in this post you will have a project which when you’ll run it it will produce a file named myFile.txt in the root of your project with the content “Hello world”, while this is useful, sometimes when you are writing your script, you need to check the output of the commands. If you modify the script by deleting “> myFile.txt”, the result will be just ‘echo “HelloWorld”‘, if we delete the initial file and run the project again, no file will be generated and we can no longer see the output. In order for us to see the output of the script, we need to access the Report navigator in Xcode and select the build phase.

screen-shot-2016-09-24-at-13-34-57

 

 

 

 

Last but not least, you can use many path variables and even git commands to fetch any details about your project repo.

The heart of the app

Today I’m going to talk a bit about the AppDelegate. In every demo project, and most of the times (I currently don’t know any examples where it does not) in every app, there is an class named AppDelegate.

Purpose

The app delegate is the entry point in an iOS application, here the app we are developing will receive different notifications regarding its state, push notifications and here is also the place where the app initialisation takes place.

Every iOS application has a lifecycle composed of 5 different states.

  1. Non-running – the application does not run, has NOT been launched
  2. Inactive – the application is in foreground but does not receive events, this is a transition state, and we usually find the app in an inactive state when launching the application or when the application runs and we receive an phone call
  3. Active – the application is in foreground and receives events (the application is open, we can interact with it)
  4. Background – the application runs in background and executes code (for eq. in an navigation app, fetching the current location of the user, and alert the user that its gonna need to change direction)
  5. Inactive – the application is in background and does not execute code (the application can become active if we tap the icon again, or press on the home button for all the apps to be displayed and select it from there, the application is loaded in memory, to not be confused with the non-running state)

 

Singleton

The app delegate is and singleton and is baiscally an object that comforms to the UIApplicationDelegate protocol. Besides the AppDelegate, every project has an singleton object of UIApplication type, which actually does all the hard work, and it just passes its events to the AppDelegate class of our application.

This means that the AppDelegate is an object that can be accessed during the whole time an iOS application is active, and keeps its state (is a singleton we don’t have multiple instances).

One common pattern when beginning to develop apps for iOS is to have a fat AppDelegate and multiple links with other classes from your app, as it keeps its state and is accessible from all over the app for beginner is the perfect place to keep different informations. The app delegate should be lightweight, should only handle the state changes of the app, and the initialisation of it, everything else, different properties or variables most of the times they should NOT be there.

 

Design

What I do for my apps in order to have a light app delegate is create classes for various classes of notifications. For eq. I have a class that handles all the push notification flow, basically the app delegate only tells my NotificationClass, that there is a new notification, the handling (the parsing of the notification, decide how to act on it) is done by my NotificationClass object. Respecting this rule, you’ll end up with a very light weight app delegate, and classes that are focused on only one job (as they should be, by respecting the “Single responsibility” from the OOP principles), which in the long term is easier to maintain and modify.

I’ve seen app delegates which had over 2000 lines of code, and I tell you now, thats some ugly stuff. We have to look at the app delegate like a phone company, its job is to link various people (the app delegate job would be to link an event to a handler), it should not care about how it can handle an event, it should only care about sending it to the right object for handling it.

 

Links

Apple

So you wanna learn iOS …

Hi there, this is my first post from many (hopefully) to follow in which I try to explain things I struggled with or things I found interesting while learning how to make apps for iPhone.

One of the first things someone who is willing to learn iOS development has to do is get his tools. Easier done then said if you are on a Mac, all you need to do is download Xcode and you are good to go. However, if you are on a Windows or Linux machine, you need to install a virtual machine which has macOS, which is not legal, but it can be achieved, or install macOS directly in you computer, if your hardware supports it. Otherwise, if you want to get you hands dirty, you can always build yourself a hackintosh, but in my humble opinion is if your can afford it, you should by a Mac, it will save you of a tons of “troubles” and you will love it.

Assuming you’ve installed Xcode, on any of the setups described above, we can move to the next step and explain a bit what is Xcode and why we are using it. Xcode is one of the most powerful and widely used IDE on Mac for developing C, C++, ObjectiveC and Swift apps. It’s highly optimised for building iOS, tvOS, watchOS and macOS apps, but people also use it to develop other types of apps.

Why use Xcode?

Apple has tried (successful in my opinion) to make the developers life as easy as possible. What do I mean by that? Basically all you need to develop, test and lunch your client side app is build in this IDE. It has a lot of powerful tools for debug (see Instruments), development, and deploying your app, and you don’t need to struggle with other things, such as different command line tools, or multiple programs or IDE’s just to achieve your purpose (creating an iOS app). Most of the developers I know, experts or beginners use it for development, but the development can be done in other environments as well for eq. Facebook developed Nuclide.

Xcode is definitely a perfect tool, but most of the people I know, in fact all the developers I know personally, get along with it pretty well and are contempt with its performance. Of course depending on the project, Xcode might not be the right tool for you but, if you are just starting developing apps for Apple platforms, I strongly suggest you to use it.

Other tools

What other tools? Like I said Xcode is all you need! Next time we’ll start to talk about actual development as its pretty straight forward to get a simple project up and running.

Start Xcode -> “Create new Xcode project” -> iOS Application -> Single View Application -> Enter a product name such as “My demo app” -> Next -> Choose a location on the disk and press create!

Now just press the “play” icon on the right of the macOS close, minimise and maximise buttons and your first iOS application will start on the selected simulator.

Thats it, you new shiny demo app is running.

See you next time!

 

Hello World

As one of the first programs you write in a new language (except Assembly and Lisp and Prolog and … ), I’ve chosen to make it as well as my first blog post. If you arrived here it means you were interested in my blog and read all the articles (which is unlikely) or this is my only article so far.

Now for the body of our program, we have our environment settled, so its time for me to say what I’m gonna do with this, the basic idea is that I’m going to write things that I found interesting, mostly programming and geeky stuff, but there might also be some more personal and cultural ones.

The main purpose of an “Hello World” program is to see that your environment is working and to get a glimpse at the way the new language works, another important aspect of it is the fact that is usually short that being said, return 0; and see you around.