I have an application, where I'll be having between 10-100 minimum phone numbers on which i want to periodically (let's say once a week) make a missed call (about 20-40 seconds of ringing and then hanging up, using all numbers "at the same time").I haven't tried any code yet but i already looked up how to make calls, missed calls etc. so I hope I know my way around this stuff a little bit.
Now you see if I'd do it by using simplest way, I'd have about one hour of my phone making these missed calls one after each other. Is there a way to make these calls somehow overlap each other (make them all at the same time)? Because I looked up that I can't make a phone call in background and since we are using activity to start a call, if I immediately start call after previous one, I suppose since it's an activity it's gonna pause.
As far as I know, it's impossible to call different phone numbers simultaneously on Android and mobile operators do not let you do it either. If you really want to do it, you should use an API like Twilio to make all calls. However, if you're using the API, your own phone numbers will be used for calls, not the mobile phone owner number.
And if you want to know how to do it all at once, this is what threads are invented for! Assuming you have 100 phone numbers, use 100 threads to simultaneously call and hang them via API.
Related
so i guess title is pretty self explanatory, i have an app where i need to make a phone call and after it rings certain amount of times (let's say 2-3), i need to hang up to leave a missed call.
With some help from already created topics, i can make a phone call and hang up, but only after certain amount of seconds, not ring tones. Problem with seconds timer is, you cannot be certain if ringing already started.
Is there even a way in API to let me know when the phone rings?
This SO article deals with the exact same issue.
As of now there is no public API that can detect the ringing on the other side of the call.
I want to create a Reminder application with a similar idea like this, but this implementation only have at most one alarm/reminder at a time (ie. when an alarm starts, we can only configure another alarm after the most recently fired alarm has finished). Where do I start if I want to implement an application that can fire off multiple alarms?
My initial idea is like this:
For example my reminder application has 10 alarms for today, 20 alarms for tomorrow, etc (a certain number of alarms at a certain day). Should I just create a fixed amount of threads and process the alarms one day at a time? Or maybe I can reuse a timer and timer task but dynamically change the delay value? Please help shed some light for this.
Should I just create a fixed amount of threads and process the alarms
one day at a time?
No, just create a thread when it's needed, to be honest you can just have a clock checker within your application and a table or some data structure which holds type of alarm, time, whatever else there and create thread only when it's needed, it will play sound, wait for termination, etc. (basically user input) or just wait for it to die after it will be done with its work. You can have some kind of fixed iteration amount.
Where do I start if I want to implement an application that can fire
off multiple alarms?
Think about what kind of features you want to add, this will pretty much shape design of your application, design yourself some kind of manager of alarms, and system to create an alarm at a certain time.
Make sure you use FXML and force yourself to keep things organized, since your application can get bigger as you go on and add additional features.
Think about what data will be shared between threads since it's highly possible that you will not like to let threads/alarms overlap each other // for instance when they will have "remind in 5 minutes" //, or just terminate alarm that's about to cross into another one, if user doesn't terminate its alarm within that period and it just keeps going and another one is gonna be started, make sure that there is an entity or some higher controller class which takes care of this. If you don't wanna limit this to some minute interval maximum.
This application that you have in your mind is quite small and trivial you might be able to avoid most problems.
Keep it simple, this might be a best advice anyone can give you.
Bud it's just my personal take on this, these kind of questions will attract opinion based answers.
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.
I want to make a program that will make a pop-up appear at a certain time in the future, eg. 5:00 tonight. Basically, the program is a reminder/notification system for appointments, meetings, etc.
My first instinct was to create a sort of "Clock Listener" that would check the computer's time every minute or so and see if currentTime == alarmTime. However, I don't know if this takes up too much resources or if it is just a bad practice to have your program constantly doing things like that. Also, for the alarm to be accurate, I think it would need to check every second, rather than every minute (since if it isn't checking the seconds and will go off at 5:00:xx, it could go off at 5:00:59, which may be too late for some people's liking). Is checking the clock every second too much?
My second thought was when the program starts running, calculate how long it is until the alarm is set to go off (say, in five hours). Then, wait five hours, and then sound the alarm. But then I thought, though unlikely, it would be possible for the user to change the computer's time, and then the alarm would go off at the wrong time. So this doesn't really work.
I've seen some solutions that use threads, but I'm not familiar with those yet, so I'd rather not use them.
I'm leaning towards the first solution, but I want to make sure it's efficient and won't slow down other programs. Perhaps I'm overthinking it and checking the clock is a trivial operation, but I just wanted to make sure I'm not doing anything wrong.
The sleep solution is very straightforward, but using java.util.Timer is not much harder, and gives you a clear way to extend your utility for multiple alarms, etc. Assuming you are going to use Swing to display the notification, note that your TimerTask will need to perform some of its work on the Swing event thread. SwingUtilities.invokeAndWait(...) will help you with that.
The first solution is OK. Waking up, checking the time, and going back to sleep should not be a problem at all. You can check every second if you want, but if you only need 1-minute resolution perhaps it is enough to check e.g. every 30 seconds.
The second approach has the problem you have outlined already. If you just go to sleep for the time remaining, and the user changes the time (or the time is changed by some other means, e.g. synchronisation with a time server), the alarm would go off at the wrong time. You could avoid this if you could register some sort of hook so that your program is called back when the system time changes, but you cannot easily do this in Java.
I am a complete newbie to Android development;
Basically, I am about to write an application, that will let the user to take photo, which (with a bunch of extra data) will be submitted to the remote webservice.
So I'm guessing I will need:
A Photo-taking application (Activity) that will gather all the extra data and put in the SQLite DB.
A background service looking up the DB in time intervals and sending the data over the Internet, optionally making web requests with current GPS location (I'm trying to keep in mind, that sometimes network would not be accessible).
A receiver object that will run the service at boot, and optionally check if the service needs to be restarted.
My concerns are:
Do I really need to monitor the service and care about anything bad that could kill it.
Will the battery last for at least 12 hours with a non-stop running service, making some networking/GPS actions in, let's say, 30-minute intervals. (G1/Dream)
What else should I be careful about?
Any ideas/suggestions will be appreciated.
a word of advice needed
Rutabaga.
Oh, wait. You're probably looking for something related to Android. OK, carry on.
A receiver object that will run the
service at boot, and optionally check
if the service needs to be restarted.
Yuck. Use AlarmManager and have your service behave more like a cron job/Windows scheduled task.
Do I really need to monitor the
service and care about anything bad
that could kill it.
Not if you use AlarmManager and have your service behave more like a cron job.
Will the battery last for at least 12
hours with a non-stop running service,
making some networking/GPS actions in,
let's say, 30-minute intervals.
(G1/Dream)
If you use AlarmManager and have your service behave more like a cron job, a 30-minute interval should be OK. Just make sure you shut down the GPS radio when you are done with it. Note that using the GPS radio from a cron job sort of task is a bit tricky, since it takes a while to get its first fix. You will also want to take a look at using PowerManager.WakeLock to keep the device awake until your work is completed.
What else should I be careful about?
Mynd you, moose bites kan be pretti nasti.
Beyond that and what I wrote above, you should be in OK shape. Note that what you are diving into is not exactly "newbie" material.