2

I'm trying to run a search on a background thread using new iOS PDFKit framework.

override func main() {
    if isCancelled {
      return
    }
    pdfDocument = PDFDocument.init(url: book.document.url)!
    pdfDocument.delegate = self
    pdfDocument.beginFindString("test", withOptions: [.caseInsensitive, .diacriticInsensitive]) (async)
    //pdfDocument.findString("test", withOptions: [.caseInsensitive, .diacriticInsensitive]) (sync)

  }

The problem is that none of the PDFDocumentDelegate's methods isn't called and if I use the TIME Profiler nothing seems to happen. The sync option works but cannot be cancelled.

Any ideas?

Claudiu Iordache
  • 2,215
  • 1
  • 10
  • 5

1 Answers1

2

Delegate methods will work fine for synchronous findString.

In case of async beginFindString you should rely on notifications:

// Objective - C
PDFDocumentDidBeginFindNotification
PDFDocumentDidEndFindNotification
PDFDocumentDidBeginPageFindNotification
PDFDocumentDidEndPageFindNotification
PDFDocumentDidFindMatchNotification

or

// Swift
Notification.Name.PDFDocumentDidBeginFind
Notification.Name.PDFDocumentDidEndFind
Notification.Name.PDFDocumentDidBeginPageFind
Notification.Name.PDFDocumentDidEndPageFind
Notification.Name.PDFDocumentDidFindMatch
Rafał Rębacz
  • 486
  • 2
  • 11
  • 1
    The problem is that `beginFindString` does nothing on a background thread, only `func documentDidBeginDocumentFind(_ notification: Notification)` is called. On main thread everything works ok. My guess is that async search has a thread guard. I tried with delegate and notifications as well. – Claudiu Iordache Oct 11 '17 at 07:37
  • Yep. It appears as though the async aspect of beginFindString: simply doesn't work. I noticed this was a problem when I started testing very large PDFs. Since beginFindString: runs on the main queue by default, and fails to invoke notifications if explicitly but on a different queue, this method is worthless. – charshep Jul 01 '19 at 23:03