Category Archives: iOS

NSURLSession – Out of process upload/download

iOS

ref – http://www.techotopia.com/index.php/An_iOS_7_Background_Transfer_Service_Tutorial

demo project

Background Uploads and Downloads

Adding support for background uploads and downloads is surprisingly easy with NSURLSession. Apple refers to them as out-of-process uploads and downloads as the tasks are managed by a background daemon, not your application. Even if your application crashes during an upload or download task, the task continues in the background.

Enabling background uploads and downloads is nothing more than flipping a switch in your session’s configuration. With a properly configured session object, you are ready to schedule upload and download tasks in the background.

When an upload or download is initiated:

  1. background daemon comes into existence
  2. The daemon takes care of the task and sends updates to the application through the delegate protocols declared in the NSURLSession API
  3. If app stops, daemon continues task
  4. If download task finishes, daemon informs session.
  5. The session then invokes the appropriate delegate methods to make sure your application can take the appropriate actions, such as moving the file to a more permanent location.

When the Background Transfer Service gets in action, what is actually happening is that the operating system takes charge of all the download process, performing everything in background threads (daemons).

While a download is in progress, delegates are used to inform the app for the progress, and wakes it up in the background to get more data if needed, such as credentials for logging in to a service. However, even though everything is controlled by the system, users can cancel all downloads at any time through the application.

A reminder that a block parameter has 3 parts. The return, the parameter, and the block name. Like so:

So this means that the block is used where it takes 2 doubles, and does not return anything. It is called by using the block name ‘block’.

Handle Events for Background Session

Apps that (using an NSURLSession with a background configuration) may be launched or resumed in the background in order to handle the
completion of tasks in that session, or to handle authentication.

In other words, when an app uses NSURLSession with background service (whether its a GET request or downloading/uploading), NSURLSession needs to let the app know and to handle the completion of tasks for that session.

We simply strong the completionHandler block in order to call it later to let the system know that we complete all tasks.

NSURLSessionDelegate’s PROTOCOL METHOD will be called. In there you access the appDelegate and call the completionHandler.

Hence when you’re using it, if an application has received an -application:handleEventsForBackgroundURLSession:completionHandler:
message, the session delegate will receive this message to indicate
that all messages previously enqueued for this session have been
delivered.

Declare the session completion handler member variable:

AppDelegate.h

Then, have its set property copy the completion handler:

AppDelegate.m

Go to your ViewController and conform to NSURLSessionDelegate.

This is so that we need to implement URLSessionDidFinishEventsForBackgroundURLSession.

Now when your session object’s delegate queue tasks have all been processed, in your AppDelegate, you will receive a
application has received an -application:handleEventsForBackgroundURLSession:completionHandler:
message and your protocol method

will be called.

Then your session delegate will send a message to protocol method URLSessionDidFinishEventsForBackgroundURLSession to indicate that all messages previously enqueued for this session have been
delivered.

Hence that’s why its the job of your URLSessionDidFinishEventsForBackgroundURLSession method to simply call the completionHandler and clean it up.

If your session delegate sends a message to call protocol method:

for authentication purposes, then you need to something similar. Where you give authentication information, then call the completionHandler().

Prepare the UI

Configuration Object

Session Object

Updating download progress percentages

When you resume a download task

Send last message related to a specific task

When your download have completed

NSURLSession basics

iOS

ref – http://code.tutsplus.com/tutorials/networking-with-nsurlsession-part-1–mobile-21394

http://code.tutsplus.com/tutorials/networking-with-nsurlsession-part-2–mobile-21581

1) Simple GET of data

2) Downloading a file using NSURLSessionDownloadDelegate protocol

So we want to download a file. However, we want to see what percentage we are at, as well as when the file has finished downloading.

A session configuration object is nothing more than a dictionary of properties that defines how the session it is tied to behaves. A session has one session configuration object that dictates cookie, security, and cache policies, the maximum number of connections to a host, resource and network timeouts, etc.

Once a session is created and configured by a NSURLSessionConfiguration instance, the session’s configuration cannot be modified. If you need to modify a session’s configuration, you have to create a new session. Keep in mind that it is possible to copy a session’s configuration and modify it, but the changes have no effect on the session from which the configuration was copied.

Once a session is created and configured by a NSURLSessionConfiguration instance, the session’s configuration cannot be modified. A SessionConfiguration is immutable. If you need to modify a session’s configuration, you have to create a new session. Keep in mind that it is possible to copy a session’s configuration and modify it, but the changes have no effect on the session from which the configuration was copied.

  1. Use a private UIImageView to hold the image
  2. privately conform to NSURLSessionDownloadDelegate protocol
  3. Implement protocol methods
ViewController.m

