Status Update
No update yet.
Comments
jg...@google.com
All extensions in 'core-ktx' target either 'core' or the framework types. This is working as expected. It sounds like this is a feature request for a transition-ktx with equivalent extensions for the androidx.transition types.
> as most framework classes are being deprecated in favor of their AndroidX counterparts, Fragments for example.
"Most"? This *dramatically* overstates what is actually happening. Fragments (and loaders) were added to the framework in a time where the Android team did not have external libraries for shipping features. Transition was added 5 years later.
to...@gmail.com
If the Transition api is unlikely to change, there is no need for a transition-ktx for androidx.transition types. If developers should use Androidx transitions over framework transitions where possible however, then it would be much appreciated.
I am well aware of the limitations that existed when Fragments and Loaders were created, and when the Transition api was introduced.
jg...@google.com
Branch: androidx-master-dev
commit ae42e311ecfbac18cedc90e489d1fdde956a4557
Author: Jake Wharton <jakew@google.com>
Date: Fri Nov 22 11:13:30 2019
Introduce transition-ktx for standalone transition library
These extensions are the same as androidx.core.transition for the platform types, just adapted to the standalone library.
Bug: 138870873
Test: gw :transition:transition-ktx:build :transition:transition-ktx:connectedCheck
Change-Id: Ie80022cc60ed1f482b7593db5ef1ac1c5ea33d8d
M buildSrc/src/main/kotlin/androidx/build/PublishDocsRules.kt
M jetifier/jetifier/migration.config
M settings.gradle
A transition/transition-ktx/OWNERS
A transition/transition-ktx/api/1.4.0-alpha01.txt
A transition/transition-ktx/api/current.txt
A transition/transition-ktx/api/public_plus_experimental_1.4.0-alpha01.txt
A transition/transition-ktx/api/public_plus_experimental_current.txt
A transition/transition-ktx/api/res-1.4.0-alpha01.txt
A transition/transition-ktx/api/restricted_1.4.0-alpha01.txt
A transition/transition-ktx/api/restricted_current.txt
A transition/transition-ktx/build.gradle
A transition/transition-ktx/src/androidTest/AndroidManifest.xml
A transition/transition-ktx/src/androidTest/java/androidx/transition/TestActivity.kt
A transition/transition-ktx/src/androidTest/java/androidx/transition/TransitionTest.kt
A transition/transition-ktx/src/androidTest/res/layout/test_activity.xml
A transition/transition-ktx/src/main/AndroidManifest.xml
A transition/transition-ktx/src/main/java/androidx/transition/Transition.kt
jg...@google.com
I'm glad to hear this works when the tile is added to the system. It depends on your exact use case; there is a minimum update interval that we enforce, as you see.
Do you just need the HTTP resources for your tile? If so, you can always return a tile later from onTileRequest, and fulfill the Future later.
jg...@google.com
Found it. UpdateScheduler is using a WeakReference to the update receiver, but TileUiClient passes a lambda here, which can get immediately GC'd. I'm assuming that physical devices have different GC settings, which avoided this.
to...@gmail.com
Unfortunately, I do not have a phsyical device, yet.
Yes, my application's UI is centered around the result returned by the API. I am aware the onTileRequest's Future can just wait for the http request. This, however, restricts me from updating the UI in between, i.e. showing a loading screen for the duration of the request.
Right now, the app will simply freeze until the result is returned. It's not a showstopper for me or the app, though. Nonetheless, being able to update the UI asynchronously would surely be a huge benefit for Tiles.
ap...@google.com
Branch: androidx-main
commit b33b62c10035ea6645827e8238068c39cdc36423
Author: Jamie Garside <jgarside@google.com>
Date: Thu Sep 16 10:40:23 2021
Fixes for Tiles:
- Don't use a WeakReference in UpdateScheduler.
- Passing a lambda here (as TileUiClient does) causes the lambda to be
immedaitely garbage collected, invalidating the reference.
- Declare that we query PackageManager for the BIND_UPDATE action.
- This is needed on R+ devices, as PM no longer allows you to query
for most packages without declaring that you're doing it.
Relnote: "Fixed bugs in tiles. UpdateScheduler no longer uses a weak
reference, fixing issues where TileUiClient would not update, and
declare that SysUiTileUpdateRequester queries PacakgeManager, fixing a
bug where tile updates would not work on R+ devices."
Test: Manually verified.
Bug: 200125542
Bug: 199061124
Change-Id: I1120ddab0752d5f2104cf65bd4235783b6b818c2
M wear/tiles/tiles-renderer/src/main/java/androidx/wear/tiles/manager/UpdateScheduler.java
M wear/tiles/tiles/src/main/AndroidManifest.xml
lu...@gmail.com
Hello,
I'm building an app and I also can't automatically update the tile. For example, if I call TileService.getUpdater(context).requestUpdate(MyTileService.class) after a SharedPrefs change, it will update the app accordingly but not the Tile - but if I press a refresh button I have on the tile, which calls ActionBuilders.LoadAction.Builder().build(), it will reflect the changes.
In my case, I'm trying to apply saved settings (colors, size, etc) instantly on the tile and have it refresh by itself on a fixed step (set by the user, with a minimum of 1 minute)
I also get the following error when I call the TileService updater:
W/HTUpdateRequester: Couldn't find any services filtering on androidx.wear.tiles.action.BIND_UPDATE_REQUESTER
E/HTUpdateRequester: Could not build bind intent
I'm using OP's artifacts except wear as it follows:
- androidx.wear:wear:1.2.0
- androidx.wear.tiles:tiles:1.0.0-alpha11
- androidx.wear.tiles:tiles-renderer:1.0.0-alpha11
Devices:
- Android Emulator, Android 11.0 API 30
Sorry if I couldn't be more of use, this is my first project using Kotlin and learning as I go. Thanks!
jg...@google.com
Hey,
Apologies, we had a bug which prevented TileService.getUpdater(context).requestUpdate(MyTileService.class) from working correctly on API 30 devices. This is fixed in
In the meantime, you add the following to your AndroidManifest.xml to work around this issue:
<queries>
<intent>
<action android:name="androidx.wear.tiles.action.BIND_UPDATE_REQUESTER" />
</intent>
</queries>
jg...@google.com
This should now be fixed in alpha12.
Description
There seems to be no way of updating a Tile. Neither
TileService.getUpdater(context).requestUpdate(MyTileService.class)nor.setFreshnessIntervalMillis(x)as shown in the Developer Guide work as expected.Instead, at each update the following warning is logged:
W/AlarmManager: Unrecognized alarm listener androidx.wear.tiles.manager.UpdateScheduler@792e555. To me it appeas the issue is rooted in theandroidx.wear.tiles.manager.UpdateScheduler.javanot working correctly, as its fieldmUpdateReceiverbecomesnullwhich leads to updates not being triggered on line 168.The error is reproducible using any of your provided examples and adding one of the lines above.
Artifact used:
Devices/Android versions reproduced on: