Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/mobile/event: lifecycle APIs are overly complicated #11619

rakyll opened this issue Jul 7, 2015 · 3 comments

x/mobile/event: lifecycle APIs are overly complicated #11619

rakyll opened this issue Jul 7, 2015 · 3 comments


Copy link

@rakyll rakyll commented Jul 7, 2015

The new lifecycle events and having to deal with crosses to determine basic states are both overly complicated for an average user. Majority of the time, users don't want to have a good understanding of the lifecycle's itself but want to perform actions such as freeing resources or stopping the playback at certain states. Currently, Go mobile has a novel (invented here™) event model that requires user to have good understanding of its novel terminology and application lifecycle details. The new event model is a big barrier for new and existing users.

I'd, at least, prefer LifecycleStageInvisible and LifecycleStageDestroyed to be pushed to the user, it's very unlikely the users will be comfortable with determining these fundamental states themselves.

@rakyll rakyll added this to the Go1.5 milestone Jul 7, 2015
@rakyll rakyll removed this from the Go1.5 milestone Jul 11, 2015
Copy link

@crawshaw crawshaw commented Jul 15, 2015

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?


@rsc rsc added this to the Unreleased milestone Jul 22, 2015
Copy link

@mokiat mokiat commented Aug 22, 2015

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 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?


Copy link

@db47h db47h commented Nov 12, 2015

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.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants