Sharing an order warning across two Android screens: where should state live?

An Android app has an order history screen and an account screen that both must warn users about an earlier order needing attention. One approach is to extract the check, dismiss and recover behaviour into a shared presentation component that each ViewModel uses, which reduces duplication and narrows what needs testing. The author notes that this doesn't settle whether a dismissed warning should reappear on the other screen, which depends on whether each screen holds its own dismissal state or they share one instance. The author argues that dismissing a dialog is a presentation choice and should not mark the underlying order as recovered. Sharing a ViewModel above both screens is also possible but is only justified if the warning truly belongs to that shared flow, since it adds scope and lifetime concerns. The author suggests listing expected behaviour for cases like dismissal, interrupted recovery and repeated triggers before choosing a pattern.