OK. I have an app that is in regular communication with a Watch.
They are running apps that can do iOS 10.0 or greater, and WatchOS 3.0 or greater. I don't care about less.
When the iOS app gets shoved into the background, comms to the Watch get interrupted, and I start seeing log entries that mention NSXPCConnectionInterrupted, which is a standard Foundation error.
I have a couple of issues:
1) Where can I intercept this error? It doesn't seem to be showing up in my callbacks or delegate methods.
2) This is not a question. It's just an annoyance. In the simulator, I don't get this. It only happens in the device itself. I didn't encounter it until I was at a point where I could actually install and run on-device.
Related
I built a simple ios app with IBeacon . I ran this app on an iPhone 4s whit ios7.1 while running an IBeacon base station.Everything is working right in background or foreground(exit region have 30 seconds delay in background).But over a period of time,about 3 hours,this app can not monitor any event though device setting were not change(blueTooth and locate is normal).This situation must restart the device.
Please tell me what should i do aboult this situation?
Thanks!
I wonder if iOS Bluetooth scanning is slowing down when your app is in the background such that it appears that events never fire because they are just taking so long to happen. Rebooting may speed up the cycle.
One way to force a Bluetooth LE scan cycle to look for iBeacons is to run a different app in the foreground that uses the CoreLocation iBeacon ranging APIs.
Try installing Locate for iBeacon, then as soon as your app appears to be not getting notifications in the basckground, launch Locate for iBeacon and tap Locate iBeacons. Do you see iBeacons? Does your background app get a notification?
If this works, then repeat the test and instead of using the Locate app to force a scan, just wait (an hour if needed). See if you eventually get your notification anyway, and note how long it took.
Edit: it appears that this is a case where iOS stops looking for iBeacons entirely requiring a reboot. See related question below.
iBeacon: didRangeBeacons stops getting called, must reset device for it to work again
Hee
Does anybody know how to recognize a multitask-kill.
When the user puts the application in background state and then kills the app through the menu in iOS 4.2 my application shuts down.
Before there used to be an function called:
- (void)applicationWillTerminate:(UIApplication *)application
This method is not called anymore in iOS 4 and higher.
Is there a way to recognize it?
Thanks already.
Actually that's not entirely true. It is called on iOS4 devices that do not support multi-tasking and the documentation says that it can be called on other handsets (though I've never seen it myself).
But to answer your question, no, you can't recognise when a user kills your app. If you have state that you want to save you need to do this when your app goes into the background and not when the app is killed.
If you look at the crash reports you'll see that iOS sends SIGKIL which you can't catch.
You cannot catch this, your processed really is killed. Hard. Without notice. That us why you need to save state when you enter background now.
Maybe setting up a signal handler might work (don't know which signal to catch, though).
So I show my iAd banners when I get a callback to:
'bannerViewDidLoadAd'
But I've noticed that sometimes this doesn't get called. I have a constant high-speed
internet connection but if I run my app 10 times. 4 of out 10 times it won't show the iAds (i.e., bannerViewDidLoadAd does not get called).
Has anyone else experienced this (and what have you done about this)?
This is by design (I'm assuming you're still running in a dev environment) so that you can test your application when an iAd is available and when an iAd isn't available.
While you are developing your
application, iAd Network sends test
advertisements to your application. To
assist you in validating your
implementation, the iAd Network
occasionally returns errors to test
your error handling code. You can also
test your error handling support by
turning your device’s wireless
capability off.
per Apple's documentation
I have a super weird problem. Every time I run a specific bit of code in the iPhone simulator, my entire Mac freezes: I can't close the simulator, or any other app, and can't open any apps. Worst of all, I can't shut down. I have to force a shut down manually by holding the power button.
I'm running on a 15" MacBook Pro, and the only thing running is Xcode and the iPhone simulator. I used Activity Monitor to shut down any unnecessary apps running in the background. I've also used OnyX to clean up my system.
I'm using Xcode 3.2.4, with iOS 3.2 (iPad simulator).
At first I suspected this was a processor issue - so I ran the same code to induce a crash while I had Activity Monitor running. I can still switch between apps when frozen, I just can't open/close any or do anything with Xcode or the iPhone simulator. Activity Monitor reported that there was plenty of room for more processing, so it can't be that. I'm not running low on system memory. If I've missed anything out that might help in debugging this, leave a comment and I'll find the information. I want to fix this ASAP.
The code in question handles a bunch of timers, 3 background threads and a lot of UDP packets. The background threads are: two UDP receive threads, and a send thread. The background threads run a constant loop, looking for data on two different ports. The send thread runs another constant loop, but only sends data when there is any in its queue. The UDP processing just uses socket(), bind(), sendto(), recvfrom(), and select() calls.
I was under the impression that any problems in the current Xcode project would only become apparent in the iPhone simulator - an over-release only crashes the simulator, etc. How is it possible to crash the OS, not the simulator?
Edit: It runs perfectly fine on a device. Doesn't crash, doesn't report any memory issues, nada.
To see if a background thread is stuck on a blocked network call, put an NSLog (or fprintf to a file and fflush it) before and after every possible blocking call, and run with the debugger console visible.
Ever since the first beta came out I’ve been trying to find out if “real” multitasking is possible — i.e. can you put a program in the background and have it hang on to a network connection indefinitely?
I’m thinking about IM or IRC apps, for example. I’ve compiled an app myself on iOS 4, and without changing a thing it appeared to stay running in the background, but for all I know it was just suspended to memory.
The docs say the best you can do is request up to 10 minutes, but in the developer presentation they showed off Skype sitting in the background and then notifying the user that a call was coming in. Does anyone know for sure how this all works?
It appears the answer is no. The API for Skype is a very special case, called the "voip" mode, and requires special behavior, such as marking the socket in use for VoIP.
You can receive alarm notifications in the background (such as time passed). The amount of time you are in the background running state is severely limited by the OS.
Android's background model is complete and in many ways much nicer.
Apple has a guide named "Supporting Multitasking In Your Applications" which you should be able to locate.
Apple's iOS 4 developer docs outline this all very clearly.
When your app is closed or switched away from, it is almost immediately "suspended", meaning the OS freezes the app's state. When the user switches back to your app, your code keeps running just where it kept off. You don't need to add any code to your app to do this, just compile it against OS 4.
The above is true in most cases. There are two reasons the "suspended" model may not apply:
1) If the device starts to run low on memory, the OS will start terminating suspended apps that haven't been switched to in a while, without warning. This is why it's in your best interest for your app to remember it's state as well, so if your app is terminated, then re-opened, the user doesn't really notice because it still returns to right where they left off.
2) Your app uses one of the "background" APIs. These are for audio playback, VoIP services, or location services. In this case, your app is allowed to continue running in the background but only has access to those APIs. Additionally, your app can designate certain long-running tasks as "background tasks" that need to be completed before the app is suspended or terminated, like uploading pictures to Flickr or rendering a video, etc.
The "background task" method doesn't cover pinging servers indefinitely, as there is a time limit for the task, after which it will be forcibly halted. Apps that need that sort of functionality are expected to implement push notifications, just as before.
That should clear this up. All in all I think it's a pretty elegant solution to multitasking on a mobile device.
iOS 4 applications can either be running or suspended. The operating system will try to keep as many requested applications as possible in memory, while all other applications are suspended.
Applications that run in the background can access features such as navigation, audio, and VOIP (but NOT instant messaging). So it looks like you might be out of luck.
-- PC World Multitasking on Apples iPhone 4
It is possible for apps to request background time. Read the docs. I would say it iOS is "controlled multitasking".
You can create a long running background task, I believe these can include networking features. Just have to set the background task flag on the work block.
https://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
the OS can limit exactly how much time you get though... it will tell you when your time is up giving you a chance to cleanup nicely.
iOS 4 has "real" multitasking to some extend. There are two things to consider:
The UI event loop is single tasking. So only the front app executes on the UI event loop. Not a big deal: detach your main code form the UI event loop (maybe you need to redesign your app).
The OS "may" terminate your app if some criteria are met (e.g. low memory).
Currently one of these criteria is that execution time is limited to 10 minutes (real time not cpu time). However I expect this to change and see better criteria for background app termination (I hope to).
Apart from this you can have timers (event loops) in background.
There is no real multitasking in iOS 4.2 even. because apps will only be allowed to finish the task related to states..for small interval of time and then it will be in suspended state.. If you will set background task for long interval of time then... it will behave unexpectedly like no method will be called when you will try to run the app from anywhere..
You may be interested in this blog post that outlines how "multitasking" works in systems such as iPhone OS 4 and Android.
in fact u can do this, although it's not allowed by Apple. u gotta set up a toolchain in ur mac and use some unofficial SDK...
check http://code.google.com/p/iphone-backgrounder/ for more information
You should use the Push Notifications framework for the feature set you are creating!