**! ! Warning**: Do not merge before testing every API call and database
read involving JSON !
**Gson** is obsolete and has been superseded by **Moshi**. But more
importantly, parsing Kotlin objects using Gson is _dangerous_ because
Gson uses Java serialization and is **not Kotlin-aware**. This has two
main consequences:
- Fields of non-null types may end up null at runtime. Parsing will
succeed, but the code may crash later with a `NullPointerException` when
trying to access a field member;
- Default values of constructor parameters are always ignored. When
absent, reference types will be null, booleans will be false and
integers will be zero.
On the other hand, Kotlin-aware parsers like **Moshi** or **Kotlin
Serialization** will validate at parsing time that all received fields
comply with the Kotlin contract and avoid errors at runtime, making apps
more stable and schema mismatches easier to detect (as long as logs are
accessible):
- Receiving a null value for a non-null type will generate a parsing
error;
- Optional types are declared explicitly by adding a default value. **A
missing value with no default value declaration will generate a parsing
error.**
Migrating the entity declarations from Gson to Moshi will make the code
more robust but is not an easy task because of the semantic differences.
With Gson, both nullable and optional fields are represented with a null
value. After converting to Moshi, some nullable entities can become
non-null with a default value (if they are optional and not nullable),
others can stay nullable with no default value (if they are mandatory
and nullable), and others can become **nullable with a default value of
null** (if they are optional _or_ nullable _or_ both). That third option
is the safest bet when it's not clear if a field is optional or not,
except for lists which can usually be declared as non-null with a
default value of an empty list (I have yet to see a nullable array type
in the Mastodon API).
Fields that are currently declared as non-null present another
challenge. In theory, they should remain as-is and everything will work
fine. In practice, **because Gson is not aware of nullable types at
all**, it's possible that some non-null fields currently hold a null
value in some cases but the app does not report any error because the
field is not accessed by Kotlin code in that scenario. After migrating
to Moshi however, parsing such a field will now fail early if a null
value or no value is received.
These fields will have to be identified by heavily testing the app and
looking for parsing errors (`JsonDataException`) and/or by going through
the Mastodon documentation. A default value needs to be added for
missing optional fields, and their type could optionally be changed to
nullable, depending on the case.
Gson is also currently used to serialize and deserialize objects to and
from the local database, which is also challenging because backwards
compatibility needs to be preserved. Fortunately, by default Gson omits
writing null fields, so a field of type `List<T>?` could be replaced
with a field of type `List<T>` with a default value of `emptyList()` and
reading back the old data should still work. However, nullable lists
that are written directly (not as a field of another object) will still
be serialized to JSON as `"null"` so the deserializing code must still
be handling null properly.
Finally, changing the database schema is out of scope for this pull
request, so database entities that also happen to be serialized with
Gson will keep their original types even if they could be made non-null
as an improvement.
In the end this is all for the best, because the app will be more
reliable and errors will be easier to detect by showing up earlier with
a clear error message. Not to mention the performance benefits of using
Moshi compared to Gson.
- Replace Gson reflection with Moshi Kotlin codegen to generate all
parsers at compile time.
- Replace custom `Rfc3339DateJsonAdapter` with the one provided by
moshi-adapters.
- Replace custom `JsonDeserializer` classes for Enum types with
`EnumJsonAdapter.create(T).withUnknownFallback()` from moshi-adapters to
support fallback values.
- Replace `GuardedBooleanAdapter` with the more generic `GuardedAdapter`
which works with any type. Any nullable field may now be annotated with
`@Guarded`.
- Remove Proguard rules related to Json entities. Each Json entity needs
to be annotated with `@JsonClass` with no exception, and adding this
annotation will ensure that R8/Proguard will handle the entities
properly.
- Replace some nullable Boolean fields with non-null Boolean fields with
a default value where possible.
- Replace some nullable list fields with non-null list fields with a
default value of `emptyList()` where possible.
- Update `TimelineDao` to perform all Json conversions internally using
`Converters` so no Gson or Moshi instance has to be passed to its
methods.
- ~~Create a custom `DraftAttachmentJsonAdapter` to serialize and
deserialize `DraftAttachment` which is a special entity that supports
more than one json name per field. A custom adapter is necessary because
there is not direct equivalent of `@SerializedName(alternate = [...])`
in Moshi.~~ Remove alternate names for some `DraftAttachment` fields
which were used as a workaround to deserialize local data in 2-years old
builds of Tusky.
- Update tests to make them work with Moshi.
- Simplify a few `equals()` implementations.
- Change a few functions to `val`s
- Turn `NetworkModule` into an `object` (since it contains no abstract
methods).
Please test the app thoroughly before merging. There may be some fields
currently declared as mandatory that are actually optional.
There are some new rules, I think they mostly make sense, except for the
max line length which I had to disable because we are over it in a lot
of places.
---------
Co-authored-by: Goooler <wangzongler@gmail.com>
* Add support for updating media description and focus point when editing statuses
* Don't publish description/focus point updates via the standard api when editing a published post
* Use blurhash as image preview and as sensitive media cover, close#1571
* Fix focal point for blurhashes
* Fix video indicator overlapping sensitive media indicator
* Add a preference for blurhash
* Add blurhash to report UI.
* Introduce StatusDisplayOptions
* Add serialization of the meta-data and focus objects
These objects are added in some attachments. This commit adds data
classes which are able to serialize these (partially) in preparation
for the ability to honour the focal point information in image
previews.
* Implement correctly honouring the focal point meta-data in previews
This commit adds code which ensures that the image previews of media
attachments to toots are correctly cropped to always show the focal
point of the image (if it is specified). It should not in any way
influence how previews of media without a focal point are shown.
To achieve the correct crop on the image a few components were
needed:
First of all we needed a way to influence how the image is cropped
into the ImageView. It turns out that the preferred way to do this is
by setting the ScaleType to MATRIX and adjusting the matrix of the
image as needed. This matrix allows us to scale and transform the
image in the way we need to make sure that the focal point is visible
within the view. For this purpose we have the FocalPointEnforcer which
can calculate and set the appropriate matrix on an ImageView as soon
as the image is loaded.
However a second problem is that we need to make sure that this matrix
is updated whenever the size of the ImageView changes. The size might
change for example because the orientation of the device changed from
portrait to landscape or vice versas, or for a number of other reasons
such as the screen being split vertically or something like that.
To be able to hook onto this event we need to create a new extended
version of the ImageView class, which we call
MediaPreviewImageView. This class behaves exactly the same as a normal
ImageView, however if the focalPointEnforcer of this view is set, then
it will call this enforcer to update the image matrix any time the
size is changed.
So this commit changes all media previews in the item_status.xml and
item_status_detailled.xml layout files to the new
MediaPreviewImageView class. Additionally in the code for loading the
images into the previews a new case is added which tests if there is a
focus attribute in the meta-data. If so it makes sure to create and
set the FocalPointEnforcer.
* Fix typos in documentation comment
"to" -> "too"
* Use static imports to remove clutter in FocalPointEnforcerTest
Instead of duplication Assert. in front of every assertEquals, simply
statically import it.
* Move the MetaData and Focus classes into the Attachment class
Since they are very strongly linked to the attachment class and are
themselves very small.
* Refactor the focal point handling code
- All the code modifying the actual members of the
MediaPreviewImageView is now in this class itself. This class still
uses the FocalPointUtil to calculate the new Matrix, but it now
handles setting this new Matrix itself.
- The FocalPointEnforcer has been renamed to the FocalPointUtil to
reflect that it only calculates the correct matrix, but doesn't set
anything on the MediaPreviewImageView.
- The Matrix used to control the cropping of the
MediaPreviewImageViews is now only allocated a single time per view
instead of each time the view is resized. This is done by caching
the Matrix and passing it to the FocalPointUtil to update on each
resize.
* Only reallocate focalMatrix if it is not yet initialized
This helps prevent unnecessary allocations in the case where
setFocalPoint is called multiple times.
* Change checking of availability of objects to use != null
As pointed out, the 'is' keyword is meant for checking types, not for
checking non-nullness.
* Make updateFocalPointMatrix() return nothing
This makes it clearer that it actually mutates the matrix it is
given.
* Fix bug with transitions crashing the PhotoView
Due to the android transitions for some reason copying the scaletype
from the MediaPreviewImageView to the PhotoView during the transition,
the PhotoView would crash on pictures with a focal point, since
PhotoView doesn't support ScaleType.MATRIX.
This is solved by the workaround of overriding both the getScaleType
and setScaleType methods to ensure that we use the MATRIX type in the
preview and the center_crop type in the PhotoView.
Additionally this commit also makes sure to remove the focal point
when the MediaPreviewImageView is recycled.
* Fix bug in overriden getScaleType
Instead of simply returning the scaleType we need to return the
super.getScaleType() method, to avoid crashing.
* Merge changes from master
Mainly the migration to androidx.
* Add circleci
* Commit to maybe fix ci
* Suppress false positives in lint
* Disable linting for tests in ci
* Add image descriptions to gallery
* Fix test
* [CI] Attempt to fix OOM error
* [CI] Attempt to fix OOM error, 2
* Add option to open status from media
* fix theme issue
* increase linespacing on media description
Christophe Beyls
Konrad Pozniak
Levi Bard
Eva Tatarka
Ivan Kupalov
jchmrt
Ivan Kupalov