FAQ
I'm doing some audio programming with Go on Android and I noticed that my
audio callback continues to be called even long after I leave the app. I
assume that the process continues to run in the background even though the
Activity has been destroyed. Activity *destruction* seems like a good time
to destroy the OpenSL objects. (I have verified that this solves my
problem.) Activity *pause* and *stop* are good candidates for silencing
audio. And it makes sense for the three of these to be complemented with
*create*, *start*, *restart*, and *resume* callbacks. (OpenGL
initialization might find a home in one of these.)

Shall I submit a CL to add these callbacks? Their numerousness puts a
faintly bad taste in my mouth, but a reading of [0] convinces me that they
are mostly essential (the only exception being *restart*, which can be
inferred in *start*).

I seem to recall that these mobile packages are meant to work with iOS apps
as well. I have zero experience with iOS apps, but a quick reading of [1]
indicates a correspondence with iOS events (see especially the app delegate
methods listed there).

[0] http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
[1] https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW3

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • David Crawshaw at Dec 18, 2014 at 8:09 pm
    Somewhere on my desk is a piece of paper where I tried to match the
    android/iOS lifecycle state machines, but I can't find it right now.
    I'm definitely amenable to exposing the lifecycle, but would like to
    do it in the most minimal way possible. A pause callback is
    reasonable, but even resume I'm not sure about: is the fact that calls
    to draw have started again enough information?
    On Thu, Dec 18, 2014 at 3:03 PM, wrote:
    I'm doing some audio programming with Go on Android and I noticed that my
    audio callback continues to be called even long after I leave the app. I
    assume that the process continues to run in the background even though the
    Activity has been destroyed. Activity destruction seems like a good time to
    destroy the OpenSL objects. (I have verified that this solves my problem.)
    Activity pause and stop are good candidates for silencing audio. And it
    makes sense for the three of these to be complemented with create, start,
    restart, and resume callbacks. (OpenGL initialization might find a home in
    one of these.)

    Shall I submit a CL to add these callbacks? Their numerousness puts a
    faintly bad taste in my mouth, but a reading of [0] convinces me that they
    are mostly essential (the only exception being restart, which can be
    inferred in start).

    I seem to recall that these mobile packages are meant to work with iOS apps
    as well. I have zero experience with iOS apps, but a quick reading of [1]
    indicates a correspondence with iOS events (see especially the app delegate
    methods listed there).

    [0]
    http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
    [1]
    https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW3

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gordon Klaus at Dec 18, 2014 at 9:24 pm
    I agree that smaller is usually better.

    I don't think you can infer *resume* from *draw* being called — as a paused
    Android activity is still visible, it seems possible that it can continue
    to redraw while in the paused state. Another relevant consideration is
    whether there are plans to give control over redrawing (which is
    particularly useful for saving battery life when there is nothing to
    animate).

    In any case, it seems clear that at least one of
    *create/start/restart/resume* is necessary. Furthermore, the specifics can
    be inferred from whether the prior transition was *pause,* *stop*, or
    neither, so at most one such callback should also be sufficient.

    That leaves us with Activate, Pause, Stop, and Destroy callbacks. This
    could be simplified to Start() and Stop(r StopReason). I think it would be
    immoderate to reduce it all the way to Transition(s State). I'm leaning
    toward Start/Stop.
    On Thu, Dec 18, 2014 at 9:09 PM, David Crawshaw wrote:

    Somewhere on my desk is a piece of paper where I tried to match the
    android/iOS lifecycle state machines, but I can't find it right now.
    I'm definitely amenable to exposing the lifecycle, but would like to
    do it in the most minimal way possible. A pause callback is
    reasonable, but even resume I'm not sure about: is the fact that calls
    to draw have started again enough information?
    On Thu, Dec 18, 2014 at 3:03 PM, wrote:
    I'm doing some audio programming with Go on Android and I noticed that my
    audio callback continues to be called even long after I leave the app. I
    assume that the process continues to run in the background even though the
    Activity has been destroyed. Activity destruction seems like a good time to
    destroy the OpenSL objects. (I have verified that this solves my problem.)
    Activity pause and stop are good candidates for silencing audio. And it
    makes sense for the three of these to be complemented with create, start,
    restart, and resume callbacks. (OpenGL initialization might find a home in
    one of these.)

    Shall I submit a CL to add these callbacks? Their numerousness puts a
    faintly bad taste in my mouth, but a reading of [0] convinces me that they
    are mostly essential (the only exception being restart, which can be
    inferred in start).

    I seem to recall that these mobile packages are meant to work with iOS apps
    as well. I have zero experience with iOS apps, but a quick reading of [1]
    indicates a correspondence with iOS events (see especially the app delegate
    methods listed there).

    [0]
    http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
    [1]
    https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW3
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gordon Klaus at Dec 18, 2014 at 11:01 pm
    I take back what I said about a Transition(s State) callback being
    immoderate. I like the way it encapsulates app lifecycle management into a
    single function.

    For completeness: app.State could be Active, Inactive, Background, or
    Terminating. These correspond well with both iOS and Android app states.
    There is also a strong correspondence between state transitions for both
    platforms.
    On Thu, Dec 18, 2014 at 10:24 PM, Gordon Klaus wrote:

    I agree that smaller is usually better.

    I don't think you can infer *resume* from *draw* being called — as a
    paused Android activity is still visible, it seems possible that it can
    continue to redraw while in the paused state. Another relevant
    consideration is whether there are plans to give control over redrawing
    (which is particularly useful for saving battery life when there is nothing
    to animate).

    In any case, it seems clear that at least one of
    *create/start/restart/resume* is necessary. Furthermore, the specifics
    can be inferred from whether the prior transition was *pause,* *stop*, or
    neither, so at most one such callback should also be sufficient.

    That leaves us with Activate, Pause, Stop, and Destroy callbacks. This
    could be simplified to Start() and Stop(r StopReason). I think it would be
    immoderate to reduce it all the way to Transition(s State). I'm leaning
    toward Start/Stop.
    On Thu, Dec 18, 2014 at 9:09 PM, David Crawshaw wrote:

    Somewhere on my desk is a piece of paper where I tried to match the
    android/iOS lifecycle state machines, but I can't find it right now.
    I'm definitely amenable to exposing the lifecycle, but would like to
    do it in the most minimal way possible. A pause callback is
    reasonable, but even resume I'm not sure about: is the fact that calls
    to draw have started again enough information?
    On Thu, Dec 18, 2014 at 3:03 PM, wrote:
    I'm doing some audio programming with Go on Android and I noticed that my
    audio callback continues to be called even long after I leave the app. I
    assume that the process continues to run in the background even though the
    Activity has been destroyed. Activity destruction seems like a good time to
    destroy the OpenSL objects. (I have verified that this solves my problem.)
    Activity pause and stop are good candidates for silencing audio. And it
    makes sense for the three of these to be complemented with create, start,
    restart, and resume callbacks. (OpenGL initialization might find a home in
    one of these.)

    Shall I submit a CL to add these callbacks? Their numerousness puts a
    faintly bad taste in my mouth, but a reading of [0] convinces me that they
    are mostly essential (the only exception being restart, which can be
    inferred in start).

    I seem to recall that these mobile packages are meant to work with iOS apps
    as well. I have zero experience with iOS apps, but a quick reading of [1]
    indicates a correspondence with iOS events (see especially the app delegate
    methods listed there).

    [0]
    http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
    [1]
    https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW3
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • David Crawshaw at Dec 19, 2014 at 1:18 am
    I found my notes and I'm pondering this. I'll send a CL soon. Thanks
    for bringing this up.
    On Thu, Dec 18, 2014 at 6:01 PM, Gordon Klaus wrote:
    I take back what I said about a Transition(s State) callback being
    immoderate. I like the way it encapsulates app lifecycle management into a
    single function.

    For completeness: app.State could be Active, Inactive, Background, or
    Terminating. These correspond well with both iOS and Android app states.
    There is also a strong correspondence between state transitions for both
    platforms.
    On Thu, Dec 18, 2014 at 10:24 PM, Gordon Klaus wrote:

    I agree that smaller is usually better.

    I don't think you can infer resume from draw being called — as a paused
    Android activity is still visible, it seems possible that it can continue to
    redraw while in the paused state. Another relevant consideration is whether
    there are plans to give control over redrawing (which is particularly useful
    for saving battery life when there is nothing to animate).

    In any case, it seems clear that at least one of
    create/start/restart/resume is necessary. Furthermore, the specifics can be
    inferred from whether the prior transition was pause, stop, or neither, so
    at most one such callback should also be sufficient.

    That leaves us with Activate, Pause, Stop, and Destroy callbacks. This
    could be simplified to Start() and Stop(r StopReason). I think it would be
    immoderate to reduce it all the way to Transition(s State). I'm leaning
    toward Start/Stop.

    On Thu, Dec 18, 2014 at 9:09 PM, David Crawshaw <crawshaw@golang.org>
    wrote:
    Somewhere on my desk is a piece of paper where I tried to match the
    android/iOS lifecycle state machines, but I can't find it right now.
    I'm definitely amenable to exposing the lifecycle, but would like to
    do it in the most minimal way possible. A pause callback is
    reasonable, but even resume I'm not sure about: is the fact that calls
    to draw have started again enough information?
    On Thu, Dec 18, 2014 at 3:03 PM, wrote:
    I'm doing some audio programming with Go on Android and I noticed that
    my
    audio callback continues to be called even long after I leave the app.
    I
    assume that the process continues to run in the background even though
    the
    Activity has been destroyed. Activity destruction seems like a good
    time to
    destroy the OpenSL objects. (I have verified that this solves my
    problem.)
    Activity pause and stop are good candidates for silencing audio. And
    it
    makes sense for the three of these to be complemented with create,
    start,
    restart, and resume callbacks. (OpenGL initialization might find a
    home in
    one of these.)

    Shall I submit a CL to add these callbacks? Their numerousness puts a
    faintly bad taste in my mouth, but a reading of [0] convinces me that
    they
    are mostly essential (the only exception being restart, which can be
    inferred in start).

    I seem to recall that these mobile packages are meant to work with iOS
    apps
    as well. I have zero experience with iOS apps, but a quick reading of
    [1]
    indicates a correspondence with iOS events (see especially the app
    delegate
    methods listed there).

    [0]

    http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
    [1]

    https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW3

    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gordon Klaus at Dec 19, 2014 at 8:59 am
    Aw, shucks, I was hoping to get my hands dirty. Just let me know if
    there's anything I can help with. And thanks for working on this stuff! I
    doubt I would have gotten into mobile development if it weren't for Go.

    FWIW, if you go with Transition(s State), I think the states should be
    defined as:

    const (
         Stopped State = iota
         Active
         Inactive
         Background
    )

    so that the zero value for State is Stopped. Then typical usage would
    involve maintaining a global "var state State" recording the current/prior
    state, and a callback would look like:

    func transition(s app.State) {
         prior := state
         switch s {
         case app.Active:
             if prior == app.Stopped {
                 initGL()
                 initSL()
                 // etc
             }
             // handle other transitions to Active
         case app.Inactive:
             // ...
         case app.Background:
             // ...
         case app.Stopped:
             // ...
         }
         state = s
    }

    But now that I see what it looks like, I begin to think that it would be
    clearer to have a separate callback for each interesting transition. Of
    which there seem to be about six :/
    On Fri, Dec 19, 2014 at 2:18 AM, David Crawshaw wrote:

    I found my notes and I'm pondering this. I'll send a CL soon. Thanks
    for bringing this up.
    On Thu, Dec 18, 2014 at 6:01 PM, Gordon Klaus wrote:
    I take back what I said about a Transition(s State) callback being
    immoderate. I like the way it encapsulates app lifecycle management into a
    single function.

    For completeness: app.State could be Active, Inactive, Background, or
    Terminating. These correspond well with both iOS and Android app states.
    There is also a strong correspondence between state transitions for both
    platforms.

    On Thu, Dec 18, 2014 at 10:24 PM, Gordon Klaus <gordon.klaus@gmail.com>
    wrote:
    I agree that smaller is usually better.

    I don't think you can infer resume from draw being called — as a paused
    Android activity is still visible, it seems possible that it can
    continue to
    redraw while in the paused state. Another relevant consideration is
    whether
    there are plans to give control over redrawing (which is particularly
    useful
    for saving battery life when there is nothing to animate).

    In any case, it seems clear that at least one of
    create/start/restart/resume is necessary. Furthermore, the specifics
    can be
    inferred from whether the prior transition was pause, stop, or neither,
    so
    at most one such callback should also be sufficient.

    That leaves us with Activate, Pause, Stop, and Destroy callbacks. This
    could be simplified to Start() and Stop(r StopReason). I think it
    would be
    immoderate to reduce it all the way to Transition(s State). I'm leaning
    toward Start/Stop.

    On Thu, Dec 18, 2014 at 9:09 PM, David Crawshaw <crawshaw@golang.org>
    wrote:
    Somewhere on my desk is a piece of paper where I tried to match the
    android/iOS lifecycle state machines, but I can't find it right now.
    I'm definitely amenable to exposing the lifecycle, but would like to
    do it in the most minimal way possible. A pause callback is
    reasonable, but even resume I'm not sure about: is the fact that calls
    to draw have started again enough information?
    On Thu, Dec 18, 2014 at 3:03 PM, wrote:
    I'm doing some audio programming with Go on Android and I noticed
    that
    my
    audio callback continues to be called even long after I leave the
    app.
    I
    assume that the process continues to run in the background even
    though
    the
    Activity has been destroyed. Activity destruction seems like a good
    time to
    destroy the OpenSL objects. (I have verified that this solves my
    problem.)
    Activity pause and stop are good candidates for silencing audio. And
    it
    makes sense for the three of these to be complemented with create,
    start,
    restart, and resume callbacks. (OpenGL initialization might find a
    home in
    one of these.)

    Shall I submit a CL to add these callbacks? Their numerousness puts
    a
    faintly bad taste in my mouth, but a reading of [0] convinces me that
    they
    are mostly essential (the only exception being restart, which can be
    inferred in start).

    I seem to recall that these mobile packages are meant to work with
    iOS
    apps
    as well. I have zero experience with iOS apps, but a quick reading
    of
    [1]
    indicates a correspondence with iOS events (see especially the app
    delegate
    methods listed there).

    [0]
    http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
    [1]
    https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW3
    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it,
    send
    an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • David Crawshaw at Dec 19, 2014 at 3:39 pm
    I have attempted something slightly smaller. I would appreciate your
    review of https://go-review.googlesource.com/1881
    On Fri, Dec 19, 2014 at 3:59 AM, Gordon Klaus wrote:
    Aw, shucks, I was hoping to get my hands dirty. Just let me know if there's
    anything I can help with. And thanks for working on this stuff! I doubt I
    would have gotten into mobile development if it weren't for Go.

    FWIW, if you go with Transition(s State), I think the states should be
    defined as:

    const (
    Stopped State = iota
    Active
    Inactive
    Background
    )

    so that the zero value for State is Stopped. Then typical usage would
    involve maintaining a global "var state State" recording the current/prior
    state, and a callback would look like:

    func transition(s app.State) {
    prior := state
    switch s {
    case app.Active:
    if prior == app.Stopped {
    initGL()
    initSL()
    // etc
    }
    // handle other transitions to Active
    case app.Inactive:
    // ...
    case app.Background:
    // ...
    case app.Stopped:
    // ...
    }
    state = s
    }

    But now that I see what it looks like, I begin to think that it would be
    clearer to have a separate callback for each interesting transition. Of
    which there seem to be about six :/
    On Fri, Dec 19, 2014 at 2:18 AM, David Crawshaw wrote:

    I found my notes and I'm pondering this. I'll send a CL soon. Thanks
    for bringing this up.

    On Thu, Dec 18, 2014 at 6:01 PM, Gordon Klaus <gordon.klaus@gmail.com>
    wrote:
    I take back what I said about a Transition(s State) callback being
    immoderate. I like the way it encapsulates app lifecycle management
    into a
    single function.

    For completeness: app.State could be Active, Inactive, Background, or
    Terminating. These correspond well with both iOS and Android app
    states.
    There is also a strong correspondence between state transitions for both
    platforms.

    On Thu, Dec 18, 2014 at 10:24 PM, Gordon Klaus <gordon.klaus@gmail.com>
    wrote:
    I agree that smaller is usually better.

    I don't think you can infer resume from draw being called — as a paused
    Android activity is still visible, it seems possible that it can
    continue to
    redraw while in the paused state. Another relevant consideration is
    whether
    there are plans to give control over redrawing (which is particularly
    useful
    for saving battery life when there is nothing to animate).

    In any case, it seems clear that at least one of
    create/start/restart/resume is necessary. Furthermore, the specifics
    can be
    inferred from whether the prior transition was pause, stop, or neither,
    so
    at most one such callback should also be sufficient.

    That leaves us with Activate, Pause, Stop, and Destroy callbacks. This
    could be simplified to Start() and Stop(r StopReason). I think it
    would be
    immoderate to reduce it all the way to Transition(s State). I'm
    leaning
    toward Start/Stop.

    On Thu, Dec 18, 2014 at 9:09 PM, David Crawshaw <crawshaw@golang.org>
    wrote:
    Somewhere on my desk is a piece of paper where I tried to match the
    android/iOS lifecycle state machines, but I can't find it right now.
    I'm definitely amenable to exposing the lifecycle, but would like to
    do it in the most minimal way possible. A pause callback is
    reasonable, but even resume I'm not sure about: is the fact that calls
    to draw have started again enough information?
    On Thu, Dec 18, 2014 at 3:03 PM, wrote:
    I'm doing some audio programming with Go on Android and I noticed
    that
    my
    audio callback continues to be called even long after I leave the
    app.
    I
    assume that the process continues to run in the background even
    though
    the
    Activity has been destroyed. Activity destruction seems like a good
    time to
    destroy the OpenSL objects. (I have verified that this solves my
    problem.)
    Activity pause and stop are good candidates for silencing audio.
    And
    it
    makes sense for the three of these to be complemented with create,
    start,
    restart, and resume callbacks. (OpenGL initialization might find a
    home in
    one of these.)

    Shall I submit a CL to add these callbacks? Their numerousness puts
    a
    faintly bad taste in my mouth, but a reading of [0] convinces me
    that
    they
    are mostly essential (the only exception being restart, which can be
    inferred in start).

    I seem to recall that these mobile packages are meant to work with
    iOS
    apps
    as well. I have zero experience with iOS apps, but a quick reading
    of
    [1]
    indicates a correspondence with iOS events (see especially the app
    delegate
    methods listed there).

    [0]


    http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
    [1]


    https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW3

    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it,
    send
    an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gordon Klaus at Dec 19, 2014 at 4:49 pm
    Yes, that's much simpler. There's still room to add Pause if necessary.
    On Fri, Dec 19, 2014 at 4:39 PM, David Crawshaw wrote:

    I have attempted something slightly smaller. I would appreciate your
    review of https://go-review.googlesource.com/1881
    On Fri, Dec 19, 2014 at 3:59 AM, Gordon Klaus wrote:
    Aw, shucks, I was hoping to get my hands dirty. Just let me know if there's
    anything I can help with. And thanks for working on this stuff! I doubt I
    would have gotten into mobile development if it weren't for Go.

    FWIW, if you go with Transition(s State), I think the states should be
    defined as:

    const (
    Stopped State = iota
    Active
    Inactive
    Background
    )

    so that the zero value for State is Stopped. Then typical usage would
    involve maintaining a global "var state State" recording the
    current/prior
    state, and a callback would look like:

    func transition(s app.State) {
    prior := state
    switch s {
    case app.Active:
    if prior == app.Stopped {
    initGL()
    initSL()
    // etc
    }
    // handle other transitions to Active
    case app.Inactive:
    // ...
    case app.Background:
    // ...
    case app.Stopped:
    // ...
    }
    state = s
    }

    But now that I see what it looks like, I begin to think that it would be
    clearer to have a separate callback for each interesting transition. Of
    which there seem to be about six :/
    On Fri, Dec 19, 2014 at 2:18 AM, David Crawshaw wrote:

    I found my notes and I'm pondering this. I'll send a CL soon. Thanks
    for bringing this up.

    On Thu, Dec 18, 2014 at 6:01 PM, Gordon Klaus <gordon.klaus@gmail.com>
    wrote:
    I take back what I said about a Transition(s State) callback being
    immoderate. I like the way it encapsulates app lifecycle management
    into a
    single function.

    For completeness: app.State could be Active, Inactive, Background, or
    Terminating. These correspond well with both iOS and Android app
    states.
    There is also a strong correspondence between state transitions for
    both
    platforms.

    On Thu, Dec 18, 2014 at 10:24 PM, Gordon Klaus <
    gordon.klaus@gmail.com>
    wrote:
    I agree that smaller is usually better.

    I don't think you can infer resume from draw being called — as a
    paused
    Android activity is still visible, it seems possible that it can
    continue to
    redraw while in the paused state. Another relevant consideration is
    whether
    there are plans to give control over redrawing (which is particularly
    useful
    for saving battery life when there is nothing to animate).

    In any case, it seems clear that at least one of
    create/start/restart/resume is necessary. Furthermore, the specifics
    can be
    inferred from whether the prior transition was pause, stop, or
    neither,
    so
    at most one such callback should also be sufficient.

    That leaves us with Activate, Pause, Stop, and Destroy callbacks.
    This
    could be simplified to Start() and Stop(r StopReason). I think it
    would be
    immoderate to reduce it all the way to Transition(s State). I'm
    leaning
    toward Start/Stop.

    On Thu, Dec 18, 2014 at 9:09 PM, David Crawshaw <crawshaw@golang.org
    wrote:
    Somewhere on my desk is a piece of paper where I tried to match the
    android/iOS lifecycle state machines, but I can't find it right now.
    I'm definitely amenable to exposing the lifecycle, but would like to
    do it in the most minimal way possible. A pause callback is
    reasonable, but even resume I'm not sure about: is the fact that
    calls
    to draw have started again enough information?
    On Thu, Dec 18, 2014 at 3:03 PM, wrote:
    I'm doing some audio programming with Go on Android and I noticed
    that
    my
    audio callback continues to be called even long after I leave the
    app.
    I
    assume that the process continues to run in the background even
    though
    the
    Activity has been destroyed. Activity destruction seems like a
    good
    time to
    destroy the OpenSL objects. (I have verified that this solves my
    problem.)
    Activity pause and stop are good candidates for silencing audio.
    And
    it
    makes sense for the three of these to be complemented with create,
    start,
    restart, and resume callbacks. (OpenGL initialization might find
    a
    home in
    one of these.)

    Shall I submit a CL to add these callbacks? Their numerousness
    puts
    a
    faintly bad taste in my mouth, but a reading of [0] convinces me
    that
    they
    are mostly essential (the only exception being restart, which can
    be
    inferred in start).

    I seem to recall that these mobile packages are meant to work with
    iOS
    apps
    as well. I have zero experience with iOS apps, but a quick
    reading
    of
    [1]
    indicates a correspondence with iOS events (see especially the app
    delegate
    methods listed there).

    [0]

    http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
    [1]

    https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW3
    --
    You received this message because you are subscribed to the Google
    Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it,
    send
    an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kevin Gillette at Dec 19, 2014 at 6:40 pm

    On Thursday, December 18, 2014 4:01:43 PM UTC-7, Gordon Klaus wrote:
    For completeness: app.State could be Active, Inactive, Background, or
    Terminating. These correspond well with both iOS and Android app states.
    There is also a strong correspondence between state transitions for both
    platforms.
    I can't see any semantic analogue to "Inactive" from the Android reference
    you provided. Also, in the iOS reference, the "Inactive" state is described
    as:

    The app is running in the foreground but is currently not receiving events.
    (It may be executing other code though.) An app usually stays in this state
    only briefly as it transitions to a different state.

    Based on the iOS lifecycle diagram in that same reference, there's no way
    for an app to get destroyed (in the common case) without first being
    backgrounded, and both Background and Inactive both have the property of
    not receiving events. Conversely, the app can't be interacted with until it
    is in the Active state -- being ignorant of the Inactive state seems
    harmless by Apple's own description, so, it looks like there's little value
    in including "Inactive" to the list of application states we expose.

    If you really want to bridge the gap between iOS and Android in terms of
    lifecycle management, from what I can see, the approach would be to break
    the concept of Active/Foreground into independent states for visibility and
    interactivity. Thus, for iOS:


        1. native Inactive state: app becomes visible and non-interactive -- you
        can begin rendering
        2. native Active state: app becomes interactive (it was already visible)
        3. native Background state: app becomes non-visible (it was already
        non-interactive)

    For Android:

        1. native onStart event: app becomes visible -- you can begin rendering
        2. native onResume event: app becomes interactive (it was already
        visible)
        3. native onPause event: app becomes non-interactive (it's still visible)
        4. native onStop event: app becomes non-visible


    Both platforms also have a "will be terminating" event as well.

    Thus the constants may look like:

    const (
        Visible State = 1 << iota
        Interactive
        Terminating
    )

    Since some of the Android events are synchronous -- the device ui will hang
    until the event handler returns, and thus must be done as quickly as
    possible, though it may not be safe to do persistence and cleanup after
    returning -- I agree with Gordon that we need either a callback, or some
    other way, explicit or otherwise, to notify the Go Android layer that
    "we're done handling the transition" -- it would cause a lot of stability
    problems if mobile/app just set some global queryable states ((or did
    fire-and-forget notifications) and returned immediately, as that'd produce
    a high level race condition. In other words, os/signal's strategy would not
    work here.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • David Crawshaw at Dec 19, 2014 at 6:46 pm
    I considered a lot of possible states, but I'm focusing on value.
    Similarly I could distinguish between Started and Resumed on android,
    but how is it useful to an app?

    What seems to be key are:
    1. when do I start drawing/receiving events?
    2. when do I clean up?

    Beyond that, the next useful thing seems to be: starting background
    tasks during cleanup. But the inactive state on iOS seems not very
    useful, similarly the paused state on android is not very useful. This
    design lets us add them later if I can think of a good use case.

    On Fri, Dec 19, 2014 at 1:40 PM, Kevin Gillette
    wrote:
    On Thursday, December 18, 2014 4:01:43 PM UTC-7, Gordon Klaus wrote:

    For completeness: app.State could be Active, Inactive, Background, or
    Terminating. These correspond well with both iOS and Android app states.
    There is also a strong correspondence between state transitions for both
    platforms.

    I can't see any semantic analogue to "Inactive" from the Android reference
    you provided. Also, in the iOS reference, the "Inactive" state is described
    as:
    The app is running in the foreground but is currently not receiving
    events. (It may be executing other code though.) An app usually stays in
    this state only briefly as it transitions to a different state.

    Based on the iOS lifecycle diagram in that same reference, there's no way
    for an app to get destroyed (in the common case) without first being
    backgrounded, and both Background and Inactive both have the property of not
    receiving events. Conversely, the app can't be interacted with until it is
    in the Active state -- being ignorant of the Inactive state seems harmless
    by Apple's own description, so, it looks like there's little value in
    including "Inactive" to the list of application states we expose.

    If you really want to bridge the gap between iOS and Android in terms of
    lifecycle management, from what I can see, the approach would be to break
    the concept of Active/Foreground into independent states for visibility and
    interactivity. Thus, for iOS:

    native Inactive state: app becomes visible and non-interactive -- you can
    begin rendering
    native Active state: app becomes interactive (it was already visible)
    native Background state: app becomes non-visible (it was already
    non-interactive)

    For Android:

    native onStart event: app becomes visible -- you can begin rendering
    native onResume event: app becomes interactive (it was already visible)
    native onPause event: app becomes non-interactive (it's still visible)
    native onStop event: app becomes non-visible


    Both platforms also have a "will be terminating" event as well.

    Thus the constants may look like:

    const (
    Visible State = 1 << iota
    Interactive
    Terminating
    )

    Since some of the Android events are synchronous -- the device ui will hang
    until the event handler returns, and thus must be done as quickly as
    possible, though it may not be safe to do persistence and cleanup after
    returning -- I agree with Gordon that we need either a callback, or some
    other way, explicit or otherwise, to notify the Go Android layer that "we're
    done handling the transition" -- it would cause a lot of stability problems
    if mobile/app just set some global queryable states ((or did fire-and-forget
    notifications) and returned immediately, as that'd produce a high level race
    condition. In other words, os/signal's strategy would not work here.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gordon Klaus at Dec 19, 2014 at 7:26 pm

    On Fri, Dec 19, 2014 at 7:40 PM, Kevin Gillette wrote:
    I can't see any semantic analogue to "Inactive" from the Android reference
    you provided. Also, in the iOS reference, the "Inactive" state is described
    as:

    The app is running in the foreground but is currently not receiving
    events. (It may be executing other code though.) An app usually stays in
    this state only briefly as it transitions to a different state.
    Android's Paused state seems to be roughly analogous to iOS's Inactive
    state. The only possible difference that I see is that while an Inactive
    iOS app definitely does not redraw, a Paused Android app might (it's not
    clear from the doc).

    Based on the iOS lifecycle diagram in that same reference, there's no way
    for an app to get destroyed (in the common case) without first being
    backgrounded, and both Background and Inactive both have the property of
    not receiving events. Conversely, the app can't be interacted with until it
    is in the Active state -- being ignorant of the Inactive state seems
    harmless by Apple's own description, so, it looks like there's little value
    in including "Inactive" to the list of application states we expose.
    I agree that iOS's Inactive state seems pretty useless – it's only a brief
    waypoint between other states – but it's the closest analogue I can see to
    Android's Paused state, which does seem useful. I can imagine, for
    example, pausing animations, reducing audio volume, or fading to grey upon
    pausing an Android app.

    If you really want to bridge the gap between iOS and Android in terms of
    lifecycle management, from what I can see, the approach would be to break
    the concept of Active/Foreground into independent states for visibility and
    interactivity. Thus, for iOS:


    1. native Inactive state: app becomes visible and non-interactive --
    you can begin rendering
    2. native Active state: app becomes interactive (it was already
    visible)
    3. native Background state: app becomes non-visible (it was already
    non-interactive)

    For Android:

    1. native onStart event: app becomes visible -- you can begin rendering
    2. native onResume event: app becomes interactive (it was already
    visible)
    3. native onPause event: app becomes non-interactive (it's still
    visible)
    4. native onStop event: app becomes non-visible


    Both platforms also have a "will be terminating" event as well.

    Thus the constants may look like:

    const (
    Visible State = 1 << iota
    Interactive
    Terminating
    )
    This looks reasonable, but I'm still inclining away from a state-based API
    in favor of a transition-based API. The state-based API is smaller but, as
    you saw in my example transition function, it leads to a verbose callback.

    Since some of the Android events are synchronous -- the device ui will
    hang until the event handler returns, and thus must be done as quickly as
    possible, though it may not be safe to do persistence and cleanup after
    returning -- I agree with Gordon that we need either a callback, or some
    other way, explicit or otherwise, to notify the Go Android layer that
    "we're done handling the transition" -- it would cause a lot of stability
    problems if mobile/app just set some global queryable states ((or did
    fire-and-forget notifications) and returned immediately, as that'd
    produce a high level race condition. In other words, os/signal's strategy
    would not work here.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • David Crawshaw at Dec 19, 2014 at 7:47 pm
    I believe the android paused state is, for normal apps, about as
    useless as the iOS inactive state. From the android docs: "When your
    activity receives a call to onPause(), it may be an indication that
    the activity will be paused for a moment and the user may return focus
    to your activity. However, it's usually the first indication that the
    user is leaving your activity."

    In my experiments last night I was unable to come up with a case in
    normal operation where onPause wasn't followed quickly by onStop. Even
    clicking on the task switcher immediately calls onPause+onStop on an
    app.

    So for now, I intend to ignore onPause until an interesting use case appears.
    On Fri, Dec 19, 2014 at 2:26 PM, Gordon Klaus wrote:
    On Fri, Dec 19, 2014 at 7:40 PM, Kevin Gillette wrote:

    I can't see any semantic analogue to "Inactive" from the Android reference
    you provided. Also, in the iOS reference, the "Inactive" state is described
    as:
    The app is running in the foreground but is currently not receiving
    events. (It may be executing other code though.) An app usually stays in
    this state only briefly as it transitions to a different state.

    Android's Paused state seems to be roughly analogous to iOS's Inactive
    state. The only possible difference that I see is that while an Inactive
    iOS app definitely does not redraw, a Paused Android app might (it's not
    clear from the doc).
    Based on the iOS lifecycle diagram in that same reference, there's no way
    for an app to get destroyed (in the common case) without first being
    backgrounded, and both Background and Inactive both have the property of not
    receiving events. Conversely, the app can't be interacted with until it is
    in the Active state -- being ignorant of the Inactive state seems harmless
    by Apple's own description, so, it looks like there's little value in
    including "Inactive" to the list of application states we expose.

    I agree that iOS's Inactive state seems pretty useless – it's only a brief
    waypoint between other states – but it's the closest analogue I can see to
    Android's Paused state, which does seem useful. I can imagine, for example,
    pausing animations, reducing audio volume, or fading to grey upon pausing an
    Android app.
    If you really want to bridge the gap between iOS and Android in terms of
    lifecycle management, from what I can see, the approach would be to break
    the concept of Active/Foreground into independent states for visibility and
    interactivity. Thus, for iOS:

    native Inactive state: app becomes visible and non-interactive -- you can
    begin rendering
    native Active state: app becomes interactive (it was already visible)
    native Background state: app becomes non-visible (it was already
    non-interactive)

    For Android:

    native onStart event: app becomes visible -- you can begin rendering
    native onResume event: app becomes interactive (it was already visible)
    native onPause event: app becomes non-interactive (it's still visible)
    native onStop event: app becomes non-visible


    Both platforms also have a "will be terminating" event as well.

    Thus the constants may look like:

    const (
    Visible State = 1 << iota
    Interactive
    Terminating
    )

    This looks reasonable, but I'm still inclining away from a state-based API
    in favor of a transition-based API. The state-based API is smaller but, as
    you saw in my example transition function, it leads to a verbose callback.
    Since some of the Android events are synchronous -- the device ui will
    hang until the event handler returns, and thus must be done as quickly as
    possible, though it may not be safe to do persistence and cleanup after
    returning -- I agree with Gordon that we need either a callback, or some
    other way, explicit or otherwise, to notify the Go Android layer that "we're
    done handling the transition" -- it would cause a lot of stability problems
    if mobile/app just set some global queryable states ((or did fire-and-forget
    notifications) and returned immediately, as that'd produce a high level race
    condition. In other words, os/signal's strategy would not work here.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nate Behary at Dec 20, 2014 at 2:55 am
    The only main thing about onStop/onPause that may be an issue, is that
    onPause is the only of the 2 that is guaranteed to be called. In low
    memory situations, an app can go directly from onPause to killed. (Which
    is why the primary use for it is saving anything you are sure the user
    wants to keep)

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 18, '14 at 8:03p
activeDec 20, '14 at 2:55a
posts13
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase