Brainstorming Version 3.0

[xperia64]

With ROM Patcher at least, about 9% of current installs are on Gingerbread or less, which translates to around 900 users.

[littleguy]

Thanks xperia64, that's good to know.

MinSDK is now officially 7 (FROYO) and the appcompat libraries have been pushed to master.

Note to devs:  You will need to import some things into your Eclipse workspace.  Please do step 3 in the new Readme file in the root of the repository (copied here):

3. Import the Eclipse project and dependencies
    Open Eclipse
    Select File → Import → Android → Existing Android Code Into Workspace, and press Next
    Browse to root of cloned repository, and press OK
    Select all projects, and press Finish

[littleguy]

With ROM Patcher at least, about 9% of current installs are on Gingerbread or less, which translates to around 900 users.

That is consistent with the overall stats as well:
https://developer.android.com/about/dashboards/index.html

The FROYO user base is pretty miniscule at this point but GB is staying strong.

[BonzaiThePenguin]

I wonder how many people with FROYO (API 7) will use Version 3?  Would be nice to eliminate the IS_GINGERBREAD (API 9) checks from the code.

It would be really nice to be able to bump to HONEYCOMB_MR2 (API 12), as that would cut way down on the API-specific branch points.  But I'm guessing there are still a sizeable number of GB users out there.

API 7 is Eclair, and incidentally so was API 5. It's just 2.1 Eclair instead of 2.0 Eclair.

I have plans for clearing up a lot of the API checks without having to drop support for anything. A lot of the checks seem to involve full screen mode and the action bar. The action bars can be replaced with the version from the support library, and there's no technical reason we can't use our own fake full-screen mode when immersive mode isn't available. All they do is detect edge swipes and show the status bar, so we can do the same thing.

At some point I also want to replace the (kinda) annoying behavior where the action bar is toggled by overriding the back button, by replacing it with the drawers that slide out from the left. So in immersive mode (whether native or fake) you swipe from the top to show the status bar, swipe from the right (or bottom, depending on the orientation) to show the home/back/task buttons, or swipe from the left for the drawer. And then the back button would actually be a back button.

[BonzaiThePenguin]

Can we do this for the launch screen?


Old version, for comparison:


It will take a bit more effort than just moving the position of the text field, since that section is also used as an error log when loading the assets, but I could come up with something nice for that.

[littleguy]

I have plans for clearing up a lot of the API checks without having to drop support for anything. A lot of the checks seem to involve full screen mode and the action bar. The action bars can be replaced with the version from the support library, and there's no technical reason we can't use our own fake full-screen mode when immersive mode isn't available. All they do is detect edge swipes and show the status bar, so we can do the same thing.

Yeah it would be nice to eliminate as many API checks as possible.  Does "fake" immersive mode require additional libraries?  I remember looking into that a long time ago and simply couldn't find a way to eliminate the navigation bar at the bottom using vanilla API calls.  It would be a nice-to-have if it's not a lot of work.

At some point I also want to replace the (kinda) annoying behavior where the action bar is toggled by overriding the back button, by replacing it with the drawers that slide out from the left. So in immersive mode (whether native or fake) you swipe from the top to show the status bar, swipe from the right (or bottom, depending on the orientation) to show the home/back/task buttons, or swipe from the left for the drawer. And then the back button would actually be a back button.

As long as the GameActivity is still fully usable without a touchscreen (i.e. with only a gamepad) that would be great.  Many moons ago when we implemented the action bar for that activity, the back-button-toggles-action-bar behavior was the norm IIRC.

Regarding the launch screen, the artwork in both cases was determined by a competition by users on the forum.  The Mario-esque one was for the original 1.x/2.x version.  The simple one was made for the OUYA release (and in fact is substituted if you are running in "big-screen" mode (global settings).  So I would rather defer to Paul since he organized the competitions.

[BonzaiThePenguin]

The old logo wouldn't have to be removed anyway, it looks quite nice in the About dialog:

[BonzaiThePenguin]

As long as the GameActivity is still fully usable without a touchscreen (i.e. with only a gamepad) that would be great.

Curious, how does it work right now? Are gamepads expected to have one of their buttons mapped to the Android menu button?

[littleguy]

Curious, how does it work right now? Are gamepads expected to have one of their buttons mapped to the Android menu button?

Yeah, they have to map it in the Controller profile editor screen.  Some of the built-in profiles (e.g. OUYA) map this by default.  It's not ideal, but then again I can't think of a better way...

[littleguy]

And the mario-esque background is ideal for the touchscreen profile editor, since the faint grid makes it clear what the differences are between display zoomed, centered, stretched, cropped.

[BonzaiThePenguin]

Ah yes, I forgot it was used there. I figured it was there to show you where the gameplay will be, so you can place the controls elsewhere.

[littleguy]

Yes that's the primary purpose.  The grid was pure serendipity that I came to appreciate after the prototype was already built.

[BonzaiThePenguin]

The ActionBar is completely gone in New-Gallery-UI now, but it looks like I won't be able to do anything about the mess that is fullscreen mode. I had no clue Android lacked the option to hide the system bar until KitKat! All of those version-specific flags and settings will have to stay. 

[xperia64]

I made a new branch that makes sure the xperia-touchpad lib only builds on armv7, and it contains some setup for a dynamic cheat interface (@littleguy I think I'm getting better at this committing thing, but I'll let you be the judge).

[xperia64]

I implemented the cheat dynamic backend as best I could. See the latest commit of my new branch. I used two separate int arrays instead of 1 2D int array. I added a single cheat and I dynamically toggled that cheat, and both worked. Yet another thing that needs a GUI I guess

I've also found that we should be more strict with mandating unique names for cheat codes because the CheatEnabled command takes a cheat name as an argument.

Here is an APK intended for use with Super Mario 64. Open the menu and tap add cheat, and it will apply the cheat I hardcoded. Tap toggle cheat to toggle the added cheat: https://db.tt/zBoGVaa1