overcommitted / parcelkit Goto Github PK

Yup, this is an unsupported iOS 5 issue, but I thought I'd let you know anyway. It seems that in iOS 5 [PKSyncManager SyncID] is returning a null value, and that's why this isn't working for iOS 5.

I'd rather not drop support for iPad 1s in my app. I'm not sure what all is going on in this function, but it seems like it's a pretty trivial function to be the one to kill iOS 5.

Then again, a bigger issue could crop up if this one were to get fixed, so you never know.

I tried installing from scratch yesterday using Cocoapods, and I got a compilation error of the pod, saying it couldn't find the header "Dropbox/Dropbox.h". I fixed it with this commit: andygeers@9c0d293

• basically, the search path is hard coded to look at the 3.1.0 framework, whereas the dependency (defined as ~> 3.1.0) was actually pulling in the 3.1.1 framework.
  Is there a more general way to define the search path so that it uses whatever framework actually gets installed?

We have a scenario where invalid data exists (e.g. a required field is nil) on the Dropbox datastore and then it comes into our app. The sync fails because of Core Data validations. We would like to handle this error in our app, but currently there's no way to know something went wrong. We have a solution here:
vijayj@d89df6d. The notification that's posted when incoming changes are saved now includes an error if something went wrong.
I didn't make this a pull request because it's on top of a branch that we currently use in our app, but you should be able to cherry pick the commit over.

Dropbox now have database apis for osx. Support for osx will be great awesome.

Basically the same issue as #25 now that 3.1.2 is out.

Does it support entity with image ? Both Binary Data (Allow external Storage) or by keeping file URL.

We are using the - (NSDictionary *)syncedPropertiesDictionary:(NSDictionary *)propertiesByName to only sync a few selected attributes with dropbox. This works great when syncing from client to dropbox.
However when you try resyncing from dropbox, the method in NSManagedObject+ParcelKit.m
- (void)pk_setPropertiesWithRecord:(DBRecord *)record syncAttributeName:(NSString *)syncAttributeName
does not use the keys from syncedPropertiesDictionary to sync. It would be nice if the setPropertiesWithRecord method can use the syncedPropertiesDictionary so that we can sync up partial attributes/relationships from the dictionary

Right now the latest code on master specifies a dependency with Dropbox 2.x in the podspec but the Dropbox 3.0 SDK is included as a framework. One of these should be removed.

I am attempting to do an archive build of my application and keep getting this error during the execute shell script phase:

cp: /Users/wayne/Library/Developer/Xcode/DerivedData/ParcelKit-djdcjakqlvinjzgepjzjqnpyiqyu/Build/Intermediates/ArchiveIntermediates/Framework/IntermediateBuildFilesPath/UninstalledProducts/Headers/: No such file or directory

This occurs in Xcode 5.1.1, Xcode 6 b2. I encounter this problem whether it is in the context of the app or the standalone archive of the framework. Any tips?

We all need to find new solutions now that Dropbox have announced they are deprecating their Datastore service: https://blogs.dropbox.com/developers/2015/04/deprecating-the-sync-and-datastore-apis/

As I evaluate the different options, I thought it would be helpful to put it somewhere public where people could comment on it and we could keep it up-to-date as helpful suggestions come in.

Here are some of the alternative options:

Option 1) Rewrite ParcelKit using Core API

As a community, we could rewrite ParcelKit to use the Core Dropbox API, aiming to keep ParcelKit's API itself roughly unchanged. One could imagine using a Dropbox folder per Datastore "table", and one JSON file per "record" (using the record ID as the filename).

Pros:

• to the end user, it carries on working much as before - they still use the same Dropbox account as before
• Payment also remains the user's concern - it uses their storage quota and the user pays
• Non-JSON content (i.e. files) can be stored alongside the JSON data
• User data is encrypted

Cons:

• Similar cons to the Dropbox Datastore itself - relative to other options, not all that many people have Dropbox accounts
• Might require quote a lot of work to move to a totally different paradigm.

