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

[Matthias Wessendorf]

On Tue, Feb 3, 2015 at 4:00 PM, Summers Pittman <supittma at 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-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 listaerogear-dev at 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 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/9aa15834/attachment-0001.html