@ 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"
<[email protected] on behalf of [email protected]> 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.
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
