So for a project I am doing for school, we need to decode some model objects using objective-c and others using swift.
I am trying to decode the json as an array of multiple sol detail objects. It is able to decode the name and total_photos keys, but when it gets to the photos: dictionary it crashes and is unable to decode. Any guidance towards a solution with this would be much appreciated.
I have figured out what I needed to do, so basically I needed to decode each dictionary individually, different from swift where you can use codable to decode a nested json array, in objective c apparently you have to decode them individually.
Related
Is it possible to lookup elements by key with the object API just like it's possible in the non-object API with the "LookUpByKey" method?
I can't find any method that seems to do that.
Am I supposed to implement a binary search by myself on the vector?
Is the vector assumed to be already sorted?
I think you need to use mini-reflection or full reflection for this task.
You can read more about reflection in the docs or see an example where it's used in their testing code.
Here's a nice tutorial by jorenjoestar from someone using reflection that I found helpful myself.
Also the vectors are not assumed to be sorted but you can pre-sort a vector and set the flatbuffer contents to that sorted vector.
I need to convert json to objective-c object. I mean not parse it in code, but generate the code of the object by some json. Are there some tools for it? I know how to do it in java(jsonpojo).
Also i wonder if there is a certain way to automatically store data from json to a real objective-c Object without manual parsing.
In Java its done by Gson library.
It looks like you are describing exactly what ROAD iOS Framework. Take a look: https://github.com/epam/road-ios-framework
The tool for generating plain model classes from JSON is ROADClassesGenerator and if you will use ROAD for networking then serialization into generated classes comes for free.
One note, it's not actively supported now, due to pervasiveness of Swift and the fact if its tight reliance on macros which are still poorly supported in Swift, but it's still work and do the job nevertheless.
I've got a bunch of managed objects that i'm fetching from a managed object context. These object have a imageFilePath attribute, which is just a path to an image data object ive saved to a directory on the phone. My question is this - what is the best way to batch convert all these data objects into an array of photos?
I'm considering just iterating thru the array of the managed objects, but that seems somewhat inefficient. I could also perhaps create a separate entity from this attribute in my model, and grab them directly.
Is there a way i could apply a block to each result of my fetch as it comes in?
thanks!
If you're worried about the Core Data side of things, take a look at the fetchBatchSize you can set on NSFetchRequest. You'll have to experiment a bit to see what size will work best for you, but something like 25 is a good starting point. That way Core Data will not fetch all objects from disk at once, but fault them in 25 at a time. You still see a normal NSArray and Core Data does all the magic in the background.
I am building a very simple app to store data on people like name, age, etc. I give the user the option of changing the data such as when a person has a birthday. I can't figure out the best way to store the data.
I have searched for a long time now and I can't find the simple answer that I am looking for. If I change the data in a mutable array will that data be changed permanently? I mean will that write over the existing code and change the data so that it will still exist when the app is closed and reloaded again?
So far I am not able to do that. I have experience in MySql and Sql server so I have a tendency to go that direction if possible, but I would really like to use a mutable array or mutable dictionary if possible. This may be such an elementary question, but I can't find an answer anywhere.
You have some misconceptions.
The objects you create are in memory. There's nothing permanent about them. You have to save them somehow or they are gone when you quit the application and come back.
If you want to save an array, you have a number of options.
If the array contains nothing but objects of type NSString, NSData, NSDate, NSNumber, NSArray, or NSDictionary, you can save the array using the system class NSUserDefaults.
NSArray also has a method writeToFile:atomically: that will save an array of data to a file.
If your array contains any objects other than the types I listed above, though, neither of those approaches (NSUserDefaults or writeToFile:atomically) won't work.
The other option is to use an NSKeyedArchiver to convert the contents of your array to data, and then write that data to a file. In order for that approach to work, every single object i your array, and all the objects in those objects, need to support the NSCoding protocol.
As others have pointed out, you could also use Core Data or mySQL to save your data, but that seems like overkill for just saving an array.
Take a look at Core Data. It is the easiest way to manage this kind of data storage requirement on iOS.
Take a look at my book, it got good reviews and is perfect for what you are trying to do: http://www.amazon.com/Pro-Core-Data-iOS-Professionals/dp/1430233559
If you want an easy way to get started, there are tons of online tutorials too. For example Ray has written some good stuff:
http://www.raywenderlich.com/934/core-data-on-ios-5-tutorial-getting-started
Mutable means you can change the data at any time, so no, it's not permanent.
Yes, it will be permanent in terms of what you are asking. Although because the array is mutable it means you can always change the data back, the initial data will be overwritten by this new data.
Edit: No, the information will not remain after closing the app. You will need to programmatically save it. I would use Core Data.
CoreData is the way data is normally persisted in Cocoa and Cocoa-Touch. It also gives you some nice extras like undo support. But it has a big learning curve.
If what you're doing is super-simple, look at NSUserDefaults. If you need a little more flexibility, you could always use NSArray's -writeToFile:atomically: and -initWithContentsOfFile: (there are also versions of both those methods that take URLs instead of file paths).
Anything more complicated than that, and it's probably worth the trouble learning CoreData.
I have a large MKOverlay that I would like to be saved in Core Data so that I don't have to create it later. Since this isn't one of the types that you can choose in Core Data, how do I go about saving it?
Do I need to somehow encode it first?
Do I then need to decode it when using?
What kind of object do I select in core data when creating a new property?
Thanks guys.
If you do not need to query for different overlays and you're not using core data elsewhere in your project, then you're probably better off caching the overlay on disk as an encoded NSArray.
However, if you're already using Core Data or you're caching multiple overlays then you can encode/decode the overlay in a field of type NSData. Add additional fields to the entity so you can query for the specific overlay you're looking for.
In iOS 5, you can enable optional storage of NSData fields in an external file by selecting the "Allows External Storage" option. Core Data will apply a size-based heuristic to determine if a blob or external file will result in better performance.
MKOverlay conforms to NSCoding, so you can encode and decode an entire array of MKOverlay objects using an encode method of NSKeyedArchiver and store the result in a binary field in your entity. You'll likely want + (NSData *)archivedDataWithRootObject:(id)rootObject on NSKeyedArchiver and + (id)unarchiveObjectWithData:(NSData *)data on NSKeyedUnarchiver
See the Archives section in the Archives and Serializations Programming guide for details of creating a keyed archive at: http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Archiving/Articles/archives.html
You can write a custom accessor for the entity's binary field that encodes and decodes the overlay array for you. Another option is to create a value transformer that encapsulates the encoding and decoding operations. The end result would be an overlays array property that you can set and read via entity.overlays.
I believe you can use Apple's NSCoding libraries to convert the object to and from a serialized state. However, Core Data may support saving objects, but NSCoding lets you save any class that implements it anywhere, including a string sent to a server, a file written to disk, or if you're as bad a programmer as me, an NSUserDefaults entry.
edit- You may have to implement NSCoding into your own class based on MKOverlay by adding read and write methods, I'm uncertain.
Why not instead save the properties (size, color, coordinates, etc can all be described with NSNumbers and those can be stored in Core Data natively) and recreate the MKOverlay when needed. I think that's a much more efficient approach to be honest. I'm not sure how much of an impact creating an object has, so prove me wrong if I'm wrong.
You need to take the large dataset that composes the overlay and turn those individual data nodes into NSManagedObjects to be stored in CoreData.
I mean, you probably COULD just NSCoder the entire thing into one giant datablob, but at that point, you might as well just write the thing to a flat file (which frankly might be better if all you want to do is read/write it without changing it).
Don't use Core Data unless you're going to be doing legit querying or piecemeal changes to the dataset.