Develop Reference

Which one is the best way to get timestamp in android in long format? [duplicate]

This question already has answers here:
System.currentTimeMillis() vs. new Date() vs. Calendar.getInstance().getTime()
(8 answers)
Closed 3 years ago.
I searched a lot I found some solutions for that and got confused to select which method to use to get a timestamp in android and which one is the best.
found
Get by using the android Calendar
Calendar.getInstance().getTimeInMillis()
By using the Date
new Date().getTime()
By using System
Long tsLong = System.currentTimeMillis()/1000;
String ts = tsLong.toString();
Please help me to understand.

System.currentTimeMillis() is obviously the most efficient since it does not even create an object, but new Date() is really just a thin wrapper about a long, so it is not far behind. Calendar, on the other hand, is relatively slow and very complex, since it has to deal with the considerable complexity and all the oddities that are inherent to dates and times (leap years, daylight savings, timezones, etc.).
It's generally a good idea to deal only with long timestamps or Date objects within your application, and only use Calendar when you actually need to perform date/time calculations or to format dates for displaying them to the user. If you have to do a lot of this, using Joda Time is probably a good idea, for the cleaner interface and better performance.
for full discussion please check the link

SQLite Database vs. File based Data storage from Battery Performance Impact perspective

I have an app runs in a background service all the time (only when screen is on), and on a regular intervals (1-10 minutes) records a how long the interval time was and whether it was a good or bad interval. At the end of each day I take these counts of good and bad intervals and record it to a csv file.
For visual people like me:
<--------------------------THE DAY --------------------->
minutes: 2m 1m 5m 3m 3m 3m 3m 1m 2m 1m 1m
|----|---|-------|-----|-----|-----|-----|--|----|---|---|
rec rec rec rec rec rec rec rec rec rec rec
Record
Currently I use SharedPreferences to store the good/bad count throughout the day, and write it to a file at the end of the day, but am becoming increasingly worried about the persistence of the SharedPrefs data (I've had a few cases of it being wiped randomly by what I think was the OS clearing my apps cache)
I'm attempting to decide between recording these temporary counts in a File vs. migrating completely over to an SQLite database structure and making consistent calls to write and read throughout the day.
From a battery performance perspective, which is the least costly for making multiple writing and reading calls a day (~500-5000 actions) and Why?

SQLite database == file based data storage
A SQLite database is just a mere file stored on disk, the performance difference will be minimal, the only thing a SQLite database does more is executing a little more instructions on the CPU to eventually get the data written.
The only reason why I wouldn't choose for a SQLite database is because maybe it's a little bit of overkill on the setup side since you're only writing numbers. What you could do instead is write a file yourself to the storage/sdcard and keep appending numbers to the file separated by newlines or some other CSV format.

Looks like file based approach will be better than sqlite, but it depends how you are handling files
SQLite itself store data on a db file. It will have its own db
management cost but very tiny
every time app insert or fetch data, it will have to open db, this
will be a cost itself. If app keeping it open, that is also costly
There will be less android API layer to update file directly than sq lite
Apart from all these facts, testing such a scenario should not be a problem. I will be writing a test case like this
Have a constant battery level i.e. 100% full charged
keep running some battery intensive activity i.e. playing a video , download, running a program which run continuously writing to a file (current date time secs )
Reduce regular interval to 10 secs ( from 1-10 minutes )
Update data in file every 5 minutes
Check the battery level after 2 hours
repeat test but in point 3 update db instead of files
There could be double work, as you will have to implement with both approach, but I believe updating in db will not have much coding efforts
few may not prefer 10 sec interval, as no significant change will happen in this duration, but here goal is to have as many iteration as possible , update them in file or DB and get the stats for battery level comparison.

Store big number in java [duplicate]

This question already has answers here:
What to do when you need to store a (very) large number?
(4 answers)
Java equivalent of unsigned long long?
(10 answers)
Closed 7 years ago.
I wan to create a funny incremental game in java but I don't know how to store data. I thought use a long but I'm not sure that it will be enough.
I know that big integer could works but I'm not sure thaht it's really efficient.

You might want to use long or BigInteger class, depending on how big number you want.
Check out this question/answer for a valid solution!
What to do when you need to store a (very) large number?

How to store datetime in SQLite

This is very similar to another question that got closed as not a real question. I tried to edit it to make it valid for reopening but was told I would be better off asking a new question.
I'm developing on android and need to store datetime values in a sqlite database to track repeating events that will generate notifications. I will also need to be able to query the database based on time ranges.
The SQLite documentation states that it does not support specific date types but that dates can be represented using TEXT, REAL, or INTEGER types:
TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.
The advantages of each initially seem to be:
TEXT useful for readability in the database with ability to be displayed directly later (no transformation necessary), but costly if calculations need to be performed on them. Introduces possible error from time zones.
REAL useful for dates before 1970, good for calculations or date comparisons. Does not represent time of day, only days.
INTEGER useful for calculations or datetime comparisons, very good compatibility since it is a widely supported standard.
Does this sound correct? Would using an INTEGER for datetimes make querying time ranges noticeably faster than when using TEXT? Anything else I haven't considered?
Given my use case, which of these solutions would be best?

TEXT useful for readability in the database with ability to be displayed directly later (no transformation necessary)
The ISO format is usually not used for display; you have to transform this, too.
(This format is more useful for debugging.)
costly if calculations need to be performed on them
With databases, the bottleneck usually is the I/O.
I doubt you will ever see a query where the actual format of date values would make a noticeable difference.
Introduces possible error from time zones.
The TEXT format does not have a time zone specifier, but neither have the other formats.
If you say that all your DB values are in UTC, there is no difference.
REAL useful for dates before 1970
All formats support all years between 0 and 9999. (Integers can be negative.)
Does not represent time of day, only days.
Time of day is represented as a fractional value.
INTEGER ... very good compatibility since it is a widely supported standard.
But Java uses milliseconds, not seconds.
Anything else I haven't considered?
The default output format of most of the built-in date functions is TEXT.
Given my use case, which of these solutions would be best?
I'd say TEXT, but I don't think there would be much of a difference.

Does not represent time of day, only days.
That's what the fractional portion of the REAL is for.
Would using an INTEGER for datetimes make querying time ranges noticeably faster than when using TEXT?
Most likely. I cannot envision a scenario in which string comparisons would be faster than integer comparisons, particularly for indexed columns in queries.
Anything else I haven't considered?
I have no idea if you have considered the effects of gamma rays on man-in-the-moon marigolds, but that's not important here. :-)
Given my use case, which of these solutions would be best?
INTEGER, IMHO.

Answers here are going to be primarily opinion, but if I were you I'd use the INTEGER type and store the unix timestamp. It seems less dependent on format conversions/parsing, and is the most universally supported standard.

Store UTC date time as eight byte 64 bit integer in SQLite. Millis sence 1970.
long time= System.currentTimeMillis();
With an indexed database you'll have excellent response for about 10k rows on order by and between datetime reading data.
Leave the time zone manipulations to the view layer because a database with all UTC times will work world wide.
Don't store dates as text that's so ancient and has no place in a modern application.
I would avoid storing just the dates because modern apps take into account when an event occured. You can store datetimes with 8 bytes. But if you must you can simply put the iso date into an integer 1999-12-31 as 19991231 and store a 4 byte integer in sqllite.

How to convert this: "'updated_time':1375486365" to normal time? [duplicate]

This question already has answers here:
Android Convert Unix Time to GMT time
(2 answers)
Closed 9 years ago.
I am developing a Facebook app. I fetch update_time and it is like this:
updated_time":1375486365
How can I convert this into a normal time in Android?

The time you get is epoch time.
Check this http://www.epochconverter.com/
You will have to use this http://developer.android.com/reference/java/util/Date.html#Date(long)
and pass the epoch time in millis. In your case multiply by 1000.