Same reason I can't leave solid explorer, the features. Being able to manage my NAS in one pane then another storage in another pane and dragging files between them is essential.
Contrary to popular belief, Java (well, Android) apps can be quite small if you have no external dependencies and minimal graphical resources. Once you depend on something like Jetpack Compose, you're pulling in about a hundred libraries and adding a few MB before minifying.
Yup! It's a major step in building any Java application. Things like stripping symbol names, removing unused APIs, and processing non-java assets like images. For Android applications Gradle handles this by invoking some Android specific utilities alongside the java ones, but there's tons of build tools out there for Java that handle doing these things for everything from Blu-Rays to web apps.
Unfortunately you can't treeshake a language that supports reflections. So it's not like a C++ program where unused parts get dropped.
You can manually remove dependencies or.. I think in the Android world you specify what classes can be reflected on and then strip unused code with Proguard (though I could never get it working with Clojure)
Would love to be corrected if I got any of it wrong
I'm afraid you did get it wrong - it's very standard to do that on all Android apps. The part that you missed is that reflection is rarely used in production apps (partially because for a long time, reflection was VERY expensive on Dalvik/ART runtimes) and can be easily handled by configuration for minifier/optimizer to explicitly keep code.
Even C++ you mention does that - you have explicit __attribute__ calls to avoid linker from dropping code you want to keep for reflection purposes.
Yes, it's enabled by default even in tutorial Android apps - Proguard was the tool used in olden days and has now been replaced by Google developed R8 optimizer/minifier.
Is it even supported way to write Android apps without compat libs? I tried to do that, and struggled. I hate dependencies and prefer to avoid them, however with Android that seems almost unavoidable (or requires expert knowledge of quirks of different Android versions, I guess).
AppCompat/JetPack don't do anything magical - they are just regular open source libraries.
If your app wants to use features which behave differently depending on the OS version, you have to if/else over the OS version. Also, note that the platform's Fragment implementation is deprecated and you might miss ViewModel.
Yes, after all, the Compat libs themselves need to talk to OS. But there's a reason why you were struggling - those libs have code that handles changes of API between different OS versions and there's been many of those during 14 major Android releases.
Patching up those differences is after all the primary purpose of compat libs.
Though it's not without compromises — because of Google's stupid policy that "nothing goes into the system unless it needs direct access to privileged or private system components", RecyclerView, ViewPager, and some other basic UI components are still AndroidX libraries that depend on AppCompat for no good reason. I had to fork them to rid them of that dependency: https://github.com/grishka/LiteX
Is this a supported thing to do? No. Do I care about it being unsupported? Also no.
It's not difficult to write sub-10Mb release APK for a production app with lots of features while using all the compat libraries and other useful dependencies (that do make life a lot easier). Our app is ~7Mb, and we don't even heavily optimize for APK size.
IME biggest dependencies are not compat libraries or _typical_ dependencies that Android apps need (like image loaders), but anything that involves native code. Media capabilities is one thing, but also solutions for analytics/user monitoring/SDKs for integration with Important Companies are more often than not _massive_, and companies like to track the user from many angles ¯\_(ツ)_/¯
I'm curious, does or is it possible for this to support the APIs available on newer Android versions like scoped storage? Would there even be any benefit to supporting those APIs in an app like this?
IIRC, there are ways to use stuff from newer API levels (or not use newer stuff, if you're on an older system) on android but it's harder than just dropping support. This seems to have a minimum api level of 1, a targetsdk of 29 (android 10) and a compilesdk of 33 (android 13, minimum for going on the play store)
I think android studio even warns you if you call a function from an api level newer than your minimum outside of an if statement checking that you're on a newer version.
I'm a long-time user of Solid Explorer. It's my favorite file manager app. I even have it setup to access my Nextcloud files (via webdav). The dual pane layout of SE makes copying/pasting/moving files easier than most others I've tried.
I haven't used Solid in years, how is it doing nowadays? Since I switched to FX, I have not ever changed, it's just so darn powerful, well designed, small and has no ads (you can buy premium for a tiny price).
It's one of those bastions of incredible app building that seemed much more common back in the day.
Still gimped in comparison. You have to manually open a menu just to see what windows you have open and to switch between them instead of always having a tab bar on the screen and swiping left and right to switch.
I wonder how small this could be if using flutter. A few years ago they had a min size of about 5mb.
I've been thinking of trying flutter with a small app so I could share URLs to it and it would open them up in the archive.is version in Firefox on android.
I already made a PWA but Firefox PWAs don't accept text to be shared to them.
I am not sure if Flutter can handle different large files. I am not entirely sure if there was a file explorer app written with a cross platform framework.
Flutter ignores most of the OS-provided functionality and packs half an OS worth of libraries into an app. That includes an entire UI framework and a bytecode VM with its own runtime library. "Flutter" and "small" can not be used in the same sentence.
But at least the app will look the same on all the devices/ Android versions without having to look like Android 2.0 because that's the minimum SDK you're targeting
Natively you can use a different theme depending on which Android version the app is running on. The 2.x one on 2.x, Holo on 4.x, and Material on 5 and newer.
Casual reminder that Android apps can be tiny. Of course, you will be limited to base framework, but you'll be getting much faster build times and many happy users. Material-like design applications are also possible, just target higher SDK. Although while you'll have to implement some more complicated components yourself, resulting application size will be way less than 1MB, maybe even less than 100KB. Dear Android developers, and especially newcomers, in 2024, please try building tiny applications.
I've been using this since Simple Mobile Tools was sold. It works well. My only real complaint is that the app icon name starts with "Little" so it's sorted under L, not F. It makes it hard to find.
Yep most certainly. Those are pretty neat little devices actually. Easy to put into developer mode and you can use wireless adb to get a shell and install apps, but to me the killer feature is being able to send it "button press" commands over adb. Basically a virtual remote control from the CLI.
I used this to write myself some bash functions so I can pause the chromecast from the CLI. Once connected (with for example `adb connect 192.168.1.243`), you can send a play/pause through adb with just:
adb shell input keyevent KEYCODE_MEDIA_PLAY_PAUSE
I can also trivially start an app like Jellyfin with:
adb shell am start -a android.intent.action.VIEW -n org.jellyfin.androidtv/.ui.startup.StartupActivity
How does the app handle the integration of newer Android file access protocols, like Storage Access Framework (SAF), especially for operations like multi-share or file path copying in Android versions 10 and above?
Side question: since this is GPL3, how does that work with APK signing? A quick peek at the docs [1] makes it seem like this would be just as much a problem on F-Droid as any other app store.
what are you even talking about? linked page makes no mention to any gpl3 consideration. and i don't see how distribution peculiarities have anything to do with the license.
are you just attempting a low effort gpl3 FUD or are you honestly confused at something concrete that you failed to describe?
I was honestly asking about the intersection of app store code signing and the anti-tivoization clause in 3.0 (I assumed everyone knew that was the major change or 3.0), but I guess I touched a nerve.
I don't think signing counts as a modification, or there's some aspect of your query I'm not getting.
Either way, the GPL 3 was designed with signing already being a thing, GPG had been out for 5+ years. And if signing broke the GPL, I imagine Stallman would have been raising a huge fit about it for decades.
app store code signing is no different than a mirror having a private ssl keys for the domain you are downloading from
or a closed source including a gpl3 Library in its packaging.
both have nothing with the license and are a common FUD argument by people who do not like the implied freedoms of the gpl when arguing for more permissively comercial licenses, so apologize if i wrongly mistook you for the more probable case.
Is there anything that prevents you from doing that today? I mean the app in this post still seems to work. Apart from some parts of the system that have been pretty much locked down, I think one reason that apps are much larger today is that our expectations increased dramatically.
My SO rewrote the robotsanywhere app to be compliant with android 5+ and the compliance stuff made it balloon from 250kb to 5mb. I was a bit humiliated.
Java apps can be rather small. I've worked on the Skype J2ME[1] version and this was around 300kB if I recall correctly (including all resources such as translations in various languages and images).
This looks nice. Useful and open source.
I find an on-device file manager really useful. I really like that Cx File Explorer has a built-in text editor and can access my WebDAV files: https://play.google.com/store/apps/details?id=com.cxinventor...
It is the glue that makes my phone much more productive, and not just a consuming device.
CX is good stuff all around. Also navigates system files and SMB shares (auth'd and anon).
I love Cx File Explorer, I just wish it had a split screen view like Solid Explorer has.
On a phone it's fine, but on a tablet, being able to copy things between the two screens is a game changer.
I still prefer Cx because, for some reason, it's about 2.5x faster than Solid when copying files from an SMB volume.
Why does a file explorer need a privacy policy? If it's not Google sharing your mobile number with advertisers it's app developers.
Same reason I can't leave solid explorer, the features. Being able to manage my NAS in one pane then another storage in another pane and dragging files between them is essential.
Some people still care about efficiency!
Contrary to popular belief, Java (well, Android) apps can be quite small if you have no external dependencies and minimal graphical resources. Once you depend on something like Jetpack Compose, you're pulling in about a hundred libraries and adding a few MB before minifying.
Is minifying a concern in the Java world?
Yup! It's a major step in building any Java application. Things like stripping symbol names, removing unused APIs, and processing non-java assets like images. For Android applications Gradle handles this by invoking some Android specific utilities alongside the java ones, but there's tons of build tools out there for Java that handle doing these things for everything from Blu-Rays to web apps.
Not any Java application, only on Android and embedded.
I never ever saw anyone doing it for desktop or server applications.
Unfortunately you can't treeshake a language that supports reflections. So it's not like a C++ program where unused parts get dropped.
You can manually remove dependencies or.. I think in the Android world you specify what classes can be reflected on and then strip unused code with Proguard (though I could never get it working with Clojure)
Would love to be corrected if I got any of it wrong
> Unfortunately you can't treeshake a language that supports reflections.
I’m pretty sure that’s exactly what the Google Closure Compiler does: https://developers.google.com/closure/compiler/docs/limitati...
Though it has a ton of restrictions on how you write code and how you can use reflection.
I'm afraid you did get it wrong - it's very standard to do that on all Android apps. The part that you missed is that reflection is rarely used in production apps (partially because for a long time, reflection was VERY expensive on Dalvik/ART runtimes) and can be easily handled by configuration for minifier/optimizer to explicitly keep code.
Even C++ you mention does that - you have explicit __attribute__ calls to avoid linker from dropping code you want to keep for reflection purposes.
>Unfortunately you can't treeshake a language that supports reflections.
Like JavaScript?
Yes, you can't treeshake Javascript. You can treeshake a subset of Javascript.
If you are limiting tooling to subsets, you can also compile subsets of Python or Javascript to machine code.
You surely can, it is a thing since Smalltalk and Common Lisp images.
On Java's case, all AOT toolchains and embedded deployment workflows have supported similar capabilities.
Yes, it's enabled by default even in tutorial Android apps - Proguard was the tool used in olden days and has now been replaced by Google developed R8 optimizer/minifier.
Yup! Most used to rely on Proguard but nowadays, Android ships an alternative called R8: https://developer.android.com/build/shrink-code
Is it even supported way to write Android apps without compat libs? I tried to do that, and struggled. I hate dependencies and prefer to avoid them, however with Android that seems almost unavoidable (or requires expert knowledge of quirks of different Android versions, I guess).
AppCompat/JetPack don't do anything magical - they are just regular open source libraries.
If your app wants to use features which behave differently depending on the OS version, you have to if/else over the OS version. Also, note that the platform's Fragment implementation is deprecated and you might miss ViewModel.
Yes, after all, the Compat libs themselves need to talk to OS. But there's a reason why you were struggling - those libs have code that handles changes of API between different OS versions and there's been many of those during 14 major Android releases. Patching up those differences is after all the primary purpose of compat libs.
If you target latest OS - yes.
Mastodon app is built like that, the release apk is around 3 Mb, ~half of which is resources: https://github.com/mastodon/mastodon-android
Though it's not without compromises — because of Google's stupid policy that "nothing goes into the system unless it needs direct access to privileged or private system components", RecyclerView, ViewPager, and some other basic UI components are still AndroidX libraries that depend on AppCompat for no good reason. I had to fork them to rid them of that dependency: https://github.com/grishka/LiteX
Is this a supported thing to do? No. Do I care about it being unsupported? Also no.
It's not difficult to write sub-10Mb release APK for a production app with lots of features while using all the compat libraries and other useful dependencies (that do make life a lot easier). Our app is ~7Mb, and we don't even heavily optimize for APK size.
IME biggest dependencies are not compat libraries or _typical_ dependencies that Android apps need (like image loaders), but anything that involves native code. Media capabilities is one thing, but also solutions for analytics/user monitoring/SDKs for integration with Important Companies are more often than not _massive_, and companies like to track the user from many angles ¯\_(ツ)_/¯
I'm curious, does or is it possible for this to support the APIs available on newer Android versions like scoped storage? Would there even be any benefit to supporting those APIs in an app like this?
IIRC, there are ways to use stuff from newer API levels (or not use newer stuff, if you're on an older system) on android but it's harder than just dropping support. This seems to have a minimum api level of 1, a targetsdk of 29 (android 10) and a compilesdk of 33 (android 13, minimum for going on the play store)
I think android studio even warns you if you call a function from an api level newer than your minimum outside of an if statement checking that you're on a newer version.
In general, file explorer apps are one of the rare apps that are allowed to opt out of scoped storage, so it doesn't really make much sense for them.
Supporiting all file operations via SAF while keeping compatibility back to Android 1.0 with old APIs would also be quite a hellish operation.
Gods I miss ES File Explorer Pro. Made everything on the market today look clumsy and backwards in comparison.
What about solid explorer? Seems to be mostly the same with better UI.
I'm a long-time user of Solid Explorer. It's my favorite file manager app. I even have it setup to access my Nextcloud files (via webdav). The dual pane layout of SE makes copying/pasting/moving files easier than most others I've tried.
I haven't used Solid in years, how is it doing nowadays? Since I switched to FX, I have not ever changed, it's just so darn powerful, well designed, small and has no ads (you can buy premium for a tiny price). It's one of those bastions of incredible app building that seemed much more common back in the day.
> Since I switched to FX
Indeed, never looked back after trying FX.
Ooo, FX seems nice. I definitely like a lot of its interface concepts.
What about Google Files Go? It kind of presents itself as a file deletion/clean up app, but works as a decent file manager as well.
What about FX File Explorer?
http://www.nextapp.com/fx/
Still gimped in comparison. You have to manually open a menu just to see what windows you have open and to switch between them instead of always having a tab bar on the screen and swiping left and right to switch.
I wonder how small this could be if using flutter. A few years ago they had a min size of about 5mb. I've been thinking of trying flutter with a small app so I could share URLs to it and it would open them up in the archive.is version in Firefox on android. I already made a PWA but Firefox PWAs don't accept text to be shared to them.
Under 40kb *edit according to fdroid
That's the size of the current app which doesn't use flutter.
using flutter would make it bigger not smaller
I am not sure if Flutter can handle different large files. I am not entirely sure if there was a file explorer app written with a cross platform framework.
Flutter ignores most of the OS-provided functionality and packs half an OS worth of libraries into an app. That includes an entire UI framework and a bytecode VM with its own runtime library. "Flutter" and "small" can not be used in the same sentence.
But at least the app will look the same on all the devices/ Android versions without having to look like Android 2.0 because that's the minimum SDK you're targeting
I can live with looking like 2.0. I could use navigation from the top bar, however.
I highly doubt Flutter can run on Android 2.x.
Natively you can use a different theme depending on which Android version the app is running on. The 2.x one on 2.x, Holo on 4.x, and Material on 5 and newer.
Agreed. Unless that sentence contains a "not" somewhere :-)
F-Droid Link: https://f-droid.org/en/packages/com.martinmimigames.simplefi...
Can it log into SMB shares on the local network?
No, this is a file manager.
That's not an unreasonable question since most 'file manager' apps on Android can do that.
Are files not stored in SMB networked drives? Or are those files not to be managed?
Everything is a file, so can it manage everything ?
Casual reminder that Android apps can be tiny. Of course, you will be limited to base framework, but you'll be getting much faster build times and many happy users. Material-like design applications are also possible, just target higher SDK. Although while you'll have to implement some more complicated components yourself, resulting application size will be way less than 1MB, maybe even less than 100KB. Dear Android developers, and especially newcomers, in 2024, please try building tiny applications.
I've been using this since Simple Mobile Tools was sold. It works well. My only real complaint is that the app icon name starts with "Little" so it's sorted under L, not F. It makes it hard to find.
Wait wait wait. Simple Mobile Tools was sold? The apps with all the orange icons, and was open source? That one?
> Simple Mobile Tools was sold?
It looks like Tibor and Naveen are still in command:
https://github.com/SimpleMobileTools
Yes: https://news.ycombinator.com/item?id=38505229
I might have used this yesterday when getting WireGuard working on a Google Chromecast.
Moving the conf file to it, then picking finding and selecting it wasn't for the faint of heart. Once imported though, WireGuard works perfectly.
Wait, how do you setup wireguard on a chromecast?
He probably means google chromecast with TV.
Yep most certainly. Those are pretty neat little devices actually. Easy to put into developer mode and you can use wireless adb to get a shell and install apps, but to me the killer feature is being able to send it "button press" commands over adb. Basically a virtual remote control from the CLI.
I used this to write myself some bash functions so I can pause the chromecast from the CLI. Once connected (with for example `adb connect 192.168.1.243`), you can send a play/pause through adb with just:
I can also trivially start an app like Jellyfin with:
If it's helpful to anyone, I threw my bash functions into a gist. These were only intended for private use so don't expect it to be pretty: https://gist.github.com/FreedomBen/8ea4cd890621521fb9bb2bf36...
After sourcing, you can use the aliases like `adbplaypause` or call the functions directly. I normally use the aliases
How does the app handle the integration of newer Android file access protocols, like Storage Access Framework (SAF), especially for operations like multi-share or file path copying in Android versions 10 and above?
It doesn't, it opts out of it and tries to gain MANAGE_EXTERNAL_STORAGE permission which enables direct manipulation of files.
(Which I guess is why it's not available on Play Store).
Neat and snappy, but it seems to lack thumbnailing of image/media files. Probably not for me then unfortunately.
Side question: since this is GPL3, how does that work with APK signing? A quick peek at the docs [1] makes it seem like this would be just as much a problem on F-Droid as any other app store.
[1] https://f-droid.org/en/docs/Signing_Process/
what are you even talking about? linked page makes no mention to any gpl3 consideration. and i don't see how distribution peculiarities have anything to do with the license.
are you just attempting a low effort gpl3 FUD or are you honestly confused at something concrete that you failed to describe?
I was honestly asking about the intersection of app store code signing and the anti-tivoization clause in 3.0 (I assumed everyone knew that was the major change or 3.0), but I guess I touched a nerve.
I don't think signing counts as a modification, or there's some aspect of your query I'm not getting.
Either way, the GPL 3 was designed with signing already being a thing, GPG had been out for 5+ years. And if signing broke the GPL, I imagine Stallman would have been raising a huge fit about it for decades.
app store code signing is no different than a mirror having a private ssl keys for the domain you are downloading from
or a closed source including a gpl3 Library in its packaging.
both have nothing with the license and are a common FUD argument by people who do not like the implied freedoms of the gpl when arguing for more permissively comercial licenses, so apologize if i wrongly mistook you for the more probable case.
What conflict do you see there? You can take the code, compile it, and install it; what restriction does the signature impose?
I miss Android <4 when you could write tiny apps that would do things.
Is there anything that prevents you from doing that today? I mean the app in this post still seems to work. Apart from some parts of the system that have been pretty much locked down, I think one reason that apps are much larger today is that our expectations increased dramatically.
My SO rewrote the robotsanywhere app to be compliant with android 5+ and the compliance stuff made it balloon from 250kb to 5mb. I was a bit humiliated.
I find apps in Android are much smaller than iOS apps in terms of download size.
App written c 25kb on API 26 https://github.com/cnlohr/rawdrawandroid
You can still write tiny apps that do things if you ignore Google.
>Supports Android 1.0+
>Currently under 40 KB.
Only 40kb in Java? I am impressed
Java apps can be rather small. I've worked on the Skype J2ME[1] version and this was around 300kB if I recall correctly (including all resources such as translations in various languages and images).
[1] https://www.youtube.com/watch?v=Gvt2MtDU698
Non-bloated and slick, love it.
Only complaint is the format of a date in the README.
>Date : 28-11-2023 dd-mm-yyyy
Please observe RFC 3339.
You mean ISO 8601?
Actually, RFC 3339 specifies that a specific ISO 8601 profile should be used.
I am fairly sure I mean RFC 3339.
There is no need to buy a copy of ISO 8601, particularly as I prefer the more specific date formats defined in RFC 3339.
mind blowing