Status Update
No update yet.
Comments
jg...@google.com
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
to...@gmail.com
jg...@google.com
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.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: