Age | Commit message (Collapse) | Author |
|
This works much better with a data-bound UI -- no confusing erasing of
the text box, and no crashes, either!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Highlight the selected configuration, and add a border between the two
panes.
|
|
This will be used for future sorting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was accidentally missed earlier when adding the optimization to
omit binding the service when unnecessary.
|
|
It will be reused for entering public keys of peers.
|
|
|
|
|
|
|
|
It may share the layout with a FAB, and that requires a parent
ViewGroup.
|
|
|
|
|
|
|
|
|
|
Apparently "configuration" is the proper term, not "profile".
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|