Swift Weekly – Issue 03 – The Swift Runtime (Part 2) – Enumerations

This is the second article in the Swift Runtime series of the Swift Weekly. In this article, we will dig deeper into the Swift Runtime and how the compiler deals with producing code for enumerations. Saturday morning writings are always fun! Let’s get this show started.

If you are an Objective-C or Swift programmer and have not done any Assembly programming or are simply not concerned with the low-level details of this article, jump right into the Conclusion section at the end to get the juice of this article.

Continue reading this Swift Weekly issue on Github.

iOS 8 Swift Programming Cookbook

Hi lovely readers 🙂

My iOS 8 book is out and it is ALLLLL new, rewritten to use Swift with tons of new stuff in it.

Check it out, it is 50% off. Click here to go to O’Reilly’s website to purchase the book.

Also a surprise, I have also done a video course to teach you all about iOS 8 programming with Swift. THAT too is 50% off for a limited time. You can click here to get the videos.

Happy coding everyone

Learn iOS programming

Giving private and group iOS development lessons

Hello internet. After writing many many books and developing iOS apps for 6+ years, I feel I am now ready to take on a new challenge. To start teaching iOS development to people who are interested in transforming or perfecting their career.

I am available for teaching iOS development to you ANYWHERE in the world you are in. If you are in London or in Brighton in the UK, we can have face to face lessons. If anywhere else in the world, I can teach you over Skype.

Classes will be tailor made to suite your free times, abilities, etc. If you are interested, get in touch by sending me an email at: vandad.np@gmail.com

 

Hiding sensitive business logic in Objective-C

So you have some business logic in a class that you want to hide from the users of your class? Let’s say that you are working on a library project and you have to expose the header file of this particular class to your user but once you do that, it’s easier for dubious programmers to find the class name behind your business logic and potential reverse engineer your app.

In Objective-C, we can hide the implementation of our business logic by taking advantage of the Objective-C runtime. Here is our action plan:

  1. We will create our class called Person (the class whose header file is going to be exposed to evil programmers out in the wild!)
  2. We will create another class called PrivatePerson and will include our business logic in there
  3. We will then redirect requests from the Person class to the PrivatePerson class

And obviously we will not export the PrivatePerson’s header files for the programmers, are we crazy? No!

Ok so let’s begin by creating the interface for our Person class like so:

Screen Shot 2014-01-17 at 16.10.09

The properties are fine. But the method named fullName is going to have business logic in it. It will return the current first name and the last name, separated with a space. We don’t want the logic for this method to be inside the Person class so what can we do? We will go first and create the class named PrivatePerson and we will put our business logic for the fullName method in there. Let’s start with the header file. But before we do that, remember that the firstName and lastName properties are in the Person class. So how can the PrivatePerson class that contains the business logic calculate the full name without having those values? Well, we just have to pass those values to PrivatePerson as parameters like so:

Screen Shot 2014-01-17 at 16.25.54

Then we will implement the PrivatePerson class:

Screen Shot 2014-01-17 at 16.26.45

 

Now what we have to do in our Person class is to implement 2 methods. The first method is methodSignatureForSelector: and this method will be called on our Person class whenever the fullName method is called. Since Person doesn’t implement fullName, the runtime will, in the process of throwing an exception, first find out whether the Person class can handle this message. By implementing the aforementioned method, we get a chance to return a method signature that corresponds to the fullNameFromFirstName:lastName: method in the PrivatePerson class, like so:

Screen Shot 2014-01-17 at 16.31.39

 

Note: self.privatePerson is a private property of our class. Look at the next screen shot to learn how we implement that property’s getter.

 

Then we will implement the forwardInvocation: method using which we redirect the call for the fullName method into the fullNameFromFirstName:lastName: method in PrivatePerson class:

Screen Shot 2014-01-17 at 16.33.21

 

Perfect, in your app delegate for instance, test this out:

Screen Shot 2014-01-17 at 16.34.39

 

You can see the correct value of “Vandad Nahavandipoor” will be printed out to the screen.

That’s all good and fluffy and warm and nice. But LLVM will be nagging at the incomplete implementation of the fullName method in the Person class since we haven’t implemented it there. Remember? That was our goal! Doh!

Screen Shot 2014-01-17 at 16.37.22

So using the awesome techniques described by the lovely people behind LLVM, we will silent these incomplete-impelemntation warnings in our Person class like so:

Screen Shot 2014-01-17 at 16.39.56

 

Awesome, problem solved. Happy coding everyone! 🙂

iOS 7 Programming Cookbook’s Source Code

As you know, my recent book is now published, titled “iOS 7 Programming Cookbook”. You can purchase it here:

http://shop.oreilly.com/product/0636920031031.do

All the source codes written for this book are now available on Github at the following location:

https://github.com/vandadnp/ios-7-programming-cookbook-source-codes

If you have any questions, please let me know.

Deprecating Properties, Methods and Enumerations in Objective-C – LLVM/Xcode Tips and Tricks

A lot of times when working in a team, you would write a class, or add an enumeration to an existing class or add a new property. Some times, you might need to tell other programmers who work on the same code-base that a property, enumeration or a method that you wrote is now becoming deprecated and perhaps a new version of the API introduces a new property/enumeration/method that programmers need to use instead.

This is where LLVM can be very useful. Obviously, if you are the only programmer in a project and not developing an API for others, this might not be of much use to you. But if you are used to working in a team, knowing this trick is an absolute necessity.

Let’s say we are writing an enumeration that at the time of writing (let’s assume at the time of writing this enumeration, iOS 5 was the latest iOS version), everything was fine like so:

Our enumeration works on every iOS version for now

Now let’s say iOS 6.0 is introduced and you are thinking to yourself “Oh that Ultra Fast item in the enumeration is just not very good and I think I have to remove it”. So what to do now? The solution is using __attribute__ like so:

Deprecating an enumeration value in Objective-C

Deprecating an enumeration value in Objective-C

The availability attribute can have the following keys:

introduced: this will be the version of the operating system (iOS, Mac OS X) where the API was introduced first.

deprecated: this is the version of the operating system where the API was deprecated (ready to be removed from the API in later versions of the API)

obsoleted: the version of the operating system where the API is completely removed and is no longer supported.

message: the message to display to the programmer in Xcode.

As you can see, right in front of the availability attribute, we can write “ios” or “macosx” to denote if an API is (un)available for iOS or Mac OS X respectively.

Now let’s assume iOS 7.0 comes along and we want to completely stop our support for the “ultra fast” enumeration value. All we have to do is to add the “obsoleted” key to the availability attribute like so:

Completely removing (obsoleting) an enumeration item from iOS 7.0I hope you enjoyed this tutorial. Let me know if you have any questions 🙂