Add the image holder to your view hierarchy

Then use a NSURLSession to get a task running

Notice that we first get a default Session Configuration object. Then we pass it into the session to be used.

Configuring a session configuration object is as simple as modifying its properties as shown in the example. We can then use the session configuration object to instantiate a session object. The session object serves as a factory for data, upload, and download tasks, with each task corresponding to a single request.

Finally, implement the protocol methods

Make sure you use the main queue, to update your image holder with the data you just downloaded.

Also, if you are to use a progress view to show updates on progress, make sure you dispatch a code block onto the main queue, so that the main thread can run the code and show it.

http://stackoverflow.com/questions/31254725/transport-security-has-blocked-a-cleartext-http

concurrency, asynchronous, parrallelism

iOS

ref – http://stackoverflow.com/questions/4844637/what-is-the-difference-between-concurrency-parallelism-and-asynchronous-methods

Concurrent and parallel are effectively the same principle as you correctly surmise, both are related to tasks being executes simultaneously although I would say that parallel tasks should be truly multitasking, executed at the same time whereas concurrent could mean that the tasks are sharing the execution thread while still appearing to be executing in parallel.

Asynchronous methods aren’t directly related to the previous two concepts, asynchrony is used to present the impression of concurrent or parallel tasking but effectively an asynchronous method call is normally used for a process that needs to do work away from the current application and we don’t want to wait and block our application awaiting the response.

For example, getting data from a database could take time but we don’t want to block our UI waiting for the data. The async call takes a call-back reference and returns execution back to your code as soon as the request has been placed with the remote system. Your UI can continue to respond to the user while the remote system does whatever processing is required, once it returns the data to your call-back method then that method can update the UI (or hand off that update) as appropriate.

From the User perspective it appears like multitasking but it may not be.

EDIT

It’s probably worth adding that in many implementations an asynchronous method call will cause a thread to be spun up but it’s not essential, it really depends on the operation being executed and how the response can be notified back to the system.

global queue and their priorities

iOS

http://stackoverflow.com/questions/25052629/ios-gcd-difference-between-any-global-queue-and-the-one-with-background-priorit

  • DISPATCH_QUEUE_PRIORITY_HIGH
  • DISPATCH_QUEUE_PRIORITY_DEFAULT
  • DISPATCH_QUEUE_PRIORITY_LOW

are priority queues with tasks in them.

These queues are performed according to their priority as evident by their names.

Let’s say you have the queue with HIGH priority; tasks in that queue will be executed first; you would do that if one specific task needs to be finished as quick as possible even if it means that other tasks are delayed.

DISPATCH_QUEUE_PRIORITY_LOW – Items dispatched to the queue will run at low priority, i.e. the queue will be scheduled for execution after ALL default priority and high priority queues have been scheduled.

DISPATCH_QUEUE_PRIORITY_BACKGROUND

Let’s say you may have a task A that takes a long time, but it is Ok for that task to wait for other tasks to finish. For example, if there is work to do at NORMAL priority, that work will be done first, and only when there is a spare CPU doing nothing else, then your task A will be performed.

You would give that task A BACKGROUND priority.

Meaning of Global Queue

Other things, like system frameworks, may be scheduling in to it. It’s very easy to starve the priority bands – if there are a lot of DISPATCH_QUEUE_PRIORITY_HIGH tasks being scheduled, tasks at the default priority may have to wait quite a while before executing. And tasks in DISPATCH_QUEUE_PRIORITY_BACKGROUND may have to wait a very long time, as all other priorities above them must be empty.

Don’t abuse the global queue

A lot of developers abuse the global concurrent queue. They want a execute a block, need a queue, and just use that at the default priority. That kind of practice can lead to some very difficult to troubleshoot bugs. The global concurrent queue is a shared resource and should be treated with care. In most cases it makes more sense to create a private queue.

ref – http://stackoverflow.com/questions/9602042/whats-the-difference-between-the-global-queue-and-the-main-queue-in-gcd

thread priorities

-main- : 0.758065
DISPATCH_QUEUE_PRIORITY_HIGH : 0.532258
DISPATCH_QUEUE_PRIORITY_DEFAULT : 0.500000
DISPATCH_QUEUE_PRIORITY_LOW : 0.467742
DISPATCH_QUEUE_PRIORITY_BACKGROUND : 0.000000

self does not hold strong ref to dispatch_async

iOS

ref – https://digitalleaves.com/blog/2015/05/demystifying-retain-cycles-in-arc/

Examples of non-cycles

      Using dispatch_async as the example is misleading as self does not hold a strong reference to it so, there is no threat of a retain cycle.

    • The block retains self, but self doesn’t retain the block. If one or the other is released, no cycle is created and everything gets deallocated as it should.

    How you get into trouble

    Where you get into trouble is something like:

    Now, your object (self) has an explicit strong reference to the block. And the block has an implicit strong reference to self. That’s a cycle, and now neither object will be deallocated properly.

Not blocking the UI with FMDB Queue

iOS,

Not blocking the UI with FMDB Queue

xCode 7.3 concept demo

So notifications are coming in rapidly…each one is a thread, and the threads’s data are getting inserted into your FMDB. Your FMDB ensures thread safety because FMDB’s queue uses dispatch_sync:

FMDatabaseQueue.m

It gets the block of database code you pass in, and puts it on a SERIAL QUEUE.

The dispatch_sync used here is not a tool for getting concurrent execution, it is a tool for temporarily limiting it for safety.

The SERIAL QUEUE ensures safety by having each block line up one after another, and start their execution ONLY AFTER the previous task has finished executing. This ensures that you are thread safe because they are not writing over each other at the same time.

However there is a problem. Let’s say your main thread is processing a for loop with the inDatabase method. The main thread places the block on FMDB Queue’s serial queue. This means the dispatch_sync that FMDB Queue is using will block your main thread as it processes each task. By definition, dispatch_sync DOES NOT RETURN, until after it has finished its executing task.

Proving FMDB does block

We need to prove that FMDB does indeed block our UI so we first put a UISlider in ViewController for testing purposes. If we are concurrently processing all these incoming notifications in the background, then this UISlider should be responsive.

You put a slider on your UI like so:

When you run a simple for loop outside of method say executeUpdateOnDBwithSQLParams:, you are essentially adding a dispatch_sync on your main thread. This will block, and your UI will NOT be responsive.

In order to solve this, we do 2 things:

  1. Use a concurrent queue and have main thread work on it to ensure concurrency and that the UI is not blocked
  2. Inside of that concurrent queue, we queue up db jobs to FMDB’s thread safe serial queue

Solution

dispatch_sync does not return until its task is finished. Thus, while the task is executing, the main queue can’t do anything because the dispatch_sync has not returned. That’s the just of the issue.

What we did to solve this issue is to

dispatch_async FMDB tasks on a concurrent queue.

This is the basic setup that enables fmdb to be non-blocking.

1) We set up a block on a concurrent queue first. This ensures that whatever runs inside of that concurrent block will be able to run
concurrently with the main thread.

2) The block starts off with executing its log. Then the PRE-TASK. Then it syncs its own block of the “DB Task”. This sync means that it blocks whatever is trying run with it, on conQueue. Hence, that’s why POST-TASK will run after DB task.

3) Finally, after PRE-TASK, then DB task, finish running, POST-TASK runs.


— start block (concurrent queue) —
—  Task PRE-TASK on concurrent queue start  —
PRE-TASK on concurrent queue – 0
PRE-TASK on concurrent queue – 1
PRE-TASK on concurrent queue – 2
^^^ Task PRE-TASK on concurrent queue END ^^^
— start block (sync queue) —
—  Task DB task start  —
DB task – 0
DB task – 1
DB task – 2
DB task – 3
DB task – 4
DB task – 5
DB task – 6
DB task – 7
DB task – 8
DB task – 9
^^^ Task DB task END ^^^
— end block (sync queue) —
—  Task POST-TASK on concurrent queue start  —
POST-TASK on concurrent queue – 0
POST-TASK on concurrent queue – 1
POST-TASK on concurrent queue – 2
^^^ Task POST-TASK on concurrent queue END ^^^
— end block (concurrent queue) —

The dispatch_sync is to simulate FMDB like so:

So BOTH tasks

  • dispatch_sync is running its db tasks (fmdb)
  • free to move your UI (main queue)

are processing on the concurrent queue via dispatch_async.
Thus, that’s how you get FMDB to be non-blocking.

Tidbit: changing dispatch_async to dispatch_sync on the concurrent queue

If you were to change from dispatch_async to dispatch_sync on the concurrent queue “conQueue”, it will block the main queue
when it first starts up because by definition, dispatch_sync means it does not return right away. It will return later
when it runs to the end, but for now, it blocks and you’re not able to move your UI.

Thus, it runs to PRE-TASK, and executes that.

Then it moves down, and runs the “DB task” block via dispatch_async on serial queue “queue”.

The dispatch_async returns immediately, starts executing “DB task” on serial queue “queue”, and then it executes
POST-TASK. Thus, DB task and POST-TASK will be executing together.

After POST-TASK finishes, our concurrent block has ran to the end, and returns (due to dispatch_sync).
At this point, you will be able to move the UI. “DB task” continues its execution because its part of the task that’s still sitting on concurrent queue “conQueue”.
Since its a concurrent queue, it will be processing this task that’s still sitting on its queue, and you will be able to move around the UI because nothing is blocking anymore.

