I'm making an app that keeps track of how many times the user uses their phone, meaning how many times they picked up/checked their phone everyday. I've searched through stackoverflow and other sites but I can't find any information that would help me implement this; any ideas? Is there a certain class I can use?
Use BroadcastService and IntentFilter to keep track of when the screen is turned on and off (ACTION_SCREEN_ON and ACTION_SCREEN_OFF). Each time the screen is turned on, increase a counter.
You could register for the ACTION_SCREEN_ON broadcast. Then just increment a counter (saved to disk just in case) each time its received. But you can't do that via the manifest, so you'd need to do it in a foreground service.
Related
I have an app, which main feature is to track user's workouts. GPS location was working OK for past few years until this month, when strange issue appeared.
Some people (not all), using different devices and android versions experience strange behaviour of gps location. Suddenly, after at least few minutes (sometimes few hours) onLocationChanged stops being fired. Sometimes it's working fine, then next day user has this issue again.
User has to start a new workout to get it back to work. Also, in the app logs I found out that
onConnectionSuspended
is called with cause = 1 (CAUSE_SERVICE_DISCONNECTED).
According to the documentation, lost connection should automatically reconnect, but it doesn't thus causing the described issue.
In order to fix that issue, I've created an internal timer (runnable), which checks when was the last time that location was updated. If it's more than, let's say, 2 minutes, it reconnects everything like this:
mGoogleApiClient.disconnect();
mGoogleApiClient.connect();
startLocationUpdates(); //calls requestLocationUpdates
It seems to be working, at least on one's of our test user devices. Seems like a small hack to me, so let me ask you: have you experienced similar issue and do you have a better way to solve it?
By the way, I'm using:
com.google.android.gms:play-services-location:18.0.0
only thing I can think of is to restart gps receiver after not getting location for some time / start vibrating phone so user know and can restart his phone / try to register more providers not only gms. Try fused, classic GPS/network location listener.. if all of them send broadcast to some class and that class wait few seconds then prioritize the best one of those you got in time it would be great! I tried this, it worked but i need to have accuracy like 3 meters.. :D so not possible for me
I have a bit of a unique issue. I'm collaborating with several other Computer Science Majors at my university on an Android Metronome app that allows two users with the app to sync metronomes. Right now, I can send the desired beats per minute of the metronome from one phone to the other and both phones will start to play their respective metronomes. Due to the latency of Bluetooth, the metronomes are only in sync about 20% of the time.
So, here's where the problem is. We're trying to make it so both of the metronomes will start at the exact same time. One way I've thought of doing this is once the first user presses the send button on their phone, a time stamp will be created. This time stamp will be exactly two seconds after the user presses the send button. The time stamp will then be sent to the second phone and the phone will utilize this time stamp to start it's metronome at the same exact time as the first phone. I've tried accomplishing this by putting UTC time in a while loop and then constantly checking the time, to no avail. Does anyone have any ideas as to how we can go about implementing this? I couldn't find any similar problem on StackOverflow, or any other website for that matter.
It's a bit late probably for your project, but if interested. This is a bit long, it's more like a case study.
If your project was about syncing two device clocks remotely, then this won't help you, but if it was about syncing the metronomes, then this may be a start.
First, getting millisecond accurate timings and callbacks in android using java is next to impossible, since android is not a real time system ( All sleep methods and timer might not execute on the exact millisecond you're expecting ). You may want to go with NDK for triggering your beat events, because native threads in android can achieve that, but if you're happy with your single metronome implementation, then that's good enough to read the rest of this .
Full disclosure :
I am the author of JAM the app referenced in the answer I just published a few days ago.
I ran into the same problem when developing the app.
And whether this answer will help you or not, depending on your situation.
and if you're going down the "clock sync" route ( Which I do plan on exploring to improve my app down the road with more features ) but the solution that I found did not involves time sync.
I will mention my approach and then state what I found as advantages/disadvantages for each of the methods .
Instead of syncing clocks ( A very difficult problem, especially for what the app was supposed to do , and that is trigger ticks on multiple devices at the "same" time ) I opted for a subscribe/publish model, where multiple devices can "subscribe" to a host device via bluetooth, and the host device controls and "publishes" the metronome beats.
most times sending a few hundred bytes ( Enough information about each beat ) via bluetooth takes less than 2ms , it could spike up to 10 and sometimes even 30, but that rarely seems to happen .
That approach took care of the syncing problem, now I can send beat events from one device to another in 2ms , and if some sort of delay happened, it will self correct once the interference is gone, because the other event comes in time.
However that approach does require constant connection, you can't start and separate the devices later on, but it's much easier to implement.
Now the interesting part, the problem I never thought of when starting this, and that was the Android 10 millisecond audio path latency problem. I'm not affiliated with superpowered, but I did use their engine in my app to deal with that problem .
To summarize :
Metronome sync over bluetooth in Android has two issues :
1 - triggering beat events simultaneously ( or within acceptable latency )
2 - The beat event should trigger sound events with minimal delay after the beat event is received
#1 is related to the original question, #2 I thought was an important addition to the original problem this question is asking.
I would use (S)NTP to check the clock drift to a public time server. After that I would just send the interval and a start time and let the devices calculate the interval individually. So you just need to sync changes and relay on the clocks of the individual devices. Together with the now known clock drift you can fix this error.
When the battery on my Android device dies what methods in the Activity and Fragment classes (if any) are called during the "Powering Off" stage of the device?
Also, if a user is currently looking at a screen in my app and they hold the power button and choose switch off, do the events called/not called coincide with when the battery is depleted and shuts down automatically?
OnPause?
OnStop?
OnDestroy?
OnDetach?
Bonus:
Will I have enough time to save a small amount of data to a web server?
To clarify "dies" when the device's battery is 'completely' dead, accepts no more input and a message box/loading screen pops up on the screen stating "Powering Off". Shortly there after the device switches off.
I just need enough time to save a forms state before the phone switches off, I have a strategy to clean the saved data should the phone not switch off, but I want to get as close to the phone switching off as possible (any more than a minute is pointless really).
onDestroy is called on everything when the battery reaches 0.5%
EDIT: There is no specified time that you have to do anything in the shutdown process resulting from low/dead battery, that would be dependent on the specific phone battery and not the system, so you may have enough time to save data to a web server on some phones but not others. Experimentally, I have only been able to write a short line to a file I was already writing to before onDestroy was called and nothing more.
The methods you have mentioned is activity life cycle callback, none of them will be called when battery is low. You need to use a broadcast receiver for this
See this How to detect when the Battery's low : Android?
My app is basically is a schedule app, where I'd like to show notifications x minutes before an (user-set) event occurs.
I read the documentation, but it only covers showing a notification at the time the notification code is being executed (which I guess is the only way).
My guess is that if I want to have notifications show up even when my app is closed, I need to somehow make the app run in the background and constantly check for upcoming events, calculate the time left, and show a notification when the time left equals the time before the event the user chose to be notified at.
I read this question (+answers): How to get android notifications when app was closed?.
There is a pretty detailed answer (using services) I could simply implement, but the other answer claims this approach is "crappy".
The second answer also suggest the usage of AlarmManager which, after reading the doc, doesn't sound that bad (executing code at a specific time).
However, since I'm targeting API19 it's "inexact" (according to the doc).
So what exactly is the most efficient (and the right) way to do this?
You need to implement alarm manager with service. Set the time user chose and show notification at that time. The sample shows a Toast, you can use notification/sound/dialog, anything.
Check out this sample.
For my application, I want to have a Notification sent to the user at a specified time. To do this, I have set up a Timer and the corresponding TimerTask.
To be sure the Notification will be sent to the user even if the phone is aslept, I have acquired a PARTIAL_WAKE_LOCK. The problem is that this method draws a lot of power from my battery (my application is responsible for more than 50% of all the power consumption at the end of the day).
Is there another way (a more power efficient one of course) to do what I want to do?
Thanks in advance for the time you will spend trying to help me.
> Is there another way (a more power efficient one of course) to
> [have a Notification sent to the user at a specified time]?
You can use an the android AlarmManager for this.
See Using AlarmManager to Schedule Activities on Android as a tutorial and example.