This question already has an answer here:
purgeIdleCellConnections: found one to purge conn = 0x1d57ba00
(1 answer)
Closed 9 years ago.
I'm getting a list of purgeIdleCellConnections shortly after downloading a lot of png images from the internet from a model class in the app.
Is this a threat to the application? It doesn't freeze up. Should I manually be closing connections?
Thanks!
xcode 4.2.1, ARC, deploying to ios 5.0+
EDIT: I'm seeing the list in my console. Also, I only see it when testing from my phone on a 3G network, not on wifi. Doesn't happen in simulator either.
I have no idea where you're seeing "a list of purgeIdleCellConnections".
If you mean in the Organizer console, it's probably normal: You've just stopped downloading stuff, so presumably there are now a bunch of idle cell network connections which can be turned off to save power (that's my take on it, anyway).
Related
This question already has answers here:
iOS ship application with pre populated sqlite database [closed]
(2 answers)
Closed 7 years ago.
I am making an app that use Core data for as the database for the app to perform an offline mode.(By swift)
So everything works fine but when i builded it on my real Iphone it seems like the database didn't go along with the app and then my app was crashed.
How can i fix it?
Thanks!
Most probably your app is running under an assumption that that data will always be present, but this is not the case. Both the instances are different, the one on simulator and the one on real device. So remove that assumption from your code. And make sure you setup the records in the real device also to make sure that you read successfully.
This question already has answers here:
Proper way to exit iPhone application?
(24 answers)
Closed 9 years ago.
In my app I am having a continuous communication with TCP server , now if
server sends a command to close the app, i want to close the app completely
and when user taps the app again, it should start with Application launch method itself.
I have tried using exit(0) in the code, using this application goes into background.But it doesn't kill the app. How can i do that?
There isn't a way. Apple doesn't allow it. The solution is: Just accept the fact that you are unable to do this and work around that fact.
This question already has answers here:
How to log all methods used in iOS app
(8 answers)
Closed 10 years ago.
I have used NSObjCMessageLoggingEnabled for logging the method entry and exit at run time for an application. THe logs has been saved in /tmp/msgSends-pid. Whre pid is process ID.
I want to save same logs while running an app on the iPhone device instead of running app on emulator using Xcode.
Please let me know if you require more details to help me out.
NSObjCMessageLoggingEnabled appears in Apple's technical note about Mac OS X debugging magic, but not the one about iOS debugging magic. It appears that it is unavailable on iOS.
Apparently, you can log Objective-C method entries and exits using a DTrace probe in Instruments.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I have a tried and tested enterprise iPhone app that's been in heavy use for over a year, and works great. The app makes frequent use of asynchronous NSURLConnectionRequests to fetch data from a server.
I monitor availability of network connectivity using Apple's 'Reachability' sample code. I've always considered the Reachability code to be a bit fragile, but I've had it working solidly for many months - iOS 4.3 onwards.
However, I'm now seeing a problem since upgrading to iOS 6. Seemingly randomly, after a day or two of dipping in and out of the app, I open the app and notice (via the console) that the app is receiving repeated 'network available' notifications from the Reachability class.
If I stop the task (and I mean, properly stop), and relaunch, the problem goes away, and the app behaves normally again.
Of course, this could be down to a subtle issue with my integration of the Reachability code (I've mentioned that I consider it 'fragile'), but I'm wondering if anyone has seen something similar since updating to iOS 6?
I did have a play with the iOS 6 -> Settings -> Developer Settings -> Network Link Conditioner, and it certainly feels like this problem has appeared since then, but it's definitely now turned off, and I've rebooted the device.
Anyone else seeing Reachability issues since updating to iOS 6?
OK, I'm going to assume this problem, that I saw twice, has magically 'gone away'.
If anyone else also sees it, please add to comments.
An update of my app has just been approved by Apple and users are now complaining the app does not launch anymore. It also happens to some new users.
I have absolutely no idea where the problem is nor can I reproduce the problem. I have tested the update on various devices (& simulator) before submitting the update: iPhone 2G running 3.1.3, iPod Touch 2G running 4.3 , iPhone 3G and iPhone 4 running 4.3.1. They ALL work as expected. The update has a few new features like random picking photos from user's photo library using AssetsLibrary framework, I have weak-linked the framework to support iOS 3 and the feature does not load until selected by the user so it should not be the problem. After all, the update has been tested and approved by Apple.
I have difficulty collecting crash information from users with the problem, but I know one of them uses iPhone 4 with iOS 4.3.2. A quick google search reveals that iOS 4.3.2 has problems launching third party apps, I suspect my problem has something to do with this but I can not confirm it. I am planning to downgrade my dev iPhone 4 to iOS 4.3.2 to test it.
Does anybody here experienced similar problem? My app's ranking has dropped significantly because of the negative reviews so I need to fix this as soon as possible.
Edit:
There should not be any watch dog problem, I tested the update on the above mentioned devices with and without Xcode/debugger.
Memory management. I can not reproduce the problem (I tried quite hard) so I can not confirm if it's EXC_BAD_ACCESS, I did check reference count and nil released objects (safely release) when applicable, I am absolutely not a pro in memory management so I take it seriously, I checked leaks and allocations with instruments, stress-tested and did memory warning simulations, no problem was found.
I have UIApplicationWillEnterForegroundNotification in -loadview, it's only available after iOS 4.0 so I check if it exists with & operator because I use it.
I do not persist data other than saving facebook connect token and expiry date (NSDate) in NSUserDefaults, since the problem also happens to new users so I think it's something else
We're going to need more info, unfortunately. But just off the top of my head:
Watch dog? What sorts of stuff are you loading when you launch your app? It may be that resources are constrained on the devices having this issue and you are doing work that should be done a separate thread, or otherwise delayed until after the app has launched.
EXC_BAD_ACCESS. There could be a race condition going on that is resulting in most people able to launch OK, but for some it just isn't working because of bad references. I know, you write good code and manage your references like a pro, but sometimes a non-obvious slip-up can creep in.
Are you safely instantiating some types of classes? An example that bit me once was with the MFMailComposeViewController class. Before instantiating you're suppose to call its static method canSendMail. If a user hasn't setup any mail accounts on their device (hard to figure there would be anyone that fits this scenario, but hey! found out after an update that there are quite a few!) then the app would crash.
What data persistence (if any) do you have? Are you using Core Data? Serialized objects in a plist? NSUserDefaults? Your strategy may be corrupting data you are persisting and that is leading to a crash.