If you just want to wait for the final value, runTransactionBlock:andCompletionBlock: is the method you want to look at. Here is a sample code:
[upvotesRef runTransactionBlock:^FTransactionResult *(FMutableData *currentData) { NSNumber *value = currentData.value; if (currentData.value == [NSNull null]) { value = 0; } [currentData setValue:[NSNumber numberWithInt:(1 + [value intValue])]]; return [FTransactionResult successWithValue:currentData]; } andCompletionBlock:^(NSError *error, BOOL committed, FDataSnapshot *snapshot) { if (error) { NSLog(@"Error: %@", error); } if (committed) { NSLog(@"Data committed"); } NSLog(@"Final Value: %@", snapshot.value); }];
This is the last value there, snapshot.value , where you can get your final value. This is the same type of FDataSnapshot that you get if you use observeEventType:withBlock:
If something goes wrong, you will get error .
If your data is committed, committed will be YES. If you returned [FTransactionResult abort] to the transaction block instead of [FTransactionResult successWithValue:] , committed will be NO.
This means that if you read the counter at 4 and try to update it. You can try updating the counter while someone else does. If you log in first, snapshot.value will be 5. If another person’s update hits before you do, snapshot.value will be 6.
You probably wanted to get up to 6, regardless of who first adopted it. For this you need to add an observer. The code for this might look like this:
[upvotesRef observeEventType:FEventTypeValue withBlock:^(FDataSnapshot *snapshot) { NSLog(@"New Value: %@", snapshot.value); }];
In this case, you do not need a completion block to find out the final value, because every time transactions are blocked, the observer block lights up. In the above example, the script will fire once at 5 and once at 6, regardless of who first adopted it. You need a completion block if you want to know if your particular transaction was able to complete, and not just what the value is in this place.
And to be complete, there is another method called runTransactionBlock:andCompletionBlock:withLocalEvents: If other users also write to the same place, a transaction block can be executed several times. This happens if he discovers that he is working with outdated data. When it will successfully work with the new data, it will call the completion block. However, you will find that every time it starts, it starts any blocks of observers in this place. If you do not want this to happen, you must pass NO to withLocalEvents: Your Firebase will fire events at this location whenever a confirmed record passes, but your local transactional records that are not confirmed will not.
Looking back at an example in which you and another person are simultaneously trying to move forward. By default, the observer will work as soon as you try to update the account from 4 to 5. The actual transaction may fail because someone else has increased the number of upvote from 4 to 5. At the same time, your transaction block will start again with new data 5 and see that he should push the count to 6. If the local events are set to NO, the observer will light up after the server lets you know that someone else pushed upvote counting from 4 to 5, and not when trying to update the count from 4 to 5.
This is not a huge deal with something as simple as upvotes, where everything just grows, but if you can potentially push different data away from other users, any observers in this place can see how the data rolls before finally settling.