I got the idea of an app that could show you, after a telephone call, what percentage of the time you were speaking and what percentage of the time you're conversation partner was talking.
For this I had two conceptual approaches, and I was wondering which of the two was most suitable for this application.
Voice recognition - During/after the call the app analyses the audio. Based on the amount of your voice present in the conversation it calculates a percentage
Data recognition - I assume that when you talk the phone uploads more data then when you're silent. Based on the amount of kbps the talking distribution can be determined
You couldn't get access to the phone conversation data itself, but you can get the up/download statistics. There are a few apps available that track 3g data by other apps (most phonecalls now a day use 3g). You could start tracking this when a phone call comes in, filter the other app datatraffic out, and then end when the phone call ends. This way you can know the amount of traffic being send in & out. You would have to do some basic testing beforehand, as there will lot's of overhead data being transmitted besides the voices themself. You could do some testing to see if there is a correlation (and by what extend) between the amount of talking and data traffic (there should be).
Related
Though as a beginner, I am trying to develop an android app which is story based, i will like to know the best way to serve content to the user, i mean like a continuous update of content, just like updating news by the hour. As users will install just once, how will they get the latest content of my news or story based app.
I have access to domain names and hosting if it requires uploading such content through a domain.
from your experience, what is the best method to achieve this? I humbly await a response, thanks
So given the clarification in the comments this is the answer:
The best way is PUSHING the content to the user's device.
Generally speaking, the two ways for a new content to reach an app are :
1.polling your server (or any third-party server) for new data every,say, 20 minutes. The disadvantage of this method is that it drains the battery. Every time that the phone connects to the internet, the radio in that phone stays on (or in a standby mode) for something like 2 minutes. Those modes (on and standby) drain the battery. Another problem is that it does use data needlessly and in some countries cellular data is expensive (Canada for example).
This could be a solution if the data changes very very frequently (for example a stock's price can change many many times a day). But generally speaking method 2 is the preferred method..
2.Pushing the content to the user's phone.
Your server will send a message to the device once new data that you want to send is there (and you could also put that data in the payload of the message if it's not too much).
This means that the phone will connect only when some new data is available.
Saves battery life,and gets the information as soon as it is available!
I recommend using GCM (Google Cloud Messaging) for this purpose which is free, and simple to use. If you have no idea how to do that in Android (which is likely since you said that you are a beginner), it is explained really well in Udacity's
Advanced Android App Development. It is a free course by Udacity and Google, but the section about GCM is only about 15 minutes long.
If you know how to implement a server but don't know how to use GCM in your server (and you don't find Google's documentation helpful) do let me know..
If you don't know how to implement a server...well then it's something you will have to learn in order to get your content to your users as that's the best way.
I hope this helps! :)
I am learning game developement and was thinking of creating a real time 2 player game for android. It needs to have simultanious game play of tow players on two android devices , the one like this: Gurrilla bob
Now I want to know is there some tutorial over what should be shared in real time between the two devices for the games running on each of them to be in sync ? I do not want to know the network implementation.
Is it that
The game runs on one main device and the screen is shared on the other device and it just reports input events to the main game.?
The two devices share Physical world details(position of bodies , forces on them , their positions) or something similar(I am just guessing)?
Or is it something totally different ?
The range of "data we share" really depends on the level of security you desire. In a massively multiplayer online game (Which is a bit different because it has a server between the players), the data shared could range between the following, from the most secure:
The user input itself. The client sends the server what the user does - he tapped the screen to shoot, he swiped the screen to move, etc... The server processes the input and decides whether to respond to it (If it's legal input) or not (If it has been modified, I.E hacks and cheats). This gives a lot of work to the server - All processing is done on it, and it has to report to all its client what happens and when. However, it blocks pretty much most if not all hacking/malicious input options, making your game very secure.
To the most insecure
The user input consequences: The client itself processes the input, and reports to the server what the input caused, its consequences. For example, if the user tapped the screen to shoot, the client calculates the bullet direction and sends to the server "I shot a bullet at this time and that direction". This allows clients to send misinformation - A client could send "I shot 100 bullets", which means you'll have to add many checks on the server, to make sure players don't cheat
Now, since you are neither talking about a MMO, nor about a game whose security is important (After all, it runs on an Android and few are those who know how to hack applications, and you weren't about to publish it anyway), I feel kinda stupid for writing that much when it's not necessary, but I hope you got some of it.
Back to your problem - When talking about 2-player game, especially on a phone, real-time and network efficiency are the most important factors. So we can wipe off the option of "Sharing screens" as streaming videos is not that fast or network efficient.
I think the best solution will be that both devices respond to input and send the consequences to each other. This way, users won't experience latency, or just very little. You'll have to handle special cases that latency may cause (For example, when talking about shooting games - If player A shot and killed player B, but player B lagged and took 5 seconds to receive that consequence, and meanwhile before his death he shot and killed player A, player A shouldn't die.)
One of the costs on a phone is that of sending messages, like for instance heartbeat messages to a service in order to be able to receive push messages.
One solution I'm trying for is to set up my timers with a time frame, for earliest heartbeat, and latest, so that when I hit the early time, I'll start listening for network traffic, and if the radio on the phone is busy anyway, I'll send my heartbeat when it is.
The idea is that I may save some power by preventing the phone from having to power up the radio just for me.
That is the theory.
But there are two problems. I'm new to Android, and I haven't been able to figure out if there is such a service I can listen to.
I'm aiming at Android 2.1 for the widest possible audience.
What you ask is covered in Android Training:
http://developer.android.com/training/efficient-downloads/regular_updates.html
Other sections about Transferring Data Without Draining the Battery should be helpful, too.
We have an android(or iphone) client we are developing. The client allows the android user to send entries to a server which we also develop. If the client does not have data services (GPRS) at the moment the user sends the entry to the server, the client also supports saving the entry to an offline database and sending it later to the server.
One important aspect of the whole process is accuracy of the timestamps on which the user sent the entry to the server (whether the entry is made in real time or sent by the client from the offline database)
When available on the client, we get a GPS location and are able to use the GPS timestamp to send that to the server (or save the GPS timestamp on the offline DB and send it later to the server). However if the user has turned off the GPS (and all other location services), the device will not have a GPS fix and therefore the server can not determine accurately when an entry was made.
We can not use the local device clock as the user may change the clock to make entries on different times than they actually occurred (these entries are part of the users salary so he might have an interest to "fix" them).
So basically I am searching for a way to determine as best I can the time some entry was made when I can not trust the internal clock of the mobile. The algorithm should support both entries sent in real time or entries sent from an offline DB. the algorithm should also support cases where the user changes the time of the mobile, turns the mobile on/off, turns the GPS on/off while the application is running on the mobile etc...
Few ideas that I thought of:
Although I can not trust the mobile's time, it can still perform as a stop watch:
Have a class that will loop until the application exists, the loop will sleep 1 second and increase an internal clock variable by 1 second. On every GPS location my code gets we update the internal clock variable. This way I have an absolute clock that came from outside the device (from the GPS) and when the client sends an entry to the server, we can use the internal clock as an absolute time.
PROS: the user can not modify this clock as it is only updated when we get a location from the GPS
CONS: the application needs at least one GPS fix before the user can make any reliable entries
I can take advantage of the fact that the server has an accurate clock which is correct. If the client would send to the server info that the age of the entry is 10 minutes, the server could use its internal time and know the exact time the entry was made on.
The biggest problem is how to know the entry age? I thought about saving the entries to the offline DB with an age of 0, then every 1 second increase the age of the entry in the DB. The problem is that if the app is closed and/or the device is off this will now happen
This is where I am currently stuck. Any ideas on how to solve this are more than welcome
Thanks
Here's how I handle this issue for iPhone. When the app starts, I call my server and ask for the current GMT time (you could also call a public NTP server if you preferred). I then compare it to the system time. If it is different by more than X then I popup a message saying, sorry your system time is wrong so you can't use the app until you fix this. I then monitor for the user changing the system time while the app is running and if they do that, then I do the compare again (and popup the error message if the time is off by more than X). This ensures that their system time is always correct (within some reasonable allowance) and you can trust [NSDate date]. However, this solution does require a valid network connection. If this solution works for you, I can post the sample code.
i think i am going to combine Jules and Joel's answers into one solution which will provide for my needs the best solution:
since the user might change the clock when the mobile doed not have GPRS, just detecting the time change event will not help us as we can not validate at that moment the new time is correct.
As Joel recommended i will pull the time from my server when my application is started (at that point i still must have communications with the server or else my application will not start). The time pulled from the server along with the current device upTime will be saved.
when the user wants to make an entry i will calculate the current time using (Server Base Time + Current UpTime - Base UpTime). this way i will have an independent source of time regardless of the current clock of the device
this will defenitly work on android
on iPhone we will try to use something out of http://www.cocoadev.com/index.pl?FindingUptime to get the upTime
Jules & Joel, thanks for your answers!
Look into android.os.SystemClock. Specifically, elapsedRealtime() returns a time since the phone was switched on, which is not affected if the clock is changed by the user.
You can correlate times in event the phone is switched off by having code that runs when it is switched on and checks the realtime clock. As the clock can't be changed when the phone is off, I suspect you could use this to put together a system that will catch any simple attempts at cheating. (If the user roots the phone all bets are off -- they could modify the behaviour of the APIs from under you).
Running code every second will kill the phone's battery life. Most phones would be unlikely to last a day if you did this.
I'm designing a location-based service where reliability plays a role.
I wish my users to know that the provided location of other users is real.
I researched mock locations a bit, and noticed in this thread the app LocationSpoofer. I don't have a rooted phone currently, but it states that when rooted it can mock locations even without the setting.
Is there any known way to protect against that? I could use some simple heuristic to verify that the user didn't travel from France to Hawaii in 30 minutes, but I would rather have complete protection.
Thanks ahead!
Instead of a long comment:
"reliability plays a role"
As long as your provide reliable output for "reliable" input i think you will be OK without having to handle 'spoofed' or fake input. In case you have data stored in persistent storage you could handle cases for 'suspicious' data.
That is define and apply scenarios on your data to identify cases like "the user traveled from France to Hawaii in 30 minutes", and handle such cases in an appropriate way. Or you could even reject data that are not realistic.
From a security point of view you should assume that any data coming from a client-side validation process cannot be trusted. The data could be intentially, or unintentionally, modified and that is out of your direct control.
If you want to protect against location spoofing then I would recommend server side checks.