DanAlbert
commented
2 months ago There's precedent for this as well: https://github.com/android/platform-samples. This repo is the native analog of that one, so if that structure makes sense for them, it does for us too.
I expect the original motivation for keeping these all separate was so that they could be easily copied and used as the starting point for a real game. The problem with that none of these samples are actually a good starting point, and that's largely because they're trying to remain small enough to be educationally useful, which means the boiler plate necessary to make these production quality apps is absent. That boiler plate can't be factored away in a useful (or maintainable) way largely because the various samples can't share code with each other without resorting to hacks that make them harmful gradle and cmake examples.
This became really clear when I was migrating all the samples from
ALooper_pollAlltoALooper_pollOnce. A lot of the samples are more or less identical with a few small differences, but because they all have to repeat the same infrastructural bits, the interesting part of the demo is not clear. Beyond that, there's a lot wrong with many of them, and fixing every sample individually is extremely time consuming.Instead, we should merge these all into a single Studio project, with each sample app being its own gradle module. That way we can factor out the common stuff and keep each sample smaller and focused on what its actually trying to show. It will also be very beneficial that the code in the samples will actually be safe to copy and paste, because that's likely very common.