5 ms·

Looking at the Flappy Bird post earlier I noted the structure of the repo to be simultaneously elegantly structured and yet still more complex than I would pref

by Lerc 2y ago

Looking at the Flappy Bird post earlier I noted the structure of the repo to be simultaneously elegantly structured and yet still more complex than I would prefer. The structure is (using [dirname] notation for directories) [Repo Root] ...git and github files, READMEs... [Flappy Bird] ... project files, keystore, build.bat ... [App] [build] ... I'm ok with tools making a mess here as long as outputs is tidy ... [outputs/apk] ..the actual .apk [src] [main] this seems a little off, main contains libs and resources Android_Manifest.xml Yep ok, I'll rant about that later, that's its own thing [assets] all good [res] Wait what? that's like a synonym for assets, (but for a different layer) [libs] Hang on, these are .so files. built libs should be in the build dir [jni] This looks like what src or src/main should have had inside it So ignoring the outer layer for the README etc. which isn't needed for an Android app, Just encapsulation for presentation. Arguably the same applies for the next layer too. I feel like the contents of App could be placed in here at no loss. I'd Shuffle it around to make [Flappy Bird] contain [main] and [build]. move [libs] to [build/libs] rename [jni] to [src]. If you had an architecture like that then the one-true-build-system should be a command line tool that you can point at [main] and it does what [Flappy bird]/build.bat does only with auto detection of the installed tools, optional config file overrides, optional commandline overrides. AndroidManifest is another issue entirely I'd like something that invisibly converted something sane to XML and I'd never see it again, but I'll grin and bear it. A decent validator and maybe I'd like a standalone AndroidManifest editor that knew what everything did and could provide appropriate boilerplate. After typing this up (mostly as organizing my thoughts), I actually think you could have a relatively painless way to make Android Apps.

BrS96bVxXBLzf5B 2y ago
The `src` folder is structured that way because the Android NDK demands it. They're not just chosen by convention, but because the build tool searches for those files and subdirectories.
- Lerc 2y ago
  Yeah, that feeds back to the tooling issues that the post I was replying to was talking about. Ideally tools should support, not dictate. For instance, if you were building a simple source only app with no assets, a good tool should be able to be pointed at, say, a main.c file in the directory and be able to use the contents of the directory containing main.c for other required files and work with no special extra configuration. Supporting a structure to keep things clean is great, Imposing one(whether you use the features it offers or not) is poor. I might take a look at the NDK and see if it can be circumvented.

by Lerc 2y ago

BrS96bVxXBLzf5B 2y ago

The `src` folder is structured that way because the Android NDK demands it. They're not just chosen by convention, but because the build tool searches for those files and subdirectories.

Lerc 2y ago
Yeah, that feeds back to the tooling issues that the post I was replying to was talking about. Ideally tools should support, not dictate. For instance, if you were building a simple source only app with no assets, a good tool should be able to be pointed at, say, a main.c file in the directory and be able to use the contents of the directory containing main.c for other required files and work with no special extra configuration. Supporting a structure to keep things clean is great, Imposing one(whether you use the features it offers or not) is poor. I might take a look at the NDK and see if it can be circumvented.