DEV Community: Kilo Loco

Why @FetchRequest Doesn't Work with Share Extensions (And What Does)

Kilo Loco — Tue, 24 Mar 2026 05:16:45 +0000

If you've built an iOS Share Extension that writes to a shared Core Data store, you've probably hit this wall: the data saves fine, but your main app's SwiftUI list doesn't update until you kill and relaunch it.

I hit this while building a bookmarking app during a live stream. I was using Claude Code to build the whole thing. Got the Share Extension working, got it saving to Core Data through an App Group, deployed to my phone, shared a YouTube link, and... the app just sat there showing the old data. Kill the app, relaunch, there it is. Cool. Very helpful.

I spent the next few hours figuring out why, and I'm writing it up so you don't have to.

The Setup

Nothing exotic going on here. A main app and a Share Extension both access the same Core Data SQLite store through an App Group container:

Main App ←→ App Group Container (ShareSaver.sqlite) ←→ Share Extension

Both targets share a PersistenceController that points the persistent store at the App Group path:

class PersistenceController {
    static let shared = PersistenceController()
    let container: NSPersistentContainer

    private static let appGroupID = "group.com.example.ShareSaver"

    init(inMemory: Bool = false) {
        container = NSPersistentContainer(name: "ShareSaver")

        if let storeURL = FileManager.default
            .containerURL(forSecurityApplicationGroupIdentifier: Self.appGroupID)?
            .appendingPathComponent("ShareSaver.sqlite") {
            container.persistentStoreDescriptions.first!.url = storeURL
        }

        container.loadPersistentStores { _, error in
            if let error { fatalError("Store failed: \(error)") }
        }
        container.viewContext.automaticallyMergesChangesFromParent = true
    }
}

The Share Extension saves items using a background context:

private func saveItem(text: String) {
    let context = PersistenceController.shared.container.newBackgroundContext()
    context.performAndWait {
        let item = SavedItem(context: context)
        item.id = UUID()
        item.text = text
        item.createdAt = Date()
        try? context.save()
    }
}

This all works fine. The data lands in SQLite. Kill the app, relaunch, the data shows up, so it's definitely being persisted. The problem is getting the main app to see that data without a relaunch.

Quick sidebar on why I went with Core Data instead of SwiftData: I was using Claude Code to build this project, and AI coding tools just aren't trained well enough on SwiftData yet. There's not enough content out there for them to do a great job with it. Plus SwiftData hasn't gone through the battle testing that Core Data has. So I stuck with what I know works. If you're doing agent-assisted coding, I'd honestly recommend the same. At least for now.

The @FetchRequest Approach

Here's what you'd write first, and what every Core Data + SwiftUI tutorial shows:

struct ContentView: View {
    @Environment(\.managedObjectContext) private var viewContext
    @Environment(\.scenePhase) private var scenePhase

    @FetchRequest(
        sortDescriptors: [NSSortDescriptor(keyPath: \SavedItem.createdAt, ascending: false)]
    )
    private var items: FetchedResults<SavedItem>

    var body: some View {
        List {
            ForEach(items) { item in
                Text(item.text ?? "")
            }
        }
        .onChange(of: scenePhase) {
            if scenePhase == .active {
                viewContext.refreshAllObjects()
            }
        }
    }
}

You share a link, switch back to the app, and... nothing. The list is stale. Only a full kill-and-relaunch shows the new item.

I already had a bad feeling about this when I saw @FetchRequest being used. I'll be honest; I don't love property wrappers. I think they partially ruined Swift. But what can you do 🤷🏽‍♂️

Why @FetchRequest Breaks Across Processes

Your Share Extension runs in a completely separate process. The extension has its own PersistenceController instance, its own NSPersistentContainer, and its own managed object context. When it calls context.save(), it writes directly to the SQLite file. The main app's viewContext has no idea that happened.

