We still haven't got to a conclusion about how the APIs must look like. See the previous discussion at #9508.

/cc @crawshaw

@jhsx if you'd like to propose an API for this (or use this issue to discuss it), please go ahead.

You will have to work out what should be called on both Android and iOS. Android at least has more than one notion of fullscreen, so bool may not be enough.

It may also be worth considering an options struct, and deciding whether or not that should be passed as a method to the App object. That is:

type AppOptions struct {
    HideTitleBar bool // set to true is traditional android fullscreen
    Fullscreen bool // android immersive mode, implies HideTitleBar?
}

and then:

type App interface {
    ...
    SetOptions(o Options)
}

This could also hold EGL options, if we can find any suitable portable subset of those (I suspect we cannot).

I prefer the android style of setting window flags, and to have different methods for window and egl management.

In some cases you may want to change just one or more things related to the window and not touch the others.

We can add many flags and process them according to the operation system.

And sorry my english is not very good.

package app

const (
    FULLSCREEN windowFlag = 1 << iota
    HIDE_NAVIGATION
    HIDE_TITLEBAR
    IMMERSIVE_MODE
    IMMERSIVE_STICKY_MODE

    // OR JUST
    FULLSCREEN windowFlag = 1 << iota
    IMMERSIVE_MODE
    IMMERSIVE_STICKY_MODE
)

type windowFlag int

type App interface {
    //...
    SetWindowFlags(flags, changingFlags windowFlag)
}

// app code

func main() {

    app.Main(func(app app.App) {
        // SET FLAG
        app.SetWindowFlags(
            app.FULLSCREEN|app.IMMERSIVE_MODE,
            app.FULLSCREEN|app.IMMERSIVE_MODE,
        )

        // REMOVE FLAG
        app.SetWindowFlags(0, app.FULLSCREEN|app.IMMERSIVE_MODE)
    })

}

The mobile repo should avoid containing non cross-platform APIs as much as possible since the mobile packages gives a promise of API parity on multiple platforms. There must be a good middle ground that needs to be investigated that support both platforms for the most common use cases. We can tolerate platform-specific flags only for edge high-priority cases.

I think that SetFullscreen method would be simple and easy for users, problem is on Android, should it hide the navigation (maybe enter in IMMERSIVE STICKY MODE) ?
For games, i think yes, i don't know about the other use cases.

I don't think we are at a stage to think about the UI libraries and are still targeting native developers. Any user who has a fully featured UI library can override this behavior by providing a call from their library. Immersive sticky mode seems to be what's expected in games.

FWIW, I don't know @crawshaw's long term goals for the UI libraries. I think it is his call to determine what is good enough for now and how it can be extended.

Ok.

Sure, as @crawshaw said for propose an api, i am proposing.
BTW, thanks you all for bring Go for android can't wait for start use.

@rakyll When it comes to future UI part of mobile package I hope the following is not true or set in stone yet. ios and android are so wildly different in api and philosophy. If android has an api that ios doesn't it should still be exposed, uniquely, and vice versa. If using common api approach, the code could be a huge mess with branching logic for platform and then subranching for diff platform versions with all the quirks in between.

Imagine writing v4-support-libraries but now times 2 or 3 for ios/android/windows with common api calls. Looking at googles own supportlibraries code is like trying to count threads in a yarn ball as it is.

The mobile repo should avoid containing non cross-platform APIs as much as possible since the mobile packages gives a promise of API parity on multiple platforms

Sorry this issue has stalled. Native apps need a way to set fullscreen mode for games.