I have a play, stop and mute button on a scene (that will be a page in iBooks) which can be pushed to play stop or mute animation along with an audio.
If I push the play a couple of times in a row, then iBooks will crash trying to run it or when I turn the page to another animation the iBooks “might” crash - random crashes depending on how many times you click on the buttons…
My question with very limited Javascript knowledge… can I disable some of these buttons for a duration of the time when one of these buttons is pressed?
Also, I am doing “pause timeline” when someone pushes the “stop” button. Is it OK to “start timeline” when they push the “play” button and pause it when the push the “stop” button? I was thinking this could be the reason for crashes in iBooks?
I'd be curious to see a zip of your .hype document; crashing is abnormal and that is probably what should be addressed more than workarounds. Most of the time crashing happens when excessive memory is being used; while this isn't typically the case from animations, it could be depending on the audio usage. (and are you using a compressed file format like mp3 or m4a?).
As for disabling certain buttons, this could be done in JavaScript by keeping track of state. You can see a basic example here:
You could also potentially disable buttons by using the visible property to hide a button, and then potentially show a dummy one in its place.
Are you running the widgets on the page, or only when users go into them? That is a lot for a book (1 MB GIFs tend to require a lot of memory and that adds up), but I’d think if any individual ones were only in the 5-8 MB range you’d be okay. However if you’re showing the animations on page, perhaps iBooks isn’t cleaning up enough. If you were to cut your book in half or a quarter (to reduce total widgets, but not an individual widget size) does that improve the matter?
I'm a little unclear of what you mean by anchor and the context (if it is within a widget or within the iBooks author page). Feel free to provide an annotated screenshot along with documents if you'd like and I might be able to better see, though this might not be a Hype-specific issue.
Sorry, but we don’t do phone support; it typically isn’t a good way to communicate technical issues. If your content is sensitive, you can send it to support@tumult.com. It is very useful if you could send annotated screenshots, video, and zips of the .hype document. This way we can be on the same page about the issue. Thanks!
Hype may not be the reason for the issue. Asking to see a project is standard (at least on this Forum) because there often are variables that are not apparent to the individual posing the question, especially when that individual is new to Hype.
I did an Internet search for "memory leaks iBooks" and got quite a few hits; below is a quote from one of the posts on an Apple discussion board (i.e. one of the search hits).
iBooks constantly runs out of memory
I'm creating an iBook with HTML widgets that contain some .mp4 videos.
The iBook has several of these widgets. If a user is reading the book, iBooks usually crashes with a low memory error before they can even get to the 3rd one. This is extremely annoying.
Why does this happen? It seems to me that, when someone loads a widget and then closes it, the widget still remains in memory (since, if you reopen the widget, it's in the state that you left it in). This seems like a pretty huge memory leak.
Is there any way to force iBooks to free that memory when a user closes the widget? I'm OK with clearing the state of the widget when they close it. These low memory issues are starting to get ridiculous.
I think you'll find that mashing on play or pause buttons for audio with even hand-coded audio will crash iBooks. I've been troubleshooting iBooks widgets for years now and audio remains one of the most finicky and troublesome issues in iBooks. Apple has a challenge where they need to make sure that the full spectrum of web technologies are supported within the widget area, while at the same time making sure that there is enough memory left over for the actual book itself which is running underneath the widget when a widget is opened.
Apple has both a timer and a likely protection mechanism that flushes widgets from memory if they continue to run in the back ground. This is not something we have any transparency over -- we can't ask Apple 'why did you close the widget?' or 'what is the memory limit for a widget?'
It's simply not information that provide in any of their developer documentation.
If you disregard all of these reasons, the real thing you should know about Hype and these forums is that you'll get much more accurate help if you can share your Hype document, and even more help if you approach issues with patience and the members of this forum with kindness.
No -- Hype handles the generation of the Default.png and we also have code in place to reduce any white flashes. I have a lot of documentation on iBooks here, with much ink spilt related to bugs and how to overcome them
Sorry, yes I had those issues, but had changed them between the time I was panicking and the time I started retyping them. It was that smart Quote (which I know how I got it, copy and paste from the book).
Now I go and learn javaScript so I can stop the crashes, maybe.