Android Platform Support

[dharanad]

This is great project ❤️, thanks for open sourcing it. I was trying to build something if this kind for my mobile application project. Is there any platform support for Android OS in the near future. As of now most the android developer have been using firebase for realtime communication, which is paid service. I see a great potential in this project and could be next big thing. Enabling android platform support would let may more developer build great app. Android platform support would be great feature of this project .I am very much interested in this project and want to develop Android Platform support tools for this project. Let me know is this could be great thing?

[Florimond]

Hi,
thank you for your nice words. In theory, you could find any mqtt lib working with Android and communicate with Emitter servers without much hassle, as Emitter SDKs are merely wrappers around MQTT libs to make a few things more convenient. You would find all you need in this documentation : https://emitter.io/develop/creating-sdk/

There is just one issue with android : push notifications. You won't receive messages from Emitter in real-time without dealing with android's push notifications system.

[ghost]

You have another easier option.

The golang client code can be compiled for mobile..then you can call it from your iOS / android GUI using a simple jsonrpc.

[ghost]

@Florimond i responded to your email

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[StephanSchuster]

There is just one issue with android : push notifications. You won't receive messages from Emitter in real-time without dealing with android's push notifications system.

@Florimond Can you please elaborate on this? What exactly is the problem, how does it affect "realtime" and how do comparable frameworks deal with it then?

[StephanSchuster]

The golang client code can be compiled for mobile..then you can call it from your iOS / android GUI using a simple jsonrpc.

@gedw99 Could you please provide a bit more information/links/... on this? I'm currently trying to access emitter from Android but the provided Java SDK is out of date (see here: emitter-io/java#2). Maybe your solution would serve as a temporary workaround until an up to date Android SDK is available.

[Florimond]

@StephanSchuster I'm not an Android developer myself, and Iast time I played with Android was quite some time ago. But if I remember correctly, the issue is that you will receive messages from Emitter in real-time as long as the app is in the foreground. As soon as it's in the background, only push notifications can reach it. I don't really know how others solve this, I have yet to dig into it.

[StephanSchuster]

[...] you will receive messages from Emitter in real-time as long as the app is in the foreground. As soon as it's in the background, only push notifications can reach it.

Ah, okay. I see. But this could be faced step by step, right? A bit simplified:

1. Having an up-to-date Java/Android client SDK which works in foreground would be the starting point which probably covers most basic use cases.
2. When Android puts the app into background, the app developer gets callbacks and can in worst case disconnect and reconnect afterwards.
3. In case a reconnect is not desired or receiving updates while in background is needed, either the app developer has to "wrap the emitter client lib into an Android service" or the emitter client lib itself supports this scenario out of the box. Maybe https://www.eclipse.org/paho/clients/android/ can help here. Haven't read about the differences to https://www.eclipse.org/paho/clients/java/. Obviously both support Android.

[montanaflynn]

@gedw99

The golang client code can be compiled for mobile..then you can call it from your iOS / android GUI using a simple jsonrpc.

Do you have any experience doing this? I would like to use emitter in both iOS and android but don't know where to start.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.