I develop applications in AndroidStudio. For the first time in my life, I faced a problem - I was asked to make the application possible for use only within ONE country. I've thought all my life that this is configurable via the Google Play Console, but I've been told that it's not. Maybe someone knows how to implement such a restriction using a code only? Mb some changes in a gradle files?
You can use Locale to get the current country of users.
val locale = context.resources.configuration.locales.get(0).country
And you can make a request to a server to know users' countries.
For example, you can try: https://ipinfo.io/country
This is not an all-time work solution, but it's worth trying.
I am creating an android app and I need to get the EXACT date and time using android studio. There are many questions which have solutions to this, but I realised that all of them give the phone's time which can be edited by the user. I need the exact world-standard time.
Currently, the code I'm using is this:
DateFormat dfgmt = new java.text.SimpleDateFormat("yyyy-MM-dd kk:mm:ss");
dfgmt.setTimeZone(TimeZone.getTimeZone("GMT+8:00"));
String nowTime = dfgmt.format(new Date());
But this is giving me the time which is at times tweaked by the user. Anyone has a way to get the exact time?
There are few different approaches that you could follow, based on whether you have access to the internet and/or GPS, and whether you want this functionality to work offline.
As others have suggested, you could use an online service to get the official time. For example, TimezoneDB provides such a REST API.
If you need to access the time offline, read the time from the GPS provider, which returns the time in UTC format. Check Location.getTime().
Use a combination of an online service to get the time once and combine it with SystemClock.elapsedRealtime() to get the actual real time after that, even if the device is offline.
You could use an external service for this. You could set up a simple REST API or use someone else's (check this post which gives an example of one Free Rest API to get current time as string (timezone irrelevant)) to make HTTP requests and get the time irrelevant of what is set on the user's phone.
You can ask the time to a remote server.
This will grant you that the time is not setted manually by the user and is not influenced by the timezone.
Use a 3rd-party NTP client library to get current time from an NTP server.
E.g. Apache Commons Net has a class for that.
I have developed one j2ee web application and generated .war file of it.
I have to share this war file with clients.
My problem is:
I don't want to give .war file for permanent use. Instead of to give it for trial period let's say for 30 days, so that they can know the features of application.
How to give trial period logic.
If I write logic using DB, they can reinstall the whole war file after one month and everything will start working again.
Client can also change the timing of system and then my control will go off.
I cannot access internet from application because it will be deployed only on intranet.
Please help me in any possible way of achieving this.
Thanks in advance
You very probably cannot do this perfectly (ever heard about cracked games and rooted phones?).
So it's a matter of making it difficult enough for the user to bypass your license, so that they won't bother.
The basic, simple idea is:
- Create a license for each user using your private key, that will contain the license expiry date
- Check the license for validity in your application, using a corresponding public key (both integrity and expiry date)
This will make sure the user won't get another month by just reinstalling.
Second simple step would be to write the last seen system time each time you exit the application, then check the system time on startup to make sure user didn't set the clock back (beware of daylight savings time though!).
That might get you covered for the two basic tricks to bypass the trial period. For more motivated users, you'll then need to add in more checks.
I'm trying to find a solution to my problem, which is only applicable in our test environments. I'm working with systems
(banking) depending on each system being on the same specific date. The development we do is solely within system integrations.
In short: Our systems generate the data, which we then adapt between our systems. Naturally, we do not hold the source
codes to the systems we have.
To my specific problem: I have a system(A) running on JBoss: JBoss_4_2_3_GA on Java JRE build 1.6.0_32-b05. I've set up
a messaging broker in WebMethods(WM) listening to a specific port on this system. When users trigger certain events in system(A), JMS
topics are created and sent to a queue. WM then do a few validations and deliver the messages to system(B).
Everything was working properly, up until recently when we noticed that system(B) was expecting a timestamp field being
on the same date as the system itself were in (the functionality we built won’t otherwise work). The problem is that system(A) does not provide such a system date option,
and the timestamp in the messages are "real" timestamps from the operating system (Windows 2008 R2). So I require
a fake date (timestamp) applied in system(A) which would be on the same date as system(B).
The first solution to this problem was simply to disable the NTP sync and set a fake timestamp in Windows running
system(A), which would solve the date issue. But doing this, we noticed that our Windows group policies stopped working,
which affected normal logins to the server. So this was not a solution we could apply.
I know that others have posted this specific issue, and solutions such as using java date alternatives as Joda-Time etc.
I don't see how I can apply mentioned changes into my system(A) due to the lack of source code.
Help/suggestions would be greatfully appreciated. Right now I’m blindly focused into changing the timestamp in Java in system(A). Perhaps there are better alternatives such as just applying the fake date in WM? I just don’t know enough about WM to do this either.
Ok, I finally found a solution to my problem. Since the lack of source code, it was really a hard shot to do anything within the application (Java/JBoss). Searching arcoss forums, I found a nifty little tool (for Windows) called "RunAsDate". This tool does exactly what I need, as it intercepts the API calls to the OS related to dates and times and gives whatever date/timestamp the user chooses!
The best thing is that it doesn't make any changes to the system (dll's), and runs either from the simple GUI (in app package) or called from command line. Of course it will take arguments if required.
I hope others can find this as helpful as I do: http://www.nirsoft.net/utils/run_as_date.html
BR
/rash
I am getting the warning
Warning: sendmailpm.jsp modified in the future.
What does this mean?
You aren't allowed to modify anything in the past if doing so might change the future. You might cause a temporal paradox, which could corrupt the time stream and cause our entire reality to cease to exist.
Please do not modify that file.
JSP files are compiled. Many servers also allow you to replace the files on a running server. It then compares the timestamp of the compiled source and the timestamp of the jsp file to determine if it needs to recompile.
If the file is dated in the future, the jsp file will always be newer than the class. This gives you a warning.
Check the timestamp on the file. Perhaps someone created it on a computer with an incorrect clock, and now it appears to be "created in the future". Or perhaps the server has the incorrect date (check timezone settings).
Are there remote file servers involved? Clock drift between a web server and a file server can cause this error too.
To diagnose this further, you'd have to give us some hints - what jsp server, what OS, what filesystem?
During an Ant build, this warning can be output during a task.
[copy] Warning: foo\bar.txt modified in the future.
Ant's <copy> task by default won't copy files if the destination files are newer than the source. This saves much time and disk I/O. However you can override this behavior with the option <copy overwrite="true">. This tells Ant that you know what you're doing; overwrite the destination files regardless of their modification date. This will also suppress the warning.
If your code is residing on a FAT/FAT32 partition or ZIP file, this can be caused by the lack of precision in the FAT/ZIP filesystem's timestamping, which is 2 seconds (afaik). This can cause compiler / build tool output to be saved with a time slightly in the future, so that when the next build/deployment step (can be internal to a JSP container) is executed, the file will appear to be from the future and the warning is produced. Try using a different file system, e.g. NTFS on DOS/Windows boxes.
I had the same warning message from Apache Ant when trying to do a Java build on a FAT32 TrueCrypt partition. After ruling out other causes (timezone difference, clock off etc), I eventually found a hint on this, changed to an NTFS TrueCrypt partition and the warning disappeared.
Someone probably modified the file, then changed the time on the server. Try checking to see what time your box is set to and make sure it's correct. If it is, you can probably ignore that warning without any side effects.
Check whether system time is correct or not. If not sync it with Standard time for your zone. Then run your build file.
JSPs are compiled on-the-fly to servlets. The servlet container compares the "last modified" dates of both to see if the JSP has been changed and the servlet needs to be updated. A "last modified" date in the future indicates that something is wrong with the system clock, which is relevant because it could disrupt the abovementioned mechanism, leading to servlets that are not updated.
This is because, The time of the system is not current on which you are running the build file
If the java file that you are compiling has a time stamp that is beyond the current time of the system on which you are compiling...you will see this warning.
I modified the file on one machine and put it on another and tried compiling and came across this issue.
I got the same issue. The solution was: I changed the date and time on the build machine, so that it was in sync with the date and time on machine which the files were copied to.
If you have a jar file that you are trying to install at remote server. It might happen that remote server timestamp is not matching with your time zone. If your timezone is couple of hour ahead than the remote server then you might get this issue.
I also tried out one more trick..
When you create a JAR file, then go to system time and set a date couple of months back and try installing the JAR, you get this error.
I had this error too, but after reading some answers above i realized that is was due to the change i've done in the computer to some days ahead because of the test of a functionality that requires date manipulation.
Here is what happened:
1 - To perform Unit Test of a new implemented functionality i had to set the computer date to 4 days in the future.
2 - When i performed the test the compiler compiled the class automatically, as expected.
3 - Therefore when i was trying to rebuild the project the IDE detected that the file was (ironically) created in the future. (LoL - that's why i love Java you can even code in the future.).
So +1 #jmanning2k.
I hope it can help somebody facing this issue.
That warning appear to me too, it was because a previously changed the time in my computer to fix it because it was like 20 minutes ahead of the actual time