• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

[APP][5.0+][ROOT/NONROOT][GPLv3] Material Files (open source file manager)

Search This thread

gdgsdg123

Senior Member
Nov 10, 2017
420
404
It has to be magnitudes slower than JNI because every time it is creating a new process, waiting for it to finish and collecting its output. This will be a huge slow-down comparing to any number of layers of abstraction within Java.
But what's really going on under those layers of abstraction?..


Deep inside, there's no process. (it doesn't really exist, it's merely an interpretation... a layer of abstraction)

What's there actually, is the actuation of the hardware.



`ls` isn't something completed and untouchable, and it can be inspected, modified and improved.
It serves well as a general purpose utility.

And many things that achieve a similar functionality, eventually (or inevitably...) took a similar routine.



The cause of Cabinet stopped working...
Thanks for the info.



I believe it's fine to say that the app is utilizing Linux syscalls (there's no other way of using Linux syscalls in Java).
The term "syscall" itself is confusing in this context...
 
  • Like
Reactions: Ultramanoid
Dec 2, 2019
27
30
But what's really going on under those layers of abstraction?..
If you mean abstraction in the Java NIO2 file API, it's just some method calls. But it helps organizing code in an meaningful way so it's more readable, maintainable and less prone to bugs.

Deep inside, there's no process. (it doesn't really exist, it's merely an interpretation... a layer of abstraction)
If you use `ls`, you have to start a new `ls` process, and it slows down significantly.

What's there actually, is the actuation of the hardware.
Of course things eventually runs on hardware, but spinning off a new process every time is just significantly slower than using syscalls within one's own process directly. Different code may lead to significantly different performance and I believe that was what we were talking about, and talking hardware all of a sudden is a over generalization.

It serves well as a general purpose utility.
Yes, but not for parsing output, nor for performance.
And many things that achieve a similar functionality, eventually (or inevitably...) took a similar routine.
Yes, that's why I refered to their implementation before writing my own.

The term "syscall" itself is confusing in this context...
It isn't, because syscalls are just calls into the Linux kernel like `opendir` etc.
 
Dec 2, 2019
27
30
Thank you for the latest version.

What is this feature about ?

https://github.com/zhanghai/MaterialFiles/commit/70d3e1ec0a98da2971292f210c45262b2d854fdb

I don't use any of those, so I don't quite get it.
 

As you can see in the commit, it is about two extra standard directories for the location where Tecent QQ and WeChat, both popular instant messenger apps in China that doesn't follow recommended practice to put downloaded files. The feature just makes it easier for people who have these two apps to find their downloaded files. The commit you mentioned is about they recently moved their download directory deeper into their external data directory for Android 10 storage restriction (which I don't think is a move in the right direction, they should just put files under Download/AppName), so I allowed both the old and the new paths for their standard directories.

I personally dislike QQ and WeChat (for their design, functionality, bloatedness and privacy) but still have to use them because most of my friends and relatives are using them. And there are a lot of Chinese users in a similar situation. I understand that although the two standard directories will be useful for people who have to use them, however for people who hate them/never use them it's not only useless, but also confusing and scary (people might wonder, how is this app linked to Tencent - in fact nothing at all), so I made them visible only when the directories do exist, which means the user is already using QQ or WeChat and the feature might be helpful.

I hope you can understand this, and if you are still concerned, you can keep auditing the source code where I won't be able to hide anything.
 
Dec 2, 2019
27
30
Could there be a setting to disable swiping down to refresh ?

( Just have been reminded in another thread that I am not the only one who finds it too often interferes with navigation... )
 

Pull to refresh requires swiping down while the list is at the start, but standard Android navigation is swiping up from navigation bar in the bottom. Could you clarify why would it interfere with navigation?
 
  • Like
Reactions: Ultramanoid

Ultramanoid

Senior Member
Apr 24, 2011
3,581
5,505
日本
Pull to refresh requires swiping down while the list is at the start, but standard Android navigation is swiping up from navigation bar in the bottom. Could you clarify why would it interfere with navigation?

By navigation I mean selecting and scrolling up and down through lists of files and folders within the application.

It is not always obvious when you're at the start of a list, particularly jumping between windows when the side scroll is not visible.

On top of that, there are touch screens and touch screens, on some of my devices the refresh gets triggered correctly, but on others half the time it does when it shouldn't, tap to select or scroll and down comes the unwanted refresh... Which means having to stop, wait until the loader animation retreats back up or the refresh is done, then try again the selection or scroll actually intended originally. Multiply by dozens of times a day, it is a considerable annoyance and waste of time.

Edit : May I add, this application does a superb job at updating listings in real time ! I can't even think of a single time I have wanted or needed to use the refresh swipe anyway. It's always been unintended.
 
 
Last edited:
Dec 2, 2019
27
30
By navigation I mean selecting and scrolling up and down through lists of files and folders within the application.

It is not always obvious when you're at the start of a list, particularly jumping between windows when the side scroll is not visible.

On top of that, there are touch screens and touch screens, on some of my devices the refresh gets triggered correctly, but on others half the time it does when it shouldn't, tap to select or scroll and down comes the unwanted refresh... Which means having to stop, wait until the loader animation retreats back up or the refresh is done, then try again the selection or scroll actually intended originally. Multiply by dozens of times a day, it is a considerable annoyance and waste of time.

Edit : May I add, this application does a superb job at updating listings in real time ! I can't even think of a single time I have wanted or needed to use the refresh swipe anyway. It's always been unintended.
 

Sorry for the late reply. I've been hesitating on whether to add this, and I've only recently got more time to work on this project. I started working on some UI improvements days ago and I've been considering this feature again. The problem with adding a toggle for pull-to-refresh is that there are other places besides the main file list that may use pull-to-refresh (e.g. file properties, probably more in the future), and in those places there may not be an alternative refresh mechanism due to design reasons, so having that toggle doesn't make sense for the whole app. Meanwhile, it's kind of weird to have a toggle that only governs the pull-to-refresh for the file list but not other places in the app, because I haven't heard about other complaints regarding this and it seems too specific an addition for everyone. So I'm still leaning towards not adding such a setting.

On the other hand, I noticed that you were auditing my commits earlier, so maybe you do know something about Android development? In that case, you should be able to just add andorid:enabled="false" to the SwipeRefreshLayout for the file list, then compile the app, and you can have a version of this app with pull-to-refresh disabled for file list.
 
  • Like
Reactions: Ultramanoid

Bracher

Senior Member
Sep 18, 2009
193
48
Hello, I have a problem with FTP-Server, I can't open an FTP-connection with the SD-Card, is there any chanc to solve this problem? Kind regards
 

Ultramanoid

Senior Member
Apr 24, 2011
3,581
5,505
日本
As the comment says here :


... Please consider again allowing full file names. I also couldn't care less about fast scrolling, and even if I did, I can't use an application where all file names look exactly the same in listings. This is the only reason why, while I test every version, I can't actually use it.

I've noticed the new options in 1.2, but neither truncating at different points or having to wait for the file name to scroll sideways provides a solution to this.