@FetchRequest creates an NSFetchedResultsController under the hood that listens for NSManagedObjectContextObjectsDidChange notifications on the viewContext. Objects inserted, updated, or deleted within that context trigger the notification and SwiftUI re-renders. Cross-process writes don't trigger any of that. The Share Extension writes to SQLite, and the main app's viewContext is sitting there working with a stale in-memory cache.

refreshAllObjects() doesn't help either. It re-faults every managed object currently registered in the context, but it can't discover new objects. If the Share Extension inserted a row that this context has never seen, refreshAllObjects() has nothing to refresh. The context doesn't even know the row exists.

The Debugging Spiral

My first thought was that it's probably a lifecycle thing. Like, maybe the scene delegate isn't detecting that the app re-entered the foreground, so the @FetchRequest isn't getting triggered to refresh. I had Claude implement the scene phase observer. Rebuilt, deployed to my phone. Didn't fix it.

OK, so it's not a foreground/background thing. Even though I was pretty sure by now that it wasn't a simple refresh issue (since the data was there on relaunch) I still wanted to try pull-to-refresh. Not because I thought it would fix it, but because it would give me better feedback. If I manually trigger a fetch and it still doesn't work, then I know the problem is deeper than just "we're not refreshing at the right time."

Implemented pull-to-refresh. Still broken.

At this point I was running out of time on the live stream, and I started going deeper. I had Claude try Persistent History Tracking, which is Apple's recommended pattern for cross-process Core Data changes. I tried Apple's class method mergeChanges(fromRemoteContextSave:into:). I tried wiring the history merge into the scene phase observer. Every Stack Overflow answer and Apple Developer Forums thread I could find said persistent history tracking was the answer.

None of it worked. I kept sending Claude back in to fix it, and each time it would say "OK, updated"... and each time, same result.

Checking Under the Hood

I wanted to see what the data layer was actually saying versus what the UI was showing, so I built a debug panel directly into the app. Three counts, side by side:

Source	Count
Fresh `NSFetchRequest` on background context	11
`viewContext.count(for:)`	11
`@FetchRequest` (SwiftUI)	10

OK, so I wasn't crazy. The data is in the store. The viewContext can see it. @FetchRequest just won't re-evaluate. The problem isn't Core Data at all. It's that @FetchRequest doesn't pick up cross-process changes no matter what you do. The property wrapper was the problem the whole time.

The Fix: Do It the UIKit Way

Once I saw that debug output, I was like... you know what, Claude, implement this the way we would've done it back in the UIKit days. Manage the NSFetchedResultsController yourself. I almost guarantee it's gonna work.

Sure enough. That shit worked.

class SavedItemListViewModel: NSObject, ObservableObject,
    NSFetchedResultsControllerDelegate {

    @Published var items: [SavedItem] = []

    private let fetchedResultsController: NSFetchedResultsController<SavedItem>
    private let viewContext: NSManagedObjectContext

    init(context: NSManagedObjectContext) {
        self.viewContext = context

        let request: NSFetchRequest<SavedItem> = NSFetchRequest(entityName: "SavedItem")
        request.sortDescriptors = [
            NSSortDescriptor(keyPath: \SavedItem.createdAt, ascending: false)
        ]

        fetchedResultsController = NSFetchedResultsController(
            fetchRequest: request,
            managedObjectContext: context,
            sectionNameKeyPath: nil,
            cacheName: nil
        )

        super.init()

        fetchedResultsController.delegate = self
        try? fetchedResultsController.performFetch()
        items = fetchedResultsController.fetchedObjects ?? []
    }

    func controllerDidChangeContent(
        _ controller: NSFetchedResultsController<any NSFetchRequestResult>
    ) {
        items = fetchedResultsController.fetchedObjects ?? []
    }

    func reload() {
        viewContext.reset()
        try? fetchedResultsController.performFetch()
        items = fetchedResultsController.fetchedObjects ?? []
    }

    func delete(at offsets: IndexSet) {
        for index in offsets {
            viewContext.delete(items[index])
        }
        try? viewContext.save()
    }
}

