[aerogear-dev] Amazon Push SDK and Android Push SDK

[Matthias Wessendorf]

On Tue, Feb 3, 2015 at 2:31 PM, Sebastien Blanc <scm.blanc at 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-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMPushRegistrar.java
> [2]
> https://github.com/sebastienblanc/aerogear-android-push/tree/refactoring
> [3]
> https://developer.amazon.com/public/apis/engage/device-messaging/tech-docs/04-integrating-your-app-with-adm
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150203/d89eb92d/attachment.html