[Android Software/Hacking General [Developers Only]] Lanchon:
im having second thoughts on this. im imagining the manager makes the db entries. making an entry as soon as the manager sees the new app assures that most of the time the backend wont need decide sys/user nor query the corresponding default record as the app record would likely exist.

but this is an implementation detail, and im not sure the best UI is the one with a simple implementation. this is option a) for the UI.

option b) would be this:

-the UI shows two checkboxes on top: user/sys which select the shown apps.

-below is a list of apps setting: first entry is default user, 2nd entry is default system, then only apps with non-default configuration follow. (if only the user checkbox is checked, the default system item is not shown, same goes for all system apps.)

-a button below reads "add" and if u press it shows u a list of unconfigured apps matching the current user/sys selection. choosing an app takes you to the app settings edit screen, only below instead of having "save", "delete" and "cancel" buttons, you have "add" and "cancel" buttons.

-the cancel buttons could be dispensed of if when u pressed "back" with unsaved settings a confirmation dialog popped up: "discard changes?" "discard" "cancel"

option c) would be like b) only unconfigured apps would be shown in the same screen in different color after configured apps, so to add them you would just click them. if you have a search box on top (useful!) this option could make more sense.

these UI versions would clearly show which apps have special permissions and would allow you to change the defaults to affect all non specially configured apps. (if, in configured apps, we added a new option for each permission that would effectively behave as "inherit this setting from the default node", we would be dangerously approaching the full inheritance model in complexity, but without the full benefits. if this kind of thing is desired, the full inheritance model is probably a better choice. in any case, the implementation options would be similar to what follows.)

under the hood, a naive backend implementation would require:

-query the db by app

-if null, query the user/sys app status

-with it query the corresponding default record

-if null, fail (invoke the fail strategy: fail-throws for instance)

this requires more cpu time than a simple query. to counter this there are some options:

1) using a cache. if a cache is already implemented it might be enough. a cache miss means doing the 3 step process above.

2) using a "cooked" db with defaults propagated to app nodes.

3) use both 1) and 2) at the same time.

option 2) can be implemented in many ways. one would be to have a flag for each record that is set when the record is logically "missing", and another flag indicating whether the app is sys or user.

when one of the default records is edited and saved, the db update statement would use a "where" clause to atomically update the default record itself along with all other records marked as missing that match the user/sys type of the default record being updated.

if there is a cache implementation in place now, option 1) could be used for version 1, transitioning to 3) in a later implementation if ever desired.

---------- Post added at 06:59 PM ---------- Previous post was at 06:24 PM ----------

the some-overrides-enabled switch makes the non-overriden (disabled-disabled) state as fast as a single override that does not discriminate user/sys.

this complexity might not be needed. it is maybe the case that reading a switch is as slow as reading two (say, if both are contained in the same file; in this case watch for read-modify-write issues if multiple writers). in this case, the two values would be compared and the app tested for user/sys status only if the values differ.

still a binary switch like some-overrides-enabled could maybe be faster by just checking the existence of a file instead of opening it.

of course each of these 2 or 3 flags must be atomically updated (either by itself or within a group).

it'd be great if the override status could be cached somehow, this would make overrides essentially free.