I have built a react native app/game where a user has 30 mins to finish a task....when they start task, the 30 mins starts to countdown and it is registered in DB (Firebase) that user is "in play". When they complete task (or 30 mins run out) then DB is again updated to "not in play".
Countdown function is operating on phone and not on server.
Problem is that if the user exits the app, then the counter on the phone ceases (the user is no longer "in play") but the DB does not know about it.....there appears to be no "user has exited app" event/handler that I can use to let DB know that user has quit.
I was thinking maybe the countdown logic should be running on backend but I cant think how.....any ideas?
Currently there is no way to handle app terminated in React Native so I think your best shot is to implement it on the backend.
How about when the user starts, you save the time the user started, and if the time difference between now and when the countdown was started surpasses 30 minutes the user is no longer "in play".
One way to detect that the user has left the game would be with Firebase's onDisconnect handler. With this call you register a write operation on the database that is executed when the server detects that the client is gone.
The server can detect this in two ways:
If the client disconnects cleanly, it sends a message to the server that it is disconnecting and the server runs the disconnect handlers for that client straight away.
If the client disconnects in another way, the server will detect that the client is gone when the socket times out, which may take a few minutes.
So in your case you could use an onDisconnect handler to either remove the player from the game, or otherwise mark them as "gone".
The only problem with this approach is that dirty disconnects may take a few minutes, which might be too long for your scenario.
An alternative would be to have the client write a message into the database periodically to signify that it's still here, e.g. a lastUpdated timestamp.
You can then in any code that reads the data use that timestamp to detect if the player was still recently playing, and consider them "gone" after a certain period that works well for your game. This code can then remove the player from the database.
This code can run in a server-side component if you want, but I've in the past also run this type of code in the client and then used (server-side) security rules to ensure it can only remove users that are "gone".
Related
I've been able to set an application badge number to my iPhone app and updating it once the user interacts with my app:
[[UIApplication sharedApplication ] setApplicationIconBadgeNumber:currNrOfNotif];
What I wont though, is for this process to occur while in background mode, ie from within applicationDidEnterBackground or similar. I would like this process to be scheduled to run daily, every night at 00:00 00:00 and take the current number in setApplicationIconBadgeNumber and decrement it by -1. No need for push notifications (or any server kind) in other words as the only thing that will happen is a change of the badge number value.
First of all, how do I schedule an activity to occur while app's in background mode, without using remote server push notifications?
Secondly, how do I get or fetch the current application notification badge value and decrement it by one?
In this post, some people argue it simply can't be done even with local notifications and that server side push's required. One person, however, states it can be done by scheduling it by midnight. Who's right, and can someone please propose a solution to this?
HelloA Windows Phone application need to connect to a server and get messages from it. This is done using WCF and long polling on the server. 3 minutes is the timeout defined on the server. Call from windows phone is done using HttpWebRequest.
The problem is that Windows Phone devices have a timeout of 60 seconds for get request (emulator have a different value, greater than 3 minutes).
Currently i can't decrease server timeout. Doing a new GetRequest after the 60 seconds doesn't get anymore messages.
Does anyone have an idea ?
Thanks
I don't think leaving a connection open is a good idea on mobile devices. I'm assuming that's what you're doing. In my app, I would just poll whenever needed by creating a new HttpWebRequest. But it made sense to do this in my app, because I would be updating train arrival status every 40 seconds.
If you're trying to pull data on a given schedule, put a timer in and just call the webserver every 3 minutes or whatever the requirement is.
If you want to be able to check things (when the app is closed) or if there's rarely fresh data on the server, then you'd need to implement a Push mechanism.
Update: Here's a good article on dealing with the timeout issue - http://blog.xyzzer.me/2011/03/10/real-time-client-server-communication-on-windows-phone-with-long-polling/
Update 2: What if you arranged it so that, you have cascading connections - what I mean is since you can't go beyond 60 seconds per connection, you can write a class that'll house two connections and once one of them is about to timeout, say several seconds before, you can start opening the other connection - you can pick the timing so that there's at most 5 seconds of overlap between them. This way you could have your always open connection.
Also see what these guys have done with the GChat app, they have their source code available at this link. This may provide a more proper design.
I have created a web-service app and i want to populate my view controllers according to the response i fetch(via GET) in main thread. But i want to create a scheduled timer which will go and control my server, if there becomes any difference(let's say if the count of an array has changed) i will create a local notification. As far as i read from here and some google results, i cant run my app in background more then ten minutes expect from some special situations(Audio, Vo-IP, GPS).. But i need to control the server at least one per minute.. Can anyone offer some idea-or link please?
EDIT
I will not sell the app in store, just for a local area network. Let's say, from the server i will send some text messages to the users and if a new message comes, the count of messages array will increment, in this situation i will create a notification. I need to keep this 'controlling' routing alive forever, whether in foreground or background. Does GCD give such a solution do anyone have any idea?
Just simply play a mute audio file in loop in the background, OR, ping the user's location in the background. Yes, that will drain the battery a bit, but it's a simple hack for in-home applications. Just remember to enable the background types in your Info.plist!
Note: "[...] I fetch (via GET) in main thread." This is not a good approach. You should never fetch any network resources on the main thread. Why? Because your GUI, which is maintained by the main thread, will become unresponsive whenever a fetch isn't instantaneous. Any lag spike on the network results in a less than desirable user experience.
Answer: Aside from the listed special situations, you can't run background apps. The way I see it:
Don't put the app in the background. (crappy solution)
Try putting another "entity" between the app and the "server". I don't know why you "need to control the server at least one per minute" but perhaps you can delegate this "control" to another process outside the device?
.
iOS app -> some form of proxy server -> server which requires
"babysitting" every minute.
Im working on a silverlight application where a user can create, edit, delete objects. The changes they make are placed in a queue which is processed every 4 minutes. When it is processed, the updates are sent over an async web method call to be saved in a sql database, one at a time. When the first update finishes, the next starts.
Im having a problem when a user makes a change and then exits the browser app before the 4 minute timer has expired. Currently the changes are getting lost.
Ive built on what the guy working on this before me has done, and explored the Dispose and Finalize methods, trying to start the update process when the factory is being shut down, but that isnt working due to the async nature of the web service calls. I get errors saying needed objects have already been disposed of.
Im looking for a way to save the data in the updatequeue using a webmethod when the user tries to close or refresh the webpage. Im not expecting the queue to be packed full with updates. This is an application that would usually be run for several hours at a time.
You can use Javascript to stop the user leaving the page. StackOverflow does it (try editing an answer and leaving the page). That works on browser close as well as page navigation. From Javascript you can also notify the Silverlight app to save any queued data (Silverlight support exposing methods to Javascript).
Q. Saving every 4 minutes is slightly odd behaviour for a Silverlight App. I am guessing it is only deigned to be run by one user at a time. What restricts you from saving more frequently?
Good morning. I have an application that queries a REST source. It needs to run continuously, capturing data which is refreshed every five minutes, without fail. My solution is Task Scheduler, where the app is set to launch on server boot. Once launched, it uses a timer to re-query periodically. The TS task is set to repeat every five minutes, with the check box "if app is already running, do not start another instance," so if the app crashes it should restart automatically within five minutes.
This works fine, but TS launches the app invisibly. I'd feel warmer and fuzzier inside if I could see the app, just as if I'd launched it myself. Also, if I need to close it (e.g., to post a new exe), I have to kill it via Task Manager; ouch. I've gone over the TS options a dozen times for some kind of "launch in foreground" option, but none exists. Can anyone tell me what I'm missing?
Notes:
From my web searches, it's clear that an app is only allowed to interact with the desktop if it's running under the same user account... but it is, I'm using my AD account, not SYSTEM or another local account.
It's acceptable for the app to only be visible to me, though even better would be if other users could also see and interact with it. I suppose the only way that would work would be if each user had their own monitor app which just reflected results exposed from a single invisible app which actually did the work.
I get the same behavior if I start the TS task manually or if it launches on boot automatically.
"Run only when the user is logged on" won't do, as I need it to resume even if the server restarts in the middle of the night.
I had been launching the app with a little PS script, so I could send a notification if the app failed to launch at all, but there's no change if I have TS launch it directly.
I suppose the proper solution would be to write this as a service. I put some time into that, but I haven't done that before and couldn't get it running. If the consensus is that that would be a better approach, I'll give it another try.
Any ideas? Thanks!
If you set the task to "run only when user is logged in" then it will be visible for you if you uncheck the "hidden" box.
If you have the "Run whetever user is logged on or not" choice checked, then it will be hidden even if you uncheck the "hidden" box. The implementation of Task Scheduler doesn't allow you to run programs in the foreground if you aren't logged in.
To solve this you can create a user that does AutoAdminLogon and start the application with the Startup script. By doing it this way, you will make the server log in with this user on boot and start the program you want.
If you then want to check how it's going or so, you can login as that user or switch to that session.