mirror of
https://github.com/accelforce/Yuito
synced 2024-12-21 12:34:51 +01:00
Yuito è un fork di Tusky, Tusky è un bellissimo client Android per Mastodon. Mastodon è una rete sociale federata. Ciò significa che nessuna singola entità controlla l'intera rete.
https://mastodon.uno
70725fd75b
When viewing a video in Tusky, there is a top toolbar where the description is shown and the bottom toolbar where play, forward, backward, and scrub controls are found. In both Tusky 23 and the new media3 video player code, the logic for showing these toolbars is *unrelated*; Tusky catches tap events and shows and hides the description, and the Android media library separately catches tap events and shows and hides the bottom toolbar. Meanwhile, Tusky and the Android media library each separately manage a set of logic for auto-hiding their respective toolbars after a certain number of seconds has passed. This all results in several problems: - The top and bottom toolbars can desync, so that one is visible and the other is not, and tapping to show/hide after this will only swap which one is visible. This happens *every* time you switch to another application then back to Tusky while the video player is up. - You can also desync the top and bottom toolbars in this way by simply tapping very rapidly. - The autohide logic was difficult for us to control or customize, because it was partially hidden inside the Android libraries (relevant because under media3, the autohide delay increased from 3 to something like 5 or 6 seconds). In this patch, I disabled all auto- and tap-based show/hide logic in media3 and set the Tusky-side show/hide to directly control the media3 toolbar. I then audited the code with printfs until I understood the state machine of show/hide, and removed anything irrational (some code was either unreachable, or redundant; either these lines were broken in the media3 transition, or they never worked).¹ While doing this, I made two policy changes: - As discussed on Matrix, the autohide delay is now 4 seconds. (In discussions with users on Mastodon, some complained the previous 3 seconds was too short; but in my opinion and [I think?] charlag's, the new 5 seconds is too long). - In the pre-existing code, if the user has hidden the controls, and they switch to another app and back, the controls display for 4 seconds then re-hide themselves, just like if the video had been presented for the first time. I think this is good and kept it— *however* I made a decision if the user intentionally taps to display the controls, *then* switches to another app and back, the controls should *not* auto-hide, because the user most recently requested those controls be shown. Tests I performed on the final PR (successfully): - Start video. Expect: toolbar+description hides after 4 seconds. - Start video. Pause. Resume. Expect: t+d hides after 4 seconds. - Start video. Wait 4 seconds until t+d hide. Switch to other app. Switch back. Expect: t+d reappears, then hides after 4 seconds. - Start video. Wait 4 seconds until t+d hide. Tap to show t+d. Switch to other app. Switch back. Expect: t+d appear, do NOT autohide. - Start video. Before 4 seconds up, switch to other app. Switch back. Expect: t+d reappears, then hides after 4 seconds. - Start video. Pause. Resume. Before 4 seconds up, switch to other app. Switch back. Expect: t+d reappears, then hides after 4 seconds. - Start video. Wait 4 seconds until t+d hide. Tap rapidly over and over for many seconds. Expect: Nothing weird - Start *audio*. Expect: At no point does controller autohide, not even if I switch to another app and back, but I can hide it by manually tapping These tests were performed on Android 13. There is an entirely separate `Build.VERSION.SDK_INT <= 23` path I did not test, but Android Studio says this is dead code (I think it thinks our minimum SDK is higher than that?) --- <small>¹ Incidentally, the underlying cause of #4073 (the show/resume part of it anyway) turned out to be that the STATE_READY event was being received not just on video load but also a second time on app resume, causing certain parts of the initialization code to run a second time although the fragment had already been fully initialized.</small> |
||
|---|---|---|
| .github | ||
| .idea | ||
| app | ||
| assets | ||
| doc | ||
| fastlane/metadata/android | ||
| gradle | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| bitrise.yml | ||
| build.gradle | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| ISSUE_TEMPLATE.md | ||
| LICENSE.txt | ||
| README.md | ||
| renovate.json | ||
| settings.gradle | ||
Tusky
Tusky is a beautiful Android client for Mastodon. Mastodon is an ActivityPub federated social network. That means no single entity controls the whole network, rather, like e-mail, volunteers and organisations operate their own independent servers, users from which can all interact with each other seamlessly.
Features
- Material Design
- Most Mastodon APIs implemented
- Multi-Account support
- Dark, light and black themes with the possibility to auto-switch based on the time of day
- Drafts - compose posts and save them for later
- Choose between different emoji styles
- Optimized for all screen sizes
- Completely open-source - no non-free dependencies like Google services
Testing
The nightly build containing the newest development code is available on Google Play.
Support
Check out our FAQs, your question may already be answered. If you have any bug reports, feature requests or questions please open an issue or send us a message at Tusky@mastodon.social!
Contributing
We always welcome new contributors! Please read our contribution guide to get started.