My Awesome Technical Creations!!!

Hello Readers,
Today on Thanksgiving, I decided to write a new blog for all the things we can be thankful for...
Family
Friends
iPhones :)
While we surely get to meet our friends and family often and learn more about them at some point of our lives, do we get to learn in depth about our iPhones?
or let me reframe the Question, do we know the Architecture of our iPhone really well?
Let's begin with a few basics of Architecture...(Warning: This blog is going to be all informative and amazing, so be prepared to read a lot here! nonetheless, I shall try my best to make it as interesting as possible)
The iPhone internal structure is made up of 4 layers( like 7 layers of web platform)
1) Core OS( the bottom layer)
It comprises of OS X Kernel, Power Management,MACH 3.0(UNIX Based, actually iPhone uses UNIX based platform,surprise!!), Keychain,Access,BSD,Certificates,Sockets,File systems,security,Bonjour(we shall see these in depth as we tread along our iPhone journey)
2)Core Services(the second most layer from the bottom)
It is made up of Collections,core-location,address book,net services,threading,networking,SQLite,File Access,Preferences,URL Utilities(note that this layer uses object oriented scenario and uses mechanisms like grand central dispatch for threading, and can also be used to open HTML and related pages and guess where your location is at etc etc)
3)Media (ipod /player at heart)
It consists of Core Audio,Image formats(jpg,png,tiff),Quartz(2D),Audio Mixing, Open AL,Open GL ES, Video Playback.
4)Cocoa Touch(top most layer)
It is very very object oriented. It uses multi touch,alerts, core motion(eg accelerometer, gyro etc) Web View, Map Kit, Localization/Internationalization,View Hierarchy,Image Picker,Controls,Camera.
We shall relate all of these terminologies with the iPhone apps we create later on, one by one, in a fun filled way!
Beginning with the platform Elements or Components,
The Tools we need for iPhone application development are:
XCode( which is an IDE as discussed in my previous blogs, more or less like dreamweaver),
IB(Interface Builder)
[Common myth about Interface builder is , using it not a good programming practice as it might create a confusion about how things work out in the end, but it is not always true, until your project is humongous and complex, then it's best not to use an interface builder],
Instruments
Usually used for Managing Memory, finding out leaks in memory and such.
The Language employed would be Objective C( you can also use hint of c /c++, if you're really good at that, along with objective c we do use JScript and associated libraries,HTML,Basic SQL(SQLite), JSON, and other light languages either to enhance the effect or make programming easier)
The Frameworks involved are: Foundation/Core Data/Mapkit/UIKit/Core Motion etc etc.
Now let us take a close look at the iPhone app Design.


Now now, the diagram has a few limitations, which we shall discuss eventually as we tread along.
Now model class is basically a "what-where-when" class, which means, it basically takes care of objects, in the way they are, not how they are, say suppose, you have a game application for a ninja game, you ask what are the names of the ninjas, what ninjas are present( a,b,c) , where are they present, when are they present, not how
Never ask a how based question to a model class, as it deals only with the what scenario of objects at hand. It is very important to understand that a model DOES NOT communicate with the controller at all, it is like a slave who listens to instructions of the controller and carries them out, It has a small Notification/KVO(Key value observing) signal which alerts and updates the controller about the changes or alterations in its contents( suppose say a ninja dies and is removed from list or level has changed etc)
This scenario of observations is termed as 'tune-in' mechanism.
Moving on to the controllers, we find out that it is the heart of the app,It takes care of all activities involved,which include controlling the view and model and letting them know HOW to perform those set of activities.A controller sends instructions to both model and view and it is responsible for the working of objects, In grammatical sense, a model is the noun and a controller is the verb which a view is the adjective.
A controller basically takes care of UI Logic
It has a radio station signal through which it receives the updates from the model.
The view is a minion of the controller, it displays the UI contents ( like buttons, test boxes etc)
It is the human readable/viewable interface on your iPhone, and it is not allowed to communicate with the controller entirely( only in 3 ways though)
Target-Action : Having a target set on the controller and through action get to that target alerting controller what action has taken place, whether a button was clicked or a a name was placed in the text box.
Delegate: As I mentioned delegates technically in my previous blog, in the architectural sense, it means A delegate is like a representative which lets the controller know what it did or what it should be doing upon completion of certain activity( say view did load then do this , or certain buttons should appear upon completion of certain activity)
Datasource: Views do not own data they display. They take care of data at or count by asking the controller for it, (eg : say it asks the controller give me data at row 6 or 8 etc), for this a datasource on controller is defined which fetches the data for it, thus restricting communication with the entire unit, more so a blind communication. Views are like dumb units which just do things as instructed, how it is done, is none of their concern.
In iPhone you have to carry out memory management yourself and as mentioned earlier it uses Objective C extensively which means it relies on dynamic binding extensive unlike c/c++(dynamic binding simply means whatever code is executed is not seen until it is actually sent at runtime)
Protocols like delegate and datasource help greatly with the process of dynamic binding.
We shall see all of these in action in the upcoming tutorials.
In this way life of an iPhone app starts with the very basic model part ,goes through controller phases, back and forth and displays the output on the view, where it ends, once the user decides to exit the app.
This pretty much covers the base lifecycle of an iPhone in depth, we shall see more of life cycle and more exciting things with apps and I shall provide the code for a few apps I make in the upcoming blogs!
Stay "tuned-in"!!!
and don't forget....

With Love and respect,
Vishwan Aranha