Having a design discussion with some co-workers about our app. Looking for the best way to transfer large data files on a, say, weekly basis from a phone to a remote server. Server will
be in the DMZ and phone will either be in WiFi mode or GSM. Some of the files will be 100Mb can even get up to 400Mb. Just not sure of the best way to approach this in my Android code. I was looking at
MTOM or even just pure FTP. Any advice would be appreciated.
I have investiagated about the use of MTOM under Android but I found nothing. I don't know whether there's any implementation working with Android yet.
But this is something you can do by FTP, which would be a good choice I think. And you could check the integrity of the file using a checksum (calculated on both sides and then compared).
Using 3G for huge files is likely to take long and to be expensive, so to me the best is to use WiFi. You can detect whether your device is connected thru WiFi as described here.
Related
I have a requirement to transfer images between two devices which do not have access to the internet/cellular data and are not on the same network.
I need this to work across Android and iOS, which rules out wifi-direct (Android) and multi-peer connectivity (iOS).
After lots of research, I've concluded that the p2pkit library is my best bet, however data transfer is limited to just 440 bytes which is nothing for an image.
What I'm about to do is create a process that splits images into chunks and transfers via p2pkit, but wanted to double check if anyone is aware of a better way/alternative libraries for achieving this? (Please don't suggest AllJoyn as I painfully learned devices must be on the same network!)
Thanks.
I'm working on a simple project in which i need to control a Arduino Robot (2-servo motors) through an Android Phone's Gyroscope Sensor, via Internet.
As you can visualize, 3-axis Gyroscopic Coordinates change quite sensitively even with little change in Phone's orientation in 3D space, so i want to minimize the Lag to milliseconds.
Now aside from hardware, my first milestone is to send Gyroscope coordinates from Android to a computer through internet as Fast and Continuously as possible (like a RealTime stream of Numeric data). I know traditional HTTP based Client-Server mechanism will be quite slow therefore i've looked into following:
Google's Chanel API
WebRTC
WebSockets
According to my research, Channel API shows latency that from 10ms to even in Seconds. Also GAE limits requests to 30 seconds. Here is a Channels API stress test:
http://channelapistresstest.appspot.com/
Try clicking "send 5"-button a lot, and you will see latency numbers going up to several seconds.
Now WebRTC sounds most promising and faster than WebSockets. I'll be really grateful if someone can guide me about practical implementation of WebRTC in Native JAVA and Native Android (Any good libraries? i want to send coords. from Android and Receive via a JAVA-SE client on Desktop). I'm not interested in Hybrid App solutions (like Crosswalk). I would also like to know about How should i setup a Signalling Server. Summing it up i have following questions:
Which method should i use? (Channel API, WebSockets, WebRTC or something else) with native Java and android support?
Incase of WebRTC, how should i setup a Signalling server? (just brief description) or a WebSocket Server for WebSockets?
Can i make use of Google's Cloud platform or something similar to reduce complexity at my end?
Any overall suggestion?
Thanks in advance.
You do not want to use WebRTC. WebRTC requires you to setup a separate signaling channel like WebSockets anyway, so it is needlessly complex and very heavyweight for what you are trying to do.
If your requirement is simply to communicate a series of gyroscope values from an device to another, I recommend:
Start with a simple socket server
Connect your clients to this server via a socket
Relay messages from one client to the other
A simple server to print socket input to standard output is just a few lines of Python, for example. This does require you to learn to use sockets because your clients need to be interpreting the byte stream in the same way. You can also use WebSockets, but this may increase the complexity of your server significantly; Java EE is significantly more complex than Java SE, for example.
If you want data integrity (I imagine you do), you should use TCP.
If you are really worried about latency, you should also skip going to the Internet. Run everything on a LAN. I imagine you have to see the device under control anyway, so there's no point on going out to the Internet.
I would ignore WebRTC for this project. It is more complicated to setup and requires a special server.
WebSocket should be just fine for this project. It is as fast as TCP.
If you would like to avoid even this delay at all cost, but packet loss is not a problem, then I would go for simple UDP. For all these, you don't need any library, just a few lines of code.
We are developing a synchronous multiplayer game. As it stands one of the players is selected as the server instead of connecting the clients to a dedicated server.
With the restricted environment of mobile apps, should we still be worried about cheating (from the player running the server) or is this a non issue in the mobile space? Are there any other major concerns we should look out for if we decide to stick with players hosting the game?
All of the below is about Android. iOS is more secure, but the server load issue still applies there too.
If you store game data on the SD card, any app can access that data. You could encrypt it, but it would still be a liability (like the Whatsapp hack here: techcrunch.com/2014/03/12/hole-in-whatsapp-for-android-lets-hackers-steal-your-conversations/)
If someone were to implement a low-level interception / modification of your game server network traffic, this could also be a problem. (http://www.justbeck.com/modifying-data-in-transit-to-android-apps-using-burp-and-backtrack-5/)
If you are using a Service, make sure it's a local service so it's only accessible from your app.
Also, the "restricted" aspect of Android systems can be easily removed by rooting the device.
Another thing to consider is network and cpu load. Both these things could grow big very fast, making the server laggy or even crash, considering the relatively low capacities of Android devices as compared to dedicated servers. Of course, this depends on the amount of work the server has to do per client.
In general, dedicated servers are a good idea, even for Android games I think.
I'd look into this from two different point of views:
Cost/Benefit: have in mind that dedicated server will impact your budget, so ask yourself if cheating is really a concern or not. I'd treat mobile space as other kind of spaces.
Game quality: As #1 is your point of view, this is your players point of view... They are going to feel something is going wrong and think about cheating? maybe. You can fix this with a reputation of the player that is hosting the server.
I've been tasked with adding support to an app for beaming large data files (tens of megabytes) from device to device via 'NFC' on Android.
I'm aware that genuine NFC on Android is painfully slow, but I know that ICS has support for doing hand-off of the bulk data transfer to Bluetooth; and Samsung have a proprietary mechanism for doing the same via Wifi Direct (S-Beam). So that's the approach I'd want to take.
Unfortunately I cannot find any information on how to actually do this.
I've looked at the Android Beam documentation, and there's no mention of special mechanisms to support large bulk data; so I took the standard AndroidBeamDemo app and simply added a large byte array to the packet size, in the hope that it would all Just Work. It seems not to --- sending a 10kB message takes about five seconds, and trying to send a 1MB message just doesn't do anything at all (although it tells me the message was sent successfully).
For Samsung's S-Beam, I simply cannot find any documentation whatsoever.
Has anybody made this work, and if so, can they point me at an example?
For Android Beam, you need to provide URIs to the files with the data using setBeamPushUris() (or setBeamPushUrisCallback() if the data is not fixed).
For S-Beam, I am not aware of any API that can be used. AFAICT, S-Beam only works with the built-in apps for pictures, video and music.
I am planning to give mobile phone development a shot and was thinking about making some simple multiplayer games. I know latency over local wifi is probably fine but what are the issues with latency over GPRS/3G?
I've searched and the best I've seen is someone saying it was 'high', without presenting any concrete numbers. I suppose latency fluctuations are important as well - does anyone have any info on this?
From my laptop with a UMTS/HSDPA card to my web server I get a ping time of 100ms (both are in Germany).
I've seen the same 802.11 link with the same hot-spot jump from ~80ms to 3000ms and back. Assume latency suck and write the program to deal with it.