Re: Go in Window on Mobile / Not Obeying Purge?
Good question. Unless there are stress-testing tools for this, maybe open the app in the morning, use a lot of apps throughout day while never re-opening yours, and in the evening finally bring yours to the front any see if it evidences time-dependent behavior. -- Richard Gaskin Fourth World Systems Terry Judd wrote: > Haven't noticed any problems but the honest answer is that I don't > know. How would you go about testing for issues? > > > On 4/3/19, 5:28 am, "use-livecode on behalf of Richard Gaskin wrote: > > Terry Judd wrote: > >> While there don't appear to be suspend or resume messages on >> mobile you can sort of script your own resume message using a >> timer. >> >> I had thought both iOS and Android would reclaim memory by closing >> backgrounded apps if needed. >> >> Is that no longer the case? > > Does the use of the timer prevent the OS from being able to manage > its apps, perhaps similar to how LC on the desktop won't quit if > timers are pending? > > -- > Richard Gaskin ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Go in Window on Mobile / Not Obeying Purge?
Haven't noticed any problems but the honest answer is that I don't know. How would you go about testing for issues? Terry... On 4/3/19, 5:28 am, "use-livecode on behalf of Richard Gaskin via use-livecode" wrote: Terry Judd wrote: > While there don't appear to be suspend or resume messages on mobile > you can sort of script your own resume message using a timer. I had thought both iOS and Android would reclaim memory by closing backgrounded apps if needed. Is that no longer the case? Does the use of the timer prevent the OS from being able to manage its apps, perhaps similar to how LC on the desktop won't quit if timers are pending? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Go in Window on Mobile / Not Obeying Purge?
Terry Judd wrote: > While there don't appear to be suspend or resume messages on mobile > you can sort of script your own resume message using a timer. I had thought both iOS and Android would reclaim memory by closing backgrounded apps if needed. Is that no longer the case? Does the use of the timer prevent the OS from being able to manage its apps, perhaps similar to how LC on the desktop won't quit if timers are pending? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Go in Window on Mobile / Not Obeying Purge?
Wow, that's cool we could put a button in the game that passed. "Keep Puzzle" (# for as long as the app is open) on MouseUp updateSessionTimer "reset" end mouseup though I wonder if the app would crash after a while, if the user forgot about it? Worth a try, because there a very "strong" use case for this. -- user is doing an activity in your app -- received/makes a phone call, email, got a "What app" notification...etc interrupted for whatever reason... -- resumes activity in your app Brahmanathaswami Terry Judd wrote: While there don't appear to be suspend or resume messages on mobile you can sort of script your own resume message using a timer. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Go in Window on Mobile / Not Obeying Purge?
While there don't appear to be suspend or resume messages on mobile you can sort of script your own resume message using a timer. If the timer is updated regularly using a send in time approach then the send will be delayed while the app is in the background. If the interval between the current and previous timer update is longer than expected then the app has been suspended and resumed. Some example code below... on updateSessionTimer pCmd if pCmd = "clear" then put empty into pSessionTimer put the pendingMessages into tPM filter tPM with "*updateSessionTimer*" repeat for each line tX in tPM cancel (item 1 of tX) end repeat exit updateSessionTimer end if if (pCmd = "reset") or (pSessionTimer is empty) then # initialise sessionTimer put seconds() into pSessionTimer send "updateSessionTimer" to me in 5 secs else put seconds() into tNow put tNow-pSessionTimer into tElapsed put tNow into pSessionTimer send "updateSessionTimer" to me in 5 secs if tElapsed > 10 then answer "resuming after suspend" ## end if end if end updateSessionTimer On 3/03/2019 4:10 am, "use-livecode on behalf of J. Landman Gay via use-livecode" wrote: On Android, if you leave the app, the OS will remove it from RAM if it needs the memory. It sounds like iOS is doing the same thing. Since SivaSiva is so big, memory may be tight enough to drop the puzzle stack when you come back to the app. It would depend on the RAM in the device. I don't know of any resume messages, though I wish we had them. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 2, 2019 7:43:20 AM Sannyasin Brahmanathaswami via use-livecode wrote: > Good morning Richard > >"But just to clarify, the stack in question is a separate stack file, and >not a substack of the one you're going to, yes?" > > @ Peter & Ralph > > "inspectors still open for closed stack" -- that would be only desktop. But > this is on mobile. In a standalone. > > I am seeing runtime changes to the UI -- a puzzle game, you can leave it > mid-way through the game, all the "tiles" left in a new location... go to > another stack, go third stack, and back to the puzzle. Tiles are still > where you left them So, we deem this a "bug"? But... could be a possible > use case to leave it the way it is? > > Navigation is now using a "back" script call > > Lib_SivaSivaPortal.livecodescript > > Handler: portal_GoStack (trimmed version for this mail) > > command portal_GoStack cardOrStackObject > > put the short name of this stack into oStackName > > # cannot pass quotes to these strings or you will > # break the JSON, BR added utilities section to lib_SivaSiva > > put removeQuotes(cardOrStackObject) into pTrackdata["contentTarget"] > > if oStackName <> empty then # this is not the first run boot of portal > deleteAllMobileControls # will destroy all except audioPlayer > end if > > set the acceleratedRendering of stack oStackName to false > > if isMobile() then > go cardOrStackObject in stack oStackName > > else > > # desktop: does not work to go from portrait to landscape > # hence: > > close stack oStackName > go cardOrStackObject > > end if > > end portal_GoStack > > It appears that a simple hack would be > > if isMobile() then > go cardOrStackObject in stack oStackName > close stack oStackName > [snip] > > ... Which I tried... it works and does not affect performance. > > But the use case could be: > > > Put "wordpuzzles,journal,myTracking" into tNoCloseStacks > > if isMobile() then > go cardOrStackObject in stack oStackName > If oStackname notI(is among) items of tNoCloseStacks then > close stack oStackName > end if > [snip] > > My puzzle fanatic users will love that! Users as the "high end" - Level 4 > with 206-270 characters, (really hard!) means they can came back to it... > > but oops? On iOS, if leave the app, but don't close the app. And come back > to it, the puzzle reverts to the original, default save state. (no tiles, > waiting to choose "New Puzzle" > > :-( > > Aside: This means that there *is* a resume app message that is sent on > mobile! Jacque has asked about this in the past > > Now I don't know, it is a bug or not? I don’t see "this close the previous > stack" anyway in the "Go" entry of the dictionary > > " Use the go command to move to another
Re: Go in Window on Mobile / Not Obeying Purge?
On Android, if you leave the app, the OS will remove it from RAM if it needs the memory. It sounds like iOS is doing the same thing. Since SivaSiva is so big, memory may be tight enough to drop the puzzle stack when you come back to the app. It would depend on the RAM in the device. I don't know of any resume messages, though I wish we had them. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 2, 2019 7:43:20 AM Sannyasin Brahmanathaswami via use-livecode wrote: Good morning Richard "But just to clarify, the stack in question is a separate stack file, and not a substack of the one you're going to, yes?" @ Peter & Ralph "inspectors still open for closed stack" -- that would be only desktop. But this is on mobile. In a standalone. I am seeing runtime changes to the UI -- a puzzle game, you can leave it mid-way through the game, all the "tiles" left in a new location... go to another stack, go third stack, and back to the puzzle. Tiles are still where you left them So, we deem this a "bug"? But... could be a possible use case to leave it the way it is? Navigation is now using a "back" script call Lib_SivaSivaPortal.livecodescript Handler: portal_GoStack (trimmed version for this mail) command portal_GoStack cardOrStackObject put the short name of this stack into oStackName # cannot pass quotes to these strings or you will # break the JSON, BR added utilities section to lib_SivaSiva put removeQuotes(cardOrStackObject) into pTrackdata["contentTarget"] if oStackName <> empty then # this is not the first run boot of portal deleteAllMobileControls # will destroy all except audioPlayer end if set the acceleratedRendering of stack oStackName to false if isMobile() then go cardOrStackObject in stack oStackName else # desktop: does not work to go from portrait to landscape # hence: close stack oStackName go cardOrStackObject end if end portal_GoStack It appears that a simple hack would be if isMobile() then go cardOrStackObject in stack oStackName close stack oStackName [snip] ... Which I tried... it works and does not affect performance. But the use case could be: Put "wordpuzzles,journal,myTracking" into tNoCloseStacks if isMobile() then go cardOrStackObject in stack oStackName If oStackname notI(is among) items of tNoCloseStacks then close stack oStackName end if [snip] My puzzle fanatic users will love that! Users as the "high end" - Level 4 with 206-270 characters, (really hard!) means they can came back to it... but oops? On iOS, if leave the app, but don't close the app. And come back to it, the puzzle reverts to the original, default save state. (no tiles, waiting to choose "New Puzzle" :-( Aside: This means that there *is* a resume app message that is sent on mobile! Jacque has asked about this in the past Now I don't know, it is a bug or not? I don’t see "this close the previous stack" anyway in the "Go" entry of the dictionary " Use the go command to move to another card in the current stack, to open a stack and go to a card within it, or to move backward and forward among recently visited cards. If the stack is open, is closed but loaded into memory, or is listed in the current stack's stackFiles property, you can specify it simply by name:" BR ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Go in Window on Mobile / Not Obeying Purge?
Good morning Richard "But just to clarify, the stack in question is a separate stack file, and not a substack of the one you're going to, yes?" @ Peter & Ralph "inspectors still open for closed stack" -- that would be only desktop. But this is on mobile. In a standalone. I am seeing runtime changes to the UI -- a puzzle game, you can leave it mid-way through the game, all the "tiles" left in a new location... go to another stack, go third stack, and back to the puzzle. Tiles are still where you left them So, we deem this a "bug"? But... could be a possible use case to leave it the way it is? Navigation is now using a "back" script call Lib_SivaSivaPortal.livecodescript Handler: portal_GoStack (trimmed version for this mail) command portal_GoStack cardOrStackObject put the short name of this stack into oStackName # cannot pass quotes to these strings or you will # break the JSON, BR added utilities section to lib_SivaSiva put removeQuotes(cardOrStackObject) into pTrackdata["contentTarget"] if oStackName <> empty then # this is not the first run boot of portal deleteAllMobileControls # will destroy all except audioPlayer end if set the acceleratedRendering of stack oStackName to false if isMobile() then go cardOrStackObject in stack oStackName else # desktop: does not work to go from portrait to landscape # hence: close stack oStackName go cardOrStackObject end if end portal_GoStack It appears that a simple hack would be if isMobile() then go cardOrStackObject in stack oStackName close stack oStackName [snip] ... Which I tried... it works and does not affect performance. But the use case could be: Put "wordpuzzles,journal,myTracking" into tNoCloseStacks if isMobile() then go cardOrStackObject in stack oStackName If oStackname notI(is among) items of tNoCloseStacks then close stack oStackName end if [snip] My puzzle fanatic users will love that! Users as the "high end" - Level 4 with 206-270 characters, (really hard!) means they can came back to it... but oops? On iOS, if leave the app, but don't close the app. And come back to it, the puzzle reverts to the original, default save state. (no tiles, waiting to choose "New Puzzle" :-( Aside: This means that there *is* a resume app message that is sent on mobile! Jacque has asked about this in the past Now I don't know, it is a bug or not? I don’t see "this close the previous stack" anyway in the "Go" entry of the dictionary " Use the go command to move to another card in the current stack, to open a stack and go to a card within it, or to move backward and forward among recently visited cards. If the stack is open, is closed but loaded into memory, or is listed in the current stack's stackFiles property, you can specify it simply by name:" BR ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: Go in Window on Mobile / Not Obeying Purge?
That's one of my annoyances. Say you are inspecting a field and then delete the field the inspector does not close. One would think that if a control is deleted while an inspector for that object is open the inspector would close. This makes me wonder if the card retains some artifacts of the deleted field if it's deleted while the inspector is open? Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Peter Bogdanoff via use-livecode Sent: Friday, March 01, 2019 2:10 PM To: How to use LiveCode Cc: Peter Bogdanoff Subject: Re: Go in Window on Mobile / Not Obeying Purge? I’ve found that if an inspector is open for something in that stack, purging is incomplete. Peter > On Mar 1, 2019, at 7:37 AM, Richard Gaskin via use-livecode > wrote: > > Sannyasin Brahmanathaswami wrote: > > >... although all my modules/stacks have both "purge stack/window" set > >to true, I am seeing change on stacks that are "closed" when you > >reopen them again. > > > > Thus, it means that Purge stack/window is not implemented on > > > > Go [new-stack] in window of stack [old-stack] on mobile. > > > > Can anyone confirm? I wonder how long the RAM can keep up before it > > crashes. > > Personally that seems like a bug to me. Maybe worth reporting. The manner > in which a stack is closed shouldn't matter with regard to how destroyStack > works. > > But just to clarify, the stack in question is a separate stack file, and not > a substack of the one you're going to, yes? > > Remember that LC keeps the entire stack file in RAM, and can't purge it until > the mainstack and all substacks within the stack file are closed. > > If it is purgeable (as a separate stack file), my hunch is you won't ever see > a RAM issue from caching. If you do it would be a bug. Caching is intended > to speed up access, not to prevent ordinary behavior, so things not in use > are purged as RAM is needed (same with cached images and other things). > > If you're seeing slow or crashing behavior that seems like it might be > RAM-related, maybe Apple's Instruments tool in xCode can help provide clarity > on that: > https://apple.stackexchange.com/questions/71237/how-to-identify-cpu-an > d-memory-usage-per-process-on-iphone > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Go in Window on Mobile / Not Obeying Purge?
I’ve found that if an inspector is open for something in that stack, purging is incomplete. Peter > On Mar 1, 2019, at 7:37 AM, Richard Gaskin via use-livecode > wrote: > > Sannyasin Brahmanathaswami wrote: > > >... although all my modules/stacks have both "purge stack/window" set > > to true, I am seeing change on stacks that are "closed" when you > > reopen them again. > > > > Thus, it means that Purge stack/window is not implemented on > > > > Go [new-stack] in window of stack [old-stack] on mobile. > > > > Can anyone confirm? I wonder how long the RAM can keep up before it > > crashes. > > Personally that seems like a bug to me. Maybe worth reporting. The manner > in which a stack is closed shouldn't matter with regard to how destroyStack > works. > > But just to clarify, the stack in question is a separate stack file, and not > a substack of the one you're going to, yes? > > Remember that LC keeps the entire stack file in RAM, and can't purge it until > the mainstack and all substacks within the stack file are closed. > > If it is purgeable (as a separate stack file), my hunch is you won't ever see > a RAM issue from caching. If you do it would be a bug. Caching is intended > to speed up access, not to prevent ordinary behavior, so things not in use > are purged as RAM is needed (same with cached images and other things). > > If you're seeing slow or crashing behavior that seems like it might be > RAM-related, maybe Apple's Instruments tool in xCode can help provide clarity > on that: > https://apple.stackexchange.com/questions/71237/how-to-identify-cpu-and-memory-usage-per-process-on-iphone > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Go in Window on Mobile / Not Obeying Purge?
Sannyasin Brahmanathaswami wrote: >... although all my modules/stacks have both "purge stack/window" set > to true, I am seeing change on stacks that are "closed" when you > reopen them again. > > Thus, it means that Purge stack/window is not implemented on > > Go [new-stack] in window of stack [old-stack] on mobile. > > Can anyone confirm? I wonder how long the RAM can keep up before it > crashes. Personally that seems like a bug to me. Maybe worth reporting. The manner in which a stack is closed shouldn't matter with regard to how destroyStack works. But just to clarify, the stack in question is a separate stack file, and not a substack of the one you're going to, yes? Remember that LC keeps the entire stack file in RAM, and can't purge it until the mainstack and all substacks within the stack file are closed. If it is purgeable (as a separate stack file), my hunch is you won't ever see a RAM issue from caching. If you do it would be a bug. Caching is intended to speed up access, not to prevent ordinary behavior, so things not in use are purged as RAM is needed (same with cached images and other things). If you're seeing slow or crashing behavior that seems like it might be RAM-related, maybe Apple's Instruments tool in xCode can help provide clarity on that: https://apple.stackexchange.com/questions/71237/how-to-identify-cpu-and-memory-usage-per-process-on-iphone -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Go in Window on Mobile / Not Obeying Purge?
Good news! Go [new-stack] in window of stack [old-stack] Is working on mobile! I was revamping the navigation of SivaSiva, and thought I would try it. (did not work on a few version ago). Now works great. Even moving from portrait to landscope, as a long you have to mobileSetFullScreenRectForOrientations "landscape left,landscape right","0,0,667,375" set right. BUT... although all my modules/stacks have both "purge stack/window" set to true, I am seeing change on stacks that are "closed" when you reopen them again. Thus, it means that Purge stack/window is not implemented on Go [new-stack] in window of stack [old-stack] on mobile. Can anyone confirm? I wonder how long the RAM can keep up before it crashes. BR ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
