[HN Gopher] Rawdrawandroid - Build Android apps without any Java...
___________________________________________________________________
Rawdrawandroid - Build Android apps without any Java, in C and Make
Author : doodlesdev
Score : 343 points
Date : 2024-09-22 13:43 UTC (1 days 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.
| modeless wrote:
| I shipped a PWA in the Play Store. Guess what? It still
| got delisted because I didn't update to the latest API
| level or whatever.
|
| Unfortunately you can't just ship a PWA with no wrapper.
| You have to build a special wrapper app that hosts the
| PWA and you have to use Android Studio and Gradle and all
| that crap.
|
| Updating the wrapper is surely still easier than a whole
| app, but it's nontrivial and it's frustrating to still
| have to deal with the platform BS for a pure web app that
| uses no platform APIs at all. More work than I wanted to
| deal with for a hobby project, anyway.
| afavour wrote:
| > Unfortunately you can't just ship a PWA with no
| wrapper.
|
| You can... but it won't be in the Play Store.
| Disqualifying for many, but not all.
| ktosobcy wrote:
| I use most of the things as pages (miniflux, bluesky) and
| feel no need to install apps for them....
| 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.
| drzaiusx11 wrote:
| Jetbrains makes great stuff, I only wish their remote
| development story was better. You basically have to run a
| full headless instance on the remote and since it's all
| java it requires way more ram resources than it should.
| sprinkly-dust wrote:
| Isn't flutter (especially including the flutter rust
| bridge), achieving that? You do need Android Studio and
| XCode installed on your machine but you don't have to
| interact with them directly.
| candiddevmike wrote:
| As someone interested in flutter, when do you have to use
| XCode and Android Studio?
| cageface wrote:
| The only times I've had to use Xcode for my flutter app
| is configuring some things related to signing and
| distribution. There hasn't been anything that required
| Android Studio except for setting up emulators.
| dsvf wrote:
| I develop an app with flutter on Mac OS. I open xcode
| when creating a new project to setup signing. I never
| installed Android studio since I use an Android device
| for testing and just use the command line tools and SDK
| (setting this up without android studio was a bit of pain
| and probably not worth it but still it proves that it's
| possible).
|
| All development work takes place in VS code, including
| the incredibly incredibly convenient and performant hot
| code reload, as well as the final step of "flutter build
| ios"/"flutter build aab"
|
| It is an experience with very few pain points* and I find
| it to be very enjoyable.
|
| *except for the random Cocoa Pods error every few months
| which can be solved by random helpless googling and then
| deleting the podfile.lock
| anta40 wrote:
| Try give a look at kraken:
| https://github.com/sal0max/kraken
|
| It's a native Android app (Kotlin) which isn't developed
| using Android Studio. Gradle only.
| GreenWatermelon wrote:
| Give ReactNative + Expo a try
| 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.
| kristianp wrote:
| I don't remember the details, but I was struck by the huge
| size of Gradle. Isn't it just a build tool? Why does it
| need so many updates?
| ashishb wrote:
| > 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.
|
| This used to be 5-6 years back. These days it is very stable.
| AshamedCaptain wrote:
| No, it's not. This year I still had to upgrade all my
| projects (I do this yearly) and they still broke in a
| myriad of different ways. Most of them fortunately and
| perhaps ironically the solution was one Google search away.
|
| I actually _like_ Java, so it's not that I hate Android,
| but frankly, I have no idea what it is even doing
| downloading and generating gigabytes of crap with
| inscrutable huge log files. Most of my applications'
| Java/GUI parts are no more complex than a hello world --
| many times I find it easier to just rewrite them from
| scratch than even try "upgrading" them using Android
| Studio.
|
| The Android tooling is basically a textbook definition of
| oversized enterprisey software. I really wish there was
| just a frigging (resource) compiler, linker and maybe
| packer that I could invoke from the command line in simple
| steps.
| metadat wrote:
| This is why folks should stick with Maven and live a happy,
| generally drama-free life.
|
| As a Gradle veteran, I've written in detail about this
| previously:
|
| https://news.ycombinator.com/item?id=38875936
|
| TL;DR: Gradle is too powerful (which is fun and seems
| valuable at first!) with too many footguns. Combine this with
| the mandatory update migrations and you're literally signing
| up for future pain compared to using a lower change-rate
| build tool like Maven. Do you really need to run arbitrary
| commands to build your app? If so, take a deep gaze in the
| mirror and reflect on what you're doing with your life.
| kaba0 wrote:
| With all due respect, that's a blatant misunderstanding of
| gradle (though gradle's documentation not being clear
| enough, giving to the spread of this misunderstanding is a
| fair criticism).
|
| Gradle is not too powerful, it builds a build graph based
| on the .gradle file, and the building itself happens
| imperatively -- but the actual execution is static, based
| on that fixed build graph. This configuration is cached and
| subsequent executions will all refer to this static graph
| to know what requires rebuilding.
|
| This is the minimum required complexity/generality for a
| build system that is not "hardcoded" for a given task (e.g.
| to a degree maven, but cargo, go's build tool etc all can
| only compile their respective languages on their own.
| "Plugins" can let them do more, but at that point plugins
| have to re-develop all the functionality of a build system
| - caching and parallelization), and as I mentioned there
| really are only a handful of tools capable of that.
|
| As for valid criticisms of gradle - it's API historically
| experiencing constant breakages, used to be dependent on
| JDK version (and lagged behind for a long time due to
| Groovy), which is more or less fixed now with toolchains,
| and the model not being clear enough for people not wanting
| to dive deep. E.g. I can count on a single hand how many
| people knows that doFirst/doLast _should_ be used for the
| actual task itself, anything else will happen at the config
| build time which is _not_ what you want.
| drzaiusx11 wrote:
| Saying Gradle is the minimum possible for a build tool
| because it generates a dependency graph is a bit of a
| stretch. Gradle is essentially a custom groovy/kotlin
| build script dsl in addition to a dependency manager. I
| just want the latter; leave the former to existing tools.
| Maven and plug-ins can do the same without learning a new
| (and brittle) dsl. Worst case in maven you have to write
| your own plugin, but then you just use their documented
| plug-in API (import org.apache.maven.plugin) like any
| other JVM project.
| pjmlp wrote:
| Gradle was created by folks that didn't learn the Ant
| lesson, and only matters thanks to Android.
|
| Had it not been for Android replacing Ant with Gradle, and
| most folks wouldn't even remember Gradle.
| anta40 wrote:
| As an Android dev who use Android Studio for daily work, I
| confirm updating Gradle _may_ break your projects, well
| depends on the libraries you used.
|
| In other cases, updating Gradle won't give any problem. You
| can build the APK fine. Debugging the build system is
| annoying :D
| ktosobcy wrote:
| Eh... "all hail Gradle" :/
|
| Each time I have to touch it, it results in problems... Oh,
| you updated JDK? Gradle won't work. There is new Gradle?
| Tough luck it will break your build..
|
| And with Maven it can update and the build keeps working just
| fine.
|
| To that end I mostly ignore prompt "update gradle!" in
| Android Studio to avoid any issues...
| kaba0 wrote:
| Maven (and pretty much every other build tool with the
| exception of bazel) is not capable enough for such a
| complex build as is required for android, though. E.g.
| maven can often "lose" that something requires a rebuild,
| and only clean build will produce the correct artifacts.
| Gradle can always keeps track of tasks correctly.
| ktosobcy wrote:
| Maven (and pretty much every other build tool with the
| exception of bazel) is not capable enough for such a
| complex build as is required for android, though.
|
| Maven is virtually infinite extensibility via plugins.
| The difference is that gradle is easier to "hack" and put
| the build logic in your configuration...
|
| > E.g. maven can often "lose" that something requires a
| rebuild, and only clean build will produce the correct
| artifacts.
|
| This is not build shortcoming but rather detection what
| requires rebuild and what not but in the worst case
| scenario it rebuilds everything...
|
| > Gradle can always keeps track of tasks correctly.
|
| LOL, from my experience that is not true.
|
| Also, if you have multiple projects using different
| gradle version this results in multiple daemons running
| in the background. Besides gradle builds as as slow as
| maven...
| kaba0 wrote:
| > Maven is virtually infinite extensibility via plugins
|
| Losing the only task of a build tool, caching and
| parallelization.
|
| No, the problem is that maven _doesn't_ rebuild
| everything. It is actually quite common in code bases
| that I had to run clean build instead of build to
| actually recompile everything that changed. I guess maven
| just doesn't have an accurate build graph?
|
| > LOL, from my experience that is not true
|
| In what way is it not true?
|
| Also, gradle is demonstrably faster, especially on
| projects that can be parallelized. Obviously a hello
| world will be dominated by javac and build tool startup
| speed so it's not relevant.
|
| And multiple daemons -- you can disable them, and they
| will go away if unused.
| ktosobcy wrote:
| > Losing the only task of a build tool, caching and
| parallelization.
|
| You are aware that Maven does offer paralle build, right?
|
| > I guess maven just doesn't have an accurate build
| graph?
|
| You guess wrong? then
|
| >> LOL, from my experience that is not true
|
| > In what way is it not true?
|
| Consistency of gradle build. You yourself stated just a
| paragraph above that sometimes you have to run "clean" xD
|
| > Also, gradle is demonstrably faster, especially on
| projects that can be parallelized. Obviously a hello
| world will be dominated by javac and build tool startup
| speed so it's not relevant.
|
| Again, learn the tool. Maven does offer parallel builds
| and is comparably fast...
|
| > And multiple daemons -- you can disable them, and they
| will go away if unused.
|
| "but you are turning off the only feature of a build!!!"
|
| Also - I had a setup open with gradle/kotlin-
| multiplatform project (shell with "gradlew" and Android
| Studio) and magically it fails to build with "Unresolved
| reference: kotlinx" even though I haven't done anything
| to the project and no ammount of running "gradlew clean"
| solves it... what a lovely tool....
| kaba0 wrote:
| > Consistency of gradle build. You yourself stated just a
| paragraph above that sometimes you have to run "clean" xD
|
| That was in reference to maven..
|
| Also, feel free to show me any benchmark showing maven
| being as fast as gradle. https://gradle.org/gradle-vs-
| maven-performance/
| ktosobcy wrote:
| > Also, feel free to show me any benchmark showing maven
| being as fast as gradle. https://gradle.org/gradle-vs-
| maven-performance/
|
| I tried and * commons took more than 2,5 minutes to build
| (they show 70s?) * tried their tests (medium project,
| https://github.com/gradle/performance-
| comparisons/tree/maste...) and maven compiled it in 4s
| and usual "clean install" took 14s but they don't enable
| paralel test run); then I tried running "gradle build"
| and... got an error:
|
| ``` FAILURE: Build failed with an exception.
|
| * Where: Build file '/Users/wojtek/dev/tmps/performance-
| comparisons/single-medium-project/build.gradle' line: 16
|
| * What went wrong: A problem occurred evaluating root
| project 'single-medium-project'. > Could not find method
| compile() for arguments [commons-lang:commons-lang:2.5]
| on object of type org.gradle.api.internal.artifacts.dsl.d
| ependencies.DefaultDependencyHandler. ```
|
| It's so nice that even gradle team themselves can keep up
| with their crap xD but of course it's probably due to
| convoluted setup... again - with maven you just clone and
| build and be done with it, with gradle you have to "stand
| on your head" to figure how to make any progress... I
| updated the build.gradle (according to https://docs.gradl
| e.org/current/userguide/declaring_dependen...) and
| `gradle build` finished in 19s...
|
| So your beloved gradle is 25% slower and can't even be
| compatible with itself...
|
| I took a look at "large-multimodule" to have something
| more challenging but: they setup each project
| individually and for some convoluted reason configure
| maven compiler with `<source>1.5</source>` (and JDK21
| complains) and same goes for gradle modules with broken
| `dependencies`. I adjusted it but then it turned out that
| the sources can't even compile (due to wrong arguments in
| tests) ffs...
| pjmlp wrote:
| Android team marketing.
|
| Almost no other build tool has had so many conference
| talks regarding performance issues, and dealing with its
| gotchas as Gradle.
| kaba0 wrote:
| I am primarily a backend developer, so nope. Also, give
| me _any_ build tool that would be similarly capable. I
| only know of Bazel.
| pjmlp wrote:
| Maven is more as capable for anyone that doesn't suffer
| from XML allergy, and doesn't require a background daemon
| to actually make it run at reasonable speed.
| kaba0 wrote:
| Correctness is the number 1 priority, and maven is simply
| not always doing what it should, unless you do a clean
| build.
|
| I am absolutely not bothered by XML and alia (btw, there
| are maven frontends in json/yaml, etc for those who are),
| and throwing out valid criticism over some straw man is
| not really productive.
| 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.
| BrS96bVxXBLzf5B wrote:
| 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 wrote:
| 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.
| ashishb wrote:
| > The biggest reason I hate doing android development is the
| java (and to a lesser extent, kotlin) "ecosystem" is a pain.
|
| Wait till you want to build anything reasonable.
|
| All libraries for Android are in Java and/or Kotlin. If you
| have to write all of them in C then best of luck doing anything
| meaningful.
|
| What kind of libraries? Anything related to SSO. Anything
| related to Material design. Anything related to any ancillary
| services that you want to integrate with e.g. Google services.
| rho4 wrote:
| > Java is a sucky language to write
|
| Please do not troll on HN.
| 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.
| kelnos wrote:
| > _Interfacing with C from Rust is harder_
|
| Sure, harder, but not really all that difficult. Run
| bindgen over the NDK headers and see what happens. Sure,
| for ergonomics you'll want to write safe Rust wrappers.
| After that's done once, it's done.
|
| > _Rust has fewer cross-compile targets._
|
| Not really an issue here. Rust supports all the targets
| Android runs on. Natively, even: $ rustup
| target list | grep android aarch64-linux-android
| arm-linux-androideabi armv7-linux-androideabi
| i686-linux-android thumbv7neon-linux-androideabi
| x86_64-linux-android
| 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/
| kragen wrote:
| thanks for the link to janet! i hadn't heard of it before. a
| lot of lua energy even if it's a lot bigger
| cfiggers wrote:
| Feel free to ask questions in the Janet Zulip (link at the
| bottom of the Janet website's front page) if there's
| anything you need help with!
| chc4 wrote:
| Love2D has Android support. It's surprisingly easy to setup:
| https://github.com/love2d/love-android
| RunSet wrote:
| SDL can be used to provide something similar to what you
| describe.
|
| https://github.com/libsdl-org/SDL/blob/main/docs/README-andr...
| 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.
| shepherdjerred wrote:
| If you're going to nit-pick then at least do us the favor
| of writing something interesting, like a case where Java
| was a surprisingly good choice or some interesting
| libraries.
|
| Yes, of course there are exceptions to every rule. In
| general, as much as I love the language, Java is not
| always going to be the best choice.
| yazzku wrote:
| No, it doesn't.
|
| Java is a piece of crap with JVMs imposing an 8-24 byte
| overhead per object, which destroys caching, memory
| footprint, and any chance of low-level optimization. Not
| only is the overhead bad, it's implementation-dependent,
| i.e. unpredictable. That, along with lacking SIMD,
| imposing stupid decisions like bounds checks on all array
| accesses, making arrays boxed (int[] is not an array of
| ints, sorry), or using exceptions for control flow, which
| is the wrong way to use exceptions, is a just part of the
| big laundry list of why Java is a piece of obsolete crap
| that nobody serious about low-level hardware programming
| uses. Java SE/ME is a fucking joke, as is every book I
| have read about "high performance Java". People who
| promote Java for low-level hardware programming, real-
| time systems, and the like, just have absolutely no
| fucking idea what they're talking about and they get
| their garbage published only because of the low standards
| of publishing nowadays. They do get the "Java Champ"
| badge from Oracle, though. Noobs award other noobs
| badges, as it turns out.
| foobazgt wrote:
| > JVMs imposing an 8-24 byte overhead per object
|
| You want project Valhalla, or more specifically Value
| Objects, which are in preview [0]. If you really want the
| highest performance related to cache accesses, you want
| to arrange things as SoA (struct of arrays) anyway, which
| has approx 0 object overhead and doesn't require Value
| Objects.
|
| > Not only is the overhead bad, it's implementation-
| dependent, i.e. unpredictable.
|
| This is silly. This happens with all other languages, and
| Java will give you better results on average. Use a
| different compiler or runtime for your C code, or run it
| on a different processor architecture, and have fun
| tuning your code.
|
| > That, along with lacking SIMD
|
| The Vector API [1] is available in preview.
|
| > imposing stupid decisions like bounds checks on all
| array accesses
|
| It's widely understood that doing the opposite has been
| perhaps one of the largest mistakes in the history of the
| industry. JITs elide access checks when safe, and it's
| easier for them to do with high performance code that
| doesn't bounce around in memory and thrash cache.
|
| > making arrays boxed (int[] is not an array of ints,
| sorry)
|
| What does this even mean? An int[] is a linear array of
| 32-bit int values in memory.
|
| > or using exceptions for control flow, which is the
| wrong way to use exceptions
|
| Are we now just talking about a small slice of people who
| write bad code?
|
| > is a just part of the big laundry list of why Java is a
| piece of obsolete crap
|
| Ah, ok. Have a fine day.
|
| 0) https://openjdk.org/jeps/401
|
| 1) https://openjdk.org/jeps/460
| John_Cena wrote:
| I feel so out of place when interviewing for
| firmware/embedded roles and the interviewers turn out to
| be java snobs. I honestly still have a hard time
| comprehending the situation; how does it come to this?
| Thanks for your insight
| JoshTriplett wrote:
| Going from Java to C is a good step along the way towards
| supporting any language capable of calling C functions.
| mdhb wrote:
| We have WASM/WASI now which is almost certainly going to
| become the new gold standard of cross language interop.
| jayd16 wrote:
| Quite a few game engines work and don't use Make.
| mdp2021 wrote:
| Game engines that we can readily use to code for Android
| outside the Java and web frameworks? Which ones exactly?
| vertalexgraph wrote:
| Unreal and Unity both target iOS and Android and are not
| "java" or "web frameworks"
| jayd16 wrote:
| At least Unreal, Unity and Godot but most likely more
| target Android and iOS as well.
| kllrnohj wrote:
| C++ or Rust? Or Zig? Or D? Kinda pretty much anything else
| tbh?
| mdp2021 wrote:
| So what you are suggesting seems to be, rewrite
| android_native_app_glue.c in (say) Zig and compile to the
| .so? Good, but it would nice to see a proof of concept.
| Also to see how extensive the work has to be: I am not
| checking all the tree, but android_native_app_glue has
| includes itself: #include
| <android/configuration.h> #include <android/looper.h>
| #include <android/native_activity.h>
| 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.
| yazzku wrote:
| It's not blind rage. I've used them, they're over-
| engineered crap, like most things Java, especially the
| abominations made at Apache land. You can't say Make is
| over-engineered; lacking, maybe, but it does what it's
| meant to do and not much of anything else.
| re-thc wrote:
| > I've used them, they're over-engineered crap
|
| Compared to what? And in what way? And then for you to
| manually recreate it anyway? Like when you need NodeJs,
| typescript, Turborepo, webpack, babel and a whole list of
| tools and then you still need scripts to build and
| deploy?
|
| Yes Maven and Gradle has its problems, but which tool is
| exactly better? They all just have their pros and cons.
| Which tool / framework in Go allows you to update a
| single dependency instead of the 100 that you might need
| and generates OpenAPI docs for you, etc etc?
| zelphirkalt wrote:
| Make can be as low level or high level as one wants. One
| simply runs shell commands with it mostly, except for in-
| built functions and using other shells. This means it all
| depends on the tooling one wants to use for a project. If
| it is a C project then probably some C compiler. If it is
| Python then probably some venv and Python. And so on. So
| it is very flexible. Only doesn't have a great syntax.
| sheeshkebab wrote:
| Honestly the whole java/kotlin tooling is the worst to pick for
| mobile dev, and KEEP it after so many other great languages and
| tools that are out there. I don't why google didn't offer at
| least Go as a native alternative for android dev.
| refulgentis wrote:
| That'd require some form of collaborative behavior across
| internal organizations, and _real_ planning! </s>
| </disgruntled_xoogler>
|
| I wake up every morning and thank God that Flutter exists. I
| can target Android without dealing with building on years and
| years of sloppy work.
|
| Sunk-cost fallacy x politics leads to this never being fixed. I
| don't think Google can fix it, unless hardware fails entirely.
| There's been years-long politics that culminated in the
| hardware org swallowing all the software orgs, and each step
| along the way involved killing off anything different.
| mohn wrote:
| >I don't think Google can fix it
|
| Can they eventually throw away Android and replace it with
| Fuchsia? In the reporting about Fuchsia that I read _ages_
| ago, it sounded like it was intended to be an Android
| replacement but, looking into it again just now, it seems
| more like an embedded OS for other non-smartphone hardware --
| maybe with some (aspirational?) claims of utility on
| smartphones and tablets.
| kmeisthax wrote:
| Fuchsia has components for running APKs (Android Runner)
| and Linux binaries (Starnix), but that probably isn't what
| you meant.
|
| The problem with replacing a UI toolkit - any toolkit - is
| that any change to the toolkit requires modification of
| _all_ software, including third-party software. Typically,
| when an OS wants to provide a new toolkit, they _wrap_ the
| existing toolkit in new code. For example, on macOS, UIKit
| wraps AppKit, and on all Apple platforms SwiftUI is a
| wrapper around AppKit and UIKit (depending on platform). On
| Windows, _every_ UI toolkit ultimately is creating
| "windows" as they are understood by USER[0], which creates
| corresponding objects in CSRSS and/or the NT kernel, which
| can then be used to draw on or attach to a GPU. The lowest
| level UI abstraction either OS provides is the objects
| supported by their oldest toolkit, and the lowest level
| programming language you can write apps in is whatever can
| call it.
|
| Linux is a bit different, because it inherits its windowing
| model from X11. X shipped with no default toolkit and a
| stable window server protocol that apps could program
| against directly, in an era where most GUI OSes[1] didn't
| _have_ 'servers' or 'protocols'. You populated resource
| files and called the relevant function calls to make things
| happen, and those function calls became sacrosanct. Even
| Windows NT couldn't escape this; it still used USER despite
| USER being years older than NT.
|
| The best you can do is shim the library - write something
| _more lower level_ than the old junk and then rewrite the
| old library in terms of the new one. This is what Xwayland
| does to make X apps work on Wayland; and it 's what Apple
| did (mostly) with Carbon to give a transition path to Mac
| OS 8/9 apps on OS X. Google could, say, ship a new Android
| toolkit that doesn't use Java bindings, and then make
| Android's Java toolkit a shim to the new native toolkit.
| However, this _still_ means you have to keep the shim
| around forever, at least unless you want to start having
| flag dates and cut-offs. For context, Apple didn 't kill
| Carbon until macOS 10.15 Catalina, and if they hadn't
| refused to ship Carbon on 64-bit Intel, it probably would
| still be in macOS today.
|
| [0] An interesting consequence of this is that disabling
| "legacy input" in games turns off the ability to move the
| application window since all that code is intimately
| coupled to every app that has to open a top-level (i.e. not
| a widget) window.
|
| [1] At the time that would be XEROX Star, the Lisa, and the
| Macintosh
|
| [2] This is also why Apple will never, _ever_ ship an iPad
| that can run macOS software in any capacity. Even if they
| were forced to allow root access and everything else macOS
| can do. The entire point of the iPad is to force software
| developers to rewrite their apps for touch, and I suspect
| their original intent was for the Macintosh to go away like
| the Apple ][ did.
| refulgentis wrote:
| Correct, tl;dr roadkill. I don't mean to be disrespectful,
| someone anonymous picked a bitter fight about this once.
| But to your point, its clear there was a larger context
| that Fuchsia was born from, and the ambitions and
| commitment to it are greatly different than they were at
| some previous juncture.
| pjmlp wrote:
| Because Go only exists due to a trio that doesn't like C++, has
| fought against Java 20 years ago and lost (Inferno and Limbo),
| and is pretty much the atenthesis of the feature rich
| capabilities of Java, Kotlin and C++, the official Android
| languages.
|
| They hit jackpot with Kubernetes and Docker taking off after
| their pivot to Go.
| kllrnohj wrote:
| Because adding Go as an official language would be a monumental
| amount of work for vanishingly little benefit. Remember Android
| itself is half written in Java, so are you doing JNI calls for
| everything from Go? That's not fast nor "native". Are you
| rewriting the framework in Go? That's a crazy amount of effort.
|
| And all for what? To satisfy a hobby itch that has no practical
| benefit? The problem of app developers is almost never the
| language. Hell, look at how popular web apps are even though
| JavaScript is the worst language in any sort of widespread
| usage. The platform is what gets people excited (or
| frustrated), not a language.
| tapirl wrote:
| Google even didn't consider supporting Go as an official
| flutter language.
| skybrian wrote:
| Looks like you still have to start by installing Android Studio,
| which seems excessive. Is there a way to just download an Android
| SDK?
|
| Looking briefly at the makefile, I think they might have avoided
| Gradle, though it calls other tools written in Java.
|
| I'd love to see a way to build a Flutter app without Gradle.
| MaXtreeM wrote:
| > _curl -k
| "https://dl.google.com/android/repository/commandlinetools-
| li..." -o commandlinetools-linux.zip_
|
| unzip somewhere, set path variable
|
| > _yes | sdkmanager --licenses && sdkmanager "platform-tools"
| && sdkmanager "ndk-bundle" && sdkmanager "build-tools;33.0.0"
| "platforms;android-33"_
| slimsag wrote:
| This is better indeed, but from recollection last time I
| tried this.. I think that still requires a full OpenJDK
| installation and I believe those `sdkmanager` commands
| install multiple GB of tools sadly.
| MaXtreeM wrote:
| Yes to both OpenJDK and large size.
| flohofwoe wrote:
| It's possible to build without gradle by calling the sdk tools
| for bundling and signing directly (for instance from make or
| cmake), but Android Studio is at least useful for debugging the
| resulting apk (AS also works as "standalone debugger" for
| debugging an apk built elsewhere).
| hyperbolablabla wrote:
| Not sure how useful this is but here's a gist that runs through
| the process without needing Android Studio:
| https://gist.github.com/jonnybrooks/13c6cbae832e7d1662e6c143...
| Vt71fcAqt7 wrote:
| >I'd love to see a way to build a Flutter app without Gradle.
|
| You generally don't need to touch gradle at all with flutter.
| Is your issue about having to install gradle onto your machine,
| even if you don't use it directly?
| skybrian wrote:
| Yes, it's mostly hidden, but it runs Gradle behind the scenes
| and that's okay as long as nothing goes wrong.
|
| (I used to work on it, or at least tried to before giving up
| in frustration.)
| Vt71fcAqt7 wrote:
| >I used to work on it, or at least tried to before giving
| up in frustration.
|
| Out of interest, what blockers did you encounter using
| Flutter? For me it was much better than native android in
| terms of development, but it could depend on the usecase.
| zmodem wrote:
| > Is there a way to just download an Android SDK?
|
| Yes, you can just grab the zip files. For example like this:
| https://www.hanshq.net/command-line-android.html#sdk
| kopirgan wrote:
| May be someone with deep pockets like Elon must get Linux to work
| on mobile. I know there's efforts going on but seems slow
| progress. That will break the back of the duopoly and also make
| things like this so much easier.
| MobiusHorizons wrote:
| Getting Linux running is not the problem. All android phones
| have a working Linux kernel, and could probably be made to run
| some kind of Linux based software if you can get through the
| bootloader hurdles. The issues so far with open source phone
| stacks are largely around getting all the hardware talking with
| open source software, battery life, mobile appropriate UIs and
| finding ways to bring the apps people expect on board.
| voidUpdate wrote:
| Already been done https://ubuntu-touch.io/en_GB/ I ran my main
| phone on this for a little while and it was definitely an
| interesting experience
| derjames wrote:
| Maybe PinePhone or Librem5 are a good start.
| codethief wrote:
| (I assume by "Linux" you mean a distribution like
| Arch/Debian/Fedora/Ubuntu/... since, as the sibling says,
| Android also runs Linux.)
|
| > That will break the back of the duopoly and also make things
| like this so much easier.
|
| ...and so much less secure by giving every application access
| to everything in my home dir. No, thank you.
| promiseofbeans wrote:
| Whenever I need to touch XCode or Android Studio, I'm reminded
| how lucky web devs are now that almost everything has converged
| around Vite (death stare at NextJS). Everything Just Works(tm).
| Simple plugin system to integrate anything.
|
| The few times there wasn't a plugin to do what I needed, I've
| managed to roll a custom one pretty easily.
|
| When Vite breaks you're completely screwed though. Find a
| different way to do it or wait until a patch comes out. Vite
| internals are nigh impossible to fix on your own.
| mdhb wrote:
| I sincerely Vite would just align with actual web standards
| rather than throwing in bits and pieces of their own nonsense.
| It's precisely why it tends to break in seemingly unfixable
| ways
| codethief wrote:
| Would you mind elaborating?
| roland_nilsson wrote:
| "I can do anything I want. It's just bits. You don't own me."
| Fair enough! x-D
| tomw1808 wrote:
| "This is computer science. There aren't restrictions." - It's
| literally what many people forget when they let themselves
| constraint by frameworks and claim this and that isn't
| possible. Very refreshing to see how liberating it is if you go
| one level deeper.
| RunSet wrote:
| "We can cause any problem by introducing an extra level of
| indirection." ;)
| donquichotte wrote:
| cnlohr is in his own league, this guy is bordering on genius.
|
| Dissatisfied with the state of the vendor SDK for CH32V003
| microcontrollers (ultra-cheap RISC-V MCUs), he created his own
| [1], which is a pleasure to use. He also has a header-only
| RISC-V emulator that runs Linux (and Doom!) [2], and hacked an
| ESP32 to emit valid LORA frames with clever use of aliasing
| [3].
|
| [1] https://github.com/cnlohr/ch32v003fun
|
| [2] https://github.com/cnlohr/mini-rv32ima
|
| [3] https://www.youtube.com/watch?v=eIdHBDSQHyw
| a-dub wrote:
| to be clear, this is only really useful for applications that
| present their ui through opengl and do not interact with the rest
| of the android system very much.
|
| the ndk is meant for writing little bits of c to speed things up
| in a classic java android application.
|
| this is a pretty cool hack that allows for opengl apps to be
| written in straight c that run full screen and have limited
| access to things like keyboards, adc inputs or usb.
|
| it does not include a reimplementation of the android frameworks
| in c and the ndk provides limited access for ndk code to interact
| with them.
|
| the main use case seems to be supporting a program for live audio
| reactive visuals based on extraction of chroma.
| mavamaarten wrote:
| I read that last bit of your comment before I opened the link,
| and thought to myself, that's something Cnlohr would write.
|
| And it is! Hah.
| spookie wrote:
| To be fair this is the way to not be platform dependent and
| more people should pursue it.
|
| I'm doing a desktop app meant to be as cross compatible as
| possible and the only reasonable way to do it (without sending
| yourself into build config hell) is with opengl.
| marcellus23 wrote:
| How do you make it accessible?
| kllrnohj wrote:
| > this is a pretty cool hack that allows for opengl apps to be
| written in straight c that run full screen and have limited
| access to things like keyboards, adc inputs or usb.
|
| It's not even a hack. Android NDK added that way back in like
| gingerbread, it's just a NativeActivity.
| https://developer.android.com/ndk/samples/sample_na
|
| This is just a small framework on top of that. It's not doing
| anything "new"
| baudaux wrote:
| I remember when I was developping a cross platform C++/OpenGL ES
| engine that worked on Android, iOS, Linux, Web... so satisfying
| justmarc wrote:
| There should be a lot more high quality, super lightweight, non
| bloated apps.
| thih9 wrote:
| Unfortunately it's easier to write a useful app (reliable, bug
| free, with useful features, etc) using more bloated tech. That
| translates to the cost.
|
| In other words: lightweight, useful, cheap - pick two.
| mouse_ wrote:
| This should be integrated into DevkitPro! Would love to see the
| relatively lightweight msys2 environment building APKs. I know
| WSL is better but I'm hesitant to use platforms Microsoft is in
| the process of embracing and extending.
| matsemann wrote:
| Given that it's a thin wrapper around GL and friends, could one
| have an alternate implementation of these calls and do most of
| the dev work natively on the desktop? And not muck around with
| devices or emulators except for some final / edge case testing?
|
| I just remember working with Libgdx back in the days. A game
| framework made for Android. It however was cleverly designed in
| that you could just run it on desktop by changing which
| implementations were used for drawing/sounds/assets. Very nice to
| work with, could just recompile the app in seconds and test, even
| hot swap, compared to the other way of building an apk,
| installing, launching etc which took minutes per iteration.
| pjmlp wrote:
| Present tense, LibGDX is still around, even though it isn't
| Unity or Godot like cool.
|
| https://libgdx.com/
| matsemann wrote:
| Yeah, sorry, the past tense was supposed to be my usage of
| it, which was around 2012-2015. I was quite active,
| maintaining lots of the documentation, writing guides on how
| to do stuff. Specifically how to get it running with
| IntelliJ, as android sdk at the time was eclipse integrated.
|
| Also made a simple project on github to show how to do a
| "loading screen", aka not just freeze while it loads but have
| a progress bar and interactivity. Somehow it still gets
| random stars a decade later.
| fredgrott wrote:
| You know its funny all the Gradle sucks comments here....I use
| Flutter which behind the scenes uses Gradle builds for android
| targets....no Gradle problems whatsoever...maybe operator
| touching and changing Gradle was the feature and the problem??
| peter_retief wrote:
| I was interested but then saw JDK/Gradle. One of the reasons I
| avoid android development.
| pkphilip wrote:
| C is neat but something like python may be simpler to work with
| for most programmers. I wonder if anyone here has experience with
| Kivy and KivyMD libraries for python.
|
| The code is simple and self explanatory.
|
| class RectangleFlatButton(TouchRippleBehavior, Button):
| primary_color = get_color_from_hex("#EB8933")
| def on_touch_down(self, touch): collide_point =
| self.collide_point(touch.x, touch.y) if
| collide_point: touch.grab(self)
| self.ripple_show(touch) return True
| return False def on_touch_up(self, touch):
| if touch.grab_current is self: touch.ungrab(self)
| self.ripple_fade() return True return
| False
|
| class MainApp(App): def build(self): screen =
| Builder.load_string(KV) screen.add_widget( RectangleFlatButton(
| text="Hello, World", pos_hint={"center_x": 0.5, "center_y": 0.5},
| size_hint=(None, None), size=(dp(110), dp(35)),
| ripple_color=(0.8, 0.8, 0.8, 0.5), ) ) return screen
|
| MainApp().run()
| intrepidhero wrote:
| I built a simple kivy app a few years. Working with kivy and
| testing on my (linux) dev machine was great. Even side loading
| to test on my phone using the kivy launcher wasn't too bad. The
| pain point was that building APKs that the play store would
| accept was an ordeal and then when they change requirements you
| have to hope the kivy folks update their build tools in time to
| recompile with a new version of the NDK before google delists
| your app.
___________________________________________________________________
(page generated 2024-09-23 23:01 UTC)