I'm about to create a GPS-tracking application for pizza-delivery services in my city, so that when someone orders pizza over the phone or Internet, he can see the courier that carries pizza to him on the map.
Assuming that both courier and client use Android- or iOS-based phone for transmitting/receiving current position, how can I organize a reliable connection between them? Should the courier's phone send his coordinates to my server via HTTP every 5 seconds for delivering it to client, or it will be better to set up something like p2p connection?
I don't know where to start, please help. Thank you very much.
There are open source solutions for GPS tracking. You can start from there instead of developing everything from scratch.
Traccar server (back-end for receiving location data from various devices):
https://github.com/tananaev/traccar
There are also apps for Android and iOS, but only for transmitting location data:
https://github.com/tananaev/traccar-client-android
https://github.com/tananaev/traccar-client-ios
I don't think p2p will be a good solution.
Most of the application use web services and make server calls after a definite interval of time like 10 seconds or 15 seconds refresh to get updated data on both side of apps(Client and courier).
If you want to build a real time application like other real time apps then you need to implement sockets on web and on mobile apps.
But I think in your case web services would be good enough solution.
Related
I'm searching for the track real time live location of the multiple users. Like Ola cabs and Uber Taxi live location. I try to find so many things but didn't find anything.
I also try with the Pubnub. but not success on it.
Thanks in advance.
I suggest that you should have a WebSockets service,
So the accuracy of tracking is good & up to date,
You will use one client to send (long, lat) to the WebSockets service,
The other client will receive the latest updates from the sockets connection,
Then you show these updates on your map.
All that looks easy,
But It will require a solid backend service implementation,
To handle sockets failure,
Also a solid management of locations services on the client end,
As this will drain battery super fast.
I am developing android application which allow users to share localization data between them, and showing it on the map.
I've done it, and its working but I am looking for better performance, or just better pattern for app like this.
For now, my app uses https connection between android client and REST servlet on tomcat.
For instance, if user is logged he is sending his gps data every 10 sec to server, and gets other users positions. Everything by HTTP POST.
First thing I want to ask you:
Does anyone knows better solution to sync data with server than android service with timed task every 10 sec? I have background service that is running all the time and every 10 sec runs AsyncTask which asking server about users localizations.
And what do you think about connection method with server?
Maybe it will be better to create connection by sockets?
Thanks in advance for all responses.
You're right. There is no necessity of establishing http connection each 10 seconds. It's absolutely inefficient for clients and your server in terms of CPU usage and data transferring.
There're two solutions which I suppose more appropriate for you task:
Yes, sockets. Socket connection could be fairly easy implemented on Аndroid. Two threads which share socket connection: first one reads data, second one writes data. To receive data when phone is sleep you could use GCM service.
P2P connection. It's quite reasonable because as I understood you don't need to modify or track transferring data by your server. Clients just will communicate with each other.
We have an Android app with over a million active users. We recently started receiving feedbacks from users complaining that our app consumes huge amount of network data when in background (around 0.5-3 gigabytes in a week).
The app doesn't have any operations in the background except for the push notifications receiver which doesn't have any network calls. the data consumption on the background should be less than 10 megabytes for a week for sure.
Is there a code I can use to help me detect the cause for this data consumption when my app is in background?
Is there a way to limit data access from all SDKs when my app is in background?
In general, what's the best way to approach such a problem?
Thanks
Update:
In our case we found eventually that the source of the problem was from an SDK we integrated with the app.
If you have the same issue, I suggest you look closely at all your 3rd party code in the app, especially new libraries you added.
Second, check all the services that your app define in the manifest, look closely if any of those services can be the source for this problem.
Third, look for places in the app that use network operation with a re-try mechanism, there could be an infinite "while loop" trying to send some data to a server (maybe some sort of reporting or analytics).
You need to inspect the traffic coming over the wire from your devices. You will need one computer and your device connected to the same local network.
Set up a debugging proxy like Fiddler on a machine on your local network and note its IP address. This assumes your app communicates via HTTP.
Connect your test device(s) via WiFi to the same network as your debugging machine.
Configure your Android devices to use a proxy that points to your debugging machine.
Now you will be able to inspect all requests originating from the device(s). Presumably you will have to leave them running for some time to replicate the problem of some kind of periodic background service running and downloading data. However, I can tell you now that push notifications themselves are not causing 3GB of data on a single device.
You can write code for count the data usage as follows.
recived = TrafficStats.getUidRxBytes(uid);// uid is your appID
send = TrafficStats.getUidTxBytes(uid);
TrafficStats.getMobileRxBytes();
TrafficStats.getMobileTxBytes();
TrafficStats.getTotalRxBytes();
TrafficStats.getTotalTxBytes();
and there is good answer you can find here..
App data usage finding
First of all, sorry for my bad English.
I've made an Android app which seems to work fine. Its mission is to connect to a website and parse it to see if there is new data. In that case, it creates a notification.
The data in the website is modified approximately once a day, but at a random hour. And I want to know it as soon as possible.
My app connects to the website every 20 minutes to check for new info, but I realized that it involves a high data consuption on 3G. I've thought that the parsing could be done in a server, and the mobile would just recive a c2dm push.
My problem: I've no idea about servers. I've seen some prices and.. Do I have to expend that high quantity of money in a 800$ server? Are there any cheaper option for my simple app?
Thank you everyone!
As you have seen, doing the parsing on the device can be troublesome with data use and also potential network access issues (what if you don't have a connection at the time you try to search?). Doing this work on a server with a more reliable internet connection is a good idea. You will be using Google Cloud Messaging (GCM) not C2DM which is deprecated. You don't need to buy special hardware to host a server, and if it's only for your use, an always-on desktop computer could do the work for you. Since you'll be using push, you don't even need a static IP address (or a domain name) for the server, since the device will never 'phone home', since you just need a notification when things change.
I would first start by opening a port on my desktop computer and try to get the device to talk to your machine via your LAN.
Hope this helps.
What's the best way to send constantly updating data from a server (over a REST API or a socket) to an iOS or Android app? Should I create a socket connection and have a socket server that pumps out data, or should I have the app periodically poll a backend resource? Thanks!
Should I create a socket connection and have a socket server that
pumps out data
This is an option. I know some top apps on the play store that use web sockets for streaming data.
Have the app periodically poll a backend resource
I would recommend against this. Polling drains the battery. The android OS will keep the CPU in idle mode at times and constant polling can wake the CPU up and cause a drain in battery. Users wont like that. You are also wasting processing power when there are no results from the server.
The easiest way to send push notifications / minor updates to the android phone is via GCM. The GCM messages are delivered in near real-time (I noticed a lag of about a second for my apps). The payload is limited to 4k and the messages are stored for up to 4 weeks. This is another option you can consider based on your use case.
The typical model I follow is to hit the server on a specified interval and download the updated data.
Polling is bad, it drains out the battery
If you want to update the screen when the application is in the foreground, it is better to go with Socket Connection. You can see the changes in realtime.
For this, you need to create a socket server and open a connection between the device and the server.
https://www.raywenderlich.com/3437391-real-time-communication-with-streams-tutorial-for-ios
I would suggest to use MQTT protocol to publish and subscribe data. Libraries for iOS(Moscapsule) and Android(Paho) for integrating MQTT protocol are available and can easily be integrated in mobile apps.
Backend needs to be configured to support MQTT also. Detail information about how MQTT works can be found here.
I am going to paste my accepted answer from a similar question that was posted a few hours ago.
It can be done using sockets or polling the server but I wouldn't recommend either for a production level app. You will eventually need security features and as a frontend developer, it would be difficult to start from scratch.
I would suggest using a third party service. Take a look at Space Cloud. It is an open source alternative to Firebase where you can use your own database and has built in security features. If you want to go deeper, it uses Apache Kafka for realtime database features.
If those don't suit you then the best option would be to go with GCM.
should I have the app periodically poll a backend resource?
this must be the last option to put in consideration. as long as the client number increases you need to scale out backend/server and this is not as simple as putting an another server next to existing one.
the perfect solution will be a push oriented design and best approach will be to register clients to events and server will push clients if that specific events occur.
you need to be more specific about your business case. you had mentioned real-time in your question but what kind of real-time is that. is it a video streaming, chat application or just ordinary rest calls?
Typically, you'll want your server to push updates to the clients because polling is expensive, may not scale well with N number of clients, and will drain your phone batteries faster. Depending on your server technology:
.NET/Core:
May want to take a look at SignalR to push notifications from the backend to your client apps.
Java:
May want to take a look at Atmosphere to push notifications from the backend to your client apps.
I have used SignalR with good results publishing to phone clients. Have not used Atmosphere, but it has good reviews.