Edit : May I add, with the craze for super tall, skinny screen ratios, 18:9, 21:9, now this particular issue is even worse. That old screenshot I linked to was on a 16:9 screen and it was bad already. Guessing names or having to check properties of each file to see the name is just out of the question. It makes file management impossible.
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 7
    Material Files

    launcher_icon.png


    An open source Material Design file manager, for Android 5.0+.
    https://github.com/zhanghai/MaterialFiles

    Downloads

    Screenshots



    Features
    • Open source: Lightweight, clean and secure.
    • Material Design: Like the good old Cabinet with attention into details, and optional MD2 style.
    • Breadcrumbs: Navigate in the filesystem with ease.
    • Root support: View and manage files with root access.
    • Archive support: View, extract and create common compressed files.
    • Themes: Customizable UI colors and night mode.
    • Linux-aware: Like Nautilus, knows symbolic links, file permissions and SELinux context.
    • Robust: Uses Linux system calls under the hood, not yet another ls parser.
    • Well-implemented: Built upon the right things, including Java NIO2 File API and LiveData.

    Why Material Files?
    Because I like Material Design, and clean Material Design.

    There are already a handful of powerful file managers, but most of them just isn't Material Design. And even among the ones with Material Design, they usually have various minor design flaws (layout, alignment, padding, icon, font, etc) across the app which makes me uncomfortable, while still being minor enough so that not everybody would care to fix it. So I had to create my own.

    Because I want an open source file manager.

    Most of the popular and reliable file managers are just closed source, and I sometimes use them to view and modify files that require root access. But deep down inside, I just feel uneasy with giving any closed source app the root access to my device. After all, that means giving literally full access to my device, which stays with me every day and stores my own information, and what apps do with such access merely depends on their good intent.

    Because I want a file manager that is implemented the right way.

    This app implemented Java NIO2 File API as its backend, instead of inventing a custom model for file information/operations, which often gets coupled with UI logic and grows into a mixture of everything. On the contrary, a decoupled backend allows cleaner code (which means less bugs), and easier addition of support for other file systems.

    This app doesn't use java.io.File or parse the output of ls, but built bindings to Linux syscalls to properly access the file system. java.io.File is an old API missing many features, and just can't handle things like symbolic links correctly, which is the reason why many people rather parse ls instead. However parsing the output ls is not only slow, but also unreliable, which made Cabinet broken on newer Android versions. By virtue of using Linux syscalls, this app is able to be fast and smooth, and handle advanced things like Linux permissions, symbolic links and even SELinux context. It can also handle file names with invalid UTF-8 encoding because paths are not naively stored as Java Strings, which most file managers does and fails during file operation.

    This app built its frontend upon modern ViewModel and LiveData which enables a clear code structure and support for rotation. It also properly handles things like errors during file operation, file conflicts and foreground/background state.

    In a word, this app tries to follow the best practices on Android and do the right thing, while keeping its source code clean and maintainable.

    Because I know people can do it right.

    Nautilus is a beautifully-designed and user-friendly file manager on Linux desktop, and it's fully Linux-aware. Phonograph is an open source Material Design music player app (which I've been using for years), and it has just the right Material Design and implementation.

    So, it's time for yet another Android file manager.


    License
    GPL-3.0-or-later
    Code:
    Copyright (C) 2018 Hai Zhang
    
    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.
    
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    
    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <https://www.gnu.org/licenses/>.

    XDA:DevDB Information
    Material Files, App for all devices (see above for details)

    Contributors
    dreamingincode
    Source Code: https://github.com/zhanghai/MaterialFiles


    Version Information
    Status: Stable
    Current Stable Version: 1.0.0
    Stable Release Date: 2019-12-02

    Created 2019-12-08
    Last Updated 2019-12-09
    3
    Thank you for the latest version.

    What is this feature about ?

    https://github.com/zhanghai/MaterialFiles/commit/70d3e1ec0a98da2971292f210c45262b2d854fdb

    I don't use any of those, so I don't quite get it.
     

    As you can see in the commit, it is about two extra standard directories for the location where Tecent QQ and WeChat, both popular instant messenger apps in China that doesn't follow recommended practice to put downloaded files. The feature just makes it easier for people who have these two apps to find their downloaded files. The commit you mentioned is about they recently moved their download directory deeper into their external data directory for Android 10 storage restriction (which I don't think is a move in the right direction, they should just put files under Download/AppName), so I allowed both the old and the new paths for their standard directories.

    I personally dislike QQ and WeChat (for their design, functionality, bloatedness and privacy) but still have to use them because most of my friends and relatives are using them. And there are a lot of Chinese users in a similar situation. I understand that although the two standard directories will be useful for people who have to use them, however for people who hate them/never use them it's not only useless, but also confusing and scary (people might wonder, how is this app linked to Tencent - in fact nothing at all), so I made them visible only when the directories do exist, which means the user is already using QQ or WeChat and the feature might be helpful.

    I hope you can understand this, and if you are still concerned, you can keep auditing the source code where I won't be able to hide anything.
    3
    Being of higher level of abstraction does not necessarily ensure being of higher level of quality...
    ...what's under the hood may be not much different from another `ls` parser.
    And usually... those abstraction layers inevitably introduced some losses in the runtime efficiency of the program.
    There must be an abstraction to represent files and paths in a file manager written in Java, however you get the file data (via `ls`, Java File or custom native things). Java NIO2 file API is a good abstraction so it's an improvement over bad ones.
    It's very diffrent from an `ls` parser in that it doesn't parse the output of an unknown version of a binary, and it doesn't start new processes.

    It doesn't have to be slow... nor unreliable. When properly implemented.
    If necessary, you can adapt your own version of `ls` specifically optimized for your specific purpose, to reduce the performance overhead. (though generic `ls` already works well... for most purposes, and usually still faster than calling similar functionalities from the abstraction layer of higher levels)
    Indeed anything unfamiliar can be considered unreliable... though `ls` indeed gives consistent output.
    It is unreliable and cannot be properly implemented, because things like newline in file name. In a word, it doesn't provide an option to separate lines with a NUL byte, and thus cannot be reliably parsed. `find` provides such an option as mentioned in the HackerNews thread, but it cannot output all the needed file metadata like `ls` and launching separate processes to retrieve metadata is painfully slower.
    It has to be magnitudes slower than JNI because every time it is creating a new process, waiting for it to finish and collecting its output. This will be a huge slow-down comparing to any number of layers of abstraction within Java.
    Building and bundling `ls` only solves parsing, but cannot avoid creating a new process every time in any way.
    `ls` isn't something completed and untouchable, and it can be inspected, modified and improved. I consulted the source code of `ls` (and various others) in toybox (the AOSP implementation now) and OpenJDK NIO2 implementation before writing my own, not inventing something new.

    I believe the cause is this. (check the adjacent posts too)
    Something about Google's whims: the approach towards "No file in the system"... (the exact opposite of the creed of Unix)
    The cause of Cabinet stopped working is unlikely the Scoped Storage work happening in Q and beyond, because it is broken on P. It is showing every file/folder name as `0` which is likely due to modification to `ls` output that added a new column, and Cabinet thought that was where the file name should be.
    About the trend in Android towards scoped storage: Rooting itself is against the Android permission system, etc, and is much less supported than raw file access. So as long as root is supported on Android, having a Linux file manager makes sense to me.

    More accurately, it's calling native Linux applications/libraries through the JNI.
    Yes this is the point. Using JNI to call into a custom native library avoids the overhead of creating new processes. However, these JNI calls are simple wrappers around the original Linux syscalls, so I believe it's fine to say that the app is utilizing Linux syscalls (there's no other way of using Linux syscalls in Java).
    syscalls.c is the source code for syscall wrappers written in C. Syscalls.java is the Java interface. As you can see, they are merely wrappers around the original syscalls.
    2
    But what's really going on under those layers of abstraction?..
    If you mean abstraction in the Java NIO2 file API, it's just some method calls. But it helps organizing code in an meaningful way so it's more readable, maintainable and less prone to bugs.

    Deep inside, there's no process. (it doesn't really exist, it's merely an interpretation... a layer of abstraction)
    If you use `ls`, you have to start a new `ls` process, and it slows down significantly.

    What's there actually, is the actuation of the hardware.
    Of course things eventually runs on hardware, but spinning off a new process every time is just significantly slower than using syscalls within one's own process directly. Different code may lead to significantly different performance and I believe that was what we were talking about, and talking hardware all of a sudden is a over generalization.

    It serves well as a general purpose utility.
    Yes, but not for parsing output, nor for performance.
    And many things that achieve a similar functionality, eventually (or inevitably...) took a similar routine.
    Yes, that's why I refered to their implementation before writing my own.

    The term "syscall" itself is confusing in this context...
    It isn't, because syscalls are just calls into the Linux kernel like `opendir` etc.
    2
    I'm not sure what fast scrolling means, but at any rate if all filenames look exactly the same, no operation is possible. Here's an example comparing with FX.
     

    Oh, fast scrolling means if you drag the scrollbar, the scrollbar actually follows you so that you can scroll through the entire content quickly. That requires knowing the item height without laying all of them out, so dynamic item height will most likely break it.

    Maybe I should consider adding an option to make all items take the height of a two-line file name. Created https://github.com/zhanghai/MaterialFiles/issues/205.

    Btw I also happened to listen to that song, a really beatiful one :) It has been in my personal music library for years, the piano arranged version.