I'm having an issue where my flash project crashes during 'Crazy kid Testing' - Where we click the same button several times and then do the same on another button. If the same button is clicked repeatedly, 10-12 times, Flash Player (SWF) crashes.
Is there any method to automatically reload the page when flash crashes WITHOUT user input? This will be used on a Kiosk in Firefox (latest).
Vesper had the right idea when it comes to both using ExternalInterface and probing for memory leaks and resolving those leaks.
You should debug your Flash app for memory leaks first, because Flash
crashing is not a sign of good application. And if Flash would still
crash after all memory leaks eliminated, you should reduce the memory
footprint of your app. Anything beyond, and only a watchdog could save
you. – Vesper Jun 6 at 18:20
Related
I am developing a 2d game using LibGdx framework , when i press HOME button and then resume the game it freezes for 3-4 secs as the textures are being reloaded . I have used AssetManager to load the TextureAtlas & then getting the images by findRegion . I referred to documentation for "Texture" (http://libgdx.badlogicgames.com/nightlies/docs/api/com/badlogic/gdx/graphics/Texture.html) and it mentions that " If the OpenGL context is lost all managed textures get invalidated. This happens when a user switches to another application or receives an incoming call. Managed textures get reloaded automatically.". I am confused what to avoid this delay !!
Kindly Help
Thanks
There will always be a delay on resuming the game.
This is because on android if you press home button or switch to another app a so called context loss occures.
When a context loss occurs on Android, it means that the operating system has decided to forcefully free the memory that was occupied with your loaded assets.
When you switch back to the game you need to reload these assets again to prevent the game from crashing and this reloading is reason for the delay.
I'm working on an app using SharpDX to render DirectX content to a DrawingSurfaceBackgroundGrid in Windows Phone 8.
I've found that, if the app goes out to the photo picker or suspends/resumes through Fast Application Resume, memory utilization will increase by about ~2mb and prior resources will not be reclaimed. This means a DirectX-based app using DrawingSurfaceBackgroundGrid will eventually run out of memory on user-initiated actions.
The leak starts once DrawingSurfaceBackgroundGrid.SetBackgroundContentProvider is invoked with a SurfaceBackgroundContentProvider. I'm using a DrawingSurfaceBackgroundContentProviderNativeBase implementation that has empty method bodies for all abstract members.
An isolated repro can be found here. Repro steps are: build and run the app, click "choose photo", hit the hardware back button, observe memory spike.
Anyone else seeing similar?
This was a bug in SharpDX, which has been resolved in this commit.
In WP8, if we set
ApplicationIdleDetectionMode = IdleDetectionMode.Disabled
the app continues to run even when the screen is locked.
If, for instance, we have a WebBrowser in an app (which is actually active only when the app is in the foreground), and the above property is set as disabled:
Will the WebBrowser continue its execution even when the screen is locked (for example, playing an audio file).
Will the WebBrowser continue its execution even when the app is switched to the background.
Thanks.
As for running under lock screen - yes it should run, you can get more information from MSDN.
As I have tested once, WebBrowser is using BackgroundAudio to play (audio element), so it should also play under lock screen and probably in background (thought you should test it).
When the App goes to dormant state - all its processes are stopped MSDN:
When the user navigates forward, away from an app, after the Deactivated event is raised, the operating system will attempt to put the app into a dormant state. In this state, all of the application’s threads are stopped and no processing takes place, but the application remains intact in memory.
You should also watch out for Certification requirements, when usind AppIdleDetection - point 6.3 – Apps running under a locked screen.
My app is like a tweet feed reader. But with use, the app's responsiveness slows down in the wp8 emulator. By being unresponsive, I mean the progress bar indicator speed slows down, no links respond, none of the app buttons respond and the app suddenly closes.
I think it is a memory issue with the emulator. Am I right? I can't test it as I don't have a device yet.
Even on increasing the memory using the Hyper-V settings I didn't observe much difference.
I have an in-app browser which works fine for the first 2-3 links but then makes the app hang!
This doesn't sound like a memory leak. What you're describing is a slow-down which is caused by putting too much work on the UI thread. Overall you should offload as much work as possible to a background thread or the compositor thread.
The app suddenly closes sounds like some unhandled exception, but it's hard to tell which one. You said the app works fine on WP7. Have you looked at known app compatability issues that occur once WP7 apps are upgraded to WP8? Check it out on MSDN # http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206947(v=vs.105).aspx
This really isn't enough to go on. Is there something printed out in the output window once the app crashes? Can you tell what's the last managed method to be invoked before the app crashes? Can you try profiling the app for CPU and see what's the method that's most invoked? And profile for memory usage and see how's memory consumption right before the crash?
I'm building an Adobe Air 2.5. desktop application with Flash CS 5. The apps filesize is 10 MB with a medium amount of movieclips, vector graphics, bitmaps and code in it. It takes around 8 seconds from clicking the desktop icon until the app is available to work with.
How to improve the startup time?
Thanks. Uli
I think that you can decrease load time by placing on stage strictly what you need to show when the app starts.You can draw the rest of the assets upon request, dynamically.
So don't just drag everything on-stage.Instead, instantiate and addChild() as needed.
Depending on the asset size, it might take a little time to load, but cetainly the user won't have to wait 10 seconds before he/she can use your app.
Maybe not all of your app's content will be viewed in every single session, so why put everything on stage from the beggining?