On my app there is a password reset page. if the textfield is blank and the user hits the submit it generates an alert with title : Invalid input however when user puts the password and clicks on submit he gets a different alert with title : password changed. when user clicks on ok of password changed alert he should gets directed to the different page but when he clicks on ok of invalid input alert he should stay on the same page.In order to redirect to the differen page I am using the method below
-(void)alertView:(UIAlertView *)alertViewclickedButtonAtIndex(NSInteger)buttonIndex
so,whenever user clicks on ok of any alert it's redirecting the user to the different page. How can I differentiate between both alert's ok button?
If you are developing for iOS 8 or later, good news: You can use UIAlertController instead, which solves this problem by its design. And if you are creating a new app now, with iOS 9 out, I'd seriously consider dropping support for iOS 7.
If you must support iOS 7, you can handle this in a couple different ways:
1) Add a class property to keep track of which alert view you last showed; in the click handler check that value and respond appropriately. This is the quick and dirty fix.
2) Create a little utility class that implements the UIAlertViewDelegate protocol. Create 2 objects of that class. Use one object for each alertview that you create. Have that class call back into code in your viewcontroller. You can use this utility class in the future when you need to do this again.
Related
I'm working on two iOS applications that share the same keychain tokens which they receive when the user logs-in in either of the apps by entering his username and password in a web view. The tokens saved saved in the keychain, are time limited for a few hours/days - they are being refreshed when the user uses the app and makes request/enters items which are being opened in a browser.
Up until the release of iOS 11, the web view in the app was a SFSafariViewController instance and it was very convenient because it shared the cookies between the apps and once a user logged-in in a browser in one app, he would automatically be logged-in in the other app, thus achieving an SSO experience.
In iOS 11, the behavior of SFSafariViewController changed, and it no longer shares the cookies between different SFSafariViewController instances in my two apps. Instead, Apple wants us to use SFAuthenticationSession to achieve the same behavior.
In my app, I have a table of about 50 rows, almost all of them open a different URL in SFSafariViewController. So now, in iOS 11, I need to create a new instance of SFAuthenticationSession every time (the URL cannot be changed once the instance was created), and in order to actually show the web view, I need to invoke the start() method on this instance. However, this method can only be invoked once on the same instance (otherwise it will return 'false' and do nothing), and every time it is being invoked, it pops the notification that "myapp" wants to use "mydomain.com" to sign in.
So it means that my users see this alert message on every tap on a row in the table.
Is there a way to make my app show the consent alert message only once, e.g. on the first time or something? I want my users to have an SSO experience in my two apps, that's why I used SFSafariViewController in the first place, but I don't want them to see this annoying alert on every tap they make in the app.
There is currently no way of having the alert message only show once using SFAuthenticationSession, we are experiencing the same issue on our apps.
I along with many others have filed a bug regarding this to Apple, asking them to show it only once like you suggested. The end of this GitHub thread discusses the alert.
I would like to customize the following part of the notification permission prompt:
Notifications may include alerts, sounds, and icon badges. These can be configured in Settings.
Is it possible to change this to my own text?
You are not able to customize this message. Read Here for more information.
The recommended way that most apps handle this is by first presenting their own dialog, then show the Apple system dialog.
So when it comes time to ask the user for notification permissions, first you trigger your own custom alert that says something like "Please allow your-app-name to send you notifications..." and maybe a brief description of why the user should allow this. With this alert, only add one action to the UIAlertController, I usually just have the action title set to "Ok" and use .default as the style. In the completion handler of this "Ok" UIAlertAction that is when you will trigger the Apple system dialogue which presents the generic UIAlertController with the option for the user to either accept or deny permissions for your app to send notifications.
So the flow is something like -> users reaches point in app where they have to decide if they want to accept or deny notifications permissions -> app presents UIAlertController that is essentially just an explanation of why the app wants/needs to send notifications -> once user taps "Ok" then trigger the generic system alert that actually makes the user choose to accept or deny notification permission.
There seems to be some psychological advantage to doing it this way. By sort of forcing the user to tap "ok" to notifications in the first dialogue, it primes them to tap "allow notifications" in the generic Apple dialogue displayed immediately after.
EDIT Dec 2020 -
Alternatively what I see a lot of apps doing now is offering an "Accept" action and a "Maybe later" action in their custom alert. If the user taps accept, then the app displays the Apple system alert which allows the user to actually Accept/Deny notifications. If the user taps "Maybe later" then the app does NOT display Apple's system dialogue. This way the user never taps DENY on the Apple system dialogue and therefore the app is still allowed to show it in the future without having to make the user manually change the app's notification preferences via the iOS settings app.
EDIT Mar 2021 - (see #blackjacx comment) Apple has rejected (at least 1) app(s) for using a "priming" dialogue before showing the system alert. So that approach seems like it is no longer allowed.
For anyone who is looking for an updated answer: This is now possible using Xcode 13 (not sure exactly what version introduced it but I was able to see it on Xcode 13.4.1 and not Xcode 13.1) by setting your custom text as the NSUserNotificationsUsageDescription key in info plist file. Unfortunately at the time of writing this, it looks like Apple released this feature with no documentation on it but I can confirm it works on devices with iOS 15.4 and above!
In XCode, you can now click your App name on the left to open it's settings, click on Info, then add a new key called "Privacy - User Notifications Usage Description" -> Then you can set the value to whatever you want that message to say.
No, this is system message, you can't change to custom.
No, I'm fairly certain that that part of the message is out of your control.
I do not believe you can change the iOS prompt, but should maybe make your own. See the guidelines that Apple has provided:
https://developer.apple.com/ios/human-interface-guidelines/interaction/requesting-permission/
Not the best resource because it does state that you can change the subtext (this is specifically for location, photos, etc.) but this, and others, have some good practices:
https://blog.clevertap.com/asking-for-ios-push-notification-permissions/
Basically, you should make your own prompt. Be sure to handle the cases where they have either said no, or turned it off in settings and redirect the user to settings, if so.
Displaying Custom Messaging Before the Alert Ideally, people already know why you’re requesting their permission based on context,
but if it’s essential to provide additional details, you can display a
custom message before the alert appears.
Make it clear that opening the system alert is the only action people
can take in your custom-messaging screen. People can interpret a
pre-alert message as a delaying tactic, so it’s critical to let them
quickly dismiss the message and view the system alert. If you display
a custom screen that precedes a privacy-related permission request, it
must offer only one action, which must display the system alert. Use a
word like "Continue" to title the action; don’t use "Allow" or other
terms that might make people think they’re granting their permission
or performing other actions within your custom screen.
Guidelines here :
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/accessing-user-data/
Just to add clarity to Uche Nkadi 's answer, add a "Privacy - User Notifications Usage Description" key in your app's Custom iOS Target Properties. This will change the message on the notification permission alert.
I am working on iOS application that contains multiple forms, user may chose a form "A" and starting it.
user can move forward and backward to change input data as required.
user can save the form at any particular point of form "A" and comeback to it later, and start form "B".
The question is, how to go back to the same view/screen when the user comes back to finish off form "A" even if the user quitted the application, where the user should be still able to navigate forward/backward.
Any ideas appreciated.
Thanks
As long as the application remains in Background or in suspend, the last used view will be shown back.
Whenever the application is terminated by user or iOS due to memory constrains, the stack that contain the viewControllers will be erased.
So when the user launches the application, flow starts with the initialViewController. However you can retain the data, the user entered before closing, by store the data in applicationWillTerminate using NSSearchPathForDirectoriesInDomains.
I'm writing an app where a user can store a list of documents. When the user adds a new document whose name is already in the list, I'd like to prompt the user for her/his consent to replace the old document. I've looked at UIActionSheet but looks like it should be used when the user clicks some sort of button. UIAlertView is more like warning the user "The document will be replaced, no matter you like or not." So my question is: what's the best way in this case to prompt the user for consent?
Alerts can be used to ask the user to confirm an action. It is done all of the time. Simply implement the proper alert view delegate methods to respond to the user's choice.
Action sheets can be shown at any time with any need for a button to trigger such an event. The action sheet provides several options for displaying the action sheet.
Here's my scenario. As part of my app when someone is sent a message it sends an alert to the phone. If they click on the alert I want to open up the specific message they were alerted to. I have a view message controller that will show the specific message. Here are my questions:
What is the best way to handle a notification while the app is open? I get the alert in the appDelegate, should I show an alert box that's triggered from there and open the correct controller if they choose to view it? This seems like code that doesn't belong in the appDelegate, but I don't know how that would otherwise happen.
For the login, this is a very similar question. When they are logged in it logs them into the server, and they stay logged in for a period of time. When the app loads I want to fire off a check on the server to see if their login has timed out. If it has I want to push them to the login screen of the app. Would this also happen in the app delegate?
My third question is how to best handle getting the phone id. I have the method set up in my app delegate where I get the ID when they accept the push notifications. My plan is to check and see if they are logged in, and if they are check to see if I already have their id saved to the server. If not send it up to save. Is that the best way to do this?
Yes, you would want to show a notification (UIAlertView is perfect for this), so the app doesn't suddenly change views, or jump around when a notification comes in. You'll want the user to be in control of whether they want to view the content related to the notification, just like they can choose to ignore notifications from apps anyway.
Yes, or switch the view to whatever view controller handled the login (you could do this modally). Be sure to let the user know why they're seeing the login view: "Login is required to view [NOTIFICATION]" or something like that. But it depends on the rest of the flow of your app.*
Not entirely sure which ID you're referring to? You might want to store a unique token in the app which you communicate to your server. This token is generated on the first login, for example which enables you to match up the user's login with the token. A UUID might work, or you can roll your own.
*A note on your auto-logout, why do you have this? Most apps stay logged in at all times, and let's the user control when they want to logout (Facebook, Twitter, Instagram, etc. - unless it's a banking app or PayPal). Alternatively, you can let the user add a custom four-digit login code like the Dropbox app for example.