IssueTracker

this issue on workManager 2.5.0 when initialize WorkManager in background thread, bring it back to UI thread

Still happening with WorkManager 2.7.1 Samsung Galaxy S21 Ultra 5G Android 12 (SDK 31)

java.lang.RuntimeException: 
  at android.app.ActivityThread.handleCreateService (ActivityThread.java:4953)
  at android.app.ActivityThread.access$1900 (ActivityThread.java:310)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2300)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loopOnce (Looper.java:226)
  at android.os.Looper.loop (Looper.java:313)
  at android.app.ActivityThread.main (ActivityThread.java:8669)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Caused by: java.lang.IllegalStateException: 
  at androidx.work.impl.WorkManagerImpl.getInstance (WorkManagerImpl.java:158)
  at androidx.work.impl.foreground.SystemForegroundDispatcher.<init> (SystemForegroundDispatcher.java:105)
  at androidx.work.impl.foreground.SystemForegroundService.initializeDispatcher (SystemForegroundService.java:96)
  at androidx.work.impl.foreground.SystemForegroundService.onCreate (SystemForegroundService.java:59)
  at android.app.ActivityThread.handleCreateService (ActivityThread.java:4940)
  at android.app.ActivityThread.access$1900 (ActivityThread.java:310)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2300)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loopOnce (Looper.java:226)
  at android.os.Looper.loop (Looper.java:313)
  at android.app.ActivityThread.main (ActivityThread.java:8669)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)

We recently moved our WorkManager initialization to the default pattern and have started seeing this same issue.

java.lang.RuntimeException: Unable to create service androidx.work.impl.background.systemjob.SystemJobService: java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
        at android.app.ActivityThread.handleCreateService(ActivityThread.java:5073)
        at android.app.ActivityThread.-$$Nest$mhandleCreateService(Unknown)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2425)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loopOnce(Looper.java:226)
        at android.os.Looper.loop(Looper.java:313)
        at android.app.ActivityThread.main(ActivityThread.java:8741)
        at java.lang.reflect.Method.invoke(Method.java:-2)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

Caused by: java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
        at androidx.work.impl.background.systemjob.SystemJobService.onCreate(SystemJobService:73)
        at android.app.ActivityThread.handleCreateService(ActivityThread.java:5060)
        at android.app.ActivityThread.-$$Nest$mhandleCreateService(Unknown)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2425)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loopOnce(Looper.java:226)
        at android.os.Looper.loop(Looper.java:313)
        at android.app.ActivityThread.main(ActivityThread.java:8741)
        at java.lang.reflect.Method.invoke(Method.java:-2)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

I would check to make sure that the app is not a multi-process app. If it is, you will need your Application to additionally sub-class Configuration.Provider or additionally define a second provider for the other process.

If your project does not have a deep dependency on the paging3 library, I recommend implementing a simple paging library yourself to avoid all the weird features of paging3. Paging library needs the coordination of the view layer and the model layer. It doesn't make sense to encapsulate these together.

Here's an example from my project. If you don't need to modify the list, it can be implemented much simpler.

https://gist.github.com/FishHawk/6e4706646401bea20242bdfad5d86a9e

Still not fixed in latest versions, workaround works. Please consider re-opening the issue.

Seconded. Still a problem in 1.3.1

https://issuetracker.google.com/issues/177245496#comment24 works

The default case (all of your items are loaded asynchronously) was fixed in comment#2. For Paging, there is the additional requirement that you must be using cachedIn in your layer above Compose (e.g., your ViewModel layer).

However, the case where you have some items available immediately (like a header and footer) and some items available only asynchronously, is not fixed. This is broken whether you use Paging or not - any data loaded from a Flow would suffer this same problem (as they also would not be available in the first composition).

Creating an generic API for informing the Lazy Layout of when all asynchronously loaded items have finished loading (particularly noting that there can be multiple items blocks loading from multiple asynchronous sources) is not something we can solve in the short or medium term.

That being said, we believe there may be a way to solve this in the specific case of headers+footers and a single call to collectAsLazyPagingItems without having to wait for an overhaul of either the Paging or Lazy layout APIs, so we will be reopening this issue to track that internal investigation.

Sounds like Paging and Component are being developed with a lot of various serious issues that are piling with each version, and the team does not have any intention of fixing them. That's alright, at least now we can finally stop waiting for this to be fixed and instead stop using them entirely. Good luck with this.

Compose requires an initial state for valid first composition.

Paging 3's entire architecture is based around emitting data through a Flow that doesn't emit until collected.

Therefore, significant changes within Paging 3 are required to enable initial states in paging-compose without collection. While these changes are not easily resolvable, we hope to address them in the coming year.

