You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the state is lost after then app (really) closes. This is not expected behavior for an - admittedly very minor - user preference setting.
Note that lock state is currently configurable per PhotoClub, and that the set of supported Photo Clubs should ultimately be determined at runtime (=dynamcally).
Possible solutions:
store Lock state in UserDefaults as a dictionary. The dictionary can grow.
store Lock state in UserDefaults as a Boolean. Means all locks open/close together. User won’t really mind or notice. But there are multiple separate Lock buttons.
store state in existing Core Data database. There is already a PhotoClubs table, so just requires one extra property, and the ability to get is (no effort) and set it (some code).
In all cases, the state of the Lock is lost when the app is reinstalled. I implemented option 3.
The text was updated successfully, but these errors were encountered:
Actually the Lock is (in theory) buggy in v2.2.8: if you lock/unlock a photo club's map when there are 2 clubs with the same name in a different town, both lock/unlock together. This won't bother anyone yet, but should be resolved as part of issue #75.
Currently, the state is lost after then app (really) closes. This is not expected behavior for an - admittedly very minor - user preference setting.
Note that lock state is currently configurable per PhotoClub, and that the set of supported Photo Clubs should ultimately be determined at runtime (=dynamcally).
Possible solutions:
In all cases, the state of the Lock is lost when the app is reinstalled. I implemented option 3.
The text was updated successfully, but these errors were encountered: