Fixed
Status Update
Comments
yb...@google.com <yb...@google.com> #2
Hi. Thanks for reporting this. Fixed in alpha-04
[Deleted User] <[Deleted User]> #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
yb...@google.com <yb...@google.com> #4
deleted
[Deleted User] <[Deleted User]> #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
yb...@google.com <yb...@google.com> #6
yea i don't think we can reasonably do this since we don't know how many thread hops you'll do inside and android transactions are thread confined.
so it is probably best if we show an error if someone has this case rather than silently failing.
so it is probably best if we show an error if someone has this case rather than silently failing.
ap...@google.com <ap...@google.com> #7
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 9b78b58d3758e84a5c4a26c812e1164076552e3e
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Tue Jan 15 13:10:58 2019
Disallow @Transaction implementations with async return types.
Since we cannot reasonably defer begin and end transactions in a
implemented DAO method that returns an async type then throw an error
if such method is detected.
Bug: 120109336
Test: ./gradlew room:room-compiler:test
Change-Id: Ifa1bf55cc736ad7c4735043e5b8bac6cd7954ab7
M room/compiler/src/main/kotlin/androidx/room/processor/ProcessorErrors.kt
M room/compiler/src/main/kotlin/androidx/room/processor/TransactionMethodProcessor.kt
M room/compiler/src/test/kotlin/androidx/room/processor/TransactionMethodProcessorTest.kt
https://android-review.googlesource.com/873033
https://goto.google.com/android-sha1/9b78b58d3758e84a5c4a26c812e1164076552e3e
Branch: androidx-master-dev
commit 9b78b58d3758e84a5c4a26c812e1164076552e3e
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Tue Jan 15 13:10:58 2019
Disallow @Transaction implementations with async return types.
Since we cannot reasonably defer begin and end transactions in a
implemented DAO method that returns an async type then throw an error
if such method is detected.
Bug: 120109336
Test: ./gradlew room:room-compiler:test
Change-Id: Ifa1bf55cc736ad7c4735043e5b8bac6cd7954ab7
M room/compiler/src/main/kotlin/androidx/room/processor/ProcessorErrors.kt
M room/compiler/src/main/kotlin/androidx/room/processor/TransactionMethodProcessor.kt
M room/compiler/src/test/kotlin/androidx/room/processor/TransactionMethodProcessorTest.kt
Description
Version used: 2.0.0
Devices/Android versions reproduced on: N/A
In current version of room if I mark method in DAO with @Transaction, and if it uses any disposable e.g. Single, the generated code will throw main thread access exception at runtime.
I would expect one of two behaviours instead:
1. It would be ideal if room could somehow defer start/end transaction to match thread that is used on Disposable, but I can imagine that this can be not possible.
2. To get compile time warning or error that this may be not the correct way of using @Transaction with mix of asynchronous code.
Example of code:
Method in abstract DAO:
@Transaction
open fun upsert(obj: T): Single<Boolean> {
return insert(obj)
.map { true }
.onErrorResumeNext {
if (it is SQLiteConstraintException)
{ update(obj)
.map { true }
} else {
Single.error(it) }
}
.subscribeOn(Schedulers.io()) }
Generated method:
@Override
public Single<Boolean> upsert(Supplier obj) {
__db.beginTransaction();
try {
Single<Boolean> _result = super.upsert(obj);
__db.setTransactionSuccessful();
return _result;
} finally {
__db.endTransaction();
}
}