Sorry for asking this type of simple question here.
But I am new at iOS development :( also i am trying on google for find my answer but i don't get it.
My Question is that which protocol method of UITableView is call after created whole TableView ?
i mean when create UITableView then call UITableViewDataSource method such like ,
Configuring a Table View
– tableView:cellForRowAtIndexPath: required method
– numberOfSectionsInTableView:
– tableView:numberOfRowsInSection: required method
– sectionIndexTitlesForTableView:
– tableView:sectionForSectionIndexTitle:atIndex:
– tableView:titleForHeaderInSection:
– tableView:titleForFooterInSection:
etc...
But i want to know which method of UITableView call after creating whole TableView (OR call above methods) without any UITableView interaction ?
so, please help me
Since the order is not specified in Apple's documentation, you cannot safely assume that they will always be called in the same order and it is generally not a good idea to make such assumptions in your implementation.
For example, cellForRowAtIndexPath is not called for all rows. It is only called for visible rows and then called for additional rows as the user scrolls to them. Old rows are also destroyed as they go off the screen and it will request the cells again if the user scrolls back up.
But in general we can assume some Order of call:
– numberOfSectionsInTableView: (...Optional method...)
– sectionIndexTitlesForTableView: (...Optional method...)
– tableView:titleForHeaderInSection: (...Optional method...)
– tableView:titleForFooterInSection: (...Optional method...)
– tableView:numberOfRowsInSection: (...Compulsory method...)
– tableView:cellForRowAtIndexPath: (...Compulsory method...)
For creation of UITable all required method has to called. i.e.
– tableView:cellForRowAtIndexPath:
– tableView:numberOfRowsInSection:
Off course these are datasource method . But after creation of the table none of this method called until you reload the table.
If you want method that called after creation of the tableview you have to look for delegate methods like:
– tableView:willSelectRowAtIndexPath:
– tableView:didSelectRowAtIndexPath:
– tableView:willDeselectRowAtIndexPath:
– tableView:didDeselectRowAtIndexPath:
Related
There are 2 forms in my program. When view controller A gets the focus and be active, view controller B will lost the focus and be inactive. Can anyone show me What the events are?
Thanks
Miken, it depends on what type of objects you are using for your "forms".
The simplest "form" to use is a UITextField, and in that case, events will be sent to your UITextField's delegate. In a lot of simple cases, you will designate the viewController that holds your UITextfield to be the UITextFieldDelegate. For more information on the methods that the delegate has, take a look at this: https://developer.apple.com/library/ios/documentation/uikit/reference/UITextFieldDelegate_Protocol/UITextFieldDelegate/UITextFieldDelegate.html#//apple_ref/occ/intf/UITextFieldDelegate
In this case, when the text field gets the focus (ie the user clicks on the text field to edit it) the delegate methods:
– textFieldShouldBeginEditing:
– textFieldDidBeginEditing:
– textFieldShouldEndEditing:
– textFieldDidEndEditing:
will be called. I'm using this as a basic example, and not assuming too much here, but generally you should be looking into your "forms" delegate methods.
I have been practicing with table views and I know how to create them but I would like to have a better understanding about delegate and source when creating table views.
Can someone explain the need for a delegate and a source when creating table views?
Why do you need them?
What is happening when you connect delegate and source to File’s Owner or ViewController and why they need to be connected?
I guess I need a general explanation about delegates and source and what happens when you connect them to File’s Owner or ViewController?
The delegate and data sources allow the tableview to conform to the MVC design pattern, which is a recurring design pattern in Cocoa and Cocoa Touch.
The TableView itself provides the [V]iew part and the delegate provides the [C]ontroller part while the data source provides the [M]odel part.
When you connect the delegate and datasource in the NIB file you are creating this connection visually; you can just as easily do it programmatically.
Delegate:-
A delegate is an object that acts on behalf of, or in coordination with, another object when that object encounters an event in a program. The delegating object is often a responder object—that is, an object inheriting from NSResponder in AppKit or UIResponder in UIKit—that is responding to a user event. The delegate is an object that is delegated control of the user interface for that event, or is at least asked to interpret the event in an application-specific manner.
Data Source:-
A data source is like a delegate except that, instead of being delegated control of the user interface, it is delegated control of data. A data source is an outlet held by NSView and UIView objects such as table views and outline views that require a source from which to populate their rows of visible data. The data source for a view is usually the same object that acts as its delegate, but it can be any object. As with the delegate, the data source must implement one or more methods of an informal protocol to supply the view with the data it needs and, in more advanced implementations, to handle data that users directly edit in such views.
For Detail info goto
http://developer.apple.com/library/ios/#documentation/general/conceptual/CocoaEncyclopedia/DelegatesandDataSources/DelegatesandDataSources.html
You dont need to make any connections if you are happy to write the following code:
tableview.delegate=self;
tableview.dataSource=self;
The UITableViewDataSource protocol is adopted by an object that mediates the application’s data model for a UITableView object. The data source provides the table-view object with the information it needs to construct and modify a table view.
Example:
Whereas a data source type object gives data to another object. For example again, the UITableViewDataSource protocol has methods such as cellForRowAtIndexPath and numberOfRowsInSection dictating what should be displayed in the table
The UITableViewDelegate of a UITableView object must adopt the UITableViewDelegate protocol. Optional methods of the protocol allow the delegate to manage selections, configure section headings and footers, help to delete and reorder cells, and perform other actions.
Example :
A delegate type object responds to actions that another object takes. For example, the UITableViewDelegate protocol has methods such as didSelectRowAtIndexPath for performing actions upon a user selecting a particular row in a table.
If your programming language doesn't support multiple inheritance, you must use delegate method. When you implement delegate method, you can use object functions such as super class. Example :
// define tableview row count
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return 1;
}
// define tableview height
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
}
// define specific tableview cell
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
UITableViewCell *cell = MyCell();
return cell;
}
I have just been learning iPhone apps development but I have a hard time in understanding what delegate actually means? Can anyone tell me with example what it does and how important it is? Thanks for any helps!
It's a key concept to understand conceptually so getting your head around how to think about it ahead of the technical details is important. Simply put, a delegate is a callback.
Two main scenarios to use delegates:
A class or control wants to abstract out the details on how to do work (like retrieve data).
Allow others to hook code into a pipeline.
Examples:
UITableView - a table view is just a control that knows how to render a list of cells. It handles all the heavy lifting of rendering, scrolling, etc... But, it has no idea how to load your data. So you implement a datasource delegate which has methods to get the cell data for a given row etc... That makes it easy on you. You just use the control and plug in the specifics for your data. The UITableView will do everything for you ... just answer a few specific questions for. A delegate answers those few specific questions.
A text control - you add a text control to your view and voila! you can type in it and alls good. But what if you want to do something when they start typing or when they're done typing? Well, the text control offers a delegate with methods that allow you to hook into the execution pipeline of the text control. It allows the text control to do everything for you and allows you to interject code where you need it. Many times, there's way to interject code to make a decision on whether something is allowed. The control will call back and ask, should I be able to do x? You can interject code and influence the behavior.
If you're creating a control or class, you can create your own protocol, datasource delegates etc... so your control can focus on doing what's advertised. For example, let's say you wanted to create a task control. You could:
First, create a contract. Hey, if you're going to provide data for my control, these are the questions I'm going to ask you. I'll take it from there... In this case, I'm going to ask you the number of tasks and I'm going to have you give me a task given the row number.
#protocol XXTaskBoardDelegate <NSObject>
-(NSInteger*)getTaskCount;
-(XXTask*)getTaskForRow:(NSInteger*)rowNumber;
#end
In the control or class, give the consumer a way to give us the delegate datasource class that will answer the questions the control will ask. At this point, the control is a pure control. It knows nothing about how you get your data. It's asking for an object (id) that implements a contract/protocol. id
#implementation XXTaskBoard
- (void)setDelegate:(id<XXTaskBoardDelegate>)newDelegate
{
// the control stores the delegate so it can callback and ask you questions.
}
Then, for the delegate class, in the header declare you implement that formal protocol
and in the implementation m file you provide the code.
#interface AppController : NSObject<XXTaskBoardDelegate>
{
//...
}
then, implement it in the implementation
#implementation AppController
- (NSInteger*)getTaskCount
{
return [model queryTaskCount];
}
- (XXTask*)getTaskForRow:(NSInteger*)rowNumber
{
return [[model tasks] getItem:(NSInteger*)rowNumber];
}
A delegate is an object that another class can pass messages to. In practice delegate classes have to conform to a delegate protocol.
For instance we will take a subclass of a table view controller. This is a delegate for your table view. First you define that it is a table view delegate by doing this:
MyTableViewController : UITableViewController <UITableViewDelegate>
This says that class MyTableViewController is a subclass of UITableViewController and CONFORMS to the UITableViewDelegate protocol.
Setting [tableView setDelegate:self] (or defining it as such in IB) then passes the self object to the tableview in order for the tableview to send messages to it.
The main message it sends is the didSelectRowAtIndexPath message which tells your class that the user has pressed a table view cell.
So the object that takes the click event (the table view) passes on the message that the cell has been clicked to the delegate object (which in this case is your MyTableViewController object).
Delegate protocols exist so that you can make sure that the delegate object has the necessary methods to deal with your messages. Methods in a delegate protocol can be #optional or enforced. Any methods that are optional don't have to be defined. In your MyTableViewController class the method didSelectRowAtIndexPath is optional - you don't have to have it. If the table view doesn't find the method it just won't call it.
However the cellForRowAtIndexPath is necessary and without it your app won't compile.
I hope this helps and is straightforwards for you. If you need any more info let me know.
Delegates are just way of getting callbacks from something. You pass a delegate (a pointer to an object that conforms to a protocol) to something and when it has new data for you or when an event occurs that something make a method call on the delegate.
For example, when events occur, like your app is put into the background or the app is about to terminate the UIApplication object will call your application delegate to let it know. When a CLLocationManager has a new GPS position is will call your delegate to pass it the new position. UITableViews call their delegates to get UITableViewCells to display in the table. There are many uses of delegates in iOS.
In what order are the following methods called for a UITableView?
numberOfSectionsInTableView
numberOfRowsInSection
cellForRowAtIndexPath
heightForRowAtIndexPath
didChangeObject (NSFetchedResultsController)
Please include any other pertinent hook methods that I may have left out.
I would be wary about being concerned with the order in which these methods are called. These methods have very specific, and complete purposes. Even though the methods are called in a certain order right now, that doesn't mean they will always be called in that order so it is dangerous to make assumptions in your code as to what order they are called. For example, cellForRowAtIndexPath is not called for all rows. It is only called for visible rows and then called for additional rows as the user scrolls to them. Old rows are also destroyed as they go off the screen and it will request the cells again if the user scrolls back up.
Bottom line, since the order is not specified in Apple's documentation, you cannot safely assume that they will always be called in the same order and it is generally not a good idea to make such assumptions in your implementation.
I eventually did use NSLog statements to figure this out but unfortunately didn't document it. For, I realized that the order those functions are called didn't matter.
Reading about Batch Insertion, Deletion, and Reloading of Rows and Sections in the Table View Programming Guide for iOS I learned to update the data before inserting rows in the table view.
for example we use this method in the tableview
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 16;
}
i want to learn we don't call this method in anywhere but application reads this value how is it being? there are a lot of methods like this we did not call.
Your object has been set as the data source of the UITableView somewhere. Most likely, by making a connection in InterfaceBuilder, though it is straightforward to do so in code by setting the dataSource property of the UITableView:
- (void) setUpMyJunkMan
{
myTableView.dataSource = self;
}
Once you have set your object as the data source, the table view will invoke the method as needed to determine what it needs to draw or how it needs to respond to events.
Your object is required to implement the UITableViewDataSource protocol (though, if you connected the data source via InterfaceBuilder, there may not be a complaint if you don't -- it is more of a compile time validation than a runtime one).
If you look at the declaration of UITableViewDataSource, you'll see that a number of methods are #optional. The rest are #required; you must implement them to fulfill the contract of the protocol.
This is the key difference between data sources and delegates. Delegates can optionally implement any of the declared methods. Data sources create a much more formal relationship between the two objects wherein some of the methods must be implemented.
An easy way see why a method is being called - set a breakpoint, run in debug mode, and then look at the stack trace.
For this particular case - It's being called automatically by the framework when it renders the table view.
I think you really need to take a look at The Table View Programming Guide so that you have a good understanding of what methods you need to override (and not override) when using Table Views. If you are extending the TableViewController class the framework does a lot of the heavy lifting and you barely have to write any code.
numberOfSectionsInTableView: is being called by the table view.
You implement numberOfSectionsInTableView: as part of the UITableViewDataSource protocol. Each UITableView is given a dataSource. Normally, UITableView will be constructed by a UITableViewController which will set itself as the view's dataSource.
When the view is shown, it calls numberOfSectionsInTableView: on its dataSource.
This is explained in the Table View Programming Guide for iPhone OS.
This is part of a Delegate Interface.
At some point in your application (possibly in your UIBuilder) you have specified that the object that contains the method is actually the delegated object. This means that when you want to adjust the behaviour (in this case of a UITableView) you can without actually extending UITableView but mearly changing the delegate methods.
basically the UITableView class will look somehting like this.
- (void) AMethodinUiTableView
{
int colums =[self.delegate numberOfSectionsInTableView:self];
}
for more info i would check out delgate programing and selectors.