motion-yapper 0.0.1

data/vendor/Pods/Headers/YapDatabase/YapDatabaseView.h

@@ -0,0 +1,186 @@
+#import <Foundation/Foundation.h>
+
+#import "YapDatabaseExtension.h"
+#import "YapDatabaseViewOptions.h"
+#import "YapDatabaseViewConnection.h"
+#import "YapDatabaseViewTransaction.h"
+
+/**
+ * Welcome to YapDatabase!
+ * 
+ * https://github.com/yaptv/YapDatabase
+ * 
+ * The project wiki has a wealth of documentation if you have any questions.
+ * https://github.com/yaptv/YapDatabase/wiki
+ *
+ * YapDatabaseView is an extension designed to work with YapDatabase.
+ * It gives you a persistent sorted "view" of a configurable subset of your data.
+ *
+ * For the full documentation on Views, please see the related wiki article:
+ * https://github.com/yaptv/YapDatabase/wiki/Views
+ * 
+ * Just in case you don't have Internet access,
+ * see the quick overview in YapDatabaseView.h.
+**/
+
+/**
+ * The grouping block handles both filtering and grouping.
+ * 
+ * When you add or update rows in the databse the grouping block is invoked.
+ * Your grouping block can inspect the row and determine if it should be a part of the view.
+ * If not, your grouping block simply returns 'nil' and the object is excluded from the view (removing it if needed).
+ * Otherwise your grouping block returns a group, which can be any string you want.
+ * Once the view knows what group the row belongs to,
+ * it will then determine the position of the row within the group (using the sorting block).
+ * 
+ * You should choose a block type that takes the minimum number of required parameters.
+ * The view can make various optimizations based on required parameters of the block.
+**/
+typedef id YapDatabaseViewGroupingBlock; // One of the YapDatabaseViewGroupingX types below.
+
+typedef NSString* (^YapDatabaseViewGroupingWithKeyBlock)(NSString *collection, NSString *key);
+typedef NSString* (^YapDatabaseViewGroupingWithObjectBlock)(NSString *collection, NSString *key, id object);
+typedef NSString* (^YapDatabaseViewGroupingWithMetadataBlock)(NSString *collection, NSString *key, id metadata);
+typedef NSString* (^YapDatabaseViewGroupingWithRowBlock)(NSString *collection, NSString *key, id object, id metadata);
+
+/**
+ * The sorting block handles sorting of objects within their group.
+ *
+ * After the view invokes the grouping block to determine what group a database row belongs to (if any),
+ * the view then needs to determine what index within that group the row should be.
+ * In order to do this, it needs to compare the new/updated row with existing rows in the same view group.
+ * This is what the sorting block is used for.
+ * So the sorting block will be invoked automatically during this process until the view has come to a conclusion.
+ * 
+ * You should choose a block type that takes the minimum number of required parameters.
+ * The view can make various optimizations based on required parameters of the block.
+ * 
+ * For example, if sorting is based on the object, and the metadata of a row is updated,
+ * then the view can deduce that the index hasn't changed (if the group hans't), and can skip this step.
+ * 
+ * Performance Note:
+ * 
+ * The view uses various optimizations (based on common patterns)
+ * to reduce the number of times it needs to invoke the sorting block.
+ *
+ * - Pattern      : row is updated, but its index in the view doesn't change.
+ *   Optimization : if an updated row doesn't change groups, the view will first compare it with
+ *                  objects to the left and right.
+ *
+ * - Pattern      : rows are added to the beginning or end or a view
+ *   Optimization : if the last change put an object at the beginning of the view, then it will test this quickly.
+ *                  if the last change put an object at the end of the view, then it will test this quickly.
+ * 
+ * These optimizations offer huge performance benefits to many common cases.
+ * For example, adding objects to a view that are sorted by timestamp of when they arrived.
+ *
+ * The optimizations are not always performed.
+ * That is, if the row is added to a group it didn't previously belong,
+ * or if the last change didn't place an item at the beginning or end of the view.
+ *
+ * If optimizations fail, or are skipped, then the view uses a binary search algorithm.
+ * 
+ * Although this may be considered "internal information",
+ * I feel it is important to explain for the following reason:
+ * 
+ * Another common pattern is to fetch a number of objects in a batch, and then insert them into the database.
+ * Now imagine a situation in which the view is sorting posts based on timestamp,
+ * and you just fetched the most recent 10 posts. You can enumerate these 10 posts in forwards or backwards
+ * while adding them to the database. One direction will hit the optimization every time. The other will cause
+ * the view to perform a binary search every time. These little one-liner optimzations are easy.
+**/
+typedef id YapDatabaseViewSortingBlock; // One of the YapDatabaseViewSortingX types below.
+
+typedef NSComparisonResult (^YapDatabaseViewSortingWithKeyBlock) \
+                 (NSString *group, NSString *collection1, NSString *key1, \
+                                   NSString *collection2, NSString *key2);
+typedef NSComparisonResult (^YapDatabaseViewSortingWithObjectBlock) \
+                 (NSString *group, NSString *collection1, NSString *key1, id object1, \
+                                   NSString *collection2, NSString *key2, id object2);
+typedef NSComparisonResult (^YapDatabaseViewSortingWithMetadataBlock) \
+                 (NSString *group, NSString *collection1, NSString *key1, id metadata, \
+                                   NSString *collection2, NSString *key2, id metadata2);
+typedef NSComparisonResult (^YapDatabaseViewSortingWithRowBlock) \
+                 (NSString *group, NSString *collection1, NSString *key1, id object1, id metadata1, \
+                                   NSString *collection2, NSString *key2, id object2, id metadata2);
+
+#ifndef YapDatabaseViewBlockTypeDefined
+#define YapDatabaseViewBlockTypeDefined 1
+
+/**
+ * I wish there was a way to inspect a given block and see what kind of parameters it takes.
+ * Sadly this does not appear to be possible (at least not in any kind of standard legal way).
+ * 
+ * Thus, unfortunately (for now), you will have to specify what kind of block you're passing.
+**/
+typedef enum {
+	YapDatabaseViewBlockTypeWithKey       = 1,
+	YapDatabaseViewBlockTypeWithObject    = 2,
+	YapDatabaseViewBlockTypeWithMetadata  = 3,
+	YapDatabaseViewBlockTypeWithRow       = 4
+} YapDatabaseViewBlockType;
+
+#endif
+
+@interface YapDatabaseView : YapDatabaseExtension
+
+/* Inherited from YapDatabaseExtension
+ 
+@property (nonatomic, strong, readonly) NSString *registeredName;
+
+*/
+
+/**
+ * See the wiki for an example of how to initialize a view:
+ * https://github.com/yaptv/YapDatabase/wiki/Views#wiki-initializing_a_view
+ *
+ * @param version
+ *
+ *   If, after creating a view, you need to change either the groupingBlock or sortingBlock,
+ *   then simply use the version parameter. If you pass a version that is different from the last
+ *   initialization of the view, then the view will automatically flush its tables, and re-populate itself.
+ *
+ * @param options
+ *
+ *   The options allow you to specify things like creating an in-memory-only view (non persistent).
+**/
+
+- (id)initWithGroupingBlock:(YapDatabaseViewGroupingBlock)groupingBlock
+          groupingBlockType:(YapDatabaseViewBlockType)groupingBlockType
+               sortingBlock:(YapDatabaseViewSortingBlock)sortingBlock
+           sortingBlockType:(YapDatabaseViewBlockType)sortingBlockType;
+
+- (id)initWithGroupingBlock:(YapDatabaseViewGroupingBlock)groupingBlock
+          groupingBlockType:(YapDatabaseViewBlockType)groupingBlockType
+               sortingBlock:(YapDatabaseViewSortingBlock)sortingBlock
+           sortingBlockType:(YapDatabaseViewBlockType)sortingBlockType
+                    version:(int)version;
+
+- (id)initWithGroupingBlock:(YapDatabaseViewGroupingBlock)groupingBlock
+          groupingBlockType:(YapDatabaseViewBlockType)groupingBlockType
+               sortingBlock:(YapDatabaseViewSortingBlock)sortingBlock
+           sortingBlockType:(YapDatabaseViewBlockType)sortingBlockType
+                    version:(int)version
+                    options:(YapDatabaseViewOptions *)options;
+
+@property (nonatomic, strong, readonly) YapDatabaseViewGroupingBlock groupingBlock;
+@property (nonatomic, strong, readonly) YapDatabaseViewSortingBlock sortingBlock;
+
+@property (nonatomic, assign, readonly) YapDatabaseViewBlockType groupingBlockType;
+@property (nonatomic, assign, readonly) YapDatabaseViewBlockType sortingBlockType;
+
+/**
+ * The version assists you in updating your blocks.
+ *
+ * If you need to change the groupingBlock or sortingBlock,
+ * then simply pass an incremented version during the init method,
+ * and the view will automatically update itself.
+**/
+@property (nonatomic, assign, readonly) int version;
+
+/**
+ * The options allow you to specify things like creating an in-memory-only view (non persistent).
+**/
+@property (nonatomic, copy, readonly) YapDatabaseViewOptions *options;
+
+@end

