Sure except that we already have computers where every app uses the same folder structure, just with some files/folders protected with elevated permissions that aren't accessible to every app. We already have a solution that works and every desktop OS uses. Why would mobile go for a solution that isn't actually usable?
The desktop solution isn't feasible in the mobile context. Even for desktops, you see an increased interest in reproducible/containerized/sandboxed environments with docker, flatpak/snap, immutable operating systems, and so on. It's all about managing complexity.
All of that interest is from people making computers, or people who manage security. Not from people that use computers as part of their life/work (in contrast to those who's work is entirely about the computer itself). From a usability standpoint, this type of sandboxing for every app is cumbersome and all it leads to is users finding unsafe work arounds. I used to be able to use my android phone much more as a regular computer than I can now. And I wanted to make a simple app for myself to allow me to automatically copy and catalog photos from my cameras sd card to an external HDD, and I literally cannot do this without jumping through a million permissions and API hoops on Android even though I never plan on publishing this app for others to use. It became such a pain to figure out how to get access to the folders I would need, I just gave up on the entire project. I essentially needed a tool to systematically copy and rename files, and it's nearly impossible because of these nonsensical policies.
Until it stops me from doing something I want to do and know is safe like modifying my Obsidian notes that are on Nextcloud from my phone. Why can't it simply prompt me to give Obsidian rw access to that directory or even have some way to allow me to manually change the permissions myself to get it working.
The right design decision isn't necessarily the best for a specific use case. Making the system overall rigid and strict by default makes the whole thing more manageable. Adding features like "user initiated opt-in shared filesystem access for sandboxed apps" increases complexity, hence cost and maintenance burden and likelihood of bugs. Not to say this feature isn't worth it, but it's necessary to accept some rough edges in some use cases.
They're not taken for granted, they are compensated by the corporations I'm purchasing the device from. Again, these problems have already been solved on desktop for decades. They're not breaking new ground here.
They’re not taken for granted, they are compensated by the corporations I’m purchasing the device from.
You're taking for granted the requirements that need to be met in order for the device you're purchasing to be technically and commercially viable. It needs to work, it needs to be safe, it needs to comply with privacy regulations and so on.
Again, these problems have already been solved on desktop for decades. They’re not breaking new ground here.
Managing complexity with containerization and sandboxing is occurring on desktops too. It's more mainstream in the mobile ecosystem because of essential differences in the ways users interact with phones versus desktops.
Managing complexity with containerization and sandboxing is occurring on desktops too.
Yes and if I want something in a container I do so. It's my choice. I'm not forced into it by design choices made based on being too cheap to go beyond the absolute bare minimum.
It’s either in
/sdcard/Downloads
or/external/emulated/0/android/data/com.google.chrome/Downloads
. Couldn’t be easier.Would certainly be easier if there wasn't an or in your statement.
Best I can do is three more ors.
Except when it is not....
For example Boost saves photo is some photo folder somewhere.
The only way i can find anything is using a photo app and scanning my entire phone to find things.
I was being facetious. Yeah, every app saves into a different location. It’s bonkers.
Sandboxing is a good thing. It makes it a lot easier and safer for billions of devices to run millions of apps.
Sure except that we already have computers where every app uses the same folder structure, just with some files/folders protected with elevated permissions that aren't accessible to every app. We already have a solution that works and every desktop OS uses. Why would mobile go for a solution that isn't actually usable?
The desktop solution isn't feasible in the mobile context. Even for desktops, you see an increased interest in reproducible/containerized/sandboxed environments with docker, flatpak/snap, immutable operating systems, and so on. It's all about managing complexity.
All of that interest is from people making computers, or people who manage security. Not from people that use computers as part of their life/work (in contrast to those who's work is entirely about the computer itself). From a usability standpoint, this type of sandboxing for every app is cumbersome and all it leads to is users finding unsafe work arounds. I used to be able to use my android phone much more as a regular computer than I can now. And I wanted to make a simple app for myself to allow me to automatically copy and catalog photos from my cameras sd card to an external HDD, and I literally cannot do this without jumping through a million permissions and API hoops on Android even though I never plan on publishing this app for others to use. It became such a pain to figure out how to get access to the folders I would need, I just gave up on the entire project. I essentially needed a tool to systematically copy and rename files, and it's nearly impossible because of these nonsensical policies.
like the people who make phones for other people to use
Until it stops me from doing something I want to do and know is safe like modifying my Obsidian notes that are on Nextcloud from my phone. Why can't it simply prompt me to give Obsidian rw access to that directory or even have some way to allow me to manually change the permissions myself to get it working.
The right design decision isn't necessarily the best for a specific use case. Making the system overall rigid and strict by default makes the whole thing more manageable. Adding features like "user initiated opt-in shared filesystem access for sandboxed apps" increases complexity, hence cost and maintenance burden and likelihood of bugs. Not to say this feature isn't worth it, but it's necessary to accept some rough edges in some use cases.
More manageable for who? Certainly not me. Which, considering I own the device, is bullshit. Desktop apps have had this figured out for decades.
The people who build the device and software ecosystem you take for granted.
They're not taken for granted, they are compensated by the corporations I'm purchasing the device from. Again, these problems have already been solved on desktop for decades. They're not breaking new ground here.
You're taking for granted the requirements that need to be met in order for the device you're purchasing to be technically and commercially viable. It needs to work, it needs to be safe, it needs to comply with privacy regulations and so on.
Managing complexity with containerization and sandboxing is occurring on desktops too. It's more mainstream in the mobile ecosystem because of essential differences in the ways users interact with phones versus desktops.
Yes and if I want something in a container I do so. It's my choice. I'm not forced into it by design choices made based on being too cheap to go beyond the absolute bare minimum.
Just go write your own Android then?
Boost saves in
/Pictures/Boost
.Don't you pick on first run?
It's a newer api but I know Sync does that, as well as mgit and a few others.
oh yeah? now list paths for all the other applications
You have other applications?