As per the FIXMEs, the list of profiles should eventually become a map.
Since it can only be modified on the main thread anyway, the current
code is still safe, and it works, it's just not optimal.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This condition was previously enforced in the AsyncTask, but was lost in
the move from ProfileListActivity to ProfileService.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The long-running service is needed for keeping track of which profiles
are enabled, for showing notifications, and for the tile service to use.
Since it has to know which profiles exist anyway, moving the main
ObservableList there avoids some code duplication. It ensures the list
is only loaded once, so it cannot get out of sync. It also makes the
ProfileList activity load faster, because it doesn't have to wait for
file I/O; and it provides a canonical place for storing the Profile
objects so they are accessible everywhere, instead of having to look
them up by name.
This does present some challenges with leaking activities, because all
listeners must be removed from the profiles list (and its contents) when
an activity is stopped.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This allows the ObservableListAdapter to be garbage collected along with
its activity. On the next list change, the OnListChangedCallback will
detect that the adapter is gone and clean itself up. This avoids needing
to manually remove the list from the adapter, as would otherwise be
required to break the reference cycle adapter→list→listener→adapter.
This will be relevant once the list of profiles outlives the activity.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
For now, it simply reads the files in the app's data directory with
file names ending in ".conf" and displays them in a list.
This includes the generic list data binding setup for future use.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
