Project Info to all projects
by Lukáš Fryč
Hey guys,
me and passos brainstormed yesterday about the project info in the README
files
as it would be nice to unify them across all repositories (discussed
elsewhere) and mainly allow people navigate from code repositories directly
to locations where they can find more help, etc.
As a result, we both liked:
1. brief Project Info in the header
2. more verbose Documentation / Development / Questions? / Found a bug?
section in the footer
Example for Android Core: https://gist.github.com/lfryc/df0c9c9a9ba7acebfd7b
Let me know what you think.
If I don't get any -1, I will send pull requests with the updates in all
aerogear repositories at the end of this week.
Cheers!
~ Lukas
P.S.: aerogear-users has just a ordinary mailman archive while aerogear-dev
uses nabble, which is far better for navigation / search, etc. (the request
to add that feature to aerogear-users is tracked in
https://issues.jboss.org/browse/AEROGEAR-1590 )
8 years, 1 month
Buddies at cookbooks
by Bruno Oliveira
Morning buddies,
I'm definitely exceeding my quota of e-mails today, but this is
necessary. At the cookbooks we have the backend "Buddies", looking at
the sources and after a chat with Passos, I was struggling to understand
why this project exists.
If I need to start WildFly + run Maven only to see a list of developers. I would totally give up on try
our SDK, because it defeats the purpose of simplicity.
I'm not saying that this doesn't help, but we should try to make it
simple with the usage of public endpoints, like Passos has been doing on
https://github.com/aerogear/aerogear-android-cookbook/tree/master/ChuckNo....
If the goal is to display the list of developers, maybe we should stick
to the public GitHub API?
--
abstractj
PGP: 0x84DC9914
8 years, 1 month
Cookbook backend
by Bruno Oliveira
Good morning, I'm struggling to understand why we have submodules here:
https://github.com/aerogear/aerogear-backend-cookbook. Do we have a good
reason for it?
To give you some context, I already tagged the cookbook backend as 0.0.1
("stable") and would like to generate the binaries from this tag.
To be it doesn't make any sense on having submodules there and we have 2
alternatives:
1. Move the repositories to the aerogear-backend-cookbook
2. Remove the submodules
Thoughts?
--
abstractj
PGP: 0x84DC9914
8 years, 1 month
AeroGear.Ajax
by Lucas Holmquist
While i was looking through the JS lib, i realized that AeroGear.ajax is really only used by the UnifiedPush client sdk. Yes, it’s used by the OAuth2 adapter for Authz, but that is getting deprecated.
I plan on sending a PR that will basically take AeroGear.ajax and merge it with the UnifiedPush client sdk.
I think the original thought i had with this part of the library is that it would be used internally for other parts, such as pipeline and auth but those have been removed so i don’t think it makes sense to keep AeroGear.ajax around.
I’ll be creating a JIRA with this info
-Luke
8 years, 1 month
Amazon Push SDK and Android Push SDK
by Sebastien Blanc
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...
8 years, 1 month