The key is reload(). reset() nukes the context's in-memory cache so performFetch() actually hits the database instead of returning stale objects. Then you update the @Published array and SwiftUI re-renders. You're controlling everything from the context manager, the way it was always meant to work.

The view:

struct ContentView: View {
    @Environment(\.scenePhase) private var scenePhase
    @StateObject private var vm: SavedItemListViewModel

    init() {
        let context = PersistenceController.shared.container.viewContext
        _vm = StateObject(wrappedValue: SavedItemListViewModel(context: context))
    }

    var body: some View {
        NavigationView {
            List {
                ForEach(vm.items) { item in
                    Text(item.text ?? "")
                }
                .onDelete { vm.delete(at: $0) }
            }
            .navigationTitle("Saved Items")
            .refreshable { vm.reload() }
            .onChange(of: scenePhase) {
                if scenePhase == .active {
                    vm.reload()
                }
            }
        }
    }
}

When the user shares content and returns to the app, scenePhase transitions to .active, reload() fires, and the new item appears. First try. Pull-to-refresh works too. In-process changes like swipe-to-delete are handled automatically by the NSFetchedResultsControllerDelegate.

What's Actually Going On

@FetchRequest is a convenience wrapper that works great when all changes flow through the same viewContext in a single process. But when another process writes to the same SQLite file (like a Share Extension does) the property wrapper's internal observation just doesn't pick it up. Even if you merge the changes exactly the way Apple's documentation says to, @FetchRequest doesn't re-evaluate. The data is right there in the context, and it just ignores it.

With the NSFetchedResultsController approach, you're not trying to convince the property wrapper that something changed. You nuke the cache, re-fetch from disk, and update the @Published array yourself. No persistent history tracking, no Darwin notification hacks. Just reset() and performFetch().

If You're Using AI Coding Tools

I built this whole app with Claude Code and it worked pretty damn well, but this is where it got stuck. It kept trying persistent history tracking because that's what the docs say, not realizing @FetchRequest was the actual bottleneck. I had to be the one to say "forget the property wrapper, just use NSFetchedResultsController." Sometimes you have to override the agent with your own instincts.

The sample project has the broken @FetchRequest version commented out alongside the working NSFetchedResultsController version so you can see the difference yourself.

Migrating Asynchronous Code to Combine

Kilo Loco — Thu, 03 Sep 2020 00:30:46 +0000

Allow me to set the stage before we jump in.

Let's say we have an app that shows a list of cells displaying an animal name and two buttons: one to show the animal emoji and the other to make the sound of that animal.

Designer was paid in equity 😛

Just like any real world app, we have similar features that have been implemented differently because everyone on the team seems to think their way is best 🤡

/// AnimalsViewController.swift

class AnimalsViewController: UITableViewController {
    ...

    func getAnimals() {
        NetworkingService.getAnimals { [weak self] (result) in
            switch result {
            case .success(let animals):
                self?.animals = animals
                self?.tableView.reloadData()

            case .failure(let error):
                print(error)
            }
        }
    }

    ...

    override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        ...

        animalCell?.delegate = self
        animalCell?.shouldMakeNoiseForAnimal = { [weak self] animal in
            self?.makeNoise(for: animal)
        }

        ...
    }

    ...
}

extension AnimalsViewController: AnimalCellDelegate {
    func shouldShowEmoji(for animal: Animal) {
        showEmoji(for: animal)
    }
}

This TableViewController is responsible for retrieving the Animal's from a server and implementing the logic for when a user taps on either the "Show Emoji" button or the "Make Noise" button.

/// NetworkService.swift

enum NetworkingService {
    static func getAnimals(completion: @escaping (Result<[Animal], Error>) -> Void) {
        let animals: [Animal] = [.dog, .cat, .frog, .panda, .lion]
        completion(.success(animals))
    }
}

When calling the networking service, we pass in a closure that acts as a callback for when the server has returned the Animal data.

