Data delivery with drag and drop

At a glance

Project structure

ClientList/
├── ContactCard.swift
├── ContactsTableViewController.swift
│   ├── ClientsDataSource
│   ├── UITableViewDropDelegate extension
│   └── UITableViewDragDelegate extension
├── ContactDetailsViewController.swift
├── AppDelegate.swift
└── Base.lproj/Main.storyboard

Structure observations

• Data encoding/decoding belongs to ContactCard, not the drag delegate.
• Row storage and local moves belong to ClientsDataSource.
• Drag/drop policy stays in same-file protocol extensions on the table controller.

Overall architecture

flowchart LR
    Table["ContactsTableViewController"] --> Data["ClientsDataSource"]
    Data --> Cards["[ContactCard]"]
    Table -->|"drag row"| Provider["NSItemProvider"]
    Cards --> Provider
    Provider -->|"vCard or UTF-8"| OtherApp["Other app / drag system"]
    OtherApp -->|"promised loadObject"| Drop["UITableViewDropCoordinator"]
    Drop -->|"placeholder + commit"| Data
    Drop -->|"local sourceIndexPath"| Move["moveClient"]
    Move --> Data
    Table -->|"segue injection"| Detail["ContactDetailsViewController"]

Reference code

ClientList/ContactCard.swift:34 — the domain object itself declares supported types and decodes either a vCard or a plain-text fallback into the same model.

static var readableTypeIdentifiersForItemProvider = [
    kUTTypeVCard as String,
    kUTTypeUTF8PlainText as String
]

static func object(
    withItemProviderData data: Data,
    typeIdentifier: String
) throws -> ContactCard {
    let contact = ContactCard(name: "")
    if typeIdentifier == kUTTypeVCard as String {
        let values =
            try CNContactVCardSerialization.contacts(with: data)
        guard let value = values.first else {
            throw ContactCardError.invalidVCard
        }
        contact.name = value.givenName + " " + value.familyName
    } else if typeIdentifier == kUTTypeUTF8PlainText as String {
        contact.name = String(data: data, encoding: .utf8)!
    }
    return contact
}

Interpretation

The transfer boundary is ContactCard, not a view controller. The table controller only decides move/copy/placement policy; NSItemProvider negotiates a representation and asks the model to encode or decode it.

Ownership and state

classDiagram
    ContactsTableViewController *-- ClientsDataSource : strong let
    UITableView --> ClientsDataSource : dataSource callback
    ClientsDataSource *-- ContactCardArray : mutable clients
    ContactCard *-- String : name and phone
    ContactCard o-- UIImage : optional photo
    UIDragItem *-- NSItemProvider : transfer promise
    NSItemProvider o-- ContactCard : local source object
    UITableViewDropPlaceholderContext --> ClientsDataSource : commit insertion
    ContactDetailsViewController o-- ContactCard : injected IUO

Ownership evidence

ClientList/ContactsTableViewController.swift:55 — the table controller keeps one strong data-source owner and installs it for data, drag, and drop collaboration.

class ContactsTableViewController: UITableViewController {
    let dataSource = ClientsDataSource()

    override func viewDidLoad() {
        super.viewDidLoad()
        tableView.dropDelegate = self
        tableView.dragDelegate = self
        tableView.dataSource = dataSource
    }

    override func prepare(
        for segue: UIStoryboardSegue,
        sender: Any?
    ) {
        let details =
            segue.destination as! ContactDetailsViewController
        details.contactCard =
            dataSource.clients[tableView.indexPathForSelectedRow!.row]
    }
}

Class and protocol design

This is protocol-oriented integration even without an app-defined protocol: ContactCard conforms directly to two narrow data-transfer contracts, so the system can request representations without knowing the table/controller.

Access control

Reference code

ClientList/ContactCard.swift:60 — writing exposes the same two ordered representations and rejects unsupported identifiers explicitly.

static var writableTypeIdentifiersForItemProvider = [
    kUTTypeVCard as String,
    kUTTypeUTF8PlainText as String
]

func loadData(
    withTypeIdentifier typeIdentifier: String,
    forItemProviderCompletionHandler completion:
        @escaping (Data?, Error?) -> Void
) -> Progress? {
    if typeIdentifier == kUTTypeVCard as String {
        completion(createVCard(), nil)
    } else if typeIdentifier == kUTTypeUTF8PlainText as String {
        completion(name.data(using: .utf8), nil)
    } else {
        completion(nil, ContactCardError.invalidTypeIdentifier)
    }
    return nil
}

Logic ownership and placement

Design patterns

Naming conventions

• Domain and screen roles are explicit: ContactCard, ClientsDataSource, ContactsTableViewController, and ContactDetailsViewController.
• Transfer methods keep framework-required names; internal commands use moveClient and createVCard.
• clients names the mutable collection while client(index:) names one lookup.
• Error cases name invalid inputs directly: invalidTypeIdentifier and invalidVCard.

Architecture takeaways

• Put representation negotiation/serialization on the transferable model, not in UI delegates.
• Use the drag/drop controller for policy and the data source for ordered model mutation.
• Separate local moves from cross-app promised loads.
• Use placeholder commit APIs so asynchronous data and final table indices stay synchronized.
• Narrow mutable array access in production even when direct mutation keeps a sample short.

Source map

• Official Apple documentation