Challenges:

• Dropbox have told me that the Core API does not support offline access in the way that the Datastore API used to
• You would have to implement a way to handle merge conflicts - you'd lose the elegant way that the Datastore used to do it

Option 2) CouchBase Lite

See their blog post here: http://blog.couchbase.com/syncing-with-core-data

Pros:

• Very similar model to ParcelKit / Datastore - you can drop in a plugin that makes your Core Data migrate nicely

Cons:

• You have to run the open source CouchBase on your own server
• You have to pay a lot if you want them to do support your CouchBase server

Option 3) Google Drive Application Data folder

Google Drive's API supports something called the "Application Data" folder: https://developers.google.com/drive/web/appdata

This would be akin to option 1 - just using Google Drive to store JSON files rather than Dropbox.

Pros:

• Lots of people have Google Drive accounts
• Uses the user's own storage quota / the user pays for it.
• Unlike Dropbox Core API, it seems like the Google Drive API supports offline access: https://developers.google.com/drive/android/files

Cons:

• Might be even more work than migrating to the Dropbox Core API
• There's a pretty tiny data limit on how much you can store in Google Drive's "Application Data" folder

Challenges:

• How well does it handle merge conflicts?

Option 4) Amazon Cognito

As I understand it, Amazon has a roughly equivalent service to the Datastore: "Cognito" http://aws.amazon.com/cognito/

Pros:

• Handles offline access nicely
• roughly similar schema model to Datastore
• most people have an amazon account

Cons:

• There's a pretty tiny number of records permitted, making this essentially useless.
• The developer has to pay all costs which scale according to the number of users and the amount of data they store.
• This gets even worse if you support files such as photos alongside the JSON data (presumably you'd have to store that in your own S3 bucket?)

Option 5) Firebase / Parse

There are various third-party services that handle sync for you, top ones that come to mind are Parse and Firebase.

Roughly similar models to Amazon Cognito, except that I imagine you have to handle your own user registrations? (Anybody know?)

Pros:

• Multi-platform
• Both handle offline access nicely
• Parse has a nice online admin dashboard
• Parse has a large developer community

Cons:

• Significant rewrite of your application from a ParcelKit world
• The developer pays all costs
• Where do you store non-JSON data such as photos?
• Parse doesn't encrypt user data automatically

Option 6) CloudKit

For some people, CloudKit will be a suitable alternative, to sync their iOS-only Core Data database.

Pros:

• Better than iCloud Core Data Sync used to be
• All iOS users have an account?

Cons:

• iOS only. For anybody with a cross-platform app to support this is a non-starter.

Anything else?

There's probably a million alternatives I've missed. Any suggestions?

I'm seriously considering undertaking Option 1 myself, because I have no money to pay for services such as Firebase / Parse! But I have a feeling it might turn out to be harder than I thought.

I have a core-data model with a few one-to-many relationships between entities (i.e. standard parent-child relationships, etc.) and I have successfully 'pushed' the data to dropbox by following the pattern in the Toado sample.

When I link a second device and the sync-manager attempts to populate core-data on that device from the records in the dropbox datastore it is failing, however, as it appears to be attempting to load the child entities before the parent entities are loaded and so the referential integrity is violated.

The only difference that I can see from my model and that of Toado is that my child-to-parent relationships are required whereas those in Toado are optional -- I'm hoping that I don't have to make all of these relationships optional... or do I?

Not sure how the NDA effects this but can the tests section of this repo be public right now? Just do not want you getting in trouble for this, when you are writing what looks like a very promising framework.

Hi there,

I got a problem, struggling to solve it so far . Maybe you could help me with that.
The thing is when I run the app for the first time I have some preloaded data for my Core Data project.
For example, I preload two categories named "one" and "two".
Then, when I turn the dropbox sync on for the first time in case if I already synced my app before and these two categories already in dropbox datastore, they got duplicated by dropbox sync. So I have two copies of "one" and two copies of "two".
If I delete my app from the iOS simulator and then install it again with newly preloaded data and these two categories, when I first sync with the same data from dropbox - I got 3 copies of these two categories. And it goes on.
Maybe there is some method or the way to avoid it? Would appreciate any help.

