At module creation time, choose whether to use a provider or import a
configuration file. After the import, the provider picker is hidden for
mutual exclusion.
For clarity, refactor the configuration part of OpenVPNView into a
ConfigurationView subview.
Also, improve filters by constraining related fields:
- Pick countries from the filtered category
- Pick presets from those available in the currently filtered servers
Closes#705
- iOS: Add category name to clarify servers context
- iOS: Show "No servers" when list is empty
- macOS: Show "Connect" in server selector when presenting from home
- Add last update to issue report
- Refactor provider strings
First of all, add country flags assets. Then, present provider server
selector:
- From installed profile view, specifically from a button with the flag
of the current country
- From profile context menu
- On toggle profile when no server is selected
Closes#711
A NavigationLink in VPNProviderContentModifier raised a few questions
about the navigation approach in module views. It turned out that having
a Binding to a local ObservedObject (ProfileEditor) is a recipe for
disaster.
Therefore:
- We don't need a binding to the editor module (the draft), because by
doing so we end up _observing_ the same changes from two properties, the
binding and the editor. This seems to drive SwiftUI crazy and freezes
the app once we navigate from the module to another view (e.g. in
OpenVPN the credentials or the provider server). Use the module binding
as a shortcut, but do not assign the binding to the view to avoid
unnecessary observation.
- Keep .navigationDestination() in the module view, and pass a known
destination to VPNProviderContentModifier. This will save the modifier
from creating a nested NavigationLink destination. The
VPNProviderServerView is now openly instantiated by the module view when
such destination is triggered by the NavigationLink in the modifier.
- Do not implicitly dismiss VPNProviderServerView on selection, let the
presenter take care. In order to do so, we add a .navigationPath
environment key through which the module view can modify the current
navigation stack.
- Move disclosable menu from installed profile view to
ThemeDisclosableMenu
- Drop unnecessary configurationType modifier parameter
- Reorg view-related module extensions to separate files
- Reuse .flow fields instead of single blocks
- Show specific error on missing provider server selection
- Drop logic behind connection button tasks, let the library handle
concurrency
- Drop AppContext observation of saved profiles for reconnection, let
save() actively decide
- NETunnelStrategy and NETunnelManagerRepository are now a single entity
- Avoid flickering when toggling same profile
Currently, NEProfileRepository decodes profiles from ALL NE managers on
any update. This is undesirable considering that:
- Profiles are only _added_ by the app
- Externally, profiles can only be _removed_
Therefore:
- Observe the initial managers to decode the initial profiles from them
- Publish values manually on save/delete (to ProfileManager eventually)
- Observe the subsequent updates for when a profile is removed
externally, i.e. its ID doesn't appear in managers
Fixes#741
Resolve some flickering and state inconsistency due to overextended
observation of VPNProviderManager. Narrow down its scope to
VPNProviderServerView.
The downside of that, for now, is that servers are loaded "lazily late",
but this flow will make region selection from home easier.
Finally, show filters in popover on iPad.
Improve rendering and work around some SwiftUI bugs, e.g. with .menu
Picker on iOS (use .navigationLink instead).
Here goes the hierarchy bottom-up:
- ProviderPicker: a Picker wrapper built around ProviderManager
- ProviderContentModifier: adds a ProviderPicker on top and replaces the
content with a set of provider selectors when a provider is selected
- VPNProviderContentModifier: wrapper for ProviderContentModifier that
adds a VPN server selector
- OpenVPNView: provides a view of specific OpenVPN settings, and adds a
credentials selector to the provider/server selectors provided by
VPNProviderContentModifier
When e.g. a OpenVPNModule is created without a configuration and a
provider/server is then selected, the ProfileProcessor class serializes
the profile with the provider configuration injected. When the module is
re-edited, we can see the provider server configuration in the module
after selecting "None" as provider.
Instead, validate the provider modules in ProfileProcessor, but generate the provider configuration on the fly in the tunnel.
Update library to allow optional VPN configurations. This in turn allows
a module to be used with a provider, where the configuration is
generated on the fly.
Davide