I am developing a Facebook WEB application and I want to know who is currently on line.
How can I detect when a user leave/close my application to change the user flag to offline.
I assume by leave/close your application you mean navigate to a different webpage or close the browser?
The simplest way to achieve this, would be to periodically send a poll back to your webserver using an ajax connection and a javascript timer.
When a user disconnects from your app by closing the browser or changing webpage, the polling would stop happening.
A script running on your server would periodically check the timestamps of the polls of 'online' users, and if it finds one that's no longer up to date, mark the user as offline.
The wikipedia page on Comet (programming) is probably a good place to start
http://en.wikipedia.org/wiki/Comet_(programming)
I wanted to know how facebook chat works when any user closes the browser without loggingout.
How does FB know that window is closed and send the message to the inbox and do not attempt to show the ping?
Facebook / GTalk and any other online chat client usually uses a 'ping' or check to see if the user is still online / using the window. You can do this easily by firing off a Ajax call in the background every 1-2 minutes.
Every time the ajax call is made, update the last_seen time in your database. If the date / time exceeds 1-2 minutes (as per your ajax call), you know the user has closed the browser or lost their connection.
I want check how to know user is using my application facebook
Example: One user go to application page, i set user online, when user close application page, i set user offline
Thanks.
If you haven't heard from a user for some time, chances are that he closed a page with your app.
Memorize last time a user did anything in your app, and set a timeout. If N minutes later there are no new actions, you mark him offline.
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.
Right now I am developing a Web-based Application, where the User has to login first.
When I open the Page by iPhone Safari, login and restart Safari, I am still logged in (Cookie & Session ID still set).
But when I add this Page with "Add to Home Screen", each Time i click the Icon for that page, I have to login again.
I did not find any information about that. What can I do so my users can set this page to their home screen
as icon and still don't have to login each time they open it?
A really simple approach could be to use a unique token in your Bookmark-URL which can serve you as a unique device identifier.
Example:
http://myWebApp.com/?token=randomId29238/1
The token can be generated at the server side at opening time of the application in Mobile Safari and before the user is prompted with the "Add to Home Screen" information.
The token can then be added to the URL using a quick redirect (…&token=randomToken) or a location hash (…#randomToken).
Whenever the Bookmark is now opened from the Home Screen, the token is sent to your server and you can identify the user's active session.
You may also use the token as a permanent session id, but I advise against that because of security concerns.
To allow future logout and login procedures, you can always assign the new sessions to the token.
The token will serve you as a unique device identifier whenever the user will re-open your link from his Home Screen.
There is an easier and, imo, more elegant solution than favo's.
At least under iOS 4.2.1, 5.1.1, 6.0 and 6.1 (I couldn't test other versions), if you extend the lifetime of your session cookie manually, Safari will hold on to the session cookie and even allow sharing of the session between the 'home screen installed' version of your web app and normal visits through Safari itself.
The trick is to do this:
// Start or resume session
session_start();
// Extend cookie life time by an amount of your liking
$cookieLifetime = 365 * 24 * 60 * 60; // A year in seconds
setcookie(session_name(),session_id(),time()+$cookieLifetime);
For a more elaborate discussion of this strategy you can take a look at my answer of this question:
Maintain PHP Session in web app on iPhone
I am going to expand a little further on Waldo Baggins' answer.
When I ran into this, I discovered the reason this was happening is that session cookies set on the server usually do not have an expiration value set. The default behavior in this case is for the browser to discard the cookie when the browser is closed / re-opened. Since the browser does not resend the cookie on re-opening, the server has no way of identifying the session, even if it hasn't expired on the server yet, and thus, your user is redirected back to the login page.
When the user is using your site in web app mode (icon added to home screen), iOS treats navigating to / from the app the same way a desktop computer would treat closing and reopening the browser, and loses the session when reopened.
So following Wilbo's suggestion and setting an expiration time for the cookie, iOS checks if the cookie has expired when the user navigates back to your app, and if it hasn't, re-sends the cookie, thus maintaining the session. The value of 1 year in Wilbo's answer is ridiculously long, you would typically want to set this to something like 8 or 24 hours, and ideally sync it with the session expiry timeout value you have set on the server.
Note that as a side effect, when your site is accessed from a desktop browser, and the user closes and re-opens the browser, the session would continue to persist and the user will still be logged in, which wouldn't have been the case previously (unless they were browsing privately). Your "Logout" feature would have to properly handle expiring this cookie.
For a Java webapp using web.xml version 3.0 or higher, the easiest way to do this is to modify <session-config> as follows:
<session-config>
<session-timeout>600</session-timeout> <!-- In minutes -->
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
<max-age>36000</max-age> <!-- In seconds -->
</cookie-config>
</session-config>
There are persistent key-value storage and database storage available for web apps. You can save your authentication data using localStorage object and use XMLHttpRequest to send it to the server.
Another option is saving your persistent data in a SQLite database, however this doesn’t seem to be a proper solution in your case.
Check out Apple’s Client-Side Storage and Offline Applications Programming Guide for details/examples.