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

Project 8 Challenge 3: Any Caveats Not Following the Exact Guidance?

Forums > 100 Days of SwiftUI

For example, this works:

GridView is more or less the same thing as ListView. They are two separate SwiftUI View files created.

What's interesting is I can only put ScrollView above LazyVGrid since List automatically comes with a scroll function. If I wrap List inside ScrollView, it doesn't appear in the UI.

I did not pass in the astronaut and mission parameters like Paul said in the hints. Why would you want to create two separate structs and pass in parameters? If seems like extra trouble to go through, or am I missing something here?

ContentView

import SwiftUI

// with an extension on Bundle, that's all it takes to get a [String: Astronaut] dictionary.
// add a Type Annotation to let Swift know what type our return will be
let astronauts: [String: Astronaut] = Bundle.main.decode("astronauts.json")
let missions: [Mission] = Bundle.main.decode("missions.json")

struct ContentView: View {
    @State private var showingGrid = true

    var body: some View {
        NavigationView {
            Group {
                if showingGrid {
                    ScrollView {
                        GridView()
                    }
                }
                else {
                    ListView()
                }
            }
            .toolbar {
                Toggle("Change View Style", isOn: $showingGrid)
                    .toggleStyle(.button)
            }
        }
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

ListView

struct ListView: View {

    var body: some View {
        List {
            ForEach(missions) { mission in
                NavigationLink {
                    MissionView(mission: mission, astronauts: astronauts)
                } label: {
                    VStack {
                        Image(mission.image)
                            .resizable()
                            .scaledToFit()
                            .frame(width: 100, height: 100)
                            .padding()
                        VStack {
                            Text(mission.displayName).font(.headline)
                                .font(.headline)
                                .foregroundColor(.white)
                            Text(mission.formattedLaunchDate).font(.headline).font(.caption)
                                .font(.caption)
                                .foregroundColor(.white.opacity(0.5))
                        }
                        .padding(.vertical)
                        .frame(maxWidth: .infinity)
                        .background(.lightBackground)
                    }
                    .clipShape(RoundedRectangle(cornerRadius: 10))
                    .overlay(RoundedRectangle(cornerRadius: 10).stroke(.lightBackground))
                }
            }
        }
        .listStyle(.grouped)
        .listRowBackground(Color.darkBackground)
        .preferredColorScheme(.dark)
        .navigationTitle("Moonshot")
    }
}

2      

I think it is worthwhile keeping variables within a struct/class that makes most sense to "own" the variable. It's definitely extra code and doesn't seem worth it for small apps; but as the code grows and the complexity increases it can make a big difference with trying to fix problems and understand the impact of making changes.

Organising functionality and data so they are "inside" other code and data is used all over the place in almost all modern programming languages. When we create functions for a struct/class we are helping ourselves understand our code by grouping things together. When we put variables inside a struct/class we are doing the same thing.

When we organise our code inside structs/classes/enums we get the added benefit of being able to say what other code can see/use that code: the private keyword is an example of telling Swift that only the struct/class/enum that the code is contained in can see/use it. Once again, this is mostly beneficial when code grows and is complex.

IMHO even though this way of organising code is really only beneficial when code gets big I think it is a good idea to get in the habit of this kind of code structure - after all, don't we all want to be skilled enough to someday create big, complex code

3      

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.