I'm trying to understand this concept but I don't get it yet. I'm new to mobile connections.
How do mobile apps and/or clients connect to the internet, if they do? if not, then, how do they serve real time data from remote servers (like twitter, fb) etc..?
I've heard that mobile apps don't require internet connection but I'm confused because I don't know how they get the data from the servers of twitter or fb or any application.
For example m.facebook.com is a site so it'll only work with some type of connection on a mobile, but with the app.. what happends (how do all of a sudden you don't need internet connection to serve the data from their servers)????
Think of a Web browser. It's an app that issues HTTP requests over the 'Net and interprets the response by rendering HTML and images, running scripts, etc. Now, there's nothing magical about the browser; it's just a program with HTTP capability.
Any other app can do the same. Except it does not have to interpret the response like the browser does. An app can just as easily issue HTTP requests and do stuff to responses. That's how Facebook, Twitter etc. client work. They normally work, however, not with user-facing parts of the target site, but with software-facing bits (called "The API").
Not all mobile apps require or use the Internet. Most games, for example, don't. But the apps that interact with websites, like Facebook, do.
Related
I'm working on a mobile app, and it makes use of a server as a middle-man for various reasons. Since the mobile app never interfaces directly with facebook, the server handles all auth. (It is in Python.) Here's the flow:
The app asks for an auth URL, and the server sends it "https://www.facebook.com/dialog/oauth" with the appropriate parameters.
The app sends the user to the page, they navigate etc. and get to the code...
...which they copy back to the app, which sends it to the server for authentication. (I'm going to factor this step out eventually.
The problem is that that particular URL juts looks dreadful on the iPhone. I've tried to find a mobile version (there must be one, right?) but nothing has come up.
Have you tried requesting "https://graph.facebook.com/oauth/authorize"? You can add "&display=touch" to force the mobile version.
I'm building a mobile version of my site for smart-phones
(iPhone/Blackberry/Android/WebOS)
and I want to redirect to the mobile version from my main site whenever the user agent is of one of the kinds listed above (my mobile site is on a different url than my Desktop site).
My mobile version is more like a WebApp and does not contain the same content as the Desktop site.
After reading This Post by Google I understand that the Googlebot expects smartphones to display the Desktop version of the site (Googlebot-Mobile is not used for smartphones)
I'm afraid that if I redirect to the mobile version for smartphones, Google will give me penalty for cloaking, How can I avoid this?
I know that including a link from the main site to the mobile version and vice versa helps a lot.
Any other advice/best practices on how to be google friendly when creating mobile versions of the site for smartphones?
From the article:
For Googlebot and Googlebot-Mobile, it does not matter what the URL structure is as long as it returns exactly what a user sees too.
The key thing is you must be consistent in the content you give to the bot and the one you serve to the user.
Another interesting excerpt from the article:
For now, we expect smartphones to handle desktop experience content so there is no real need for mobile-specific effort from webmasters. However, for many websites it may still make sense for the content to be formatted differently for smartphones, and the decision to do so should be based on how you can best serve your users.
You can also serve a different page/content/styling based on the UA string, as stated in the article:
If you serve all types of content from www.example.com, i.e. serving desktop-optimized content or mobile-optimized content from the same URL depending on the User-agent, this will also lead to correct crawling by Googlebot and Googlebot-Mobile. This is not considered cloaking by Google.
I think it all boils down how different the content/styling is. If it's only slightly different, I would probably go with the same url serving both. If it's dramatically different, I would use a different url for smartphones.
Hope this helps!
Updating this with current information. Google now crawls with a smartphone Googlebot-Mobile user agent. See: Google blog post
Google's SEO PDF explains how to avoid cloaking penalties. Specifically, see Page 27. See: SEO PDF
The gist is, the content you serve a desktop user can be different from the content you serve a mobile user, as long as Googlebot is always served the same content you serve to any desktop user, and Googlebot-Mobile is always served the same content you serve to any mobile user. To abide by this, it seems to me you should not configure your site to serve mobile content based on finding "Googlebot-Mobile" in the user agent. The bot will supply a typical smartphone user agent string as part of it's own user agent--that's the part to rely on, or else if a new device comes out that you do not yet account for, you'll serve desktop content to it, but mobile content to Googlebot-Mobile impersonating that device.
You could use subdomain for your mobile site and redirect google mobile bot there together with smartphones
For a middleware system with internet (which works inside a set-top box) I want to develop a primitive Facebook interface where users can type their user-names and password, showing their latest notification, messages and other casual stuff on the TV screen by using the recent Facebook Graph API.
This middleware program uses Java ME to run programs (such as this simple facebook app) and it can connect to internet however it doesn't have a real web browser. Without browser it can connect to any url to retrieve the JSON response however I am not sure how to achieve authentication without a real browser.
Under this circumstances, is it possible Facebook authentication? If you think so, what approach would you suggest ?
Thanks
Facebook provides trusted partners with a private Authorization API to get an OAuth 2 token from a username / password.
A more complicated approach would be doing something similar to how Netflix enrolls a device:
device calls server to obtain a Code
device shows code on screen and directs user to go to URL on server and enter Code
server redirects user to Facebook and obtains OAuth token, user told to go back to device
device calls server with Code and obtains OAuth token
device can now make calls directly on behalf of user
According to this documentation on "Desktop Application Authentication" I don't believe your desired result is possible:
Facebook's OAuth implementation does not include explicit desktop application support. However, if your desktop application can embed a Web browser, you can add Facebook support to your application easily using the same OAuth User-Agent Flow used by JavaScript clients.
However, it is clearly possible for certain vendors to do this, since Microsoft's Xbox 360 Facebook application does exactly what you are proposing. I'd be interested to see if anyone has dug up any API for doing this that Facebook doesn't want in their most obvious documentation.
This isn't an answer but I'm trying to do the same thing. Check out this guy's blog which uses another server to proxy the requests:
cory wiles blog
If you figure it out please post a detailed answer here so I can do it to.. :)
I think it is possible though it is pretty complicated and subject to sudden changes of Facebook interface. It might break the agreement between you and Facebook.
What you do is to emulate the Facebook.
One path you have to set up a Facebook application. Once you got the authorisation from user, you can to something with Graph API.
You need to the Facebook log-in process and authorisation process. There are some capturing tools on http/https request and response. Analyse them, both header and body.
Once you know the authorisation mechanism, you can replace it with you own. Everything afterward is on Graph API.
Another path is to emulate Facebook login and message and notification process. Capturing and analysis is needed.
In the past I have used a tool called screen-scraper (full disclosure: I used to work there) to automate logging in to facebook. Basically, it imitates a browser session; it allows you to set session variables (i.e. username, password) which would then be submitted to facebook, just as if the user had submitted them in a browser.
You may not be able to use screen-scraper in your set-top box environment (although it is java-based, so it's possible it would work). Even if it doesn't, you could implement a similar strategy in java, making the HTTP calls a browser would make to load the login page and submit the user's credentials. To keep the user's info safe make sure whatever HTTP client library you use supports HTTPS.
Proxy tools and extensions like Charles, Fiddler2, Firebug, Chrome's dev tools, etc. are helpful in seeing exactly what the browser is sending to the server in requests.
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.
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.