On IOS (webview) after sometime in the background it stops without warning

[Rogério Alan Cruz]

On IOS (webview) after sometime in the background it stops without warning.
I come back and try to send messages and it doesn't arrive to the other connected people.
And when i check if it's connected it says it is:

function amIConnected()
{
    var result = false;
    for(var user in client.core.users)
    {
        if(typeof(client.core.users[user])=='object' && user!='$family')
        {
            if(sender_name_code == client.core.users[user].properties['name'])
            result = true;
        }
    }
    return result;
}

It even gives me all connected users.
But it is not really connected to the channel because no messages get through.
WHAT IS WRONG?

[Louis Charette]

Hi!

As you can see, APE is basically EOL/Dead (See https://github.com/APE-Project/APE_Server/issues/58). You might get some support here, but no new version should be expected.

That being said, I don’t think your problem comes from APE, but from how iOS handle stuff.  You can’t keep something running on Safari (either the browser and in app web view) forever. Otherwise, you would consume most of the device ressources (Data & battery life) in background for nothing. There’s a complex way in iOS apps to do that (which I’m not a specialist of). Long story short, that’s why safari close the connexion to APE when in background for too long. From what I experienced, I would say it keeps everything alive for 30-60 secs. After that, background management stuff is needed. 

In your example, you probably have an outdated users list when you come back, that’s why you can see the « connected » users (new users probably don’t appear).

The best way to work around this in APE (or other socket type thingy) is to detect when the app closes/go to background (window.onunload in JS or something like applicationDidEnterBackground & applicationWillEnterForeground in your AppDelegate on iOS native), tell the server to hold on to the message it need to send to you and close the connexion. When you come back, you get from the server what happened while you where away and restore the connexion. While in background, Apple Push Notification (APN) should be used from the [APE] server to notify the user (way more simple and efficient).

Again, depending of what exactly you want to do with APE on iOS, APN would probably be way some simple to use than an APE solution. The only advantage I see to using APE (or other socket type connection) in an iOS app is if the volume of notification/data being sent (request per second) is really high. For low volume, it’s much easier to stick to APN / NSMutableURLRequest.

If you really want to go the APE way on iOS, you can also check this native Client I wrote a couples of years ago: https://github.com/lcharette/APE_iOS_Client

It’s very experimental and has never been tested on a real life App Store available app (My App got rejected for unrelated reasons before I could implement APE in it), but you will get a global ideas on how it works.

  - Louis

--
--
You received this message because you are subscribed to the Google
Groups "APE Project" group.
To post to this group, send email to ape-p...@googlegroups.com
To unsubscribe from this group, send email to
ape-project...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/ape-project?hl=en
---
APE Project (Ajax Push Engine)
Official website : http://www.ape-project.org/
Git Hub : http://github.com/APE-Project/

---
You received this message because you are subscribed to the Google Groups "APE Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ape-project...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.