I am new to iOS development and looking for some help. I am wondering if an iOS app can send interrupt to itself?
In particular i want to send a mediaServicesWereResetNotification to app to force a hard reset. Please suggest if it is possible. As per documentation this notification can be triggered by force fully restart media server on device. I want to check if I can just get the notification on my app without restart.
There's no need for a 'hard reset'.
As the documentation says, the iOS Settings app has an option to manually trigger this event (as many times you like):
You can trigger a media server reset by choosing the “Reset Media Services” selection under the Developer menu in the iOS Settings app. Using this utility helps to ensure that your app responds appropriately if media services were reset.
Related
We have a customer who wants us to have our iOS app check for new data posted every night and download it if it is available. As far as I can tell this is only possible if the app is already open or if they have someone physically accept a notification or initiate the process themselves.
Is this correct? I can't imagine Apple wanting to allow launching of an app and downloading data with no user interaction at all.
Yes, generally you can only download data at exactly specified times if the app is actually running in the foreground, that is correct. It wouldn't matter if the app was open already or the user opened it from a notification, the point is that user interaction is required. So, the client can't have exactly what they want.
Look at background downloading (fetch) from iOS7+ where you can register the app to perform background downloading in advance of usage. iOS is fully in control of this and it may choose to run the app and it may not. iOS will monitor when your app is usually used by a particular user and, if appropriate, it will allow the app to run in the background to do some downloading before the user is expected to use the app.
In particular you're looking at setMinimumBackgroundFetchInterval: and setting the UIBackgroundModes key with to fetch in the Info.plist.
As an aside, here's an idea based on your expanded information:
Use idleTimerDisabled to prevent the app from sleeping during main usage and keep a track of the time
After the main usage period of the app is over, start your downloads
After the downloads are done allow the screen to sleep
On the next day, if a user opens the app, repeat
It isn't perfect, but it's an approximation
I have a voip app, but it won't wake up from standby mode when a call comes in. The docs say the following:
There are several requirements for implementing a VoIP app:
1. Enable the Voice over IP background mode for your app. (Because VoIP
apps involve audio content, it is recommended that you also enable
the Audio and AirPlay background mode.) You enable background modes
in the Capabilities tab of your Xcode project.
// I did this using the "capabilities" tab in the project's settings.
// I have "audio and airplay", "voice over ip",
// "background fetch" and "remote notifications" checked.
2. Configure one of the app’s sockets for VoIP usage.
// I have 2 sockets, one for sending stuff to the server that closes after sending.
// One socket that stays alive all the time, which is used to
// receive stuff from the server.
// The one that stays alive is configured as voip*.
3. Before moving to the background, call the
setKeepAliveTimeout:handler: method to install a handler to be
executed periodically. Your app can use this handler to maintain its
service connection.
// I did this and in the handler I send a login message to the server,
// On the server side it's detected that the account is already logged in so
// it refreshes the connection instead.
4. Configure your audio session to handle transitions to and from active use.
// I did not do this yet, I might in the future.
5. To ensure a better user experience on iPhone, use the Core Telephony
framework to adjust your behavior in relation to cell-based phone
calls; see Core Telephony Framework Reference.
// I did not do this and probably never will (company's decision, not mine).
6. To ensure good performance for your VoIP app, use the System
Configuration framework to detect network changes and allow your app
to sleep as much as possible.
// I don't do this yet, but will implement it once all the basics run fine.
When a call comes in I create a local notification to let the user know about the call. When the app is minimized this works fine, but when the device is in standby (sleep) there is no notification. When I wake the device from standby, the notification pops up after a few seconds (so it's not already there, it really appears after waking up the device).
I created more voip apps in the past, and I can't remember ever having trouble with this. I'm running ios 8 now, perhaps I have to do some more to make it work while in standby? Are there more requirements for voip now? Or am I missing something stupid?
Note: I know about push notifications. They are an option (in fact, I already tested and they make it work), but I'd rather not be dependent on the apns.
I just spent two full days troubleshooting a similar problem. An iPhone 6+ worked properly but neither of two iPhone 6's did. To make a long story short, SIP packets were not being transmitted reliably. I pinged the VOIP servers offered me and found that I was using one with a latency of 30 milliseconds but one with 15 milliseconds' latency was available, so I tried switching servers. That did the trick.
Be aware that if the user closes the App manually (double click home button, swipe up) your application will not be able to run in the background until the user manually opens it up.
However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
Check it here.
I have a problem guys.I have requirement where my app should detect if the device is idle without any application running or without any user interaction from my application or at-least to know if the device is in home screen.What i am asking may be stupid but this is my requirement.Is there a way to achieve this. Help me
OK, enterprise apps are different. I think this can be done.
Have your app record whenever it's launched by the user (the app delegate receives events when the app enters/exits the foreground).
Then setup a "local push notification" several times a day that launches your app in the background and checks the log to see if the last entry is a "did leave".
If it is, then load up the URL to your itms services URL to install the new version of the app.
I have always coded for Android, and now I'm looking to expand my knowledge to iOS development; so I'm really new at this, please be patient.
I understand that only a small group of apps are allowed to run indefinitely in the background. Those are VoIP, Music players and location tracking apps.
I want to write a chat app using the XMPP framework. Everything is fine until the user puts the app in the background, in which case, the app will stay connected for about ten minutes to then be killed by the system and therefore the user won't be able to receive new messages.
I am aware of hacks to keep the app alive. Hacks such as defining it as a music playing app in the info.plist file and then just play some empty sound indefinitely. But I'm also aware that Apple will reject the app when it's time to publish to the App Store.
So, normally, how do other apps do it? How can other chat apps stay alive in the background to receive new messages from the servers? Apps like Google Hangouts, IM+ and such?
Ideally, they aren't really running in the background, but use push notifications, as others have mentioned.
But some chat clients seem to do something else: I've verified (by sniffing the traffic of an idle iOS device) that at least Google Hangouts, Facebook and Skype all keep a persistent socket opened in the background, and regularly send traffic to keep it alive.
I'm suspecting that they are using the VoIP exceptions to Apple's otherwise strict background execution policies. iOS allows "VoIP apps" to run in the background and keep one socket open to be notified about incoming calls and messages.
Maybe they are also using the new "background fetch" feature of iOS 7, but as far as I know, that doesn't allow persistent socket connections.
The iOS operating system allows for the existence of something called a PUSH NOTIFICATION
There exists hundreds of tutorials online which teach you how to implement the notification code and how to respond accordingly when you receive such a message!
http://www.raywenderlich.com/32960/apple-push-notification-services-in-ios-6-tutorial-part-1
Check this link out for an in-depth tutorial on push notifications!
http://maniacdev.com/2011/05/tutorial-ios-push-notification-services-for-beginners
I think most of these apps use push notifications and just load the last messages from the server as soon as the app is being opened.
While there are some hacks, and your app can ask for more time when it goes in background (up to a point, and with no guarantees), this is a perfect application for push notifications.
The server tells the phone there's a message, and iOS wakes your app up to process it.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html
As of iOS 7 there is a new background-execution mode - 'fetch' for apps that need to periodically fetch new data. It sounds like your case would meet that definition.
You can find the information in the iOS App Programming Guide -
Fetching Small Amounts of Content Regularly
In iOS 7 and later, an app that retrieves content regularly from the
network can ask the system for background execution time to check for
new content. You enable support for background fetches from the
Background modes section of the Capabilities tab in your Xcode
project. (You can also enable this support by including the
UIBackgroundModes key with the fetch value in your app’s Info.plist
file.) At appropriate times, the system gives background execution
time to the apps that support this background mode, launching the app
directly into the background if needed. The app object calls the
application:performFetchWithCompletionHandler: method of its app
delegate to let you know when execution time is available.
You can also use push notifications, but that requires some server infrastructure
An app running in the background has limited capability. Read App States and Multitasking thoroughly to decide how best to design your app. Chat is not listed as one of the specific exceptions that can operate with a more relaxed policy. You will never be able to "keep [your] app live in background forever." You might be able to leverage an iOS 7 feature also described in this guide, Fetching Small Amounts of Content Regularly.
iOS App Programming Guide: App States and Multitasking
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOS ProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
I was able to show an Alert View like the image above after registering for Remote Notifications.
But when i delete my Project App and build it again, it will not show anymore.
Will there be any chances to show the alert view again to the same device?
What i like is to get my device token again because I failed to store the device token temporarily in the NSUserDefaults.
Delete your app from the device.
Turn the device off completely and turn it back on.
Go to Settings > General > Date & Time and set the date ahead a day
or more.
Turn the device off completely again and turn it back on.
reference: https://developer.apple.com/library/ios/technotes/tn2265/_index.html
Addressing the question of presenting the push notifications permissions dialog again as needed for testing -- this is certainly a workaround, but here goes:
Having just finished work on an app that uses Push Notifications extensively, and having tried all the usual permutations, without success ... I ultimately realized that the most streamlined way to work around that issue was to get a device to use only for testing (i.e., a low-end iPod Touch).
To reset the dialog, do a Settings > General > Reset > Erase All Content and Settings. Go thru the device's setup process, reinstall the app and Go.
This was the only way I found to test the 'first launch' experience on demand, as needed during the course of development/testing. It also added a lot of additional versatility to the process.
Shouldn't have needed to resort to all this, but I'm very glad I did, as it turned out to be a real godsend. FWIW.
[P.S. It will probably also prove handy in the future for testing beta versions of the OS, etc.]
At launch, your app should be requesting a token via:
- (void)registerForRemoteNotificationTypes:(UIRemoteNotificationType)types
and will get a token from iOS in the delegate message:
– application:didRegisterForRemoteNotificationsWithDeviceToken:
iOS will prompt the user to allow notifications only when necessary. If remote notifications are already authorized for your app the alert will not appear and your app will get a valid token.
Net is you can't force the alert but you don't need to.
Yes.
http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
If you want to simulate a first-time run of your app, you can leave the app uninstalled for a day. You can achieve the latter without actually waiting a day by setting the system clock forward a day or more, turning the device off completely, then turning the device back on.
Temporarily change your package id.
com.mycompany.app - > com.mycompany.app1