Develop Reference

Exchange data between Android and Windows - what communication solution to use?

I am extending custom written windows based server (c#). Currently server provides two commnication interfaces (SignalR based, and simplified TCP protocol based). Both interfaces work well with windows clients which i also wrote.
There is a new requirement that server should communicate with native Android (java) client. Communication should be bi-directional:
-> server should be able to push data to client
-> client should be able to push data to sever
Can you recommend any usefull communication solution?
It Man.

Have you considered JSON over HTTP2?
In HTTP2 you can do a server push which allows bi-directional communication. That being said, often bi-direction communication between a client and server like this is implemented with a polling model.
Another option might be GRPC which allows streaming connections on top of http2. It often uses proto as the serialization format but doesn't have to.
Those two might be worth checking out.

GAE: MQTT broker

So I was wondering if it's possible to run a MQTT broker on the Google App Engine platform?
Couldn't find any information about it (or maybe I might be using the wrong keywords).
I've got my GAE running on Java so I'd like to go into direction of running the MQTT broker on GAE using a backend.
EDIT:
Did some further research and it seems Moquette is running on Java. Does someone have experience running Moquette on the GAE?
EDIT2:
Ok, it seems the examples of Moquette are running using an OSGi container, which is unavailble in GAE. Looking for a script to start this server on GAE.

MQTT is protocol on top of TCP. In order to run MQTT server, one needs to be able to open a listening socket. Those are still not supported on normal AppEngine instances.
Note: GAE backends have been replaced: now you just have automatic scaled (aka frontend) instances and manual scaled (aka backend) instances.
Back to your problem: Managed VMs have most of the benefits of GAE (access to services), but run a full JVM, which allows listening sockets.

An alternative to Moquette would also be the HiveMQ broker, it also runs on Java and can be easily installed. All the documentation is available here.
We haven't tested it on GAE yet, but if you have any problems running it, you could ask in the support forum.
Update: If Peter Knego is right, then HiveMQ or any other MQTT broker won't work on GAE.
Full disclose: I'm working for the company, who develops HiveMQ.
Cheers,
Christian

#Peter Knego is definitely right, and all i would add to his answer is that,
If you manage to configure you application to use a custom Runtime on the Managed Vms of Appengine and Compute Engine,
then you will be able to run you MQTT brooker perfectly sound and well.
As long as you define a fire wall to allow a tcp connection at the port which your broker is listening from.
By default the ports are blocked for security reasons.

How to make Push notification server for my android application?

How i can make my own push notification server for my android & ios application?
m not wanna to use GCM.

GCM and APN are the client side part of the infrastructure. You should still set up your own messaging server. That event-based server will then push messages to the clients via the proprietary infrastructure. I think applications should be respectful of their enironment, and using the push facilities of the platform is indeed a good thing for your users. Also, it should be even easier for you to implement, thanks to the standard setup and the working documentation.
Otherwise, just pick your favourite message queue middleware (Active, Zero, you name it) and integrate it directly with the native client for the supported platforms, without using GCM (or Apple push). But be warned that this will make your application less efficient, and you may face higher development costs to set up the background notification service.

Node.JS provide a module called SOCKET.IO. I use this in my android apps for live messaging. You can configure it on AWS, Digitalocean Or you can use Heroku.
Here is the good example of Socket.io with android http://nkzawa.tumblr.com/post/46850605422/connecting-to-a-socketio-server-from-android
Android chat app wit socketio
https://github.com/nkzawa/socket.io-android-chat

Manage Topics on Mosquitto

I want to develop a simple push notification system for various android devices.
After two days of documentation i've found very interesting to use MQTT protocol.
System needs:
- an MQTT client on Android: eclipse Paho seems to be a good solution
- any MQTT broker you like for the server part: my attention is on Mosquitto cause is Open-Source
I've read documentation and the configuration file and seemed clear. The only thing that I couldn't understand is if i can manage topics (where clients subscribe to). In particular if i can create topics and how to.
Thanks.

It's not clear whether you mean on the client side or the broker side...
Assuming you mean the broker side, you don't need to create topics, they are created automatically as needed. You can control what clients have access to what topics using the built in authentication and ACL code, or you could use an authentication and access plugin. Writing your own is quite easy, or you could use the excellent https://github.com/jpmens/mosquitto-auth-plug
On the client side, simply subscribing or publishing to a topic is sufficient to create it on the broker, assuming you have permissions for that topic. This may not be the case in all MQTT implementations.
As an example, try subscribing to the # topic on test.mosquitto.org or iot.eclipse.org. These show a huge range of available topics and there is no admin to support them in the background.
This basically means that the only administrative load you have is restricting access on the broker where required.

Using code stole from somewhere, I made a pretty simple "MQTTMessenger" app for Android. https://bitbucket.org/mjgasner/mqttmessenger
From what I remember, you'll need to go into src/com/gasner/mqttmessenger/MessengerService.java
and change the host ip to the ip of your MQTT server.
For the MQTT server, I used Mossquitto server.
You'll also have to make sure you port forward port 1883 to the server.
I used this to send stock numbers to my phone. It's been almost 2 years ago, otherwise I could tell you more.
The C2DM directory is unrelated. It is Google's push notification service that I was also playing with at the time.
In the other directories at Bitbucket https://bitbucket.org/mjgasner are the .NET service and winforms app I wrote to communicate with the MQTT server. The service would accept the message from the android app through the server and reply with the stock amount it pulled from google's api.
If you have any more questions, comment below.

UDP packet capturing on a servlet application running at GAE

I have a code running in router that sends UDP packets(using Sendto() function and a string of data) to a particular server whose IP address and port number I will mention in my code.
I want to deploy a server application that could receive a UDP packet and store its information on server or somewhere else not sure right now.
I have decided to use Google app Engine for hosting my server side code which most probably will be having something like recvfrom() function to receive string.
So how and by using what API's can I start developing my server side code.

Google App Engine has a Preview release of a Socket API, but it does not let you create listening sockets. See Limitations and restrictions section at https://developers.google.com/appengine/docs/python/sockets/
You cannot create a listen socket; you can only create outbound sockets.

You can use Google Compute Engine to run any reasonable software on Google's cloud platform, including programs that receive UDP datagrams. You must always pay for Compute Engine instances.

According to the newest edition of App Engine Socket docs for Java, if you're using java 8 runtime you should be able to use java sockets without limitations:
Applications in the Java 8 runtime default to using native Java
sockets with no restrictions: Google recommends that you keep this
default.
That means that it should be possible to use java.net.DatagramSocket or java.nio.channels.DatagramChannel freely to work with UDP.