iVars vs @properties in Objective-C

My pondering re: Objective-C the past week:

Do not use instance variables (ivars) when creating or accessing properties.

Always use self + properties to access your variables. For several reasons:

(1) It provides an easy way for other developers involved in the project to debug and set breakpoints.

(2) Properties are ultimately encapsulations of data and methods. Think of it as a universal standard for accessing the data encapsulated by the object (namely the getter and setter methods, and memory offsetting).

(3) If we later decide to implement a feature which uses KVO or KVC (key-value observation & key-vaue coding) the code will not be able to detect a change if we use instance variables.

Oftentimes mobile developers will engage in religious wars over the use of ivars; arguing that because direct access to ivars bypasses method dispatch and thus increases speed and efficiency. This is true. But only by nanoseconds. (source: https://www.bignerdranch.com/blog/should-i-use-a-property-or-an-instance-variable/)

Finally, (since I know I’ve already filled the thread with plenty of* snoretech mumbo jumbo). Declare your properties in the implementation file’s interface. Because of iOS’s non-fragile Application binary Interface (ABI), we don’t have to worry about memory offset issues. Any instance variable will be properly matched with it’s space in memory due to the ABI so there’s no reason to worry about client clashes.

Plus it’s just less ugly.

And I like pretty code.

First week at my big boy job

So I got a great job with a company called Pangea. In one week I’ve learned more about building iOS applications than a week studying on my own. I’ve been working with my mentor Jorge Kinejara. The man–besides being a great guy–is also a fellow Naruto fan. In our short time together he’s introduced me to tagging, enlightened me on UIAlertviews deprecation in iOS 8 (I had no idea), and advised me on the pros and cons of certain iOS design patterns as applied to specific scenarios More updates to come this Monday.

Time to reawaken

So I haven’t been doing much with this blog unfortunately but I’m hoping I can change that. I’ve realized that there is something to be said about writing your efforts down.

The first change I’m going to make is revising the purpose of the blog. It is to chart my journey to becoming a software engineer. My programming skills have improved dramatically, but I still feel far behind when it comes to learning engineering proper. This may take the form of me posting things I find interesting or things I’ve found helpful, or things I’ve learned.

The second purpose of this blog is to provide people like me who are teaching themselves to enter this new field a space where they can read and discuss content. The third is to provide a space for underrepresented groups to discuss their experiences, and to provide a lens into what it’s like being a URM in a Cis White world.

With that said, here we go.

First Post

Someone from my Bootcamp recommended that I try to explain what I learned each day in an effort to maximize retention and to show what it is I’m learning. So here’s a concept I was familiarized with today: MapKit. 

Mapkit is an interface for embedding maps directly into windows and views. Today we covered the major basic behind it. This marked the first time we utilized a framework outside of Foundation.

Other interesting tidbits: mutablecopy is this nifty method that lets you turn an array to a mutable array upon command (Kevin showed me that! Pretty awesome).

I also cleared up some confusion on typecasting. I’ll try posting some of my basic code later.