Other details when you have time

where concurrencyQueue is created and initialized like so:

But what about the database writing that is dispatch_sync on the serial queue? Wouldn’t that block?

No. The dispatch_sync on the serial queue only blocks against thread(s) that touches FMDB Queue’s serial queue. In this case, it would be FMDBQueue’s serial queue’s own thread, and the concurrent queue’s thread.

does_not_block_main

max of 64 threads running concurrently

ref – http://stackoverflow.com/questions/34849078/main-thread-does-dispatch-async-on-a-concurrent-queue-in-viewdidload-or-within

Note that when you are using custom concurrent queues, you are only allowed to use 64 concurrent working threads at once. Hence, that’s why when your main thread calls on the concurrent queue and queue up tasks, the system starts blocking your UI after 64 tasks on the queue.

The workaround is to put the task of placing db tasks onto the concurrent queue onto your main queue like so:

Then simply call the utility method run_async_with_UI and place your database calls in there.

Proof of concept

The dispatch_sync(serialQueue,….) is essentially the FMDB Queue.
We just added dispatch_async(concurrencyQueue…). Now, you can see that we are manipulating the database in a thread-safe manner, in the background, without clogging up the UI.

result:

So, the dispatch_async throws all the tasks onto the concurrent queue without returning (aka blocking). That’s why all the task blocks log “concurrentQueue inserts task n”.

The task the dispatch_async throws onto the serialQueue will start executing immediately via dispatch_sync. Dispatch_sync by definition means it won’t return until its block has finished executing. Hence, this means that “concurrentQueue’s END task n” message won’t be logged until after the block on serialQueue has been executed”.


Notice how serialQueue FINISHED 1, then concurrentQueue logs END task 1.
serialQueue FINISHED 0, then concurrentQueue END task 0…

its because dispatch_sync does not return until it has finished executing.
Once it returns, it continues onto the “concurrentQueue END task n” log message.

In other words, due to dispatch_sync, line 10-16 must be run, before line 20 is run.

Another important note is that notice serialQueue has started to execute. But by definition, dispatch_sync blocks and does not return until the current executing task is finished…so how does concurrentQueue keeps inserting?

The reason is that the blocks on serialQueue is running in the background. The dispatch_sync that’s not returning happens in the background, and thus, does not affect the UI. The enqueueing of the “db simulate write” onto the serialQueue is done on the background queue concurrentQueue.

Say we switch it

So now we dispatch_sync a block onto a queue, it will not return until it finishes enqueueing. The key point here is that “due to dispatch_async throwing the task onto the serialQueue and returning immediately”, enqueueing will be:

lots of fast enqueueing of blocks onto the concurrent queue, thus, logging of
line 5, and line 20.

example:

1. block task 1 goes onto concurrent queue via dispatch_sync, WILL NOT RETURN UNTIL WHOLE TASK BLOCK IS FINISHED
2. “simulate DB write” task block goes onto serial Queue via dispatch_async, RETURNS RIGHT AWAY.
3. block task 1 finished, thus RETURNS control to concurrent queue.

4. block task 2 goes onto concurrent queue via dispatch_sync, WILL NOT RETURN UNTIL WHOLE TASK BLOCK IS FINISHED
5. “simulate DB write” task block goes onto serial Queue via dispatch_async, RETURNS RIGHT AWAY.
6. block task 2 finished, thus RETURNS control to concurrent queue.

…
…
etc.

continues until the serialQueue, being a background queue, starts processing its first block. Hence it will display:

serialQueue – START 0———
serialQueue – FINISHED 0——–

Hence, the situation is that all the tasks of putting “simulate write tasks onto the serial Queue” are enqueued onto the concurrent queue quickly.

Then, when the serial Queue decides to execute its first task, thats’ when it does its first “DB write simulate”. This DB write simulate does not block UI because its being done in the background.

result:

Then after all the tasks are being enqueued onto the concurrent queue…the serialQueue processing task one by one.

instance variable strong references?

C/C++/Objective-C, iOS

ref – http://stackoverflow.com/questions/16461343/ivars-references-strong-weak-or-what

Default behavior of instance variable

Instance variable maintains a strong reference to the objects by default

Why don’t we specify weak/strong for iVar like properties?

Local variables and non-property instance variables maintain a strong references to objects by default. There’s no need to specify the strong attribute explicitly, because it is the default.
A variable maintains a strong reference to an object only as long as that variable is in scope, or until it is reassigned to another object or nil.

If you don’t want a variable to maintain a strong reference, you can declare it as __weak, like this: