When I call the first time UIActivityViewController, the interaction is locked. After the first click it will be normal without locking interaction, does anyone know how to not catch the first time?
Maybe this can help. I had a similar issue, UIActivityViewController was pretty slow to appear the first time.
I solved it removing AirDrop from the supported activity types (through excludedActivityTypes) and it became super fast.
So if you are not interested in AirDrop (my case) you can do something like this:
if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber_iOS_6_1) {
activityVC.excludedActivityTypes = #[UIActivityTypeAirDrop];
}
Note that UIActivityTypeAirDrop is only available starting from iOS 7.0.
I don't really understand the problem - you alloc/init a UIActivityViewController and then you present it with presentViewController:animated:completion, correct? Make sure to call the presentViewController... on the main thread. Sometimes UI stuff called on the wrong thread takes seconds to get executed. But it might also just be iOS - UIActivityViewController takes some time to check for available services and stuff, that might be the thing that's slowing it down too.
Related
I'm getting a "Slow defaults access for key ClientState took 0.034635 seconds, tolerance is 0.020000" warning when testing my iOS app - it seems to occur intermittently. I've tried to look around to see what it is about, but I'm not entirely sure! Any help appreciated, thanks.
My best guess is that the first Viewcontroller is taking to long to load.
I never got this message until adding a large background png to the first view controller which now exhibits the same behaviour but all the time. Take out the png and I did not get it on 5 loads.
Guessing same as depicus: first viewController loads too long.
In my case app starts by populating tableView from last saved CoreData. Right after that server tells me authorization has expired, I start re-auth and facebook login view comes on-screen - on top of tableView.
This is were I get that error. Without facebook login, everything is ok == fast enough.
SMSidat - I had the same problem and was looking found forever. I have an sqlite database and upon loading the vc that accessed the database it stated "slow defaults .....clientState took to long to load and all.
Try to remove Auto Layout from your nibs. Once I did that, no more "slow defaults...warning"!! Even though this is from 3 years ago...Hope it can help someone out.
Here is a link to the tread that helped me out
Slow UIViewController load time (slow ClientState warning)
In my experience this is cause by the time it takes to load a view when you invoke it. Take my case for example. I had a TabBar app and in one of my tabs it was a gallery. I was calling the view but within the view I was fetching everything on the main thread (big no no)... obviously, User interaction was gone out the window and the app will lock until done. The phone will take its time to load the images and to present the view. Once I multi-threaded my application and the pictures loaded in the background no more warning. Hope that helps, I am not sure how this warning works underneath but that changing this things got rid of it. :)
I have an app where I have 5 sets of animations that I'm storing in an array. The animations get picked to play randomly after a button touch. This is all working perfectly, however I noticed a bug when I quit the app and reopen immediately, I'll see my main view, then it'll jump to my second view that has the animation in it. (This shouldn't happen since you have to tap the main view in order for it to modally swap in the second view. If I interact with it everything works for a few seconds, then it closes with no crash log.
I finally realized that some of the objects must not be getting released fast enough, since if I close the app and wait three seconds, then reopen, everything executes fine.
I didn't want to put down code to show as this is more of a brainstorming question. I'd love any insight that could point me the right way. I changed a lot of my code to get rid of convenience methods and have all my variables defined and then released in my dealloc.
Is there a way to truly tell the app to kill everything on quit? It's not set to run in the background so this is a bit odd. Thanks for your help I'm still new to this and learning!
Alright, after working on this all weekend and doing more research comparing a barebones version of my app to my prerelease version, I traced memory leaks to the Flurry Analytics api that I am using. Apparently I was suffering from the same issue as the post here: App hangs on restart with latest Flurry SDK and ios4 . I resolved this by setting these optional methods to false, since they take extra time to send data after the app terminates, and depending on the connection it takes a few seconds.
FlurryAnalytics.h
/*
optional session settings that can be changed after start session
*/
+ (void)setSessionReportsOnCloseEnabled:(BOOL)sendSessionReportsOnClose; // default is YES
+ (void)setSessionReportsOnPauseEnabled:(BOOL)setSessionReportsOnPauseEnabled; // default is YES
Hope this helps anyone else who experienced something similar to me!
All apps can enter the background by default. Normally they do not do anything there, but they stay there in a frozen state and when you open them again, your program does not restart, it just picks up where it left off.
Anything that's set as an animation delegate might not get released, since it's retained for that purpose until the animation completes.
You can add an applicationDidEnterBackground: method to your app delegate to get informed when your app is going into the background, but exactly what you need to do depends on the design of your app. You can also add applicationWillEnterForeground: to do anything you need to do differently when restarting, as opposed to newly starting.
You might be able to force your animations to complete by starting a new animation with duration 0.0 (or very short if for some reason you can't do that).
If this happens only if your app goes to bkgnd and comes back AND you don't mind if the app restarts everytime it comes back then just put UIApplicationExitsOnSuspend in your app's plist. In all my cases where these and other bad things happen with apps going to and returning from bkgnd this helped.
While you might still see the app on the buttom when double tapping it is really stopped and will restart. Apps that show on the buttom do not always have to run or be stored in the bkgnd I learned.
ps. don't forget to set the value of UIApplicationExitsOnSuspend to YES
I have two things concerning AudioStreamer and i hope I'm getting some clues here:
1. I have set up a UITabBarController and in my Appdelegate is a AudioStreamer-Object. Two views refer to the appDelegate.streamer. It it looks like that im getting two sessions when i release and alloc it new. I get two running audiosession.
2. I use a UITableView to play out of this list. in the didSelectRowAtIndexPath-method I initialize with a URL. when the user taps with a fast double, or tripple-click. the audiosession will get startet three times. although i'm using a bool to prevent that. so my dirty solution is to set the system sleeping for a second. it is ugly because the screen freezes for a sec.
Thankfull for some hints
Simon
In terms of your problems, it sounds like you should implement your AudioSteamer as a singleton, as this will prevent multiple instances from being created and provide a single point to control playback (i.e.: prevent multiple taps from triggering multiple playbacks).
For more information on how to create a singleton class, see the "Creating a Singleton Instance" section within Apple's Cocoa Fundamentals Guide.
for 2nd point. It is a bug of AudioStreamer class. Also this has been solved and code is put up on gitHub see link. also if this does not seems working then you can go to the pause method and add more states as below
-(void)pause
{
if (state==AS_PLAYING || state==AS_BUFFERING || state==AS_WAITING_FOR_DATA)
{
//rest code goes same....
}
// rest code goes same....
}
this solved my same problem. Hope this will help you also...
Im trying to find the best way to avoid having tiny UI lockups after certain events in my app. For example here are two cases where i have come across mini-lockups:
I have a button that when pressed loads a local mp3 file (around 20-30mb) using AVAudioPlayer, calls the prepareToPlay method and then plays the audio file. The issue is that the button has the showsTouchWhenHighlighted flag set to yes and after pressing it it stays highlighted until the audio file begins playing which could take 1-3 secs.
Another similar example is using a navbar button to sort and reload the table data. There is a very short but noticeable lockup where the button remains highlighted until the table has reloaded.
Can anyone suggest a good approach to minimizing/eliminating these mini lockups? I didnt really come across any code to achieve this in any of the books/tutorials i read that dealt with tableviews and avaudioplayer. Should i be launching these actions on different threads?
thx
For number 1, your best bet is to load the item on a background thread and inform the user that you're doing so (either via a loading HUD or some other indicator). The simplest way of doing this will be to use - (void)performSelectorInBackground:(SEL)aSelector withObject:(id)arg;. If you're running iOS 4.0 + you may want to look into executing block callbacks and see if they will work for you.
For number 2, perform the sorting on the background thread or change your sorting method (consider using a sorted data structure rather than resorting after inserts?). reloadData should occur only on the main thread.
I'm an iPhone noob myself, but it sounds like your code is stuck doing synchronous actions, which will guarantee that your UI gets locked up until the action is done executing.
Although I don't have an explicit answer, look for asynchronous options to perform these actions as they will not lockup your UI. These are usually achieved through using threads or deferred objects. From my experience so far w/ Objective-C, most actions your program neds to take can be achieved through async actions.
So I׳m trying to play some effects in my Cocos2D game using SimpleAudioEngine , but after I have added them my app crashes when it goes to background (multitasked).
I searched for this problem in the internet but all the solutions that I found didn't work for me. What I did find out is that this problem happens because my app is somehow trying to play sounds when backgrounded.
In console it shows me (which is the same error I found other people had):
sgx error (background gpu access not permitted):
And another thing, when I run my app on the simulator, or even on my device while debugging carefully (going line-by-line with XCode while the app is running) this doesn't happen.
I just had this issue. I resolved it by having a bool to check if the app is running or in background that I set to true when the app goes to foreground ( applicationWillEnterForeground ) and that I set to false when the app goes to background ( applicationDidEnterbackground ) . So using the bool you can tell if the app is in the background and if it is, I just exit out of drawView function in EAGLView (thus not doing any graphics rendering which was causing the error).
I am a very dodge programmer but that method has worked for me and I hope it works for someone else. I did not need to unload and reload my sounds or anything and my app now has Multitasking XD
I was experiencing this, on about 25% of the occasions that my application re-entered the foreground. Like you, when I removed the sounds, the problem went away. That is how I came across your question here.
I may have found a solution to this. I have made what appears to be an unrelated change, but the problem seems to have gone away. Now, when my app enters the background, I invalidate my main scheduled timer. When my app re-enters the foreground, I then re-schedule the timer (after reloading my sounds, which I completely shut down on entering background).
So far, the problem has not come back. I would be interested to know if this helps.
I just resolved this issue on my end. Here's what was wrong in my case and, from what I can tell from the other answers and comments on this page, many other people's case as well:
By default, when I started my project, CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->resume(); were both being called twice, once by (void)applicationWillResignActive:(UIApplication *) and (void)applicationDidBecomeActive:(UIApplication *) respectively in AppController.mm, and once by AppDelegate::applicationDidEnterBackground() and AppDelegate::applicationWillEnterForeground() respectively in AppDelegate.cpp.
Make absolutely sure that these methods are only being called once, in AppController.mm. In AppDelegate.cpp, instead make sure that you are calling CCDirector::sharedDirector()->stopAnimation(); in place of CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->startAnimation(); in place of CCDirector::sharedDirector()->resume();.
Hope that's helpful to anyone else stuck in this crappy situation!
Are you sure it's related to audio? "background gpu access" sounds like it's using OpenGL.
I had the same issue in my application and spent some 4 hours to find out. Going background was OK the first time, but crash application the second time. With a short error message related to OpenGL. I had the same questions: how audio can crash graphics. But it wasn't a question of audio, but a question of notifications...
I discovered that going foreground was creating 2 timers in my custom level meter class.
I had registered UIApplicationWillEnterForegroundNotification and UIApplicationWillResignActiveNotification. Then, going background invalidated only one, since I registered only on notification... That was it!
One need's count its notifications!