It seems to me that the system takes a different screen capture that the one my app takes on applicationWillResignActive.
To my surprise there is a delay of about 0.6 secs between the image taken by the system (b) and the image taken by the game (d). It kind of makes sence if the system needs to take the screen capture before applicationWillResignActive, but for a game with fast moving objects this can be easily noticed by the player.
How can I workaround this?
The following are the steps the player makes and how it causes such discrepancy:
(a) The player pulses the home button when she is playing. (b) The system screen capture is taken. (c) The player taps the game icon. (d) The game is launched with the screen capture taken on applicationWillResignActive. (e) The game is paused showing the discrepancy in a fast moving object.
I believe this is because your game rendering is not on main thread(certainly it shouldn't be on main thread), so when applicationDidEnterBackground/applicationWillResignActive is returned, the system takes a screen shot from video card's buffer immediately.
At this time, your game loop thread is still running, so it may update some frames before it is paused.
I don't know how you implement your game loop, but you can try this:
In applicationDidEnterBackground/applicationWillResignActive, put a global semaphore(dispatch_semaphore_t) and block the main thread, in your game loop, observe the semaphore and if it exist, pause your game loop, then signal the semaphore.
This will assure that the screen shot is taken after your game is paused.
Also notice that after applicationWillResignActive, the system will take the snapshot for task switcher, and after applicationDidEnterBackground, the system will take snapshot for next time you app enter foreground.
Hope this will help you.
Related
How could I continue to play media even with screen lock?
The player has a progress bar that shows how far the current music has been played and there is a list of songs to be played.
When screen is locked, the player stops after about 1 minute and resumed when screen is unlocked.
Some suggestions were to use Services but from my understanding, to communicate with the progress bar, objects are to be serialized and used as input variables of an intent putExtra in the startService(new Intent(this, MyMediaPlayerClass.class));
What other approaches could I try?
Building an audio streaming app using just_audio and audio_service. It uses an HLS url stream to get the audio. When audio is playing and the device is locked the controls will show on the lock screen and work properly using play/pause. However if the audio is paused for around a minute or longer the play button is tapped the lock screen controls will turn grey. I'll then open the app and try tapping play in the view and the Audio processing state will change to idle and nothing else happens.
I'm wonder if it has to do with the HLS stream at all. The amount of time that the player has to be paused before it "breaks" varies, but does seem to be consistent with the amount of audio that has buffered. So play/pause works fine if the amount of time the audio has been paused is less than the buffered amount, but if it passes then I encounter this issue.
As far as I can tell, nothing useful is logged at the time the audio player stops working, nor when tapping play/pause while in this state. I've tried to see if the OS kills the audio player maybe so I could re-init, but that doesn't seem to be the case either.
Figured this out, however, I'm not sure it's best solution.
One part is the provider for our HLS url for the live stream was able to increase the session timeout from 45 seconds to 5 minutes. There doesn't seem to be any negative behavior in doing this. It somehow prevents the background controls from breaking (greying out) when the audio has been paused for more then a minute (this varies and doesn't seem directly related to the session timeout, so maybe some magic iOS is doing too, who knows).
The other part is when a user locks their device and interacts with the background player something breaks to the point where if they go back into the app and try to switch the audio source something fails deep in the audio player. To "fix" this, when switching from the live stream to a non-HLS url I am now calling dispose on the audio player in the handler then re-initializing it.
This has solved my problem, but I think a better solution exists. For my specific case, using the SwitchAudioHandler may be that better solution, but I haven't had the time to try it.
I'm building a Windows Store app and it pops up toast notifications from time to time. I also have an animation that plays to show when something has updated. Both of these happen at the same time.
What I would like is to not show the toast when the app is running.
So, is there a nice easy way to determine this or do I have to manually track the state via the suspending/resuming events?
Edited info:
The solution has a background task project which goes off, gets the data, then decides if anything has changed that the user needs to know about.
If so, it creates a toast, updates the tile badge, and plays an animation to fade in the new data.
The issue is that I don't want to show the toast and update the tile badge if the user has the app full screen. Similarly, playing the animation isn't needed until the app is resumed (that's the easy part though).
I realize I could solve it by having one timer that works when the app is running, and a separate background task for when it's suspended but that seems like overkill in this case.
The simple answer here is that if your app is suspended, your code won't be running.
If you want to pop up toasts when your app is suspended, you'll either need to use the WPNS or a background task to track changes.
I'm working on an alarm clock application for iOS 4.x. The other alarm clock applications that I've seen are able to present the user with something other than a local notification (i.e., a custom view) and are able to play a sound file. I've been looking into how that's done and have only found this solution:
Play sound with screen turned off / don't let iPhone go to sleep
Is there another approach or is this the best practice?
When your app is not visible, you can't display anything. The silent sound workaround is a cool trick but when a user presses your home button, your app is not visible (and might get destroyed under certain conditions) -> therefore you can't display anything.
So if you tell your user to use your alarm clock by firing it up and then press the sleep button it will work - you can display anything on your screen after the user unlocks the iphone again.
Needless to say that playing sound (even silent sound files) drains the battery so your user might be disappointed if he's not woken up because his iphone has run out of battery.
And yes, there is best practice: Local Notifications! Beginning with iOS 5 it will display your apps icon next to the notification...
I have a application that runs on touch enabled device with WinCE 3.5 OS. I have a show player control to display adds when the system is left idle for some configured amount of time..
So the DirectShowPlayerControl will be iniated every time the show player is launched and will be destroyed when it is closed...
The player for the first time plays videos continuously for any amount of time. Once the player is destroyed and recreated the video are changing but the display goes black and in between if some small video is placed that alone is displayed.
Whenever the form is closed am calling DirectShowPlayerControl.Dispose() method.