Move Gson serialization into MastodonClient

[bocops]

Originally posted to #5:

Currently, basically every API method looks like this:

    fun getAccount(accountId: Long): MastodonRequest<Account> {
        return MastodonRequest(
            { client.get("api/v1/accounts/$accountId") },
            { client.getSerializer().fromJson(it, Account::class.java) }
        )
    }

with the Gson instance being exposed via MastodonClient.getSerializer(). It is probably cleaner to change this into something like a call to client.getMastodonRequest(...), which would deal with the necessary serialization in our MastodonClient instead.

[bocops]

Here's how the above call might look in practice, using the suggested client.getMastodonRequest(...):

    fun getAccount(accountId: Long): MastodonRequest<Account> {
        return client.getMastodonRequest(
            endpoint = "api/v1/accounts/$accountId",
            method = MastodonClient.Method.GET,
            parameters = null
        )
    }

I think that this is a much cleaner call - with some caveats, though:

1. the new function is a reified inline function, which means that most of the old stuff stays as accessible as before.
2. additional functions are necessary, for example to return Pageable<T> or List<T> instead of the simple <T> returned by getMastodonRequest(...).

Here's an example of the changes necessary to make Account work as before. I think this is still better overall.

@andregasser What do you think? Should I go forward with this?

[andregasser]

I like your approach. I have added one comment to bocops@15d7a44 regarding parameter default value. It is just a minor improvement. Feel free to continue. 👍

[andregasser]

We should make sure we do not expose the getSerializer() method to the library user. But if I got you right, that is already covered in the current approach.

[bocops]

Regarding parameters = null, I initially thought that not having a default value here might make it more obvious if necessary parameters are missing from the call - but I agree, that might not be necessary after all.

Yes, getSerializer() would get an internal modifier in the end.

[bocops]

I've sent PR #73 to deal with most of this, including the changes requested above. As mentioned in the PR, some special cases remain:

• Media.kt
• Streaming.kt
• postUserNameAndPassword() in sample apps

After cleanup of those and related tests, Gson instance no longer needs to be exposed via MastodonClient.getSerializer.

We already have issues opend to rewrite Media.kt (#62) and to redo the sample apps (#68), so it would be best to do this cleanup at the same time. I currently don't know how to deal with Streaming.kt.

[bocops]

Media and Streaming are actually not a problem - they are a part of the same module, so can continue to access an internal getSerializer().

Since postUserNameAndPassword() in sample apps is using undocumented functionality and thus probably is a lost cause anyway, I believe it is better to create a new Gson() instance there so that we can at least close this issue.