we have a Cordova application that’s using Codrova 3.3.
The application uses org.jboss.aerogear.cordova.push 1.0.2
When preparing for an android build, there seems to be an problem installing one of the dependencies of the aurora plugin
An id has been updated: com.vladstirbu.cordova.promise, now has a different id: es6-promise-plugin.
The newer plugin 2.0.2 is in the npm registry.
Is it possible to add a fix and deploy to the old cordova registry so that it’s usable in 3.x
Is the newer plugin 2.0.2 backward compatible with 1.0.2
I understand that the ideal approach would be to use a more up-to-date version of Cordova, and use the latest aurora plugin, however it will take some time before I will be able to do that.
I’m open to other suggestions also.
One of the things passos and I have discussed in the past is using
dependency injection (possibly dagger) to reduce a lot of the boiler plate
that is in AGDroid projects (think those nasty config blocks in the
quickstarts which exist for EVERY pipe, oauthmodule, push module, etc). We
decided not to do that in the past because to make it work we would need to
use a gradle plugin, extend all the activity and fragment classes to
interrupt the normal lifecycle, or require the user to call magic methods.
This felt out of touch with the "style" of programming Google was
advocating at the time.
With Google play services 7.5 Google is preparing a gradle plugin which
will consume a services file and provide those values to code via static
variables. (Specifically it injects them into the value.xml file which aidl
turns into values in the Resources object). So we've decided to revisit
See Epic : https://issues.jboss.org/browse/AGDROID-476
We want to create a Gradle plugin which will parse ups and keycloak json
files and provide convenient tools for managing interactions with those
objects. These tools right now will consist of providing annotations to
inject modules and interaction with the Activity lifecycle.
In the Push Issue on the Jira I have a quick sample of how the code might
look. You can see there is a LOT less boiler plate. The idea is that all
of the values in the PushRegistrar were parsed from json config file
automatically and the PushRegistrar was instantiated and managed
wdyt? What are pain points you've had with AGDroid this style of tool
could help? Should we also make plugins for maven applications?
While I was doing the migration work I've noticed there's an index for
device tokens on the installation table. The problem is that MySQL InnoDB
doesn't support indexes for VARCHAR columns wider than 255 chars.
Any ideas on how to fix this? Was this really a point of contention? What
motivated the index addition?
Hmm, looks like I emailed to soon. It appears I have a version mix match and that my openshift UPS is on the 1.0.x branch and the Node sender release for that branch doesn’t include an options object for including categories?
From: <Fink>, mfink <mfink(a)email.unc.edu<mailto:email@example.com>>
Reply-To: AeroGear Developer Mailing List <aerogear-dev(a)lists.jboss.org<mailto:firstname.lastname@example.org>>
Date: Thursday, July 9, 2015 at 1:22 PM
To: "aerogear-dev(a)lists.jboss.org<mailto:email@example.com>" <aerogear-dev(a)lists.jboss.org<mailto:firstname.lastname@example.org>>
Subject: [aerogear-dev] UPS Node Sender client categories issue?
I’m just starting out with UPS (which is awesome btw!) and the Node.js sender client. One thing I’ve noticed is that a message sent from the dashboard with a particular category is sent to only those installations that have that category listed. This works great and is expected. I’m glad there is a way to target specific notification channels, etc.
Sending a notification via the Node Sender client however appears to be sending to everyone’s installation regardless of the categories sent with the message. Here’s a pastie of what my node client call looks like: http://pastie.org/10282358
Unifiedpush Node Sender version 0.8.0-beta1
UPS is the setup via the openshift cartridge, from https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/opensh...
Any pointers would be greatly appreciated. Very well could be me doing it wrong… ;-)
As you (maybe) know Summers and I started plan and create some Jiras for
the next AeroGear Android release (3.0.0). We also did some organized in
Jira, one of that was rename some components do be more close to the name
of the GH repos. See the list below
OLD NEW Datamanager Store Datasync Sync Pipeline Pipe OAuth2
Authorization UnifiedPush Push Crypto Security
Previously GCM allowed multiple senders to be registered with a single
registrationId. Now with the new APIs each senderId gets its own
I don't think we ever supported this use case with UPS, we never really
documented an example using multiple senders, and the developer can have a
different registrar for each sender if she needs this feature with the new
(GCM 3.0) APIs.
Because we are already using a major version jump for dropping JDK6, I
propose we change the push registrar to only accept a single senderId
instead of allowing multiple sender Ids. This more accurately reflects
what the service (GCM) is doing under the hood now anyway.
If someone has an objection let me know and we can discuss it. Otherwise
I'll continue down this path.