Data and Accessor Properties

In order to define a property we use Object’s defineProperty method on a particular object. There is the value we want to initialize with, which is the passed in parameter of var firstName. The second writable simply means if we can write over it.

Creating Objects and Factory Functions

javascript old school way of creating objects:

New style of creating object

Factory functions

Passing in parameters

Thus, you can just go

Constructor functions

‘this’ keyword

ref –


property—a variable with the value of the object that invokes or calls the function where this is used.

“my name is ricky”.

The this reference ALWAYS refers to (and holds the value of) an object—a singular object—and it is usually used inside a function or a method, although it can be used outside a function in the global scope.

The use of this in the global scope

In the global scope, when the code is executing in the browser, all global variables and functions are defined on the window object. Therefore, when we use this in a global function, it refers to (and has the value of) the global window object (not in strict mode though, as noted earlier) that is the main container of the entire JavaScript application or web page.

var firstName = “Peter”,
lastName = “Ally”;

function showFullName () {
// “this” inside this function will have the value of the window object​
// because the showFullName () function is defined in the global scope, just like the firstName and lastName​
console.log (this.firstName + ” ” + this.lastName);


this scope, another example

johnDoe.greet(); //my name is john doe
globalGreet(); //my name is r t

this keyword is ‘attached’ to the object that is calling the function

Using Bind

The bind function binds the calling object to another scope. For example, we we are binding globalGreet to the window scope, instead of the var johnDoe scope. Thus, the calling object would be window, and therefore, this keyword would be referring to the window. This means we would be using, instead of

johnDoe.greet() will display “my name r t”

Primitives and Objects

Primitive types:

  • String
  • Number
  • Boolean
  • Undefined
  • Null

Reference types. Objects:

  • Object
  • Array
  • Function
  • Date
  • RegExp



But how?

new String(“hello”).length;

notice the constructor

type of obj –> “object”

typeof String(“hello”) –> “string”

obj.valueOf(); –> “hello”
typeof obj.valueOf(); –> “string”

Only way to create object is by using new String. All others will give you a string.


//notice the constructor

typeof num; –> “object”
typeof 10 –> “number”

typeof Number(10) –> “number”
typeof num.valueOf() –> “number”

remember that our num is an object

typeof sum; –> “number”
typeof num; –> “object”

Even though num was used in a numeric operation, it did not get converted to number.

Cannot assign properties and methods to Primitives

For example

If we change num to object, then we can assign property and methods:

Identity vs Equality aka (strict vs abstract)

=== is called Identity Operator compares value AND type.

== will do type conversion. Namely, it converts the type down to a comparable value and match that way.

Notice that true != “true”, I want to comment that by rule 5, since true is Boolean, it gets converted into a number.
Hence, 1 != “true” is true.

Similarly, remember that in “==”, from rule 5), booleans are converted to numbers first.

Null manipulation

remove storyboard and start with empty project

ref –

Xcode 5 and 6 introduced some changes in iOS project templates, which may or may not be to everyone’s taste. This mini-tutorial shows how to create a pre-Xcode 5-style Single View Application based on xib files, and and a pre-Xcode 6-style Empty Application, using Xcode 6.

You get not only a Main.storyboard file, but also a default LaunchScreen.xib file. Some developers prefer Storyboards, and some do not. It’s relatively easy to modify a project to get back to what a pre-Xcode 6 Empty Application template created; a second modification gets you from there to a “standard” xib-based application, à la Xcode 4. (It should be possible to create custom Xcode 6 templates for both of these types of projects, but that will require some research and experimentation).

The first step is to remove Main.storyboard, LaunchScreen.xib, ViewController.h, and ViewController.m—select them all, right-click, and choose to either remove them from the project, or delete them completely.

If you run the app at this point, you’ll get an exception: “Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘Could not find a storyboard named ‘Main’ in bundle…” This is because the project is trying to use that storyboard file you just removed. This information is in the project’s Info.plist, and the entry is “Main storyboard file base name”:

To fix this, simply remove the entry (select it and hit delete or hover and click the remove icon). Running the app now will just get you a solid black window, because there’s simply no code present that will create one for you. We’re just one step away from the equivalent of an Xcode 5 Empty Application. Open AppDelegate.m, and edit applicationDidFinishLaunchingWithOptions so that it looks like this:

In order to get to the functional equivalent of an Xcode 4 Single View Application, we need to add a View Controller. The first step is to add a subclass of UIViewController. Use ⌘-N or the File->New->File.. menu item to create a new file, and select “Cocoa Touch Class”.

The next dialog asks you to name the class; I cleverly called mine “ViewController”. Make it a subclass of “UIViewController”. If you are doing everything programmatically, do not check the NIB box.

This will create 2 files in your project: ViewController.h, ViewController.m

Running the app at this point will give you the same behavior as before, as we’ve not yet told your app to actually use the ViewController. To do this, we need to add a property to the AppDelegate, to hold the ViewController; edit AppDelegate.h so it looks like this:

Finally, we need the AppDelegate to create and make use of the ViewController. Add an import directive to AppDelegate.m, so that it knows about the ViewController:

and then edit didFinishLaunchingWithOptions so it looks like this:

