6 ms·
Probably around 2011 I was trying to push for XMPP at a .edu for internal chat (they was no current system at all). Around that time the iPad was showing up ev
by justinsaccount 6y ago
Probably around 2011 I was trying to push for XMPP at a .edu for internal chat (they was no current system at all).
Around that time the iPad was showing up everywhere and I found was that there were zero good iOS XMPP clients. Every single one we tried, I'd notice it was proxying the credentials through a 3rd party server to deal with the lack of background connection support and to handle the push notifications. This was a major security issue, and also meant it would have been unusable during an internet outage.
This sort of thing, combined with the lack of server side history was probably what killed it.
- toast0 6y agoYeah, Android in 2011 could just run a connection in the background and actually work (assuming the client pings when idle / and adapts the ping interval to avoid stateful firewalls with low idle timeouts). But iOS doesn't let you do background sockets, so you need push messages, and that's hard to coordinate between unrelated XMPP servers and clients. Of course, modern Android doesn't let you have background sockets either.
- Arnt 6y agoI have an android app that uses background connections; it works fine on modern Android. The connections are broken when people walk in and out of WLAN coverage, but as long as the app uses minimal CPU and network traffic Android doesn't intercede much.
- toast0 6y agoHmmm. Doesn't Android Doze randomly kill/pause your background execution?
- Arnt 6y agoNot so I've really noticed. The user starting apps that require very much memory probably does too, but that's also a minor effect. If you don't use scheduled jobs to reopen your connections, WLAN/mobile switching is a pain and there are some smaller similar pains. If you solve that big pain and make sure to use very little battery power, the smaller pains go away.