Fixed
Status Update
Comments
yb...@google.com <yb...@google.com> #2
Hi. Thanks for reporting this. Fixed in alpha-04
ze...@gmail.com <ze...@gmail.com> #3
Project: platform/frameworks/support
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug: b/264018028
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
https://android-review.googlesource.com/2373449
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug:
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
du...@gmail.com <du...@gmail.com> #4
deleted
du...@gmail.com <du...@gmail.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.tv:tv-material:1.0.0-alpha04
ch...@gmail.com <ch...@gmail.com> #6
We have the same issue, it'll be nice if we can have something like that
xi...@gmail.com <xi...@gmail.com> #7
We have the same issue, @see http://greenrobot.org/greendao/documentation//queries/
for example:
```
Query<User> query = userDao.queryBuilder().where(
new StringCondition("_ID IN " +
"(SELECT USER_ID FROM USER_MESSAGE WHERE READ_FLAG = 0)")
).build();
```
for example:
```
Query<User> query = userDao.queryBuilder().where(
new StringCondition("_ID IN " +
"(SELECT USER_ID FROM USER_MESSAGE WHERE READ_FLAG = 0)")
).build();
```
du...@gmail.com <du...@gmail.com> #8
If I am not mistaken, I thought Yigit previously said that they don't want to create a query builder API like in comment #7 above. If that is still true, then adding support for something like: public User find(RoomSQLiteQuery statement) would be more realistic. That way, it is up to the users of the library to deal with the query builder
ze...@gmail.com <ze...@gmail.com> #9
Any Updates on this ??
jo...@gmail.com <jo...@gmail.com> #10
A simple approach would be to have a annotation
```
@DynamicQuery(columns = {id, name, ...}, tables={person, address, ...})
public List<PersonAddress> getPersonAddress(String query, String[] queryArgs);
```
That way we could generate the mapping and attach the table observers. Then users could use whatever query builder they would like.
```
@DynamicQuery(columns = {id, name, ...}, tables={person, address, ...})
public List<PersonAddress> getPersonAddress(String query, String[] queryArgs);
```
That way we could generate the mapping and attach the table observers. Then users could use whatever query builder they would like.
yb...@google.com <yb...@google.com> #11
Sorry, no updates on this yet and it is not high priority right now.
ol...@gmail.com <ol...@gmail.com> #12
Any updates? Workarounds are ugly
am...@gmail.com <am...@gmail.com> #13
I'd like to voice support for this. I invested a lot of time into conversion only to brick wall on the order. `CursorLoader` supported some fairly complex order clauses. To get Room to do the same I'd need 16 individual query methods each 10 lines long and sharing 95% of the query.
[Deleted User] <[Deleted User]> #14
Currently I solved this by using a Transformation as a mediator between multiple queries, which picks appropriate query based on Transformation input, as long all queries return the same data type. Keep the Transformation code inside repository so it keeps your View classes clean..
ze...@gmail.com <ze...@gmail.com> #15
Can you share some code please. Thanks and happy new year
On Dec 31, 2017 3:53 PM, <buganizer-system@google.com> wrote:
On Dec 31, 2017 3:53 PM, <buganizer-system@google.com> wrote:
[Deleted User] <[Deleted User]> #16
The following code loads a list of "Stores" for the visible map region on the Google MapView. The reason I needed dynamic queries is because the WHERE clause is different depending on the exact values of visible region coordinates.
VisibleRegion class is com.google.android.gms.maps.model.VisibleRegion, if you want to look into it, while I based the dynamic queries on the original algorithm fromhttps://developers.google.com/android/reference/com/google/android/gms/maps/model/LatLngBounds.html#contains(com.google.android.gms.maps.model.LatLng)
Here is the code:
private final MutableLiveData<VisibleRegion> visibleRegion = new MutableLiveData<VisibleRegion>();
public final LiveData<List<StoreEntity>> storeLiveData = Transformations.switchMap(visibleRegion, new Function<VisibleRegion, LiveData<List<StoreEntity>>>() {
@Override
public LiveData<List<StoreEntity>> apply(VisibleRegion vr) {
final double swLat = vr.latLngBounds.southwest.latitude;
final double swLng = vr.latLngBounds.southwest.longitude;
final double neLat = vr.latLngBounds.northeast.latitude;
final double neLng = vr.latLngBounds.northeast.longitude;
StoresDao d = Database.getDb().storesDao();
if (swLng <= neLng)
return d.loadStoresSwlngSmallerOrEqual(swLat, swLng, neLat, neLng);
else
return d.loadStoresSwlngLarger(swLat, swLng, neLat, neLng);
}
});
=======================================================
@Query("SELECT * FROM stores WHERE :sw_lat <= stores.lat AND stores.lat <= :ne_lat AND :sw_lng <= stores.lng AND stores.lng <= :ne_lng")
public abstract LiveData<List<StoreEntity>> loadStoresSwlngSmallerOrEqual(double sw_lat, double sw_lng, double ne_lat, double ne_lng);
@Query("SELECT * FROM stores WHERE :sw_lat <= stores.lat AND stores.lat <= :ne_lat AND (:sw_lng <= stores.lng OR stores.lng <= :ne_lng)")
public abstract LiveData<List<StoreEntity>> loadStoresSwlngLarger(double sw_lat, double sw_lng, double ne_lat, double ne_lng);
========================================================
That's it. Every time the map moves, I post the new VisibleRegion to "visibleRegion" MutableLiveData.. and you see the rest.
Happy new year! :)
VisibleRegion class is com.google.android.gms.maps.model.VisibleRegion, if you want to look into it, while I based the dynamic queries on the original algorithm from
Here is the code:
private final MutableLiveData<VisibleRegion> visibleRegion = new MutableLiveData<VisibleRegion>();
public final LiveData<List<StoreEntity>> storeLiveData = Transformations.switchMap(visibleRegion, new Function<VisibleRegion, LiveData<List<StoreEntity>>>() {
@Override
public LiveData<List<StoreEntity>> apply(VisibleRegion vr) {
final double swLat = vr.latLngBounds.southwest.latitude;
final double swLng = vr.latLngBounds.southwest.longitude;
final double neLat = vr.latLngBounds.northeast.latitude;
final double neLng = vr.latLngBounds.northeast.longitude;
StoresDao d = Database.getDb().storesDao();
if (swLng <= neLng)
return d.loadStoresSwlngSmallerOrEqual(swLat, swLng, neLat, neLng);
else
return d.loadStoresSwlngLarger(swLat, swLng, neLat, neLng);
}
});
=======================================================
@Query("SELECT * FROM stores WHERE :sw_lat <= stores.lat AND stores.lat <= :ne_lat AND :sw_lng <= stores.lng AND stores.lng <= :ne_lng")
public abstract LiveData<List<StoreEntity>> loadStoresSwlngSmallerOrEqual(double sw_lat, double sw_lng, double ne_lat, double ne_lng);
@Query("SELECT * FROM stores WHERE :sw_lat <= stores.lat AND stores.lat <= :ne_lat AND (:sw_lng <= stores.lng OR stores.lng <= :ne_lng)")
public abstract LiveData<List<StoreEntity>> loadStoresSwlngLarger(double sw_lat, double sw_lng, double ne_lat, double ne_lng);
========================================================
That's it. Every time the map moves, I post the new VisibleRegion to "visibleRegion" MutableLiveData.. and you see the rest.
Happy new year! :)
ze...@gmail.com <ze...@gmail.com> #17
Thx for sharing. But still I am looking for full dynamic queries :)
On Dec 31, 2017 5:39 PM, <buganizer-system@google.com> wrote:
On Dec 31, 2017 5:39 PM, <buganizer-system@google.com> wrote:
[Deleted User] <[Deleted User]> #18
Ah well sorry no, this only works if you need to switch between finite amount of queries based on input.. I was mostly giving a suggestion to the guy above who said he needs to manage 16 queries, and how he could more easily solve it..
jo...@gmail.com <jo...@gmail.com> #19
Take a look at https://github.com/jeffdcamp/dbtools-room .
https://github.com/jeffdcamp/dbtools-room/blob/master/app/src/main/kotlin/org/dbtools/sample/roomsqlite/datasource/database/main/foo/FooDao.kt
Shows an example of dynamic queries using this library. It takes three parameters. The query, the tables to observe, and a mapping function to convert from cursor to object.
Shows an example of dynamic queries using this library. It takes three parameters. The query, the tables to observe, and a mapping function to convert from cursor to object.
ze...@gmail.com <ze...@gmail.com> #20
du...@gmail.com <du...@gmail.com> #22
Hmm, that links requires me to login. Can you please verify that it is publicly accessible?
du...@gmail.com <du...@gmail.com> #23
And sorry if I misunderstood this and that link is not for public Access. Thank you.
lo...@gmail.com <lo...@gmail.com> #25
Is paging supported properly too?
to...@gmail.com <to...@gmail.com> #26
In regards to https://issuetracker.google.com/issues/62169706 - why isn't this a compilation error from the @Query annotation processor?
Description
Version used: 1.0.0.aplha1
Devices/Android versions reproduced on: All
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).
I would be cool if queries could be dynamic i.e passed as a parameter, something similar to the @url annotation in retrofit 2