I am currently involved in a project where we performed some computer vision object recognition and classification using python. It is necessary to use photos taken from an Android phone (photos should be automatically sent from android to python). I actually don't know how should I connect both applications (android and python) together. I thought of using TCP Server, but I am new to socket programming and don't know how and where to start.
Any one can help?
Android gives you options to connect via HTTP.
http://developer.android.com/guide/topics/connectivity/index.html
So I would probably go with a REST type implementation
https://en.wikipedia.org/wiki/Representational_state_transfer
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Here is a tutorial for Android and REST
http://www.majidkhosravi.com/android-rest/
But you are dealing with pictures. Here is a SO talking about that.
POSTing image from Android to WCF Rest Service
On the Python side you have multiple choices, but the main ones I would consider:
Twisted (or maybe Tornado) if you want Asynch.
http://twistedmatrix.com/trac/wiki/WebDevelopmentWithTwisted
http://zenmachine.wordpress.com/web-services-and-twisted/
Flask for Synch.
http://flask-restful.readthedocs.org/en/latest/quickstart.html
Maybe Nginx/Apache + Django
http://django-rest-framework.org/
SO post about Python and REST
Recommendations of Python REST (web services) framework?
If you want to implement this at the socket level, this book would be a great resource:
http://www.amazon.com/Foundations-Python-Network-Programming-Goerzen/dp/1590593715
Hope this helps provide you some directions to explore.
poof's answer is a good overview, but here are some notes on the various options:
Option 1: Have your Android get the picture and do a HTTP POST to a Python application running a framework such as Django. It should be 1 line of code on Android, and only a few lines of code on Python (around your existing code).
The upside is that the low-level "Glue" is written for you, and it scales easily. The downside is that HTTP has some overhead.
Option 2: Have your Android talk a custom TCP protocol to a custom TCP application.
This is more work, so you should avoid it unless you need it. It will be more efficient and have lower latency, especially if you're sending multiple pictures. The response can also be much smaller without HTTP headers.
In either option, you don't have to send a JPEG, you could send any custom format you want (there is a trade-off between compression on Android and size of file).
I thought of using TCP Server, but I am new to socket programming and don't know how and where to start.
Start where everyone else started - by reading a lot and playing a lot. You can find plenty of introductions to Socket programming in Python on the web. Go thru the tutorials, and start modifying them to see how they work. Read up on TCP/IP itself -- there are a lot of dark corners (Nagel, fragmentation, slow start) that can affect how you write the app when you get to a low level.
Related
I am developing an Android application, in which I want to make a calls using internet using SIP in android. So I need to maintain my own SIP sever for my app users, how can I create my own SIP server?
I would not advise creating your our sip server as it would take a large number of man years of development and there are a lot of pitfalls.
There are some open source implementations that you could install and setup yourself. Like FreeSwitch or Asterisk. Both are large and complete to setup as there is a lot of domain knowledge required to understand how to set them up correctly.
There are also free server that you could try out as well like Sip2Sip.
Then there is the job of creating a sip client on Android. Again it's not that simple either. I would look at using a open source library here as well, like pjsip. This gives you the advantage of being able to look at examples of full sip clients already developed for Android like csipsimple. pjsip also has the advantage of being cross-platform, so you could reuse it in IOS for example.
Good luck.
The Server
As a communication server, choose for example sip:providerCE v2.6. The easiest way to get started with it is to download the VMware or Virtualbox image and fire it up on a suitable machine. If you get more serious, you want to install the system from scratch on a dedicated server with a public static IP. If you’re new to VoIP and SIP, do NOT try to install it on an Amazon EC2 instance, as they’re using destination NAT, which is a big pain for SIP and needs some experience with the SPCE to tweak it properly for that scenario.
Note that the SPCE is a 64bit system, so in order to run the VM images, you need to turn on 64bit CPU virtualization in your BIOS if VMware or Virtualbox warns you about it.
...There is very good tutorial HERE! on how to set things up.
...Don't forget there is a technical advise concerning SIP check the accepted ANS!
...Least but not last check THIS! VOIP Wiki, It covers everything related to VOIP.
SIP RFC is very easy protocol to implement. Just create a socket listener and implement RFC-3261. Start with with a basic codec GSM, then move up to A-LAW (G.711), as needed.
The tricky parts with SIP are (A) ensuring your call flows are correct (RFC-3665) and (B) media encoding/compresion. Use Asterisk (FreeSwitch) and WireShark to test your call flow. If you need DTMF support you'll need RFC-2833. If you need advanced codecs, consider using open-source library like FFMPEG.
I used uSIPserver on android. It works well and support video call. If you use client app which supports video then you can video call eachother on wifi.
It is so simple to use.
Good luck :-)
I want to connect an android mobile program to a C++ program, and i dont really know how it should be done.
I was thinking about a Bluetooth connection, but i dont really know how to handle bluetooth in C++. Could you give me some general advice about this?
If you think that i should use another kind of connection, like tpc-ip based, please, let me know and give me some general advices too.
I need the data transfer to be fast, because im trying to use the android device as an interactor, so i need a fast feedback from the C++ program.
Thanx.
If I were you, I would use a TCP/IP connection. It is very easy to implement in Java (Android) and also in C++. Besides, it makes it easy to change the frontend later on. And it is as fast as your network connection, which is usually faster than bluetooth.
Just make sure you put enough effort in the design of your protocol.
There are a lot of resources to be found on the internet on how to create TCP/IP connections, both in Java and C/C++.
If you wanted to have a client server model kind of an use here. Better is to host your Server app(Port your C++ app to Java servlets) & access the Server app via http via Android client. Webviews in android are very useful in doing these.
I need to develop an Android application that sets up connection via WiFi with computer and then sends packets with data. Jowever, I need to control send packets, not only theirs data but also headers, there should be possible to modify any field in their header as well. In windows in it is possible with use of winpcap and jpcap, and I wonder if sth similar I may find on Android. Is there any ready API that will help with my problem?
There's no API available to a Java/Dalvik app on Android which would allow you to do that.
Android is a Linux system, though. So you could try to find/write one or two Linux applications to support your effort - or use JNI.
Bottomline: Native code will definitely be necessary to achieve what you want, no way to do this in Java alone.
I want to build a server that communicates with an android phone
based on a request/response model
At first i thought i will use Httpservlets and communicate with the android
by Http messages. but i need to be able to access a pretty big object with every
request so i guess i cant really transfer the object to the servlet.
so i know this is a pretty newbish question but iv'e been searching for days
what kind of java EE tech should i use(i thought of EJB but as i understand they cant communicate with android)?
Thanks in advance
I think the right question is how to implement service layer for your android application:
Basically there are two options REST based web services and SOAP. Android's support for SOAP is inadequate and I personally prefer REST over soap any day. If you have decided to go with REST, your options in Java are Jersey, RESTlets or Spring Rest services. I will prefer Jersey, but you can also look in to Spring ( although not strictly complaint with the JSR).
(note: look in "SO" for comparison on various rest based frameworks in Java)
I have a web application to be hosted on android device. I am currently using the emulator available with android sdk. My application will serve both static as well as dynamic data. I am currently using jetty version 6.1.22. I wanted to ask what will be a better option to be used.
1. Jetty webserver with stripped off code.
2. I-Jetty.
My application uses following features-
ResourceHandler to serve static resources.
A Generic servlet to serve synchronous data requests.
An extension to CometServlet to serve asynchronous data requests.
I am looking forward to following criteria for comparison.
Application size. Size of apk which will contain the code.
Memory and CPU usage under a maximum load of 30 requests/sec. These are short bursts which occur very few times in app-life cycle. The average load would be approximately 5 requests/sec.
Ease of maintenance. Including important upgrades of Jetty in application.
Any other side-effects which I probably am missing out at.
I too have been searching for information on embedding the i-Jetty server in an application. Like the original poster, I need to serve both static and dynamic resources. I found the following post to be a helpful start:
http://puregeekjoy.blogspot.com/2011/06/running-embedded-jetty-in-android-app.html
I notice that in searching for answers about embedding a web server in an Android app that many responders, rather than providing a helpful answer, chide the original poster for wanting to do such a thing "in a phone". They then proceed to give all the reasons not to. There are more Android devices out there than just phones. My project involves just such a device. Thanks for all the helpful answers on this and other sites that guided me in my efforts. I hope the link I provided helps other searchers.
There are good reasons for embedding a web server in your app. May not be the best way but you have to do it when Android ties your hands. An example is when you want to decrypt video on the fly at runtime and use the media player to play it. Android media player does not allow me to feed it an in-memory stream as would come from a decryption pipe.
In this case, one solution (help me think of others please!) is to embed a web server that would serve up the stream - because Android does accept a stream from a URL!!
The other solution would be port some native library over and write a JNI interface to it. Too much work and unstable at best.
The point is, there are valid enough reasons out there.
It you need to decrypt video or serve content, you might consider just writing a simple web server yourself that can specifically handle your application's needs without any bloat. Adding an existing web server or web container might be more than you need. It very much depends on your application's needs though.
I have a web application to be hosted
on android device.
Why? It won't be usable, except maybe on a WiFi LAN. It won't be able to run terribly long, because services cannot run forever. Etc.
Whatever technical problem you think you're solving by using a Web server on Android can be better solved by other means.
I wanted to ask what will be a better
option to be used. 1. Jetty webserver
with stripped off code. 2. I-Jetty.
Arguably "neither", not only due to the technical issues, but that Greg Wilkins (creator of Jetty) does not like Android much. Of the two, though, i-jetty is at least regularly tested on Android.
Memory and CPU usage under a maximum
load of 30 requests/sec. These are
short bursts which occur very few
times in app-life cycle. The average
load would be approximately 5
requests/sec.
While running, battery life will suck, because you are going to keep the CPU and WiFi running all of the time to support the Web server, let alone the load.