possibly a simple question, but I couldn't find definitive answer (see below for excerpt from HIG) myself that would state below scenario as 'unacceptable' and will result in app being rejected:
On 1st application launch after installation user will see an alert
asking to activate the app.
Tapping "Activate" will open Safari and display a web page with
"Activate" button.
Tapping it will launch my app via URL-scheme, pass some server
generated data and allow user to enter main UI.
The application will be locked until user activates.
If you need more context on why and how, please see this answer.
Mobile HIG (as of 2011-10-12):
"If possible, avoid requiring users to indicate their agreement to your EULA when they first start your application. Without an agreement displayed, users can enjoy your application without delay. However, even though this is the preferred user experience, it might not be feasible in all cases. If you must display a license agreement within your application, do so in a way that harmonizes with your user interface and causes the least inconvenience to users."
Well there's similar cases where an app is almost useless until the user registers to some service, take Instagram as an example.
I'd suggest however that you solve this by not forcing the user to leave your app. Instead, present the user with a web view within your app where you politely describe why it is necessary for the user to go through the activation process.
We've done something similar before (EULA presented modally within a web view on first launch, which could only be dismissed by accepting it) and it was approved right away.
Related
When a user is not logged in and they navigate to a page tab made with our app, they get an obtrusive dialog asking them to log in:
This has nothing to do with http vs https, the app is not in sandbox mode, there is nothing in the tab asking for a login or user information, etc. I've gone through the app settings at least a half dozen times now, and nothing is wrong there. Aside of urls, the settings are identical to another app I have that does not suffer from this problem. I'm stumped!
Edit: here is an affected tab: https://www.facebook.com/StaticHtmlThunderpenny/app_203351739677351
This message is not about login to your app, but Facebook in general.
So my guess would be that the page your app is installed as page tab app on is restricted in some way – by age, location, or for having alcohol-related content. And then of course Facebook asks for login, because otherwise they can not determine whether or not the (as of now still “anonymous”) user qualifies to see the page.
So go check the page settings.
This is actually not app related question.
This is thumb rule!! To access any app on Facebook, you need to log in to Facebook. You can see Facebook page without log in. But for facebook apps, you should be authentic user.
with this issue in my own experience that I came across some years back with a facebook app that I was running, if this doesn't relate to any of your other social networking apps then am aligning two set of possibilities and solution.
The user might have not properly logged out as "written" in the app for the users logout stage.
Solution would be that the user logout as expected before closing the app.
The user might have set up an automatic login prompt which was removed by the app when it was been updated automatically. (If you do get me???)
Solution would be to monitise your app on updates and login informations or better still just login and logout ask intended by the app and for security reasons.
Lastly I would say that automatic bookmark database should be added to the server part so current pages as the user uses the app would be saved after logout or login stage. Thank you, hope this helps and if not let me know what am missing.
I'm currently developing my first native iPhone app (though I have many years of experience as a web developer). I'm having some difficulty understanding the best way to handle login and I'm looking for some advice on the best way to go about it. The more I think about all the things that can go wrong during login, the more my brain wants to jump out of my head. I'm getting really frustrated with this and could really use some advice from some more experienced iPhone developers. Thanks in advance for your help.
My goal is to support Facebook Connect in the first version of the app, and then to support other SSO services (Twitter, Google, etc.), as well as my own user account system in future versions. The current plan is to have a MySQL table on the server that looks something like this:
users (id, nickname, facebook_id, ...)
When a user logs into the app via Facebook for the first time, an entry will be created in this table for them. You may think this isn't necessary, but it will allow me to expand to other services later on. For example, I could do this:
users (id, nickname, facebook_id, twitter_id, google_id, username, ...)
This table would have nullable fields for facebook_id, twitter_id, google_id, and username. If the user logs in with facebook, they'll have a facebook_id. Twitter users will have a twitter_id, Google users a google_id, and my own users will have a username. They'll all be uniquely identified by my own id regardless of what login system they're using.
So I'm pretty comfortable with the back-end implementation of user accounts. I can setup a web service that the app can call to create/retrieve users, verify logins, etc. No problem.
The problem I'm having is implementing a proper login flow with the iPhone UI components. My particular app uses a UITabBarController that serves as the main navigation. One of the tabs is labeled "My Account" and contains information about the currently logged in user. If the user clicks on the "My Account" tab, they are presented with a table view that serves as a submenu. It has options such as "My Profile", "Settings", and some other things. If they click on any of these menu items and they aren't logged in, then I use the presentViewController function to pop up a login screen. They click "login with facebook" and go through the typical Facebook authorization process. When they've completed that process, I use dismissViewController to remove the login page and display the page they were trying to access. If they cancel the login or if the login fails, then I use popViewControllerAnimated on the UINavigationController to send them back up to the "My Account" submenu. For those of you who are having a difficult time envisioning this, check out the Amazon app. It is almost the exact same thing (just click the "More" tab when you're not logged in and try to click one of the menu items underneath it).
That all works pretty well and I'm happy with it. But here's where I get confused:
What the heck do I do if they're several levels deep into the UINavigationController within the "My Account" tab and their login session expires?
Let's take Facebook login for example. Facebook uses session tokens to keep users logged in. The tokens expire after a certain amount of time. Let's say the user navigated down into "My Account", then clicked "My Profile", and then clicked on "Edit" and are shown a screen where they can edit their profile information. So they obviously need to be authenticated in order to view this page. In fact, they're 2-3 levels deep into pages that they need to be authenticated to see. Now let's say they get interrupted by a phone call or something and forget all about what they were doing. The next time they access the app is a week later when their login session has expired. I can handle this in a few ways. None of them seem great to me.
Solution #1
The Facebook SDK will automatically call a method on the AppDelegate class that notifies me of the expired session. Since I am notified of the session expiration at the AppDelegate level, I have no idea what page the user is currently looking at and whether or not they need to be authenticated in order to use it. To get around this, I can have all ViewControllers that require login to extend a "ProtectedViewController" class or something that indicates the user should be logged in to see that page. Then when the AppDelegate is notified of the session expiration, it will try to figure out what the current ViewController is and check if it extends "ProtectedViewController". If it does, then present a login screen. If the user successfully logs in, then everything proceeds as normal. If not, then return the user to the first screen of the app where they have to start all over. This is bad because the user will lose anything they've typed in already, but I don't see any way to avoid it with this solution.
Solution #2
Ignore the session expiration event at the AppDelegate level and instead do this: before any action is taken that requires a user to be logged in (e.g. when the user clicks "Save" on their "Edit Profile" page), check if they are still logged in. If they aren't, then present a login screen. If the user fails to login, then send them back to the start screen. This solution is a pain in the ass to code because I have to perform a check on practically everything the user does within the protected area of the app -- when they view a page, when they click a button -- just about everything.
I would also prefer to avoid sending the user all the way back to the start screen of the app if they fail to re-authenticate. Instead, in this case, I'd prefer to send the user back up the UINavigationController to the "My Account" menu -- which is the closest page that doesn't require login. Sure, I could hardcode that, but I'm looking for a solution/pattern that works a little more naturally and that I can reuse in other apps.
I would really appreciate some guidance. Surely I'm not the first person in the world who has needed to solve this problem. Unfortunately, Google hasn't been much help.
Thanks.
EDIT: Another idea is to subclass UIViewController (e.g. "ProtectedViewController") and implement the "viewWillAppear" method. Inside this method, I can check if the user is logged in. If not, then I slide up a login page. I still don't know how to handle the case when they fail to login, though. This solution has a problem, though: if the user's session expires while they're using the app, then I won't re-authenticate them until the next time they click on a new view. If they're already looking at say an "edit" page and click the "save" button, then they won't be re-authenticated. But perhaps this is a step closer to the solution.
Don't forget that the app delegate is the one that adds the whole tab bar to the main UIWindow. On detection of credentials failing, you could simply remove the UITabBarController from the UIWindow, and replace it only with your own login view to re-authenticate. That eliminates any possibility they could interact with anything in the tab structure, but when restored means whatever position they are at within the tabs is preserved (since you would simply remove the tab bar controllers view but leave the controller intact).
Here how I managed it in a recent project using singletons.
Create a singleton class, say LoginManager that has a method called,
-(UserInfo*) getValidatedUser: (UIView*) senderView
Inside this method check to see if the token is still valid.
If it is not valid simply create a new view that forces the user to login using FB credentials and overlay it on top of the "senderView" so that the user is forced to login, like this:
[senderView addSubview:loginView];
Once the token is valid, you return back the user information.
With this basic logic in place you can now call this getValidatedUser method from your view controller classes whenever you need a valid credential to do something:
UserInfo* myUser = [loginManagerObj getValidatedUser:self.view]
The method internally decides if a login page should be shown or not.
Hope this helps.
I'm writing an app for a retailer, but my client wants that once that the user has logged in the app does not let him/her log out.
My question is: Is this a permitted behavior on Apple apps? Will it get rejected? I've been looking up for a policy related to this, but haven't found anythin that either allows or denies this.
Thanks in advance.
You cannot prevent the user from just killing the app. But she does not necessarily be logged out. If you mark her as "logged in" by means of some persistant store (such as user preferences), you can have him be logged in automatically next time she starts the app.
This is a design that I have seen in many apps. I do not think that it would get you rejected. The user would have to delete the app completely to log out.
One possibility: put a "change login" option into the preferences. At least on iPhone, that is very far away from the app, at the bottom of the settings app which most users never find. Even then you could only let the user be logged out completely once she is logged in with a different valid login.
My recommendation: don't take the control away from the user. Explain to your client that there is a balance between marketing necessities and the danger of annoying important customers who might unduly amplify negative sentiments. Accomodate the needs of your client by making it a bit tedious to log out - but not more.
I am designing an iOS application where a user is presented a "sign out" button as the client wants that to be there.
However I am having a tough time working through the logic.
Should I:
1). exit the application at that point since the entire app runs on the premise of authenticated web service calls. (if so how do I make my app exit? )
2). Take the user to the initial splash screen where he/she is given the choice of login/register. (if so how do I reset the app back to initial screen?)
I know what I am asking is confusing so I hope I am making sense.
Exiting from the app is not recommended. It would give the feeling of app crash to the user. You may use the second approach of sending the user back to the initial login screen after he sign outs. If you are using a navigation controller based approach you can try using popToRootViewController method of going back to the login screen(assuming login screen is your root).
Exiting the app is definitely not a good option. I would suggest you take the user back to the page where the user has the option to login or register. As an end user if he/she want to sign in with a different account if he/she can, it would certainly be the best option. No user would want to exit the app and launch it again to use them.
I know about test accounts, but during beta I'd like to allow access only to my friends, and then later friends-of-friends, and then only eventually Kevin Bacon and his friends.
That would probably suck, wouldn't it? The app would be listed (is there a way to prevent listing?) and someone I don't know might try it and get a "sorry, this is in development message." I imagine they'd be irritated and not come back.
From what I've read, only a few apps take off, but when they take off, they REALLY take off. Do developers just release these things fully baked?
Anyone start out with OpenSocial or other smaller-than-Facebook networks?
Any ideas for a soft, gradual, restricted roll-out?
Once you've set up your application, there is a setting in the Developer application control panel for your app: Your app -> Advanced -> Sandbox Mode.
Sandbox mode lets you restrict access to only those people listed as developers (under the Basic section).
In terms of expanding the app, Facebook doesn't provide much more flexibility that the Sandbox mode. Unfortunately, adding everyone as Developers of the app doesn't work very well for a beta, as people can access the application control panel once they are a developer. I ended up putting a whitelist of Facebook Ids into the front controller of my application for a previous beta, and it worked fairly well.
The apps are only listed in the App Directory if you submit them and they are accepted. There's no issue about preventing listing, it's something you have to apply for.
As for restricting users, you can accomplish it with a script in the application that checks whether the currently logged-in user is within your restricted user set. For example, if you only want friends of yourself, check whether the current user is friends with your user id. If not, simply display an error/message page or redirect them to the Facebook home page (or wherever). Add this check to the rest of the start-up logic run each page (such as connecting to your DB and authenticating with Facebook).
What I have done in some cases is keep a database table with the user id's of users who are allowed access, essentially a "whitelist". If the user isn't in the table, redirect them.