4 ms·

I disagree on the part about manifests. Having a manifest file containing device compatibility and permission information that can be read without executing you

I disagree on the part about manifests. Having a manifest file containing device compatibility and permission information that can be read without executing your app is critical for e.g. app stores.

stu2010 6y ago
The manifest file could be generated at build time. I believe it's more developer-friendly in the long run to be able to do configuration from in-band in the same language / environment the application is running in vs out-of-band config. Spring config has become a good bit more manageable now that it's in doable Java (or Kotlin) rather than only XML. Both in-band and out of band could be offered, it wouldn't have to be a hard cutover anyway.
saurik 6y ago
And particularly the complaint from the thread that focuses on "program name, orientation handling, icon, permissions"... these are all things that are always done as part of separate languages if not separate files (whether it be .rc files on Windows or Info.plist files and plist entitlements on iOS/macOS).
- quelsolaar 6y ago
  In win32 you can set icon, application name and pretty much everything programmatically.
  - flohofwoe 6y ago
    The actual icon pixel data must exist as a resource though and not as (for instance) a C array of RGBA values (which sort of makes sense because Explorer must also be able to access the icon). I guess that's also the reason why those things are in manifest files on Android (and I think iOS too): they must be accessible from the outside without running the program. I 100% agree that Android is by far the worst platform to develop for though, at least when it comes to native code.
quelsolaar 6y ago
Why is there an assumption that I'm going to distribute my program using an app store? Why is there a assumption that all app stores want the same information in the same format? Submission should be a completely separate process from software development.
- flohofwoe 6y ago
  FWIW pretty much all platforms have switched to manifest files now, even Windows (they're just not mandatory). For Android I simply create a dummy manifest file during the build process, along with the whole APK packaging and code-signing with a debug certificate. This might help if you want to try ditching Gradle, it's essentially the "missing link" to put the whole build process into cmake (or similar C/C++ build tools): https://github.com/floooh/fips/blob/master/tools/android-create-apk.py https://github.com/floooh/fips/blob/master/tools/android-cre...
- lern_too_spel 6y ago
  It's really to tell the OS's package manager at install time what the entry points are and what device capabilities are required. The fact that app stores can also parse that information out is a convenient side benefit.

I disagree on the part about manifests. Having a manifest file containing device compatibility and permission information that can be read without executing your app is critical for e.g. app stores.

stu2010 6y ago

The manifest file could be generated at build time. I believe it's more developer-friendly in the long run to be able to do configuration from in-band in the same language / environment the application is running in vs out-of-band config. Spring config has become a good bit more manageable now that it's in doable Java (or Kotlin) rather than only XML. Both in-band and out of band could be offered, it wouldn't have to be a hard cutover anyway.

saurik 6y ago

And particularly the complaint from the thread that focuses on "program name, orientation handling, icon, permissions"... these are all things that are always done as part of separate languages if not separate files (whether it be .rc files on Windows or Info.plist files and plist entitlements on iOS/macOS).

quelsolaar 6y ago
In win32 you can set icon, application name and pretty much everything programmatically.
- flohofwoe 6y ago
  The actual icon pixel data must exist as a resource though and not as (for instance) a C array of RGBA values (which sort of makes sense because Explorer must also be able to access the icon). I guess that's also the reason why those things are in manifest files on Android (and I think iOS too): they must be accessible from the outside without running the program. I 100% agree that Android is by far the worst platform to develop for though, at least when it comes to native code.

quelsolaar 6y ago

Why is there an assumption that I'm going to distribute my program using an app store? Why is there a assumption that all app stores want the same information in the same format? Submission should be a completely separate process from software development.

flohofwoe 6y ago
FWIW pretty much all platforms have switched to manifest files now, even Windows (they're just not mandatory). For Android I simply create a dummy manifest file during the build process, along with the whole APK packaging and code-signing with a debug certificate. This might help if you want to try ditching Gradle, it's essentially the "missing link" to put the whole build process into cmake (or similar C/C++ build tools): https://github.com/floooh/fips/blob/master/tools/android-create-apk.py https://github.com/floooh/fips/blob/master/tools/android-cre...
lern_too_spel 6y ago
It's really to tell the OS's package manager at install time what the entry points are and what device capabilities are required. The fact that app stores can also parse that information out is a convenient side benefit.