refactor: Convert from Gson to Moshi #428
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Moshi is faster to decode JSON at runtime, is actively maintained, has a smaller memory and method footprint, and a slightly smaller APK size. Moshi also correctly creates default constructor arguments instead of leaving them null, which was a source of `NullPointerExceptions` when using Gson. The conversion broadly consisted of: - Adding `@JsonClass(generateAdapter = true)` to data classes that marshall to/from JSON. - Replacing `@SerializedName(value = ...)` with `@Json(name = ...)`. - Replacing Gson instances with Moshi in Retrofit, Hilt, and tests. - Using Moshi adapters to marshall to/from JSON instead of Gson `toJson` / `fromJson`. - Deleting `Rfc3339DateJsonAdapter` and related code, and using the equivalent adapter bundled with Moshi. - Rewriting `GuardedBooleanAdapter` as a more generic `GuardedAdapter`. - Deleting unused ProGuard rules; Moshi generates adapters using code generation, not runtime reflection. The conversion surfaced some bugs which have been fixed. - Not all audio attachments have attachment size metadata. Don't show the attachment preview if the metadata is missing. - Some `throwable` were not being logged correctly. - The wrong type was being used when parsing the response when sending a scheduled status. - Exceptions other than `HttpException` or `IoException` would also cause a status to be resent. If there's a JSON error parsing a response the status would be repeatedly sent. - In tests strings containing error responses were not valid JSON. - Workaround Mastodon a bug and ensure `filter.keywords` is populated, mastodon/mastodon#29142
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Moshi is faster to decode JSON at runtime, is actively maintained, has a smaller memory and method footprint, and a slightly smaller APK size. Moshi also correctly creates default constructor arguments instead of leaving them null, which was a source of
NullPointerExceptionswhen using Gson.The conversion broadly consisted of:
Adding
@JsonClass(generateAdapter = true)to data classes that marshall to/from JSON.Replacing
@SerializedName(value = ...)with@Json(name = ...).Replacing Gson instances with Moshi in Retrofit, Hilt, and tests.
Using Moshi adapters to marshall to/from JSON instead of Gson
toJson/fromJson.Deleting
Rfc3339DateJsonAdapterand related code, and using the equivalent adapter bundled with Moshi.Rewriting
GuardedBooleanAdapteras a more genericGuardedAdapter.Deleting unused ProGuard rules; Moshi generates adapters using code generation, not runtime reflection.
The conversion surfaced some bugs which have been fixed.
Not all audio attachments have attachment size metadata. Don't show the attachment preview if the metadata is missing.
Some
throwablewere not being logged correctly.The wrong type was being used when parsing the response when sending a scheduled status.
Exceptions other than
HttpExceptionorIoExceptionwould also cause a status to be resent. If there's a JSON error parsing a response the status would be repeatedly sent.In tests strings containing error responses were not valid JSON.
Workaround Mastodon a bug and ensure
filter.keywordsis populated,FilterResult.filter.keywordsnot populated when included in a status'filteredproperty mastodon/mastodon#29142