I have a parse class(named "Story") with following columns:
contents - Array of Pointers to Media class
creator - User pointer
lastPosted - Date
title - String
users - array of pointers to User class
I am trying to update a PFObject from "Story" class like this
storyObject.addUniqueObjectsFromArray(selectedFriends, forKey: "users")
storyObject.setObject(createStoryTextField.text, forKey: "title")
storyObject.saveInBackgroundWithBlock({ (succeed: Bool, error: NSError?) -> Void in
hud.hide(true)
})
In some cases the completion block takes a lot of time to complete. By debugging, I have found that the more objects in the "contents" column, the longer it takes. But I haven't even updated the "contents". All the values in the code are not nil. I checked for that too. Any help would be appreciated. Thanks.
This is potentially expected behavior. In general when you put something on a background thread (like saveInBackgroundWithBlock is almost definitely doing) it will take a lot longer to complete than if you call it on the main thread. If you need it to return quickly and don't mind blocking the UI, you can use the save: method.
You also may want to check to see how many requests you are making simultaneously as this may slow down each one.
Finally, if you want to customize the network behavior of Parse more than you already do, you can just use the REST API and make all your own network calls (using NSURLSession or a third party library like AFNetworking.)
Related
We're using Realm (Swift binding currently in version 3.12.0) from the earliest days in our project. In some early versions before 1.0 Realm provided change listeners for Results without actually giving changeSets.
We used this a lot in order to find out if a specific Results list changed.
Later the guys at Realm exchanged this API with changeSet providing methods. We had to switch and are now mistreating this API just in order to find out if anything in a specific List changed (inserts, deletions, modifications).
Together with RxSwift we wrote our own implementation of Results change listening which looks like this:
public var observable: Observable<Base> {
return Observable.create { observer in
let token = self.base.observe { changes in
if case .update = changes {
observer.onNext(self.base)
}
}
observer.onNext(self.base)
return Disposables.create(with: {
observer.onCompleted()
token.invalidate()
})
}
}
When we now want to have consecutive updates on a list we subscribe like so:
someRealm.objects(SomeObject.self).filter(<some filter>).rx.observable
.subscribe(<subscription code that gets called on every update>)
//dispose code missing
We wrote the extension on RealmCollection so that we can subscribe to List type as well.
The concept is equal to RxRealm's approach.
So now in our App we have a lot of filtered lists/results that we are subscribing to.
When data gets more and more we notice significant performance losses when it comes to seeing a change visually after writing something into the DB.
For example:
Let's say we have a Car Realm Object class with some properties and some 1-to-n and some 1-to-1 relationships. One of the properties is a Bool, namely isDriving.
Now we have a lot of cars stored in the DB and bunch of change listeners with different filters listing to changes of the cars collection (collection observers listening for changeSets in order to find out if the list was changed).
If I take one car of some list and set the property of isDriving from false to true (important: we do writes in the background) ideally the change listener fires fast and I have the nearly immediate correct response to my write on the main thread.
Added with edit on 2019-06-19:
Let's make the scenario still a little more real:
Let's change something down the hierarchy, let's say the tires manufacturer's name. Let's say a Car has a List<Tire>, a Tire has a Manufacturer and a Manufacturer has aname.
Now we're still listing toResultscollection changes with some more or less complex filters applied.
Then we're changing the name of aManufacturer` which is connected to one of the tires which are connected to one of the cars which is in that filtered list.
Can this still be fast?
Obviously when the length of results/lists where change listeners are attached to gets longer Realm's internal change listener takes longer to calculate the differences and fires later.
So after a write we see the changes - in worst case - much later.
In our case this is not acceptable. So we are thinking through different scenarios.
One scenario would be to not use .observe on lists/results anymore and switch to Realm.observe which fires every time anything did change in the realm, which is not ideal, but it is fast because the change calculation process is skipped.
My question is: What can I do to solve this whole dilemma and make our app fast again?
The crucial thing is the threading stuff. We're always writing in the background due to our design. So the writes itself should be very fast, but then that stuff needs to synchronize to the other threads where Realms are open.
In my understanding that happens after the change detection for all Results has run through, is that right?
So when I read on another thread, the data is only fresh after the thread sync, which happens after all notifications were sent out. But I am not sure currently if the sync happens before, that would be more awesome, did not test it by now.
In my program, it uses both of
DispatchQueue.global(qos: .background)
and
self.concurrentQueue.sync(flags: .barrier)
to deal with the background multithread issues.
It is swift 3 so I use the latest way to get the childContext:
lazy var context: NSManagedObjectContext = {
return (UIApplication.shared.delegate as! AppDelegate).persistentContainer.newBackgroundContext()
}()
I also enable -com.apple.CoreData.ConcurrencyDebug 1 to debug
Then the problem occurs:
1, When there's an API call and in the callback block (background thread), I need to fetch the core data, edit, then save. I tried to use self.context from the code above to call performBlockAndWait and do save inside of this block. The whole process goes fine but when I try to access my result outside of this block but inside of the callback block, the error occurs. I have also tried to get the objectId and getObjectById by both self.context and self.context.parent and the error occurs on this line. What did I do wrong and how should I do this? since I need to use the result everywhere in many different thread (not context).
2, I read a post says that I need one context per thread, then in my case, how do I determine which exact thread it is if it's a call back from API call and do I really need to do this?
3, You might ask that why do I need a privateConcurrentType, because my program has things need to be running in background thread so that it has to do it this way, (read from other post), is this right?
4, Even in my question 1, get object by passing objectId to different Context still not working in my case. Let's assume this is the proper way. How am I gonna manage passing so many objectID throughout my entire program in different thread without being super messy? To me this sounds crazy but I suppose there's a much cleaner and easier way to deal with this.
5, I have read many posts some are pretty old (before swift 3), they have to do childContext.save then parentContext.save, but since I use the code above (swift 3 only). It seems that I can do childContext.save only to make it work? Am I right?
Core data in general is not multithreading friendly. To use it on concurrent thread I can assume only bad things will happen. You may not simply manipulate managed objects outside the thread on which the context is.
As you already mentioned you need a separate context per thread which will work in most cases but by my experience you only need one background context which is read-write and a single main thread read-only context that is used for fetch result controllers or other instant fetches.
Think of a context as some in-memory module that communicates with the database (a file). Fetched entities are shared within the context but are not shared between contexts. So you can modify pretty much anything inside the context but that will not show in the database or other contexts until you save the context into the database. And if you modify the same entity on 2 contexts and then save them you will get a conflict which should be resolved by you.
All of these then make quite a mess in the code logic and so multiple contexts seem like something to avoid. What I do is create a background context and then do all of the operations on that context. Context has a method perform which will execute the code on its own thread which is not main (for background context) and this thread is serial.
So for instance when doing a smart client I will get a response from server with new entries. These are parsed on the fly and I perform a block on context to get all the corresponding objects in the database and create the ones that do not exist. Then copy the data and save the context into database.
For the UI part I do similar. Once an entry should be saved I either create or update the entity on the background context thread. Then usually do some UI stuff on completion so I have a method:
public func performBlockOnBackgroundContextAndReturnOnMain(block: #escaping (() -> Void), main: #escaping (() -> Void)) {
if let context = context {
context.perform {
block()
DispatchQueue.main.async(execute: { () -> Void in
main()
})
}
}
}
So pretty much all of the core data logic happens on a single thread which is in background. For some cases I do use a main context to get items from fetch result controller for instance; I display a list of objects with it and once user selects one of the items I refetch that item from the background context and use that one in the user interface and to modify it.
But even that may give you trouble as some properties may be loaded lazily from database so you must ensure that all the data you need will be loaded on the context and you may access them on the main thread. There is method for that but I rather use wrappers:
I have a single superclass for all the entities in the database model which include id only. So I also have a superclass wrapper which has all the logic to work with the rest of wrappers. What I am left with in the end is that for each of the subclass I need to override 2 mapping methods (from and to) managed object.
It might seem silly to create additional wrappers and to copy the data into memory from managed object but the thing is you need to do that for most of the managed objects anyway; Converting NSData to/from UIImage, NSDate to/from Date, enumerations to/from integers or strings... So in the end you are more or less just left with strings that are copied 1-to-1. Also this makes it easy to have the code that maps the response from your server in this class or any additional logic where you will have no naming conflicts with managed objects.
I'm new to CloudKit and I was trying to figure out if a Record was created by the current user. I have researched this topic and have come about two methods to do this. I'm not sure which one is right or better and I don't even quite understand how the second method works.
The first way is using the following method to get the current user and then comparing it to the user who created the record:
func fetchUserRecordID(
completionHandler: (recordID: CKRecordID?, error: CKError?) -> Void
)
The second way involves an extension on CKRecord:
extension CKRecord{
var wasCreatedByThisUser: Bool{
return (creatorUserRecordID == nil) || (creatorUserRecordID?.recordName == "__defaultOwner__")
}
}
The first method is making another call to the server to fetch an additional record. The downside is that costs time, it counts against your monthly traffic quotas, and you have yet another async callback function that your code flow will have to account for. If you wind up calling this check a lot, you would generate a lot of unnecessary traffic to the server.
The second method is checking a value, creatorUserRecordID, that came with the record you already fetched. So at the time you check its value, it's all local data, no additional calls to the server and no async processing required.
Per the answer here: creatorUserRecordID.recordName contains "__defaultOwner__" instead of UUID shown in Dashboard, __defaultOwner__ is a synonym for the local user.
The second method looks to be the better choice for most scenarios I can think of.
I need to run a SYNCHRONOUS call to parse.com. This is what I got:
var query = PFQuery(className:"myClass")
query.whereKey("groupClassId", equalTo:self.currentGroupId)
query.selectKeys(["objectId", "firstName", "lastName"])
self.arrayCurrentData = query.findObjects() as Array<myData>
This return the correct number of rows from parse.com and fills up my local array. But how can I extract the data from the array? If I look at the array at runtime it shows that all the data I need is in 'serverData' in self.arrayCurrentData.
Normally if I loop an async(findObjectsInBackgroundWithBlock) filled array I would ask
self.arrayCurrentData[i].lastName
to get the lastName, but that is not the case in the sync array. There I can't ask directly for values (or so it seems).
Anyone who know what I am talking about and how to get data synchronous from parse.com?
Get the PFObject's attributes with valueForKey(). This is true whether or not the object was fetched synchronously. In other words...
self.arrayCurrentData[i].valueForKey("lastName")
EDIT - This approach generates a compiler message because you've typed the response as Array<myData>. But find returns PFObjects, so ...
self.arrayCurrentData = query.findObjects() as [PFObject]
... is the correct cast. I'm not a swift speaker, but the expression self.arrayCurrentData[i].lastName pleases the compiler because arrayCurrentData[i] is typed as myData. But this fails at run time because the real returned objects are PFObjects.
As an aside, I'd take a hard look at the rationale for fetching synchronously. I can't think of a case where its a good idea on the main thread. (off the main okay, but then you've already opted for asynch vs. the main, and the block-based methods provide a good way to encapsulate the post-fetch logic).
When I implement the getLoggedInUserOnSuccess:onFailure method (or the loginWithUsername: password: onSuccess:^(NSDictionary *results)...method in xcode, the results array does not become available until after all of my code has finished running. (If I NSLog the results, they will show up correctly.)
There is one other question that mentions this in Stackoverflow:
How to get the sm_owner User object using StackMob as backend
However, the Stackmob Evangelist in the answer here does not suggest that there is any requirement for a completion block or something of this nature. (And in fact, in his own code, it appears to work without such a block or any sort of "waiting.") This was my first hunch as to what might be going wrong.
(Without posting a ton of code, I am trying to use this function to get the sm_owner which then serves as the predicate in the FetchedResultsController's getter, to ensure the user only sees their own creations and not those of other users, when in one view; in another fetch, they might be able to see the creations of users they follow.)
Has anyone else tried to use one of these methods with a results dictionary returned to write the predicate on a FetchedResultsController or similar and been able to make it work?
None of the Stackmob tutorials appear to limit data returned from a database based on its creator as far as I can tell.
If you set your schema's read permissions to "Allow to sm_owner", then you don't need to place a predicate on the fetch. Doing a generic fetch will return only those objects owned by the current logged in user.