Step 1: Defining the Recipe Model

Setup a Recipe model that represents a dish with a name, cooking time, and ingredients.

import Foundation
import SwiftData

@Model
class Recipe {

    @Attribute(.unique) var id: UUID
    var name: String?
    var cookingTime: Int // in minutes
    var ingredients: [String]

    init(id: UUID = UUID(), name: String? = nil, cookingTime: Int, ingredients: [String]) {
        self.id = id
        self.name = name
        self.cookingTime = cookingTime
        self.ingredients = ingredients
    }
}

This model defines each recipe with a unique ID, name, cooking time, and a list of ingredients. With this setup, you can now store recipes in SwiftData and use them in your app.

Step 2: Creating Sample Data for Previews

Now, let’s generate sample data using ModelContainer. You’ve written a method to insert sample recipes into a ModelContainer for use in previews.

import Foundation
import SwiftData

let sampleRecipes = [
    Recipe(name: "Spaghetti Bolognese", cookingTime: 45, ingredients: ["Spaghetti", "Minced Beef", "Tomato Sauce"]),
    Recipe(name: "Grilled Cheese Sandwich", cookingTime: 10, ingredients: ["Bread", "Cheese", "Butter"]),
    Recipe(name: "Beef Wellington", cookingTime: 120, ingredients: ["Beef Tenderloin", "Puff Pastry", "Mushrooms", "Dijon Mustard"])
]

extension Recipe {
    @MainActor static func makeSampleRecipes(in container: ModelContainer) {
        
        let context = container.mainContext
        
        // Check if there are any existing recipes in the database
           let existingRecipesCount = (try? context.fetch(FetchDescriptor()))?.count ?? 0
           guard existingRecipesCount == 0 else {
               // If there are existing recipes, do not create new ones
               return
           }
           
           // Sample data to create
           let recipes = [
               Recipe(name: "Spaghetti Bolognese", cookingTime: 45, ingredients: ["Spaghetti", "Minced Beef", "Tomato Sauce"]),
               Recipe(name: "Grilled Cheese Sandwich", cookingTime: 10, ingredients: ["Bread", "Cheese", "Butter"]),
               Recipe(name: "Beef Wellington", cookingTime: 120, ingredients: ["Beef Tenderloin", "Puff Pastry", "Mushrooms", "Dijon Mustard"])
           ]
           
           // Insert the sample recipes into the context
           for recipe in recipes {
               context.insert(recipe)
           }
           
           // Save the context to persist the new data
           try? context.save()
        
    }
}

This method defines three recipes and inserts them into the ModelContainer. The @MainActor annotation ensures this method runs on the main thread, which is essential for interacting with SwiftData.

Step 3: Implementing the RecipeSampleData for Previews

The RecipeSampleData structure serves as a PreviewModifier to create in-memory sample data. This makes it easy to display recipes in SwiftUI previews.

import SwiftUI
import SwiftData

struct RecipeSampleData: PreviewModifier {
    static func makeSharedContext() throws -> ModelContainer {
        let config = ModelConfiguration(isStoredInMemoryOnly: true)
        let container = try ModelContainer(for: Recipe.self, configurations: config)
        Recipe.makeSampleRecipes(in: container) // Load sample recipes
        return container
    }
    
    func body(content: Content, context: ModelContainer) -> some View {
        content.modelContainer(context)
    }
}

extension PreviewTrait where T == Preview.ViewTraits {
    @MainActor static var sampleRecipeData: Self = .modifier(RecipeSampleData())
}

This modifier creates a ModelContainer configured for in-memory storage. The makeSampleRecipes method loads sample recipes into the container, and the modifier applies this data to any view using the .modelContainer() modifier.

Step 4: Creating Recipe Views with Sample Data

Now let’s integrate this sample data into a few SwiftUI views.

Recipe List View

The RecipeListView displays a list of recipes loaded from SwiftData. The @Query property wrapper retrieves the recipes, and the list is built dynamically.

import SwiftUI
import SwiftData

struct RecipeListView: View {
    @Query private var recipies: [Recipe]
    @Environment(\.modelContext) private var context
    
    var body: some View {
       
        List {
            ForEach(recipies) { recipe in
              
                VStack(alignment: .leading) {
                    Text(recipe.name ?? "")
                           .font(.headline)
                       Text("Cooking Time: \(recipe.cookingTime) mins")
                           .font(.subheadline)
                   }
            }
        } .task {
            
               Recipe.makeSampleRecipes(in: context.container)
        }
    }
}

#Preview(traits: .sampleRecipeData) {
    RecipeListView()
}

In this example, the @Query property wrapper retrieves all Recipe objects from the ModelContainer, which are then displayed in a List using SwiftUI. The preview uses .sampleRecipeData to load in-memory recipes for testing the UI.

Recipe Detail View

For more detailed recipe information, the RecipeDetailView displays the name, cooking time, and ingredients of a single recipe. This view doesn’t query for data but accepts a Recipe object as a parameter.

import SwiftUI
import SwiftData

struct RecipeDetailView: View {
    let recipe: Recipe

    var body: some View {
        VStack(alignment: .leading, spacing: 10) {
            Text(recipe.name ?? "No Name")
                .font(.largeTitle)
            Text("Cooking Time: \(recipe.cookingTime) mins")
                .padding(.bottom)
            Text("Ingredients:")
            ForEach(recipe.ingredients, id: \.self) { ingredient in
                Text(ingredient)
            }
        }
        .padding()
    }
}

#Preview(traits: .sampleRecipeData) {
    @Previewable @Query var recipes: [Recipe]  // Query sample recipes
    RecipeDetailView(recipe: recipes.first!)
}

In this view, the recipe’s details are displayed, including the name, cooking time, and ingredients. The preview fetches the first recipe from the sample data.

Step 5

Now let’s connect our ListView with a DetailView using a NavigationLink inside a NavigationStack

import SwiftUI
import SwiftData

struct RecipeListView: View {
    @Query private var recipies: [Recipe]
    @Environment(\.modelContext) private var context
    
    var body: some View {
       
        NavigationStack {
            List {
                ForEach(recipies) { recipe in
                    NavigationLink(destination: RecipeDetailView(recipe: recipe)) {
                        
                        // Recipe Row
                        VStack(alignment: .leading) {
                            Text(recipe.name ?? "")
                                .font(.headline)
                            Text("Cooking Time: \(recipe.cookingTime) mins")
                                .font(.subheadline)
                        }
                    }
                }
            } .task {
                
                Recipe.makeSampleRecipes(in: context.container)
                
            }
        }
    }
}

#Preview(traits: .sampleRecipeData) {
    RecipeListView()
}

Key Differences Between Preview and @Previewable

1. Preview with Traits (.sampleRecipeData):
   • Best for views that query data using SwiftData.
   • Automatically loads sample data into the view’s query and binds it to the UI.
   • No need to manually pass data; the query handles it for you.
2. @Previewable:
   • Best for views that rely on models passed in as parameters (e.g., detail views).
   • Allows you to create sample data and pass it directly to the view.
   • You have full control over what specific data is provided for the preview.

Conclusion

By using SampleData and the @Previewable macro, you can easily preview recipe data within your SwiftUI views. Whether you’re working with data that relies on queries or views that require individual models, SwiftData provides an efficient way to prototype and test your app in Xcode.

The post Learn how to work with Xcode Previews in SwiftData App appeared first on AppMakers.Dev.

Basic Usage: Copying Text to Clipboard

Let’s start with a basic example where we copy a text string to the clipboard when a button is pressed.

Example: Copying Text to Clipboard

import SwiftUI

struct CopyTextView: View {
    @State private var textToCopy = "Hello, SwiftUI!"
    @State private var message = "Tap the button to copy text"

    var body: some View {
        VStack(spacing: 20) {
            Text(message)
                .padding()

            Text(textToCopy)
                .padding()
                .background(Color.gray.opacity(0.2))
                .cornerRadius(10)

            Button(action: {
                UIPasteboard.general.string = textToCopy
                message = "Text copied to clipboard!"
            }) {
                Text("Copy Text")
                    .padding()
                    .background(Color.blue)
                    .foregroundColor(.white)
                    .cornerRadius(10)
            }
        }
        .padding()
    }
}

In this example:

1. We define a @State variable textToCopy that holds the text we want to copy.
2. Another @State variable message is used to display the status message.
3. When the button is pressed, the text is copied to the clipboard using UIPasteboard.general.string.

Combining Copy and Paste Functionality

Let’s combine the copy and paste functionality into a single view.

Example: Copy and Paste Text

import SwiftUI

struct CopyPasteTextView: View {
    @State private var textToCopy = "Hello, SwiftUI!"
    @State private var pastedText = "Tap 'Paste' to see clipboard text"

    var body: some View {
        VStack(spacing: 20) {
            Text("Text to Copy:")
            Text(textToCopy)
                .padding()
                .background(Color.gray.opacity(0.2))
                .cornerRadius(10)

            Button(action: {
                UIPasteboard.general.string = textToCopy
            }) {
                Text("Copy Text")
                    .padding()
                    .background(Color.blue)
                    .foregroundColor(.white)
                    .cornerRadius(10)
            }

            Divider()

            Text("Pasted Text:")
            Text(pastedText)
                .padding()
                .background(Color.gray.opacity(0.2))
                .cornerRadius(10)

            Button(action: {
                if let text = UIPasteboard.general.string {
                    pastedText = text
                } else {
                    pastedText = "No text found in clipboard"
                }
            }) {
                Text("Paste Text")
                    .padding()
                    .background(Color.green)
                    .foregroundColor(.white)
                    .cornerRadius(10)
            }
        }
        .padding()
    }
}

In this example:

1. We define two @State variables textToCopy and pastedText.
2. The “Copy Text” button copies textToCopy to the clipboard.
3. The “Paste Text” button retrieves and displays text from the clipboard in the pastedText variable.

Conclusion

Using the clipboard in SwiftUI is straightforward and enhances the interactivity of your app. By understanding how to copy and paste text, you can create more user-friendly interfaces.

The post Clipboard – Copy and Paste in SwiftUI appeared first on AppMakers.Dev.

Conceptual Overview

@Bindable: Introduced in more recent updates to SwiftUI, @Bindable is used for creating bindings directly to properties of observable objects. It is particularly useful when multiple views need to interact with the same piece of data.

@State: This is one of the original property wrappers in SwiftUI used for declaring state within a single view. It is ideal for data that is local to that specific view and doesn’t need to be shared across different parts of the app.

Unified Example: User Preferences Settings View

We’ll consider a settings page where users can adjust preferences like enabling dark mode and setting a username. This example will illustrate how @Bindable and @State could be used to manage these preferences.

The Model: UserPreferences

First, let’s define our observable object model that stores user preferences:

@Observable
class UserPreferences {
    var isDarkMode: Bool = false
    var username: String = "User"
}

Scenario 1: Using @Bindable

Let’s say the UserPreferences object needs to be accessed and modified across multiple views within the app.

struct SettingsViewBindable: View {
    @Bindable var preferences: UserPreferences

    var body: some View {
        Form {
            Toggle("Enable Dark Mode", isOn: $preferences.isDarkMode)
            TextField("Username", text: $preferences.username)
        }
    }
}

Here, @Bindable allows SettingsViewBindable to directly bind UI elements to properties of UserPreferences. Any changes made in this view will update the model and reflect across other views using the same model, ensuring consistency.

Scenario 2: Using @State

Now, consider a simplified scenario where each setting is managed locally within the view, without the need for external synchronization.

struct SettingsViewState: View {
    @State private var isDarkMode: Bool = false
    @State private var username: String = "User"

    var body: some View {
        Form {
            Toggle("Enable Dark Mode", isOn: $isDarkMode)
            TextField("Username", text: $username)
        }
    }
}

In SettingsViewState, @State is used because the data does not need to be shared or synced with other parts of the app. Each setting is managed locally within the view, making @State ideal for this encapsulated data handling.

Key Differences Explained

• Data Sharing: Use @Bindable when the state needs to be shared or observed by multiple components. It helps maintain synchronization across different parts of the app. On the other hand, @State is perfect for data that is used and modified within a single view without the need for external access.
• Complexity and Scope: @Bindable is beneficial in more complex app architectures where data flow and consistency across multiple views are critical. @State is simpler and more straightforward for handling state that is contained within individual components.

Conclusion

Choosing between @Bindable and @State depends on the scope of your data and how it interacts within your app’s architecture. For shared, observable data that affects multiple views, @Bindable provides a robust solution. For localized, view-specific data, @State offers a simpler, more encapsulated approach. By understanding these distinctions, you can better design your app’s data flow, ensuring that it is both efficient and easy to manage.

The post @Bindable versus @State in SwiftUI appeared first on AppMakers.Dev.

Overview of @Observable in SwiftUI

@Observable enables SwiftUI views to react to changes in data models by updating the UI automatically. This implementation follows the observer design pattern, which allows objects to be notified of changes in another object without tight coupling between them.

Step-by-Step Tutorial: Creating a Dynamic Weather Dashboard

Let’s build a simple weather app that updates its display based on changes to weather data.

Step 1: Define the Weather Data Model

First, we’ll define a WeatherData class that will hold temperature, humidity, and weather condition information. We’ll make this class observable using @Observable.

import SwiftUI

@Observable
class WeatherData {
    var temperature: Double = 75.0
    var humidity: Double = 50.0
    var condition: String = "Sunny"
    
    init(temperature: Double, humidity: Double, condition: String) {
        self.temperature = temperature
        self.humidity = humidity
        self.condition = condition
    }
}

Step 2: Create the Weather View

Now, we’ll create a WeatherView that displays the temperature, humidity, and current weather condition. It will update these values whenever they change in the WeatherData object.

struct WeatherView: View {
    @Bindable var weatherData: WeatherData

    var body: some View {
        VStack {
            Text("Current Temperature: \(weatherData.temperature)° F")
            Text("Humidity: \(weatherData.humidity)%")
            Text("Condition: \(weatherData.condition)")
            Button("Refresh Weather") {
                // Simulate receiving new weather data
                weatherData.temperature = Double.random(in: 70...80)
                weatherData.humidity = Double.random(in: 40...60)
                weatherData.condition = ["Rainy", "Sunny", "Cloudy"].randomElement()!
            }
        }
        .padding()
        .background(Color.blue)
        .foregroundColor(.white)
        .clipShape(RoundedRectangle(cornerRadius: 10))
    }
}

Step 3: Integrate Weather Data in App View

Finally, integrate the WeatherData and WeatherView into the main content view of the app.

struct ContentView: View {
    var weatherData = WeatherData(temperature: 75, humidity: 50, condition: "Sunny")

    var body: some View {
        WeatherView(weatherData: weatherData)
    }
}

Conclusion

This example shows how to use @Observable in SwiftUI to build an app that responds dynamically to changes in its data model. The WeatherView updates automatically as the WeatherData changes, demonstrating a practical application of the observer design pattern without tight coupling between UI components and the data model. By using @Observable, developers can ensure their apps remain responsive and the UI consistently reflects the current state of the application data.

The post Observable protocol in SwiftUI appeared first on AppMakers.Dev.

Understanding @StateObject: Managing Complex, Persistent Data

@StateObject is used to instantiate and manage the lifecycle of an observable object that owns significant data or logic that persists for the lifetime of the view. It’s best used when the data model needs to persist and be shared across multiple views or when the data model performs tasks that affect the app state globally.

Example: TodoList Manager

Consider a simple todo list manager where tasks can be added, and each task has a completed state.

import SwiftUI

@Observable
class TaskManager: Observable {
   var tasks: [String] = []
}

struct TaskListView: View {
    @StateObject private var taskManager = TaskManager()

    var body: some View {
        List {
            ForEach(taskManager.tasks, id: \.self) { task in
                Text(task)
            }
            Button("Add Task") {
                taskManager.tasks.append("Task \(taskManager.tasks.count + 1)")
            }
        }
    }
}

Here, TaskManager is an observable object that manages our tasks. @StateObject is used to instantiate it in TaskListView, ensuring that it stays alive and updates the view as tasks are added.

Understanding @State: For Transient, Local View Data

@State is a property wrapper designed for simpler, view-specific state management. It is ideal for transient data that only exists for the life of the view and does not need to be shared across different parts of the app.

Example: Simple Counter

Let’s implement a simple counter that increments when a button is tapped, demonstrating @State.

struct CounterView: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Text("Count: \(count)")
            Button("Increment") {
                count += 1
            }
        }
    }
}

In this example, count is a simple integer managed by @State. It’s perfect for @State as it’s specific to CounterView and doesn’t need to be shared with other parts of the app.

Choosing Between @StateObject and @State

• Use @StateObject for managing complex data models that need to persist beyond the view, are shared among multiple views, or have business logic.
• Use @State for simple, ephemeral state that is contained within a single view and does not influence other parts of your app.

When to use @Bindable instead of using State and StateObject

In cases where a view requires a direct binding to a property of an Observable object within its content, it’s advisable to employ the @Bindable property wrapper. This would typically be declared as @Bindable var model: DataModel within your view. Adopting @Bindable is in line with SwiftUI’s principles for data flow, promoting a more streamlined and robust implementation. This method reduces complications and enhances the integrity of the data interactions within your SwiftUI application

Summary

@State and @StateObject are powerful tools in SwiftUI for state management, tailored for different use cases @State for lightweight, view-local states, and @StateObject for more substantial, persistent data models. By understanding and utilizing these appropriately, you can ensure that your SwiftUI applications are both efficient and easy to manage.

The post State and StateObject in SwiftUI appeared first on AppMakers.Dev.

• Usage Example: If you have a settings screen where toggles reflect and control settings stored in the main app environment, @Binding lets you modify those settings directly from the toggles.

Bindable – is a property wrapper that simplifies the process of creating two-way bindings directly to properties of observable objects. It’s used to bind UI components directly to the properties of a model that conforms to theObservable protocol, enabling straightforward management of model updates from the UI.

• Usage Example: In a form where you need to edit a user profile with fields like name and email, @Bindable allows the text fields to bind directly to the UserProfile object’s properties, making the code cleaner and more manageable.

In essence, while @Binding acts as a reference to link UI components to data managed elsewhere, @Bindable provides a more direct and less verbose way to bind UI components to observable object properties.

Example Setup

Suppose we have a simple data model for a user profile that we want to display and edit in different views.

User Profile Model

import SwiftUI

@Observable
class UserProfile {
    var name: String
    init(name: String) {
        self.name = name
    }
}

Using @Binding

First, we’ll use @Binding to create a child view that can edit the name in the UserProfile.

struct ProfileEditorBinding: View {
    @Binding var name: String

    var body: some View {
        TextField("Enter name", text: $name)
            .padding()
            .border(Color.gray)
    }
}

struct ParentViewBinding: View {
    @State var userProfile = UserProfile(name: "John Doe")

    var body: some View {
        VStack {
            Text("Profile name: \(userProfile.name)")
            ProfileEditorBinding(name: $userProfile.name)
        }
    }
}

Here, ProfileEditorBinding does not own the name data; it merely binds to it, allowing for changes that reflect back in the ParentViewBinding.

Using @Bindable

Next, we’ll use @Bindable in a similar setup but with a slightly different approach:

struct ProfileEditorBindable: View {
    @Bindable var userProfile: UserProfile

    var body: some View {
        TextField("Enter name", text: $userProfile.name)
            .padding()
            .border(Color.gray)
    }
}

struct ParentViewBindable: View {
    @StateObject var userProfile = UserProfile(name: "Jane Doe")

    var body: some View {
        VStack {
            Text("Profile name: \(userProfile.name)")
            ProfileEditorBindable(userProfile: userProfile)
        }
    }
}

In this case, ProfileEditorBindable uses @Bindable to create a more direct and intuitive binding to the entire UserProfile object. The view can bind directly to the properties of userProfile, simplifying how data flows between the UI elements and the data model.

Key Differences Demonstrated

• @Binding: Best for when you need to share a specific piece of data between views without ownership, keeping views synchronized with a source of truth defined elsewhere.
• @Bindable: Useful for more direct interaction with multiple properties of an observable object, streamlining how properties are updated from the UI, especially when those properties are used across different views.

s
dfsdf

The post Differences between @Binding and @Bindable in SwiftUI appeared first on AppMakers.Dev.

