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.
The structure is (using [dirname] notation for directories)
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.