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.
Related
When a user verifies their email address, I want to receive some notification on my client app (iOS/Android).
I need this to ensure that I can unlock additional capabilities for those users whose address is verified. How can I achieve this?
Currently, the only way to do this is to call the reload method on the User object. However, it is not an ideal way of dealing with this situation – after all, I have no idea when they would click on the link. So, performing a reload every time my app becomes active seems excessive.
Maybe there is a trigger which I missed?
Well, what I do is, each app launch I query the user object for its verification status; if it's not verified I send a verif request right there, if not sent before, and if it is and it's the first time, I show some thank you text and move on. I don't think there's an actual notification you can hook with for when the user clicks the link in the email, but alternatively you could build an admin node function server side to check every now and then for verifications and send pushes to the relevant devices.
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 have been struggling with this question and cannot seem to find a clean answer for. I am using social login in an app I am writing (my first). After the app launch, the user gets authenticated with his choice of a social network, in particular, Facebook. when a user suspends the IOS app for days, and returns to it, the app returns right where the user left off, away from the initial login mechanism and the login viewController. How and where do you attempt to verify if the user Facebook token changed (due to password change) or expired? from what I understand you have to make a social graph api request, but does that mean I have to implement this request in every viewController in my app? I am under the impression that when the app becomes active it will only load the viewController displayed before the suspension. Maybe I am wrong.
your input is greatly appreciated.
Regards
So I do have controller over what I present when an app becomes active. I can simply present in the window the login view controller. I can silently verify the credentials. if pass present the next view controller. if not present the login page for the user interaction.
cheers
My iOS app gives the user the option to login using their Facebook account. I would like to be able to see the list with all the friends and invite the ones selected to use the app. The problem is that using the app request window, the friends get a notification that is displayed somewhere in the App Center, rather than in the Notifications panel. Unfortunately, this sort of notification is very subtle and might not be seen only after a long time.
From obvious reasons, I cannot fetch the emails of friends as this would be a great alternative.
Do you know if there is a way to send a Facebook Message or some other sort of notification that is more 'visible' to the receiver? Thanks!
I'm not sure if I completely understand your problem. If it's the problem that I think you're having, it sounds like you need to fill out more information on your Facebook App's configuration page.
From what I remember when I had this same issue, you need to have a Canvas URL set in your Facebook App's configuration page. Even if your app is not going to use Canvas, you need to have that part filled out in order for your friends to receive the app's notification jewel on Facebook.
I'm learning the basics of iOS development, and I'd like to make a simple application that connects to a web service. I've got a lot of experience on the web application side, so I'm comfortable with what kinds of requests the app needs to send/receive etc. The part I'm not sure about is what the big picture architecture of a service-backed mobile application looks like.
When my application runs, I have one major requirement: the user must authenticate into the web service. The web service can send back a token and the app can use this for all subsequent requests. I want the user to be able to log in once, and for the app to stay logged in (ie the token remains valid for that device) indefinitely unless they log out.
Until the user logs in the application should really just be a login screen. If they log out, the same. Otherwise, they don't need to see the login screen at all.
So my question is, what is the right way to structure this?
In AppDelegate, do I want to make a LoginViewController and set it to the rootViewController? Then if the user is logged in, push to the main view for the rest of the app?
Or do I want to initialize the main part of the app (for instance, a UITabBarController with a few views in it), and check for a token, and then display a modal login screen if no token is available?
What I'm not clear on is what the rootViewController should be for an application like this, and how the app should keep track of whether the user is logged in, and determine what screen to show when the app is opened.
If anyone can give me a high level overview of how such an app should be structured, I'd really appreciate it.
Thanks!
There isn't really a right way to do this, either flow could be appropriate for an application. If I had some UI or data that would be displayed if a user is not logged in then I would use that as the initial rootViewController and use a modal login dialog to force the user to login. On the other hand, if I had nothing to display until a user has logged in then I would setup the login view controller to be the initial rootViewController if the user is not currently logged in.
For keeping track of the user being logged in you should leverage NSUserDefaults to persist the authentication token. Then in the application:didFinishLaunchingWithOptions: call to your app delegate look for this token in NSUserDefaults (and possibly validate it with the server) then set the rootViewController as appropriate.