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