https://issuetracker.google.com/issues/177245496#comment23 - how this condition is going to help if you completely remove the list from composition?

This has been fixed internally and will be available in the next release. The next release version is TBD.

In short, the fix works by making cached data immediately available for presentation after config change / navigation. This prevents the list from having zero items right after config change/ navigation so the scroll state will be preserved without requiring workarounds such as comment#24.

That said, it only works if there is cached data to begin with. This means you need pager.flow.cachedIn(scope). Note that any PagedData mapping/transformations should be applied prior to cachedIn(), such as

val pager = pager.flow.map { pagingData -> 
    pagingData.map {
       // map items
    }
}.cachedIn(scope)

Is it going to fix incorrect loadState (Loading) as well (to avoid displaying incorrect refresh indicator to users)?

val lazyPagingItems = viewModel.pagingDataExample.collectAsLazyPagingItems()
val loadState = lazyPagingItems.loadState.refresh // loadState == Loading initially on config changes/navigation

It should be NotLoading if data is returned from cahce and no request to refresh is triggered

Yes it will start with NotLoading if displaying cachedData.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.paging:paging-common:3.2.0-alpha05

I'll note that while some of the changes from this bug made it into Paging 3.2.0-alpha05, the important ones did not - it'll be in the next release of Paging.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.paging:paging-compose:1.0.0-alpha20

comment#51 are you using cachedIn and paging-common 3.2.0-alpha06?

Re comment#51 - please file a new bug with a sample project that reproduces your issue.

comment#52, comment#53- Sorry, I did a mistake, I used function instead of val in viewmodel. Bug has been fixed now. Tested...

Regarding the workaround from comment#24, if you want firstVisibleItemIndex and firstVisibleItemScrollOffset to continue to remain the same in case other code depends on them, it looks like the workaround should be modified to this?

@Composable
fun <T : Any> LazyPagingItems<T>.rememberLazyGridState(): LazyGridState {
    val state = androidx.compose.foundation.lazy.grid.rememberLazyGridState()

    return when (itemCount) {
        // Return a different LazyListState instance.
        0 -> remember(this) {
            LazyGridState(
                firstVisibleItemIndex = state.firstVisibleItemIndex,
                firstVisibleItemScrollOffset = state.firstVisibleItemScrollOffset
            )
        }
        // Return rememberLazyListState (normal case).
        else -> state
    }
}

If there is a combined flow, cachedIn does not seem to work. Could you please confirm?

val pager = pager.flow
    .map { pagingData -> 
        pagingData.map {
            // map items
        }
    }
    .cachedIn(scope)
    .combine(otherFlow) { pagingData, otherFlow ->
        pagingData.map{
            // something
        }
    }
    .cachedIn(scope)

If you call the pager again with collectAsLazyPagingItems(), LoadState will be called LoadState.Loading rather than LoadState.NotLoading.

Re comment#56 - please file a new bug with a sample project that reproduces your issue

Re comment#58 - there's no difference between navigating a single screen away and navigating multiple screens away - in either case, the ViewModel for your original screen stays in memory the entire time and the composition for the old screen is removed.

Please file a new issue with a sample project that reproduces your issue if you are seeing something different.

im having a similar problem as comment#58 but when navigating to another screen. I update some of the room paging elements in the previous composable with lazy column and when i return scroll state is lost, if i navigate and the return without changing any items from room, state is preserved. The workaround of the mentioned comment is working for me so guess it has to do with the paging behaviour rather than my implementation .... version 3.2.1 too

Re comment#60 can you please file a separate bug with a sample app that reproduces the issue?

Yes they do not want the if and placeholders to be inside the LazyColumn we are supposed to use if outside of the LazyColum.

The workaround is to use a fake lazystate until your data is loaded.

See for example solution https://issuetracker.google.com/issues/177245496#comment62

re comment#62 if you are caching the pager flow with cachedIn(), you shouldn't need a workaround. Can you upload a sample app for me to take a look?

Cachein does not keep the data when the app is killed in the background or viewmodel is unloaded.

That's cute but you might actually want to read the issue.

val pager = pager.flow
    .map { pagingData -> 
        pagingData.map {
            // map items
        }
    }
    .cachedIn(scope)
    .combine(otherFlow) { pagingData, otherFlow ->
        pagingData.map{
            // something
        }
    }
    .cachedIn(scope)

my-version = androidx.paging:paging-compose:3.3.5

When otherFlow updates data, an error occurs: Attempt to collect twice from pageEventFlow, which is an illegal operation. Did you forget to call Flow<PagingData<*>>.cachedIn(coroutineScope)?

comment#69 can you please file a separate bug for your issue?