simple question, as per the subject: i have no intention of uploading changes to a returned array of PFObjects, but want to purge the array of specific items. Given it is set to readonly, what is the best way to approach this while still using PFQueryTableViewController?
Or is it better to got with a regular tableviewcontroller and lose the benefits of parse's VC?
I am trying to wrap my head around getting the proper data i require but without proper SQL, it seems very very difficult. (lack of Distinct, grouping etc)
I would override the objectsDidLoad and objectAtIndexPath methods if you want to modify the returned results. See here for a better explanation: https://parse.com/questions/using-pfquerytableviewcontroller-for-uitableview-sections
It's just a good post on overriding the methods in PFQTVC to do different things with the data.
Related
I'm wondering if there is some sort of way to set up something similar to a spreadsheet in Xcode. I'm trying to create a 'tapping game' or a 'clicker game' and storing so many variables in regular coding would be really tough.
Having this 'table' would enable me to keep track of multipliers and upgrade levels instead of clogging my coding with it.
Preferably, I could then just tell my code what to pull and what to look for off of the table. The table would be an 'engine' of sorts and it would not be UI. The table would do all of the work behind scenes, then show it through UI based on labels and buttons.
As traxido is saying, without more details we can't point you to a concrete example/solution. Base on the title the answer is yes. It's not a ui component though. It doesn't even need to be one.
What you want is a data structure to hold your data in a way that's convenient to access (save and retrieve). You could create a class which is a composite of other data structures like arrays and dictionaries and possibly other data structures. You might end up having many questions before you're through.
So: the answer is yes. Try it yourself and ask new questions if you get stuck.
Provide the code and error messages and I bet you quickly get answers.
Yes, you can.
Create a shared or singleton instance and retain all the data in instances of it.
(or) create a custom data structure and overide set or get methods to autoprocess the exiting data everytime you add or delete data element
Ex: If you want to maintain an array thats is always sorted. MySortedArray is the custom structure that inherits NSMutableArray and maintain a protected NSMutableArray instance. Overide addObject method to ensure sorting it whenever a new object is added.
I have an api which could look like http://URL/news/:lastloaded/:size where lastloadedand size is the range of objects the api should return. This api returns a list of different news, which i want to show in a tableView. However in order to make it effective i wan't to make some kind of pagination, so that not all objects is loaded into the tableView. This i've achieved through simple variables like
let pageSize = 20
var lastLoadedPage = 0
however how do i make sure that the database in my case realm.io always is up to date with all the news from the api. I can easily change the api and add more parameters if it makes this easier? What is best practice? i'm using Alamofire and realm.io
Realm itself doesn't actually require pagination. The data is saved straight to disk, and then only the properties that are required are lazily paged in as they are called. As such, it's very memory-efficient, so much to the point where managing blocks of objects in memory (like pagination works) isn't necessary.
If you want to 'simulate' pagination with Realm, it's simply a matter of querying for all of the objects as a List, and then pulling out a sub-set of the objects you wish to display.
That all being said, it's probably still wise to paginate your calls to the web API so you don't needlessly download more news items than you require, but once they're downloaded and saved to Realm, you won't need to worry about any similar device-side logic. :)
I'm making a simple bank account tracker, for self-instructional purposes. I'm using Core Data to store three entities, related as in the screenshot:
WMMGTransaction objects are simply stored as they are recorded, and extracted as needed to feed tableviews and detail views. This will be done via NSFetchedResultsController and a predicate. I'm using MagicalRecord to access Core Data, if that matters.
My question is this:
When I pass WMMGAccount data from one VC to another, such as when creating a new account, or when selecting one from a list (via delegation as a rule), does it matter if I pass a reference to the entire entity, or can I just use an NSString bearing the .name of the account and identify the account when required with a predicate and an NSFetchedResultsController? I guess this is a strategy question, and may generate discussion, rather than having a cut and dried answer, but I'm wrestling with it, so I thought I'd ask.
It sounds like you're asking if you should pass an object to the code that needs it, or if you should pass information that could be used to look up the same object again.
Unless you need to use the managed object on a different thread or queue, you should always pass the actual object. No sense re-fetching an object you already have. It's extra work and code complexity that (unless there are some unusual extenuating details you didn't mention) won't help in any way.
If you are needing to use the object on a different queue or thread, passing information that can be used to look it up is the correct approach. But in that case-- don't pass the value of one of the properties. Use the managed object ID.
Core Data won't force name values to be unique, while the object's managedObjectID is unique. It's also faster when retrieving the object, because you can use objectForID: or existingObjectForID: instead of performing a fetch.
I use Core Data within my iOS 7 app to handle the editing and creation of entities. The entities have relationships between them, which all have inverses (as Apple advises).
For the sake of this question, let's pick any one of these interrelated entities and call it the Root entity: the thing that I want to encode with; the thing that logically lives on the 'top' of the hierarchy. I will call this the 'object graph'.
The question is:
What's the easiest way of encoding and decoding such an object graph to and from NSData?
The reason I want to do this is that I'd like my Core Data object graph to be persisted onto a cloud service, without the need of writing my own NSIncrementalStore subclass (it's a bit involved...!).
AutoCoding together with HRCoder almost looks like it could do the job, but I've experimented with this combination and it doesn't quite work with NSManagedObjects at the time of writing.
Still, I'm seeking alternatives. There can't only be one way to do this, surely.
It doesn't have to be JSON, but it'd be nice. Binary would be fine.
It seems to me you do not need to subclass NSIncrementalStore. You can create records and save them to your store with a plain vanilla store created via addPersistentStoreWithType:... with a NSPersistentStoreCoordinator.
The straight-forward way is to handle the incoming JSON by simply taking the data and copying it to the properties of your NSManagedObject subclasses, like this:
object.title = jsonDictionary[#"title"];
object.numericAttribute = [jsonDictionary[#"numericAttribute] integerValue];
If you take care about naming the attribute and entity names exactly the same you can maybe use some shortcuts using KVC, like
[object setValue:jsonDictionary[key] forKey:key];
I once did the above for a large legacy project where it was not feasible to repeat the old attribute names, so I used a custom property list (plist) to match around 800 attribute names.
When using core data + table views in combination with SearchDisplayController the predicate for the fetchedResultsController is changed such that only the subset of results confirming to the string in the search display are fetched.
The function shouldReloadDisplayForSearchString is called several times when the user types a search string. A common strategy seems to be to simply overwrite the current predicate for the fetched ResultsController with a new one. Apple suggests to invoke deleteCacheWithName when the search predicate is changed.
For me it seems to be a bit brutal to delete the cache every time. Is this the best practice for this case? Are there other strategies, such as instantiating a temporal fetchedResultsController for the search?
Thanks for Help!
I think that, as you said, it is a bit brutal and you'd better using a different request for search controller. I, for example, don't use a fetched results controller for search controller but a request to an array. While my fetched results controller is not modified.