What's new in AeroGear (18th May)
by Christos Vasilakis
Hi all,
in order to minimize the amount of email on what's new in our various
platforms, we have decided to combine into one collective email (thanks to
abstractj for the suggestion!).
So here is our first instalment with a hope it will become a useful tool to
learn about our latest developments
*What's new in Android*
- UPS Metrics support has been added into the push library
<https://github.com/aerogear/aerogear-android-push/pull/36> as well as
on the accompanied HelloWorld demo
<https://github.com/danielpassos/unified-push-helloworld/tree/analytics>
.
(Since analytics also cover all our platforms, if you are interested in the
topic, we suggest to visit our our analytics mail thread
<http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Metrics-Endpoint-w...>
to
get a high level view of the architecture)
- Since we initiated work
<https://github.com/simpligility/android-maven-plugin/issues/623> to
support JUnit 4 in the official maven android-plugin and this work has been
merged as part of the 4.2.1 release, we have started adding support in our
android libraries too, with the first library to get love be the
android-pipe <https://github.com/aerogear/aerogear-android-pipe/pull/35>.
Work is under-way to support our other Android libraries too.
*What's new in iOS*
- As with Android, work to support analytics has been started in
our push-sdk
library <https://github.com/aerogear/aerogear-ios-push/pull/56> as well
as on the accompanied HelloWorld demo app
<https://github.com/jboss-mobile/unified-push-helloworld/pull/6>.
Although work was initiated first for our Swift variants (we love Swift!),
this week we'll carry on our effort for an ObjC version of the same API.
- iOS 2.4 release is on its way! Main focus is to strengthen iOS7
support and Objc/Swift interoperability. Check out project's JIRA tracker
<https://issues.jboss.org/issues/?filter=12323789> for more details and
help shape the release.
*What's new in Apache Cordova*
A new version of the Push Plugin 1.0.3 has been released. Details of the
release can be found in the official announcement
<http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-PushPlugin-release...>
.
*What's new in JS*
Nothing new to report with regards to our JS libs but it was sure a heavy
week in the JS community with many core project having new releases: These
caught our attention:
* Convergence <https://github.com/nodejs/node> of Node.js and IO.js.
* Release of Ember 1.12
<http://emberjs.com/blog/2015/05/13/ember-1-12-released.html>
* Not really a new thing, but for those interested in using ES6 today you
many find this project <https://babeljs.io/> interesting.
* For those interested in Angular, there is a new tutorial
<https://auth0.com/blog/2015/05/14/creating-your-first-real-world-angular-...>
on getting started with Angular 2.
We would love to get feedback and further testings from the community
regarding our current on-going analytic work, so if you have some spare
time that's a perfect time to jump-in and give us feedback.
That's all for now, see you all next week!
*AeroGear team*
10 years, 10 months
Re: [aerogear-dev] [Aerogear-users] Aerogear Unified Push registration through a server backend
by Erik Jan de Wit
The problem is that you don't want/need to call unregister in a normal
flow. Unregister is used for instance when a new version of you app
drops support for push notifications.
I don't get why you are proxy-ing the requests to UPS, because you
cannot have 2 applications receiving the same push notifications. On
iOS the bundle id makes sure of that, and on android there is the
unique project id. So even if a second app would register with UPS it
will not get the push notifications.
On Mon, May 18, 2015 at 2:12 PM, Alex Ballesté
<alexandre.balleste(a)udl.cat> wrote:
> Hi, I'm developing a mobile app for android and ios for our University. It
> will use AeroGear Unified Push Server to send notifications to students when
> a new announcement is sent in our LMS.
>
> We are developing the app with ionic framework and we are using the register
> and unregister process through a custom backend service instead of direct
> from device.
>
> We use the cordova plugin and we call registers and unregister JS methods,
> but we don't point to the push server endpoint, but backend server instead.
> Once the Backend server gets the requests it creates a new request to Push
> server providing variantSecret and variantID; the response received is sent
> back to the app.
>
> We would like to use this flow for security reasons. We want to avoid that
> the users do their own apps and use those values to register and supply
> alias to get users notifications. So backend handles the security (tokens,
> deviceids, usernames, ... ) and if everything is ok then proxies then
> backend generates a new request fullfilling alias and real authentication
> parameters and the received parameters from app. We achieved the registation
> and unregistration, but when unregistration process is done if we do a new
> re-registration then we got a success response, but then notification didn't
> arrive.
>
> Has anybody did something similar to this approximation? Do you have any
> advise or trick that would be useful for us?
>
> Thanks in advance
>
> Alex
>
>
>
> --
>
> Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> Àrea de sistemes d'Informació i Comunicacions
>
> Analista/Programador
>
>
> University of Lleida
>
> Information and Communication Systems Service
>
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Avís legal/Aviso legal/Avertiment legal/Legal notice
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
--
Cheers,
Erik Jan
10 years, 10 months
UPS Migrations for Master, Sequences and Friends
by Douglas Campos
Howdy!
While working on rebasing the migration PR I've noticed that Lukas moved my
'category_seq' generator to the shiny-new 'enhanced-sequence' generator.
Does anyone remembers the reasoning for the change? I'm asking because we
do want a sequence-style generator BUT with individual sequence-like tables
when using mysql. The reason for this is SEVERE contention with InnoDB
tables under load - something that is prone to happen when you go with the
`hibernate_sequence` magic table.
I might be missing something.....HALP? :)
[]'z
10 years, 10 months
Fwd: New Push Server Deployed: Autopush 1.0
by Matthias Wessendorf
interesting to see a rewrite from go to twisted python
---------- Forwarded message ----------
From: *JR Conlin* <jconlin(a)mozilla.com>
Date: Wednesday, May 13, 2015
Subject: New Push Server Deployed: Autopush 1.0
To: dev-push(a)lists.mozilla.org
Yesterday, a new version of the Push Server has been promoted to production.
This version is a total rewrite of the go version into Python Twisted
framework.
The code is available at:
https://github.com/mozilla-services/autopush
There were many reasons for the code rewrite, however the principal was
better memory handling for TLS connections. The new server is able to be
run on a smaller, more afforable AWS instance as well as be able to handle
a larger number of connections.
Operation has passed QA and we expect no impact to existing services. We
have identified several client based issues and are working to address
them. As always, we're available in the irc.mozilla.org #push channel or
via this email list.
_______________________________________________
dev-push mailing list
dev-push(a)lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-push
--
Sent from Gmail Mobile
10 years, 10 months
Metrics Endpoint (was: Re: Advanced Analtyics, new PR and call to the client tech leads)
by Matthias Wessendorf
Hi,
as discussed on the previous thread, there will be a new endpoint to
'track' the "App opened/launched due to received push notification".
Internally, on the UPS, the Push Message has an ID, which get's append to
the payload of the notification, like here:
https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push...
On the client SDKs this will be read and a HTTP call made to the soon
introduced MetricsEndpoint. Currently this info is send to the
RegistrationEndpoint, including the deviceToken/registrationId. However, I
think that the deviceToken/registrationId is currently not needed for
metrics, since we are just interested in anonymous "app launched/opened due
to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet
open".
So all we really need is the ID of the push notification, to be processed
by our Metrics Service
https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr...
Therefore my proposal is have an endpoint:
PUT /metrics/pushmessage/{pushMessageID}
I think PUT is good/best, because there is nothing really created on the
server, it's more updating the 'counter' on the existing
PushMessageInformation object.
Thoughts?
-Matthias
On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>
>
> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych(a)gmail.com>
> wrote:
>
>> To give a bit of background on this background to foreground issue :))
>>
>> Push Cordova plugin matches Cordova life cycle by storing some
>> information locally see:
>>
>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP...
>> Doing so allows you to call multiple time registration, even when an app
>> comes back from background to foreground. you can do it because you have
>> stored locally all the information neede for registration.
>>
>> But when dealing directly with native apps, the life cycle does not
>> always goes through a registration.
>>
>> To sort out this issue,we can:
>> - either store locally at the ios-push lib level instead of doing it in
>> Cordova plugin and then call registration API on all delegate methods (even
>> though we don't want to register but just send the metrics)
>>
>
> based on summers comments, I thought about this - perhaps this is the way
> to go.
> For sending metrics, we do not need to run the registration again, with
> the new endpoint in place. The iOS push SDK could call a (private) method
> and just deliver the metrics related info - that's splits the concerns and
> removes the need to call register endpoint on places where we do not really
> need it
>
> -M
>
>
>
>
>> - or leave the ios-push lib without any storage and provide a separate
>> endpoint for sending metrics or changing categories.
>>
>> I'd go for the second option.
>>
>> ++
>> Corinne
>>
>>
>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com> wrote:
>>
>>> I agree with this and maybe we want even more functionality moved,
>>> because also updating the categories is strange in a 'register'
>>> method. Say for instance you want to change the categories your
>>> interested in a developer has to call register again? And if I
>>> understand Corinnes mail that will currently not even work on iOS.
>>>
>>> For cordova I store the device info, because the lifecycle is
>>> different, but that is okay it's an integration problem.
>>>
>>> So updating the installation details should be a separate method that
>>> also contains updating the categories. That way we have a better split
>>> between a device that registers itself with UPS and updating the
>>> subscription data.
>>>
>>>
>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com>
>>> wrote:
>>> > Hello Sebi,
>>> >
>>> >
>>> > I've done an initial work on aerogear-ios-push [swift branch], adding
>>> a new
>>> > parameter when doing the registration to pass the ag-push-id. See:
>>> >
>>> >
>>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c...
>>> >
>>> > This client could be tested with HelloWorld. See:
>>> >
>>> >
>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob...
>>> >
>>> > What is not covered is the background app coming to foreground through
>>> a
>>> > push notification. If you look at HelloWorld:
>>> >
>>> >
>>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332...
>>> >
>>> > In iOS, when we go from background to foreground we don't go through
>>> > registration API. The iOS push lib doesn't store locally (as opposed to
>>> > windows sdk for ex) the device information. So i can't really make
>>> another
>>> > call to registration API. What i'd suggest is to have a separate
>>> endpoint
>>> > for metrics instead of having it coupled with registration endpoint.
>>> wdyt?
>>> >
>>> > ++
>>> >
>>> > Corinne
>>> >
>>> > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com> wrote:
>>> >>
>>> >> Hi Corinne !
>>> >> We want to collect for both situations you described :)
>>> >>
>>> >> Envoyé de mon iPhone
>>> >>
>>> >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com> a
>>> écrit :
>>> >>
>>> >> Hello Sebi,
>>> >>
>>> >> After giving it a closer look, I've got a question for you: do we
>>> want to
>>> >> collect metrics only when an app is opened via push notification or
>>> do we
>>> >> also want to collect metrics when an app is brought to foreground by
>>> a push
>>> >> notification?
>>> >>
>>> >> ++
>>> >> Corinne
>>> >>
>>> >>
>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>>> >>>
>>> >>> Yeap
>>> >>> on it.
>>> >>>
>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been
>>> rebased on
>>> >>>> the latest master and got a lot of polishing.
>>> >>>>
>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The
>>> only
>>> >>>> "breaking" change is the rename of the header's name that
>>> identifies a Push
>>> >>>> Notification, it's called now "aerogear-push-id"
>>> >>>>
>>> >>>> Seb
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971
>>> >>>> [2]
>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540
>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> aerogear-dev mailing list
>>> >>>> aerogear-dev(a)lists.jboss.org
>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >>>
>>> >>>
>>> >>
>>> >> _______________________________________________
>>> >> aerogear-dev mailing list
>>> >> aerogear-dev(a)lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> aerogear-dev mailing list
>>> >> aerogear-dev(a)lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > aerogear-dev mailing list
>>> > aerogear-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Erik Jan
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)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
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 10 months
Dealing with UPS Keycloak data post-datasource-split
by Douglas Campos
Howdy y'all!
I'm revisiting migration strategies for UPS master, and we have a tough
situation to deal with.
Since we have moved keycloak to its own DataSource, there are KC leftovers
at UPS database which need to be cleaned up.
1) Any suggestions on how to provide a migration path?
Since the tables are intertwined with UPS tables, it's not a matter of
doing a db dump/restore...
2) How to ensure we can safely get rid of the leftover tables on UPS
DataSource?
I can easily provide migrations which just nuke the tables from the face
of the earth, but how to do this without data loss?
Thoughts?
10 years, 10 months
