EVE Technology Lab

Ok, so I have changed structure of the AssetList class slightly. I won't normally make changes to the public API, but I don't think many are using it yet and the change does make quite a few things a lot easier.

response.Result.Assets is now response.Result.Items, and everything is Item objects now, with a LocationId of 0 unless it's a top level object. Also all contained items are in a list called Items.

I've also made a few other updates and fixes that doesn't change the public API, so if you want to download the newest version you should, before implementing too much using the old asset structure.

I can write you a way to flatten the assets as well if you want ?

I see, that is indeed much simpler. Anyways, I'll implement a flatten function as I imagine that could be useful for others as well. The previous change to the structure is on git, and I'll have the flatten function ready in a bit.

Cool, will have a play!

Do I just download the 1.2 zip file again? never understood git :-)

Don't use the zip under releases, they are very old. If you go to the main page of the repo, you can click Download ZIP on the right side, that will give you the newest version. It would make it a lot simpler if you used a git client though, as you could automatically get the newest versions and such. But that's up to you.

The library does not automatically segment requests. For evecentral requests you pass in an EveCentralOptions object, which has a List of itemIDs. If you want to segment, you add x amount of IDs to the lis and make a request. Clear the list and add the next X ids, repeat.

edt:
I added a new release zip that you can use too.

Another few updates. I've cleaned up the separation between http requests, deserialization and caching. It should be very easy to add your own cache implementation if you want to cache using eg. a database.

I'm also currently working on providing a range of methods for retrieving some basic of the data from the static database export. This is also done through http requests though, and is not meant for heavy usage. If you need to perform complex or many queries you should use a local database.

This is however a very lightweight alternative if you only need to request some basic data every now and again. I only just implemented GetInvTypes and GetInvType as a test, more should be coming shortly.

Hey man,

Awesome to see all the work you have been doing on this library. I have added it to the Wiki list of EVE API libraries here: https://wiki.eveonline.com/en/wiki/EVE_API_Libraries

You probably wont want to do it until you are done your v2 of the library but consider also adding a basic example of it's usage here: https://wiki.eveonline.com/en/wiki/EVE_API_Getting_Started

Since you are also about the only one doing .NET stuff it would be great to see a raw .NET example there as well. :D

Funny you'd ask about the library changes, I've been contemplating this exact issue for the past few hours. By convention the new methods have to be named using an "Async" postfix. So the question is whether I should remove the old synchronous methods or not. And if I keep them, do I just wrap the async methods and block, or do I keep a separate fully sync implementation.

From a maintenance and clarity perspective, removing the synchronous methods would be much easier. If someone really wants to avoid using async, they can still use SomeMethodAsync().Result with the implications that causes.

I really can't seem to decide how to do it. If anyone has any input, that would be greatly appreciated.

About the code contracts, MS recommends using the non-generic version of Requires unless backward compatibility with old DataContracts versions force you use the generic one. I have to admit I haven't used CodeContracts much, and I've been considering removing it all together but haven't had the time to look into it further. The non-generic one does however also throw an Exception if the contract is violated, just not a user specified one.

To be honest, multithreading is the way most applications run these days.
Due to the Await-Async implementation it has made the usage of multithreading alot easier. I hardly use non-async methods these days.

However I understand some people refraining from the multithreading. Personally I would go with the "Async" postfix with the non-async methods being blocked versions of the async ones. It allows for easier debugging & testing since you're basically testing the same in 2 seperate "methods".

I feel a user of a library is still responsable for how he/she handles the return of the methods exposed inside it. If the user feels like using the non-Async methods, the user should know the implications. Same for the async methods.

About the Code Contracts, thanks for the information. I never used Contracts before mostly due to never hearing about it till now. If you go about removing it, would you go back to the normal if-else clauses or search for different solution?

I've updated all modules, except EveOnline.Image, to include Async versions of all methods. What is available on the master now will be the final API for version 2.0, bar minor bugs that might have passed the unit tests.

I might add support for progress reporting and task cancellation, but in a way that doesn't affect the current api.

I would greatly appreciate any feedback or help with debugging the async methods, as well as the regular ones.

Also, keep in mind that async does not mean that the library is automagically multithreaded. Some methods may still be CPU bound during deserialization. However, the library shouldn't block on any IO operations (disk access, web requests) if you use the async api.

It seems I was a bit too quick on the trigger regarding the final API. I need to figure out how to deal with the lazy loading of properties in CharacterKey and CorporationKey.

My current options are:
1. Provide a separate method, InitAsync(), which loads all properties in async fashion. Accessing any properties for the first time without first calling InitAsync(), will load the properties synchronously.

2. Provide properties which lazy loads synchronously (as it is currently), and a separate method named GetSomePropertyAsync(), which provides the async behaviour. I don't like the fact that I'll have to mix properties and methods for accessing the same fields though.

3. Provide properties named SomePropertyAsync, which lazy loads asynchronously. This might be the most elegant solution, but it also seems to go against many conventions for properties, and isn't directly supported so I'd have to use some dirty code.

4. Remove all properties, and only provide methods, like GetSomeProperty() and GetSomePropertyAsync(). This will make the API more consistent than mixing properties for sync and methods for async operations, but will break backwards compatibility for this part of the api.

Any input would be welcome