data/vendor/Pods/Headers/YapDatabase/YapDatabaseViewChange.h

@@ -0,0 +1,272 @@
+#import <Foundation/Foundation.h>
+
+typedef enum {
+	YapDatabaseViewChangeInsert = 1,
+	YapDatabaseViewChangeDelete = 2,
+	YapDatabaseViewChangeMove   = 3,
+	YapDatabaseViewChangeUpdate = 4,
+	
+} YapDatabaseViewChangeType;
+
+typedef enum {
+	YapDatabaseViewChangedObject     = 1 << 0, // 0001
+	YapDatabaseViewChangedMetadata   = 1 << 1, // 0010
+	YapDatabaseViewChangedDependency = 1 << 2, // 0100
+	
+} YapDatabaseViewChangesBitMask;
+
+
+/**
+ * YapDatabaseViewChange is designed to help facilitate animations to tableViews and collectionsViews.
+ * 
+ * In addition to the documentation available in the header files,
+ * you may also wish to read the wiki articles online,
+ * which are designed to give you an overview of the various technologies available.
+ * 
+ * General information about setting up and using Views:
+ * https://github.com/yaptv/YapDatabase/wiki/Views
+ * 
+ * General information about technologies which integrate with Views:
+ * https://github.com/yaptv/YapDatabase/wiki/LongLivedReadTransactions
+ * https://github.com/yaptv/YapDatabase/wiki/YapDatabaseModifiedNotification
+**/
+
+@interface YapDatabaseViewSectionChange : NSObject <NSCopying>
+
+/**
+ * The type will be either:
+ * - YapDatabaseViewChangeInsert or
+ * - YapDatabaseViewChangeDelete
+ *
+ * @see YapDatabaseViewChangeType
+**/
+@property (nonatomic, readonly) YapDatabaseViewChangeType type;
+
+/**
+ * The section index.
+ * 
+ * If the type is YapDatabaseViewChangeDelete, then this represents the originalIndex of the section (pre-animation).
+ * If the type is YapDatabaseViewChangeInsert, then this represents the finalIndex of the section (post-animation).
+**/
+@property (nonatomic, readonly) NSUInteger index;
+
+/**
+ * The corresponding group for the section.
+**/
+@property (nonatomic, readonly) NSString *group;
+
+@end
+
+////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
+#pragma mark -
+////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
+
+@interface YapDatabaseViewRowChange : NSObject <NSCopying>
+
+/**
+ * The type will be one of:
+ * - YapDatabaseViewChangeInsert
+ * - YapDatabaseViewChangeDelete
+ * - YapDatabaseViewChangeMove
+ * - YapDatabaseViewChangeUpdate
+ * 
+ * @see YapDatabaseViewChangeType
+**/
+@property (nonatomic, readonly) YapDatabaseViewChangeType type;
+
+/**
+ * The changes property is a bitmask representing what changed for the corresponding row in the database.
+ *
+ * There are 3 types represented in the bit mask:
+ * - YapDatabaseViewChangedObject
+ * - YapDatabaseViewChangedMetadata
+ * - YapDatabaseViewChangedDependency
+ * 
+ * YapDatabaseViewChangedObject means the object was changed via setObject:forKey:inCollection:.
+ *
+ * YapDatabaseViewChangedMetadata means the metadata was changed.
+ * This might have happend implicitly if the user invoked setObject:forKey:inCollection: (implicitly setting
+ * the meatadata to nil). Or explicitly if the user invoked setObject:forKey:inCollection:withMetadata: or
+ * setMetadata:forKey:inCollection:.
+ * 
+ * YapDatabaseViewChangedDependency means the row was flagged due to a cell drawing dependency configuration.
+ * See YapDatabaseViewMappings: setCellDrawingDependencyForNeighboringCellWithOffset:forGroup:
+ * 
+ * Keep in mind that this is a bitmask. So, for example, all bits might be set if
+ * a row was updated, and was also flagged due to an inter-cell drawing dependency.
+ *
+ * This may be useful for various optimizations. For example:
+ * The drawing of your cell depends only on the object.
+ * However, your objects are rather large, and you're using metadata to store small subsets of the object
+ * that often need to be fetched. In addition, you're keeping other information in metadata such as refresh dates
+ * for pulling updates from the server. The grouping and sorting block are optimized and use only the metadata.
+ * However this means that the metadata may change (due to a refresh date update),
+ * when in fact the object itself didn't change.
+ * So you could optimize a bit here by skipping some cell updates.
+ * 
+ * if (change.type == YapDatabaseViewChangeUpdate)
+ * {
+ *     if (change.modifiedColumns & YapDatabaseViewChangedObject) {
+ *         // object changed, update cell
+ *     }
+ *     else {
+ *         // only the metadata changed, so we can skip updating the cell
+ *     }
+ * }
+ *
+ *
+ * @see YapDatabaseViewChangesBitMask
+**/
+@property (nonatomic, readonly) int changes;
+
+/**
+ * The indexPath & newIndexPath are available after
+ * you've invoked getSectionChanges:rowChanges:forNotifications:withMappings:.
+ *
+ * @see YapDatabaseConnection getSectionChanges:rowChanges:forNotifications:withMappings:
+ * 
+ * These properties are designed to help facilitate animations to tableViews and collectionsViews.
+ * 
+ * Recall that a view has no concept of sections.
+ * That is, a view has groups not sections.
+ * A group is a string, and a section is just a number.
+ * 
+ * Using groups allows a view to be more dynamic.
+ * Your view may contain dozens of groups,
+ * but a particular tableView within your app may only display a subset of the groups.
+ * 
+ * For example, you may have a view for displaying products in a grocery store.
+ * Each product is grouped by department (e.g. produce, deli, bakery), and sorted sorted by name.
+ * Using this view you can easily bring up a table view which displays only
+ * a few departments such as: liquor, wine, beer.
+ * 
+ * In this example:
+ * - Section 0 = liquor
+ * - Section 1 = wine
+ * - Section 2 = beer
+ *
+ * NSArray *groups = @{ @"liquor":@(0), @"wine":@(1), @"beer":@(2) };
+ * YapDatabaseMappings *mappings = [YapDatabaseViewMappings mappingsWithGroups:groups view:@"order"];
+ *
+ * The mappings are then used to "map" between the 'groups in the view' and 'items in the table'.
+ * 
+ * Mappings can provide a lot of additional functionality as well.
+ * For example, you can configure the mappings to only display a particular range within a group.
+ * This is similar to a LIMIT & OFFSET in SQL.
+ * This is the tip of the iceberg. See YapDatabaseViewMappings.h for more info.
+ *
+ * In order to animate changes to your tableView or collectionView, you eventually do something like this:
+ * 
+ * NSArray *sectionChanges = nil;
+ * NSArray *rowChanges = nil;
+ * [databaseConnection getSectionChanges:&sectionChanges
+ *                            rowChanges:&rowChanges
+ *                      forNotifications:notifications
+ *                          withMappings:mappings];
+ * 
+ * This gives you a list of changes as they affect your tableView / collectionView.
+ *
+ * The indexPath and newIndexPath properties are modeled after:
+ * NSFetchedResultsControllerDelegate controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:
+ * 
+ * - indexPath represents the ORIGINAL indexPath for the row.
+ *   It is non-nil for the following types : Delete, Move, Update.
+ *   (And nil for insert since there was no original indexPath.)
+ *
+ * - newIndexPath represents the FINAL indexPath for the row.
+ *   It is non-nil for the following types : Insert, Move.
+ *   (And nil for delete since there is no final indexPath.)
+ *   (And nil for update since that's how NSFetchedResultsController works,
+ *    and thus how existing code might expect it to work.)
+ * 
+ * Once you have the sectionChanges & rowChanges, you can animate your tableView very simply like so:
+ * 
+ * PS - For a FULL CODE EXAMPLE, see the wiki:
+ * https://github.com/yaptv/YapDatabase/wiki/Views#wiki-animating_updates_in_tableviews_collectionviews
+ *
+ * if ([sectionChanges count] == 0 & [rowChanges count] == 0)
+ * {
+ *     // Nothing has changed that affects our tableView
+ *     return;
+ * }
+ *
+ * // Familiar with NSFetchedResultsController?
+ * // Then this should look pretty familiar
+ *
+ * [self.tableView beginUpdates];
+ *
+ * for (YapDatabaseViewSectionChange *sectionChange in sectionChanges)
+ * {
+ *     switch (sectionChange.type)
+ *     {
+ *         case YapDatabaseViewChangeDelete :
+ *         {
+ *             [self.tableView deleteSections:[NSIndexSet indexSetWithIndex:sectionChange.index]
+ *                           withRowAnimation:UITableViewRowAnimationAutomatic];
+ *             break;
+ *         }
+ *         case YapDatabaseViewChangeInsert :
+ *         {
+ *             [self.tableView insertSections:[NSIndexSet indexSetWithIndex:sectionChange.index]
+ *                           withRowAnimation:UITableViewRowAnimationAutomatic];
+ *             break;
+ *         }
+ *     }
+ * }
+ *
+ * for (YapDatabaseViewRowChange *rowChange in rowChanges)
+ * {
+ *     switch (rowChange.type)
+ *     {
+ *         case YapDatabaseViewChangeDelete :
+ *         {
+ *             [self.tableView deleteRowsAtIndexPaths:@[ rowChange.indexPath ]
+ *                                   withRowAnimation:UITableViewRowAnimationAutomatic];
+ *             break;
+ *         }
+ *         case YapDatabaseViewChangeInsert :
+ *         {
+ *             [self.tableView insertRowsAtIndexPaths:@[ rowChange.newIndexPath ]
+ *                                   withRowAnimation:UITableViewRowAnimationAutomatic];
+ *             break;
+ *         }
+ *         case YapDatabaseViewChangeMove :
+ *         {
+ *             [self.tableView deleteRowsAtIndexPaths:@[ rowChange.indexPath ]
+ *                                   withRowAnimation:UITableViewRowAnimationAutomatic];
+ *             [self.tableView insertRowsAtIndexPaths:@[ rowChange.newIndexPath ]
+ *                                   withRowAnimation:UITableViewRowAnimationAutomatic];
+ *             break;
+ *         }
+ *         case YapDatabaseViewChangeUpdate :
+ *         {
+ *             [self.tableView reloadRowsAtIndexPaths:@[ rowChange.indexPath ]
+ *                                   withRowAnimation:UITableViewRowAnimationNone];
+ *             break;
+ *         }
+ *     }
+ * }
+ *
+ * [self.tableView endUpdates];
+**/
+@property (nonatomic, readonly) NSIndexPath *indexPath;
+@property (nonatomic, readonly) NSIndexPath *newIndexPath;
+
+/**
+ * The "original" values represent the location of the changed item
+ * at the BEGINNING of the read-write transaction(s).
+ *
+ * The "final" values represent the location of the changed item
+ * at the END of the read-write transaction(s).
+**/
+
+@property (nonatomic, readonly) NSUInteger originalIndex;
+@property (nonatomic, readonly) NSUInteger finalIndex;
+
+@property (nonatomic, readonly) NSUInteger originalSection;
+@property (nonatomic, readonly) NSUInteger finalSection;
+
+@property (nonatomic, readonly) NSString *originalGroup;
+@property (nonatomic, readonly) NSString *finalGroup;
+
+@end