My small world
Only a year ago I laughed at objective-c with its mumbo jumbo crazy code and syntax. Now I finished my first „Hello world” example (It was rather complex hello world) and I’d like to share my observations with you.
I’m currently working as Android Developer so why did I start learning another, some may say “competitory”, platform? “Because I can!” of course but main reason is that as programmer in general you can’t look down on other programming languages or other concepts because you just think they are bad. If you’re going to dislike something you should at least know anything about that subject.
So I took away my all aversions, antipathies and with clear mind full with happy thoughts I began my great adventure in oriental land of weirdness, crazy code syntax and alien technology (they close windows with red x placed on left side!).
High in the mountain$
No! You can’t develop applications on windows… So there is a first obstacle ahead, you need an apple computer in form of iMac, MacBook , Mac mini etc. It’s best to add iPhone ( as we are creating mobile apps ), iPad or eventually Apple Watch (if you plan to develop smartwatch apps) to our expenses. To sum it up we need approximately 1000$. Of course we can work on emulator but in the end we need to check our app on real device.
Luckily for me I can learn objective-c and develop applications on machines at my workplace as part of my quarterly performance review. How awesome is that!? Thank you Pracuj.pl!
As you can see there is pretty high entry cost you need to pay to even play with objective-c and It can discourage many to experience this technology. If you don’t have such luxury as I have you can try your luck in popular auction services and buy some decent used Mac mini.
Setting hardware cost aside there is last cost in the form of Apple Developer Program membership. It’s paid yearly and at time of writing it’s 299$. If you plan on using only iPhone emulator there is no need for this fee.
The good news is that the rest of the software is free. You can develop your applications on pretty good Xcode.
I could compare learning objective-c to learning how to walk backwards when going forward is definitely easier to master.
Let’s look at this example where I’d like to add user to a database in Java. Method delaration would look something like this:
Now I wonder how It looks like in objective-c
The “-” sign at the beginning of a method means that, it’s object member.
If there would be a “+” sign it would be a static method.
Nothing to brag about. There are types specified in brackets like NSNumber and NSString it’s clear enough (
* sign means that we are dealing with pointer pointing to object). But what the heck are these payHimMonthly,withYearlyBonus? Objective-c documentation states that this convention was designed for better readability.
According to them calling method in java like:
is less readable than this:
I found it crazy because it seems to overcomplicate things to add additional labels to every parameter.
Next is naming conventions. Why there types named like NSString, NSNumber, NSArray and so on when in most of programming languages there are equivalent String, Number, Array?
NS prefix is heritage from NeXTSTEP system some may say grandfather of iOS system and apparently
Apple doesn’t want to change this convention.
Defining NSStrings with
Why do I need to add
@ every time when I pass string text?
So instead of:
Later I’ve learned that it’s because objective-c is built on plain “c” language.
We can mix both languages and to distinguish objective-c from “c” an
@ sign is added so there is no doubt if we are dealing with one or the other.
Did you know that you can call some method on null value ? Yes… something that is not possible in Java:
It’s quite possible in objective-c:
In objective-c will be no error and return value from
[person getName] will be also
Why is that ?
Invoking a method on nil returns a zero value. This greatly simplifies expressions, because we don’t need to check for nil before doing anything.
For example expression:
Can be simplified to this:
In objective-c we have four ways for describing “nothingness” (as if one way wasn’t enough …).
NULL - it’s equivalent to null value for C pointers
nil - it’s equivalent to null value for Objective-c objects
Nil- it’s equivalent to null value for Objective-c classes
NSNull - it’s Singleton object used to represent null
There were of course also good things related with my iOS experience.
As an Android developer I create many Android xml layouts on daily basis. You can approach this problem in two ways. One is dragging them and placing in visual editor which is not precise and can lead to unexpected behaviour.
The other one is, my favourite, xml editor and I assume that most of Android Developers are using it.
When I began creating my first layout I was pretty surprised. It’s possible to create visual editor that works! It’s even possible to bind fields references, touch actions by simply draggin them from properties of visual object to class file. It’s easy and I must say beautiful.
Another nice thing is iOS built-in xcode emulator which is fast. Compilation takes much less time than Android emulator and programs are running faster.
I mentioned earlier that we can mix “c” language with objective-c which is great feature and we can communicate with one another without using any bridges or stuff like that.
The aversion fog clears out
Two weeks have passed and after a lot of cursing I began getting used to this strange syntax, naming conventions and whole other iOS platform specific things. Everything is more normal now and I feel like everything has more sense to it and writing code is more intentional and precise.
Even crazy method syntax became clear now. I wrote that method writing convention was over complicated and saying (by Apple) that it’s for better readability was farce for me. But it was opposite in the end, it’s indeed better approach.
Again, let’s take a look on addUserToDatabase example and consider two developers “A” and “B”. Developer “A” is born and raised in New York. Developer “B” is born and raised in London.
In Java developer “A” could call it like this:
Which is correct use of this method because company that will be using this database is located in Poland (where salary is paid monthly). But let’s imagine that developer “A” gets another job and company is hiring developer “B”.
Developer “B” has a lot of work and his software company told him to create database for another client.
He knows more or less that there is method
userName as first parameter ,
salary as second and
bonus as third.
“B” comes from England where salary is paid weekly so seeing that there is no
getWeeklySalary he creates this method and his code will look like this:
Job is done but client’s workers get 1/4 of desired salary…
Let’s consider the same situation but our heroes “A” and “B” are objective-c developers.
Developer “B” comes from England and creates implementation with weekly salary:
He wrote the code but discovered that something is not quite right.
He focused his gaze on
payHimMonthly:weeklySalary part of method call and he scratched his head.
Then he has opened the class with
addUserToDatabase method and after quick code inspection, and asking few colleagues, he found out that in Poland they pay salary monthly.
If there was no label in method code he could do a grievous mistake and make trouble for his company client, its workers and in the end on his software house. Of course this example is pretty abstract and simplified but I think that readers are getting the picture. Adding those labels may seem excessive but when label is properly named It can benefit in more readable code.
iOS trip ends
My simple application is done, most of the aversions are gone. I was wrong with bad judgements on objective-c and whole iOS platform and I feel a little bit ashamed. But on the other hand I am proud and happy that I had the need to explore this subject and in the end changed my unfair opinion.
I think that with more spare time I’ll create more iOS apps and learn more about objective-c and its ecosystem. I thoroughly encourage you all to learn different programing languages and expand your knowledge.
Remember, don’t judge book by its cover.