passepartoutvpn/passepartout-apple
1
0
Fork 0
mirror of https://github.com/passepartoutvpn/passepartout-apple.git synced 2024-12-24 02:21:00 +00:00
Code Issues Packages Projects Releases Wiki Activity
bad9e8b58e
passepartout-apple/Passepartout/Library/Sources/UILibrary/Protocols/ProviderEntityViewProviding.swift

40 lines
1.3 KiB
Swift
Raw Normal View History

Avoid nested module navigation (#749) 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.
2024-10-23 13:42:54 +00:00
//
Refactor AppUI for TV target (#775) Split AppUI into AppUI and AppUIMain to allow for a new, simplified AppUITV target tailored for the Apple TV. As a PoC, present a view with a list of the shared profiles.
2024-10-29 13:30:41 +00:00
// ProviderEntityViewProviding.swift
Avoid nested module navigation (#749) 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.
2024-10-23 13:42:54 +00:00
// Passepartout
//
Refactor AppUI for TV target (#775) Split AppUI into AppUI and AppUIMain to allow for a new, simplified AppUITV target tailored for the Apple TV. As a PoC, present a view with a list of the shared profiles.
2024-10-29 13:30:41 +00:00
// Created by Davide De Rosa on 10/16/24.
Avoid nested module navigation (#749) 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.
2024-10-23 13:42:54 +00:00
// Copyright (c) 2024 Davide De Rosa. All rights reserved.
//
// https://github.com/passepartoutvpn
//
// This file is part of Passepartout.
//
// Passepartout is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// Passepartout is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with Passepartout. If not, see <http://www.gnu.org/licenses/>.
//
Late dismissal after changing active provider server (#804) The dismissal action waited until the current connection was disconnected. Consider that AppContext makes the explicit .connect() redundant, reconnection is already happening after saving a profile while connected.
2024-11-03 10:12:19 +00:00
import CommonUtils
Avoid nested module navigation (#749) 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.
2024-10-23 13:42:54 +00:00
import PassepartoutKit
import SwiftUI
Rearrange targets for unit testing (#900) - Move and rename entities - Split protocols and default extensions - Move in-app entities to CommonIAP target
2024-11-20 17:05:47 +00:00
public protocol ProviderEntityViewProviding {
Refactor AppUI for TV target (#775) Split AppUI into AppUI and AppUIMain to allow for a new, simplified AppUITV target tailored for the Apple TV. As a PoC, present a view with a list of the shared profiles.
2024-10-29 13:30:41 +00:00
associatedtype EntityContent: View
Avoid nested module navigation (#749) 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.
2024-10-23 13:42:54 +00:00
@MainActor
Refactor AppUI for TV target (#775) Split AppUI into AppUI and AppUIMain to allow for a new, simplified AppUITV target tailored for the Apple TV. As a PoC, present a view with a list of the shared profiles.
2024-10-29 13:30:41 +00:00
func providerEntityView(
Update library with provider in modules (#887) Move provider metadata from profile to module.
2024-11-17 21:27:02 +00:00
with provider: SerializedProvider,
Late dismissal after changing active provider server (#804) The dismissal action waited until the current connection was disconnected. Consider that AppContext makes the explicit .connect() redundant, reconnection is already happening after saving a profile while connected.
2024-11-03 10:12:19 +00:00
errorHandler: ErrorHandler,
Refactor AppUI for TV target (#775) Split AppUI into AppUI and AppUIMain to allow for a new, simplified AppUITV target tailored for the Apple TV. As a PoC, present a view with a list of the shared profiles.
2024-10-29 13:30:41 +00:00
onSelect: @escaping (any ProviderEntity & Encodable) async throws -> Void
) -> EntityContent
Avoid nested module navigation (#749) 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.
2024-10-23 13:42:54 +00:00
}
Reference in New Issue Copy Permalink