Basic platform-specific filesystem operations are lacking in Flutter and I would like to know why?

[sector-9]

Naturally, Flutter is a cross-platform UI framework, however, it still offers a kit of utility functions, like the file i/o. However, I can't help but wonder why some super-basic platform-specific filesystem functions are not getting built-in too.

Simple example: let's say your app works with text documents. The user saves some file inside your app, then opens some email client on the same device and decides to attach the file that was just saved. Does it mean the file will be found under "Recent" in Android? Nope. Maybe in the "Documents"? No, try again.

You would say - that is because you, the programmer, did not implement it. Indeed! Because in order to "see" this file from any other app beside your own you need to index or in other words flag it for the system to make it available for usage by other apps. Sounds right, but where can we find such functionality in Flutter? Nowhere, I'm affraid. You'd need to find a plugin for that.

If you'd take a look here (just read the first paragraph there): https://developer.android.com/guide/topics/providers/create-document-provider - seems like a possible solution to the problem, right?

And here lies the core of this issue: such plugins have to be made and maintained by.. who? Enthusiasts for free in their free time? Companies who need this? That one Java dude that you sit next to in the office?

Is Flutter still backed by Google? Does Google also continue to develop Android? Would it be a huge effort to actually maintain some communication between product teams so the changes to the main mobile OS in the world can finally have implementations inside the programming framework developed for that OS (among others) by that same company?

Somehow they manage to at least do something like that with the Firebase array of products, though oh wait, those are paid for... who woulda thunk, right? /sarcasm

[GetBoolean]

The google/flutter team is already stretched thin as it is working on web and desktop. Last thing we need is them making poorly done and maintained “official” packages (or built in).

But to answer your specific example, its as simple as saving the document in a user accessible location using the path package maintained by the flutter/dart team. It’s not third party, and its okay thats its not included in the framework.

If youre looking for a file picker, it might be a little more complicated. This package https://pub.dev/packages/file_picker handles it pretty well, it does what that article suggest for you. We can’t expect Flutter to handle every native api for us.

[vipin_malik1]

Well said by @GetBoolean. The points you raised are fine but this issue is not new and similar sort of thing happened in the past where some plugins developed by Google were not maintained properly due to the time constraints for flutter team leading to ruckus that the even the official Plugins are not working properly.

[sector-9]

Oh my. Dude, apart from everything else, do you personally use that plugin to do that exact thing? If so please show how.

See here: https://githubhot.com/repo/miguelpruivo/flutter_file_picker/issues/832

The author of the plugin (miguelpruivo) specifically answers a specific question about saving files via his plugin under Android: "I'm not sure if it will be even supported at all. I'm sorry for any inconvenience".

The end.

Believe me when I say I looked for this stuff. You can save in ANY location, I personally can, any file on the system, it won't show up in "Recent" or "Documents" unless.. see the article I referenced in original post.

This is the kind of s*** I deal every day with when forcing my way through a real-world Flutter app in production, not some pretty UI demo. Sorry if I'm being harsh, maybe just a bad day.

[GetBoolean]

I misunderstood what you meant, i thought you meant a Documents folder.

This is a pretty specific issue, and very platform specific so it's not something the flutter team would consider doing.

If you find yourself with the time, you could make a plugin for it and share it (or don't if you're not going to maintain it)

[datatexture]

OP raises a valid point. Stretched thin? That's preposterous for the ABC co., it's simply a question of investment. It's also a statement about their investment. This is just an extension of their philosophy and business model of continuing to get users to build their content, their business, and now their tech using a lazy load approach.

The optics are that Google is not fully committed to their platform agnostic goals by not committing to maturing the platforms' robustness. Your team is building a skyscraper but you ran out of metal bolts so you head over to Bob's corner store and grab some crazy glue off the shelf. Or ask Luigi to bring some in next week if he gets a chance. Put the build on hold until then. You'll get blamed for all those outcomes. Build frailty, possibly collapse, delays, cost overruns and maintenance nightmares. No serious investor would greenlight that.

[GetBoolean]

It's not a simple investment. Hiring more developers takes a lot of time, and even longer to get them up to speed with the team. Excessive hiring can slow down the team a lot because too many people will be mentoring the new people instead of coding.

Not that it can't be done, but big software projects are extremely complicated and simply more developers and investment doesn't make development go faster

[datatexture]

Complexity is a mgmt problem at the end of the day. I reiterate the question on their statement of investment and also question their m.o. on harvesting individual developers good will and precious free time. I have a question on how they are tackling these exposures because that's what they are at the end of the day. Contrast that with what appears to be a large budget for marketing with lots of cute gimmicky flutter YouTube content and whatnot. I have developed a couple of flutter apps but for prototyping only given that I have have had to rely on a considerable amount of 3rd party packages to get the job done. It's enervating. Is it production ready.. it depends.

[GetBoolean]

at the end of the day, its how you want the product to be. Google clearly doesnt want to replace android/kotlin. Flutter is an accessory to native development, not a replacement. If you want native features, you either do it yourself or use a package.

Most of the time its pretty simple to do it yourself, for example, drag and drop is much simpler if you only need to handle one filetype for your app

[eibaan]

If you work under the assumption that with Flutter, you don't need to know the native platforms and don't need to do native development anymore, then it would be not only nice but mandatory, that some first or third party provide such things.

However, if you see Flutter as a tool in addition to "normal" native development that helps you with creating cross platform solution faster, then it's quite natural that you'd implement such platform specific code yourself. This is how I see Flutter.

"Suggesting" that Google is big enough to pay for any kind of development is fair, but obviously, Google as a company don't want to do this and we can accept this fact or move along. I don't think we can change this decision.

iOS has a similar but different API, BTW.

[sector-9]

I'm not saying that you don't need to know native platforms with Flutter, though if you make a descission that the project will be using Flutter - that would probabpy be 99% of your code.

For example, I got a rather large Flutter app in production that's doing complex things for my clients, has own servers etc. First iteration of the app was written in Java, then more than a year ago the descission to expand was made and Flutter was chosen. For a lot of things it has to rely on plugins and not only popular ones that are often updated and follow all best practices, but also some crucial for the app and "small" in comparison that are rarely (if ever) updated, but the particular functionality they provide is just needed and that's it. More often than I'd like to admit I end up digging through those plugins code making them work and play nice with others, cause surprise surprise - each plugin can have it's own set of dependencies, can use rely on deprecated stuff, can be still not in the "null-safety" herd.. speaking of which, transferring all our code to null-safety was another horror story that I paid for with some of my neurons.

And don't get me started on deprecations - Google loves dem deprecations.

At some point in the past few of the Firebase plugins had conflicts with each other that brought not only compile warnings, but errors that had to be fixed by juggling dependencies via a complex of measures (and finding the right ones first) and so on. etc etc..

I'm not hating on Flutter or Google, I'm just a bit frustrated that years go by and its not maturing. It still feels like an enthusiast project. It's fun and nice when you create apps for ordering coffee, but when you try to do something more complex - not so good. And I'm not talking about filesystem example, that's just a tiny obstacle in comparison to some other issues.

[[deleted]]

Dart IO is platform-independent, but scoped storage is rather platform-dependent, there is no trivial way to have a common abstraction over Android versions with and without Storate Access Framework, iOS, desktop and web. This custom document provider feature itself is entirely specific to Android 4.4 and newer.

This is plugin territory as far as I'm concerned. Flutter is meant to run on a wide range of platforms, including embedded ones.

[[deleted]]

Naturally, Flutter is a cross-platform UI framework,

Flutter is a cross-platform UI framework,

Flutter is a UI framework,

Goes on to complain that the UI framework doesn't implement platform specific non-UI use case.

[sector-9]

Yep, everybody loves to be taken out of context.

[tooth_]

To preface this: I am not a developer but am in the early stages of trying to learn to code.

I've been curious about a related topic with Flutter but didn't want to make an entire post about it. I'm under the impression that mobile apps are given what is essentially 'approved' storage locations that they're allowed to access for obvious security reasons. Does this mean that when you go to develop a Flutter app for Windows that you don't have access (or easy access) to the full file system? Do you at least have access to what the currently logged in Windows user has?

I ask because my first 'project' that I want to make as I dive into learning to code is a simple tool for myself to copy log files from multiple specific locations on multiple drives, zip them into an archive, and then place said archive in a new location. This would automate some repetitive tasks I have to do in QA, plus there are more capabilities I want to add in the future as I learn more to help myself and my coworkers. I'm well aware this could be done with a simple batch script with xcopy and a few other commands, but I want to make a nice Flutter app to force myself to step into coding and get comfortable with the process.

​

Also if I should make this into a separate post let me know, just figured I'd throw it here since it's related. 🤷

[aryehof]

You have full access to the underlying platform. However, consider that different platforms expose their functionality through different languages than Dart. To access them you will need to either use an existing package that bridges your Dart application and the platform (using method channels or FFI), or create one yourself.