The other 2 problems with your app getting killed is: 1) Your presence will be unavailable, so people are potentially less likely to contact you. 2) You will no longer receive VoIP Calls, which is the real purpose of the background socket.
Maybe we are talking about 2 different problems with 2 different solutions? Spencer On Tue, Oct 29, 2013 at 11:03 AM, Dave Cridland <d...@cridland.net> wrote: > > > > On Tue, Oct 29, 2013 at 9:02 AM, Spencer MacDonald < > spencer.macdonald.ot...@gmail.com> wrote: > >> I think your under estimating the amount of messages somebody receives in >> an active chat, especially when some people tend to split their messages up >> like so: >> > > I try not to talk to such people. > > But seriously, while it could easily be that my patterns are different, my > message traffic is usually way lower than 3/min. I used to graph such > things, but based on simple counting it doesn't seem that high. > > >> Moreover if your mobile app has a Desktop counterpart you might end up >> being a participant in one or more group chats, like you said could end up >> generating a lot of traffic. >> >> > Right, being able to distinguish from important messages and background > traffic in a MUC environment is hard, of course, but possible - the clients > manage to identify the user's nickname in messages, for instance, so > therefore so could the server. > > >> Also (iOS specific again, sorry) your not allowed to use the background >> socket for "messages" anyway, thats what push notifications are for. Also >> the user is not informed in any way that the app has been killed so they >> wouldn't bother to relaunch it, thus not resuming the stream until the next >> time they want to send a message. >> >> > No, the user wouldn't be informed the app has been killed, but would see a > notification that a message is deliverable when offline. > > Dave. >
