8: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