Added 'email' attribute to mobi:cloudPush component. Modified CloudPushRenderer to use the provided email address for cloud push notification when the request comes from a desktop browser. Modified cloud push demo bean to hold the email provided by the user. Also modified cloudpush-eample.xhtml page to render input field for the email address when rendered in a desktop browser.

Oops, I forgot to mention that Java Mail library needs to be added to application's WEB-INF/lib. This is where you can get it: http://www.oracle.com/technetwork/java/javamail/index-138643.html

Jack, please have a look at cloud push side of this test. After I configured correctly the SMTP server and credentials I still could not see the cloud push notification. While debugging I discovered that cloud push notification is not even triggered for some reason.

Yes, the browser needs to be closed so that the normal notification is not received. I believe having this described in the demo should be fine. We could also shutdown the blocking connection programmatically (with a button in the page, maybe).

I also confirmed this one to be working using FF 35 and my ICEsoft e-mail account.

Modified ICEpush to still use cookies (in parallel with parameters) to keep track of the browser ID. This is necessary for the use case where the push ID is generated on the server and sent to the browser along with the markup of the page.

Added to the cloud push demo a button for closing the blocking connection so the user can remain on the page and test away the priority push notifications. This button avoids having the pushID discarded when window is closed (which in turn discards the priority message that was just sent).

Tested with ICEfaces 4 trunk r44189. Tomcat 7, ios 7 and android 4.4.2.
1.) Using the Disconnect Push button does allow the sending of messages without minimizing the browser however the messages come much later (3 mins) as opposed to the browser minimize method which takes < 1 min.
2.) Attempting to access the showcase demo (with anything appended to the URL such as /showcase-mobile.jsf , direct link to any demo or bookmark) in desktop browsers or devices can cause the following server error and showcase can not be reached:
Mar 10, 2015 10:37:00 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/showcase] threw exception [null] with root cause
java.lang.NullPointerException
at org.icepush.Browser.getBrowserIDFromCookie(Browser.java:250)
at org.icepush.Browser.getBrowserID(Browser.java:80)
at org.icepush.PushContext.createPushId(PushContext.java:89)
at org.icefaces.impl.event.BridgeSetup.generateViewID(BridgeSetup.java:270)
at org.icefaces.impl.event.BridgeSetup.assignViewID(BridgeSetup.java:261)
at org.icefaces.impl.event.BridgeSetup.access$300(BridgeSetup.java:44)
at org.icefaces.impl.event.BridgeSetup$AssignViewID.beforePhase(BridgeSetup.java:293)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1852)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

1) I don't think we have a problem here. The delay depends on when the server discovers that the blocking connection is not recreated and the fixed interval that server waits until it decides to send the cloud push notification.

2) This issue was fixed as a commit for PUSH-348.

Verified ICEfaces EE-4.0.0 r41144. Tomcat 7, IE 11, FF 34, Chrome 40, ios 7