I am a beginner in Android development. I have to develop an Android app which enables real time on-demand crowd feedback.
The idea is: the task producer needs a task to be solved on day x, time y, by n workers, so he announces this to the system; the workers see when a task is available and they subscribe to it; at that date and time, task producer posts the task which is sent to the subscribed workers, who solve it immediately, and the result has to be returned to the task producer as soon as the task is solved.
I am not sure what architecture pattern to use so that I can enable the communication between the task producer and the task worker without using a server.
I thought about using MVP and publish-subscribe for the communication between the task producer and the task worker. Would this be the right approach?
You have to use a server. There is no way to accomplish this without a central point to send data back and forth from. You can try and use the task producer as the server, but you will definitely have connectivity issues, and have problems with this approach.
This would require that all consumers "know" the producer, probably by IP Address. This address changes regularly, so you will probably want to register it with a Dynamic DNS server so that clients can find it.
Then you would have to run a socket server in the provider app to allow consumers to connect and pull tasks, and push results.
This is going to be complicated, and ultimately not work very well with a cell-phone network. It gets much easier if there is a centralized database of tasks, and the phones act as clients to that centralized application.
I found this: http://developer.android.com/guide/topics/connectivity/wifip2p.html which kind of walks through the process involved in a pure peer-to-peer architecture on android, it's definitely a good starting point.