iOS development-beginupdates && endupdates usage

This article mainly introduces the use of the Beginupdates and Endupdates methods for batch operation update of the UITableView cell. First, the data sources that are dependent on the process are given:

     Self. Arraysections= [NsmutablearrayArraywithcapacity:0];Nsmutablearray*array1 = [Nsmutablearrayarraywithobjects:@"Apple",@"Alice",@"Apache",@"Amount",@"Application",@"Abort",@"Action",@"Alert",Nil];Nsmutablearray*array2 = [Nsmutablearrayarraywithobjects:@"BMW",@"Beach",@"Boom",@"Band",@"BBBB",@"Baby",@"Bear",Nil];Nsmutablearray*array3 = [Nsmutablearrayarraywithobjects:@"Cache",@"Clean",@"Clear",@"Class",@"Client",@"Count",@"CCC",@"Can",@"Ccccca",@"c1618",Nil]; [ Self. ArraysectionsADDOBJECT:ARRAY1]; [ Self. ArraysectionsAddobject:array2]; [ Self. ArraysectionsADDOBJECT:ARRAY3];

beginUpdatesAnd endUpdates methods are a pair of methods that are bound together to be used for UITableView bulk update operations. Let's take a look at beginUpdates the cases where multiple insertions and deletions are not used endUpdates :

 Nsmutablearray *array1 = (Nsmutablearray *) self.arraysections[<    Span class= "Hljs-number" >0 ];    Operation 1  Delete [array1 removeobjectatindex:0 ]; [Self.tablemain deleterowsatindexpaths:@[[nsindexpath indexpathforrow:0 inSection:0]]     Withrowanimation:uitableviewrowanimationautomatic]; Action 2  Insert [array1 insertobject:@ "Insert"  Atindex:    3 ]; [Self.tablemain insertrowsatindexpaths:@[[nsindexpath indexpathforrow:3 inSection:0]]     Withrowanimation:uitableviewrowanimationautomatic]; Action ...  

This practice for each operation, is strictly in order to execute, first perform operation 1, then perform operation 2 ... When you perform any action, update the data source, and then invoke the related operation of the table view, and immediately call the relevant proxy method to update the table view when the action method finishes executing. After the update is complete, proceed to the next operation ... That is, the entire process is constantly calling the proxy method to update the table view. So for this sequential Update method, each update operation is not at the same time, if there are many operations, can be seen by the naked eye of the update, which is usually not what we want.

Through beginUpdates and endUpdates then you can batch processing operations , different from the above operation one by one and then continuously update the table view, batch processing implemented after all operations have been executed after the call agent method update the table view at once, this method ensures that all operations are eventually updated at the same time.

beginUpdatesand endUpdates Batch updates have trilogy:

1. Update data source (all operations)
2. Create a corresponding indexpaths array
3. Perform actions

The following examples illustrate:

Nsmutablearray *array1 = (Nsmutablearray *) self.arraysections[0]; [Array1 Removeobjectatindex:0]; [Array1 Removeobjectatindex:2]; [Array1 insertobject:@"111"Atindex:1]; [Array1 insertobject:@"333"Atindex:3]; Create the corresponding indexpaths array nsarray *indexpathsdelete = @[[Nsindexpath indexpathforrow:0 Insection:0],[nsindexpath indexpathforrow:2 insection:0]]; Nsarray *indexpathsinsert = @[[Nsindexpath indexpathforrow:1 Insection:0],[nsindexpath indexpathforrow:3 insection:0]];    Perform operation [Self.tablemain beginupdates];    [Self.tablemain Deleterowsatindexpaths:indexpathsdelete Withrowanimation:uitableviewrowanimationfade];    [Self.tablemain Insertrowsatindexpaths:indexpathsinsert Withrowanimation:uitableviewrowanimationfade]; [Self.tablemain endupdates];

The operation between the Beginupdates and Endupdates methods does not immediately update the table view, but instead calls the proxy method to be updated once the Endupdates method returns, so all update animations are executed concurrently.

The table view before and after execution is displayed as follows:

Before execution:

After execution:

After executing this code, the following questions arise:

• Problem One: The proxy method is to update the view based on the data source, since the data source has been updated, and endUpdates after the return of the proxy method will be executed, then beginUpdates endUpdates the operation between and what is the use?

  Guess this process is not so simple, if really just based on the data source update to refresh the view, I update the data source a reloaddata not to be done, but also so troublesome to do! How do you verify this conjecture? It's easy to print out the updated results of the data source to see if the inconsistency with the table view shows that the conjecture is reasonable. The printing results are as follows:
  
  

  In fact, the comparison found that the two are indeed inconsistent; there is also a verification method, the update operation between Beginupdates and Endupdates all commented out, run again to find that the table view is not updated at all, breakpoint Discovery Cellforrowatindexpath: is not called at all. There are all sorts of signs that insert/delete these newer methods have a secret! What is the specific secret? How does it work with the data source? I don't even have it!

• Question two: beginUpdates and endUpdates the insert operation and operation of the delete Exchange order will affect the results?

  The answer is NO! Two operation methods were exchanged and the result of execution was not bad. This is found in the official documentation:
  The code calls the DeleteRowsAtIndexPaths:withRowAnimation:method after it calls INSERTROWSATINDEXPA Ths:withrowanimation:. However, this was not the order in which UITableView completes the operations. It defers any insertions of rows or sections until after it has handled the deletions of rows or sections. The
  roughly means: the deletion operation has a higher execution priority than the insertion operation.
  So when the insertion operation is performed, the deletion operation is complete. You should be careful because deletion is on indexpaths in the original table view, and insertion is in deletion operation on the indexpaths of the table view after the operation, the two references are different! This is also indicated in the official documentation:
  Deletion and reloading operations within an animation block specify which rows and sections in the Ori Ginal table should be removed or reloaded; Insertions Specify which rows and sections should is added to the resulting table. The
  is a clue to this original table and resulting table .

• Question three: Does the data source update order affect the results?

  The answer is YES! Put the data source insert code in the above code in front of the deletion, the result of the operation changed, and became a kind of I see the change also did not see the result of the law.
  
  
  

  So once again it proves the problem one of the conclusions, updating the operation function and the data source really has a leg! All right, seriously, if anyone knows the correlation between the operation function and the data source, please tell the little brother, thank you very much!! Although the data source "insert" before the "delete" results are not expected, but "delete" before "insert" The result is not expected, so the default is to write "delete" in front of "insert" it is helpless!

Let's look at an example below to prove the relevant conclusions in question two.

//Update data source    Nsmutablearray*array1 = (Nsmutablearray*) Self. Arraysections[0];Nsmutablearray*array3 = (Nsmutablearray*) Self. Arraysections[2]; [Array1 Removeobjectatindex:0];//delete No. 0 Group No. 0 record[Array1 Removeobjectatindex:2];//Delete No. 0 Group 2nd record[ Self. ArraysectionsRemoveobjectatindex:1];//delete 1th group[Array1 insertobject:@"1111"Atindex:1];//Insert No. 0 Group 1th record[Array3 insertobject:@"3333"Atindex:0];//Insert 2nd Group No. 0 record    //Create the corresponding indexpaths array    Nsarray*indexpathsdelete = @[[NsindexpathIndexpathforrow:0Insection:0],[NsindexpathIndexpathforrow:2Insection:0]];Nsarray*indexpathsinsert = @[[NsindexpathIndexpathforrow:1Insection:0],[NsindexpathIndexpathforrow:0Insection:1]/ * To insert the 2nd group No. 0 record, but here the number of groups is 1, thinking why * *];//Perform actions[ Self. TablemainBeginupdates]; [ Self. TablemainInsertrowsatindexpaths:indexpathsinsert Withrowanimation:uitableviewrowanimationfade]; [ Self. TablemainDeletesections:[nsindexset Indexsetwithindex:1] Withrowanimation:uitableviewrowanimationfade]; [ Self. TablemainDeleterowsatindexpaths:indexpathsdelete Withrowanimation:uitableviewrowanimationfade]; [ Self. TablemainEndupdates];

The post-execution interface is as follows:

Since the execution of the insert has been delete completed, the original 1th group has been deleted, the original 2nd group becomes the 1th grouping, so the insert indexPath corresponding 1 instead of 2 for the second cell to be inserted by the method section .

Summary: If it is simply an insert or delete operation, there is no need to use beginUpdates and endUpdates parcel operation method, if the batch operation, recommended endUpdates and endUpdates , has ensured that the interface to each update operation simultaneously response.

iOS development-beginupdates && endupdates usage