Support for Flutter Web

[deakjahn]

Not merely a feature request, more than that. :-)

I've created the first functioning sample of flutter_pdfview_web. Not a full viewer yet but it can display a PDF using the PDF.js package.

Web plugins can't be simply added like Android and iOS ones. You have to move forward to a federated plugin where you can specify the interface and the various platforms are packaged separately (although you can note in the main plugin which additional platform plugins belong to it). Basically, you will have an interface package, a main package like now (that houses the Android and iOS implementations) and any number of related extra plugins later (like Web).

I spent a day to be cleverer than the system and to mix the old layout with the web plugin. It doesn't work. The plugin won't see any necessary external packages and won't be able to communicate with the JavaScript PDF viewer in the browser. So, no, there's no easy way out. :-)

So, this is more than a simple PR, it's a commitment. :-) To test a web plugin, you have to switch to the Flutter beta channel (at least for now) and to restructure the existing one, starting a parallel development for some time. But if you are interested, I can send you what I have now.

[deakjahn]

In addition, I can send you the boilerplate of another plugin that I've just converted to federated. Documentation is very scarce, nothing actually discusses the PlatformView case but by mimicking and improving upon various stock plugins I seem to be on the right track now.

[endigo]

@deakjahn Can you create PR? Maybe I get some understanding of flutter_web. Actually, I never tried it before and I was rarely working on dart/flutter almost the last 6 months.

[deakjahn]

No, I can't. That's what I said. Moving to federated requires a complete reorganization of the plugin, the whole current plugin goes to a different folder than now, two completely new plugins appear inside. Besides, while I'm (we're?) working on it, we can't simply refer to the plugins on pub.dev as dependencies but have to refer to them locally.

So, I don't think this is realistic with a PR. Practically, you should create a new project for yourself, a v2, and test it on your computer (or create a new one on GitHub if you need it during testing). This isn't something you want to pollute your current codebase with, I guess.

So, I can supply that boilerplate for you to see how it should be set up but the existing functionality should be a bit reshuffled to fit. Not much. The main difference is that you no longer assume the MethodChannel between the two sides because, in the case of the web, both sides are written in Dart and get compiled to JavaScript, anyway, so they can simply co-operate directly, without the need of a channel. To accomplish this, you have an abstract interface that Android and iOS extends with the previous MethodChannel all right but other platforms (eg. Web) can implement in a different manner.

Actually, the whole point of federated plugins is that you no longer need to maintain platform subplugins yourself. If you don't want to struggle with the web yourself, somebody else can make the _web variant, and if all goes well, you just refer to that platform plugin from your main one, like saying "this is the web implementation I officially recommend" and the system will do the rest transparently for the users. So, you should really do this some time even if you only want to stay Android or iOS yourself, because this is the new scheme plugins should follow now. But it isn't enforced at all for now, just recommended.

[deakjahn]

@endigo Hold your horses, a private mail will arrive. :-)

[endigo]

@deakjahn Hello, changing the plugin to support other platforms takes a lot of work and time.
Lately, I rarely using flutter because my work doesn't use it.

If you still want to help to support the web and other platforms, feel free to contribute.

Best regards,
Tsogt

[deakjahn]

Past tense. I did it, I use the plugin on all three platforms, with success, Android, iOS and web. It works.

Simply, changing the structure to a federated plugin is more than a PR should normally handle. That's why I sent the whole package earlier to @endigo and I'm more than willing to send it again if you want to take a peek and use the modified approach.

[endigo]

Yeah, I remember. But I think you should create PR.

[deakjahn]

Sorry but that won't happen. That would mean I have to rebase it completely to find out what you have changed in the meantime, during more than half a year or so. You're in a much better position to do that than me because you know your recent changes and I don't. I offered a complete solution of two rather large issues: first, to restructure the whole plugin as a federated one (which is clearly the only recommended way to go further with plugins in Flutter), and second, to add a complete new implementation. I could've published on Pub under my own name, with reference to you as a fork but I didn't and don't intend to do it, I'd much rather see it improve the original for the benefit of the existing users.

So, without hard feelings, I have to say take it or leave it. :-)

[kenthinson]

@deakjahn Would you be willing to make your repo public so I can look at your changes? This feature is of interest to me.

[deakjahn]

I kinda lost track of what it was all about. :-) Yes, the PDF viewer on the web. I don't have it in a repo, it's local and I use it in some apps. Yes, I can upload it as it is now, I really don't know how it compares to this current plugin, I haven't touched it for about a year (well, I did, I null-safed it recently), it just works for me.

[deakjahn]

@kenthinson I had a fork previously but I did a spring cleanup of orphaned forks that had PRs already merged. :-) I uploaded the whole package now under a new name to avoid problems: https://github.com/deakjahn/flutter_pdfview_2

I would really love to contribute it to the original but I won't be able to rebase it completely again now to match the current state. This one is federated and null-safe, all to the latest spec but if @endigo could take a peek of what he has changed in the meantime in the original and whether it's feasible to merge it somehow...

[kenthinson]

@deakjahn thank You for uploading the code. It will help me learn for sure :)

[kenthinson]

@endigo this feature is something I will need for a project I’m working on. I could just use the code @deakjahn provided as is. However this is a long term project I’m working on. so I would prefer to have it in the main package. As deakjahn also would like this feature in the main package (looking at his comments above). I now come to my question.

endigo If I do the time consuming task of rebase on your current code and create a pull request. Are you still open to it being merged in? I want to make sure it’s not a wasted effort :)

[endigo]

@kenthinson hey, If you do that it will be an amazing contribution to this package.

[deakjahn]

@kenthinson I'm here, count me in if you need any help with the web side, just that I really don't have the time to do the full rebase myself. The web side uses a Dart-JS co-operation style that I use in several of my in-house plugins and it works quite well but some things might not be immediately obvious, who knows. Just start a thread over there and we can discuss it.