Join Two Objects for Custom Serialization? - linq

In C# on Framework 4, I have a List and List. They can be joined on the JoinId property. ParentObj will have 2 ChildObj matches, sometimes 10.
I would like to take each Parent and all Children and serialize to a single XML entity. I am having a hard time figuring out where to start, because I also need to serialize the objects in a custom way. Can I use Linq-to-XML in this case to get each object written correctly? XmlSerializer? Not sure.
Thanks.

Can I use Linq-to-XML in this case to get each object written correctly?
Yes. This is exactly what you need. A basic example.
XmlSerializer?
This will work too, but this approach is older and I think it is less appropriate and more complicated in this case.

Related

Why do I sometimes get embedded attributes and sometime not?

I'm using parse-platform with React-Redux and thunk.
If I make a query for objects which have pointers as attributes, sometimes I get the embedded attributes of the pointer and sometime I don't, is this normal behaviour? It means having to make lots more queries for the pointer attributes as you can't be confident they will be in the original results.
As you state correctly sometimes Parse fetches the pointers of an object and sometimes it doesn't.
In order to ensure that the query will bring the pointers of the object alongside all its attributes its a good idea to use the include method as query.include('pointerAttribute').
In order to ensure that only some attributes will be fetched and the rest won't, then it is a good idea to use the select method query.select('attribute1toselect', 'attribute2toselect').
Using select is much better if not going to use all the attributes as the payload's weight in the response will decrease and the frontend will have to deal with less data.

What is the name of the design pattern to avoid chained field access?

There is a pattern or term that is used to avoid codes like
myObject.fieldA.fieldB.fieldC
something like this. I forgot what this term is called. Can anyone let me know about it?
It violates the Law of Demeter, which states that code should only access its own local variables, parameters, and instance members.
It could be a case of of feature envy, where a class calls a lot of getters or accesses a lot of data from another class.
If these are really fields, they are poorly encapsulated (i.e., not behind a function), and any change to these fields forces you to modify all code that's using them.
Testing such code becomes hard, as you will have to mock not only fieldA, but also that's fieldB, and in turn that's fieldC.
I think you are trying to create a new object and add certain properties to that object. If that is the case then it's Builder design patten where you seperate the construction and representation.
If you are trying to call a certain field with the above shown code then your design is very poor. An object should store only it's own properties.

Managing an Ordered Core Data Relationship Using NSArrayController

