**! ! 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.
#4205 did change how the counters for the detailed posts behave and for
a good reason I believe.
However I find the changed order very confusing and not aesthetically
pleasing.
I have tried a few options, including reserving space for it but it was
confusing (when counters are not displayed there would be a danging
separator or if we show separator together with it it would be confusing
as well).
I propose we simply show the counters independent on the counts. I know
we try to de-emphasize the counters but I believe this is fine to do in
detailed view.
One disadvantage is that we need translators to update the translations.
Additionally I've done two spacing changes: I removed a separator
between the counters and the buttons, removed padding around the
counters and increased the space between the counters and the buttons
instead. I believe it's better to use space than separators. This also
makes the space above/below the media/counters separator balanced.
In the second commit I've also made the metadata/counters separators
thinner, I think it looks better.
here's the combined version:
The sensitive flag indicates sensitive media, but we want to check if
there is a contentwarning on the post. I think statuses that have a
contentwarning but no sensitive flag are rare so we never noticed this
bug.
closes#4201
Found with Leak canary: The transformation ends up in Glide's memory
cache and leaks whole Activities through the view -> context reference.
This fixes the problem by removing the background detection logic (so
the view reference is no longer needed) and setting the background
directly instead. Looks exactly as before.
Avatars that are semi-transparent are a problem when viewing a thread,
as the line that connects different statuses in the same thread is drawn
underneath the avatar and is visible.
Fix this with a CompositeWithOpaqueBackground Glide transformation that:
1. Extracts the alpha channel from the avatar image
2. Converts the alpha to a 1bpp mask
3. Draws that mask on a new bitmap, with the appropriate background
colour
4. Draws the original bitmap on top of that
So any partially transparent areas of the original image are drawn over
a solid background colour, so anything drawn under them will not appear.
Update to Kotlin 1.9.0 and migrate to newer language idioms.
- Remove unnecessary @OptIn for features migrated to mainstream
- Use `data object` where appropriate
- Use new enum `entries` property
formatNumber() was existing code to show numbers with suffixes like K, M, etc, so re-use that code and delete shortNumber().
Update the tests to (a) test formatNumber(), and (b) be parameterised.
* Show reblog/favourite confirmations as menus not dialogs
The previous code used dialogs and displayed the text of the status when
reblogging or favouriting.
This didn't work when the post just contained images, and other material
from the status (content warning, polls) was not shown either.
Fix this by displaying a popup menu instead. The status remains visible so
the user can clearly see what they're acting on.
In addition, this lays the groundwork for supporting a long-press menu
in the future to allow the user to reblog/favourite from a different
account.
Fixes https://github.com/tuskyapp/Tusky/issues/3308
* Revert the change that puts the menu immediately over the icon
Although this behavious is consistent with how the option menu works, I
decided that the risk of someone inadvertently double-tapping in the same
location, and the first tap opens the menu and the second tap confirms the
action was too great.
So now the menu appears either above or below the icon depending on space,
and the user has to tap in two slightly different spaces.
This is also consistent with the previous behaviour, where it's highly
unlikely that the confirm button on the dialog would have been directly
under the user's finger if they double-tapped.
* Show toot stat inline
* Correct elements position
* Format stats and show it according to setting
* inline toot statistics setting
* Code formatting
* Use kotlin functions
* Change the statistics setting description
* Use capital letters for all variants
* increase the statistics margin
* Merge fixes
* Code review fixes
* move setReblogsCount and setFavouritedCount to StatusViewHolder
* code cleaning
* code cleaning
* import lexicographical order
---------
Co-authored-by: Grigorii Ioffe <zikasaks@gmail.com>
Co-authored-by: grigoriiioffe <zikasaks@icloud.com>
* Replace "warn"-filtered posts in timelines and thread view with placeholders
* Adapt hashtag muting interface
* Rework filter UI
* Add icon for account preferences
* Clean up UI
* WIP: Use chips instead of a list. Adjust padding
* Scroll the filter edit activity
Nested scrolling views (e.g., an activity that scrolls with an embedded list
that also scrolls) can be difficult UI.
Since the list of contexts is fixed, replace it with a fixed collection of
switches, so there's no need to scroll the list.
Since the list of actions is only two (warn, hide), and are mutually
exclusive, replace the spinner with two radio buttons.
Use the accent colour and title styles on the different heading titles in
the layout, to match the presentation in Preferences.
Add an explicit "Cancel" button.
The layout is a straightforward LinearLayout, so use that instead of
ConstraintLayout, and remove some unncessary IDs.
Update EditFilterActivity to handle the new layout.
* Cleanup
* Add more information to the filter list view
* First pass on code review comments
* Add view model to filters activity
* Add view model to edit filters activity
* Only use the status wrapper for filtered statuses
* Relint
---------
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* Kotlin 1.8.10
https://github.com/JetBrains/kotlin/releases/tag/v1.8.10
* Migrate onActivityCreated to onViewCreated
* More final modifiers
* Java Cleanups
* Kotlin cleanups
* More final modifiers
* Const value TOOLBAR_HIDE_DELAY_MS
* Revert
* show status edits part 1
* show status edits part 2 - load status edits
* fix code formatting
* add dialog to show status edits
* small improvements
* use ALIGN_CENTER to position status visibility icon when possible
* rename status_timestamp_info view to status_meta_info
* make dateFormat static
* remove commented-out code
* move edits to dedicated fragment
* Fix off-by-one error in HttpHeaderLink
Link headers with multiple URLs with multiple parameters were being parsed
incorrectly.
Detected by adding unit tests ahead of converting to Kotlin.
* Convert util/HttpHeaderLink from Java to Kotlin
* Convert util/ThemeUtils from Java to Kotlin
* Convert util/TimestampUtils from Java to Kotlin
* Add tests for PairedList
* Convert util/PairedList from Java to Kotlin
* Implement feedback from PR
* Relicense as GPL
* issue 2890: Add an "ALT" sticker to the media preview container if there are descriptions
* issue 2890: Use end and start for positioning
* issue 2890: Adapt to new media view group
* issue 2890: Use an indicator overlay for every (single) preview image
* issue 2890: Reduce radius to match that of the preview layout
* issue 2890: Remove (again) unused code
* issue 2890: Set visibility in any case
* issue 2890: Use a translatable text for ALT
* issue 2890: Show ALT flag only when showing media
* issue 2890: Call doOnLayout on the layout wrapper
* fix crash in TouchDelegateHelper when not all views are available
* filter views before passing to TouchDelegateHelper
* remove unused import
* fix indentation
* Add editedAt field to Status
* Status: Display indicators of edited posts
* Annotate edited posts in the Status description
* Cache info that post has been edited
* initial setup
* add spacing between images
* use blurhash
* handle hidden state and show video indicator
* handle item clicks
* small cleanup
* move SquareImageView into account.media package
* fix build
* improve AccountMediaGridAdapter
* handle loadstate, errors and refreshing
* remove commented out code
* log error
* show audio attachments with icon
* fix glitchy transition animation
* set image Description on imageview
* show toast with media description on long press
* guard against the status of a notification being null in rare cases
* improve code, fix bug when payloads is not null
* remove findViewById
* add comments in NotificationsAdapter
* Improve time format of posts when using absolute time
* fix AbsoluteTimeFormatter, add tests
* fix tests
Co-authored-by: Conny Duck <k.pozniak@gmx.at>
* Migrate LinkHelper to kotlin
* Support tags field on statuses
* Use embedded tags list in status instead of text scraping to embed tag click handler.
Fixes#2283
* Make mentions and tags lists nonnullable
* Make LinkHelper.openLink a Context extension method
* Use builtin extension for uri conversion
* More cleanup in LinkHelper
* Add tests for LinkHelper.getDomain
* Unbreak tags in places that don't have a tag list (e.g. profiles)
* Fixup javadoc
* Open photos embedded in preview cards in the internal image viewer instead of opening the browser
* Enable toolbar for single image viewer
* Apply review feedback
Christophe Beyls
Willow
Konrad Pozniak
Levi Bard
Nik Clayton
Goooler
Grigorii Ioffe
UlrichKu
Eva Tatarka
fruyek
Josh Soref
Mélanie Chauvel
Colin Kinloch
Alibek Omarov
Conor Flynn