Questions captured from: http://albertodebortoli.com/blog/2016/05/28/best-ios-interview-epicfails/ and attempted answers

iOS-questions.md

1. Explain how the memory management works on iOS
2. What is a weak qualifier and when should it be used
3. Explain the MVC pattern
4. Explain the MVVM pattern
5. What are the property qualifiers that define the memory management behaviour?
6. Describe ARC
7. What’s the main problem with ARC?
8. Explain what is dependency injection
9. Is a block an object?
10. Describe the behavior of objc_msgSend?
11. Delegation is a common pattern on iOS and historically well-known, give an example
12. When are the objects deallocated?
13. Why do we use the * for the objects in Objective-C?
14. Describe yourself using JSON
15. Do you know how autolayout works under the hood?

Notes for Question 1.

• There are two methods of application memory management in objective-c:
  • MRR - Manual retain-release where the developer explicitly manages the memory by keeping track of objects he owns.
  • ARC - Automatic Reference Count where the system uses the same reference count as MRR but it adds the memory management calls for the user at compile-time
• An object is owned when:
  • the dev creates it using alloc, new, copy or mutableCopy
  • the dev uses retain
• When not in use, the dev should release the object with release or autorelease.
• The dev should not release (relinquish) an object that does not own

Notes for Question 2.

The difference is that an object will be deallocated as soon as there are no strong pointers to it. Even if weak pointers point to it, once the last strong pointer is gone, the object will be deallocated, and all remaining weak pointers will be zeroed out.

Perhaps an example is in order.

Imagine our object is a dog, and that the dog wants to run away (be deallocated).

Strong pointers are like a leash on the dog. As long as you have the leash attached to the dog, the dog will not run away. If five people attach their leash to one dog, (five strong pointers to one object), then the dog will not run away until all five leashes are detached.

Weak pointers, on the other hand, are like little kids pointing at the dog and saying "Look! A dog!" As long as the dog is still on the leash, the little kids can still see the dog, and they'll still point to it. As soon as all the leashes are detached, though, the dog runs away no matter how many little kids are pointing to it.

As soon as the last strong pointer (leash) no longer points to an object, the object will be deallocated, and all weak pointers will be zeroed out.

http://stackoverflow.com/questions/9262535/explanation-of-strong-and-weak-storage-in-ios5

A week qualifier identifies the variable as a weak pointer to an object. We should use weak pointers when we want to be able to access to it while it still lives but won't need to grab hold of it if no one else is referring to it. For example, writing your own cache management system would be a good example. If the data you're trying to access is still around then you want to be able to access it, but once the values have been destroyed, you don't want to keep the object in memory anymore.

Notes for Question 2:

• We generally use weak qualifier for IBOutlets (UIViewController's Childs).This works because the child object only needs to exist as long as the parent object does (while strong qualifier is used for UIViewControllers (UI item's parents))

http://stackoverflow.com/questions/8927727/objective-c-arc-strong-vs-retain-and-weak-vs-assign

Notes for Question 3.

MVC stands for Model-View-Controller

• Model is responsible to hold/maintain the data
• View is responsible for displaying a portion or the totality of the data
• Controller establishes the interactions between the model and the view

This pattern allows the separation of concepts and responsibilities. There are some variants and different languages/technologies might implement it differently.

Some extra reading: https://developer.chrome.com/apps/app_frameworks

Question 3:

The bank analogy makes it easier to grasp.

http://zenofcoding.com/2009/01/06/another-way-to-think-about-mvc/

Question 1:

In Ruby, the memory management is taken care by the garbage collection (which will Sweep the unused, garbage objects back onto the free list when there are no objects remain on the free list).
In IOS, if you

• need to keep an object around,
  you must retain it unless you know it's already been retained for you.
• want to get rid of an object that you own,
  you need to release it, unless you know it's already been released for you

Hence, ARC is introduced in the way that, if no strong pointer points to it (retain count = 0), the object will be destroyed.

Notes for Question 4.

MVVM stands for Model-View-ViewModel

It is somehow similar to MVC pattern, being sometimes considered da variation of it, but this pattern suggests the implementation of a ViewModel to make the translation of the Model's data into the data needed for the View. In this way, it allows yet another level of separation of concepts.

Notes for Question 5:

http://rdcworld-iphone.blogspot.sg/2012/12/variable-property-attributes-or.html

Notes for Question 3 & 4:

MVVM vs MVC

In MVVM:

• User hits the view first
• User can't see the model

In MVC:

• User hits the controller first
• The view knows about the model
  -Request first comes to the controller.
  -Controller binds the model with the view.
  -Logic is stored in the controller.

Question 8

Dependency injection means giving an object its instance variables.

Fishing Examples

Let's imagine that you want to go fishing:

• Without dependency injection, you need to take care of everything yourself. You need to find a boat, to buy a fishing rod, to look for bait, etc. It's possible, of course, but it puts a lot of responsibility on you. In software terms, it means that you have to perform a lookup for all these things.
• With dependency injection, someone else takes care of all the preparation and makes the required equipment available to you. You will receive ("be injected") the boat, the fishing rod and the bait - all ready to use.

Why using it?

It can make testing lots easier

- Without Dependency Injection
Application needs Foo (e.g. a controller), so:
Application creates Foo
Application calls Foo
Foo needs Bar (e.g. a service), so:
Foo creates Bar
Foo calls Bar
Bar needs Bim (a service, a repository, …), so:
Bar creates Bim
Bar does something

- With Dependency Injection
Application needs Foo, which needs Bar, which needs Bim, so:
Application creates Bim
Application creates Bar and gives it Bim
Application creates Foo and gives it Bar
Application calls Foo
Foo calls Bar
Bar does something

http://www.jamesshore.com/Blog/Dependency-Injection-Demystified.html
http://stackoverflow.com/questions/130794/what-is-dependency-injection

Question 9

Blocks are Objective-C objects, which means they can be added to collections like NSArray or NSDictionary.

https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithBlocks/WorkingwithBlocks.html