Guild Wars 2

Hey guys,

I’m a beginner in programming C#/.NET. I’m currently working on a library that makes the GW2-API usable in a .NET environment.
My objective is not to publish it (neither it gets finished anytime in the future). It is just some kind of training and should help me to improve my skills.

At the Moment I’m trying to deserialize the “event_details.json”-data. I actually got that working but, if I strictly follow the structure of the json-data, I have to create one type member in C# per ingame event in the container type. Since there are 1667 different events in GW2, that seems a bit inconvenient to me.

If that was another array just like in “events.json”, with the event_id as a type member of the event type, I could map this to a List<> too. But all events seem to be a distinct member of the container, although they all have the same members.

Does anyone have an idea how to deserialize “event_details.json” without the need to create a container-type member for every event?
AFAIK there is no possibility in C# to dynamically name variables at runtime.

Thanks in advance!

Thank you very much guys.

I’ve found a solution. I just switched from DataContractJsonSerializer to JSON.NET:
http://james.newtonking.com/pages/json-net.aspx

That works with Dictionary<string, EventDetails> as well as with Dictionary<Guid, EventDetails> and is very comfortable to use.

Although it works now, you awakened that fire in my mind that challenges me to work on my knowledge about serialization/deserialization and to implement an own JSON serializer/deserializer in the future. Probably during my studies in computer science, which begins in October :-)

Instead of a List, you use a Dictionary, where the ID of the event is the key in the dictionary. If you can deserialize events.json into a list, you shouldn’t have much trouble changing it to a dictionary.

There was a .NET project being worked on, so you may be able to use it as an example.
https://forum-en.gw2archive.eu/forum/community/api/NET-Implementation/
https://gw2dotnet.codeplex.com/

For a RestSharp basic example,

Thanks for your reply.

I already tried this out too. But it doesn’t work so far.
(I’m using DataContractJsonSerializer.)

What errors do you get? (I’m using 4.0 instead of kitten I can’t use the DataContractJsonSerializer).

And watch that you make a Dictionary<string, EventDetails> instead of a Dictionary<Guid, EventDetails>

Well if you are talking of JSON deserialization in general you should keep the structure of the JSON you are trying to parse. So make sure you are familiar with the JSON specification. A simple way to parse JSON-Data is to use structs and unions by combining them cleverly within an array(this is like you would do it in C and it should work the same in C#). To improve the lookup speed for e.g the events_json (i suppose you don’t want to iterate through the array all the time) you should create a hash-function which organizes the events.
This is also possible with C++ Containers in combination with either classes or the above mentioned structs/unions.

@LadyRhonwyn
I tried out that Dictionary<string, EventDetails>, but it doesn’t work too. Maybe I’m doing something wrong. My C# types in attachments.

To avoid confusion: I know that there are not all members present yet, but thats not the problem as it works if every event is a type member of the container type (not shown here, it would just replace the dictionary) named with the event id.

I didn’t get any exception. The objects just weren’t created so the method just returned a null reference.

@Heimdall
I guess I DO keep the structure by the approach to represent every event by a member of the container type. As I mentioned, the problem is that there is no json array in event_details.json. Have a look at the attachments.

An array would be indicated by []-brackets.

What do you mean by " use structs and unions by combining them cleverly within an array"?

I simply deserialize arrays and objects into Dictionary collections. I use Int32 as the key type for arrays, and String as the key type for objects. This seems to work fine.

I don’t bother to make custom types for every kind of object — I just treat them all as Dictionary<String, Object>. yes, compile-time “type safety” would be enhanced by defining a specific type for every JSON object, but sometimes that’s simply too much work for too little benefit.

My code isn’t actually quite as simple as what I’ve described (I do implement some type-checking to provide run-time type safety) but essentially the underlying structure and the access behavior are pretty similar to what you would get from a Dictionary of Objects. I’ve previously posted my C# JSON deserializer in another thread if you want to look at it:
https://forum-en.gw2archive.eu/forum/community/api/Simple-C-Example-Rating-Calculation

-ken

Well I mean something like this. If you want to see a working example in C or C++ visit my codeplex repo.

incidentally, ‘structs and unions’ is essentially what I do in my parser. except instead of unions, I use the System.Object type instead.

-ken

Well the benefit of unions is that you can save memory space. And to make the whole thing more efficient you should organize the memory by yourself (…not really necessary in C# I know), and don’t forget the hash-function if you consider not to use containers like dictionaries or maps. But how I mentioned before this is the way you would do it in C/C++. In C# this should be a lot easier.

unions can definitely save space in C/C++, compared to not using them.

but C# doesn’t have unions in the C/C++ sense. you can simulate them using structs tagged with the ‘Explicit’ layout modifier, but there are a number of disadvantages with this method (you need to organize the memory yourself, you can’t embed arrays in structs, redundant field initialization is needed to make the compiler happy, etc.).

System.Object is really the closest thing, and it lets you do everything a discriminated union can do but in a type-safe (at runtime) way. the only potential memory cost over a C/C++ style union is the amount of space needed to ‘box’ a value type and store a pointer to it. and if your union includes only reference types then there will be no extra memory usage at all (although in C/C++ you would typically just use “void *” in that case, rather than a union).

-ken

Don’t be tempted to just leave it at a Dictionary of strings and objects.

It may seem like a lot of work to create custom objects for the things you’re deserializing, but JSON.NET makes it trivial to work with them once you have them. Further, the type checking and or converting you end up doing for anything even remotely non trivial will start to add up if you have to constantly work with only strings and base objects.

Further, it’s a good habit to not be lazy, especially if you’re going to be going into computer science and programming as a career choice. It makes your intent much clearer, and gives you a lot more options in the future.

You’re on the right track =)

I don’t want to get too far off-topic, but I should point out that this is one of the differences between computer science and computer engineering.

Computer science best practices assume that you will have all the programmer time you need for initial development and ongoing maintenance. “Best practices” are always best, and if you don’t have time to follow them then clearly you’re not doing things the best way. I can’t argue against this.

But as a computer engineer, my focus is slightly different — computer engineering is essentially the intersection of computer science and economics. There will be times where the benefits of a feature will be worth the cost, and there will be times when it’s not. Where you draw the line depends on your particular conditions and budget.

I’m confident you’ve heard the saying “anything worth doing is worth doing right”. The corollary to that rule is “if you don’t have time to do it right, don’t do it at all”. In computer engineering, you implement this corollary by leaving unnecessary features out. Identifying which features are “unnecessary” is an exercise left to the reader.

-ken