Overriding classes in our iOS viewer

Nutrient has a unique and easy-to-use system that enables you to subclass classes that are used deeply within the framework without having to know where they’re all instantiated.

The PDFConfigurationBuilder object has an overrideClass(_:with:) method in the builder, which is where you can register your subclasses to be used in place of the default Nutrient classes created in the user interface (UI). There’s a similar method on Document to replace classes created outside of the UI.

Say you want to move the ScrubberBar all the way to the top. Classes usually don’t manage their placement themselves, so in this example, the class is managed by the UserInterfaceView, which requires you to override the class. We sometimes expose subclassing hooks, which are methods specifically for being overridden by subclasses. In this case, UserInterfaceView has a subclassing hook, updateScrubberBarFrame(animated:).

First, create a custom subclass to override this method:

class CustomUserInterfaceView: UserInterfaceView {

    override func updateScrubberBarFrame(animated: Bool) {
        super.updateScrubberBarFrame(animated: animated)

        // Put scrubber bar at the top.
        var newFrame = dataSource!.contentRect
        newFrame.size.height = 44
        scrubberBar.frame = newFrame
    }

}

Next, register your custom subclass:

PDFView(document: document)
    .updateConfiguration {
        $0.overrideClass(UserInterfaceView.self, with: CustomUserInterfaceView.self)
    }

let pdfController = PDFViewController(document: document) {
    $0.overrideClass(UserInterfaceView.self, with: CustomUserInterfaceView.self)
}

That’s it! From now on, every time Nutrient creates a UserInterfaceView, it actually uses CustomUserInterfaceView.

Things to keep in mind

• Your subclass must be an actual subclass or we’ll throw an exception to warn you.
• Only classes that already conform to the Overridable protocol can be overridden. Don’t add conformance to this protocol for any other existing classes or for your new ones.
• Most methods require that you call them on super.
• If your subclass isn’t being used, try registering it with both the PDFConfiguration and the Document. There’s no harm in registering your subclass with both.
• Overrides need to be registered before calling any other method on the object (e.g. trying to set an override on the document after unlock(withPassword:) has been called will silently fail — it’d be too expensive to check all calls for timing correctness).
• If you’re using PDFView (SwiftUI), you can subclass its internal PDFViewController by registering your view controller subclass in the same way shown above.
• If you see a getter/setter property pair or a read-only getter, don’t override it unless doing so is specifically documented. In most cases, this will lead to unexpected/inconsistent/buggy behavior. Nutrient will even detect and assert some of these attempts, but we can’t possibly anticipate every use and every way to dynamically override properties. In most cases, there will be a better way to achieve what you’re trying to do — contact us on support; we’re happy to help.