[aerogear-dev] Push!

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] Push!

Glen Daniels

Hey team,

So thinking a bit about the Android roadmap, and realizing that for
either the Android or the iOS libs to work well (i.e. without killing
the batteries of end-users' phones), we're going to need to do push
integration.

A quick recap - if we want to know when data on the backend has been
updated without a manual "refresh" button, we either have to 1) poll
(which sucks, uses network resources, and doesn't work in the background
on iOS devices) or 2) use push (for which there are specific APIs for
Android and iOS, and there are also "higher level" push service
providers such as Urban Airship).

Yes, polling can be used as a fallback, but for any serious application
that needs live or background updates, push is the only way to go.  Yes,
this means another coupling point to "our" server (or at least
contract-compatible servers).

Just wanting to make sure that this is on everyone's radar.

Thoughts/comments?

--Glen
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Burr Sutter
I was thinking about this same topic last week :-)

I wonder if we can "port" a PHP or Node.js  option over to Java.


I spent a couple of hours trying to get a Cordova app + Urban Airship working last week but run into a problem.  I need to revisit it this week. 


On Sep 17, 2012, at 7:01 PM, Glen Daniels wrote:


Hey team,

So thinking a bit about the Android roadmap, and realizing that for
either the Android or the iOS libs to work well (i.e. without killing
the batteries of end-users' phones), we're going to need to do push
integration.

A quick recap - if we want to know when data on the backend has been
updated without a manual "refresh" button, we either have to 1) poll
(which sucks, uses network resources, and doesn't work in the background
on iOS devices) or 2) use push (for which there are specific APIs for
Android and iOS, and there are also "higher level" push service
providers such as Urban Airship).

Yes, polling can be used as a fallback, but for any serious application
that needs live or background updates, push is the only way to go.  Yes,
this means another coupling point to "our" server (or at least
contract-compatible servers).

Just wanting to make sure that this is on everyone's radar.

Thoughts/comments?

--Glen
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Burr Sutter
A node version 


On Sep 17, 2012, at 7:25 PM, Burr Sutter wrote:

I was thinking about this same topic last week :-)

I wonder if we can "port" a PHP or Node.js  option over to Java.


I spent a couple of hours trying to get a Cordova app + Urban Airship working last week but run into a problem.  I need to revisit it this week. 


On Sep 17, 2012, at 7:01 PM, Glen Daniels wrote:


Hey team,

So thinking a bit about the Android roadmap, and realizing that for
either the Android or the iOS libs to work well (i.e. without killing
the batteries of end-users' phones), we're going to need to do push
integration.

A quick recap - if we want to know when data on the backend has been
updated without a manual "refresh" button, we either have to 1) poll
(which sucks, uses network resources, and doesn't work in the background
on iOS devices) or 2) use push (for which there are specific APIs for
Android and iOS, and there are also "higher level" push service
providers such as Urban Airship).

Yes, polling can be used as a fallback, but for any serious application
that needs live or background updates, push is the only way to go.  Yes,
this means another coupling point to "our" server (or at least
contract-compatible servers).

Just wanting to make sure that this is on everyone's radar.

Thoughts/comments?

--Glen
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Jay Balunas
In reply to this post by Glen Daniels
Yes, push notifications is something we certainly have considered, but need to get more concrete roadmaps in place.  The most obvious use is extending messaging, and CDI events, but data syncing is also valid.  

IMO - the biggest concern with push is setup, and frequency.  These needs to be considered and be an active option for developers.  We also want to think about this as a secondary priority to initial basic options imo.  

The concern about server-side coupling is valid, but we should be able to get around that by defining the expected message formats and connections + the required config options.

----- Original Message -----

>
> Hey team,
>
> So thinking a bit about the Android roadmap, and realizing that for
> either the Android or the iOS libs to work well (i.e. without killing
> the batteries of end-users' phones), we're going to need to do push
> integration.
>
> A quick recap - if we want to know when data on the backend has been
> updated without a manual "refresh" button, we either have to 1) poll
> (which sucks, uses network resources, and doesn't work in the
> background
> on iOS devices) or 2) use push (for which there are specific APIs for
> Android and iOS, and there are also "higher level" push service
> providers such as Urban Airship).
>
> Yes, polling can be used as a fallback, but for any serious
> application
> that needs live or background updates, push is the only way to go.
>  Yes,
> this means another coupling point to "our" server (or at least
> contract-compatible servers).
>
> Just wanting to make sure that this is on everyone's radar.
>
> Thoughts/comments?
>
> --Glen
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Marius Bogoevici
Off the top of my head (and I'm sure that this has been discussed within the AG team extensively already), a CDI-driven push mechanism (that Java EE developers could just hook in their apps) would be great.

On 2012-09-17, at 8:01 PM, Jay Balunas <[hidden email]> wrote:

> Yes, push notifications is something we certainly have considered, but need to get more concrete roadmaps in place.  The most obvious use is extending messaging, and CDI events, but data syncing is also valid.  
>
> IMO - the biggest concern with push is setup, and frequency.  These needs to be considered and be an active option for developers.  We also want to think about this as a secondary priority to initial basic options imo.  
>
> The concern about server-side coupling is valid, but we should be able to get around that by defining the expected message formats and connections + the required config options.
>
> ----- Original Message -----
>>
>> Hey team,
>>
>> So thinking a bit about the Android roadmap, and realizing that for
>> either the Android or the iOS libs to work well (i.e. without killing
>> the batteries of end-users' phones), we're going to need to do push
>> integration.
>>
>> A quick recap - if we want to know when data on the backend has been
>> updated without a manual "refresh" button, we either have to 1) poll
>> (which sucks, uses network resources, and doesn't work in the
>> background
>> on iOS devices) or 2) use push (for which there are specific APIs for
>> Android and iOS, and there are also "higher level" push service
>> providers such as Urban Airship).
>>
>> Yes, polling can be used as a fallback, but for any serious
>> application
>> that needs live or background updates, push is the only way to go.
>>  Yes,
>> this means another coupling point to "our" server (or at least
>> contract-compatible servers).
>>
>> Just wanting to make sure that this is on everyone's radar.
>>
>> Thoughts/comments?
>>
>> --Glen
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Matthias Wessendorf
In reply to this post by Glen Daniels
On Tue, Sep 18, 2012 at 1:01 AM, Glen Daniels <[hidden email]> wrote:

>
> Hey team,
>
> So thinking a bit about the Android roadmap, and realizing that for
> either the Android or the iOS libs to work well (i.e. without killing
> the batteries of end-users' phones), we're going to need to do push
> integration.
>
> A quick recap - if we want to know when data on the backend has been
> updated without a manual "refresh" button, we either have to 1) poll
> (which sucks, uses network resources, and doesn't work in the background
> on iOS devices) or 2) use push (for which there are specific APIs for
> Android and iOS, and there are also "higher level" push service
> providers such as Urban Airship).

AFAIK the (apple) push payload size is limited, so it will be mostly
some combination of push/poll.
The 'push' tells the app: Some data has changed, go online and 'pull' it.

IMO another option would be WebSocket, when the app is online. If it's
offline, of course the message would not make it to the device, here
comes 'push' in again.


>
> Yes, polling can be used as a fallback, but for any serious application
> that needs live or background updates, push is the only way to go.  Yes,
> this means another coupling point to "our" server (or at least
> contract-compatible servers).

Right, but not sure if it's that bad if we make this available as a
'somewhat' generic server side component, to be deployed to JBoss
(never dealt with push)

-M

>
> Just wanting to make sure that this is on everyone's radar.
>
> Thoughts/comments?
>
> --Glen
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Matthias Wessendorf
In reply to this post by Marius Bogoevici
agreed,

CDI events (similar like JMS events) are a good fit

-M

On Tue, Sep 18, 2012 at 3:26 AM, Marius Bogoevici <[hidden email]> wrote:

> Off the top of my head (and I'm sure that this has been discussed within the AG team extensively already), a CDI-driven push mechanism (that Java EE developers could just hook in their apps) would be great.
>
> On 2012-09-17, at 8:01 PM, Jay Balunas <[hidden email]> wrote:
>
>> Yes, push notifications is something we certainly have considered, but need to get more concrete roadmaps in place.  The most obvious use is extending messaging, and CDI events, but data syncing is also valid.
>>
>> IMO - the biggest concern with push is setup, and frequency.  These needs to be considered and be an active option for developers.  We also want to think about this as a secondary priority to initial basic options imo.
>>
>> The concern about server-side coupling is valid, but we should be able to get around that by defining the expected message formats and connections + the required config options.
>>
>> ----- Original Message -----
>>>
>>> Hey team,
>>>
>>> So thinking a bit about the Android roadmap, and realizing that for
>>> either the Android or the iOS libs to work well (i.e. without killing
>>> the batteries of end-users' phones), we're going to need to do push
>>> integration.
>>>
>>> A quick recap - if we want to know when data on the backend has been
>>> updated without a manual "refresh" button, we either have to 1) poll
>>> (which sucks, uses network resources, and doesn't work in the
>>> background
>>> on iOS devices) or 2) use push (for which there are specific APIs for
>>> Android and iOS, and there are also "higher level" push service
>>> providers such as Urban Airship).
>>>
>>> Yes, polling can be used as a fallback, but for any serious
>>> application
>>> that needs live or background updates, push is the only way to go.
>>>  Yes,
>>> this means another coupling point to "our" server (or at least
>>> contract-compatible servers).
>>>
>>> Just wanting to make sure that this is on everyone's radar.
>>>
>>> Thoughts/comments?
>>>
>>> --Glen
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Burr Sutter
In reply to this post by Matthias Wessendorf

On Sep 18, 2012, at 1:31 AM, Matthias Wessendorf wrote:

> On Tue, Sep 18, 2012 at 1:01 AM, Glen Daniels <[hidden email]> wrote:
>>
>> Hey team,
>>
>> So thinking a bit about the Android roadmap, and realizing that for
>> either the Android or the iOS libs to work well (i.e. without killing
>> the batteries of end-users' phones), we're going to need to do push
>> integration.
>>
>> A quick recap - if we want to know when data on the backend has been
>> updated without a manual "refresh" button, we either have to 1) poll
>> (which sucks, uses network resources, and doesn't work in the background
>> on iOS devices) or 2) use push (for which there are specific APIs for
>> Android and iOS, and there are also "higher level" push service
>> providers such as Urban Airship).
>
> AFAIK the (apple) push payload size is limited, so it will be mostly
> some combination of push/poll.
> The 'push' tells the app: Some data has changed, go online and 'pull' it.
+1

>
> IMO another option would be WebSocket, when the app is online. If it's
> offline, of course the message would not make it to the device, here
> comes 'push' in again.
+1 - websocket is valuable for the "online" scenario - but does not address the "offline" (or app turned off) scenario

>
>
>>
>> Yes, polling can be used as a fallback, but for any serious application
>> that needs live or background updates, push is the only way to go.  Yes,
>> this means another coupling point to "our" server (or at least
>> contract-compatible servers).
>
> Right, but not sure if it's that bad if we make this available as a
> 'somewhat' generic server side component, to be deployed to JBoss
> (never dealt with push)
>
> -M
>
>>
>> Just wanting to make sure that this is on everyone's radar.
>>
>> Thoughts/comments?
>>
>> --Glen
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Burr Sutter
In reply to this post by Matthias Wessendorf
Would CDI events handle the scenario of 100K end-users (with unique deviceIDs) receiving their push notifications? - I believe Apple allows for approximately 20 messages at a time - so pushes need to be queued and managed.

I will try to investigate more...just need to find enough time.

On Sep 18, 2012, at 1:33 AM, Matthias Wessendorf wrote:

> agreed,
>
> CDI events (similar like JMS events) are a good fit
>
> -M
>
> On Tue, Sep 18, 2012 at 3:26 AM, Marius Bogoevici <[hidden email]> wrote:
>> Off the top of my head (and I'm sure that this has been discussed within the AG team extensively already), a CDI-driven push mechanism (that Java EE developers could just hook in their apps) would be great.
>>
>> On 2012-09-17, at 8:01 PM, Jay Balunas <[hidden email]> wrote:
>>
>>> Yes, push notifications is something we certainly have considered, but need to get more concrete roadmaps in place.  The most obvious use is extending messaging, and CDI events, but data syncing is also valid.
>>>
>>> IMO - the biggest concern with push is setup, and frequency.  These needs to be considered and be an active option for developers.  We also want to think about this as a secondary priority to initial basic options imo.
>>>
>>> The concern about server-side coupling is valid, but we should be able to get around that by defining the expected message formats and connections + the required config options.
>>>
>>> ----- Original Message -----
>>>>
>>>> Hey team,
>>>>
>>>> So thinking a bit about the Android roadmap, and realizing that for
>>>> either the Android or the iOS libs to work well (i.e. without killing
>>>> the batteries of end-users' phones), we're going to need to do push
>>>> integration.
>>>>
>>>> A quick recap - if we want to know when data on the backend has been
>>>> updated without a manual "refresh" button, we either have to 1) poll
>>>> (which sucks, uses network resources, and doesn't work in the
>>>> background
>>>> on iOS devices) or 2) use push (for which there are specific APIs for
>>>> Android and iOS, and there are also "higher level" push service
>>>> providers such as Urban Airship).
>>>>
>>>> Yes, polling can be used as a fallback, but for any serious
>>>> application
>>>> that needs live or background updates, push is the only way to go.
>>>> Yes,
>>>> this means another coupling point to "our" server (or at least
>>>> contract-compatible servers).
>>>>
>>>> Just wanting to make sure that this is on everyone's radar.
>>>>
>>>> Thoughts/comments?
>>>>
>>>> --Glen
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Pete Muir
"CDI events" are a programming model (API) not an implementation. I don't think the API would constrain scalability here, the thing that would constrain scalability would be (as usual) around how the bus was implemented from the JVM to the phone (aka IO).

On 18 Sep 2012, at 13:45, Burr Sutter wrote:

> Would CDI events handle the scenario of 100K end-users (with unique deviceIDs) receiving their push notifications? - I believe Apple allows for approximately 20 messages at a time - so pushes need to be queued and managed.
>
> I will try to investigate more...just need to find enough time.
>
> On Sep 18, 2012, at 1:33 AM, Matthias Wessendorf wrote:
>
>> agreed,
>>
>> CDI events (similar like JMS events) are a good fit
>>
>> -M
>>
>> On Tue, Sep 18, 2012 at 3:26 AM, Marius Bogoevici <[hidden email]> wrote:
>>> Off the top of my head (and I'm sure that this has been discussed within the AG team extensively already), a CDI-driven push mechanism (that Java EE developers could just hook in their apps) would be great.
>>>
>>> On 2012-09-17, at 8:01 PM, Jay Balunas <[hidden email]> wrote:
>>>
>>>> Yes, push notifications is something we certainly have considered, but need to get more concrete roadmaps in place.  The most obvious use is extending messaging, and CDI events, but data syncing is also valid.
>>>>
>>>> IMO - the biggest concern with push is setup, and frequency.  These needs to be considered and be an active option for developers.  We also want to think about this as a secondary priority to initial basic options imo.
>>>>
>>>> The concern about server-side coupling is valid, but we should be able to get around that by defining the expected message formats and connections + the required config options.
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>> Hey team,
>>>>>
>>>>> So thinking a bit about the Android roadmap, and realizing that for
>>>>> either the Android or the iOS libs to work well (i.e. without killing
>>>>> the batteries of end-users' phones), we're going to need to do push
>>>>> integration.
>>>>>
>>>>> A quick recap - if we want to know when data on the backend has been
>>>>> updated without a manual "refresh" button, we either have to 1) poll
>>>>> (which sucks, uses network resources, and doesn't work in the
>>>>> background
>>>>> on iOS devices) or 2) use push (for which there are specific APIs for
>>>>> Android and iOS, and there are also "higher level" push service
>>>>> providers such as Urban Airship).
>>>>>
>>>>> Yes, polling can be used as a fallback, but for any serious
>>>>> application
>>>>> that needs live or background updates, push is the only way to go.
>>>>> Yes,
>>>>> this means another coupling point to "our" server (or at least
>>>>> contract-compatible servers).
>>>>>
>>>>> Just wanting to make sure that this is on everyone's radar.
>>>>>
>>>>> Thoughts/comments?
>>>>>
>>>>> --Glen
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Push!