In SwiftUI, @Bindable is a property wrapper designed to create two-way bindings between UI components and observable objects. This allows for real-time UI interactions that reflect changes in the underlying data model, ensuring your views stay updated and interactive.

Step 1: Setting Up the Observable Object

First, we define a TimerManager class, which will keep track of time in our example, showcasing a timer functionality that users can start or stop.

import SwiftUI

@Observable
class TimerManager: ObservableObject {
    var time = 0
    var timer: Timer?
    var isRunning = false
    
    func start() {
        isRunning = true
        timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { _ in
            self.time += 1
        }
    }
    
    func stop() {
        isRunning = false
        timer?.invalidate()
        timer = nil
    }
}

Step 2: Creating the Timer Control View

We’ll build a TimerView that uses @Bindable to interact with the TimerManager object for starting and stopping the timer.

struct TimerView: View {
    @Bindable var timerManager: TimerManager

    var body: some View {
        VStack {
            Text("Time: \(timerManager.time)")
            Button(timerManager.isRunning ? "Stop" : "Start") {
                if timerManager.isRunning {
                    timerManager.stop()
                } else {
                    timerManager.start()
                }
            }
        }
    }
}

Step 3: Implementing in ContentView

In ContentView, we instantiate TimerManager and pass it to TimerView. This demonstrates the real-time interaction with the TimerManager through the UI.

struct ContentView: View {
    var timerManager = TimerManager()

    var body: some View {
        TimerView(timerManager: timerManager)
    }
}

Conclusion

This example illustrates the power of @Bindable in creating highly interactive and responsive UIs in SwiftUI. By binding UI components directly to observable object properties, @Bindable ensures that the UI stays consistent with the application state, providing an intuitive and responsive user experience. This approach simplifies state management in SwiftUI, reducing boilerplate and enhancing code readability and maintainability.

Exploring @Bindable Further

To deepen your understanding of @Bindable, consider experimenting by adding more functionality to the TimerManager, such as resetting the timer or adding lap functionalities. This will give you hands-on experience with @Bindable and its potential to facilitate complex data interactions in SwiftUI.

The post Simplifying SwiftUI Data Bindings with @Bindable appeared first on AppMakers.Dev.

Understanding @State with a Simple Toggle Example

@State is pivotal for managing local state within a SwiftUI view—it’s the view’s private data storage. Here’s a straightforward example where we use @State to control the on/off state of a light.

struct LightSwitchView: View {
    @State private var isLightOn = false

    var body: some View {
        VStack {
            Text(isLightOn ? "The light is On" : "The light is Off")
            Button("Toggle Light") {
                isLightOn.toggle()
            }
            .padding()
            .background(isLightOn ? Color.yellow : Color.gray)
            .foregroundColor(.white)
            .clipShape(Capsule())
        }
    }
}

In this example, isLightOn is a @State variable used to track whether the light is on or off. The button toggles this state, and the view updates to reflect the current state of the light.

Understanding @Binding with a Volume Control Example

@Binding helps create a two-way connection between a view and data managed elsewhere, making it ideal for cases where data needs to be shared across different views.

Let’s consider a scenario where you have a parent view with a volume control that affects how a child view displays information.

struct SpeakerSystemView: View {
    @State private var volume: Double = 50 // Volume level from 0 to 100

    var body: some View {
        VStack {
            Text("System Volume Control")
            Slider(value: $volume, in: 0...100)
            SpeakerView(volume: $volume)
        }
    }
}

struct SpeakerView: View {
    @Binding var volume: Double

    var body: some View {
        Text("Speaker volume: \(Int(volume))")
            .padding()
            .background(volume > 50 ? Color.red : Color.blue)
            .foregroundColor(.white)
            .clipShape(RoundedRectangle(cornerRadius: 10))
    }
}

In the SpeakerSystemView, volume is a @State variable. The SpeakerView receives this state as a @Binding, allowing it to reflect and even modify the volume state directly. Changes in the volume are shared between the parent and child views seamlessly.

Key Differences and When to Use Each

• @State is for internal data management within a view. It is the source of truth within its local context and is not shared directly with other views.
• @Binding is for managing shared data. It does not own the data but instead binds to data owned by another part of your app, allowing multiple views to share and modify the data efficiently.

