When is open stack sent on Mobile

[Sannyasin Brahmanathaswami]

@ Mark… thanks for the clarification

The current app we have in progress is modular… many, many stacks being called all of which are independent LC stacks (not substacks of anything). it works quite well on the desktop but on mobile there are caveats that have to be dealt with explicitly and "immediately" so to speak, when:

instantiating scrollers
     -- the standard implementation is to delete a scrolling regions when creating a new one, because you can't necessarily know where (what card, stack) the user is coming and going from and the ID and rect of the scroller that is required on any given card will differ. So if you are firing those on open stack, then you need to close it first.  I'm  a newbie at this mobile stuff, so perhaps over time we will find better architecture, but for now I've start issuing a "close this stack" on every move to a different "module" (stack) … this works. 

switching from landscape to portrait
    -- similarly one must re-set up the UI explicitly and typically the old way of doing such would be in a preopen or open stack handlers… again, these need to fire when moving back and forth. Just this morning I successfully was able to go from a stack in portrait orientation lock to portrait, portrait upside down to a landscape stack, lock to landscape right, left… and back again…  but it required specifically setting the rect of the stack to 0,0,414,716 in a preopen stack handler

So  I've taken to using things like this throughout, because the user could be on card 3 of Stack 2, (portrait) moves to card 5 of Stack 6 (landscape)… so "Back" requires

command closeStopCloseGoRecent
   go recent
   close me # to ensure that future preopen and open stack handlers fire
end closeStopCloseGoRecent

so that when we go back to Stack 6.. the 

on preopenstack
   initializeInterfaceDefaults pOrientation 
# in which we explicitly set up card rect
# mobileSetAllowedOrientation  on the fly… 
end preopenstack

I'm sure others could analyze the frame work and come up with more optimized methods… but so far it's working!  I'm not sure that "go in window" gets us much more than what I'm doing now.

Slowly finding ways to moving thing to common backscripts and behaviors. But "who gets the message" can be tricky.  e.g. I'm told that "the script that creates mobile object gets it's subsequent messages… " OK… and it appears these message will not "cascade up" the message path. So still stuck on scrollers--I have the same script to instantiate scrollers in every stack, because the same methods that work in that context do not work if I move them to a single common behavior for the different stacks… I suspect because the preopencard handler is call the 

createScroller "portal-links" 

 and since the messages about this are sent back to the card… the behavior never gets it… most significantly, the cmd to delete existing scroller with different ID for that same or different region. 

Still wrestling with that one… or rather, threw in the towel after two days wasted trying to optimize the architecture.. I bailed and copied that createScroller handler to all the stacks… 

learning slowly…


On 7/28/16, 6:43 AM, "use-livecode on behalf of Mark Waddingham" <use-livecode-bounces at lists.runrev.com on behalf of mark at livecode.com> wrote:

    Stacks on mobile and desktop work in the same way so if you 'go stack' 
    then it opens the new stack (if it is not already open) and moves it 
    (notionally) to the top (just as happens on desktop - the window of the 
    target of 'go' is brought to the front of that layer).
    
    If you use 'go stack ... in window ...' then it will close the current 
    stack and open the new one.