All those “NSOrderedSet was added later and thus doesn’t have to play nice with other components” bugs drive me crazy…
(https://twitter.com/kubanekl/status/413447039855640576)
I have two managed objects and an ordered 1:N relationship between them, which is backed by an instance (or more precise a subclass) of NSOrderedSet. I want to manage this relationship using a NSArrayController in order to profit from features it offers (selection management, binding of the content, bindings to views like NSTableView).
Since NSOrderedSet is not a subclass of NSSet, the contentSet binding of NSArrayController doesn't work with that relationship. I found following thread and tried to implement the suggestions mentioned there.
The first suggestion is to use the contentArray binding and a value transformer for transforming the ordered set to an array on the fly. The problem with this solution is the reassigning of the content each time a change is made, which is not what I want.
The second suggestion provided in the mentioned thread is to use the contentArray binding and apply the #array operator to the model key path. I've tried that, but the underlying relationship was not touched at all when adding/removing objects through the NSArrayController.
Another option I found is using sort descriptors with the contentSet binding. This would require making the relation unordered in order to make the contentSet binding work and introducing a new attribute used especially for managing the order. This would furthermore require a custom ordering mechanism to implement and it would mess up the model. Honestly said, I would like to avoid this solution.
My question is pretty clear: Is there any way to manage an ordered Core Data relationship using NSArrayController? If so, which is the best way causing as little pain as possible?
It is indeed very sad that NSArrayController does not come with support for ordered relationships. As a keen observer to the bindings technology I find it sub optimal that it seems that Apple has "abandoned" it without saying anything. The last notable change that Apple introduced with regards to bindings are NSTreeController bug fixes. That was I believe with 10.6/10.7. It seems that Apple does not want to touch the bindings technology anymore. I am not sure why because bindings are really great sometimes. They can be the "90% solution". During prototyping this is fine. I am using bindings where it makes sense and having NSArrayController with ordered relationships support would be something great.
Most of the solutions that have been mentioned already are no real solutions. But this depends. Here is something to think about:
If you are planning to support iCloud then you should not/cannot use ordered relationships anyway because Core Data on iCloud does not support them.
Since ordered relationships are fairly new and the desire for a ordered collection of objects existed long before them, there must be a way in Core Data to mimic ordered relationships. You have already pointed out what 99.9% of the Core Data eating world did before ordered relationships were available: Sort by an additional attribute. You have pointed out that this is messing up the model but I disagree: It is true that you have to add an additional attribute to your model which does not necessarily "represent" true model data. But how many ordered relationships are you planning to have in your model? Usually you don't have that many per application. Even though it feels a bit dirty this is what has been done by lots of people for at least three major releases of Core Data (10.4, 10.5 and 10.6). Even today this solution is used for backwards compatibility or if you want to use iCloud. It is a "pragmatic" solution. Not a nice one but pragmatic. Also please not: Even if you were using ordered relationships the order of your objects has to be stored somewhere. If you are using the SQLite store then having an ordered relationship causes the NSSQLiteStore to create an additional column for you. The column has the name: Z_FOK_$RELATIONSHIPNAME. So by using ordered relationships you are merely doing something that is done for you under the hood anyways. This means that it does not really matter from a pure technical perspective if you are using ordered relationships or an additional attribute. The underlying technical problems remain the same. Ordered relationships are no magic.
If you are planning to go with the "additional attribute" solution be aware that you have to adjust the value of this attribute a lot: Every time the user is changing the ordere via drag and drop you have to modify the value of the attribute. This seems wasteful but it really isn't. Even the worse case: A user who is exchanging the object at row 0 with an object at the last possible row does only cause 2 attribute changes. The complexity of the trivial solution for changes needed to represent any change that can be made by drag and drop in a table view is O(n) where n is the number of selected rows. This is really not that bad since users are usually not reordering 10000000 rows at once and even then there are smarter algorithms out there which are not that hard to implement.
If you are looking the for cleanest solution you should subclass NSArrayController and add a "orderedContentSet" bindings yourself. You can find out how to do that by reading the Cocoa Bindings Programming topic guide. The guide contains an example: https://developer.apple.com/library/mac/documentation/cocoa/conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html (Listing 2). The bad thing about this is that you are subclassing NSArrayController which is usually a no go. Many people tend to subclass NSArrayController for reasons that don't justify subclassing it. In this case however subclassing NSArrayController is justified if you want to go with the cleanest solution.
For 3. there are generic solutions out there which do a lot of the stuff for you. Don't use them.

java customize a hashmap values

I am working on using a real time application in java, I have a data structure that looks like this.
HashMap<Integer, Object> myMap;
now this works really well for storing the data that I need but it kills me on getting data out. The underlying problems that I run into is that if i call
Collection<Object> myObjects = myMap.values();
Iterator<object> it = myObjects.iterator();
while(it.hasNext(){ object o = it.next(); }
I declare the iterator and collection as variable in my class, and assign them each iteration, but iterating over the collection is very slow. This is a real time application so need to iterate at least 25x per second.
Looking at the profiler I see that there is a new instance of the iterator being created every update.
I was thinking of two ways of possibly changing the hashmap to possibly fix my problems.
1. cache the iterator somehow although i'm not sure if that's possible.
2. possibly changing the return type of hashmap.values() to return a list instead of a collection
3. use a different data structure but I don't know what I could use.
If this is still open use Google Guava collections. They have things like multiMap for the structures you are defining. Ok, these might not be an exact replacement, but close:
From the website here: https://code.google.com/p/guava-libraries/wiki/NewCollectionTypesExplained
Every experienced Java programmer has, at one point or another, implemented a Map> or Map>, and dealt with the awkwardness of that structure. For example, Map> is a typical way to represent an unlabeled directed graph. Guava's Multimap framework makes it easy to handle a mapping from keys to multiple values. A Multimap is a general way to associate keys with arbitrarily many values.

Virtualizing Data in Windows Phone 7: An example

In Windows Phone a ListBox support the virtualization of the data, that means it can only load the data needed and not everything. Peter Torr explains the interface you need to implement.
The short version is that you have to create both a method that return the position of an element and another one that return the element in a specific position. The problem is that the example of Peter Torr is rather dumb, he just return an object with the index as a name.
My question is: how do you actually implement this ?
My idea is to create one file that contains a list of an (integer) index and an (integer) id and a file for every object that contains the actual data. It doesn't seem a really elegant idea, but I can't think of anything better, can you ?
UPDATE
It seems that my question is inaccurate. When I say that the example of Peter Torr is "rather dumb" I am not saying that he has done anything wrong; his objective was simply to explain what interface you need to implement. The practical implementation will depend on the specific data.
What I am asking is what choices do I have to implement this ? Should I simply put the data on a web service and query it every time (with a local cache, of course), build a database, create a file the store the indexes and one for the data ? Is there a solution good enough in every case ? What are the downsides and upsides of every choice ?
The article you linked to includes a link to a downloadable project which demonstrates how to implement this.
What more are you after? The general idea is that the ListBox will call into your IList when it needs data. it will ask for an item at a specific index and you pass back an object. it then, presumably, calls ToString() on that object and displays the result in the list.
What that actual object is and where you pull it from is completely up to you. You might be using a really large array in memory. You might be pulling from IsolatedStorage or a web service. You could certainly use it to pull file info, but I don't suspect anyone has a ready-built IList implementation so that's the part that you will have to implement based on your specific project.

Resources