Async Fetch Request – part 2

xCode 7.3 AsyncFetchRequestEx2

Fetch Request

Result Block

The Async Fetch Request

Perform the async fetch request with a context

Async Fetch Request – part 1

xCode 7.3 demo, AsyncFetchRequestEx1

Setting up the Stack

We create the core data stack called BNRCoreDataCoordinator.

Then we set up the PSC and MOC…

1) Set up lazy loading accessor for NSPersistentStoreCoordinator
2) Set up lazy loading accessor for NSManagedObjectContext

Notice that the MOC is connected to the PSC:

MOC Saving

Inserting Data

We throw a task block on our MOC’s private background queue. That task to simply initialize an Entity object
n number of times. Core Data returns ready objects for us to initialize. Once all the Entity objects are set up,
we tell the MOC to save context.

The caller of this method will get a completion block to signify that our Entity insertions have been done.
We throw this completion block onto the main queue visual reply.

How To Use

In your ViewController, import the core data coordinator, and implement a lazy loading accessor.

Let’s insert the data when it first appears. As you can see, when the insertion have completed,
we can do something on the UI, or just log a completion message.

Serializing Data – domain model to persistence

http://nshipster.com/nscoding/

There are many ways you serialize data, or convert domain model to persistence:

Core Data
NSKeyedArchiver
pList
NSUserDefault
etc…

Core Data may not be your answer because:

Not all apps need to query data.
Not all apps need automatic migrations.
Not all apps work with large or complex object graphs.

NSKeyArchiver and NSCoding

Thus, using NSKeyArchiver and NSCoding maybe a great solution in some cases.

NSCoding is a simple protocol, with two methods: -initWithCoder: and encodeWithCoder:. Classes that conform to NSCoding can be serialized and deserialized into data that can be either be archived to disk or distributed across a network.

NSKeyArchiver serializes -compliant classes to and from a data representation.

NSCoding delegates

This is so that you can tell it what properties to encode into objects. Encode means to “convert into a coded form”.
Hence, we inject our properties into encodeObject.

Decode means to convert a coded message into something readable.
Thus, that’s why we have our properties take on data returned by the decoder.

Each property is encoded or decoded as an object or type, using the name of the property of as the key each time.

File System

NSKeyedArchiver and NSKeyedUnarchiver provide a convenient API to read / write objects directly to / from disk.

You first get the path of the directory you want. Then you append a file name to that path. The resulting NSString appFile is your full path to the file you are saving to.

Then, use your Array or Dictionary, and insert it into NSKeyedArchiver’s archiveRootObject toFile method in order to save.
When you want to load, use unarchiveObjectWithFile:appFile.

pLists

A property list (a.k.a. pList) is a structured data representation used by Cocoa and Core Foundation as a convenient way to store, organize, and access standard types of data. You can build little more complex structures but not that much. NSString, NSData, NSNumber, NSDate, NSArray, NSDictionary – these are the only Objective-C data types that property list supports. Sub-entries are only allowed with NSDictionary or NSArray. A property list is used to store “less than a few hundred kilobytes” of data. A very significant and popular use of property lists is to define application settings.

If you open a pList with Xcode this is how it will show a very comfortable view of key-value pairs. But if you open the pList with a text editor you will see the actual format, which is XML. Property list is a subset of XML.

ARC vs MRC

https://www.quora.com/How-does-garbage-collection-happen-in-iOS
http://stackoverflow.com/questions/6385285/why-doesnt-ios-have-automatic-garbage-collection

Manual Reference Counting has the developer take care of the allocation and release of the object life cycle by using new/delete, alloc/release. You have to make sure every alloc is matched with a release.

MRC behind the wheel :
1. Every time you create and allocate an object, you increase the reference count of the variable. So suppose you created object foo , so now the reference count got increased to 1.
2. If any other object is also referring to this object, then the count increases to 2.
3. Now if I decide to remove my ownership and i want to remove my reference, then the reference count drops by -1;

So technically, every reference to an object is referenceCount++ and every release of the object is a referenceCount–

Once the reference count reaches zero, that’s when the object foo becomes eligible garbage collection.

Automatic Reference Counting – the iOS compiler looks after the memory management. Thus, you don’t have to worry about releasing the objects. You just allocate and that’s it.

In other words, it is a memory management enhancement where the task of keeping track of reference counting for objects is removed from the programmer and onto the compiler.

ARC differs from Cocoa’s garbage collection [4] in that there is no background process doing the deallocation of objects.[5] Unlike garbage collection, ARC does not handle reference cycles automatically. It is up to the program to break cycles using weak references.[6]

Developers no longer have to worry about retain / release of objects, you don’t have a garbage collector process slowing execution randomly, and you still maintain fairly tight control over memory usage.

How ARC works

ARC works its magic at compile time to do the reference counting for you thereby making it unnecessary (and actually non-allowed) to use any other sort of memory management.

Now what ARC does is it looks up your code, sees where the scope of the variable ends and then adds autorelease, on those objects, and release is deprecated.
So what autorelease does is it adds the object to AUTORELEASE POOL , which basically means once the scope/block ends, objects in that block will be sent release messages.

Why it does not use Garbage Collection

At WWDC 2011, Apple explained that they didn’t want garbage collection on their mobile devices because they want apps to be able to run with the best use of the provided resources, and with great determinism. The problem with garbage collection is not only that objects build up over time until the garbage collector kicks in, but that you don’t have any control over when the garbage collector will kick in. This causes non-deterministic behavior that could lead to slowdowns that could occur when you don’t want them.

Bottom Line: You can’t say, “OK. I know that these objects will be freed at X point in time, and it won’t collide with other events that are occurring.”

Height of Tree

Height of tree is used to find the maximum number of steps to search for an item in a data set using logarithmic division.

If you wanted to find a number in that tree, you compare the toFind integer with the current node. If larger, go down right side. If smaller, go down left side.

You may find your integer at the very top, or at the next node, or a few steps down the tree. But the absolute maximum number of steps it takes to find your item is the height of the tree.

By going down 1 step, you’ve removed half of the data set by process of elimination. For example, if you search for a 2, and the node is 8, you go down the left side. You don’t need to worry about the right side of 8, because all those numbers is guaranteed to be bigger.

With each step you take, you eliminate half of the data set until you finally get to your number.

The number of eliminations (or divisions) you make is basically the height of the tree.

1) get the height of the tree
2) Go through each level of the height and print

level is how many depths to go into the tree..
0 is root
1 means go down 1 level..display all nodes there.
2 means go down 2 levels…display all nodes there..
etc
NOTICE LEVEL. we recursively traverse via LEVEL

QuickSort

http://www.algolist.net/Algorithms/Sorting/Quicksort

Sort in Place

In-place sorting is a form of sorting in which a small amount of extra space is used to manipulate the input set. In other words, the output is placed in the correct position while the algorithm is still executing, which means that the input will be overwritten by the desired output on run-time.

stable sorting

http://stackoverflow.com/questions/1517793/stability-in-sorting-algorithms

A sorting algorithm is said to be stable if two objects with equal keys appear in the
same order in sorted output as they appear in the input array to be sorted.

Suppose we have input:

peach
straw
apple
spork

Sorted would be:

apple
peach
straw
spork

and this would be stable because even though straw and spork are both ‘s’, their ordering is kept the same.

In an unstable algorithm, straw or spork may be interchanged, but in stable sort, they stay in the same relative positions (that is, since ‘straw’ appears before ‘spork’ in the input, it also appears before ‘spork’ in the output).

Examples of stable sorts:

mergesort
radix sort
bubble sort
insertion sort

Deleting in Azure

Given that a refresh pull involves pulling data that is filtered according to an attribute, Soft Delete involves setting that attribute to YES/NO. This affects clients in that they will then not be able to pull that data. Additionally, that data is kept safe in Easy Table for future references and undeletes.

For example, let’s say you create an attribute “complete”.
When pulling data, you may specify that you want to pull all data that has NO for attribute “complete”.

Once you assign YES for attribute complete on say row 88, client refresh pulls will not include row 88 anymore. It will include all rows with NO for attribute “complete”.

When fetching from your fetch controller/core data, simply filter data according to complete == NO.

HARD DELETE – Delete on Local and Server

If you want to remove local AND server data, all you have to do is call the delete method from your MSSyncTable.

It sends a request to your local data source to remove the given item, then queues a request to send the delete to the mobile service.

It first removes the data locally.
Then, when the queued request goes through into the mobile service, then it will update remotely, and you can log into your Azure account, look at the Easy Tables, and see that the item has been removed.

Notes

Do not remove data by hand on the backend directly. Currently, MS have no way to re-syncing, and your client app will have many error messages on its request queue.

Using MSTable’s readWithCompletion to pull data from Server

For the issue of when there is a delete on the server side, it means we have less data on the server side
than the local side.

we need to make sure our local db sync up to that. One way to do that is to pull the data by using MSTable’s
readWithCompletion to get the latest from the server.

Than compare it to the core data.

In your QS******Service.m,

declare some properties to save data:

Then, we implement a method where we store the results from the server. We use MSTable’s
readWithCompletion method like so:

Then when you get the latest results