11–20 of 157 posts
Memory corruption, now on Android! Just gonna leave this here: https://safecpp.org/draft.html#the-call-for-memory-safety P.S. Was discussed on HN recently: https://news.ycombinator.com/item?id=41528124 P.P.S. The author has a great YT channel with awesome embedded systems projects: https://www.youtube.com/playlist?list=PLDRymMFQl3Nktk_pjlUP_...
If works with C why not Rust
Earlier quoted context omitted.
I can tolerate Java and Kotlin, but the tooling is just awful *. I've stopped counting how many times I came back to an Android project after only a few months, only to have Android Studio force me to update Gradle and dependencies and whatnot, and break everything. * Of course one could blame me for not learning the ins and outs of the build system!
Gradle rot really is a pain, at least for Android projects (haven't used it in e.g. serverside stuff). Proguard is fun too, with how it'll carve out or break chunks of functional code if you don't spell out precisely what shouldn't get deleted/obfuscated.
(Then gradually rewrite the core in Zig.)
Memory corruption, now on Android! Just gonna leave this here: https://safecpp.org/draft.html#the-call-for-memory-safety P.S. Was discussed on HN recently: https://news.ycombinator.com/item?id=41528124 P.P.S. The author has a great YT channel with awesome embedded systems projects: https://www.youtube.com/playlist?list=PLDRymMFQl3Nktk_pjlUP_...
If works with C why not Rust
I'd expect Zig to be an easier deal here, with its zero-impedance interface with C.
Now we only need to embed Lua into this to write the high-level logic, and we may have a winner for stuff that does not need a lot of accessibility support. Like, say, games, or media players. Easy to link C libraries that do performance-critical stuff, or writhe your own C code. (Then gradually rewrite the core in Zig.)
This is pretty great. The biggest reason I hate doing android development is the java (and to a lesser extent, kotlin) "ecosystem" is a pain. Java is a sucky language to write; Kotlin is less bad, but the whole build tooling/package management/IDE mania mess is still a hassle to use. So thanks to the author.
I can tolerate Java and Kotlin, but the tooling is just awful *. I've stopped counting how many times I came back to an Android project after only a few months, only to have Android Studio force me to update Gradle and dependencies and whatnot, and break everything. * Of course one could blame me for not learning the ins and outs of the build system!
Memory corruption, now on Android! Just gonna leave this here: https://safecpp.org/draft.html#the-call-for-memory-safety P.S. Was discussed on HN recently: https://news.ycombinator.com/item?id=41528124 P.P.S. The author has a great YT channel with awesome embedded systems projects: https://www.youtube.com/playlist?list=PLDRymMFQl3Nktk_pjlUP_...
Check out this blog on zig memory safety: https://www.scattered-thoughts.net/writing/how-safe-is-zig/
(Not my blog, just a blog I found that discusses zig)
Zig is not at 1.0 yet so its a bit behind rust from what iv seen online. One I manage to get C under my belt and get good at writing los level stuff in that language, I might attempt to learn rust or zig.
Memory corruption, now on Android! Just gonna leave this here: https://safecpp.org/draft.html#the-call-for-memory-safety P.S. Was discussed on HN recently: https://news.ycombinator.com/item?id=41528124 P.P.S. The author has a great YT channel with awesome embedded systems projects: https://www.youtube.com/playlist?list=PLDRymMFQl3Nktk_pjlUP_...
Zig also much better at memory as far as I can tell. Only reason I found out about it was some random twitch clip I can't remember, but parts of zig seem to be more readable and easier to learn than rust. Granted I will not stop loving the C language even as someone who has only begun to learn C programming but I do recognise the need for secure software. Check out this blog on zig memory safety: https://www.scattere…
Earlier quoted context omitted.
If works with C why not Rust
Interfacing with C from Rust is harder, and Rust has fewer cross-compile targets. I'd expect Zig to be an easier deal here, with its zero-impedance interface with C.
C++ Rust is much more annoying.
This is pretty great. The biggest reason I hate doing android development is the java (and to a lesser extent, kotlin) "ecosystem" is a pain. Java is a sucky language to write; Kotlin is less bad, but the whole build tooling/package management/IDE mania mess is still a hassle to use. So thanks to the author.
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
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.