Terminology question re Objective-C / iOS

Sorry if this sounds like a bit of a noobie question, i'm still relatively new to ObjC and iOS but not new to software development, however, when reading documents / watching videos on various topics, I hear certain phrases that i'm not sure about, could someone take a moment to give a very brief description of the following terms - or, point me to a good reference for them.

I'll list below the terms i'm stuck with and what I think i've figured it is/means and any help in correcting me so I can follow the flow of Apple's documentation better would be heavily app开发者_C百科reciated.

1) Singleton

Possibly similar to a wholly static class in PHP, has no instance methods

2) Model, View, Controller (MVC) organisation - specifically the 'model' component

I know the broad definition is keeping things seperate, what I think this equates to is your view would be what you build to output to the screen either programatically or in interface builder, the controller would be the code that handles messages (clicks, taps etc) from the view and pushes information into the view although in many cases the .xib and .h/.m pair which form view and controller are part of the same family (ie, MyViewController.h/.m/.xib). The model in my guesswork is where seperate handlers for reading and writing data to/from a source, eg, a class which you send messages to which can load and return data from an SQLite database or from an XML feed and process it.

3) Where is the right place for the * when talking about object types?

I know the * means a pointer but i've seen things written like the below, looking like they mean the same thing:

NSString *myVar;
NSString* myVar;
NSString * myVar;

I understand the * goes after the type in a message header eg:

- (void)myMessageHandler:(NSString *)str;

4) When to use NSInteger versus just plain int?

This is the one that might make me look an idiot but I have to ask it as i'm not sure when to use which and I see many different examples where it's mixed.

5) Reusable entity identifiers

When de-queing/creating objects that work via the re-use queue, I see the same identical identifier used each time (eg for a UITableViewCell, @"cellIdentifier"). However, what I see is that the cell is reset with the relevant row data each time rather than simply stored on the queue, this confusion comes from tables in HTML where to address each row, you either traverse the DOM or add an ID tag to each row which is unique.

I think this is a memory management thing whereby you wouldn't really notice what's going on if you're using the default class but if you were using different custom classes, I assume the idea is you instantiate one of each type only per parent class instance (eg UITableView) so that even though you reset the properties each time, the total memory required is minimal and the instantiation time is taken out of the loop as you only do it once?

A part 2 to this question would be if I have an app which has multiple view controllers pushed onto each other, would it be advisable to use a unique identifier which relates to a specific view so if I was using custom subclasses, the identifiers wouldn't cause an overlap and probably a memory leak.

eg, UITableView pushes a map which pushes a UITableView when an annotation is selected, if I used "cellIdenfier" as my re-usable identity name in both UITableView's but the second one used a custom class for UITableViewCell, when I return to the top view, would the system not potentially return me the wrong type during the de-queue and cause slightly strange output?

Even though you have accepted an answer, since it is not complete, I'll add to it.

Karl's singleton definition is on the money as far as I'm concerned.

The model is not just the objects storing the data, it's the business logic as well.

As for where the * goes, yes it is a matter of style, but it is subtly incorrect to say it is part of the type in C (of which Objective-C is a superset). This is easily demonstrated with the following:

int* foo, bar;

It does not declare two variables of type int* but a pointer to an int (foo) and an int (bar). So technically you should put the * with the variable name. However, I use the same convention as Karl and avoid the above issue by never declaring variables in comma separated lists.

When to use NSInteger versus just plain int?

You should always use it any time the Cocoa API documents say you should. There is otherwise absolutely no advantage to using it as opposed to a plain int. If you need to guarantee a specific width for an int type you should use the C99 standard ones from stdint.h (int32_t, int64_t etc). If you don't need to guarantee a certain width you might as well use the built in types, except where a Cocoa API gives you an NS(U)Integer. Casting an NS(U)Integer to an (unsigned) int runs the risk of truncating it on some architectures (x86_64 for instance).

Reusable entity identifiers

A UITableView needs one instance for every cell that is currently visible on the screen. Instantiating a cell might be expensive (you might need to go to disk to load a NIB, for instance), so instead of throwing away the cells once they go out of view, the table view will put them in the queue of discarded cells. It's much faster to then pull an unused cell off that queue when you need a new one than it is to instantiate one from scratch.

The reuse identifier is needed because your table view may have cells of different types in it. e.g. one row might have a text field and another row might have a date picker. So if the table view requests a cell for the text row, it would be no good giving it a cell with a date picker.

As middaparka said, you should probably split the questions, but I can answer 1-3.

A singleton is a design pattern meaning there is only one instance of a class in the entire program. It is usually implemented with a static getInstance method that either returns the existing instance (stored as a static variable) or creates a new one if it doesn't exist. Any good reference on design patterns should address it.

For MVC, your idea of a model is essentially correct. The model is where the data is stored. Again, look at a design pattern reference for details.

As for where the * goes, that's largely a matter of style as the compiler will accept any method. I personally prefer to put it next to the type, as it technically is part of the type, but most places I've worked put it next to the identifier. I believe the rationale for putting it next to the identifier is that one of the other uses for * is to dereference a pointer, in which case it makes sense to group it with the variable, and they want to make it visually consistent. I've only seen the spaces around a * when used as a multiplication operator.