State for a MultiKey only stores the last View that save() was called for

[edenman]

KeyDispatcher passes KeyChanger a Map of contexts, but only one incomingState. State.save() looks like this:

  public void save(@NonNull View view) {
    SparseArray<Parcelable> state = new SparseArray<>();
    view.saveHierarchyState(state);
    viewState = state;
  }

Unfortunately this means if you're saving view state of multiple keys, only the last one actually gets stored in the bundle 😭 Should probably have a Map<Int, SparseArray<Parcelable>> viewState instead and use view ids as the key?

[dcow]

I noticed this too and held off on any attempt to build compound layouts using multiple keys.

[dcow]

Keep in mind: views don't always have ids. But I think the running convention is to only expect views with ids to be saved.

[loganj]

Good catch. This is another weird wrinkle related to MultiKeys being keys themselves.

I like the idea of making State's viewState field a map. That opens the door to saving arbitrary state as well, if we wanted to do so later.

This does add a requirement that views have ids to be persisted, but that's fine IMO. Should be added to javadoc.

[edenman]

Cool, I'll work on a PR

[edenman]

Should I blow up if somebody calls save on a view with no id? Feels like it'd be too easy to accidentally stop saving state on one of your screens if I don't blow up.

[loganj]

blowing up sounds right.