The lifecycle model is complicated, but I'm not convinced it's too complicated. Apps have a lot of fundamental states. My old model hid a lot of stages that a typical game-like app doesn't need, but it's not clear that was the right approach. My thinking on this is that simpler app models belong at a higher level. For example if exp/sprite got a 2D game engine (even as an optional extra package), it could end up managing lifecycle for a user and presenting a much higher-level interface. Similarly an all-Go UI could provide an optional management system that took care of the primary event loop for some common class of apps.

As to the notion that it's of Go invention, that's true, but I given the general confusion I've seen over the Android/iOS models I don't expect users to come in with a good understanding of any of those systems.

I'm not sure what "pushed to the user" means. Could you elaborate?

I'd have to agree here. I mean, after some browsing through the code it becomes a bit clearer what it does and how it works, however, it still looks a bit complicated to comprehend.

What was the reason to have stages and have positive and negative passes through them? Why wasn't the Android model of having two callbacks per stage (e.g. onResume, onPause; btw, documentation references onFreeze where it should be onPause) used? Those could have been implemented as Events as well, if callbacks were not desired (e.g. lifecycle.ResumeEvent and lifecycle.PauseEvent respectively).

From the documentation, it does not become apparent also that all the events occur on the OpenGL thread. My initial assumption was that only events in the paint package would occur on the GL thread but a look at the source code (and example) showed me differently.

Additionally, it seems that the pump method in app can grow indefinitely https://github.com/golang/mobile/blob/master/app/app.go#L150 leading to new allocations. Since events are passed as interface{} types, they might lead to allocations as well. Hence, GC. Haven't tested this, so feel free to negate me on this one. I know Java Android uses some type of pool pattern to prevent Event allocation and GC.

Finally, the basic example uses the lifecycle.StageVisible Event (which maps to onStart and onStop callbacks) to perform OpenGL resource initialization and destruction. However, in Java Android those should occur in the onResume and onPause callbacks. (Actually, they don't even occur there, rather the Canvas is notified of the state change there which triggers the onInit calls to the Canvas on the GL thread. There is no way to be notified of OpenGL destruction in Java). Was this on purpose or was it an oversight?

As a user, I admit that the lifecycle event model wasn't obvious by just looking at client code and had to check out the docs and source code. It is however pretty easy to grasp.

The good: with the way crosses work, there is no need to send fake events for intermediary stages/states that are not handled on a given platform. For example, right now on X11 the first and last lifecycle event is from StageDead to StageFocussed, yet Crosses allow the user to check that the app has reached StageAlive and StageVisible and act upon it as if they had actually been sent. Of course, the user has to understand that both stages could be crossed in a single event and should be handled in the proper order upon app startup and shutdown. Then again, it's not overly complicated.

The bad: my only gripe with it could be the wording of the API and some needed improvements to the documentation:

• clarify that when calling Crosses(), if s is equal to To it counts as a cross for CrossOn and the same for s equals From for CrossOff. Rename the method to something that makes this more obvious?
• "crosse(s)" is somewhat confusing. May be a Transition type instead of Cross and rename CrossOn/CrossOff to just On/Off.
• remove documentation references to negative and positive crosses (which do not exist in the code) in favor of cross on/off.
• up and down instead of on and off (I picture the model as an ECG...)

IMHO, this API provides a neat wrapper around platform specific event models (that I do not want to bother with), and it can easily be extended by adding intermediary stages should a given platform require it.