Fixed
Status Update
Comments
yb...@google.com <yb...@google.com> #2
I've experienced seen this issue, even on 26.0.0-beta1.
ze...@gmail.com <ze...@gmail.com> #3
Thank you for reporting this issue. We have shared this with our engineering team and will update this issue with more information as it becomes available.
du...@gmail.com <du...@gmail.com> #4
I think I'm running into this issue again--but this time it's with deep-linking and synthesizing a fragment back stack. If I have postponeEnterTransition in the fragment I'm deep-linking to, I see the other (backstacked) fragments briefly show on screen.
In one project, I'm using the Navigation Component. The graph is just two fragments: A1 is the start destination with a deep-link to A2. I see A1 show momentarily if I use postponeEnterTransition in A2. And I see similar results in another project that does its own fragment transactions; in that case, I can use setReorderingAllowed(false) to prevent the issue.
In one project, I'm using the Navigation Component. The graph is just two fragments: A1 is the start destination with a deep-link to A2. I see A1 show momentarily if I use postponeEnterTransition in A2. And I see similar results in another project that does its own fragment transactions; in that case, I can use setReorderingAllowed(false) to prevent the issue.
du...@gmail.com <du...@gmail.com> #5
This has been fixed internally and will be avilable in Fragment 1.3.0-alpha08.
Note: this fix relies on using the
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