motion-yapper 0.0.1 → 0.0.2

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

@@ -97,4 +97,53 @@ typedef enum {
               block:(YapDatabaseSecondaryIndexBlock)block
           blockType:(YapDatabaseSecondaryIndexBlockType)blockType;
 
+/**
+ * Creates a new secondary index extension.
+ * After creation, you'll need to register the extension with the database system.
+ *
+ * @param setup
+ * 
+ *   A YapDatabaseSecondaryIndexSetup instance allows you to specify the column names and type.
+ *   The column names can be whatever you want, with a few exceptions for reserved names such as "rowid".
+ *   The types can reflect numbers or text.
+ * 
+ * @param block
+ * 
+ *   Pass a block that is one of the following types:
+ *    - YapDatabaseSecondaryIndexWithKeyBlock
+ *    - YapDatabaseSecondaryIndexWithObjectBlock
+ *    - YapDatabaseSecondaryIndexWithMetadataBlock
+ *    - YapDatabaseSecondaryIndexWithRowBlock
+ * 
+ * @param blockType
+ * 
+ *   Pass the blockType enum that matches the passed block:
+ *    - YapDatabaseSecondaryIndexBlockTypeWithKey
+ *    - YapDatabaseSecondaryIndexBlockTypeWithObject
+ *    - YapDatabaseSecondaryIndexBlockTypeWithMetadata
+ *    - YapDatabaseSecondaryIndexBlockTypeWithRow
+ * 
+ * @param version
+ * 
+ *   If, after creating the secondary index(es), you need to change the setup or block,
+ *   then simply increment the version parameter. If you pass a version that is different from the last
+ *   initialization of the extension, then it will automatically re-create itself.
+ *
+ * @see YapDatabaseSecondaryIndexSetup
+ * @see YapDatabase registerExtension:withName:
+**/
+- (id)initWithSetup:(YapDatabaseSecondaryIndexSetup *)setup
+              block:(YapDatabaseSecondaryIndexBlock)block
+          blockType:(YapDatabaseSecondaryIndexBlockType)blockType
+            version:(int)version;
+
+/**
+ * The version assists in making changes to the extension.
+ *
+ * If you need to change the columnNames and/or block,
+ * then simply pass an incremented version during the init method,
+ * and the FTS extension will automatically update itself.
+**/
+@property (nonatomic, assign, readonly) int version;
+
 @end

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

@@ -443,40 +443,148 @@
 
 /**
  * Primitive access.
+ * This method is available in case you need to store irregular data that
+ * shouldn't go through the configured serializer/deserializer.
  *
- * These are available in-case you store irregular data
- * that shouldn't go through configured serializer/deserializer.
+ * Primitive data is stored into the database, but doesn't get routed through any of the extensions.
+ *
+ * Remember that if you place primitive data into the database via this method,
+ * you are responsible for accessing it via the appropriate primitive accessor (such as
+ * primitiveDataForKey:inCollection:). If you attempt to access it via the object accessor
+ * (objectForKey:inCollection), then the system will attempt to deserialize the primitive data via the
+ * configured deserializer, which may or may not work depending on the primitive data you're storing.
+ * 
+ * This method is the primitive version of setObject:forKey:inCollection:.
+ * For more information see the documentation for setObject:forKey:inCollection:.
+ *
+ * @see setObject:forKey:inCollection:
+ * @see primitiveDataForKey:inCollection:
+**/
+- (void)setPrimitiveData:(NSData *)primitiveData forKey:(NSString *)key inCollection:(NSString *)collection;
+
+/**
+ * Primitive access.
+ * This method is available in case you need to store irregular data that
+ * shouldn't go through the configured serializer/deserializer.
+ *
+ * Primitive data is stored into the database, but doesn't get routed through any of the extensions.
  *
- * @see objectForKey:collection:
+ * Remember that if you place primitive data into the database via this method,
+ * you are responsible for accessing it via the appropriate primitive accessor (such as
+ * primitiveDataForKey:inCollection:). If you attempt to access it via the object accessor
+ * (objectForKey:inCollection), then the system will attempt to deserialize the primitive data via the
+ * configured deserializer, which may or may not work depending on the primitive data you're storing.
+ * 
+ * This method is the primitive version of setObject:forKey:inCollection:withMetadata:.
+ * For more information see the documentation for setObject:forKey:inCollection:withMetadata:.
+ *
+ * @see setObject:forKey:inCollection:withMetadata:
+ * @see primitiveDataForKey:inCollection:
+ * @see primitiveMetadataForKey:inCollection:
 **/
-- (void)setPrimitiveData:(NSData *)data forKey:(NSString *)key inCollection:(NSString *)collection;
-- (void)setPrimitiveData:(NSData *)data
+- (void)setPrimitiveData:(NSData *)primitiveData
                   forKey:(NSString *)key
             inCollection:(NSString *)collection
    withPrimitiveMetadata:(NSData *)primitiveMetadata;
-- (void)setPrimitiveMetadata:(NSData *)primitiveMetadata forKey:(NSString *)key inCollection:(NSString *)collection;
+
+/**
+ * Primitive access.
+ * This method is available in case you need to store irregular data that
+ * shouldn't go through the configured serializer/deserializer.
+ *
+ * Primitive data is stored into the database, but doesn't get routed through any of the extensions.
+ *
+ * Remember that if you place primitive data into the database via this method,
+ * you are responsible for accessing it via the appropriate primitive accessor (such as
+ * primitiveDataForKey:inCollection:). If you attempt to access it via the object accessor
+ * (objectForKey:inCollection), then the system will attempt to deserialize the primitive data via the
+ * configured deserializer, which may or may not work depending on the primitive data you're storing.
+ *
+ * This method is the primitive version of replaceObject:forKey:inCollection:.
+ * For more information see the documentation for replaceObject:forKey:inCollection:.
+ *
+ * @see replaceObject:forKey:inCollection:
+ * @see primitiveDataForKey:inCollection:
+**/
+- (void)replacePrimitiveData:(NSData *)primitiveData forKey:(NSString *)key inCollection:(NSString *)collection;
+
+/**
+ * Primitive access.
+ * This method is available in case you need to store irregular data that
+ * shouldn't go through the configured serializer/deserializer.
+ * 
+ * Primitive data is stored into the database, but doesn't get routed through any of the extensions.
+ * 
+ * Remember that if you place primitive data into the database via this method,
+ * you are responsible for accessing it via the appropriate primitive accessor (such as
+ * primitiveMetadataForKey:inCollection:). If you attempt to access it via the object accessor
+ * (metadataForKey:inCollection), then the system will attempt to deserialize the primitive data via the
+ * configured deserializer, which may or may not work depending on the primitive data you're storing.
+ *
+ * This method is the primitive version of replaceMetadata:forKey:inCollection:.
+ * For more information see the documentation for replaceMetadata:forKey:inCollection:.
+ *
+ * @see replaceMetadata:forKey:inCollection:
+ * @see primitiveMetadataForKey:inCollection:
+**/
+- (void)replacePrimitiveMetadata:(NSData *)primitiveMetadata forKey:(NSString *)key inCollection:(NSString *)collection;
+
+/**
+ * DEPRECATED: Use replacePrimitiveMetadata:forKey:inCollection: instead.
+**/
+- (void)setPrimitiveMetadata:(NSData *)primitiveMetadata forKey:(NSString *)key inCollection:(NSString *)collection
+__attribute((deprecated("Use method replacePrimitiveMetadata:forKey:inCollection: instead")));
 
 #pragma mark Object & Metadata
 
 /**
  * Sets the object for the given key/collection.
- * Objects are automatically serialized using the database's configured serializer.
+ * The object is automatically serialized using the database's configured objectSerializer.
  * 
- * You may optionally pass metadata about the object.
- * The metadata is also written to the database for persistent storage, and thus persists between sessions.
- * Metadata is serialized/deserialized to/from disk just like the object.
+ * If you pass nil for the object, then this method will remove the row from the database (if it exists).
+ *
+ * This method implicitly sets the associated metadata to nil.
 **/
 - (void)setObject:(id)object forKey:(NSString *)key inCollection:(NSString *)collection;
+
+/**
+ * Sets the object & metadata for the given key/collection.
+ * 
+ * The object is automatically serialized using the database's configured objectSerializer.
+ * The metadata is automatically serialized using the database's configured metadataSerializer.
+ * 
+ * The metadata is optional. You can pass nil for the metadata is unneeded.
+ * If non-nil then the metadata is also written to the database (metadata is also persistent).
+ *
+ * If you pass nil for the object, then this method will remove the row from the database (if it exists).
+**/
 - (void)setObject:(id)object forKey:(NSString *)key inCollection:(NSString *)collection withMetadata:(id)metadata;
 
 /**
- * Updates the metadata, and only the metadata, for the given key/collection.
- * The object for the key doesn't change.
+ * If a row with the given key/collection exists, then replaces the object for that row with the new value.
+ * It only replaces the object. The metadata for the row doesn't change.
+ * 
+ * If there is no row in the database for the given key/collection then this method does nothing.
+ * 
+ * If you pass nil for the object, then this method will remove
+**/
+- (void)replaceObject:(id)object forKey:(NSString *)key inCollection:(NSString *)collection;
+
+/**
+ * If a row with the given key/collection exists, then replaces the metadata for that row with the new value.
+ * It only replaces the metadata. The object for the row doesn't change.
  *
- * Note: If there is no stored object for the given key/collection, this method does nothing.
- * If you pass nil for the metadata, any given metadata associated with the key/colleciton is removed.
+ * If there is no row in the database for the given key/collection then this method does nothing.
+ * 
+ * If you pass nil for the metadata, any metadata previously associated with the key/collection is removed.
+**/
+- (void)replaceMetadata:(id)metadata forKey:(NSString *)key inCollection:(NSString *)collection;
+
+/**
+ * DEPRECATED: Use replaceMetadata:forKey:inCollection: instead.
 **/
-- (void)setMetadata:(id)metadata forKey:(NSString *)key inCollection:(NSString *)collection;
+- (void)setMetadata:(id)metadata forKey:(NSString *)key inCollection:(NSString *)collection
+__attribute((deprecated("Use method replaceMetadata:forKey:inCollection: instead")));
 
 #pragma mark Touch
 
@@ -487,11 +595,13 @@
  *
  *   You have a BNBook object in your database.
  *   One of the properties of the book object is a URL pointing to an image for the front cover of the book.
- *   This image gets changed. Thus the UI representation of the book needs to be updated to reflect the updated image.
- *   You realize that all your views are already listening for YapDatabaseModified notifications,
- *   so if you update the object in the database, all your views are already wired to update the UI appropriately.
- *   However, the actual object itself didn't change. So while there technically isn't any reason to
- *   update the object on disk, doing so would be the most efficient way to keep the UI up-to-date.
+ *   This image gets changed on the server. Thus the UI representation of the book needs to be updated
+ *   to reflect the updated image on the server. You realize that all your views are already listening for
+ *   YapDatabaseModified notifications, so if you update the object in the database then all your views are
+ *   already wired to update the UI appropriately. However, the actual object itself didn't change. So while
+ *   there technically isn't any reason to update the object on disk, doing so would be the easiest way to
+ *   keep the UI up-to-date. So what you really want is a way to "mark" the object as updated, without actually
+ *   incurring the overhead of rewriting it to disk.
  *
  * And this is exactly what the touch methods were designed for.
  * It won't actually cause the object to get rewritten to disk.
@@ -502,7 +612,7 @@
  * and passing the object & metadata that already exists for the key. But without the overhead of fetching the items,
  * or re-writing the items to disk.
  *
- * The touchMetadataForKey: method is similar to calling setMetadata:forKey:,
+ * The touchMetadataForKey: method is similar to calling replaceMetadata:forKey:,
  * and passing the metadata that already exists for the key. But without the overhead of fetching the metadata,
  * or re-writing the metadata to disk.
  * 

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

@@ -1,9 +1,13 @@
 #import <Foundation/Foundation.h>
 
 #import "YapDatabaseExtension.h"
+#import "YapDatabaseViewTypes.h"
 #import "YapDatabaseViewOptions.h"
 #import "YapDatabaseViewConnection.h"
 #import "YapDatabaseViewTransaction.h"
+#import "YapDatabaseViewMappings.h"
+#import "YapDatabaseViewChange.h"
+#import "YapDatabaseViewRangeOptions.h"
 
 /**
  * Welcome to YapDatabase!
@@ -22,122 +26,46 @@
  * Just in case you don't have Internet access,
  * see the quick overview in YapDatabaseView.h.
 **/
+@interface YapDatabaseView : YapDatabaseExtension
 
-/**
- * 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.
+/* Inherited from YapDatabaseExtension
+ 
+@property (nonatomic, strong, readonly) NSString *registeredName;
 
-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.
+ * See the wiki for an example of how to initialize a view:
+ * https://github.com/yaptv/YapDatabase/wiki/Views#wiki-initializing_a_view
  *
- * 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.
+ * @param groupingBlock
  * 
- * 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.
+ *   The grouping block handles both filtering and grouping.
+ *   
+ *   @see YapDatabaseViewTypes.h for block type definition(s).
  * 
- * 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.
+ * @param groupingBlockType
  * 
- * Performance Note:
+ *   Specify the type of groupingBlock that is being passed.
+ *   
+ *   @see YapDatabaseViewTypes.h for block type definition(s).
  * 
- * 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.
+ * @param sortingBlock
  * 
- * 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.
+ *   The sorting block handles sorting of objects within their group.
+ *   
+ *   @see YapDatabaseViewTypes.h for block type definition(s).
  * 
- * Although this may be considered "internal information",
- * I feel it is important to explain for the following reason:
+ * @param sortingBlockType
  * 
- * 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
+ *   Specify the type of sortingBlock that is being passed.
+ *   
+ *   @see YapDatabaseViewTypes.h for block type definition(s).
  *
- * @param version
+ * @param versionTag
  *
  *   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
+ *   then simply use the versionTag parameter. If you pass a versionTag that is different from the last
  *   initialization of the view, then the view will automatically flush its tables, and re-populate itself.
  *
  * @param options
@@ -154,13 +82,13 @@ typedef enum {
           groupingBlockType:(YapDatabaseViewBlockType)groupingBlockType
                sortingBlock:(YapDatabaseViewSortingBlock)sortingBlock
            sortingBlockType:(YapDatabaseViewBlockType)sortingBlockType
-                    version:(int)version;
+                 versionTag:(NSString *)versionTag;
 
 - (id)initWithGroupingBlock:(YapDatabaseViewGroupingBlock)groupingBlock
           groupingBlockType:(YapDatabaseViewBlockType)groupingBlockType
                sortingBlock:(YapDatabaseViewSortingBlock)sortingBlock
            sortingBlockType:(YapDatabaseViewBlockType)sortingBlockType
-                    version:(int)version
+                 versionTag:(NSString *)versionTag
                     options:(YapDatabaseViewOptions *)options;
 
 @property (nonatomic, strong, readonly) YapDatabaseViewGroupingBlock groupingBlock;
@@ -170,13 +98,26 @@ typedef enum {
 @property (nonatomic, assign, readonly) YapDatabaseViewBlockType sortingBlockType;
 
 /**
- * The version assists you in updating your blocks.
+ * The versionTag 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.
+ * then simply pass a different versionTag during the init method, and the view will automatically update itself.
+ * 
+ * If you want to keep things simple, you can use something like @"1",
+ * representing version 1 of my groupingBlock & sortingBlock.
+ * 
+ * For more advanced applications, you may also include within the versionTag string:
+ * - localization information (if you're using localized sorting routines)
+ * - configuration information (if your sorting routine is based on some in-app configuration)
+ *
+ * For example, if you're sorting strings using a localized string compare method, then embedding the localization
+ * information into your versionTag means the view will automatically re-populate itself (re-sort)
+ * if the user launches the app in a different language than last time.
+ * 
+ * NSString *localeIdentifier = [[NSLocale currentLocale] localeIdentifier];
+ * NSString *versionTag = [NSString stringWithFormat:@"1-%@", localeIdentifier];
 **/
-@property (nonatomic, assign, readonly) int version;
+@property (nonatomic, copy, readonly) NSString *versionTag;
 
 /**
  * The options allow you to specify things like creating an in-memory-only view (non persistent).