AeroGear Crypto Java 0.1.2 released
by Bruno Oliveira
Good morning, just to let you know we released today the bits for digital signatures and some bug fixes.
Have a happy new year sweet hearts.
--
abstractj
4 years, 4 months
AeroGear WebPush Java Client
by Idel Pivnitskiy
Hi all!
I've just implemented a lightweight java client for receiving push messages
from AeroGear WebPush Server [1]. It is easy to use and fully async!
A few words about decision to use Jetty as a HTTP/2 client:
Currently there are only 3 Java libraries, which implement client side of
HTTP/2 protocol [2]: Netty, Jetty and OkHttp. I tried all of them:
- First of all I tried to use OkHttp. This is a lightweight http client
for Android and other Java apps. But currently this library supports HTTP/2
protocol only via old HTTP/1.1 API. It works well for simple
request-response, but its client API does not allow to use HTTP/2 features,
like Server Push Frames. I looked at GRPC [3], because Googlers use OkHttp
for HTTP/2 transport. But they don't use public API, they use only inner
classes to handle frames and built their own logic atop this classes. It
would be too complicated for our purposes.
- Secondary, I tried to refactor our WebPush console to a client
library. But this way is complicated too. netty-codec-http2 does not
provide a client API, it is only codec, low level protocol implementation.
- Now I use jetty-http2-client. It is easy to configure and use, fast
and async. Jetty provides a user friendly API to handle HTTP/2 streams and
get PUSH_PROMISE frames.
For more information, look at my commit history.
In the future, if there will be more lightweight alternatives than Jetty
(for example, new version of OkHttp or Java 9 API), I will rewrite the
transport layer of my library.
Here is an example, how to use my library [4].
[1] https://github.com/idelpivnitskiy/aerogear-webpush-java-client
[2] https://github.com/http2/http2-spec/wiki/Implementations
[3] https://github.com/grpc/grpc-java/tree/master/okhttp
[4]
https://github.com/idelpivnitskiy/aerogear-webpush-java-client/blob/maste...
Best regards,
Idel Pivnitskiy
--
E-mail: Idel.Pivnitskiy(a)gmail.com
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
10 years, 7 months
GCM Topics in UPS
by Summers Pittman
So I've got a few ideas for how to implement this, but I hope some people
more experienced with the platform can give some feedback before.
Quick Background:
In UPS right now we have a concept of categories. A single UPS message can
be broadcast to a bunch of devices which are subscribed to this category.
Google now supports this for GCM on Chrome, iOS, and Android so UPS can
send a single message to GCM and GCM will broadcast that to up to a million
devices.
End Quick Background
So first, how do we switch between sending a message to each device in a
category to sending a topic message to GCM?
In TokenLoader.java#L113 we are using the clientInstallationService to
build a string of deviceTokens based on the variant and message criteria.
Is there any reason we can't create a "topicToken" which will be recognized
later by GCMPushNotificationSender? Another benefit to making this change
here is that if we have over a million subscribers to the category we can
just default to the default messaging.
There is also an open issue of whether or not we will update the clients to
filter based on what category a message was sent to. To do this we will
have to include the category information in the message when we send it to
devices going forward. In GCM a topic message includes this information.
This means that if we have over a million subscriptions in the topic we
will need to fall back to using the category information anyway.
Continuing on from the thread of falling back, it is possible for a topic
message to fail to send because there are too many subscribers. How would
UPS handle regenerating the messages as deviceToken instead of topicToken
messages?
Of course if someone has a better idea than "topicTokens" I'm all ears.
10 years, 7 months
Problem on migrating to 1.1.0-Final
by Javornik, Romain
Hello,
I don't really know if this is the right email address for asking question but I give it a try, please redirect me if I'm wrong !
------ Problem in the UnifiedPush Server User Guide ------
Before explaining my problem I want to tell you that something isn't clear enough from my point of view in your migration guide (https://aerogear.org/docs/unifiedpush/ups_userguide/index/#migration-guide).
On the part where you explain the database migration for mysql you write :
MySQL
Inside of the extracted zip file, there is a liquibase-mysql-example.properties, copy that to liquibase.properties.
cp liquibase-mysql-example.properties liquibase.properties
Once done, you need to edit the new file to match your database name and credentials.
The problem with this is that you can't choose the version you want to upgrade to.
Since I have "changeLogFile=liquibase/master.xml" in my liquidbase.properties, the only upgrade I was able to make was to the 1.0.0-Final and I'm on the 1.0.2.
I had to open the ups-migrator.jar (wich wasn't really userfriendly) to see what was my option. And then I was able to go the version I want (exemple -> "changeLogFile=liquibase/1.1.0-Final/releasechanges.xml")
To conclude I think that just a small explanation in the migration guide will make everything more clear.
------ My migration problem ------
I'm currently using AerogearPush Server 1.0.2 and I want to go to the 1.1.0-Final version.
I download the last package (1.1.0-Final) on this page https://aerogear.org/getstarted/downloads
Like explain above I had some trouble make it work to move to the version I wanted.
Right now in 1.0.2 I can use the Migrator Tool to make sure that my 1.0.2 Mysql database is good and to upgrade it to 1.0.3.
But I can't go the 1.1.0-Final, I join to this email the error I get from the Migrator Tool.
Can you please tell me where the problem might come from or if you have any solution ?
Best Regards,
Romain
10 years, 9 months
Push customization with Android background App
by Bourillon, Matthias
Hello,
I have carefully read and applied the procedure to use Aerogear Push in a Cordova / Ionic App (https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/).
Everything is OK except that my onNotification() JS method is not called when my Android App is running in background. The notification is displayed as it arrives and I am not able to apply any logic before it reaches the notification bar.
We are using push to send some instructions to our App which should not always be displayed as-is to end users. Is there a way to customize or apply some logic when an App is in background? Or is this a limitation we have to deal with?
Thanks,
Matthias
10 years, 9 months
Re: [aerogear-dev] Long delay from first to last push message received on iOS devices
by Øivind Hoff Johansen
Hi,
Sure, can do this after the holidays. January at the earliest.
Do you have any way of measuring on what is the better value ?
Øivind
Fra: mwessendorf(a)gmail.com [mailto:mwessendorf@gmail.com] På vegne av Matthias Wessendorf
Sendt: 18. desember 2015 15:29
Til: AeroGear Developer Mailing List; Øivind Hoff Johansen
Emne: Re: [aerogear-dev] Long delay from first to last push message received on iOS devices
Hi Øivind,
we are decreasing the number in the code base:
https://github.com/aerogear/aerogear-unifiedpush-server/pull/663
I wonder if 2k is really the best value. Would you mind testing some configs, e.g. 3k or 4k via the system property?
Thanks a lot!
-Matthias
On Thu, Dec 10, 2015 at 12:53 PM, Øivind Hoff Johansen <oivind.hoff.johansen(a)adresseavisen.no<mailto:oivind.hoff.johansen@adresseavisen.no>> wrote:
Hi,
Looks like decreasing the ios batch size did the trick, thanks :)
People report that it now only takes seconds.
Added "-Daerogear.ios.batchSize=2000" to standalone.conf
Regards,
Øivind
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org<mailto:aerogear-dev@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
10 years, 10 months
UPS: next releases and branches
by Matthias Wessendorf
Hi folks,
for early Jan, I'd like to get the UPS-1.1.1 out:
https://issues.jboss.org/projects/AGPUSH/versions/12327457
Not sure we will be doing a 1.1.2 later, but maybe... given these JIRAs:
https://issues.jboss.org/projects/AGPUSH/versions/12323762
The next minor version will be 1.2.0:
https://issues.jboss.org/projects/AGPUSH/versions/12327301
However, I had quick chat w/ Lukas in the morning, that we already have KC
version update on master, but that really should not be in a 1.1.x patch
version.
Here is the proposal of what to do:
* I branch of master for a 1.1.x patch branch, and on that branch, I simply
rewert the KC update.
* Obviously on master we keep the update, but also update the version there
to 1.2.0-SNAPSHOT
Also, since "active" branches are a PITA (we had that on 1.0.x), the idea
is that the 1.1.x branch will be deleted ASAP, e.g. once we get out 1.1.1
shipped. In case we do a 1.1.2, we'd simple create a new 1.1.x branch of
the 1.1.1 TAG.
But on master, things will be moving forward, towards UPS 1.2.0
Any thoughts?
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 10 months
