Skip to content

Re-designing the API library #2

@Twinklebear

Description

@Twinklebear

The API library is a bit of a mess to work with due to a bunch of different packages each defining their own versions of the same classes. It looks like this was done so that GSON could be used, which requires that the class exactly matches the JSON response, but because the site api is kind of inconsistent about what information it gives us where this results in the library being as inconsistent as the site.

For example there are quite a few versions of the Torrent class: 1, 2, 3, 4, 5 and one class named Result that shares a lot with Torrent 6. This happens a lot throughout the library.

Because of the awkwardness of dealing with GSON I've been looking into using Jackson for parsing the JSON ourselves, where now we'd need to handle the inconsistencies ourselves perhaps by doing a full load of the object when wanting to access a missing data field or something.

Also it sounds like the Apache HTTP client we're using at the moment is being phased out from reading this post and that we should move to HttpURLConnection, however using HttpURLConnection isn't recommended on 2.2 and lower due to bugs, which would mean that the user mentioned in this bug wouldn't be able to use the app. We could have an older phone build, stick with Apache or just decide to not support 2.2 and lower (if we're even able to with Apache).

Anyways this would definitely be a lot of work but I think we could improve the app as well if we had a simpler/cleaner library to work with. Let me know what you think folks.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions