CRITICAL BUG using java.time.Instant which is not available in API below 26 about navigation HOT 6 CLOSED

The navigation events are timestamped:

• This allows each event, even subsequent ones of the same type, to be emitted since they are considered different. (StateFlows by nature perform similarly to the distinctUntilChanged operator in that they do not emit the same value twice in a row). The timestamp makes sure that all events are accessed, for instance, two goBack calls will actually go back twice.
• In a future release, replay/time-travel features can be introduced which will help with debugging. This requires some concept of time tracking of the events.
• Whatever model is used for storing time for an event must be serializable with kotlinx serialization as that is used to store and restore the state of a Navigator between configuration changes within the app via the rememberSavableNavigator calls.
• The kotlinx datetime library already provides an abstraction layer (expect/actual) of the Instant type. No need to duplicate this abstraction.

It is possible that I can change the timestamp value from an Instant to perhaps a local clock value. This would remove the dependency on kotlinx.datetime but might produce issues if for whatever reason the local clock restarts or comes out of sync. This will also prevent restoring to a previous Navigator state using serialization as the local clock times will be different (other than for short ranges as it is used now, such as between processes in a Bundle), though that is out of scope anyway.

from navigation.

expect/actual would not solve this problem. You should be able to add the kotlinx.datetime dependency to your project and may also need to use Android desugaring which allows usage of the java.time components in Android (which is what kotlinx.datetime's actual implementation uses on Android and JVM).

https://developer.android.com/studio/write/java8-support-table

from navigation.

I've done it for the time being as I don't want latest version to crash on devices But since this is a navigation library I expected it to not rely on kotlinx datetime and work without desugaring I think that'd be a plus +1

from navigation.

I will look into including the Android Desugaring process in the library's build file for a future release.

from navigation.

Why is using kotlin date time important...?

from navigation.

This is addressed by the following PR and will the fix will be out in the next release: #10

from navigation.