I am creating an app which can monitor elapsed time taken for a particular task. The times are taken from server and its working fine. But when I added offline feature , I take time from System.currentTimeMillis(); . There is problem ,if user change their phone time ,then they can easily cheat the elapsed time. Is there any other way I can fetch duration of particular task interval.Or How can I prevent this cheating? I already search stack overflow for a good answer. but can't find anything. Please help
You could start a thread to count the elapsed time yourself. Place counter inside a service, to prevent it closing with the app. If the service if closed by the device restarting or whatever, then it needs to go online to confirm the time again before continuing.
As long as the device is not restarted or the service being closed by system due to low resources, the user will be able to stay offline.
From what I have seen through my research you'll have to store the time, on a server would be better to prevent the user to change it by accessing your app's files.
I believe these two links can give you a lead on the idea.
Preventing time manipulation.
Changing time on device.
Related
I'm developing the app, which is supposed to be active all the time on the device (customer-specific app). The application isn't big, it doesn't use a lot of resources, but it works with scheduling (handlers, timers, AlarmService).
And it happens, that customer reports the device reboots by itself from time to time (once in a day or more rarely). I don't know the reason.
Unfortunately, I don't have any logs related to shutting down of the devices.
In "onCreate" method, I start logcat process and write all logs into a file, but there are nothing useful. Yes, I know, it's hard to find a reason without them. I'm trying to capture as much information as i can.
There are also 2 services, that runs every ±1hour, one pull the data from the git (JGit lib) and another sends some messages to the server. We also have logging for developers (write to a file), and we use only one instance of FileWriter (so we don't close it).
Could you suggest, what CAN possibly be the cause of rebooting? What is common mistakes in such apps? How can I find the reason of rebooting.
Yes, I know, I didn't provide enough information, but any advices would be really helpful for me.
Since your application using File and FileWriter which you are not closing. Please check the number of File Descriptor[FD] count. If FD count reached to 1024, System automatically restarts the APP to reset the count.
Sometimes Android just seems to restart when there is a lot of allocated memory, which not only has to do with the app but maybe with the whole system and environment. Try to delete all the cache from your storage and save free space, this may improve the R/W speed from disk.
I have java web applciation where we have a system with approvals and confirmations depending on the time period.
the steps of the process are.
user requests for an event to be fired at particular time.
user gets a approval or confirmation mail to be processed.
If user does not approval or confirm with in 5 days,then the system should Cancel the request automatically(a change in database status is enough for this) .
How can i track this kind of request continously ??
should i run any Job continously which takes of changing the status in database?
issue : this affects the performance of the system
If i run the system at specific intervals of time, then a cancellation may take some more time than what is expected. this should not happen strictly.
Could anyone give me right direction to handle this kind of cases?
this depends on how your system should work. Let me just outline two options. There are probably a lot more but you'll need to figure out yourself what you want:
You go with an internal scheduler for the actual user defines events. Then why not use the same scheduler for expiring unconfirmed events?
You use external scheduling. E.g. you decide to check every 5 Minutes if there are events to be fired. Then you might just run a cancelation job at the same time.
Dependig on your system there are a lot more parameters to check... this is just to give an idea.
In some games people can cheat by changing the time. For example: when they have to wait 30 minutes before a building is built.
Can i prevent this, assuming that the devices have connection with my server?
I am programming in java using the libGDX library.
Any solutions that work both on IOS and Android?
Store the time they have to wait to on the server (tell the server they perform a task, server will log that time and when they can do it again) and make the client check if the server thinks it can in fact perform the action. Anytime you store something on the client it is likely that there will be a way around it.
Your best bet would be to use SystemClock.elapsedRealtime() as an assistant to an infrequent server side timecheck.
return the time since the system was booted, and include deep sleep. This clock is guaranteed to be monotonic, and continues to tick even when the CPU is in power saving modes, so is the recommend basis for general purpose interval timing.
After verifying the time from your server, you can do local checks against SystemClock.elapsedRealtime until the next boot up.
In my Android app, I need a certain bit of code to execute every minute, whether the phone is active or not.
(For those curious, the app is meant for a personal project, a "talking" clock which will need to check every minute if that time has a corresponding sound file to play. It's not something I plan to release to the world, so battery considerations are not in play.)
My current approach is to use Timer.scheduleAtFixedRate() to schedule a task.
This seems to work whenever I am looking at the app, and interacting with it occasionally to keep the screen from blanking, but if the phone turns the screen off to save power, it seems like my call happens sporadically.
I tried setting the interval to be every 30 seconds, but even then it seems like I miss some minutes. Are there specific considerations to using Timer on Android? Is there a better way to achieve what I need?
Question: are you 100% absolutely sure you need to be doing this every minute? It just sounds to me that you'll be hogging the battery like crazy and will get quite a few unhappy users.
But if you answer yes to that question:
After your activity is paused, there's not guarantee from the system that anything on it (including your task) will be kept running; that way as soon as the systems needs a couple of megabytes to do anything it will kill your activity and stop your timer.
You should implement the timer/task in a Service. Services are much less likely to be killed by the system and you might ask that if the system needs to kill it to re-created it as soon as possible.
Have you tried using AlarmManager, this will let you do a task every X amount of time even if the phone is in standby mode or off
Here are the docs for it
If you want a nice example of using an AlarmManager, here it is... This one does not work if the phone is turned off but you can enable this easily if you want
I'm planning on hosting a JRuby on Rails app on Google AppEngine/Java. I found a great blog post by Ola Bini on how to to this, but in the summary he says:
Overall, JRuby on Rails works very
well on the App Engine, except for
some smaller details. The major ones
are the startup cost and testing. As
it happens, you can’t actually get
GAE/J to precreate things. Instead
you’ll have to let the first release
take the hit of this. Now, GAE/J does
a let of preverifying of bytecodes and
so on, so startup is a bit more heavy
than on other JDKs. One runtime takes
about 20 seconds wall time to startup,
so the first hit takes some time.
I don't fully understand this. How often, under what circumstances, will a runtime need to be started up? A regular 20 second lag is likely to be an issue.
App Engine will start new runtimes for you whenever demand is outstripping the currently running instances. It will then shut down instances when demand is lower. Ultimately, this means that all of your instances could be shut down if your app is not used for a certain amount of time. Then, the next time a user tries to access your app, a new instance will need to be started, or "spun up" as some people call it.
As of March, the app engine team wouldn't give any official estimate on how long an instance will stay up:
7:40pm] nwinter: Is it possible to get a rough estimate of how long an app
instance will stick around once spawned?
[7:40pm] marzia_google: #nwinter, not really
[7:40pm] marzia_google: there are no garuntees
[7:41pm] nwinter: No average time or anything?
[7:42pm] marzia_google: #nwinter i'm not sure an average time would be
meaningful, even if i knew off hand what it was ( i don't)
[7:42pm] marzia_google: since it really can be quite variable
[7:42pm] Kardax: Re instance lifetime: So an app instance could last a few
seconds or a few hours? Just curious
[7:43pm] dan_google: nwinter: Apps are evicted by least-recently-used on an
app server. As someone noted recently (forums or chat I forget), low
traffic could mean lots of "restarts", but so could spikes in traffic which
may start new instances on multiple app servers.
[7:43pm] nwinter: #dan_google: good to know!
[7:43pm] dan_google: Kardax: Yes, depending on the weather. By which I
mean, request patterns, other apps on each app server, and so forth. Not
really predictable.
This is the transcript of a chat with the app engine team. I have deleted the non-relevant lines in the transcript like "so and so logged in." The full transcript can be found here