For me as a user of indi-enabled programs and skysafari the main point would be ability to use both at the same time without disturbing the calibration and workings of any of the programs. This is really the main point. The applications have strengths and weaknesses. I would love to use S-S on my phone at the scope while not loosing control from the client running on my PC (I use linux, you will probably not support linux in the near future ...).
Regarding UI - Jasem should weight on this but I think it should be reasonably easy to expose indi properties in your UI without disrupting your design. You have different setup screens for different mounts already - this will be just another one.
There are at least two android clients for indi (remote observatory and ipparcos).

... and third INDI client for Android - KStars Lite .

And if I may put down my two cents as a paying and satisfied customer of SkySafari 5 Pro - *please* at least consider implementing this bridge. It will make your program much more useful for people like me - running the scope from the RPi and controlling it remotely from the PC. Right now it is only useful for playing and demonstrations. If I want to do anything more serious I need to drop it and change to INDI.
I would also vote for Linux support - but that is quite different story...

Jochym,
do you know about the SkySafari 5 for Android?

Sure. I am a user of this version. I have no OSX machines to run it on

Hi!
sorry for bringing up an old topic - but I wrote a LX200 client (that works with KStars, CdC and so on), and I encounter the same problem. When connecting via SkySafari 6 on an android device, connection is established, :GR# is received, a reply is being sent (i use standard C++ and the classical socket mechanism). After that send, the socket goes into an "Bad Address" state and further requests are being ignored. Could that be the problem? And does anyone have an idea how this can be solved? And why does it work with anything else?

BTW, it also works with QTCPServer sockets, which is even more mysterious to me ...

yours
wolfgang

Hi! I found the problem. Sky Safari closes the socket after each write and tries to reconnect. If you don't take care of this on the other side, the socket is dead for further reads. This is in my opinion a bug in SkySafari - or they tried to "flush" the socket with the close command. a workaround is to set the server socket to reuse the port (SO_REUSEADDR) and to set it to immediate shutdown (using SO_LINGER with 0s grace period). If the server closes the receiving socket using "shutdown" and "close", and starts accepting incoming connections immediately after each "write" to SkySafari, it works somehow ...
yours
wolfi

I wonder if this affects the INDI SkyWatcher bridge driver somehow as well.

hi!
this i cannot say - however, look at the traffic:
SSafari (192.168.4.12) sends a request (SYN) and is accepted by the server (192.168.4.1)
SSafari sends an LX command (:GR#) in this case
Server responds
SSafari ACKnowledges and does a FIN signal
the remainder is the result of my reaction as i shutdown socket (that is the RST)
SSafari sends another SYN and is, in this case accepted again.

If I don't do this, SSafari sends a FIN and a millisecond later a SYN request comes in. in this case, no RST takes place. I do not claim to be the worlds greatest programmer or expert on TCP/IP, but to this looks as if they kill the client on their side after each write. QTCPServer sockets "tolerate" this, I do not know why yet. BSD standard sockets react on that FIN signal ...
yours
wolfi

This is using SkySafari 5 or 6?

SkySafari 6 pro

hI!
an addendum: in my previous screenshot you see that the server shuts down - this is the effect of my brutal countermeasure. this screenshot now is the traffic if i don't shutdown on server side; this one now is another server that is setup the way W. R.Stevens taught us: bind - listen - accept - recv/send and so on: the first two packets are the connect request (SYN) from SSafari (192.168.4.12) and the accept from the server (192.168.4.1); what follows is a little chitchat, and then (packets 8 and 9) - BLAM (SSafari closes the connection with a FIN). 1.3 ms later it begs for a new connect (packet 9) ... the socket on the server side is, however, dead at that point in time, it was half closed ....

... took me 1.5 weeks to figure this out ...
yours wolfi