Thank you.

Hello.
I create test project where want to integrate ParcelKit and MagicalRecord.
It almost got me, but there is one problem.
If the application to insert the data, and then login in dropbox will crash.

Error:

 2013-08-02 14:46:54.698 MCCoreData[2280:907] [ERROR] ERR: DROPBOX_ERROR_INVALID: misc.cpp:69: record ID cannot be null
 2013-08-02 14:46:54.710 MCCoreData[2280:907] DropboxSync error - Error Domain=dropbox.com Code=2001 "The operation couldn’t be completed. (dropbox.com error 2001.)" UserInfo=0x1f54a090 {desc=misc.cpp:69: record ID cannot be null}
 2013-08-02 14:46:54.712 MCCoreData[2280:907] [ERROR] ERR: DROPBOX_ERROR_INVALID: misc.cpp:69: record ID cannot be null
 2013-08-02 14:46:54.714 MCCoreData[2280:907] DropboxSync error - Error Domain=dropbox.com Code=2001 "The operation couldn’t be completed. (dropbox.com error 2001.)" UserInfo=0x20055790 {desc=misc.cpp:69: record ID cannot be null}

The second time synchronization application works fine.
My test project - https://github.com/nullproduction/MCCoreData

Please tell me where I'm wrong?

I have this issue:

TableA related with TableB and TableC .

1. Created an entry for tableA " a1" on one device.
2. Turned On Dropbox Sync and this synced it " a1" correctly on all device (browsing datastore is all ok).
3. Turned Off Dropbox and added another entry " a2"
4. " a2" on local core data had relationship with TableC and tableB
5. Turned On dropbox.
6. After DropBox Sync " a2" didn't has more relationship with TableB and TableC so two fields for relationship are NULL .

We sometimes get NSMergeConflict errors logged from [PKSyncManager updateCoreDataWithDatastoreChanges]. This is possible when changes are saved to the persistent store by another managed object context while updateCoreDataWithDatastoreChanges is running.
A simple solution to this is to set the merge policy on the managed object context:
vijayj@c05e287

Thank you for ParcelKit. Works really cool.
Why requires a minimum of iOS 6.1?
What technical problems adding support ios5.1?

Getting this constantly even when sync batch size is reduced to 1 :-(
Any help would be greatly appreciated!

ERR: DROPBOX_ERROR_SIZE_LIMIT: database.cpp:138: delta size limit
exceeded (sync() more often!)
DropboxSync error - Error Domain=dropbox.com Code=2012 "The operation
couldn’t be completed. (dropbox.com error 2012.)" UserInfo=0x17f45350
{desc=database.cpp:138: delta size limit exceeded (sync() more
often!)}

I updated my Core Data model to a new version.
In this version i only added a new non optional attribute with a default value (BOOL).
After getting old Data from dropbox, the core data save process fails,
because ParcelKit trys to set a nil value to an non optional attribute in line
116 from NSManagedObject+ParcelKit.h
[strongSelf setValue:value forKey:propertyName];

I think that is not the right behaviour.
You can easily fix this by adding:

if(value || [propertyDescription isOptional])
 {
            [strongSelf setValue:value forKey:propertyName];
 }

I have 2 entity Parent and Child. When turn Dropbox sync off and add new Child to Parent, this newly created child disappear when I turn Dropbox sync back on. Have any one experienced this ?

Repro steps for Toado:

1. Create Task A and let it sync on all devices.
2. Turn Dropbox sync off for one device (Say Device C).
3. Create Tag B under Task A.
4. Turn Dropbox sync back on for device C.

Expect
Every device Task A got Tag B.

Result.
Device C got no Tag while others got Tag B.

I just set up ParcelKit using Dropbox Sync 3.1.1 and followed all the instructions.

I link my app to Dropbox then when I attempt to create a record in any of my entities, I get this error:

Thread 1: EXC_BAD_ACCESS (code=1, address=...)

I tried deleting the app and rebuilding, cleaning, etc. but it still happens.

Any idea what might be wrong?

It seems that the method sets up a managed object context with PrivateQueueConcurrencyType. However, the code seems to be running on main thread as it does not use performBlock. This could be a possible fix:

    NSManagedObjectContext *managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
    [managedObjectContext setPersistentStoreCoordinator:[self.managedObjectContext persistentStoreCoordinator]];
    [managedObjectContext setUndoManager:nil];

    [managedObjectContext performBlockAndWait:^{
        __block NSMutableArray *updates = [[NSMutableArray alloc] init];
...

Everything work perfectly for NSFetchedResultController view controller, but I have one controller that not using it. Is there any notification I can registered to ?

Our app has a default context where most of the work is done, and a different context for creating and editing entities. Our PKSyncManager points to the default context. We synchronize between the contexts using NSManagedObjectContextDidSaveNotification and mergeChangesFromContextDidSaveNotification. When changes are merged into the default context they aren't synced to Dropbox because PKSyncManager only listens for NSManagedObjectContextWillSaveNotification on its context, which doesn't happen on our default context when merging changes.

We have a potential fix vijayj#1 with a couple issues:

1. It requires the client code to call a new method managedObjectContextDidSave: when the default context merges changes.
2. This new method managedObjectContextDidSave is getting called when updateCoreDataWithDatastoreChanges: saves changes from Dropbox, leading to inefficiency.

Our fork also fixes an issue where syncIDs are not set across related objects soon enough.

PKSyncManager currently uses NSManagedObjectContextWillSaveNotification to save changes to managed objects into the Dropbox datastore. According to this article, CoreData validations run after the WillSave notification is fired. Thus, you could have invalid data on a managed object, save the object, then PKSyncManager would pick up the changes and save them to the Dropbox datastore. Soon after, CoreData validations would fail for the object, but you've already saved the bad data to the Dropbox data store.

Is there a reason that PKSyncManager doesn't just use NSManagedObjectContextDidSaveNotification, which fires after coredata validations?

Note I haven't seen any problems like this in our app, it's just something I thought of that could theoretically happen, and I don't have time right now to actually try to write a failing test.

Hi there,
I get some errors like this

[!] Unable to satisfy the following requirements:
- `Dropbox-Sync-API-SDK (~> 2.1)` required by `Podfile`- `Dropbox-Sync-API-SDK (~> 2.0.3)` required by `ParcelKit (1.2.1)` 

every time I'm trying to update Dropbox API, because ParcelKit still works with 2.0.3 version and Dropbox already released 2.1.2 (2.1.0 is the latest one so far through CocoaPods) and they have a lot of bugs fixed in 2.1.0 and higher.

If I go round of ParcelKit and install Dropbox 2.1.0 with CocoaPods I get this weird Dropbox error when I compile and syncing becomes unpredictable:

[WARNING] ERR: DROPBOX_ERROR_SHUTDOWN: DBHTTPRequest.mm:567: Request cancelled.

So could you please update ParcelKit?

Thanks.

Hello,
I am using ParcelKit for syncing in my app.
Data is moving correctly from app to dropbox but when I am retrieving the same data in different device, data become duplicate.
I don't know why its happening. I have added syncID with the type String. with Indexed property checked.
I have used TodoDataManager class for syncing. (just added my Entities name )
https://github.com/daikini/toado/blob/master/Toado/Classes/Models/TDODataManager.m

I am not getting any solution for this problem. Is there any solution?

Please help me for this issue.

Hi,

I'd like to implement ParcelKit for syncing where a group of users would need to have access to the same data (read/write). Is this possible with ParcelKit ?

Sometimes when the application loads crash.

Screen: