UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

Pushing a view without Navigation View Swift UI

Forums > SwiftUI

Hey guys. I'd like to push the view without a Navigation View. I dont want the next view to have that possibility to go back.

I've build some viewModel I do wonder how can I use it throughout this operation.

Thanks!

4      

Try using .navigationBarHidden(true)

struct ContentView: View {
    var body: some View {
        NavigationView {
            NavigationLink(destination: FirstView()) {
                Text("To First View")
                    .padding()
            }
            .navigationTitle("Home")
        }
    }
}

struct FirstView: View {
    var body: some View {
        VStack {
            Text("First View")
        }
        .navigationBarHidden(true) // Use to hide back button
    }
}

3      

Have an upper-most (or outer-most) view that checks some environment state and loads the appropriate view. I'll post some succinct-as-possible code here.

First, create some object to be held as an @EnvironmentObject that goes into the environment in @main, and show your main view, which is basically just a switch block for what to show in its confines. I don't like to junk up the @main file.


import SwiftUI

enum CurrView:Int {
    case welcome
    case signin
    case signup
    case home
    case settings
}

class OpDat : ObservableObject {
    @Published var currView = CurrView.home
}

@main
struct mykillerapp: App {
    private var opDat = OpDat()

    init(){

    }

    var body: some Scene {
        WindowGroup {
            MainView()
                .environmentObject(opDat)
        }
    }
}

Main view is where all the which-view-to-show dispatching happens.


import SwiftUI

struct MainView: View {

    @EnvironmentObject var opData:OpData

    var body: some View {
        switch(opData.currentView){
        case .welcome:
            WelcomeView()
                .environmentObject(opData)

        case .signin:
            SigninView()
                .environmentObject(opData)

        case .signup:
            SignupView()
                .environmentObject(opData)

        case .home:
            HomeView()
                .environmentObject(opData)

        case .settings:
            SettingsView()
                .environmentObject(opData)

        }
    }
}

Then whenver you want to switch views without getting mucked up in stack based navigation, just grab your opDat reference and change the current view.

func tappedSignin() {
    viewModel.resetErrors()
    viewModel.doSignin { success, error in
        if success {
            opData.currentView = .home
        }
    }
}

That triggers a redraw in MainView, reads the switch again, selects the appropriate view, and whammo, blammo, bob is still your uncle.

Doing this, you're still free to use NavigationView in any of the "top level" views like Settings or Home, etc., and still throw that whole stack away when it's time to navigate to another "top level" view. I use this model in pretty much every app.

6      

Simple answer:

.navigationBarBackButtonHidden(true)

implemented in the body of the SubView like this:

struct SubView: View {
    var body: some View {
        VStack {
            Text("SubView")
        }
        // hides only the back button, not the entire bar
        .navigationBarBackButtonHidden(true) 
    }
}

Enjoy :-)

@chornbe answer is quite interesting. It is a sort of:

"How to navigate between Views without NavigationView"

My only concern is that you'll loose the structure and funcionality provided by NavigationView, and you MUST be very organized otherwise you will loose yourself (particulary in large projects)

I am curious about: viewModel.resetErrors() and would appreciate if @chornbe could elaborate. What kind of errors are expected to occur and why do you need to reset? Thx

2      

Oh, that resetErrors function is just to clear any indicators I gave the user about missing or incorrect data. Sorry, it's outside the scope of this discussion and I probably should have chopped it out.

I use this navigation method in conjunction with the NavigationView model where it makes sense.

I look at most apps using only navigationView and I generally think that if you visualize them as walking paths, it rarely makes sense for everything to be just on one long winding path, and perhaps you see in front of you several doorways. One for Settings, one for data entry, one for journal viewing, etc (as abstract examples). Then each of those doorways might have a path (navigation stack) behind it, and you can just clear out and jump to another path, giving memory and resources to be cleaned up while you're off doing other things, and without 93 taps in the top left corner to always get back to home base before going off on another path.

In short, I find navigationview to be quirky and annoying, and requiring too much boilerplate (a la hiding the bar when it's not in the best interest of user experience) for simple things. I'd rather build UP those features than always having to tear them down. I'd go opposite on a number of defaults in UX were Apple to get wise and finally bring me on staff. ;) (Don't get me started on how much cruft I'd change, strip out, or light on fire in Flutter) :D

As for being very orgaized, IMO, that's as fundamental and foundational to being a developer as you can get. In fact, I'd say that the skill of "good coding" is probably the last thing or the least impactful thing on the list of requisite skills. I find that being an outstanding diagnostician and logicists analyst are far more important, and have led me in a ~35 year very fruitful career in software development (and IT writ large). :)

2      

Hacking with Swift is sponsored by RevenueCat

SPONSORED Take the pain out of configuring and testing your paywalls. RevenueCat's Paywalls allow you to remotely configure your entire paywall view without any code changes or app updates.

Learn more here

Sponsor Hacking with Swift and reach the world's largest Swift community!

Archived topic

This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.

All interactions here are governed by our code of conduct.

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.