Improving customization abilities of OpenShift cartridge
by Karel Piwko
Hi All,
I'd like to know your opinion on following changes to UnifiedPush
Server. They are both focused on improving customization process for the
cartridge.
Just in short, current update process now:
1/ Clone official git repository of cartridge
2/ Extract wars and do the modifications or build ones
3/ Package wars
4/ Push cartridge to your own repository
5/ Create cartridge from your own repository
Whereas, I'm proposing:
1/ Create cartridge from official repository
2/ Clone git repository for gear created by Openshift (by default if rhc
is used)
3/ Modify some files there we expose for user modification
4/ Push back to make changes live
What particular configuration elements I'm interested to have
externalized?
1/ Ability to load keycloak.json from external location
=> This allows user to create cartridge and modify it prior the first
access. This allows users to configure it to be consumable by other
services automatically, e.g. they can add developer users, roles, etc.
2/ Externalize GCM/APNs locations
=> Now, URLs are hardcoded in GCM/APNs JARs. If they would be loaded
from external location (defaults can still be hardcoded), this allows
user to easily check business logic that queries data in UPS and not
sending any messages. Also allows to put proxy in between UPS and
APNs/GCMs.
Both these will significantly reduce QE overhead. However, I believe
they are valuable for other as well.
Feedback and tomatoes (I prefer plum ones) are welcomed.
Thanks,
Karel
10 years, 2 months
message format change proposal
by Erik Jan de Wit
Hi,
With the upcoming windows support and simple push change (making simple push more like 'normal') the number of ‘special’ keys in our message is increasing. Right now we are mixing our ‘special’ keys with those the user can add, but we keep simple push out of it:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com", "someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"someKey":"some value",
"anotherCustomKey":"some other value"
},
"simple-push": "version=123”
}
As simple push is going to be more like ‘normal’ push why not move the simple-push into the message as well. As for the windows support there are a lot more types of messages you can send. The most normal form is called ‘toast’, but there are other ones for when you app is pinned to the home screen. Then one can send message that contain pictures. To support all of this we need something like this: https://gist.github.com/edewit/305d76c31960aa6254a9
Adding all these ‘special’ keys will make it easier to get into a conflict with the users own data, so I propose we put the user data into a separate data object, like so:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com", "someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"simple-push": "version=123",
"data" : {
"someKey":"some value",
"anotherCustomKey":"some other value"
}
}
}
WDYT?
Cheers,
Erik Jan
10 years, 2 months
oath2 cordova plugin
by Erik Jan de Wit
Hi,
I was working on a Oath2 plugin for cordova with the latest swift bits, but using swift for a cordova plugin is not very user friendly. The generated project that gets downloaded when you do a `cordova platform add ios` has to be change by opening Xcode.
Things that need to be changed by hand are the following:
* iOS Deployment target needs to be set to something higher then the 6.0 it’s now at
* Bridging-Header.h to Objective-c Bridging Header under the Swift Compiler - Code Generation options
e.g (HelloCordova/Plugins/org.jboss.aerogear.cordova.oauth2/Bridging-Header.h)
* the following to LD_RUNPATH_SEARCH_PATHS to "$(inherited) @executable_path/Frameworks”
That is just a little to much for a user to do, and I see no way to hook this into the cordova project / plugin configuration. The cordova team are planning to change the way the project is created and how settings are maintained in version 4.0 I’ve created two PR that help that effort, but these have not been merged yet.
So I propose that we don’t release the plugin, but wait on cordova to update so that manual steps will no longer be needed, or we add a big Notice on how to install use this plugin.
WDYT?
Cheers,
Erik Jan
10 years, 2 months
Cordova Push Plugin Release
by Erik Jan de Wit
Hi,
After successful testing we are happy to announce that version 1.0.2 of the push plugin has been released. With a new feature support for external configuration, instead of using code you can store the variantId and secrets into a separate json file.
Cheers,
Erik Jan
Here are the release notes:
Bug
[AGCORDOVA-36] - Make Push Plugin work again with Android < 4.4
Feature Request
[AGCORDOVA-34] - externalise Push config
10 years, 2 months
