8:31 a.m.
Good Morning all !
As you might know, we are currently adding Amazon Device Messaging support
to the UnifiedPush server.
The server side has been PRed and it's now time to work on the client SDK.
As you probably know, the amazon devices : the Kindle Fire (2nd and third
generation), Fire Phone and FireTV are running FireOS which is basically a
fork of Android OS. And since we have an Android Push SDK I start looking
if we could reuse it.
First good news, is that since AGDroid 2.0, things has been nicely isolated
and is open for extension. But there is still some refactoring to do, the
"UPS Registration" flow/logic is still in the "gcm" package[1]. That
logic
should be moved one package level higher in a new Abstract class.
In the end we will have a "gcm" package and a "adm" package (or
project,
see later in my questions)
This way the ADM logic would be able to reuse that registration code. I
started to play a bit with this refactoring here[2], disclaimer here, I'm
not even sure that this code compiles, is just to give an idea.
So before I go further, some questions (mainly for our Android Gods ;) )
:
- Is this a good idea (reusing your SDK) ? I think yes, even if there is
some time and effort needed for refactoring to make it completly generic.
- How do we build / package / deliver ? We probably want 2 distinct
JAR/aar. We could use profile in Maven to only package one feature but that
sounds a bit "messy".
What about having sub-projects, this way we would have
aerogear-android-push and then : aerogear-android-push-gcm and
aerogear-push-gcm.
- The registration flow for ADM[3] (so device <-> Amazon's server) is a bit
different thant the GCM one
, it's the same interface that receive the registration event and the push
notification events. We have to check how this fit with the current
architecture of android-push.
Other challenge will be shipping ADM jar, since this one is on Maven and
must be downloaded manually but that is for later ;)
Sebi
[1]
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
[2] https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
[3]
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
9:56 a.m.
On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Good Morning all !
As you might know, we are currently adding Amazon Device Messaging support
to the UnifiedPush server.
The server side has been PRed and it's now time to work on the client SDK.
once our java-adm is on maven central, I will take a look at the PR
As you probably know, the amazon devices : the Kindle Fire (2nd and
third
generation), Fire Phone and FireTV are running FireOS which is basically a
fork of Android OS. And since we have an Android Push SDK I start looking
if we could reuse it.
First good news, is that since AGDroid 2.0, things has been nicely
isolated and is open for extension. But there is still some refactoring to
do, the "UPS Registration" flow/logic is still in the "gcm"
package[1].
the package name shouldn't be the smallest concern :-)
That logic should be moved one package level higher in a new
Abstract
class.
In the end we will have a "gcm" package and a "adm" package (or
project,
see later in my questions)
+1
This way the ADM logic would be able to reuse that registration code. I
started to play a bit with this refactoring here[2], disclaimer here, I'm
not even sure that this code compiles, is just to give an idea.
So before I go further, some questions (mainly for our Android Gods ;) )
:
- Is this a good idea (reusing your SDK) ? I think yes, even if there is
some time and effort needed for refactoring to make it completly generic.
sounds reasonable to me, to extend it and apply changes on a separate
ADM-PUSH-SDK
- How do we build / package / deliver ?
gradle? or, what does Amazon do / prefer ?
We probably want 2 distinct JAR/aar. We could use profile in Maven to
only
package one feature but that sounds a bit "messy".
What about having sub-projects, this way we would have
aerogear-android-push and then : aerogear-android-push-gcm and
aerogear-push-gcm.
Not sure I get that, but do you mean "aerogear-android-push"
- aerogear-android-push-gcm
- aerogear-android-push-adm
sounds reasonable
- The registration flow for ADM[3] (so device <-> Amazon's server) is a
bit different thant the GCM one
, it's the same interface that receive the registration event and the push
notification events. We have to check how this fit with the current
architecture of android-push.
Other challenge will be shipping ADM jar, since this one is on Maven and
must be downloaded manually but that is for later ;)
not sure, why do we need to ship it? what's the license? Why do I need a
manual download from maven ? Not following here
Sebi
[1]
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
[2]
https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
[3]
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
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
10:07 a.m.
On 02/03/2015 09:56 AM, Matthias Wessendorf wrote:
On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc <scm.blanc(a)gmail.com
<mailto:scm.blanc@gmail.com>> wrote:
Good Morning all !
As you might know, we are currently adding Amazon Device Messaging
support to the UnifiedPush server.
The server side has been PRed and it's now time to work on the
client SDK.
once our java-adm is on maven central, I will take a look at the PR
As you probably know, the amazon devices : the Kindle Fire (2nd
and third generation), Fire Phone and FireTV are running FireOS
which is basically a fork of Android OS. And since we have an
Android Push SDK I start looking if we could reuse it.
First good news, is that since AGDroid 2.0, things has been nicely
isolated and is open for extension. But there is still some
refactoring to do, the "UPS Registration" flow/logic is still in
the "gcm" package[1].
the package name shouldn't be the smallest concern :-)
That logic should be moved one package level higher in a new
Abstract class.
In the end we will have a "gcm" package and a "adm" package (or
project, see later in my questions)
+1
This way the ADM logic would be able to reuse that registration
code. I started to play a bit with this refactoring here[2],
disclaimer here, I'm not even sure that this code compiles, is
just to give an idea.
So before I go further, some questions (mainly for our Android
Gods ;) ) :
- Is this a good idea (reusing your SDK) ? I think yes, even if
there is some time and effort needed for refactoring to make it
completly generic.
sounds reasonable to me, to extend it and apply changes on a separate
ADM-PUSH-SDK
- How do we build / package / deliver ?
gradle? or, what does Amazon do / prefer ?
We probably want 2 distinct JAR/aar. We could use profile in Maven
to only package one feature but that sounds a bit "messy".
What about having sub-projects, this way we would have
aerogear-android-push and then : aerogear-android-push-gcm and
aerogear-push-gcm.
Not sure I get that, but do you mean "aerogear-android-push"
- aerogear-android-push-gcm
- aerogear-android-push-adm
sounds reasonable
No it isn't. For starters it will break the 2.0 API and
require a 3.0
API release.
- The registration flow for ADM[3] (so device <-> Amazon's server)
is a bit different thant the GCM one
, it's the same interface that receive the registration event and
the push notification events. We have to check how this fit with
the current architecture of android-push.
Other challenge will be shipping ADM jar, since this one is on
Maven and must be downloaded manually but that is for later ;)
not sure, why do we need to ship it? what's the license? Why do I need
a manual download from maven ? Not following here
Amazon's SDK is a giant zip
bundle. We will need to find a way to
package it into the local maven repo.
They do publish some things to central, but it looks like that is their
AWS APIs but not ADM.
Sebi
[1]https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-...
[2]
https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
[3]
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
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
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.
10:13 a.m.
On 02/03/2015 10:07 AM, Summers Pittman wrote:
On 02/03/2015 09:56 AM, Matthias Wessendorf wrote:
>
>
> On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc <scm.blanc(a)gmail.com
> <mailto:scm.blanc@gmail.com>> wrote:
>
> Good Morning all !
>
> As you might know, we are currently adding Amazon Device
> Messaging support to the UnifiedPush server.
> The server side has been PRed and it's now time to work on the
> client SDK.
>
>
> once our java-adm is on maven central, I will take a look at the PR
>
> As you probably know, the amazon devices : the Kindle Fire (2nd
> and third generation), Fire Phone and FireTV are running FireOS
> which is basically a fork of Android OS. And since we have an
> Android Push SDK I start looking if we could reuse it.
>
> First good news, is that since AGDroid 2.0, things has been
> nicely isolated and is open for extension. But there is still
> some refactoring to do, the "UPS Registration" flow/logic is
> still in the "gcm" package[1].
>
>
> the package name shouldn't be the smallest concern :-)
>
> That logic should be moved one package level higher in a new
> Abstract class.
> In the end we will have a "gcm" package and a "adm" package
(or
> project, see later in my questions)
>
>
> +1
>
>
> This way the ADM logic would be able to reuse that registration
> code. I started to play a bit with this refactoring here[2],
> disclaimer here, I'm not even sure that this code compiles, is
> just to give an idea.
>
> So before I go further, some questions (mainly for our Android
> Gods ;) ) :
>
> - Is this a good idea (reusing your SDK) ? I think yes, even if
> there is some time and effort needed for refactoring to make it
> completly generic.
>
>
> sounds reasonable to me, to extend it and apply changes on a separate
> ADM-PUSH-SDK
>
>
> - How do we build / package / deliver ?
>
>
> gradle? or, what does Amazon do / prefer ?
>
> We probably want 2 distinct JAR/aar. We could use profile in
> Maven to only package one feature but that sounds a bit "messy".
> What about having sub-projects, this way we would have
> aerogear-android-push and then : aerogear-android-push-gcm and
> aerogear-push-gcm.
>
>
> Not sure I get that, but do you mean "aerogear-android-push"
> - aerogear-android-push-gcm
> - aerogear-android-push-adm
>
> sounds reasonable
No it isn't. For starters it will break the 2.0 API and require a 3.0
API release.
>
>
> - The registration flow for ADM[3] (so device <-> Amazon's
> server) is a bit different thant the GCM one
> , it's the same interface that receive the registration event and
> the push notification events. We have to check how this fit with
> the current architecture of android-push.
>
> Other challenge will be shipping ADM jar, since this one is on
> Maven and must be downloaded manually but that is for later ;)
>
>
> not sure, why do we need to ship it? what's the license? Why do I
> need a manual download from maven ? Not following here
Amazon's SDK is a giant zip bundle. We will need to find a way to
package it into the local maven repo.
They do publish some things to central, but it looks like that is
their AWS APIs but not ADM.
Sorry to self reply, but does anyone know anyone inside
of Amazon that
we could possibly work with to get ADM in a more sane distribution
mechanism?
>
> Sebi
>
>
>
[1]https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-...
> [2]
> https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
> [3]
>
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> 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
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.
10:26 a.m.
On Tue, Feb 3, 2015 at 4:07 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 02/03/2015 09:56 AM, Matthias Wessendorf wrote:
On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
> Good Morning all !
>
> As you might know, we are currently adding Amazon Device Messaging
> support to the UnifiedPush server.
> The server side has been PRed and it's now time to work on the client SDK.
>
once our java-adm is on maven central, I will take a look at the PR
> As you probably know, the amazon devices : the Kindle Fire (2nd and
> third generation), Fire Phone and FireTV are running FireOS which is
> basically a fork of Android OS. And since we have an Android Push SDK I
> start looking if we could reuse it.
>
> First good news, is that since AGDroid 2.0, things has been nicely
> isolated and is open for extension. But there is still some refactoring to
> do, the "UPS Registration" flow/logic is still in the "gcm"
package[1].
>
the package name shouldn't be the smallest concern :-)
> That logic should be moved one package level higher in a new Abstract
> class.
> In the end we will have a "gcm" package and a "adm" package (or
project,
> see later in my questions)
>
+1
>
> This way the ADM logic would be able to reuse that registration code. I
> started to play a bit with this refactoring here[2], disclaimer here, I'm
> not even sure that this code compiles, is just to give an idea.
>
> So before I go further, some questions (mainly for our Android Gods ;)
> ) :
>
> - Is this a good idea (reusing your SDK) ? I think yes, even if there
> is some time and effort needed for refactoring to make it completly generic.
>
sounds reasonable to me, to extend it and apply changes on a separate
ADM-PUSH-SDK
>
> - How do we build / package / deliver ?
>
gradle? or, what does Amazon do / prefer ?
> We probably want 2 distinct JAR/aar. We could use profile in Maven to
> only package one feature but that sounds a bit "messy".
> What about having sub-projects, this way we would have
> aerogear-android-push and then : aerogear-android-push-gcm and
> aerogear-push-gcm.
>
Not sure I get that, but do you mean "aerogear-android-push"
- aerogear-android-push-gcm
- aerogear-android-push-adm
sounds reasonable
No it isn't. For starters it will break the 2.0 API and require a 3.0 API
release.
yeah - fair point :-) I smell a future JIRA :-) hehe
>
> - The registration flow for ADM[3] (so device <-> Amazon's server) is a
> bit different thant the GCM one
> , it's the same interface that receive the registration event and the
> push notification events. We have to check how this fit with the current
> architecture of android-push.
>
> Other challenge will be shipping ADM jar, since this one is on Maven
> and must be downloaded manually but that is for later ;)
>
not sure, why do we need to ship it? what's the license? Why do I need a
manual download from maven ? Not following here
Amazon's SDK is a giant zip bundle. We will need to find a way to package
it into the local maven repo.
They do publish some things to central, but it looks like that is their
AWS APIs but not ADM.
>
> Sebi
>
>
> [1]
>
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
> [2]
> https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
> [3]
>
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> 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
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
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
10:31 a.m.
On 02/03/2015 10:26 AM, Matthias Wessendorf wrote:
On Tue, Feb 3, 2015 at 4:07 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
On 02/03/2015 09:56 AM, Matthias Wessendorf wrote:
>
>
> On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc
> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote:
>
> Good Morning all !
>
> As you might know, we are currently adding Amazon Device
> Messaging support to the UnifiedPush server.
> The server side has been PRed and it's now time to work on
> the client SDK.
>
>
> once our java-adm is on maven central, I will take a look at the PR
>
> As you probably know, the amazon devices : the Kindle Fire
> (2nd and third generation), Fire Phone and FireTV are running
> FireOS which is basically a fork of Android OS. And since we
> have an Android Push SDK I start looking if we could reuse it.
>
> First good news, is that since AGDroid 2.0, things has been
> nicely isolated and is open for extension. But there is still
> some refactoring to do, the "UPS Registration" flow/logic is
> still in the "gcm" package[1].
>
>
> the package name shouldn't be the smallest concern :-)
>
> That logic should be moved one package level higher in a new
> Abstract class.
> In the end we will have a "gcm" package and a "adm"
package
> (or project, see later in my questions)
>
>
> +1
>
>
> This way the ADM logic would be able to reuse that
> registration code. I started to play a bit with this
> refactoring here[2], disclaimer here, I'm not even sure that
> this code compiles, is just to give an idea.
>
> So before I go further, some questions (mainly for our
> Android Gods ;) ) :
>
> - Is this a good idea (reusing your SDK) ? I think yes, even
> if there is some time and effort needed for refactoring to
> make it completly generic.
>
>
> sounds reasonable to me, to extend it and apply changes on a
> separate ADM-PUSH-SDK
>
>
> - How do we build / package / deliver ?
>
>
> gradle? or, what does Amazon do / prefer ?
>
> We probably want 2 distinct JAR/aar. We could use profile in
> Maven to only package one feature but that sounds a bit "messy".
> What about having sub-projects, this way we would have
> aerogear-android-push and then : aerogear-android-push-gcm
> and aerogear-push-gcm.
>
>
> Not sure I get that, but do you mean "aerogear-android-push"
> - aerogear-android-push-gcm
> - aerogear-android-push-adm
>
> sounds reasonable
No it isn't. For starters it will break the 2.0 API and require a
3.0 API release.
yeah - fair point :-) I smell a future JIRA :-) hehe
That usually means I need to
take a shower ;)
>
> - The registration flow for ADM[3] (so device <-> Amazon's
> server) is a bit different thant the GCM one
> , it's the same interface that receive the registration event
> and the push notification events. We have to check how this
> fit with the current architecture of android-push.
>
> Other challenge will be shipping ADM jar, since this one is
> on Maven and must be downloaded manually but that is for later ;)
>
>
> not sure, why do we need to ship it? what's the license? Why do I
> need a manual download from maven ? Not following here
Amazon's SDK is a giant zip bundle. We will need to find a way to
package it into the local maven repo.
They do publish some things to central, but it looks like that is
their AWS APIs but not ADM.
>
> Sebi
>
>
>
[1]https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-...
> [2]
> https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
> [3]
>
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> 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
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
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
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.
10:35 a.m.
On Tue, Feb 3, 2015 at 4:07 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 02/03/2015 09:56 AM, Matthias Wessendorf wrote:
On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
> Good Morning all !
>
> As you might know, we are currently adding Amazon Device Messaging
> support to the UnifiedPush server.
> The server side has been PRed and it's now time to work on the client SDK.
>
once our java-adm is on maven central, I will take a look at the PR
> As you probably know, the amazon devices : the Kindle Fire (2nd and
> third generation), Fire Phone and FireTV are running FireOS which is
> basically a fork of Android OS. And since we have an Android Push SDK I
> start looking if we could reuse it.
>
> First good news, is that since AGDroid 2.0, things has been nicely
> isolated and is open for extension. But there is still some refactoring to
> do, the "UPS Registration" flow/logic is still in the "gcm"
package[1].
>
the package name shouldn't be the smallest concern :-)
> That logic should be moved one package level higher in a new Abstract
> class.
> In the end we will have a "gcm" package and a "adm" package (or
project,
> see later in my questions)
>
+1
>
> This way the ADM logic would be able to reuse that registration code. I
> started to play a bit with this refactoring here[2], disclaimer here, I'm
> not even sure that this code compiles, is just to give an idea.
>
> So before I go further, some questions (mainly for our Android Gods ;)
> ) :
>
> - Is this a good idea (reusing your SDK) ? I think yes, even if there
> is some time and effort needed for refactoring to make it completly generic.
>
sounds reasonable to me, to extend it and apply changes on a separate
ADM-PUSH-SDK
>
> - How do we build / package / deliver ?
>
gradle? or, what does Amazon do / prefer ?
> We probably want 2 distinct JAR/aar. We could use profile in Maven to
> only package one feature but that sounds a bit "messy".
> What about having sub-projects, this way we would have
> aerogear-android-push and then : aerogear-android-push-gcm and
> aerogear-push-gcm.
>
Not sure I get that, but do you mean "aerogear-android-push"
- aerogear-android-push-gcm
- aerogear-android-push-adm
sounds reasonable
No it isn't. For starters it will break the 2.0 API and require a 3.0 API
release.
>
> - The registration flow for ADM[3] (so device <-> Amazon's server) is a
> bit different thant the GCM one
> , it's the same interface that receive the registration event and the
> push notification events. We have to check how this fit with the current
> architecture of android-push.
>
> Other challenge will be shipping ADM jar, since this one is on Maven
> and must be downloaded manually but that is for later ;)
>
not sure, why do we need to ship it? what's the license? Why do I need a
manual download from maven ? Not following here
Amazon's SDK is a giant zip bundle. We will need to find a way to package
it into the local maven repo.
Yeah it's a nightmare. You can get this ZIP only from their developer's
portal. Once unzipped, you have to dig some folder before finding the ADM
jar (the only one that we need)
They do publish some things to central, but it looks like that is their
AWS APIs but not ADM.
Yep, I checked as well and it's only for AWS stuff :(
>
> Sebi
>
>
> [1]
>
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
> [2]
> https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
> [3]
>
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> 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
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:45 a.m.
About Licence of their SDK :
https://developer.amazon.com/appsandservices/support/pml.html
" you will not (a) incorporate or compile any portion of the Program
Materials into your own programs or any other software, (b) distribute,
sub-license or otherwise provide any portion of the Program Materials to
any third party, or (c) modify or create derivative works of the Program
Materials."
...
On Tue, Feb 3, 2015 at 4:35 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
On Tue, Feb 3, 2015 at 4:07 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
> On 02/03/2015 09:56 AM, Matthias Wessendorf wrote:
>
>
>
> On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
> wrote:
>
>> Good Morning all !
>>
>> As you might know, we are currently adding Amazon Device Messaging
>> support to the UnifiedPush server.
>> The server side has been PRed and it's now time to work on the client
>> SDK.
>>
>
> once our java-adm is on maven central, I will take a look at the PR
>
>
>> As you probably know, the amazon devices : the Kindle Fire (2nd and
>> third generation), Fire Phone and FireTV are running FireOS which is
>> basically a fork of Android OS. And since we have an Android Push SDK I
>> start looking if we could reuse it.
>>
>> First good news, is that since AGDroid 2.0, things has been nicely
>> isolated and is open for extension. But there is still some refactoring to
>> do, the "UPS Registration" flow/logic is still in the "gcm"
package[1].
>>
>
> the package name shouldn't be the smallest concern :-)
>
>
>
>> That logic should be moved one package level higher in a new Abstract
>> class.
>> In the end we will have a "gcm" package and a "adm" package
(or project,
>> see later in my questions)
>>
>
> +1
>
>
>>
>> This way the ADM logic would be able to reuse that registration code.
>> I started to play a bit with this refactoring here[2], disclaimer here, I'm
>> not even sure that this code compiles, is just to give an idea.
>>
>> So before I go further, some questions (mainly for our Android Gods
>> ;) ) :
>>
>> - Is this a good idea (reusing your SDK) ? I think yes, even if there
>> is some time and effort needed for refactoring to make it completly generic.
>>
>
> sounds reasonable to me, to extend it and apply changes on a separate
> ADM-PUSH-SDK
>
>
>>
>> - How do we build / package / deliver ?
>>
>
> gradle? or, what does Amazon do / prefer ?
>
>
>> We probably want 2 distinct JAR/aar. We could use profile in Maven to
>> only package one feature but that sounds a bit "messy".
>> What about having sub-projects, this way we would have
>> aerogear-android-push and then : aerogear-android-push-gcm and
>> aerogear-push-gcm.
>>
>
> Not sure I get that, but do you mean "aerogear-android-push"
> - aerogear-android-push-gcm
> - aerogear-android-push-adm
>
> sounds reasonable
>
> No it isn't. For starters it will break the 2.0 API and require a 3.0
> API release.
>
>
>
>>
>> - The registration flow for ADM[3] (so device <-> Amazon's server) is
>> a bit different thant the GCM one
>> , it's the same interface that receive the registration event and the
>> push notification events. We have to check how this fit with the current
>> architecture of android-push.
>>
>> Other challenge will be shipping ADM jar, since this one is on Maven
>> and must be downloaded manually but that is for later ;)
>>
>
> not sure, why do we need to ship it? what's the license? Why do I need
> a manual download from maven ? Not following here
>
> Amazon's SDK is a giant zip bundle. We will need to find a way to
> package it into the local maven repo.
>
Yeah it's a nightmare. You can get this ZIP only from their developer's
portal. Once unzipped, you have to dig some folder before finding the ADM
jar (the only one that we need)
>
> They do publish some things to central, but it looks like that is their
> AWS APIs but not ADM.
>
Yep, I checked as well and it's only for AWS stuff :(
>
>
>
>
>>
>> Sebi
>>
>>
>> [1]
>>
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
>> [2]
>> https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
>> [3]
>>
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> 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
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
12:28 p.m.
On 02/03/2015 10:45 AM, Sebastien Blanc wrote:
About Licence of their SDK :
https://developer.amazon.com/appsandservices/support/pml.html
"you will not (a) incorporate or compile any portion of the Program
Materials into your own programs or any other software, (b)
distribute, sub-license or otherwise provide any portion of the
Program Materials to any third party, or (c) modify or create
derivative works of the Program Materials."
...
May actually be a good point. Their license also explicitly calls out
that software made with the SDK should be intended for distribution in
Amazon's App Store.
" You may use Program Materials only in connection with Your Products
intended for distribution through the Distribution Program, unless the
documentation for the applicable Program Materials authorizes broader use. "
I think we might need to summon a lawyer on this one.
On Tue, Feb 3, 2015 at 4:35 PM, Sebastien Blanc <scm.blanc(a)gmail.com
<mailto:scm.blanc@gmail.com>> wrote:
On Tue, Feb 3, 2015 at 4:07 PM, Summers Pittman
<supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote:
On 02/03/2015 09:56 AM, Matthias Wessendorf wrote:
>
>
> On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc
> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote:
>
> Good Morning all !
>
> As you might know, we are currently adding Amazon Device
> Messaging support to the UnifiedPush server.
> The server side has been PRed and it's now time to work
> on the client SDK.
>
>
> once our java-adm is on maven central, I will take a look at
> the PR
>
> As you probably know, the amazon devices : the Kindle
> Fire (2nd and third generation), Fire Phone and FireTV
> are running FireOS which is basically a fork of Android
> OS. And since we have an Android Push SDK I start looking
> if we could reuse it.
>
> First good news, is that since AGDroid 2.0, things has
> been nicely isolated and is open for extension. But there
> is still some refactoring to do, the "UPS Registration"
> flow/logic is still in the "gcm" package[1].
>
>
> the package name shouldn't be the smallest concern :-)
>
> That logic should be moved one package level higher in a
> new Abstract class.
> In the end we will have a "gcm" package and a "adm"
> package (or project, see later in my questions)
>
>
> +1
>
>
> This way the ADM logic would be able to reuse that
> registration code. I started to play a bit with this
> refactoring here[2], disclaimer here, I'm not even sure
> that this code compiles, is just to give an idea.
>
> So before I go further, some questions (mainly for our
> Android Gods ;) ) :
>
> - Is this a good idea (reusing your SDK) ? I think yes,
> even if there is some time and effort needed for
> refactoring to make it completly generic.
>
>
> sounds reasonable to me, to extend it and apply changes on a
> separate ADM-PUSH-SDK
>
>
> - How do we build / package / deliver ?
>
>
> gradle? or, what does Amazon do / prefer ?
>
> We probably want 2 distinct JAR/aar. We could use profile
> in Maven to only package one feature but that sounds a
> bit "messy".
> What about having sub-projects, this way we would have
> aerogear-android-push and then :
> aerogear-android-push-gcm and aerogear-push-gcm.
>
>
> Not sure I get that, but do you mean "aerogear-android-push"
> - aerogear-android-push-gcm
> - aerogear-android-push-adm
>
> sounds reasonable
No it isn't. For starters it will break the 2.0 API and
require a 3.0 API release.
>
>
> - The registration flow for ADM[3] (so device <->
> Amazon's server) is a bit different thant the GCM one
> , it's the same interface that receive the registration
> event and the push notification events. We have to check
> how this fit with the current architecture of android-push.
>
> Other challenge will be shipping ADM jar, since this one
> is on Maven and must be downloaded manually but that is
> for later ;)
>
>
> not sure, why do we need to ship it? what's the license? Why
> do I need a manual download from maven ? Not following here
Amazon's SDK is a giant zip bundle. We will need to find a way
to package it into the local maven repo.
Yeah it's a nightmare. You can get this ZIP only from their
developer's portal. Once unzipped, you have to dig some folder
before finding the ADM jar (the only one that we need)
They do publish some things to central, but it looks like that
is their AWS APIs but not ADM.
Yep, I checked as well and it's only for AWS stuff :(
>
> Sebi
>
>
>
[1]https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-...
> [2]
> https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
> [3]
>
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> 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
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698 <tel:404%20941%204698>
>>Java is my crack.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.
2:43 p.m.
Good catch, Summers!
Let me follow up on that!
On Tuesday, February 3, 2015, Summers Pittman <supittma(a)redhat.com> wrote:
On 02/03/2015 10:45 AM, Sebastien Blanc wrote:
About Licence of their SDK :
https://developer.amazon.com/appsandservices/support/pml.html
" you will not (a) incorporate or compile any portion of the Program
Materials into your own programs or any other software, (b) distribute,
sub-license or otherwise provide any portion of the Program Materials to
any third party, or (c) modify or create derivative works of the Program
Materials."
...
May actually be a good point. Their license also explicitly calls out
that software made with the SDK should be intended for distribution in
Amazon's App Store.
" You may use Program Materials only in connection with Your Products
intended for distribution through the Distribution Program, unless the
documentation for the applicable Program Materials authorizes broader use. "
I think we might need to summon a lawyer on this one.
On Tue, Feb 3, 2015 at 4:35 PM, Sebastien Blanc <scm.blanc(a)gmail.com
<javascript:_e(%7B%7D,'cvml','scm.blanc@gmail.com');>> wrote:
>
>
> On Tue, Feb 3, 2015 at 4:07 PM, Summers Pittman <supittma(a)redhat.com
> <javascript:_e(%7B%7D,'cvml','supittma@redhat.com');>>
wrote:
>
>> On 02/03/2015 09:56 AM, Matthias Wessendorf wrote:
>>
>>
>>
>> On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc <scm.blanc(a)gmail.com
>> <javascript:_e(%7B%7D,'cvml','scm.blanc@gmail.com');>>
wrote:
>>
>>> Good Morning all !
>>>
>>> As you might know, we are currently adding Amazon Device Messaging
>>> support to the UnifiedPush server.
>>> The server side has been PRed and it's now time to work on the client
>>> SDK.
>>>
>>
>> once our java-adm is on maven central, I will take a look at the PR
>>
>>
>>> As you probably know, the amazon devices : the Kindle Fire (2nd and
>>> third generation), Fire Phone and FireTV are running FireOS which is
>>> basically a fork of Android OS. And since we have an Android Push SDK I
>>> start looking if we could reuse it.
>>>
>>> First good news, is that since AGDroid 2.0, things has been nicely
>>> isolated and is open for extension. But there is still some refactoring to
>>> do, the "UPS Registration" flow/logic is still in the
"gcm" package[1].
>>>
>>
>> the package name shouldn't be the smallest concern :-)
>>
>>
>>
>>> That logic should be moved one package level higher in a new Abstract
>>> class.
>>> In the end we will have a "gcm" package and a "adm"
package (or
>>> project, see later in my questions)
>>>
>>
>> +1
>>
>>
>>>
>>> This way the ADM logic would be able to reuse that registration code.
>>> I started to play a bit with this refactoring here[2], disclaimer here,
I'm
>>> not even sure that this code compiles, is just to give an idea.
>>>
>>> So before I go further, some questions (mainly for our Android Gods
>>> ;) ) :
>>>
>>> - Is this a good idea (reusing your SDK) ? I think yes, even if there
>>> is some time and effort needed for refactoring to make it completly generic.
>>>
>>
>> sounds reasonable to me, to extend it and apply changes on a separate
>> ADM-PUSH-SDK
>>
>>
>>>
>>> - How do we build / package / deliver ?
>>>
>>
>> gradle? or, what does Amazon do / prefer ?
>>
>>
>>> We probably want 2 distinct JAR/aar. We could use profile in Maven to
>>> only package one feature but that sounds a bit "messy".
>>> What about having sub-projects, this way we would have
>>> aerogear-android-push and then : aerogear-android-push-gcm and
>>> aerogear-push-gcm.
>>>
>>
>> Not sure I get that, but do you mean "aerogear-android-push"
>> - aerogear-android-push-gcm
>> - aerogear-android-push-adm
>>
>> sounds reasonable
>>
>> No it isn't. For starters it will break the 2.0 API and require a 3.0
>> API release.
>>
>>
>>
>>>
>>> - The registration flow for ADM[3] (so device <-> Amazon's server)
is
>>> a bit different thant the GCM one
>>> , it's the same interface that receive the registration event and the
>>> push notification events. We have to check how this fit with the current
>>> architecture of android-push.
>>>
>>> Other challenge will be shipping ADM jar, since this one is on Maven
>>> and must be downloaded manually but that is for later ;)
>>>
>>
>> not sure, why do we need to ship it? what's the license? Why do I need
>> a manual download from maven ? Not following here
>>
>> Amazon's SDK is a giant zip bundle. We will need to find a way to
>> package it into the local maven repo.
>>
> Yeah it's a nightmare. You can get this ZIP only from their
> developer's portal. Once unzipped, you have to dig some folder before
> finding the ADM jar (the only one that we need)
>
>>
>> They do publish some things to central, but it looks like that is their
>> AWS APIs but not ADM.
>>
> Yep, I checked as well and it's only for AWS stuff :(
>
>>
>>
>>
>>
>>>
>>> Sebi
>>>
>>>
>>> [1]
>>>
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
>>> [2]
>>> https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
>>> [3]
>>>
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
<javascript:_e(%7B%7D,'cvml','aerogear-dev@lists.jboss.org');>
>>> 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 listaerogear-dev(a)lists.jboss.org
<javascript:_e(%7B%7D,'cvml','aerogear-dev@lists.jboss.org');>https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> --
>> Summers Pittman
>> >>Phone:404 941 4698
>> >>Java is my crack.
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
<javascript:_e(%7B%7D,'cvml','aerogear-dev@lists.jboss.org');>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
_______________________________________________
aerogear-dev mailing listaerogear-dev(a)lists.jboss.org
<javascript:_e(%7B%7D,'cvml','aerogear-dev@lists.jboss.org');>https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
--
Sent from Gmail Mobile
10 a.m.
On 02/03/2015 08:31 AM, Sebastien Blanc wrote:
Good Morning all !
As you might know, we are currently adding Amazon Device Messaging
support to the UnifiedPush server.
The server side has been PRed and it's now time to work on the client SDK.
As you probably know, the amazon devices : the Kindle Fire (2nd and
third generation), Fire Phone and FireTV are running FireOS which is
basically a fork of Android OS. And since we have an Android Push SDK
I start looking if we could reuse it.
First good news, is that since AGDroid 2.0, things has been nicely
isolated and is open for extension. But there is still some
refactoring to do, the "UPS Registration" flow/logic is still in the
"gcm" package[1]. That logic should be moved one package level higher
in a new Abstract class.
In the end we will have a "gcm" package and a "adm" package (or
project, see later in my questions)
This way the ADM logic would be able to reuse that registration code.
I started to play a bit with this refactoring here[2], disclaimer
here, I'm not even sure that this code compiles, is just to give an idea.
So before I go further, some questions (mainly for our Android Gods
;) ) :
- Is this a good idea (reusing your SDK) ? I think yes, even if there
is some time and effort needed for refactoring to make it completly
generic.
+1
- How do we build / package / deliver ? We probably want 2 distinct
JAR/aar. We could use profile in Maven to only package one feature but
that sounds a bit "messy".
What about having sub-projects, this way we would have
aerogear-android-push and then : aerogear-android-push-gcm and
aerogear-push-gcm.
Putting gcm in a new artifact will break semver. Both should
probably
just be in the -push artifact.
- The registration flow for ADM[3] (so device <-> Amazon's server) is
a bit different thant the GCM one
, it's the same interface that receive the registration event and the
push notification events. We have to check how this fit with the
current architecture of android-push.
It looks close enough to the GCM flow that I
wouldn't worry. The
biggest difference is GCM's service to handle messages and hand to your
app is in Google Play Services and here it is explicitly in your app.
Other challenge will be shipping ADM jar, since this one is on Maven
and must be downloaded manually but that is for later ;)
/me sees the old,
deprecated ADT and runs.
The biggest problem will be supporting Eclipse again. I don't think we
can do this.
Sebi
[1]https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-...
[2]
https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
[3]
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.
10:08 a.m.
On Tue, Feb 3, 2015 at 4:00 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 02/03/2015 08:31 AM, Sebastien Blanc wrote:
Good Morning all !
As you might know, we are currently adding Amazon Device Messaging
support to the UnifiedPush server.
The server side has been PRed and it's now time to work on the client SDK.
As you probably know, the amazon devices : the Kindle Fire (2nd and third
generation), Fire Phone and FireTV are running FireOS which is basically a
fork of Android OS. And since we have an Android Push SDK I start looking
if we could reuse it.
First good news, is that since AGDroid 2.0, things has been nicely
isolated and is open for extension. But there is still some refactoring to
do, the "UPS Registration" flow/logic is still in the "gcm"
package[1].
That logic should be moved one package level higher in a new Abstract
class.
In the end we will have a "gcm" package and a "adm" package (or
project,
see later in my questions)
This way the ADM logic would be able to reuse that registration code. I
started to play a bit with this refactoring here[2], disclaimer here, I'm
not even sure that this code compiles, is just to give an idea.
So before I go further, some questions (mainly for our Android Gods ;)
) :
- Is this a good idea (reusing your SDK) ? I think yes, even if there is
some time and effort needed for refactoring to make it completly generic.
+1
- How do we build / package / deliver ? We probably want 2 distinct
JAR/aar. We could use profile in Maven to only package one feature but that
sounds a bit "messy".
What about having sub-projects, this way we would have
aerogear-android-push and then : aerogear-android-push-gcm and
aerogear-push-gcm.
Putting gcm in a new artifact will break semver. Both should probably
just be in the -push artifact.
good point!
- The registration flow for ADM[3] (so device <-> Amazon's server) is a
bit different thant the GCM one
, it's the same interface that receive the registration event and the push
notification events. We have to check how this fit with the current
architecture of android-push.
It looks close enough to the GCM flow that I wouldn't worry. The biggest
difference is GCM's service to handle messages and hand to your app is in
Google Play Services and here it is explicitly in your app.
Other challenge will be shipping ADM jar, since this one is on Maven and
must be downloaded manually but that is for later ;)
/me sees the old, deprecated ADT and runs.
The biggest problem will be supporting Eclipse again. I don't think we
can do this.
+1 on not going back to that for our current development
Sebi
[1]
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
[2]
https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
[3]
https://developer.amazon.com/public/apis/engage/device-messaging/tech-doc...
_______________________________________________
aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
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
3368
days inactive
3368
days old
11 comments
3 participants
participants (3)
-
Matthias Wessendorf -
Sebastien Blanc -
Summers Pittman