iOS: second stack in memory disrupts message flow

Ben Rubinstein benr_mc at cogapp.com
Wed May 8 09:52:33 EDT 2013


I spent a lot of time trying to debug why my stack wasn't getting a 'shutdown' 
message when it was backgrounded.  Eventually I found that the issue related 
to the fact that my main stack has opened a preferences stack, invisibly, in 
the background.

The preferences stack is just a carrier for some data - it's created on the 
fly the first time the app launches, subsequently opened from documents 
folder: in either case this occurs inside a push cd/pop cd pair.

Because the prefs stack exists, it receives the 'shutdown' message instead of 
the main stack.

The main stack is definitely the top stack - I can interact with it and so on, 
and I've belt-and-braces tacked on a "toplevel this stack" after loading the 
prefs stack too.  Indeed when I added a shutdown message catcher in the prefs 
stack, and had it log "the topstack" that was my main stack, while "the 
defaultStack" was the prefs stack.  But then it would be, in the context of a 
handler in its stack script.

Finally I found the notice in the dictionary for "shutdown":
> In standalones, some care is needed to ensure you receive the shutdown message if your application uses multiple stacks. The most reliable approach is to install a library stack or backscript to handle the message when your application starts up.

... so I did just that and went on my way.

Then I started trying to do something with the "keyboardActivated" message in 
a card of my mainstack, and found that this message too was being sent to the 
first card of prefs stack instead of to the card that deserved it.  Again I 
can catch it in my backscript: but that handler in the backscript reports both 
"the target" and "the current card" reference the first card of the prefs 
stack, rather than the card, so this is a harder case to work-around, as it's 
less obvious what object the message really should have gone to.

Is this known behaviour, or am I doing something else weird?
Is there any possibility that this behaviour is anything other than a bug?
Is there a way to manipulate it so that the messages go where they should?

For now, I've rewritten things so that the prefs stack is opened, everything 
is moved to globals, then the stack is immediately closed and removed from 
memory; and on shutdown, the prefs stack is opened again, globals are moved to 
properties, the stack is saved and then closed.

This restores normal message routing - is it the best solution?

Many thanks,

Ben




More information about the use-livecode mailing list