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
3 years, 8 months
Storing the payload of the push notification
by Matthias Wessendorf
Hi,
earlier this week there was some discussion about storing the payload of
the push notifications ([1]).
Right now, we store some metrics (e.g. client that send the push, number of
devices, deliveryStatus etc) *and* the entire content of push notification.
This includes custom key/value pairs, the name of the sound file or even
the size of the badge.
Is all of that, storing the entire push notification payload really needed?
*No!*
What do we need, and why?
For counting the number of sent pushes (over time), the metrics are good
enough. We do *NOT* need any of the push content for that, that's correct!
But we want to do more on the 1.1.0 release. We want to introduce some
analytic features, to give our app developers (our users) a better
understanding of their push usage (see [2]).
In order to see details on how successful a push was (or not), we need to
only store the value of the alert key:
https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png
Ok, let's change that (see [3])!
For our app developers, using the UPS to reach out to their mobile app
users ("user engagement"), it's important to understand which push was more
successful:
- "Get 10% discount today" (sent on a Monday)
- "Our shop got new site, check it out and get 5% discount" (sent on a
Friday)
With the upcoming analytics we can help them to improve usage of their app.
User interaction is very important to a successful mobile application and
push is a key driver here! Our app developers want an app that is actively
used by their users (Nobody wants his app sitting on the last page of the
device or, even worse, in a folder together with Apple-Maps). Therefore
it's critical for our app developers to understand the relevance of their
push messages sent and how it impacts the usage of their app. That's why we
do the analytics described in [2]. And, yes - only the alert, not the
entire payload is needed for that.
<https://gist.github.com/matzew/b6459083f39394a892c5#privacy>Privacy
On the mentioned PR there was also some discussion about privacy violations
and stuff, when we store the content of the notification. An example where
*sensitive* data was sent over push was given. Something like: "Dear Mr.
Joe, your blood donation appointment was scheduled for 3 p.m"
1. This is not how push notifications are used for mobile apps. Push is
to signal, not carry actual (sensitive) data around.
2. In a lot of countries, at least almost all European countries, you
are not even allowed, by EU law, to give "data" to 3rd party providers
(like the push-networks of Microsoft, Apple or Google).
How does the actual (sensitive) data come to an app?
As said above a push is used to signal/ping an app, to indicate that there
is real data for the mobile app user. In the background the mobile app
tries to connect to the backend of the company, running/maintaining the
mobile app. After the real data was fetched, "local notifcations" are used
to give the user a visible notification, like "Dear Mr. Joe, your blood
donation appointment was scheduled for 3 p.m", or simply "New appointment
scheduled".
If the app was a chat system (and not a blood donation app from the Red
Cross), it would be the same: After a signal, the app connects to "chat
server" and receives the actual chat message from there. A reply would go
over the same "chat server" connection. None of this would go over a 3rd
party push network provider like Google, Microsoft or Apple.
What would we store from these silent notifications?
Nothing, since there is no alert, we would just store the metrics (e.g.
client that send the push, number of devices, deliveryStatus etc). If the
signaling is actually done with an alert (e.g. alert:"you got a new Chat
text" or "New appointment scheduled"), we would store that.
I hope this helps a bit to understand what is stored and also why we do
need a little bit of information.
BTW. our documentation already says that push is used for signaling, not
carrying actual data around, but based on this email I will update it to
have explicit information on best practices. Also, the documentation will
be clear about what (the alert only) is stored by the UPS, and why. (see
[4])
Greetings,
Matthias
- [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/478
- [2] https://issues.jboss.org/browse/AGPUSH-971
- [3] JIRA TO CREATE: to only store ALERT and not the full payload
- [4] JIRA TO CREATE: update doc regarding push message storage and best
practices
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years
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 )
11 years
Chrome Push Messages
by Lucas Holmquist
Hello,
now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i’m starting to look at the new API that Chrome apps use for sending push notifications.
the TL;DR of it is, it’s basically the same as Android now.( no more refresh tokens and access tokens and such )
So the question is, do we need to have a deprecation period on what is currently there?
The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1
While i have looked to deeply, it’s possible we can use the same “Variant” structure for Chrome Apps, Since they will be using the same Network
wdyt?
-Luke
11 years
iOS push error
by Matthias Wessendorf
Hi Harini,
I opened a new thread for this to make it easier to follow up on this
subject.
I just tested my Push Server and iOS just worked fine. Here are a few
questions:
* Did you upload the correct .p12 file for the iOS variant?
* Or did you replace a development cert with a production cert ?
* Did it work a few days ago?
* Did you try to reboot the instance via the openshift UI ?
Thanks,
Matthias
On Tue, Jan 27, 2015 at 1:08 PM, Sekar, Harini <harini.sekar(a)rntbci.com>
wrote:
> Hi guys,
>
> Have deployed the aerogear in openshit and push notification for IOS is
> not working
> Error :
> reason: Error sending payload to APNs server:
> sun.security.validator.ValidatorException: No trusted certificate found
>
> please help me sort this out
>
> Thanks & Regards
> Harini S
>
> --
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years
Amazon Device Messaging (ADM) support on UPS
by Sebastien Blanc
Hi Folks,
I've just submitted a PR to support ADM (Amazon Device Messaging) on UPS[1]
, yay !
A few notes :
- The Java ADM connector is also managed by AeroGear [2], it's not yet
on Maven Central, so you will need to clone it and build it
- The Client SDK (and updated Cordova Plugin) is not yet available but
to make this PR testable, we have adapted a Cordova App that Amazon use as
sample to show ADM, this fork will register with UPS [3], this app contains
also all the instructions to get started
- About the client SDK, FireOS (Amazon's OS) is almost "just" Android,
so we should be able to reuse most of our Android Lib [4], we jsut need to
remove the GCM part and use the ADM library instead. I will start work on
that today and ping our Android gods to see which is the best way to do
that.
So anyone who has a Amazon Tablet, please give it a shot and report on the
PR !
Have fun !
Sebi
[1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/480
[2] https://github.com/aerogear/java-adm
[3] https://github.com/sebastienblanc/adm-cordova-sample
11 years
Polishing our Jedi demo app for sync
by Corinne Krych
Hello All,
For our sync-1.0.0.alpha1 release we have our “Jedi” kind of helloworld demo which do a great job to demo what we want to show in alpha1.
Some small suggestions for the flow and look and feel:
- could we have a first screen like a list of jedi (for now only one value i.e.: Luke is available).
- could we have a list of hobbies as tableview with possibilities to add remove some hobbies?
- could we have an update button so we can “batch” input fields changes together?
- does the “disconnect” button make sense for this alpha1 (as we don’t demo offline support). The button will be usefull for next release, but maybe for this one we can remove it.
- last but not least, would it be possible to scheme it with a jedi theme: dark colors, stars, light blue colors… maybe @agalante can come up with some nice galaxy theme?
On iOS side i’ve added AGIOS-358 to track those improving UI items (liked to epic AGIOS-350). I think we ca “polish” the demo app without too much work involved.
wdyt guys?
++
Corinne
11 years
