I have one requirement that when user submit a form. I have to give user 30 minute time gap to edit the form. If he don't edit the form in 30 minute time interval , the form should be automatically submitted even if the app is not running. Can we make a service call when app is not at all running? If yes then how to do this. Please help.
To expand on Jasmeet's answer, you will need to change the server. You will need to submit the form at the latest in applicationDidEnterBackground:, though you may want to submit it much sooner than that (since the app may crash or the phone may be turned off, in which case you will never go into the background). If there are edits made, then you would submit the form again. If 30 minutes pass (as measured by the server), then the server will accept the form. You will likely want to include some timestamp information in the request so the server knows when the form was last edited.
There is no way to run code at an arbitrary time on the device. You must change the server code, or you cannot solve this problem. (Even if there were a way to run code at an arbitrary time on the device, it would not solve your problem, since the device may not even be turned on or have network access 30 minutes later.)
If you cannot change the server for some reason, then you will have to change your requirements. This cannot be solved as you describe it.
If you want to submit the form in background there might be chances the form will not submit if the app is suspended in the background.
you can submit a form first and if user edit the form within 30 min you can resubmit the form.
If you submit the app with background mode enabled and handling your work without Apple guidelines for background mode support enabled. Your app will be rejected. Please review the background mode support guidelines before taking up the appdidenterbackground call working. You may prompt the user to fill the data but don't autosubmit rather autosave and next time he wake up just restore the form so he can continue to have a good user experience.
Apple Guidelines to use background mode.
2.5.4 Multitasking apps may only use background services for their
intended purposes: VoIP, audio playback, location, task completion,
local notifications, etc. If your app uses location background mode,
include a reminder that doing so may dramatically decrease battery
life.
https://developer.apple.com/app-store/review/guidelines/
Related
I've been developing iOS apps for enterprise use for several years now. It was an adjustment from having spent many (!) years developing desktop apps. One of the first things I learned very early on was that it is frowned upon for an app to kill itself. The posters in the Apple dev forum were downright hostile about it, which is a reason I never go there anymore.
Now I have an app that has very critical functions, and it requires that the user accept the terms and conditions before using the app, and that the app will not function if the terms have not been accepted. The choice is there to accept or to decline, but it seems like the best thing to do when the user actively declines is to kill the app entirely.
My question is, under those circumstances, would there be anything wrong with that? Will I be damned to developers hell for eternity?
You can change the interaction here.
Instead of accept (and use the app) or decline (and never be able to use the app) change it to accept (and use the app) or nothing.
If the user does not accept then they cannot use the app. They do not have to decline anything. Absence of acceptance is all you need.
If they don't accept then don't do anything. They can always come back later and accept and start using the app.
Why kill an app on a declying? I would rather just leave a user at the same screen with no actions before he puts acceptance checkbox, disabling all buttons
If you make the app kill itself, Apple won't let you post it on the App Store.
You should adjust your User Experience to the case of the user declining the terms and conditions.
For example, show a screen saying that the app can't be used unless terms are accepted, with a button saying "Take me back" that takes the user back to the terms screen.
I am coding in Xcode 6.1.1 with objective-c.
In my app it is critical that I use the correct time.
I only want the app to use the time of the device when the time is synced with the servers.
If an user is somehow using his/her own "weird" time the app should detect that and tell the user to switch back to use the app.
I know there is NSSystemClockDidChangeNotification, but that only gives back when the time is changed. It does not give back what the change was and if the user switched to "custom" time or synced back to an NTP server.
Question: How do I detect if an user is connected to an NTP server or not?
Maddy is right that you can't specifically find this out from iOS.
However, in the past I've delivered a client for a premium subscription service that had a similar need to know if the user was messing with time. In particular we needed to verify this when there was no network available, in order to prevent the user from accessing premium content after their subscription had lapsed. The very simple mechanism we used was as follows (IIRC):
every time the app launches or comes in from the background, record the current time (eg: in NSUserDefaults)
compare the current time to the last recorded time--if the current time is earlier than the last recorded time, force the user to go online and sign in to the service.
I don't claim it is 100% foolproof, but for our purposes we felt it was good enough to prevent users from trying to circumvent time-based restrictions on accessing premium content.
I have a couple apps on the Apple App Store and would like some way to send announcements to users whenever I want. Basically, I want to remotely change the text of an IUAlertview and only trigger it to appear if I want it to (upon app opening and only if I updated the message).
So far I have no problem making the IUAlertview appear on when the app opens, and I can easily program an NSUserDefault flag to only make the IUAlertview appear under certain circumstances, but really have no idea how to dynamically change the UIAlertview text without resubmitting my app to Apple continuously.
Can someone please explain how this is done? Thanks!
One way to do this is to have your app periodically (or upon each launch) check a file on a website that you control and if there is changed text (or a version number, or newer date than the last time an alert was displayed) there, then display that changed text in your UIAlertView.
I have an in-app subscription product. When the app is loaded, I present a "subscribe now" screen to initiate the buy process. If the user cancels, the application MUST close/move to background/terminate since they have refused the service. What is the best method to use to do this?
This situation is addressed in the iOS Human Interface Guidelines, under "Don't Quit Programmatically":
Never quit an iOS application programmatically because people tend to interpret this as a crash. However, if external circumstances prevent your application from functioning as intended, you need to tell your users about the situation and explain what they can do about it. Depending on how severe the application malfunction is, you have two choices.
Display an attractive screen that describes the problem and suggests a correction. A screen provides feedback that reassures users that there’s nothing wrong with your application. It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application
For example, consider the iTunes Store or App Store apps, which are useless without a network connection. If you put your device in Airplane Mode and then launch either one, they will display a large Wi-Fi icon with a message saying an Internet connection is required. (I think an alert offers to disable Airplane Mode, but if you tap Cancel you'll see what I mean; the app will not quit.)
Be assured, if you simply force-quit the app, Apple will reject it.
I don't know if it's allowed.. but you can use
Exit(0);
OR:
[[NSThread mainThread] exit];
The application will close.
Best not to do that. You could just display another screen after they hit cancel explaining why they can't continue and give them a button to try again.
I know Apple frowns upon closing the app because the user might think it crashed.
So how do I make it quit intentionally with an exception that doesn't get caught when the user goes back to the home screen? Also, would this be rejected by the App Store?
I wrote this answer to another question. It an extract from the Apple Human interface guidelines and should help you understand why you shouldn't quit programatically.
You shouldn't force close an app as the standard way to terminate an application is to press the home button (or use the multitasking bar)
Don’t Quit Programmatically
Never quit an iOS application programmatically because people tend to
interpret this as a crash. However, if external circumstances prevent
your application from functioning as intended, you need to tell your
users about the situation and explain what they can do about it.
Depending on how severe the application malfunction is, you have two
choices.
Display an attractive screen that describes the problem and suggests a
correction. A screen provides feedback that reassures users that
there’s nothing wrong with your application. It puts users in control,
letting them decide whether they want to take corrective action and
continue using your application or press the Home button and open a
different application
If only some of your application's features are not working, display
either a screen or an alert when people activate the feature. Display
the alert only when people try to access the feature that isn’t
functioning.
Source
Apple will most likely reject it as a violation of the human interface guidelines, so it really doesn't matter how to do it.
So how do I make it quit intentionally with an exception that doesn't
get caught when the user goes back to the home screen?
You don't. If your app is "done," just go back to the initial state. Reset all your variables, release your view controllers, whatever. Pretend that the app actually did terminate, and that the user started it up again. You'll be happy, your users will be happy, and Apple will be happy.
An alternative, if your app truly can't continue for some reason, is to display a message that explains the situation to the user and tells them how to resolve the problem. Leave that message visible until the user leaves the app by pressing the Home button. This can be the only reasonable way to deal with situations where some resource such as network access is missing.
Also, would this be rejected by the App Store?
Nobody can say that for certain other than Apple, but I think the probability of rejection is high.
Please see the answer to this question:
Forcing a background application to terminate in iOS simulator
It will tell you how to setup your application to terminate instead of backgrounding when the user hits the home button.
If you don't want to do that, I recommend you should instead release resources when your delegate's applicationDidEnterBackground fires. I think that is your safest bet. More than one of us say what you're wanting to do is not ideal.