Currently translated at 100.0% (634 of 634 strings)
Co-authored-by: fin-w <puf@users.noreply.weblate.tusky.app>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
Using saner defaults for R8 while reducing the app size even further.
- Add Kotlin compiler options to skip adding assertions in release
builds
- Remove `optimizations`, `optimizationpasses` and `dontpreverify` rules
that are ignored by R8
- Only keep runtime annotations by default. If other attributes are
needed by a specific library, these will already be provided by the
library rules (for example Retrofit or coroutines)
- Remove the obsolete rule allowing a View to reflectively call any
arbitrary public Activity method accepting a View as argument. This has
always been a bad practice and is not used in this project anyway
- Remove the rules related to enums. R8 already optimizes enums properly
out-of-the-box and keeping these rules may prevent some of these
optimizations
- Add support for the `@Keep` annotation. Even if it's not currently
used in the code base, it can be handy in the future
- Add a missing rule to prevent generic signature of `NetworkResult`
class from being removed in `MastodonApi` so Retrofit works
- Allow obfuscation and shrinking of `kotlin.coroutines.Continuation`,
matching the rule defined in the next release of Retrofit
- Remove the rule forcing the removal of `String.format()`. This method
is actually used in the code (and in third-party libraries) for other
things than logging so forcing its removal can do more harm than good.
This pull request removes the remaining RxJava code and replaces it with
coroutine-equivalent implementations.
- Remove all duplicate methods in `MastodonApi`:
- Methods returning a RxJava `Single` have been replaced by suspending
methods returning a `NetworkResult` in order to be consistent with the
new code.
- _sync_/_async_ method variants are replaced with the _async_ version
only (suspending method), and `runBlocking{}` is used to make the async
variant synchronous.
- Create a custom coroutine-based implementation of `Single` for usage
in Java code where launching a coroutine is not possible. This class can
be deleted after remaining Java code has been converted to Kotlin.
- `NotificationsFragment.java` can subscribe to `EventHub` events by
calling the new lifecycle-aware `EventHub.subscribe()` method. This
allows using the `SharedFlow` as single source of truth for all events.
- Rx Autodispose is replaced by `lifecycleScope.launch()` which will
automatically cancel the coroutine when the Fragment view/Activity is
destroyed.
- Background work is launched in the existing injectable
`externalScope`, since using `GlobalScope` is discouraged.
`externalScope` has been changed to be a `@Singleton` and to use the
main dispatcher by default.
- Transform `ShareShortcutHelper` to an injectable utility class so it
can use the application `Context` and `externalScope` as provided
dependencies to launch a background coroutine.
- Implement a custom Glide extension method
`RequestBuilder.submitAsync()` to do the same thing as
`RequestBuilder.submit().get()` in a non-blocking way. This way there is
no need to switch to a background dispatcher and block a background
thread, and cancellation is supported out-of-the-box.
- An utility method `Fragment.updateRelativeTimePeriodically()` has been
added to remove duplicate logic in `TimelineFragment` and
`NotificationsFragment`, and the logic is now implemented using a simple
coroutine instead of `Observable.interval()`. Note that the periodic
update now happens between onStart and onStop instead of between
onResume and onPause, since the Fragment is not interactive but is still
visible in the started state.
- Rewrite `BottomSheetActivityTest` using coroutines tests.
- Remove all RxJava library dependencies.
This way the `FOREGROUND_SERVICE_REMOTE_MESSAGING` permission is not
needed and we should be able to publish on Google Play again. Drawback:
The service can get killed after a while (usually 3 mins) on Android 14.
I also tried using [user initiated data transfer
jobs](https://developer.android.com/about/versions/14/changes/user-initiated-data-transfers),
but that is not available on all api levels, and `WorkManager`, but that
is a huge refactoring and sending would probably work differently than
before.
```
java.lang.RuntimeException: Unable to start service com.keylesspalace.tusky.service.SendStatusService@1eb9198 with Intent { cmp=com.keylesspalace.tusky.test/com.keylesspalace.tusky.service.SendStatusService (has extras) }: android.app.MissingForegroundServiceTypeException: Starting FGS without a type callerApp=ProcessRecord{18608f7 22134:com.keylesspalace.tusky.test/u0a193} targetSDK=34
at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:4839)
at android.app.ActivityThread.-$$Nest$mhandleServiceArgs(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2289)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at android.app.ActivityThread.main(ActivityThread.java:8177)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:971)
Caused by: android.app.MissingForegroundServiceTypeException: Starting FGS without a type callerApp=ProcessRecord{18608f7 22134:com.keylesspalace.tusky.test/u0a193} targetSDK=34
at android.app.MissingForegroundServiceTypeException$1.createFromParcel(MissingForegroundServiceTypeException.java:53)
at android.app.MissingForegroundServiceTypeException$1.createFromParcel(MissingForegroundServiceTypeException.java:49)
at android.os.Parcel.readParcelableInternal(Parcel.java:4870)
at android.os.Parcel.readParcelable(Parcel.java:4852)
at android.os.Parcel.createExceptionOrNull(Parcel.java:3052)
at android.os.Parcel.createException(Parcel.java:3041)
at android.os.Parcel.readException(Parcel.java:3024)
at android.os.Parcel.readException(Parcel.java:2966)
at android.app.IActivityManager$Stub$Proxy.setServiceForeground(IActivityManager.java:6761)
at android.app.Service.startForeground(Service.java:775)
at com.keylesspalace.tusky.service.SendStatusService.onStartCommand(SendStatusService.kt:137)
at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:4821)
at android.app.ActivityThread.-$$Nest$mhandleServiceArgs(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2289)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at android.app.ActivityThread.main(ActivityThread.java:8177)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:971)
```
builds upon work from #4082
Additionally fixes some deprecations and adds support for [predictive
back](https://developer.android.com/guide/navigation/custom-back/predictive-back-gesture).
I also refactored how the activity transitions work because they are
closely related to predictive back. The awkward
`finishWithoutSlideOutAnimation` is gone, activities that have been
started with slide in will now automatically close with slide out.
To test predictive back you need an emulator or device with Sdk 34
(Android 14) and then enable it in the developer settings.
Predictive back requires the back action to be determined before it
actually occurs so the system can play the right predictive animation,
which made a few reorganisations necessary.
closes#4082closes#4005
unlocks a bunch of dependency upgrades that require sdk 34
---------
Co-authored-by: Goooler <wangzongler@gmail.com>
While working on #4249 I noticed that quick replies also don't work as
expected. The notification just stays in the sending state forever.
There are actually 2 problems:
- Notifications are sent in `NotificationFetcher` with the id of the
Mastodon notification as tag and the current account id as id. The wrong
notification id was forwarded to `SendStatusBroadcastReceiver` so it
never had a chance of updating the notification.
- Notifications containing an active remote input can't be cancelled
(they just stop their animation when doing so). So instead I update the
notification with info that the reply is being sent and have it dismiss
automatically.
I also tried replacing the original notification with the "sending"
notification of `SendStatusService`, but that doesn't work because
`Service.startForeground` doesn't have a tag parameter, only an id.
---------
Co-authored-by: Willow <charlag@tuta.io>
#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:
Rationale: In the current layout, when performing multiple interactions
(e.g. fav+boost, fav+reply) on a post that hasn't been interacted with
before, the statistics bar appears and pushes the buttons down, so the
second tap goes to the statistics bar instead
I had it happen multiple times recently that I was testing green Tusky
but Android Studio actually put blue Tusky on my device and I wasted a
lot of time until I found out 😣
This change should tell it that greenDebug is the preferred flavor for
developing.
Currently translated at 100.0% (634 of 634 strings)
Co-authored-by: fin-w <puf@users.noreply.weblate.tusky.app>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
according to crash logs there are seem to be some instances that don't
always return the expected json, so lets be extra safe here
```
Exception java.lang.NullPointerException:
at com.keylesspalace.tusky.components.instanceinfo.InstanceInfoRepository$getInstanceInfo$2.invokeSuspend (InstanceInfoRepository.kt:67)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run (DispatchedTask.kt:108)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run (LimitedDispatcher.java:115)
at kotlinx.coroutines.scheduling.TaskImpl.run (Tasks.kt:103)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely (CoroutineScheduler.java:584)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask (CoroutineScheduler.kt:793)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker (CoroutineScheduler.kt:697)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run (CoroutineScheduler.kt:684)
```
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
Currently translated at 98.7% (625 of 633 strings)
Co-authored-by: fin-w <puf@users.noreply.weblate.tusky.app>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
Chrome defaults to showing it anyways, but Firefox doesn't. By enabling
this feature, users across both browsers will now have the same
experience.
closes tuskyapp/Tusky/issues/4137
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>
Ihor Hordiichuk
XoseM
fin-w
Christophe Beyls
Konrad Pozniak
Willow
Weblate
Zongle Wang
Salif Mehmed
Rhoslyn Prys
Levi Bard
Hồ Nhất Duy
Ümit Solmaz
ButterflyOfFire
Sveinn í Felli
Bruno Miguel
João Alves
Newidyn
Maximilian Ertl