Jay Balunas
In an ideal world the IDM implementation should be able to to track UUID's for devices.  The api for push would be able to trigger based on user, role, group, or sets of specific UUIDs.  The push system would then manage the details of the push operation, validating msg size, breaking the msgs up into chunks, etc...  In a perfect world the user would not even need to know if the push would be native or non-native.


On Sep 18, 2012, at 8:50 AM, Pete Muir wrote:

> "CDI events" are a programming model (API) not an implementation. I don't think the API would constrain scalability here, the thing that would constrain scalability would be (as usual) around how the bus was implemented from the JVM to the phone (aka IO).
>
> On 18 Sep 2012, at 13:45, Burr Sutter wrote:
>
>> Would CDI events handle the scenario of 100K end-users (with unique deviceIDs) receiving their push notifications? - I believe Apple allows for approximately 20 messages at a time - so pushes need to be queued and managed.
>>
>> I will try to investigate more...just need to find enough time.
>>
>> On Sep 18, 2012, at 1:33 AM, Matthias Wessendorf wrote:
>>
>>> agreed,
>>>
>>> CDI events (similar like JMS events) are a good fit
>>>
>>> -M
>>>
>>> On Tue, Sep 18, 2012 at 3:26 AM, Marius Bogoevici <[hidden email]> wrote:
>>>> Off the top of my head (and I'm sure that this has been discussed within the AG team extensively already), a CDI-driven push mechanism (that Java EE developers could just hook in their apps) would be great.
>>>>
>>>> On 2012-09-17, at 8:01 PM, Jay Balunas <[hidden email]> wrote:
>>>>
>>>>> Yes, push notifications is something we certainly have considered, but need to get more concrete roadmaps in place.  The most obvious use is extending messaging, and CDI events, but data syncing is also valid.
>>>>>
>>>>> IMO - the biggest concern with push is setup, and frequency.  These needs to be considered and be an active option for developers.  We also want to think about this as a secondary priority to initial basic options imo.
>>>>>
>>>>> The concern about server-side coupling is valid, but we should be able to get around that by defining the expected message formats and connections + the required config options.
>>>>>
>>>>> ----- Original Message -----
>>>>>>
>>>>>> Hey team,
>>>>>>
>>>>>> So thinking a bit about the Android roadmap, and realizing that for
>>>>>> either the Android or the iOS libs to work well (i.e. without killing
>>>>>> the batteries of end-users' phones), we're going to need to do push
>>>>>> integration.
>>>>>>
>>>>>> A quick recap - if we want to know when data on the backend has been
>>>>>> updated without a manual "refresh" button, we either have to 1) poll
>>>>>> (which sucks, uses network resources, and doesn't work in the
>>>>>> background
>>>>>> on iOS devices) or 2) use push (for which there are specific APIs for
>>>>>> Android and iOS, and there are also "higher level" push service
>>>>>> providers such as Urban Airship).
>>>>>>
>>>>>> Yes, polling can be used as a fallback, but for any serious
>>>>>> application
>>>>>> that needs live or background updates, push is the only way to go.
>>>>>> Yes,
>>>>>> this means another coupling point to "our" server (or at least
>>>>>> contract-compatible servers).
>>>>>>
>>>>>> Just wanting to make sure that this is on everyone's radar.
>>>>>>
>>>>>> Thoughts/comments?
>>>>>>
>>>>>> --Glen
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev