英文:
Compose Navigation: How Can Users Launch The Application on Unexpected Screens?
问题
为什么用户可以在我们导航层次结构更深的屏幕上启动应用程序？
使用Jetpack Compose Navigation。我们在应用程序中看到了Crashlytics中记录的崩溃。我们还记录了屏幕视图，可以在崩溃事件的日志中看到。这使我们能够看到用户自启动以来在应用程序中的活动轨迹。
我们崩溃的原因是因为我们依赖于内存中的一些数据，这些数据存储在一个单例存储库中。如果用户按照我们指定的唯一方式进入该屏幕，这可能没有问题，但是从日志中我们可以看到会话开始，然后他们立即进入屏幕。
请参见下面的Firebase崩溃报告日志截图： 
英文:
Why can the user launch the application on a screen that is deeper in our navigation hierarchy?
Using Jetpack Compose Navigation. We are seeing crashes in the app which we are logging in Crashlytics. We are also recording screen views which we can see in the crash event's logs. This allows us to see where the user has been in the app since launch.
We are crashing because we rely on some data stored in memory in a singleton repository. This would be fine if the user went through the only way we've specified to get onto that screen, however from the logs we can see that the session starts and they're immediately on the screen somehow.
See below for a screenshot of the firebase crash report logs:
答案1
得分: 0
这是可能的，也经常发生。基本上，用户在深层屏幕上最小化了应用，过了一段时间，系统终止了您的应用（进程死亡），然后用户重新启动了应用：导航组件保存了上次可见的屏幕，并在重新启动时自动恢复。
看起来您需要稍微重新设计应用，例如，如果屏幕需要一些来自先前屏幕的数据，请将其作为屏幕参数传递，而不是保存在存储库中。屏幕参数将在进程死亡时保留。
阅读有关 onSaveInstanceState 和 SavedStateHandle 的信息。
英文:
That's possible and this happens. Basically the user minimized the app on the deeper screen, left it for some time, system killed your app (process death), then user launched the app again: navigation component saved last visible screen and restored it automatically on re-launch.
Looks like you need to redesign the app a little bit, e.g. if the screen needs some data from previous screen, pass it as a screen argument instead saving in repository. The screen arguments will survive process death.
Read about onSaveInstanceState and SavedStateHandle.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论