We are developing an android app, and i need some analytics to track usage patterns in real-time. I tested several analytics and found out that most like Google and Flury cannot work in real-time, and so far the fastest real-time android analytics I tried seems Includeapp.
Does anyone have actual experience using the Includeapp API for this purpose? For example, is it best to track fewer events to speed up things, etc..?
Includeapp tracker engine is flexible enough to track hundreds of events in
real-time. Experimentally, the best case scenario with say 100 events
of events per second is a round-trip time of about 100-200
milliseconds. The worse case scenario, with several hundred events is
less than 4-5 seconds end-to-end.
Related
I'm currently developing a Real-Time Multiplayer top down shooter.
The Multiplayer is "working" and I'm currently struggling with pushing the player updates such as position and fired shots.
My first try was using the service "appWarp" which worked perfectly but isn't free and only provided around 2 Million Messages in the free version which i completely filled in around 2 weeks with only 2 devices and 2 players. ( Maybe way to much updates send )
Then I implemented Google Play Game Services and tried using this to send the updates:
I'm able to use "sendUnreliableMessage" for Position updates, which works faster than appWarp used to. I use interpolation to get over the package loss issue here which works alright.
But here the problem is with firing shots. The nature of UnreliableMessages is that packages can get lost, which happens a lot. Shooting 4 times only makes around 1 or 2 of them appear on the other device. Which means that 2 packages are getting lost. Using "sendRealiableMessage" i can achieve around 2-3 packages getting through but with, of course a higher latency. Which makes the shots appear after around 1 second on the other device.
For a fast paced real time multiplayer game this is not what i wanted to achieve.
So what is a better way to do this ? I found web based solutions like socket.io but don't really know which fits the best for my needs.
I found this website which contains a big list of every web based solution for this problem but don't really know where to start.
https://www.leggetter.co.uk/real-time-web-technologies-guide/#_hosted-realtime-services
I am really really thankful if someone could help me with this problem!.
Since you're asking for opinion, I can suggest you try Multiplayer in Unity. It is the leading game engine as of today, so you can expect a huge support from a stupendous user-base.
Another option would be Photon. Hope these suggestions helps.
The Google Fit app, when installed, measures the duration you are walking or running, and also the number of steps all the time. However, strangely, using it does not seem to drain the battery. Other apps like Moves which seems to record number of steps pretty accurately declares that it uses a lot of power because of it constantly monitoring the GPS and the accelerometer.
I imagine several possibilities:
Wakes up the phone every minute or so, then analyses the sensors for a few seconds and then sleeps again. However it seems that the records are pretty accurate to the minute, so the waking up must be frequent.
Actually turns on the accelerometer all the time, and analyzes it only after the accelerometer measurement data buffer is full. However I think the accelerometer has a small buffer to store the latest measurements.
Use GPS to estimate the number of steps instead of actually counting it. However this should not be the case, since it works even indoors.
The app still feels magical. Counting steps the whole time without perceptible battery drain.
Thanks for asking this question!
Battery is one of our top most concerns and we work hard to optimize Google Fit's battery usage and provide a magical experience.
Google Fit uses a mix of sensors(Accelerometer, Step counter, Significant Motion counter), Machine Learning and heuristics to get the data right. Our algorithm is pretty similar to your 1st option plus a little bit of magic.
We periodically poll accelerometer and use Machine Learning and heuristics to correctly identify the activity and duration.
For devices with hardware step counters, we use these step counters to monitor step counts. For older devices, we use the activity detected to predict the right number of steps.
Our algorithms merge these activities, steps and sometimes location to correlate and further increase accuracy.
We do not poll GPS to estimate steps or detect activities.
-- Engineer on Google Fit Team.
On some very recent phones like the Nexus 5 (released in late 2013 with Android 4.4 KitKat), there is a dedicated low-power CPU core that can serve as a pedometer. Since this core consumes very little power and can compute steps by itself without the need for the entire CPU or the GPS, overall battery use is reduced greatly. On the recent iPhones, there is a similar microcontroller called the M7 coprocessor in the iPhone 5s and the M8 in the iPhone 6.
More information here:
https://developer.android.com/about/versions/kitkat.html
http://nexus5.wonderhowto.com/how-to/your-nexus-5-has-real-pedometer-built-in-heres-you-use-0151267/
http://www.androidbeat.com/2014/01/pedometer-nexus5-hardware-count-steps-walked/
having a 3 year old HTC OneX I can say that THERE IS NO DEDICATED HARDWARE, Google Fit just uses standard sensors in a very clever way. I come from Runtastic Pedometer: there is a clear battery consume when in use, it would be impossible to keep it on all the time as it needs the full accelerometer power. On the other side, if you stand still and shake the phone Runtastic will count the shakes, while Google Fit apparently does nothing... Still it works perfectly when you actually walk or run. Magic.
Google fit try to learn use pedo step pattern and try to create its own personal walking patterns and its clusters. This eliminates the need of having huge mathematics calculations on receiving sensor data every time. This makes Google fit more power efficient compared other software pedo apps. Having said that, there is compromise on accuracy factors here. Between power-accuracy trade off, google seems to be more aligned towards power factor here.
At this moment the most power efficient detection happens Samsung flagship & its other high end models. Thanks to Samsung's dedicated hardware chip! No matter how power efficient your software pedo algorithm be but its hard to beat dedicated hardware unit advantage. I also heard about Google's bringing dedicated hardware unit for Ped upcoming nexus devices.
It would seem like the solution would be device dependent, with devices where a co-motion processor or "wimpier" core is available for low power operations, that it would default to this once the buffer is full or similar condition. With devices where a low-power core is not available, it seems like waking the device could trigger a JIT operation that would/should finish by the time the app is called.
While the Nexus 5 does have a dedicated "low-power" pedometer built in. It isn't as "low power" as you might think.
My Nexus 5 battery life was decreased by about 25% when I had Google Fit Activity Detection switched on.
Also, the pedometer doesn't show up in the battery usage stats. Presumably, because it is a hardware thing.
I don't know for the other phones out there, but Google Fit was really draining my battery life on my Nexus 5. Disabling it definitely improved my battery life.
So I am working with a quiz game in android where you are supposed to be two players playing against each other on different devices.
I am trying to figure out how the correct way is to set up the server communication to the devices. I want both devices to know when both players has given their answers to a question so they can receive the game result.
My first thought was that both devices will repeatedly ask the server if the other device is finished so they can have the game result. But I start thinking this is a bad idea as it will cause a lot of unnecessary traffic and probably some background performance.
So what is the correct way of doing this?
The Google Android way of doing this would be using Google Cloud Messaging (GCM.) This approach is battery & processor efficient, supports broadcasting up to 1000 users at once and has built in functionality for outdated/expired messages.
http://developer.android.com/training/cloudsync/gcm.html
Of course there are other ways of communicating that may be correct/right/valid but this approach is the best for your specified requirement.
I want to create multiplayer 2D top-view race game for 2-4 players. For multiplayer this game will use Google Play game services. Players will move their cars by roration device (accelerometer). This data I will send to all participant in room. Its realtime and this type of game needs, as exact as possible, positions and angle of cars for smooth animations, checking for objects collisions, display positions, etc …, so game must refresh fast enough to be smooth and work with given data.
Google Play game services multiplayer messaging has 2 concepts of exchanging game data between clients:
Sending real time message - Reliable (max 50 messages/sec) and Unreliable
Socket-based
Which concept I shoud use for exchanging players data?
I'm doing something like this too and my plan is to build a prototype with Reliable Messaging first and see how that goes. If the latency turns out to be an issue, I'll then step down to Unreliable Messaging, and then if it's really not working out, Socket-based. As with any software project, having a good architecture will allow you to switch protocols relatively painlessly.
Also, there won't be any wasted work by implementing Reliable Messaging and then switching to Unreliable, since the programming required for Reliable Messaging is prerequisite for Unreliable Messaging.
It'll be nice too if someone with experience could answer this question right off the bat with what will and what won't work.
I'm in the process of developing an almost exactly identical game as you've described for my university project. We use AndEngine as the game engine.
We decided to go for Unreliable Messaging because we read that for quickly-updating games like shooters or racing games it's better to use a UDP-like protocol.
We've had 2 approaches:
broadcasting my car's position to all other users - fairly straightforward and reliable, however with ~30 updates per second still not smooth enough,
broadcasting my car's speed and direction whenever there's any change - very smooth results, however with Unreliable Messaging if any packet gets lost it turns out after some time that the position of the same car is different on different users' devices.
I would really like to upvote the issue and ask someone with experience in the matter to contribute :)
I'm developing an Android app which needs to download a lot of data.
To improve the usability, I'd like to measure the data traffic my app produces and give the users a hint if the app downloaded a specific amount of data.
My current idea: Sum all downloaded bytes together and react on a specified limit. However, as I downloaded things in many different situations and in many different positions in the code, is there any other possibility to measure the data usage per app?
AFAIK, sys/net/NETINTERFACE/statistics/rx_bytes reports the total amount of the whole system, so this is not a solution.
However, as I downloaded things in many different situations and in many different positions in the code, is there any other possiblity to measure the data usage per app?
TrafficStats may be able to report things by UID. I say "may" because it seems tied to devices. I suspect that Android 3.0+ will consistently report by UID, but my 2.2 and 2.3 experience has been mixed.
Here is a sample application demonstrating recording this information.