http://stackoverflow.com/questions/12071726/how-to-use-beginbackgroundtaskwithexpirationhandler-for-already-running-task-in
http://stackoverflow.com/questions/28993628/how-to-pass-background-task-identifier-to-completion-handler
http://www.raywenderlich.com/29948/backgrounding-for-ios

The Problem

When you do an update, an add of an event, or whatever feature that you would like to update on the Azure, it will take anywhere from 1 to maybe a few long seconds to sync the data over the network.

This will cause a problem if the user hits the home button and causes our app to process in the background. iOS will give the app 5 seconds to do what it needs to do before it suspends it.

But what if our network task takes longer!? How to make sure whatever network task we have runs completes safely?

Solution

Apple introduced a feature where you get to background your task for a full 3 minutes. If it can’t finish after 3 minutes, then you’re out of luck and it will suspend your app. But for some network task where we’re synching user data/actions against an Azure server, etc…3 minutes is plenty!

How it Works

When a network task happens, we create a timer to check on the application state for the lifetime of that network task.

For example, when the network starts, we create a timer that calls on method evaluate every 1 second to check on the application state like so:

For the whole duration of the network task, we need to check if the APP is in active state UIApplicationStateActive, or not. If its in the active state, then do nothing, and let the app continue its network task.

Say while the network task is processing, the user presses the Home button. Our app gets backgrounded, and the (UIApplicationStateActive) STATE would the be false. When this happens, the App’s singleton backgroundTimeRemaining will start counting down.

We simply log out to see what the remaining time is. We have a full 180 seconds.

The logs will let you know that as you’re processing this network task, the backgroundTimeRemaining will decrease while the app is in the background.

If the user clicks on the app again within the 3 minutes, your backgroundTimeRemaining will reset.

When the 3 minutes are up, it will call an expiration handler that your property

points to like this:

iOS Tutorial: Editing TableViews

xCode 7.3 demo

Basics

1. Declare an Array data structure
2. numberOfSectionsInTableView
3. numberOfRowsInSection
4. cellForRowAtIndexPath

1. Declare an Array data structure

The table always matches an array(s) of some sort to represent data.
Each row matches up to an element in the array.

2. numberOfSectionsInTableView

The first order things is to let the table know how many sections we will represent. Each table can contain m sections.
Each sections can contain n rows. For simplicity purposes, we’ll designate only 1 section for our table.

Usually, use one array to represent one section. Each section will have n number of rows, which matches up to n number of elements in that array.

3. numberOfRowsInSection

Now, we simply specify the number of rows for each section. Each section usually represent an array, where n elements in that array
matches up to n number of rows in that section.

4. cellForRowAtIndexPath

The concept here is that the UITableView keeps a list of reusable cells.

At first, before showing the rows, it will have nothing. So dequeueReusableCellWithIdentifier will return nil. If you run the app, you’ll see the log show that it creates the cell:

-[RootViewController tableView:cellForRowAtIndexPath:] – Creating new cell
row 0 setting text
[RootViewController tableView:cellForRowAtIndexPath:] – Creating new cell
row 1 setting text
-[RootViewController tableView:cellForRowAtIndexPath:] – Creating new cell
row 2 setting text

In the case of UITableView building new cells for displaying the rows, we get the cell variable reference and point it to a newly created
UITableViewCell object allocated on the heap. We only do this if the cell returned is nil.

Once it creates the cell, it will set the cell’s properties.

Notice there is no ‘else’. That’s because whenever dequeueReusableCellWithIdentifier return a valid cell to be displayed, we always want to make sure the properties are correct, by assigning them.

Always reset all content when reusing a cell

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/TableView_iPhone/TableViewCells/TableViewCells.html

An example of this is if you pull the table up and the rows disappear from the screen.

Once the table bounces back on the visible screen, you’ll see logs like this:

row 0 setting text
row 1 setting text

That’s because when dequeueReusableCellWithIdentifier returns valid cells, you need to always reset the contents of the cell when the reusable cell is returned.

Cells and Table View Performance

The proper use of table view cells, whether off-the-shelf or custom cell objects, is a major factor in the performance of table views. Ensure that your application does the following three things:

Reuse cells. Object allocation has a performance cost, especially if the allocation has to happen repeatedly over a short period—say, when the user scrolls a table view. If you reuse cells instead of allocating new ones, you greatly enhance table view performance.
Avoid relayout of content. When reusing cells with custom subviews, refrain from laying out those subviews each time the table view requests a cell. Lay out the subviews once, when the cell is created.
Use opaque subviews. When customizing table view cells, make the subviews of the cell opaque, not transparent.

Select Row

When you click on a row, this method will be triggered. Then call method setEditing on the table view object. Once you set it to YES, the row will animate its set settings where your deletion option appears on the left, and the move row button appears on the right.

Click and drag the first row’s move icon for a row and move it to the very bottom. Basically we’ll be switching the topmost row with the bottom most row.

You can see that by using the fromIndexPath.row, we can get the string by our data array. We use the NSArray’s methods to manipulate the data so that it reflects what’s happening on the UI.

Namely, use removeObjectAtIndex at from index path, and then insertObject on the row string at index toIndexPath.row.
Finally, we use a NO on setEditing to tell the tableView to finish.