Instead of simply making the window background white, we tell the app to make us a ViewController from the new xib file, and use it as the root view controller (thereby eliminating the warning we saw earlier). At this point, we have what Xcode 4’s Single View Application template created: a minimal, non-storyboard-based app with one xib file.

dynamic binding vs static binding

ref -

Dynamic binding is determining the method to invoke at runtime instead of at compile time. Dynamic binding is also referred to as late binding.

In Objective-C, all methods are resolved dynamically at runtime, due to having every class must derive from NSObject. The exact code executed is determined by both the method name (the selector) and the receiving object. On the other hands, functions such as NSLog or abs, fabs, etc are statically bound. They are determined during compile time.

Dynamic binding enables polymorphism. For example, consider a collection of objects including Rectangle and Square. Each object has its own implementation of a printArea method.

In the following code fragment, the actual code that should be executed by the expression [anObject printArea] is determined at runtime. The runtime system uses the selector for the method run to identify the appropriate method in whatever class of anObject turns out to be.

Parent class – Shape

Child class Square

Child class – Rectangle


Now when we compile and run the program, we will get the following result.

2013-09-28 07:42:29.821 demo[4916] The area of square is 100.000000
2013-09-28 07:42:29.821 demo[4916] The area of Rectangle is 50.000000

The parent class pointer will know which method to execute because it will dynamically bind the correct method to the object at hand. Note that we can also do it with

because id is a generic pointer.

Namely, ff you have a reference that’s of parent type at compile type, you can assign a child type to it at runtime. The behavior of the reference will change to the appropriate type at runtime. A virtual table lookup will be done to let the runtime figure out what the dynamic type is.

Another exaplantion:

Dynamic binding – This is a step beyond late binding where it is left to runtime to determine if the referenced item exists. A simple example in Objective-C:

Static Binding

Static, compile time binding is easy. There’s no polymorphism involved. You know the type of the object when you write and compile and run the code. Sometimes a dog is just a dog.

Static binding: is where the item being referred to is determined at compile time. In (Objective-)C(++) a call to a function is statically bound; for example the library functions fabs and NSLog.

Also references to variables are static in these languages; which variable is being referenced is determined completely at compile time. Static binding cannot fail at runtime, it is a compile time error to fail to determine what a statically bound reference refers to.



@synthesize will generate the getter and setter methods of the properties if the getter and/or setter has not already been implemented manually. This is what you currently believe @dynamic does.

@dynamic is used when you don’t want the runtime to automatically generate a getter and setter AND you haven’t implemented them manually. Basically, @dynamic is telling the compiler that the getter/setter will be provided dynamically at runtime or provided elsewhere, like a base class.


Since @dynamic means that the getter and setter methods are implemented elsewhere. One of the ways is to have runtime look for them in a Base class.

For example, say we have a Base class, and we implement the getter/setter methods like so:

When we use self.publicAge, we use the getter/setter properties generated by the compiler. If we want to manipulate the instance variable itself, we use _publicAge.

Same goes for publicName.

If we want to write our own customizable methods, we’d do:

In which case we over-ride the get/set methods generated by the compiler with our own custom get set methods. Whether you want to use the generated or your own custom methods is both fine, depending on your needs.

Using @dynamic

Now this is where using @dynamic comes in.

Say you have a class Child1, which is derived from the Base class.

@dyanmic means the getter/setter methods are implemented by the self class, but somewhere else
like superclass (Base), or be provided at runtime.

Hence when you use the properties

they will use Base’s publicAge and publicName getter/setter methods.

Core Data part 1 and 2 – data model and data stack


Create a Single Project

name it “CoreDataTut”

We’re going to do everything by scratch so do not check the Core Data box. Leave it blank.

Generate a xcdatamodeld file

Once the project is generated, look at your list view on the left side. We need a .xcdatamodeld file, which represents the model diagram of our entities. The reason why is because core data code need to use a .xcdatamodeld to initialize a Managed object Model, which it uses to save state and data.

See how to create a data model here

In our core data stack, we actually load this file into an NSManagedObjectModel object.
Make sure that the name of your data model . xcdatamodeld file matches that of the name you use in your code. We do this by using global #define as noted in the code below.

The core data stack

First we make a singleton object out of Core data’s basics by creating a singleton class that houses

  • NSManagedObjectContext
  • NSManagedObjectModel
  • NSPersistentStoreCoordinator

From a picture perspective, core data’s basic parts are connected like this:


Create the source file:


Click on Cocoa Touch Class, and input “THCoreDataStack”. The subclass should be “NSObject”.


THCoreDataStack.h source


Managed Object Model

The lazy loading and getter method of our MOM.

The mom and momd files are compiled versions of xcdatamodel and xcdatamodeld files…so here we’re just saying that we need to allocate a NSManagedObjectModel object and init with the compiled versions of our xcdatamodeld files.

Basic lazy loading of the PSC, and its getter. When creating the PSC, we use a #define macro for the sql’s file name.

Managed Object Context – scratch pad for DB changes

This MOC is basically a scratch pad for database changes. Later, when you save context, it will be reflected to the Persistent Store Coordinator, and thus, the database.
We have basic lazy loading and get methods for the MOC.

Saving the Context

This method is called right after an Object is returned from the MOC designated to be inserted or changed.

That way the MOC’s changes are safely saved.