NOTE: This was written about a year before posting.
I've spoken highly of the project Refit and that it's a nice port of Retrofit. I still stand by this; but... I'm wondering; do I need it?
I'm getting HttpResponseMessage back. There's the loss of auto-conversion that is available if I'm using dumb objects, like data bags.
public interface IHackerNewsApi
{
[Get("/topstories.json")]
Task<HttpResponseMessage> TopStories();
[Get("/item/{itemId}.json")]
Task<HttpResponseMessage> Item(string itemId);
}
I have this issue a little in the Android project as well, using Retrofit. It allows the adapters; which I've kinda foisted in ontop of Refit.
Which, if I can refer to it as "foisting"... is it worth having?
This post is to figure that out.
It would be awesome if my unit tests would run... but they seem to think differently.
I thought I fixed all of the async void to async Tasks earlier... oh well.
The goal is to not change behavior; obviously.
Now I'm fighting my tools... VS 2017 is not running the tests; let's dust off VS 2015; and see what it does...
Still nothing...
Finally... 2017 preview... works there. Only took me 4 hours to find that.
Anyway - It runs the tests. Now... Now I can go see how "not refit" looks.
Looking at my Response object; I'm allowing the StatusCode to leak out... That's gonna have to be stopped.
The object should be able to be queried about the error, not returning it. I don't know that behavior yet, so... Nothing! Or because I'm lazy it'll stay for now. Need examples.
There's 4 failing tests... Not sure why... Bad past me.
Looks like a merge didn't go right. hehe, and it's just me...
Small refactor I see I need is that the internal adapters don't return NullObjects if they can't parse the json correctly. That's being fixed.
Playing a little with using a raw HttpClient and ... I'll have to build what Refit is, essentially; but more code.
So... woo?
Guess that was pretty easy for me to see.
Super short post; refit stays!