This works much better with a data-bound UI -- no confusing erasing of
the text box, and no crashes, either!
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This was accidentally missed earlier when adding the optimization to
omit binding the service when unnecessary.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Prefer updating an object instead of replacing it. This preserves the
selection in the UI list. Also make renaming atomic as it should be. Now
the only possibility for data loss is if the old file can be opened but
not written to.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Caching the actual profile object is important when the fragment is on
an activity's back stack: when it is shown again, onCreateView will be
called with profile already set and the service already connected. In
this case, there is no later notification from which to bind the
profile, so the existing object needs to be bound there.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This has no visible changes at the moment, but will allow most functions
to pass around strings instead of Profile objects, obviating the need to
implement serialization for them. It also trades some naive linear
searches for the binary search in SimpleArrayMap.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Since the conversion to a sequential list (to implement ListAdapter)
depends on the implementation detail that ObservableArrayMap is backed
by an array, we can't use the ObservableMap interface here.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This is designed for tablets, but for testing purposes, it is currently
enabled for all devices in landscape orientation.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This is required for a future two-fragment tablet layout, and simplifies
the code a bit since the profile detail (view/edit) will be implemented
as fragments anyway.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This should help discourage editing a Profile without making a copy
first, since the caller has to keep track of the old Profile as well.
ProfileAdder has been updated to prevent adding duplicate profiles. It
checks once in the constructor, so the caller can catch the exception
and pass the error back to the UI. It checks again in the worker thread
to prevent any race from happening if a profile is added twice quickly.
Either the file exists, or it doesn't.
Additionally, this change solves the race condition when the old
profile is removed before it is updated; previously this would lead
to the profile being re-added. Now, ProfileRemover will fail and the
profile will stay removed.
Finally, updating a profile's name should now work correctly. There were
previously multiple bugs with that (the old profile wasn't removed, the
new one could duplicate a name, the new one could overwrite some random
other one, etc.).
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This allows retrieving the public key and generating keypairs, both of
which will be exposed in the UI.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
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 is a simple, naive implementation that {,de}serializes the
profile's state, but it does not depend on the internal representation
of Profile or its contained classes.
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>
This parser should be able to handle any valid WireGuard or wg-quick
configuration file. It separates the file into a single interface object
and a peer object for each peer. All "[Interface]" sections in the file
are combined into the one object.
For now, later lines in a block with the same key overwrite earlier
lines. This is only relevant for attributes that are lists, such as
Address and AllowedIPs, where additional lines may be expected to append
to the list.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
