How are application idle settings configured for Worklight 6.2 Hybrid applications?
We are developing a hybrid app for Android 4.1.x with JQuery and would like to return the user to the login page after a period of inactivity...
Is there any in built capability in the framework we should be looking to make use of for this?
There is no built-in idle functionality. You will need to implement a custom one.
One way to achieve this would be to base your custom implementation on counting against the Worklight Server session timeout.
The session timeout is defined in your-project\server\conf\worklight.properties.
What you could do is:
Upon a successful WL.Client.connect(), you will start counting for the same amount as set for the session timeout
For every server action (adapter request...), reset the counting
If the counting expired (or reaches, say, 5-10 seconds before), logout from the realm and display the login form
I don't think it would be good to count for "general" idle time in the app, since you'll need to account for both the session timeout And whichever "activity" timeout you will set, which will have to be Lower than the session timeout. its just more scenarios to take care of...
Edit: actually I have another idea - use the API for heartbeat in Worklight to keep the connection to the server active, and count for whichever activity timeout you would like for the app... If it expires, logout from the realm and display the login form.
You can also do it without pinging the server, with Jquery by attaching the mouse and key listeners to document or body.
Something like this code: (not tested)
var idleTime = 30*1000; //30 seconds
var idleTimer = null;
$(document.body).bind('mousemove,keydown,click',function(){
clearTimeout(idleTimer);
idleTimer = setTimeout(isIdle,idleTime);
});
function isIdle(){
clearTimeout(idleTimer);
//logout and go to login form
}
Another option which maybe a better UX (depending on your specific needs) is to capture the screen turn-off/turn-on natively on device.
Related
I am developing an application for a client and I would like a usage timeout. For example, the user installs the app and after 3 hours it can no longer use. What would be the best way to do this?
I could do it in the most basic way, recording a time flag to check every time the app loads, but how do I prevent the user from uninstalling and reinstalling the app and can use it again?
Can I record a global variable on Android?
After user first time installs the app you can get unique UUID for that device using for example Ionic Native Device plugin and send it to your database along with timestamp.
import { Device } from '#ionic-native/device';
constructor(private device: Device) { }
...
console.log('Device UUID is: ' + this.device.uuid);
After that, it's enough at some time intervals or every time an API is called, compare that time in the database with current time and if more than three hours have passed prohibit calling all APIs from device with that UUID. The application will, in that case, become unusable.
Of course, you can always allow a particular user (UUID) to use it for a long time.
I have an mobile application (iOS and Android) and I need send some notification from my server to these, then the mobile app need to make some tasks and when they finish, send a message from mobile to server to confirm. I have thought using Push Notification, but the problem is if the user disable this feature, the app will never receive this notification. Anyone know some direct communication server-app but keeping security?
You may try the long polling technique. But it will drain your battery very fast, so be careful. The main idea is that you set connectionTimeout to a very very long time (30 mins for example) and when not closing that connection until the server says there is something. After receiving an answer or timeout, just reopen it.
Another approach is to make some method like getJobStatus on the server, assign a unique id for your job and ask the server if it's complete every N minutes for example.
When trying to synchronise the client with the server, we usually need to combine both push and pull.
Something you can think of:
The server provides an API that allows the client to get the latest updates.
On the client side, when the app is active, use a timer to try fetching updates every N minutes.
When the app is in the background, use a background fetch to try fetching updates. In this case, the user doesn't care about if the task is done instantly, because his is not using it.
Call the getUpdates when the app becomes active from the background, to make sure handle the updates when the user starts to use it.
I'm creating mobile application for iOS and Android. The problem is when any data has changed on server, I cannot notify mobile devices.
I have found 3 solutions, each have minus and pluses.
Use push notifications. Since iOS always shows a notification to user this is not a solution at all. Also I cannot know if the notification will go to device or when it will.
For every X seconds ask server if any change exists. I don't want to do that, because creating too many HTTP connections and closing them is not a good idea I think. Also if the data is changed right after the device asks, the info change on device will occur late.
Use web socket. My application's one time usage expectation is ~2 minutes. So web socket looks like a good choice, because app will be terminated or go to background state quickly and battery consume won't be much. Also all the server side data changes will come to the device just in time. But I don't know much about web socket. Is my opinion acceptable? Also how many concurrent connections can be done by my server. Is it a question too.
Here are my all solutions.
The document would suggest assumption 1. above is incorrect.
If you read the The Notification Payload section, you'll come across this;
The aps dictionary can also contain the content-available property. The content-available property with a value of 1 lets the remote notification act as a “silent” notification. When a silent notification arrives, iOS wakes up your app in the background so that you can get new data from your server or do background information processing. Users aren’t told about the new or changed information that results from a silent notification, but they can find out about it the next time they open your app.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
I think for the most part this depends on what your app is doing.
I would say you should use a combination of #1 and #2.
2 - At the very base level if you need information from the server you are going to have to make a request. If this information needs to be up to date then you can proceed to make a request for the information when the ViewController is loaded. If you need this information to update as the ViewController is loaded then you will need to make subsequent requests every X seconds... In addition to this if your user is interacting with this data and sending an update to the server you can check at this point if the data is up to date and alert the user as well as return the current data.
1 - Push Notifications operate off of the 'send and forget' protocol. The notification is sent and is not verified if it is received or not. This is used as a supplement to #2 and is 'nice' but should not be depended upon.
Push notification is the intended way (from both Google through Google Cloud Messaging, and Apple through Apple Push Notification Service).
Both option 2 and 3 are frowned upon as they affect battery life, and they are unnecessary as most cases scenarios can be covered by push notifications.
I am working with one game which is basically a location based game. The duration of game is 5 mins. Everything is working fine. But the problem is on one device game is starting before the game is started on the other device.
Suppose User A has sent request, user b has accepted the request. then only game screen should appear. But in my case its not happening.
Can anybody help me to give me the logic to start the game between two devices at the same time without a second delay. I am using web service for sending the game requests.
Thanks
Just a thought:
You might use some sort of Mutex on the server side that tries to determine if both clients are ready.
This is assuming the game is run on a server as you described, and not peer to peer.
Hope this helps!
Maybe user B starts when the he accepts but user A hasn't actually received the response yet...or something in that scenario.
How about when user B accepts, take the time (server time to ensure same time) and start around X (10 or 15) seconds after? then send that time (time, not duration) to user A as well. In this case, both user A and user B will just be waiting for the appointed time and then start at the same time? Just an idea, implementation is all up to you :)
I have an android app that I'm building and it's based on a web app that lets users login and reserve a book (think library). Because you are able to reserve books it needs to have a valid session (cookie to be exact)
Here is my issue - how can I work with multitasking when I have this 20 minute constraint?
Do I keep a timer running the entire time the app is up (in the Application global object) -then on resume verify this timer is under the 20 min window and if so assume cookie is good - else ask them to login again.
Or do I blow away the activities loaded (in my app) on resume and start the app over each time the user clicks the icon from the home screen
Or something else? I simply avoided this in my iPhone version because I don't support multitasking currently (maybe I will if the android solution fits)
Thank you in advance!
Normally people handle this problem by assuming any cookie they have is valid and letting the server tell them if they need to login again. The client should have very little (read: none, if possible) intelligence about this aspect which they cannot control.
You have several options, and which one's the best will depend on the app specifics
You can set up a timer to log out after 20 mins, either as part of your Application or as a part of your Activity (although in the latter approach, it will be lost if the activity is restarted).
Can set an Alarm to fire an Intent to show the login screen after 20 min (if you want to force a re-log in) or to set a flag LOGGED_IN=false if not.
You can set a long field in your Application object and query it during onDraw(), or while fetching a new page, or whenever you deem fit: if it's past the 20 min point, logout.
If the app will be fetching the book from a server one page at a time or similar, then I would add a time token to the POST request and let the server decide whether to return the page or to send a 401 error. You would then handle the error by showing the log in screen and reposting if log in is successful