[HN Gopher] Rawdrawandroid - Build Android apps without any Java...
___________________________________________________________________
Rawdrawandroid - Build Android apps without any Java, in C and Make
Author : doodlesdev
Score : 117 points
Date : 2024-09-22 13:43 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| _bin_ wrote:
| 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.
| tredre3 wrote:
| 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!
| 627467 wrote:
| > only to have Android Studio force me to update Gradle and
| dependencies and whatnot, and break everything
|
| This. And people are surprised that many just wrap websites
| as apps on Android.
| gnarbarian wrote:
| If targeting Android people should first consider if their
| app can work as a PWA.
|
| Try and do it. if you run into a deal breaking issue with
| PWA features, then wrap it in a minimalist app shell.
|
| Best case: everything works on Android and iOS and it's
| also a website.
|
| Worst case: you will end up doing some platform specific
| code and dealing with the app stores like you were going to
| do anyway.
|
| Average Case: everything will work on android and some
| things will be broken on iOS.
| freedomben wrote:
| This really is a good way to go. The majority of apps can
| be a PWA just fine as long as you don't have to have an
| app in the Apple app store. If you need push
| notifications of the specific Apple variety or any other
| APIs that Apple doesn't think non-native apps should be
| able to call, then you'll hit some friction as well, but
| for the most part it's a pleasant delivery strategy.
|
| Even now if I need a "native" app I'm looking very
| seriously at React Native first before rolling two
| totally separate apps in different languages.
| jwells89 wrote:
| 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.
| nine_k wrote:
| Gradle is pretty sane, from my backend dev experience. But
| you indeed can get in a situation when dependencies become
| slightly incompatible after an attempt to upgrade, and you
| have to fix your code or juggle version requirements, much
| like with npm or pip.
| candiddevmike wrote:
| Same thing with XCode. I'd love a mobile app development
| pipeline that lets me never use either Android Studio or
| XCode. Let me drive everything with scripts and/or VSCode
| extensions.
| Discordian93 wrote:
| If only Firefox OS had taken off...
| Larrikin wrote:
| XCode is awful but JetBrains makes the best IDEs. There are
| people that dislike all IDEs which I disagree with but
| understand.
|
| VSCode isn't bad but disliking Android Studio just feels
| like you started with it and didn't want to learn a
| different tool.
| kllrnohj wrote:
| Gradle/Studio rot is _so bad_. If you continuously keep up to
| date it 's not so bad, but you're absolutely fucked if you
| want to open a project from a year ago.
|
| Unfortunately this doesn't actually protect you from that
| since you still have to deal with that for both the actual
| "make an APK" step as well as the Java bindings for critical
| features.
| Lerc wrote:
| 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.
| smarx007 wrote:
| 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_...
| asveikau wrote:
| Any effort to make android more accessible to a C ABI with a
| simple toolchain can probably also serve as an FFI to other
| languages.
| fbn79 wrote:
| If works with C why not Rust
| nine_k wrote:
| 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.
| Yoric wrote:
| In my experience, C <-> Rust works quite well, except when
| the C API relies too much on macros.
|
| C++ <-> Rust is much more annoying.
| tonetegeatinst wrote:
| 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.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.
| smarx007 wrote:
| Yes, I think Zig is the most suitable language (of Zig, Rust,
| Go, ...) to replace C in various (systems-related) contexts
| including embedded/RTOS.
| rkagerer wrote:
| _Rawdraw operates on everything from an ESP8266, to RaspberryPi,
| Windows Linux and now, even Android. Write code once, use it
| everywhere._
|
| That "everything" contains a pretty big gap.
| nine_k wrote:
| 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.)
| nine_k wrote:
| ...I of course would rather embed Janet [1], but I realize what
| is going to have an easier time gaining popularity %) Also, Lua
| has Love [2] which could be immediately usable, among other
| things.
|
| [1]: https://janet-lang.org/
|
| [2]: https://www.love2d.org/
| chc4 wrote:
| Love2D has Android support. It's surprisingly easy to setup:
| https://github.com/love2d/love-android
| 38 wrote:
| Make? Jesus Christ people are still using that? It's like people
| don't realize that other languages have been created in the last
| 20 years
| mdp2021 wrote:
| So which other actual alternative should we use for Android
| development besides Java and webapps.
| 38 wrote:
| I am not a fan of Java, but going from Java to C is not an
| improvement.
| shepherdjerred wrote:
| It depends purely on what you're making.
|
| It would be silly to write low-level software in Java, or
| high-level software (with exceptions for software which
| would require a low-level language) in C.
| wiseowise wrote:
| > It would be silly to write low-level software in Java
|
| Depends on what kind of low-level stuff.
| JoshTriplett wrote:
| Going from Java to C is a good step along the way towards
| supporting any language capable of calling C functions.
| jayd16 wrote:
| Quite a few game engines work and don't use Make.
| kllrnohj wrote:
| C++ or Rust? Or Zig? Or D? Kinda pretty much anything else
| tbh?
| yazzku wrote:
| Obviously the complete and utter crap that gradle/maven are is
| much better, right?
| wiseowise wrote:
| Yes. Definitely. Ignore your blind rage of Gradle/Maven for a
| second and realize that they're literally next iterations of
| Make.
___________________________________________________________________
(page generated 2024-09-22 23:00 UTC)