Fixed
Status Update
No update yet.
Comments
ap...@google.com
To give more color to this, every android related library or framework that I use is initialized by passing it a Context. This allows me to have a ContentProvider where I can do all my initialization. The benefits of this are:
1. Abstraction - my app module doesn't need to know about anything other than my internal modules and doesn't interface directly with libraries
2. An Application is built for each process, which means that we now have a CameraXConfig.Provider for secondary processes like a crash reporting process, etc... ContentProvider is only created once across all processes (and can be set to create one per process for apps that need to configure the camera across multiple processes, which I'm positive are very rare)
TL;DR the recent trend has been to move away from Application as a source of configuration for a variety of benefits
1. Abstraction - my app module doesn't need to know about anything other than my internal modules and doesn't interface directly with libraries
2. An Application is built for each process, which means that we now have a CameraXConfig.Provider for secondary processes like a crash reporting process, etc... ContentProvider is only created once across all processes (and can be set to create one per process for apps that need to configure the camera across multiple processes, which I'm positive are very rare)
TL;DR the recent trend has been to move away from Application as a source of configuration for a variety of benefits
ap...@google.com
Thank you for the feedback, we'll take a look and assess.
Description
Having just a
remember { }around calls togetBackStackEntry(route)causes new entries with the same id to use the old remember scope which can cause crashes. We should instead be telling devs to useremember(entry) { }using the entry from thecomposablefunction lambda scope as the input to theremembercalculation. This way, whenever the entry object changes, we also recompose therememberand we never get a stale entry.