Commit your Edit

Once in edit mode, you will commit on a task. A common one is to delete the row. Once you click on the Delete button, you’ll hit the commitEditingStyle:forRowAtIndexPath method in which you commit your deletion.

When the delete button is selected, it will hit commitEditingStyle:forRowAtIndexPath: method where the editingStyle is UITableViewCellEditingStyleDelete.
From there, its the same as moving rows, where you manipulate your array. You remove the object at the data source, then call deleteRowsAtIndexPaths on the UI tableview object.

Once the deletion takes place, the tableview will redraw all the rows, thus, it will go through numberOfSectionsInTableView: and tableView:numberOfRowsInSection: to recalculate how many elements of the array it should show.

Adding a Insertion Row

Adding an insertion row involves 3 steps

1. Return Insert macro for Row

We want to add a row specifically for entering data and inserting that data into our table. Hence, let’s just designate the first row for that. Hence,
we specify in method editingStyleForRowAtIndexPath, where we return the insert macro for the 0th row to tell the table view to show an “Insert” button when the edit mode is on.

For all other rows, show the delete button when the edit mode is on.

Then in your commitEditingStyle:forRowAtIndexPath method, use an option where if the editing style is for insertion
we add a property NSString where it points to the string to be added

2. Setting up a Custom Row to receive data

One easy way to do this is to create a custom cell with a textfield in there that receives a string.

3. ViewController observe UITextFieldTextDidChangeNotification messages from UITextField

Insert a property InsertionCell, where it will point to the 0th row of type InsertionCell.

You assign it in cellForRowAtIndexPath, where when after 0th cell is created, you simply
assign a reference to it so we can keep track of it.

Then, we register for the UITextFieldTextDidChangeNotification notifications on
textfield of the insertion Cell:

This means that whenever the user enter a character, the UITextfield will send UITextFieldTextDidChangeNotification,
in which the ViewController will observer.

It will run textUpdated: method, like so:

The notification message will contain the UITextField with its text. Hence we just have a NSString property point to that text.

When the green plus button is clicked, it will run to commitEditingStyle:forRowAtIndexPath:, check that editingStyle is UITableViewCellEditingStyleInsert and add the string to the data source array. Then it refresh the data by calling the table view’s reloadData method method.

frc-basic-demo

The signatures of the delegate methods reveal the true purpose of the NSFetchedResultsController class. On iOS, the NSFetchedResultsController class was designed to manage the data displayed by a UITableView or a UICollectionView. It tells its delegate exactly which records changed, how to update the user interface, and when to do this.

Creating the Fetch Results Controller

First, create a NSFetchedResultsController property

Make sure to synthesize it

Create the accessor.

NSFetchedResultsController takes:

• NSFetchRequest, which must set inject a sort descriptor
• Managed Object Context

In your accessor, you’ve set the fetchResultsController’s delegate to self. This means
it’ll be delegating messages to us and we have to take care of it. Thus, we do so by conforming to that delegate and implementing its methods.

In your class extension, conform to NSFetchedResultsControllerDelegate:

Finally, perform the fetch in your viewDidLoad:

Basic FRC delegate methods

Adding some Data

First, we get the MOC that’s connected to our fetch results controller.
Then, we set inject that MOC into NSEntityDescription’s insertNewObjectForEntityForName method, which returns us an Managed Object “Hero”.

We then set the properties of that Hero object and have the MOC call save.

Finally, let’s have our fetch results controller do a performFetch. We see that it now has objects.

When you add additional data and have your MOC save, it’ll call the FRC’s didChangeObject: method, which in turn inserts data into your table view by calling insertRowsAtIndexPaths:withRowAnimation.

Making the Results show up

Use your fetch controller for data display instead of NSArray in your cellForRowAtIndexPath.

Do the same for numberOfRowsInSection

Adding objects in a loop

We loop through creating a bunch of Managed Objects. We set the properties to milliseconds to give them unique data.
Then after the loop is done, we simply tell the MOC to save.

Once, you save, you’ll see that our FRC will animate all the adding of the newly added objects into our table.

Its output is:

As you can see FRC’s delegate methods will and did change content are always wrapped around insertions, deletions, changes, etc.

ADDING GROUP OF PEOPLE

-[ViewController controllerDidChangeContent:]

Deleting Objects

We delete objects by clicking on the delete button in edit mode. In order to get into edit mode, we need to set TRUE for editing on a table row.

Let’s make the table view editable when we click on a row:

When the edit mode is on, let’s use the default delete button style, which is a rectangular red button.

We can also set the string of the button. Instead of the standard Delete, let’s use “Kick!” instead:

output:

— DELETING OBJECT —
-[ViewController controllerWillChangeContent:]

-[ViewController controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:]
tableView deleteRowsAtIndexPaths:withRowAnimation:

-[ViewController controllerDidChangeContent:]

As you can see, the deletion is animated in our table view!

Click and re-click to get in/out of editing mode

When a table is in edit mode, by default, it does not allow you to re-click or re-select rows. However, if you set the property allowsSelectionDuringEditing to YES, then you can.

Let’s say you want the user to be able to go back to non-edit mode by clicking the table again. Look at property isEditing to see if you’re in edit mode. If so, just simply set the tableview back to NO for setEditing.