/// AnimalCell.swift

protocol AnimalCellDelegate: AnyObject {
    func shouldShowEmoji(for animal: Animal)
}

class AnimalCell: UITableViewCell {

    ...

    weak var delegate: AnimalCellDelegate?
    var shouldMakeNoiseForAnimal: ((Animal) -> Void)?

    @IBAction func didTapShowEmojiButton() {
        delegate?.shouldShowEmoji(for: animal)
    }

    @IBAction func didTapMakeNoiseButton() {
        shouldMakeNoiseForAnimal?(animal)
    }

    ...
}

The AnimalCell is where we have two different ways to do the same thing; pass the Animal object when a button is tapped. The first way is in didTapShowEmojiButton which is using the delegate pattern to send the Animal object to our AnimalsViewController. The other is in didTapMakeNoiseButton which is using a callback to send the animal to AnimalsViewController.

So as we can see, we have a few examples of asynchronous code in this app. One important difference to understand between these types of communication is that the "networking request" that we are performing is only going to give us a single result. Either we will end up with a success and get our array of Animal's, or we will get an error, and that's it.

If the server is down, and sends an error, but one second later it is up and can send the array of Animal's, it wont do so until another request is made. It is in these circumstances where we are only expecting a single result to come back, that we want to work with Future.

Futures

Future is a publisher that is designed to return the result of a Promise. A Promise is almost identical to a callback with a Swift.Result, you write some control flow, then return a Promise by doing something like promise(.success(myObject)). Future is initialized with a Promise closure and then is treated like any other Publisher where you must use a sink to get the value.

Let's take a look at this in action by replacing our getAnimals method in NetworkingService.swift:

... // enum NetworkingService {

static func getAnimals() -> Future<[Animal], Error> {
    return Future { promise in
        let animals: [Animal] = [.dog, .cat, .frog, .panda, .lion]
        promise(.success(animals))
    }
}

... // NetworkingService closing }

There is clearly a lot of similarity between our former function signature with a callback and our new function signature that returns a Future. We created our Future by passing in a closure that takes a Promise, and we pass either a success or a failure to our promise once we have determined the correct result to return; in this case, success(animals).

Back in our AnimalsViewController we are going to start getting errors since the function signature of NetworkingService.getAnimals has changed. To fix these errors, we simply handle our newly returned Future just like we would handle any other Publisher.

...

var getAnimalsToken: AnyCancellable?
func getAnimals() {
    getAnimalsToken = NetworkingService.getAnimals()
        .sink(
            receiveCompletion: { completion in
                switch completion {
                case .finished:
                    print("Subscription finished")

                case .failure(let error):
                    print("Error getting animals -", error)
                }
            },
            receiveValue: { [weak self] animals in
                self?.animals = animals
                self?.tableView.reloadData()
            }
        )
}

...

So now we have a sink for our Future Publisher which takes in two closures: receiveCompletion and receiveValue. We use receiveCompletion to handle any errors that may have occured as well as do any additional logic once the subscription has finished. The receiveValue block is more straightforward by simply passing in the expected value; in our case, an array of Animal objects.

Another thing we need to keep in mind is that sink's will fall out of memory if we don't keep a reference to them. That's where our little buddy getAnimalsToken comes in.

PassthroughSubjects

The difference between the "networking request" and the button taps coming from our cell is that there can be an infinite number of taps/values that are passed down stream from our buttons. When we are working with multiple results and don't know if/when they will stop coming, we need to use PassthroughSubject.

Unlike Future, the PassthroughSubject subscription will not finish after the first result is sent, but instead requires that a Completion<Failure> is manually sent down the stream if we want it to finish.

Let's take a look at this in action by replacing our delegate and callback code in AnimalCell.swift with PassthroughSubject.

...

var showEmojiPublisher = PassthroughSubject<Animal, Never>()
var makeNoisePublisher = PassthroughSubject<Animal, Never>()

