In the newly released GLPaint sample code from Apple seems to be an error: the shake event doesn't work. But i can't find the reason, even after looking up nearly every thread about shake events in this forum.
i am really going crazy because i don't see anything wrong in the code.
EDIT:
I thought i would have come closer (but it still doesn't work) by changing following things:
In AppController.h change UIWindow to "PaintingWindow". Also the .xib file, i changed the class to PaintingWindow. Another thing is, i overwrote the function canBecomeFirstResponder in PaintingWindow.m with return YES. Furthermore i added in applicationDidFinishLaunching, that the window becomes first responder.
So changed a lot, nothing worked. Please someone?
Related
I'm having the most bizarre problem which I'm not even close to figuring out. I have a button which fires a delegate method. Once upon a time it was working fine, but after making some changes to my code, now the delegate method only fires after I push the button x amount of times (the changes I made to the code had nothing to do with the infrastructure that connects the delegate together). It varies, it can be 5 times to 10 times. I used the analyzer to check for memory leaks and there aren't any.
There is too much code for me to paste here (I don't even know where to start or where the problem could be), but I'm wondering if anyone has experienced this problem before, or what could be causing it? This is very odd and have no clue what could be causing it.
sounds like some other view is getting the touch events over the button. I've also seen this type of behavior when the touch area is too small (either because the button is too small or because it's getting clipped by another view)
I have this map view with a bunch of overlays. When I hit the home button and re-open it, all the overlays disappear for a second and immediately re-appear. At first I thought it was my code that was doing it but I put breakpoints pretty much everywhere and none of my code seems to be triggering the "reset". Even mapView:viewForOverlay: doesn't get called before the overlays reappear.
I thought maybe this is an inevitable behavior of MKMapView, but it seems like Maps.app doesn't do it either — if you calculate a route and quit/re-open the app, the overlays stay there the whole time.
I'm thinking maybe MKMapView clears all of its annotations/overlays by default on quit so it takes less memory while staying backgrounded. Is there any way to avoid this? Kinda like Maps.app does?
EDIT: here's a small project I put together to demonstrate the problem. Just launch it in Simulator, click the home button, and re-open it. You'll see the map path overlay disappear for a moment.
This is more of a follow-up than an actual answer, but basically this issue has been flagged as a bug by Apple. I submitted this as a TSI to Apple a while ago and received the following answer:
Thanks for providing a sample project. I don't see any issues in your
code. At this point I recommend escalating the issue to engineering by
filing a bug about the "flicker" from the MKPolylineView being redrawn
at https://developer.apple.com/bugreporter/ and sending me the bug
number so I can use it to follow up.
I then submitted radar #11041378
Thanks again for your bug report. As it happens, I don't have a
workaround for you at this time. Engineering is still working on the
issue, but I don't have a timeline for a fix.
I'll go ahead and leave this incident open for you as long as bug
11041378 is open. If you have any questions about it's status in the future, or the status of a workaround, feel free to reply back and I
will check it for you.
If you have any comments for engineering, or want to tell the story of
why it's important to your situation, I'd actually encourage you to
put that directly in the bug. Since it's been assigned to engineering,
any comments will go directly to them.
I appended the following comment that describes why the issue is important to me:
This bug feels rather important to me as the user expects to find the
app in the exact state he left it when he quit the app. The flickering
overlays (sometimes disappearing for less than second, other times for
2-3s) may get the user confused about what is going on, when all he
really wants is to interact with the map/overlays right away.
Haven't heard back from Apple since. Hopefully this will get fixed in iOS 6?
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 am trying to access the UITextView delegates and have a problem
I have a UIViewController with the UITextViewDelegate protocol and a Nib containing the textView.
If I set the delegate inside viewDidLoad like "textView.delegate = self" and I touch the textView, the app crashes without logging errors.
If I start editing the textView with code like "[textView becomeFirstResponder]" all delegates get called.
When I set the delegate in the Nib creating a connection between the textView and the File's owner and deleting "textView.delegate = self" also no delegates get called.
What am I doing wrong here?
Regards,
Elias
It's not easy to help you without more description, posted code or a xib file.
You say application crashes without any logging errors - well, do you mean that there's no output in console's window ? That is normal, for an app that has crashed.
Anyway, you should be able to get the stack-trace to figure out where approximately the application has crashed. Open the debugger (⇧⌘Y), and see the position. That should give you an idea of what went wrong.
Here you can see an example of such debugger session (after EXC_BAD_CRASH):
First two lines doesn't give us much information, but later on we can see that application has crashed while loading user interface from a NIB file. Well, usually the only code that executes during such load are awakeFromNib methods - it's up to you to find a problem along those lines.
Often top of code's execution doesn't make any sense - for example you might see your ViewController method somewhere, but the top few function calls (those where the code crashed) are located in methods/classes which you never call in your code. In most cases that is a sign of wrong memory de-/allocation. What might happened is that you forgot to retain some of your objects, it has already been released, but you are still keeping reference (a pointer) to its memory. Because that memory has been in fact freed, another object took its place later on, usually some Apple's internal object you've never heard about. Later on your code tries to message your poor object but it sends a message to something completely different. BUMMER! That's how you get those crashes and strange stack traces.
To fix the kind of problem I've just described you can use Instruments and its Zombies instrument. Unfortunately you can't start Zombies from within Xcode, you need to start Instruments standalone, then choose the Zombies under iPhone Simulator/Memory, then Choose Target from the toolbar, you should see your application in there, or be able to navigate to it on filesystem.
What Zombies instrument does is that it never really frees memory after objects are deallocated. Instead, it will mutate those objects into NSZombie class. That class intercepts all calls to itself, and informs you when some code is trying to send a message to it.
This is how such Instruments session looks like (this is the same crash as seen in debugger above):
In the table you can see that we're trying to message UIScrollView that has already been deallocated. You can as well see the whole history of retain/release calls to this particular object. That way you can find a missing retain or wrong release/autorelease.
Remember - Zombies Instruments can only be used with Simulator, because there's not enough memory on the real device to keep all those memory blocks.
Hopefully I could help you with further analysis of your problem.
Ok so I've got a really annoying bug in my app. It's driving me crazy and I'm sure it's beyond my skill level as I am learning as I go.
Here is the initial rundown of the bug: A shot in the dark - Application bug
However I have found a way to consistently reproduce the bug (only on the device not in the simulator)
First you create a new Pool and save it. Then add 20 blank time entires into one day. Save it and this is where the problems begin. (when you go back to the main detail view the tableview has put itself out of editing mode with being told to do so). Now if you go back to the day to see the time entries you just added they are still there.
If you go back to the main overall tableview listing all pools and now go back to the day you added the times they have dissapeared.
Add one time and it all saves fine. Add twenty and it doesn't save. WTF!!
Main Menu listing Pools:
Detail view:
Edit View:
Time Edit View:
Add a time:
I'd appreciate any more guesses. But as well as this question I'm offering a bounty of £25 (Sorry I'm a poor student) to whoever is good enough to fix this bug first!
if your interested my email is danmorgz[at]gmail.com
Thanks,
Dan
If you haven't already done so, I'd recommend turning on NSZombie support and seeing if you're using any of your objects after they've been freed. As far as I know this can be turned on in the simulator and on the device.
Most likely, you're failing to retain some object somewhere along the way. When an object gets released and then the memory is re-used for something else, you'll get all sorts of bad behavior, including crashes, or mysterious "disappearance" of other objects.
One thing you can try is putting breakpoints into the -dealloc method of your custom classes. Then you can see where they're getting deallocated from. Most likely though, this will end up being when the AutoreleasePool gets drained, which won't tell you much.
Alternatively, look into using some of the memory debugging tools built into Cocoa.
That document is for Mac OS X, but I think most all of this will work in the iPhone simulator, at least. I know that your bug "doesn't happen" in the simulator, but that really only means that the symptoms are different, and you're not noticing them.
Thanks for all your answers. It's now fixed.
For those interested I'd forgotten to add a cellidentifer in the XIB of my cell subclass.
cellForRow: method was therefore creating a new cell every time. The memory got filled up very quick. It then seemed as though my app was automatically trying to cut the fat by forcing another tableView out of editing mode and not managing my instances properly.
Again it's a memory problem. Isn't this always the case!?!
The clue was a one off 101 error in the console indicating my app was using too much memory. Oh and a slow scrolling tableView.