I'm trying to glue information from a web page to an iPhone app that said web page suggests to download. I control both the web page and the downloadable app.
Scenario is like this:
User visits my web page, on which I recognize the user (he may have logged in, and I store his info in a cookie). I then present a link to him to an app in the App Store that he should download for "enhanced experience" of this web service of mine.
Now, when the user launches the downloaded app on his iPhone, I like to re-identify the user who previously visited said web page.
All would be easy if an iPhone app could read Safari's cookies. But it can't.
A somewhat lame solution could be that the web server stores the visitor's IP address and uses that to recognize him once he launches the iPhone app. But that's not reliable.
Another one would be to give the user a token (code) that he needs to remember and then re-enter in the app. Still quite awkward, I think.
Any better suggestions?
Simply put, you can't do this.
One thing you could consider is a custom URL scheme to launch the app. You could send the user an email that uses this custom link. However there's a couple of problems with this:
the user may not have the account that they used to register for your site set up on their iPhone. This might seem unlikely, but say the user signed up for your site 5 years ago with their Hotmail account and they have since switched to Gmail.
it's unlikely that the email would fit into their workflow. They would probably download the app and just launch it by touching the icon instead of clicking a link in a received email.
You could also put the custom URL as a link on your web page, but again, this won't fit into the workflow because they have to go to the App Store app to do the download.
Consider this - if you've got some sort of website that has an authentication step, it's probably a fair bet to say that the user is the type of person who already has an application such as Facebook installed on their iPhone. They are already used to the paradigm of having to enter their credentials into an application despite the fact that they may have already done it in Safari.
If you could read the unique iPhone device ID from javascript on your web page, you could look for that again when the application connected...
But I cannot find any means of reading this from Javascript in Mobile Safari, I thought I'd post in case there is a way now to give you another option to consider.
OK, we found a somewhat working solution: The html code can create a cookie. Later, when the app runs, it can't directly read that cookie, of course (due to the sandboxing of iPhone apps). However, it can connect to the server, then open a http URL pointing to the server and including a unique token that it has gotten from the server beforehand. This leads to launching Safari, accessing the server. The server can now read the aforementioned cookie and finally establish the connection with the help of the token.
Just stumbled over this question and I'm curious if you thought about using a UIWebView.
Where the question is - does UIWebView share cookies with safari?
If it does the rest should be easy.
UIWebView's DON'T share cookies with Safari. So unfortunately that is not an option.
Related
I have a web page that redirects to the appstore, once the user has installed the app I'd like it to go fetch some data based on a parameter passed to the web page.
so http://myapp.com/?q=123 redirects to app store for app installation, once the app is opened it should go fetch data from something like http://myapp.com/data/123
Would it be possible to start a session on the web page and store the 123 there, and then make a call from the app to any page on the domain and retrieve the 123 from there?
As far as I know it is not possible to pass some value to the appstore that will then somehow be retained for the app when/if it is installed. What you will have to do is find some means of identifying the user or device both on your site and in the app. Anything from a username, email, facebook account will do. Anything like device ID and MAC addresses are pretty much off limits as well, if not impossible. I hope this helps, or maybe there is another solution out there that I do not know of.
I'd like to be able to send invitation in an email to a specific "event" happening inside my iOS app. So I figured I'd need to use custom URL. That's fine.
But I'd also like to be able to handle the user that doesn't have the app installed yet, to be taken to a mobile Safari and to the webpage with installation instructions for the app.
What would be the best way to do it?
I could try the following:
In the email I send a link to a http://www.example.com/joinevent/?id=foo
User is taken to a Safari webpage that sends a redirect to mycustomscheme://joinevent/?id=foo
If the user doesn't have the app installed this redirection won't work and he stays in the Safari - I could then handle the displaying of installation instructions probably.
But this approach doesn't seem "natural" for me. Is there a better/more native way to do it?
Try http://rdrct.it
It is a web service that allows you to achieve exactly this functionality very easily.
Full disclosure - I created rdrct.it
Here's the basics:
Login to the site, create a project for your particular app. Choose a unique code (this could be the name of your app).
You'll then be provided with a URL in the form: http://rdrct.it/uniqueCode
Once you've done that, you need to register the app's ID in the app store, and also details about the custom URL scheme. Tick "Auto-redirect" - what it will then do is try to open the app, and if that fails, it will automatically send the user to the app store.
If the app is opened, then the querystring is also passed to the app, so in your example case, the device will have been served: mycustomscheme://joinevent/?id=foo
It also works across multiple device types, so if you have the app available for Blackberry, Android or Windows Phone, then it will also do the same for those depending on which device type the user is using.
Like I said, I created it, but it should solve your problem.
If you are using Distimo to track you app analytics, they provide a shortlink to your apps that can be used also used to track conversions. It shows a custom page depending on the device used to access. This is especially convenient if you have the same app published in the AppStore, Google Play, Amazon, etc.
I'm building an app that uses OpenID for authentication. I'm giving Google, Yahoo and the general OpenID site as options.
At present, when the user selects a site, I open a UIWebView and the user performs their login with that frame, all within the app.
However, it has struck me that when using UIWebView, you cannot easily show to the user that the connection is over https or that they are indeed at the site I'm claiming they are at. I could be easily harvesting passwords.
Would it be, and I'm looking for opinions on this, be better from a user confidence perspective to actually open Safari when the user selects a login and once they've logged in have Safari direct me back to app?
Thanks
Most people using iOS devices are used to the way Facebook logins work; no URL bar, no nothing. I'd just follow the typical workflow. You could bump out to Safari, and return via a custom URL scheme. However, I think users will think that is more weird. iOS users are not used to being jumped in and out of different apps.
just my 2 cents, it would be also faster if the user has already logged in those services with Safari before.
Prompting out a UIWebView and switching to Safari is using the same amount of steps, so why not?
I thought I'd follow up on this thread to say I'm having difficulties getting the app approved and I think it's because I use the Safari approach. I've had it rejected by Apple twice now because:
"Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy" button that goes to a web site to purchase a digital book, will be rejected "
I think it's because I'm launching Safari. I've opened a dispute with Apple and I'll come back with more information once I hear back from them. I really hope a quick change to a UIWebView will help!
This is really just a "what-if" type question, so forgive me if it is either ridiculous or ridiculously easy...
I have a client whose site offers a "chat with a consultant" option that you see on many sales and support sites. We were wondering if there was a way that iPhone users (or any user, in theory, but mostly iPhone) could click this option and after giving the basic form info (name, question,etc) the actual chat itself could open up in the chat client.
Is this as simple as the "click here to send me an AIM message" syntax?
The XMPP (jabber) server is Openfire and the webchat uses the Fastpath plugin. Would this feature need to be enabled deeper than the page's HTML/PHP? Does the server/plugin need to modified as well?
Would this threaten the security of the XMPP server (which is behind a firewall and can only be accessed externally via the above plugin)?
Does this even sound like something that iPhone users would appreciate, or would it simply be confusing/obtrusive?
Sorry for the objective last question, but I'd hate to spend time on this only irritate users.
Referrals to resources and documentation welcome. I'm not looking for someone to walk me through the whole thing, I just want to get an idea of it can be done and where to start reading.
I'm a little confused by what you want to do - the user fills out a form on a web site and then they are put into a "chat room" on their iPhone?
This is possible. However all of them require that the user has already installed your app, so it may be a hurdle to what you are trying to do.
However if it's using a pre-existing chat service (such as AIM), you may already be OK if the user already has a chat client installed on their iPhone. You could launch the app using custom urls or push notifications - however, this is assuming that the app developer has enabled such hooks, and if so if they are published.
If you want to go with your own client, if the user is filling out the form on the iPhone, then on submission you could redirect them to a custom url for your application. From mobile Safari, this will directly launch your app. Note that the user must already have the app installed for this to work, or else they'll see an error, and it won't be a particularly user-friendly one.
Another way, if the user is filling out the form on their computer, is via push notification. Again, they must first have the app installed. They would receive a notification that, on acceptance, launches your app.
The final way, if the user is filling out the form on their computer, is that they would have to download your app first and run it, so that it could communicate with a desktop client of yours via network services.
I'm working on an iPhone app that ideally uses OAuth to communicate with Twitter. I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The problem is, Twitter has this whole scheme for working with desktop apps, using a pin number. When I register my app with Twitter, they have a web form asking me if I'm a desktop or web client. If I choose desktop client, when I try to have the user authorize, I can set the oauth_callback parameter but Twitter will ignore it after authorization and show a pin number. If, on twitter's form, I specify that I'm a web client, it requires me to enter a URL to redirect to after authorization. And, since I'm using an iPhone app-specific url scheme, their web form fails on validation as it only seems to accepts URLs conforming to the HTTP protocol.
So, it seems like I'm stuck - I can't say "desktop" because I don't want to bother with a pin, and I can't say "web" or I can't use an iPhone app URL. Any solution to this?
From your question:
I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The Pownce article suggests that quitting your application and opening Mobile Safari to perform the authentication step is problematic, and that they started receiving bad reviews from users for doing it that way. They also experienced a failure rate of around 40%.
Pownce's solution is to use a UIWebView within your application instead, so I have a feeling you may have misinterpreted their recommendations. That being said, they do label this as a "naive" solution and go on to suggest a bunch of theoretical "ideal" solutions.
Another point you might not realise is that desktop applications (using the "out of band" / pin number method) and web applications need to open the Twitter site in either an embedded or external browser.
So you've got two choices on the iPhone:
Open up twitter.com in a UIWebView, specifying no oauth_callback parameter or oauth_callback=oob to start the pin-based out-of-band flow. The user then needs to copy the pin using the iPhone's copy-paste functionality, manually close the UIWebView, and paste the pin into your application. The pin can then be used converted to an access token.
Do it how everyone else is doing it (UIWebView + custom-uri://foo.bar in the callback parameter).
For obvious reasons, the first option is pretty crap and really only useful on platforms where Twitter is unable to redirect to a custom URI.
A simple solution may be to create an HTTP page that always sends a 301 redirect to your custom URL scheme and then provide that HTTP URL to the twitter web API.
Aside from that, Nathan's answer is very complete.
Here's how I do it: tell Twitter you're a web app, and make up any old HTTP:// URL to satisfy Twitter during registration of your oauth client.
Then in your app, pass the URL you want to in the callback parameter. Twitter (in my experience) uses the one you give it.
You could use an intermediate website for the authentication. Your app creates a unique id (hardware based?) and stores it. It then records it has sent the user for authentication and sends the unique id to your website. It then redirects the user to your website. Your website then sends the user to Twitter using oAuth. The user returns to your website and you mark the unique id as authenticated and store the authentication information. The user restarts the app on the iPhone, it reads it has sent the user for authentication and contacts your website with the unique id - and reads in the authentication information.
Long winded and needs another website, but it should work.