@IBAction func didTapShowEmojiButton() {
    showEmojiPublisher.send(animal)
}

@IBAction func didTapMakeNoiseButton() {
    makeNoisePublisher.send(animal)
}

...

It's a pretty straightforward swap. We replace the delegate and shouldMakeNoiseForAnimal properties with PassthroughSubject's that can be subscribed to through sink's at the call site. Then we simply send the Animal through the respective Publisher whenever either button is tapped.

While replacing our two original forms of communication with two PassthroughSubject's would work, it is less than ideal because we would need to hang onto a reference for both sink's in every cell. It's also kinda smelly cuz they're the same type of Publisher with different names.

Let's create a nested Action enum that we can send to the Publisher while still maintaining context as to what should be happening when each Action comes down stream.

...

enum Action {
    case showEmoji(Animal)
    case makeNoise(Animal)
}

var actionPublisher = PassthroughSubject<Action, Never>()

...

@IBAction func didTapShowEmojiButton() {
    actionPublisher.send(.showEmoji(animal))
}

@IBAction func didTapMakeNoiseButton() {
    actionPublisher.send(.makeNoise(animal))
}

...

Our new actionPublisher will publish AnimalCell.Action's and now we only have one sink to hang onto for each cell in our table view.

Time to update cellForRowAt indexPath in AnimalsViewController.swift:

...

// 1
var cellTokens = [IndexPath: AnyCancellable]()

override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    ...

    // 2
    cellTokens[indexPath] = animalCell?.actionPublisher
        .sink { [weak self] action in
            // 3
            switch action {
            case .showEmoji(let animal):
                self?.showEmoji(for: animal)

            case .makeNoise(let animal):
                self?.makeNoise(for: animal)
            }
        }

    ...
}

...

cellTokens will allow us to keep a reference to each sink so it stays alive and can observe values.
We set the resulting sink to the associated IndexPath.
Switching on the action allows us to handle both our AnimalCell.Action's, and acts as a reminder to update our sink's logic if we do add another Action in the future.

Our app should now continue to work as it did before, and now our way is best.

Welcome to 10x Engineer status 🙌🏽

Conclusion

Combine is pretty slick, and offers us an opportunity to consolidate all of our communication patterns into a single pattern. Also, everybody and their mom is using reactive frameworks, so might as well get comfortable with the first party version as it is likely to become the standard for native iOS development.

Now go out there, convince your boss that you need to refactor all your code, and do so passionately 😘

Passing Data with Safe Args using Android Jetpack

Kilo Loco — Mon, 31 Aug 2020 19:39:12 +0000

Android Jetpack aims to make life easier by providing devs with several tools that help speed up development while encouraging best practices. The tools we're going to be focusing on today are the Navigation component and passing data with Safe Args.

Safe Args is a Gradle plugin that gives us type safety when navigating and passing data between destinations.

We will be exploring these concepts by creating a simple app that displays a list of users in a fragment that contains a RecyclerView and passing the selected User to our UserDetailsFragment.

We'll start from scratch with a new AndroidX project with an Empty Activity.

Let's start off by setting up our dependencies.

In your project build.gradle file, add the following:

... // dependencies {

def nav_version = "2.3.0"
classpath "androidx.navigation:navigation-safe-args-gradle-plugin:$nav_version"

... // dependencies closing }

In the module build.gradle file, we will need all of the following:

... // other plugins

apply plugin: "androidx.navigation.safeargs"

... // android {

This plugin will generate our NavArgs and NavDirections for us.

... // android {

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

kotlinOptions {
    jvmTarget = "1.8"
}

... // android closing }

Java 8 is a minimum requirement to work with safe args.

... // depedencies {

def nav_version = "2.3.0"
implementation "androidx.navigation:navigation-fragment-ktx:$nav_version"
implementation "androidx.navigation:navigation-ui-ktx:$nav_version"
implementation "androidx.navigation:navigation-dynamic-features-fragment:$nav_version"

... // dependencies closing }

