I am experimenting with Parse for creating the backend for my application and I need to support localized data.
I can't be the first one that tries to do that, but I am unable to find anything about it. I was thinking of keeping the data like this:
// Post class
{
"title": {
"en": "Good morning!",
"de": "Guten Tag!"
},
// Other properties
}
But then the queries would need to be targeted specifically against a localization on the client side since you can't query the title property directly. So I need to do some client side magic first. Does it seem like a bad way to do it? Have this been solved better?
It depends what the data is and how it's being added / updated. I wouldn't use a dictionary with multiple keys like that, I'd either use different objects with a language column so I could query for just the language I want or I'd have multiple language specific columns so I could include only what I want. The former is easier to manage and likely more efficient in the long run.
Related
I have a problem where I need to select a specific value from a specific entity from a entity set, however, I need to do it in a way without knowing the key.
This is the query I actually need:
odata/..../picklistLabels(locale='en_GB',optionId=10819)/label
However I need to program it in a way so it automatically selects the label without knowing the optionId. Is there a way to do this in OData?
From your question, I think that you want to perform a navigation but you don't have a key. Unfortunately, this exact functionality isn't available, however, you can perform an expand like this:
odata/..../picklistLabels?$filter=locale eq 'en_GB' and optionId=10819&$expand=label
This will get you the same information that the other call would do but in a slightly different format, you would have to find the first element in the array and then get the label property to get that information
As an aside, if you have the option to change the server (I'm guessing not due to the sapui5 tag but it might be useful for other users) you could change the key. If the locale and the optionId are enough to identify the object, then you could make these into a composite key. Here is a link for an example within the WebAPI OData source code: https://github.com/OData/ODataSamples/tree/master/WebApi/v4/ODataCompositeKeySample
I'm working on visualizing several geojson files with a large set of properties. I would like to use json-ld to add some meaning to some of these properties. I don't have a lot experience with JSON-LD, but sucessfully applied the jsonld.js to expand, compact, etc. my geojson file and #context. In doing so I noticed that the end results only returns the graph that is actually described in the context. I can understand that, but since it only represents a small part of all my properties, I have some difficulty using the results.
It would help me if I could somehow merge the results of the jsonld operation with the original geojseon file. eg:
"properties": {
"<http://purl.org/dc/terms/title>": "My Title",
"<http://purl.org/dc/terms/type>": "<http://example.com/mytype>",
"NonJSONLDPropertyKey" : "NonJSONLDPropertyValue",
etc.
I would still be able to recognize the properties with an URI, but could also work with the non-json-ld properties. Any suggestions how this might work? Or is there a better approach?
You could map all other properties to blank nodes... that is identifiers that are scoped to the document. The simplest way to do so is to add a
"#vocab": "_:"
declaration to your context.
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.
I'm working to import and export data into Core Data from a web API.
The web API that i'm interfacing with doesn't have consistent naming with itself, and certainly doesn't match the naming conventions that i'd use for attributes in my core data model. (I don't have control over changing the API conventions).
To illustrate the issue, in one api call the data for a contact might look something like this :
"rows": [
{
"name": "Bob",
"group": "Testing Group A",
"email_address" : "bob#fakedata.com"
}
]
And in another different call that still returns contacts it might look something like this :
"rows": [
{
"Name": "Bob",
"group_name": "Testing Group A",
"Email" : "bob#fakedata.com"
}
]
Notice the small differences in the key naming? In the past, i've resolved issues like this by having a "mapping" for each API call. The mapping is just an NSDictionary that has the key's of the core data names I use, and the values of the API server keys.
So resolving each of these two calls would require each to have an NSDictionary like the following
dict = #{ #"name" : #"name", #"group" : #"group", #"email" : #"email_address" };
dict = #{ #"name" : #"Name", #"group" : #"group_name", #"email" : #"Email" };
This works pretty well, and it's certainly one path to solve this problem, but having these mappings in every API call isn't very elegant, and certainly is poor design for code maintainability.
So the real question here is : does anyone have a better solution for managing the mapping of web api's to Core Data? Obviously having a well written web API is the ideal solution, but even mapping well written API's can have minor differences (For example, core data requires attributes to begin with a lowercase letter).
My proposed solution is to add the mappings into the core data attribute under the "User Info" (attached image below to see example), but i have zero experience using this feature of attributes, and I don't know if there is a way better option that i've overlooked. Thanks for any help.
Additional Notes : Yes, i've used Restkit extensively, and it does have convenient mappings (similar to how I've explained using an NSDictionary above). But for this project, i'm eliminating dependency on such a framework that I don't have control over, and don't completely understand. I'm pulling this data in with a simple NSURLConnection.
update
If you go down this route (which has been very nice btw, the accepted answer helped a lot). I recommend not using the key word "map" simply because it's not the default. Use "key" instead because this doesn't require making two edits to the user info field. For my particular project there are many mappings and this has been annoying. Too late to change now, but learn from my mistake.
Wow, that is one screwed up web API.
Your suggested approach is more or less how I'd deal with it. But instead of having multiple mapX keys, I'd use a single map key whose value was a comma-separated list of mappings. In this case, the key map would have a value of Company,Company_Name,company. That way you read one known key instead of repeatedly testing to see if the next one exists. You can easily convert the comma-delimited list to an array by using NSString's componentsSeparatedByString: method.
A different approach would be to put all this in a property list that you can read at run time. That would be effective but I prefer keeping all of the information in one place, and the user info dictionary is ideal.
As an aside, for what it's worth, Core Data does not require that attribute names begin with a lower case letter. However, Xcode's data model editor does enforce that restriction-- forcing you to follow a guideline that you might well have cause to violate. If you're so inclined, you can edit the model file by hand and change attribute names to start with upper case letters. The file is XML, and if the tool compatibility setting is Xcode 4.0 or higher it's very easy to read. Once you do this you can even use Xcode's built-in class generation with those attributes.
I hope this isn't too vague, but I'm stuck on a problem that has put me in an Unfortunate Position.
I'm Flash developer getting my feet wet with with AS3 and am trying to build an interior decoration tool for a client. My thinking so far has been: create the basic user interface, get the screen flow down, and then finally use a couple of simple arrays to store user selections and stuff like that.
Naturally my 'couple of simple arrays' is totally inadequate to model the many user decisions that my program has to take into account. So I find myself trying to create an enormous, multi-dimensional array with several layers of nesting and before Panic sets in.
Here's an example of my thinking for the 'bedding' component of the application in pseudo ActionScript:
bedding['size'] = 'king':String
bedding['cover'] = cover:Array
cover['type'] = 'coverlet':String
cover['style'] = 'style_one':String
cover['variation'] = 'varation_one':String
cover['fabric'] = fabrics:Array
fabrics[0] = 'paisely':String
fabrics[1] = 'argyle':String
fabrics[2] = 'plaid':String
cover['trim'] = trim:Array
trims[0] = trim_pair:Array
trim_pair['type'] = 'trim_one':String
trim_pair['color'] = 'blue':String
trims[1] = trim_pair:String
trims[2] = trim_pair:String
cover['embellishments'] = embellishment_pair:Array
embellishment_pair['type'] = 'monogram':String
embellishment_pair['letters'] = 'TL':String
... keep in mind that this is just a fraction of what goes into bedding and there are several other of these kinds of arrays that would go into a room like flooring and walls and funture... all equally complex. And I'll need to frequently access different combinations like, how many options under bedding have no value associated and things like that.
So, I realize I'm out of my league and am going to get hurt on this, but I'd like to try to get this right so that I get better and any help you guys can provide is great.
My questions are:
1) Could it be that using nested arrays like this actually isn't such a bad thing and I should just stick it out? That would suprise me, but I want to make sure I'm not already on the right path.
2) If not, where do I go from here if I want to do this right?
Off the top of my head I feel like I could maybe make everything class based. So my sheets are a class and beds have instances of sheets and rooms have instances of beds... etc. It think it would be complicated but might be the way to go.
Or maybe, I go the XML route and store all of the room options in nested blank XML nodes that a user then populates as they move through the application.
These are my thoughts but I'd like to hear what more experienced members of the community say.
Thank you so much for your help!
My suggestion would be to use a strongly typed model. Look into using collections and value objects to store and retrieve data. A collection could be a class that wraps an Array and provides a clean interface for fetching the value objects that it stores. Value objects are simple objects representing data that can be assembled in various ways to create more complex collections. Value objects can also be passed around to transfer data to various parts of an application. The advantage to using collections and value objects is that your code will be ( potentially ) more explicit and over-all easier to read than if you went with a dynamic approach. For some, the downside to this approach is that you end up with too many classes. Personally, I prefer working with many small to medium size classes versus one monolithic class.
If you are not familiar with the concept of value objects: http://en.wikipedia.org/wiki/Data_transfer_object.
AFAIK, AS3 is not well suited to the type of complex data model you're trying to create.
You need to completely decouple the UI/Flash tier from your "inventory" system. The UI should be completely abstract, with no knowledge of, or coupling to, your data schema or content. This could be accomplished with a middle-tier webservice-styled system that handles all the business logic around searching/retrieving/updating your data.
Store everything your UI needs to handle presentation-side rendering in your product metadata. This will allow you to add new products and types without having to update the UI every time new products are introduced. For example, if a product comes with an image, store a URI to the image with the product record and load it on demand. You could extend this all the way to custom animations, I believe- just reference an outside .SWF file and load it into your application on request.