I'm quite new into flutter and coding in general. I'm trying to build a meditation app, that plays a bell every 30/60/120... seconds, depends on user input. My code works perfectly fine on Android device, but when running on iOS, it plays bell only once and doesn't play anymore. Any suggestions please? Thank you!
if (((widget.meditation.notification) != 0) &&
((_time % widget.meditation.notification) == 0)) {
print('notification $_time');
audioCache.play('audio/bell.wav');
}
Finally I found solution, simply everytime .release() must be called.
By default, the player will be release once the playback is finished or the stop method is called.
This is because on Android, a MediaPlayer instance can be quite resource-heavy, and keep it unreleased would cause performance issues if you play lots of different audios.
On iOS and macOS this doesn't apply, so release does nothing.
Related
A try to start a screen recording with RPScreenRecorder. I got the following error:
Recording interrupted by multitasking and content resizing
func startRecording() {
let recorder = RPScreenRecorder.shared()
recorder.startRecording(handler: { (error) in
if let unwrappedError = error {
print(unwrappedError.localizedDescription)
} else {
}
})
}
Before iOS 12.0 everything worked fine. From the update I get the error above.
My app has been rejected from App store for the same reason. So far the only workaround is to reboot the device.
I had a similar problem and here is how I solved it.
go to project then targets then capability switch on Background mode then enable audio and VOIP. It should work
I've done a lot of research on the errors and posted the solution Here.
For now my screen recording feature is bug free. But who knows what comes with the new OS updates
We've been rejected same issue several times.
But we found a senario to re-produce as bellow,
We reported it on Resolution Center in App Store Connect, then passed.
connect iOS(12.4) device to host launched XCode 10.3
(regardless of opened related project)
cold boot iOS device.
launch app and start recording video ASAP(until 30sec after booted)
Now iOS13, we don't face this error at the above senario.
So I decided to finally put Unity Ads on my Android game. I tried to build it on Windows platform and found no problem (FPS is fine)
But when I rebuilt it for Android, my FPS scaled down to 30+, what just happened?
I didn't put anything but integrating the Unity Ads so this time I just comment out the Ads that initializes the ads.
void InitializeAds(){
StartCoroutine(ShowAdWhenReady());
}
IEnumerator ShowAdWhenReady(){
while(!Advertisement.IsReady()){
yield return null;
}
Advertisement.Show();
}
In hopes that the FPS will go back to normal. But heck when I recompiled the APK and installed it on my phone the FPS still around 30+ FPS :/
Any help regarding this? I'm certain my game has good frame rate before I put the ads so I know there must be some kind of bugs on the plugin.
By the way, I invoked the InitializedAds on the Start method.
Thanks!
UPDATE:
I installed Unity Remote from Google Play to see if it's also going to have same low FPS but its NORMAL. So I recompiled the current Unity project, installed on my phone, FPS still SUCKS. This is so straaange T.T
Please try this for making FPS higher in your game,
Application.targetFrameRate = 60;
I guess, your problem will solved using this line.
Having a weird problem with my app.
Trying to play a video in a loop (see the code below). VideoPlayer repeatMode is set to Ti.Media.VIDEO_REPEAT_MODE_ONE.
Works in simulator, works on iPhone 4s, works on iPad Air... does not work on iPhone 4 (all of them running iOS 7.1.1 apart from simulator - 7.1).
Exact symptoms: after one play, video should restart from beginning, but it stops. If controls are available, I can press play to start playing it again, then after reaching the end it stops again.
I could swear that it worked on iPhone 4 before the 7.1 upgrade, but somehow it stopped.
Anyone could replicate this issue? Or have any idea?
Sys info:
Titanium SDK: Tested with 3.2.3.GA; 3.2.2.GA; 3.2.1.GA; 3.2.0.GA
Platform & version: iOS 7.1.1 (11D201)
Device: works on iPhone 4s, iPad Air, simulator; fails on iPhone 4
Host Operating System: OSX 10.9.2
Titanium Studio: 3.2.3.201404181442
Xcode: 5.1.1 (5B1008)
Alloy: 1.3.1
Code for basic Alloy project to replicate:
index.js
var videoPlayer = Titanium.Media.createVideoPlayer({
autoplay : true,
fullscreen : false,
mediaControlStyle : Titanium.Media.VIDEO_CONTROL_DEFAULT,
repeatMode: Ti.Media.VIDEO_REPEAT_MODE_ONE,
scalingMode : Titanium.Media.VIDEO_SCALING_ASPECT_FIT
});
//Video is 12s long so it is easy to notice that it does not loop.
videoPlayer.url = "video/candles.mp4";
$.index.add(videoPlayer);
$.index.open();
index.xml
<Alloy>
<Window class="container">
</Window>
</Alloy>
I would appreciate any suggestions.
I have done some research and played around with the Titanium.Media.VideoPlayer and managed to work around the issue. Below you can find the solution in case anyone else encounter this problem.
First of all, some info on the problem.
I have found some forum boards where developers were having very similar problem with MPMoviePlayerController on iPad 1st gen. Looped video was less or more randomly freezing on loop. So I think there is a problem with the Apple video player on some devices, and not necessary with Titanium implementation.
My first approach was to try replay video on complete event that is fired when video stops playing, instead of using repeatMode.
So far so good. It worked on the first time, yay! But the happiness was rather short. During an hour of test of videoPlayer.play() on event complete, the video sometimes was repeating 10-30 times fine and then suddenly was freezing. What gives? Turns out the video player had some sort of a hiccup.
Normal sequence of events was as follows:
video ends, playbackstate changes to 2,
complete event is fired
I restart video on complete
playbackstate changes to 1, video is playing until the end.
For a mysterious reason once in a while this sequence got additional something happening:
video reaches the end - playbackstate changes to 2,
complete event is fired.
video gets restarted on complete
playbackstate changes to 1, video starts playing
suddenly playbackstate changes to 1, video stops, without firing complete event.
Solution
So, knowing all this, I have set up listeners to listen to playbackstate instead of complete and when I hear playbackstate: 1 then I restart video and tadaaa! Everything works!.
Caveat: not 'everything' unfortunately. I am using custom video controls, so I have lost pause, and stop ability (every time video playback state changes to 'stopped' I restart it forcefully). To make it work I have to remember to remove listener every time I press 'pause/stop' buttons and then reattach it afterwards.
Hope that helps someone.
I have a bad performance problem with OpenAL in my iPhone game. My game runs smoothly with 60fps but when I initialize OpenAL the game begins to jerk. This is my initialisation code:
ALCdevice* device = alcOpenDevice(NULL);
ALCcontext *context;
if(device) {
context = alcCreateContext(device, NULL);
alcMakeContextCurrent(context);
}
I don't create any OpenAL Sources nor load/play any sounds. The jittering (the game jerks all the time) is caused by the initializing of OpenAL.
The XCode instruments are saying that the game runs with stable 60fps yet it's obviously jittering (when I don't run the code above the game runs smoothly).
This also doesn't happen on an old iPod Touch 2G with iOS 3.1.3. On all my other devices with iOS 4 the jittering happens, which is also crazy.
I also tried to put the OpenAL stuff in a separate thread but it doesn't help.
Has anybody noticed a similar behaviour?
Try calling alcGetError() after context set up to ensure it succeeded.
Is this failing on the simulator or on an actual phone?
Are you doing anything with sound after the code you posted? In the code you posted if alcOpenDevice fails then you won't have a context, yet you don't return either.
I have used:
[UIApplication sharedApplication].idleTimerDisabled = YES;
in a number of Apps developed and running under iPhone OS 2.x and never had any problems with it. They were clock apps so needed to run constantly and ignore the iPhone's idle Timer setting.
However, trying to achieve the same with a new App running OS 3.0 (and which needs to be deployed under 3.0 as it uses some 3.0 APIs) I've found the idle Timer to be either ignored or inconsistent.
My App plays music from the iPod library and when the music is playing it auto-locks regardless of the above setting. But once you unlock it, it then doesn't auto-lock again unless you play music again, in which case it locks again after the iPhone auto-lock time setting.
I'm amazed no-one else has come across this as I imagine it would affect a large number of Apps.
Just to clarify:
1. The above code is in ApplicationDidFinishLaunching
2. I know that the phone won't auto-lock when testing from xCode regardless of settings
If anyone has any thoughts I'd be very grateful...
Our app uses the MPMediaPLayer. We also had the idleTimerDisabled=YES code in the ApplicationFinishedLaunching, which works EXCEPT if untethered, and there is already a current nowPlayingItem which is left playing (or unpaused, if paused at app startup). Obviously this is all with the Settings -> General -> Autolock set to some timed value.
By adding idleTimerDisabled=NO, immedately followed by idleTimerDisabled=YES in one of the other bits of code AFTER we had figured out what bit of music we would get playing seemed to solve the problem. Just setting it to YES was insufficient.. and subsequent queries had always indicated the correct value (YES).. so it appears the Apple code ignores the setting of the value IF there is a current piece of music and that is not changed by your code.. but does notice a change of value.
This is all under iOS 3.0.
Even in 2015, using iOS 8.2, this bug is still alive and kicking.
Here's my solution, using XCode 6.2.
iPhone - phone goes to sleep even if idleTimerDisabled is YES
Basically, even now, in 2015, the only way to safely make sure that the device doesn't go to sleep is to repeatedly call a piece of code to keep the device awake.
-(void)callEveryTwentySeconds
{
// DON'T let the device go to sleep during our sync
[[UIApplication sharedApplication] setIdleTimerDisabled:NO];
[[UIApplication sharedApplication] setIdleTimerDisabled:YES];
}
Sounds like a bug, file with Radar - I am not too surprised this has not been seen much as there are probably not a lot of apps that try to lock the screen open and play music.
Having same issue. It does work when the device is plugged in. You can press lock button on top, and my NSTimer fires later and causes a vibrate. However if the device is not plugged in pressing the lock button puts the device to sleep. Any solution would be greatly appreciated.
iCodeblog posted about the idletimer, I said it didn't work, and the person who develops 'cute clock' was nice enough to reply. You have to do a hack, play a 1 second or longer silent sound every 10 or so seconds with NSTimer. This keeps the device awake even if the user hits the lock button.
I develop Seconds - Interval Timer for iPhone and iPod touch and I've had no end of trouble with this. The idea of my app is that people create timers based on a number of intervals where each interval can have it's own playlist or track played.
In iOS3 I had the problem that I couldn't disable the idle timer by just setting idleTimerDisabled = YES. In the end I came up with the same solution as Neil whereby I would periodically set it to NO, then immediately to YES again. This seemed to work.
I'm now updating the app to iOS4 (I know, iOS5 is just around the corner...) and now I have the opposite problem. If the MPMediaPlayer changes track before the idle timer reaches it's limit it gets reset. I've just tested this by creating an interval in my app that was 55 seconds, my auto-lock was set to a minute. At 50 seconds the screen dimmed as it prepared to lock, but at 55 seconds when the music changed it went back to full brightness and then didn't lock as it should.
Overall, the implementation of this seems flakey at best.