We will keep our Android Jetpack Navigation depedency versions in sync by using a single variable for all three dependencies.

We should be able to build our project, get all of our dependencies into the project, and get to the juicy stuff now 🥩

Our app needs to show a list of users, then be able to open the details screen for the selected user. Let's make two fragments that represent both of those screens.

We'll start by creating the User object that we will be working with. (Right click project folder > New > Kotlin File/Class > Class)

import android.os.Parcelable
import kotlinx.android.parcel.Parcelize

@Parcelize
data class User(val id: Int, val name: String, val age: Int): Parcelable {
    val description: String
        get() = "$name is $age years old."
}

We are keeping our object very simple here by only giving a few properties like id, name, and age. We are also making it Parcelable so we can pass it between fragments.

Let's go ahead and add the fragment that will be responsible for showing our users (Right click project folder > New > Fragment > Fragment (List))

I'll configure the component with names that make sense for my project, in this case the names/objects will revolve around our User object.

Going through this process will generate a lot of the boilerplate code for us. We should now have the following files in our project: UsersFragment, UsersRecyclerViewAdapter, fragment_users.xml, and fragment_users_list.xml.

We can get rid of a lot of the unnecessary code in our UsersFragment and use our own dummy data by replacing it with this:

class UsersFragment : Fragment() {

    private val users = listOf<User>(
        User(1, "Kyle", 29),
        User(2, "Adri", 36),
        User(3, "Andy", 14),
        User(4, "Xayxay", 3),
        User(5, "Mya", 1)
    )

    override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        val view = inflater.inflate(R.layout.fragment_users_list, container, false)

        if (view is RecyclerView) {
            with(view) {
                layoutManager = LinearLayoutManager(context)
                adapter = UsersRecyclerViewAdapter(users)
            }
        }
        return view
    }
}

Since UsersRecyclerViewAdapter is expecting the dummy object that was autogenerated, we will get an error for trying to pass in a list of User objects. Let's fix that.

class UsersRecyclerViewAdapter(
    private val users: List<User>
) : RecyclerView.Adapter<UsersRecyclerViewAdapter.ViewHolder>() {

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        val view = LayoutInflater.from(parent.context)
            .inflate(R.layout.fragment_users, parent, false)
        return ViewHolder(view)
    }

    override fun onBindViewHolder(holder: ViewHolder, position: Int) {
        val user = users[position]
        holder.idView.text = user.id.toString()
        holder.contentView.text = user.name
    }

    override fun getItemCount(): Int = users.size

    inner class ViewHolder(view: View) : RecyclerView.ViewHolder(view) {
        val idView: TextView = view.findViewById(R.id.item_number)
        val contentView: TextView = view.findViewById(R.id.content)

        override fun toString(): String {
            return super.toString() + " '" + contentView.text + "'"
        }
    }
}

The only changes here were changing the values property to users and the type to User as well. We also made sure the we are binding relevant data to the ViewHolder in the onBindViewHolder method.

Now that our UsersFragment is properly configured, let's setup a new UserDetailsFragment (Right click project folder > New > Fragment > Fragment (Blank))

class UserDetailsFragment : Fragment() {

    override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        val view = inflater.inflate(R.layout.fragment_user_details, container, false)

        return view
    }
}

We'll also update our fragment_user_details.xml to have the pre-generated TextView to be in the center of the screen.

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".UserDetailsFragment">

    <TextView
        android:id="@+id/textView"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/hello_blank_fragment"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

</androidx.constraintlayout.widget.ConstraintLayout>

Now we have both fragments laid out, we are ready to use them in a navigation graph.

Create a new resource (Right click res folder > New > Android Resource File), and create a new Navigation resource called nav_graph

Our Editor should now look like this:

Let's add our fragments to the graph by clicking the (+) icon.

I added the usersFragment first, so it has a house icon next to the name indicating that it will be the entry point for our nav_graph. If you added them in a different order, you can simply select the usersFragment and tap the house icon at the top to make it the start destination.

I also dragged the navigation action arrow to the userDetailsFragment to indicate that we should be able to navigate from usersFragment to userDetailsFragment.

This is a great visual representation of our app's flow, but if we tried to run the app now, we actually wouldn't see our usersFragment. We still need to update our activity_main.xml to become our NavHostFragment.

Let's replace the pre-generated TextView in activity_main.xml with a NavHostFragment.

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <fragment
        android:id="@+id/fragment"
        android:name="androidx.navigation.fragment.NavHostFragment"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        app:defaultNavHost="true"
        app:navGraph="@navigation/nav_graph" />

</androidx.constraintlayout.widget.ConstraintLayout>

Note
You might receive a warning here to use FragmentContainerView instead, but the Android documentation only specifies fragment at this stage, so we will continue to use it here.

We can head back over to our nav_graph.xml and we should see our activity_main under the HOST section of our Destinations panel.

Now that our nav_graph is laid out, we can specify that we want to pass a User object from usersFragment to userDetailsFragment.

In the code of nav_graph.xml, I can now add an argument within the userDetailsFragment attributes:

... // other userDetailsFragment attributes

<argument
    android:name="user"
    app:argType="com.kiloloco.passing_data.User" />

... // </fragment> of userDetailsFragment

Here we are specifying that we want our Safe Args to have an argument named user which will be of type User.

Note
If you would like to see the different types of arguments you can pass to Safe Args, check out the Android Docs.

Now if we build our project, we should have UsersFragmentDirections and UserDetailsFragmentArgs generated for us.

These generated objects will help us use type safety when passing our arguments between fragments as well as remove some of the boilerplate required to access the value of the passed argument.

We need to update UsersRecyclerViewAdapter and UsersRecyclerViewAdapter.ViewHolder to handle passing and receiving the selected User.

... // override fun getItemCount(): Int = users.size

inner class ViewHolder(view: View, var user: User? = null) : RecyclerView.ViewHolder(view) {

... // val idView: TextView = view.findViewById(R.id.item_number)

... // holder.contentView.text = user.name

holder.user = user

... // onBindViewHolder closing }

We added a nullable user property to our ViewHolder, then updated the user property of the holder in our onBindViewHolder method.

Let's also update our ViewHolder to actually handle the selection of the user and the navigation to the UserDetailsFragment.

... // val contentView: TextView = view.findViewById(R.id.content)

init {
    view.setOnClickListener {
        user?.let { user ->
            val directions = UsersFragmentDirections.actionUsersFragmentToUserDetailsFragment(user)
            view.findNavController().navigate(directions)
        }
    }
}

... // override fun toString(): String {

In our onClickListenter, we are passing the user as an argument in UsersFragmentDirections.actionUsersFragmentToUserDetailsFragment which is expecting a User object; that's the sexy type safety we were after 🙌🏽

The directions contain the action that is generated from our nav_graph which is associated with the flow we created from the UsersFragment to the UserDetailsFragment. It also passes our User object into the bundle which we will be able to access from our UserDetailsFragmentArgs.

We can now head over to the UserDetailsFragment to handle the receiving of the selected User.

... // class UserDetailsFragment : Fragment() {

private val args: UserDetailsFragmentArgs by navArgs()
private lateinit var user: User

... //

We can access our arguments by delegating to navArgs() and will need a lateinit var that will hang onto the User.

... // val view = inflater.inflate(R.layout.fragment_user_details, container, false)

user = args.user

... // return view

Since args is of type NavArgsLazy<UserDetailsFragmentArgs>, we are able to access the user property directly from the arguments and store it to this.user.

... // onCreateView closing }

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    textView.text = user.description
}

... // UserDetailsFragment closing }

With this.user updated in onCreateView, we can access our NonNull user to update our UI in onViewCreated.

Let's give our app a run, and see if it works as expect 🤞🏽

Now that's a pretty clean way to pass some data! ✨