Protocol Support for PDFDocument about ios-pdf-reader HOT 4 CLOSED

This seems like a much cleaner solution, but I'm still weary of making fileURL optional, as several features of the library depend on them, for example the print and activity sheet. If this were to be optional, how would we handle these buttons/actions, and how would this get communicated to the user of the library, especially at the point of initialization?

from ios-pdf-reader.

I guess I am looking at it from a flexibility standpoint. It would allow consumers to use the project with a more flexible set of PDF sources, similar to vfr reader supports. We could handle the button behavior via documentation, examples, and asserts.

Happy to put together all of the above so it is clear to the developers using the project.

from ios-pdf-reader.

My main concern is making it clear to users what features/customizations are available when. If we can add the flexibility of a protocol oriented approach and not compromise on clarity and ease-of-use for developers using the project, I think we're golden. I'd be happy to take a look at a pull request.

from ios-pdf-reader.

Closing due to inactivity. Free free to re-open if you want to open up a pull request for this in the future.

from ios-pdf-reader.