Conclusion

Understanding and using @State and @Binding effectively can greatly enhance the functionality and responsiveness of your SwiftUI apps. They are essential tools for data management, with @State being perfect for private, view-local data, and @Binding for shared, interactive data scenarios.

Experiment with the above examples in Xcode’s SwiftUI previews, and try modifying them or creating new ones to deepen your understanding of how @State and @Binding work together to manage data flow in SwiftUI applications.

The post State and Binding in SwiftUI appeared first on AppMakers.Dev.

Step 1: Define the Shared Data

First, let’s create a simple observable object class that will hold our shared data. In this example, it’s a user setting indicating whether it’s night.

@Observable
class UserSettings {
    var isNightTime: Bool = false
}

Step 2: Setup the Main App Structure

We’ll inject our UserSettings into the SwiftUI environment so that all views within the app can access it.

@main
struct MyApp: App {
    @State private var settings = UserSettings()

    var body: some Scene {
        WindowGroup {
            ContentView()
                .environmentObject(settings)
        }
    }
}

Step 3: Create the Main View

ContentView will act as the primary view that modifies the UserSettings.

struct ContentView: View {
   
  @State var settings = UserSettings()
    
    var body: some View {
        
           VStack {
               
               Text("settings.isNightTime: \($settings.isNightTime.wrappedValue)")
               
               Toggle("Toggle Night Mode", isOn: $settings.isNightTime)
               if settings.isNightTime {
                   Text("Night time")
                       .foregroundColor(.white)
                       .padding()
                       .background(Color.black)
               } else {
                   Text("Day time")
                       .foregroundColor(.black)
                       .padding()
                       .background(Color.white)
               }
           }.padding()
        
        
    }
}

This tutorial illustrated how to use the @Environment property wrapper in SwiftUI to manage shared data, such as user preferences for dark or light themes. By leveraging @Environment, we allow for a clean and efficient propagation of data changes across all views that observe the shared object. This approach minimizes the need for passing data through initializers and helps maintain a clear separation of concerns.

Examples of @Environment Use Cases

• Theme Settings: Apply user-selected themes (like dark mode) across all views.
• Localization and Accessibility: Adjust text size or localize content based on user settings.
• User Authentication State: Reflect login status on various UI components.
• Device Orientation and Size Class: Adapt UI layout based on device orientation and size.
• Environment Overrides: Customize elements like fonts and colors across multiple views.

Using @Environment simplifies state management, enhances code reusability, and makes the app maintainable by centralizing access to shared data.

The post How to use Environment property wrapper in SwiftUI appeared first on AppMakers.Dev.

Step 1: Understanding @Bindable

@Bindable creates bindings to properties of observable objects, allowing for direct UI interactions with the data model.

Step 2: Setting Up the Observable Object

Define a Book class with properties for title and availability:

import SwiftUI

@Observable
class Book {
var title = "Sample Book Title"
var isAvailable = true
}

Step 3: Creating the Book Editing View

Build a BookEditView that uses @Bindable for real-time editing:

struct BookEditView: View {
    @Bindable var book: Book

    var body: some View {
        Form {
            TextField("Title", text: $book.title)
            Toggle("Book is available", isOn: $book.isAvailable)
        }
    }
}

Step 4: Implementing in ContentView

In ContentView, instantiate Book and pass it to BookEditView. Also add Text with book.title and book.isAvailable .

struct ContentView: View {
    var book = Book()

    var body: some View {
        BookEditView(book: book)
        Text(book.title)
        Text(book.isAvailable ? "Available" : "Unavailable")
       
    }
}


#Preview {
    ContentView()
}

Step 5: Exploring @Bindable Further

Experiment with @Bindable by adding more properties to Book and updating BookEditView accordingly.

Conclusion

@Bindable in SwiftUI simplifies creating interactive forms and UIs directly linked with your data model. Practice by adding more features and observe the ease of UI updates with @Bindable.

Apple Documentation: @Bindable

Learn more about @State and @Binding

Happy SwiftUI coding! 🌟👩‍💻👨‍💻

The post How to use @Bindable in SwiftUI appeared first on AppMakers.Dev.