Forum Discussion
Storyline 3 Crashes on iPad Safari and Chrome
Hi Justin,
Thank you for the excellent write-up about the problem. I've been developing for years and understand the struggles of memory management and garbage collection.
Could the solution be as simple as only keeping a predefined number of pages in memory?
For example, let's assume you keep the preloading functionality for the next 3 pages. Each time a file is loaded into memory, you store the page_id in an array. Then, if that array is ever going to be larger than the limit, it will unload the items that have less chance of being navigated to.
It would prioritize pages that have direct navigation tied to them (such as the next page, the previous page, and any pages that can be navigated directly to from this page via triggers).
Sample
Let's say you are on Page D and the limit of the number of loaded pages is set to 6. Before removing any items, the array would look something like like this:
['A', 'B', 'C', 'D', 'E', 'F', 'G'].
Then, it would check the following logic:
- Page D would never be removed, since it's the current page.
- Pages E and C would have the highest priority to persist, since they are directly next to Page D.
- It would then check to see if Page D there are any active triggers that could navigate you to another page (such as a menu button, or if Page D was a sub-menu). It would prioritize these next.
- Then, it would move on and prioritize Page F, then Page G, in that order.
- Lastly, it would prioritize Page B, then Page A.
In our example, it would mark Page A for removal.
Page A would then be removed from the array, released from memory, and all references deleted so that it COULD be picked up by garbage collection.
This would probably need to happen BEFORE you started loading new content, so that GC could actually have a chance to delete the old content from memory.
Also, there could be other parameters tied to this logic, such as purposely removing items from memory that take up too much memory after they have been viewed.
--------------------------------
From my understanding, the worst case scenario is that the user attempts to go to a page that wasn't pre-loaded. If this happens, the course pauses and shows the loading animation while it finishes loading the page. Not that bad, considering the alternative.
I hope this made sense and hope it helps!
Thanks for the input, Adam. We'll continue to preload as much as we can whenever possible, but sometimes even 2 content-heavy slides are too much for Mobile Safari. It's a balance for sure!