I'm wondering what would be a good way to build an Android application with offsite processing. Essentially I am going to record an input (audio recording or photo), and then send it to a computer I have online (securely - probably using HTTPS). I then will have the computer process the data and send back a response.
Essentially this is a Shazam like application, except everywhere I look to how Shazam works they talk about the processing algorithm, not the process. Any help would be appreciated.
If your server processing may take time, you can use Push Notification to tell the application that you are done on the server side. The application can then get the result instead of holding up the connection for too long.
Related
I started with a application where you can chat.
Now im in the position to start with the chat.
The problem I'm facing is that I don't want to use
resources from "outside". With outside I mean:
Firebase, Socket.io and so on.
I do simply rent a webspace. And I'm asking you now,
how is it possible to realize an live chat without
using extern services like firebase.
Is it possible with only using an Webspace?
What is required to make an live chat?
And there comes the second question:
How do I realize to stay connected to a server to check if there is a new message without using much battery or network ressources?
I'm not asking without hardly trying by my self.
Two days ago I started with the research of possibility, but I didn't found anything which would work I guess.
Thanks folks...
You need to connect to the Web Server using a Socket and keep that connection open to receive new messages with little delay (see for example http://srchea.com/build-a-real-time-application-using-html5-websockets) This keeps the phone active and uses much battery.
The very purpose of Firebase is to bundle this work for all services which need this type of communication (E-Mail, Push messages of newspapers, Chats) such that the phone only has to query one server. Therefore, I see no way for you to find another solution which uses little battery.
I am currently working on a small scale project to prove something works, I currently have a smart band device which has an Android SDK.
From this device I use the SDK to track a users heart rate in real time.
So my Android application receives updates to the heart rate in real time.
This was fairly easy to do however I now need to send this data in real time from the Android device to the server as efficiently as possible.
To start with battery drain is OK as initially this is just a proof of concept.
I have limited experience with sending large amounts of data to a server in real time and I was wondering if anyone has an ideas on what might be the best approach on Android?
I have looked into Sync Adapters but these seem to be more about keeping data aligned between the client and the server, this is something I am not concerned about. Another approach would be to see if the RequestQueue from Volley might work but again I am unsure if looking into this is even worthwhile?
Should I be looking into creating a Service and somehow using a socket to transfer the data?
EDIT: It looks like IntentService may be the best option for handling the task execution but I am assuming http requests would be too heavy for the client and I should look into something else for the transfer?
I am working on similar kind of project but the wrist band I am dealing with is Empatica E4. Please bear in mind that I am not an expert developer, therefore I am also looking forward for corrections in my design. Also, I will try to justify my idea step-by-step and as much as I can. I hope that this will give you some hints for your application and help others as well.
So, my current architecture looks like;
First of all, Empatica has also provided an Android SDK to receive the data. SF stands for Sampling Frequency whereas EDA, Temp, BVP and AccXYZ are my sensors in wrist band. Each sensor has different sampling frequency and the maximum is 64 Hz which gives you 15 ms interval between each samples. This interval is quite challenging to perform all the operations, therefore I buffer the sensors data in (Volatile LinkedBlockingQueue) FIFO queue so that I don't miss any sample. This was all happening in the service of my application.
Now, I have a Runnable task that I have used with ScheduledExecutorService to collects samples from the queue with the interval of 250 ms (you can vary it as per your need but I used 250 ms considering my needs, network latency and the device performance) and put them in a single JSON object. Number of samples that this Runnable task collects are varying for each sensor, which are, BVP: 16 samples, AccXYZ: 8 samples, Temp: 1 sample and EDA: 1 sample. At the output, I have a JSON object with the data to be sent to my server.
For transferring data to my server, I am using HTTP POST request. The reasons are easy, fast, efficient and good for concurrency. I am using Volley framework which will handle all my network related issues by itself. So I just add the JSON object in the Volley RequestQueue and my client is done here. As you mentioned, you can use socket connection to achieve your goal but I have to use multiple devices, therefore in my case, sockets can be problematic to achieve concurrency. I also tried to do it manually by using HttpURLConnection but the code was becoming tedious and hard to handle.
Finally, I have a REST API (in Python) on my server side which will handle the POST requests, parse the data and insert it in my MySQL database. As of now, I am still working on this REST API to parse the data and store it in DB. However, I have tested my application and I am successfully receiving the data from my device to the server.
Regarding your question "Should I be looking into creating a Service and somehow using a socket to transfer the data?", it's an excellent option if you are working on a single device. If more than one device, i think Http is better option.
Regarding your second question, I don't think Http would be heavy for the client and Volley is taking all your pain on itself. You just have to make a request queue and voila !!! You can find plenty of good tutorials for volley and I particularly followed this.
I hope my answer will help you a little.
PS: As I am still working on this thing and I have not come up with the final product yet, therefore I cannot surely tell about the risks involved in it but I will keep you updated if something new happens. Also, I am open to any suggestions and ideas that can help. Lastly, the picture above is not very detailed, I made it for you, just to share how I am dealing with the same idea.
I've written an android application, and I'd like to make it controllable to other machines by sending HTTP request to the device that run my application. I've written a tiny HTTP server and made it start when my application is started. I know I could translate HTTP requests and send messages to various activities to perform UI operations, that need to add listener to all my activities. But in order to make the remote controller code reusable, I hope separate remote controller code from existing application code and thus I need to find a way to make as less as change to the application code to make it be remote controllable.
Could anyone share your ideas?
I dont get what you are asking tbh but in one of application that my friend create, he just implement a mouse pointer which works from any android phone. With that application he can manage to use the android tv.
When he was implementing that app, he took advantage of socket programming and send messages from remote controller, in that situation a phone, to other device and fetch the data in there. In my opinion if you follow such a manner you just dont need to apply so many changes in your other applications. It is all communication in the end.
I don't know how to present the title more clearly.
I want build a site on Google app engine (GAE), and one app on android.
The site on GAE should wait the signal which is from the app on android and handle the signal to do something.
I don't know how to search the "keyword" on Google of waiting signal on GAE, or what method should I use.
Is here have anyone who have some related experiment on it ?
Thank you very much.
You don't seem to have understood how web applications work. They don't wait for signals - or, rather, that's all they do. Every page served by a Web service is in response to a signal, ie a request. Your web service just needs to respond to normal requests in the normal way.
I need to make for school an app that runs on Android. Actually there are two apps, a client and a server. Ther server runs on a PC while the clients run on Android devices. I want to know what is the best technology for this. I know RMI and WebServices are not implemented in Android so what are the alternatives (besides actually communicating with sockets in the traditional way). One alternative that I did not look into is REST, but I will need to be able to notify a client once another client has done something, similar to turn base games where Player A notifies Player B that he made his move.
Like I said, sockets do the trick, but are little low-level compared to RMI and WebServices and only want to use those as a last resort.
Keep it simple. Use REST and have the clients poll for updates.
Also, if you get to a point down the road where you need to scale, this solution is actually fairly easy to scale because your servers do not need to maintain connections. Since there is no shared state between a particular server and the client (there is shared server between the application and the client), you can easily add more servers to handle the polling and put them behind a load balancer.
You can also add in caching so that the polling just gets the exact same response without causing a re-compute of the response. You would then be able to have the back-end game-state servers update the caches when the game state changes. This would let you poll much more frequently and still have a very flexible, scalable architecture.
For a turn-based game you can take a look at XMPP (e.g. Smack) that is traditionally used for instant messaging. It would also be interesting to create a game using C2DM that is used for push notifications.
You can also look into HTTP streaming which is essentially an unending HTTP response in which player moves are fed into.
Alternatively you can look into binary messaging systems that are more suited for real-time games but still applicable such as RabbitMQ (what's wrong with a smooth turn-based game?).