From daniel.bevenius at gmail.com Tue Apr 1 02:50:28 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 1 Apr 2014 08:50:28 +0200 Subject: [aerogear-dev] AeroGear Controller Message-ID: Hi, was going over aerogear.org and found the following information about AeroGear Controller: http://aerogear.org/download/ http://aerogear.org/docs/specs/aerogear-controller/ http://aerogear.org/docs/guides/aerogear-controller/ http://aerogear.org/docs/planning/roadmaps/AeroGearController/ I think removing these from the site would simplify things and make one less thing for new users to "have" to read about, only to find that it is not being actively developed. Are there any objections about removing this content? /Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/b2c9cb81/attachment.html From scm.blanc at gmail.com Tue Apr 1 02:51:40 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 1 Apr 2014 08:51:40 +0200 Subject: [aerogear-dev] AeroGear Controller In-Reply-To: References: Message-ID: +1 to remove any reference to it On Tue, Apr 1, 2014 at 8:50 AM, Daniel Bevenius wrote: > Hi, > > was going over aerogear.org and found the following information about > AeroGear Controller: > > http://aerogear.org/download/ > http://aerogear.org/docs/specs/aerogear-controller/ > http://aerogear.org/docs/guides/aerogear-controller/ > http://aerogear.org/docs/planning/roadmaps/AeroGearController/ > > I think removing these from the site would simplify things and make one > less thing for new users to "have" to read about, only to find that it is > not being actively developed. > > Are there any objections about removing this content? > > /Dan > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/c9f8e744/attachment.html From corinnekrych at gmail.com Tue Apr 1 02:52:27 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 1 Apr 2014 08:52:27 +0200 Subject: [aerogear-dev] AeroGear Controller In-Reply-To: References: Message-ID: <0C9F3546-17C9-4669-A800-942AD41D851A@gmail.com> Go ahead cleaning the doc is important. ++ Corinne On 01 Apr 2014, at 08:50, Daniel Bevenius wrote: > Hi, > > was going over aerogear.org and found the following information about AeroGear Controller: > > http://aerogear.org/download/ > http://aerogear.org/docs/specs/aerogear-controller/ > http://aerogear.org/docs/guides/aerogear-controller/ > http://aerogear.org/docs/planning/roadmaps/AeroGearController/ > > I think removing these from the site would simplify things and make one less thing for new users to "have" to read about, only to find that it is not being actively developed. > > Are there any objections about removing this content? > > /Dan > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Apr 1 03:13:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Apr 2014 09:13:07 +0200 Subject: [aerogear-dev] AeroGear Controller In-Reply-To: <0C9F3546-17C9-4669-A800-942AD41D851A@gmail.com> References: <0C9F3546-17C9-4669-A800-942AD41D851A@gmail.com> Message-ID: yeah, let's get rid of it On Tue, Apr 1, 2014 at 8:52 AM, Corinne Krych wrote: > Go ahead cleaning the doc is important. > ++ > Corinne > On 01 Apr 2014, at 08:50, Daniel Bevenius > wrote: > > > Hi, > > > > was going over aerogear.org and found the following information about > AeroGear Controller: > > > > http://aerogear.org/download/ > > http://aerogear.org/docs/specs/aerogear-controller/ > > http://aerogear.org/docs/guides/aerogear-controller/ > > http://aerogear.org/docs/planning/roadmaps/AeroGearController/ > > > > I think removing these from the site would simplify things and make one > less thing for new users to "have" to read about, only to find that it is > not being actively developed. > > > > Are there any objections about removing this content? > > > > /Dan > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/ee7a4694/attachment.html From edewit at redhat.com Tue Apr 1 03:54:32 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 1 Apr 2014 09:54:32 +0200 Subject: [aerogear-dev] automated plugin release Message-ID: Hi, Because the release process for cordova plugins has a lot of steps and because it?s a source distribution I would like to suggest an automated process for releasing and testing the plugins. What I would like to suggest is that we create a gradle script (for instance can be something else) that will execute the tests, merge the development branch create a tag and publish to plugins.cordova.io. I?ve already experimented with it a bit and it seems very doable. So what do you think? Cheers, Erik Jan From daniel.bevenius at gmail.com Tue Apr 1 03:57:04 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 1 Apr 2014 09:57:04 +0200 Subject: [aerogear-dev] automated plugin release In-Reply-To: References: Message-ID: Sounds good to me. On 1 April 2014 09:54, Erik Jan de Wit wrote: > Hi, > > Because the release process for cordova plugins has a lot of steps and > because it's a source distribution I would like to suggest an automated > process for releasing and testing the plugins. > > What I would like to suggest is that we create a gradle script (for > instance can be something else) that will execute the tests, merge the > development branch create a tag and publish to plugins.cordova.io. I've > already experimented with it a bit and it seems very doable. > > So what do you think? > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/7707fbea/attachment.html From daniel.bevenius at gmail.com Tue Apr 1 04:01:40 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 1 Apr 2014 10:01:40 +0200 Subject: [aerogear-dev] AeroGear Controller In-Reply-To: References: <0C9F3546-17C9-4669-A800-942AD41D851A@gmail.com> Message-ID: Removing the controller documentation in this PR: https://github.com/aerogear/aerogear.org/pull/289 On 1 April 2014 09:13, Matthias Wessendorf wrote: > yeah, let's get rid of it > > > On Tue, Apr 1, 2014 at 8:52 AM, Corinne Krych wrote: > >> Go ahead cleaning the doc is important. >> ++ >> Corinne >> On 01 Apr 2014, at 08:50, Daniel Bevenius >> wrote: >> >> > Hi, >> > >> > was going over aerogear.org and found the following information about >> AeroGear Controller: >> > >> > http://aerogear.org/download/ >> > http://aerogear.org/docs/specs/aerogear-controller/ >> > http://aerogear.org/docs/guides/aerogear-controller/ >> > http://aerogear.org/docs/planning/roadmaps/AeroGearController/ >> > >> > I think removing these from the site would simplify things and make one >> less thing for new users to "have" to read about, only to find that it is >> not being actively developed. >> > >> > Are there any objections about removing this content? >> > >> > /Dan >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/c7860a7b/attachment.html From scm.blanc at gmail.com Tue Apr 1 04:34:37 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 1 Apr 2014 10:34:37 +0200 Subject: [aerogear-dev] automated plugin release In-Reply-To: References: Message-ID: Sounds good ! Question : will this process be really tied to AeroGear's Plugins or will be that / could that be generic ? Since we could contribute by providing a cordova plugin release mechanism On Tue, Apr 1, 2014 at 9:57 AM, Daniel Bevenius wrote: > Sounds good to me. > > > On 1 April 2014 09:54, Erik Jan de Wit wrote: > >> Hi, >> >> Because the release process for cordova plugins has a lot of steps and >> because it's a source distribution I would like to suggest an automated >> process for releasing and testing the plugins. >> >> What I would like to suggest is that we create a gradle script (for >> instance can be something else) that will execute the tests, merge the >> development branch create a tag and publish to plugins.cordova.io. I've >> already experimented with it a bit and it seems very doable. >> >> So what do you think? >> >> Cheers, >> Erik Jan >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/3a3dca76/attachment.html From corinnekrych at gmail.com Tue Apr 1 05:47:34 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 1 Apr 2014 11:47:34 +0200 Subject: [aerogear-dev] automated plugin release In-Reply-To: References: Message-ID: Interesting. For iOS it is also source distribution, we could benefit from it too. Looking forward to seeing more of it. ++ Corinne On 1 April 2014 10:34, Sebastien Blanc wrote: > Sounds good ! > Question : will this process be really tied to AeroGear's Plugins or will > be that / could that be generic ? Since we could contribute by providing a > cordova plugin release mechanism > > > On Tue, Apr 1, 2014 at 9:57 AM, Daniel Bevenius > wrote: > >> Sounds good to me. >> >> >> On 1 April 2014 09:54, Erik Jan de Wit wrote: >> >>> Hi, >>> >>> Because the release process for cordova plugins has a lot of steps and >>> because it's a source distribution I would like to suggest an automated >>> process for releasing and testing the plugins. >>> >>> What I would like to suggest is that we create a gradle script (for >>> instance can be something else) that will execute the tests, merge the >>> development branch create a tag and publish to plugins.cordova.io. I've >>> already experimented with it a bit and it seems very doable. >>> >>> So what do you think? >>> >>> Cheers, >>> Erik Jan >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/9008bdcd/attachment.html From tolisemm at gmail.com Tue Apr 1 06:00:44 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Tue, 1 Apr 2014 13:00:44 +0300 Subject: [aerogear-dev] automated plugin release In-Reply-To: References: Message-ID: 2014-04-01 11:34 GMT+03:00 Sebastien Blanc : > Sounds good ! > Question : will this process be really tied to AeroGear's Plugins or will > be that / could that be generic ? Since we could contribute by providing a > cordova plugin release mechanism > > + 1 for a plugin providing cordova related generic configurable gradle tasks > > On Tue, Apr 1, 2014 at 9:57 AM, Daniel Bevenius > wrote: > >> Sounds good to me. >> >> >> On 1 April 2014 09:54, Erik Jan de Wit wrote: >> >>> Hi, >>> >>> Because the release process for cordova plugins has a lot of steps and >>> because it's a source distribution I would like to suggest an automated >>> process for releasing and testing the plugins. >>> >>> What I would like to suggest is that we create a gradle script (for >>> instance can be something else) that will execute the tests, merge the >>> development branch create a tag and publish to plugins.cordova.io. I've >>> already experimented with it a bit and it seems very doable. >>> >>> So what do you think? >>> >>> Cheers, >>> Erik Jan >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/31499b40/attachment-0001.html From kpiwko at redhat.com Tue Apr 1 07:27:48 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 1 Apr 2014 13:27:48 +0200 Subject: [aerogear-dev] automated plugin release In-Reply-To: References: Message-ID: <20140401132748.1a406a27@kapy-ntb-x220> Sounds great. I'd like to contribute with integration tests (for Android part) we have and add them to the release process script (we use gradle/maven/java, so it should be easy to combine). Here is the itest workflow 1/ create a cordova app via cli (using to-be-release-version plugin) 2/ build app 3/ start android emulator/connect to real device 4/ deploy ups (or use openshift instance) 5/ install app 6/ execute test a/ check app is registered b/ send message c/ check message is received - various variants (foreground, background, etc) 7/ cleanup (uninstall, stop, etc) All but step 1/ are currently automated for Cordova/Android. For iOS is it more complicated, given the fact you can't test APNs in simulator. Karel On Tue, 1 Apr 2014 09:54:32 +0200 Erik Jan de Wit wrote: > Hi, > > Because the release process for cordova plugins has a lot of steps and > because it?s a source distribution I would like to suggest an automated > process for releasing and testing the plugins. > > What I would like to suggest is that we create a gradle script (for instance > can be something else) that will execute the tests, merge the development > branch create a tag and publish to plugins.cordova.io. I?ve already > experimented with it a bit and it seems very doable. > > So what do you think? > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From kpiwko at redhat.com Tue Apr 1 07:56:40 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 1 Apr 2014 13:56:40 +0200 Subject: [aerogear-dev] Modularization and Push In-Reply-To: <5339935F.4010008@redhat.com> References: <533974A1.1020406@redhat.com> <20140331170703.7e719f86@kapy-ntb-x220> <20140331173824.26658c37@kapy-ntb-x220> <5339935F.4010008@redhat.com> Message-ID: <20140401135640.4c58258a@kapy-ntb-x220> On Mon, 31 Mar 2014 12:10:07 -0400 Summers Pittman wrote: > The plan as I see it (and passos can correct me) is that we would keep > aerogear-android as it is and create a "forked" project which is only > aerogear-android-gcm-push and the bits it needs with no dependency on > aerogear-android. This MAY be a jar but will probably be an apklib and > aar artifact. > AIUI it does not matter that whether it will be jar/apklib/aar. The point is that the file(s) is published somewhere (Maven Central) wherefrom others can consume it using build system we plan to support (Maven, Gradle, ...). > We (android) don't want to modularize the whole project right now > because that will be a lot of work to maintain 1.x compatibility for > semver and we aren't ready to build 2.0 yet. Semver allows pre-release versions. So there should be no concerns to start releasing what you have right now using 2.0.0-alpha-X versions. From edewit at redhat.com Tue Apr 1 08:13:26 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 1 Apr 2014 14:13:26 +0200 Subject: [aerogear-dev] automated plugin release In-Reply-To: <20140401132748.1a406a27@kapy-ntb-x220> References: <20140401132748.1a406a27@kapy-ntb-x220> Message-ID: <1256FE9B-0E31-4EBA-86A1-56E622FF8B38@redhat.com> On 1 Apr,2014, at 13:27 , Karel Piwko wrote: > Sounds great. > > I'd like to contribute with integration tests (for Android part) we have and add > them to the release process script (we use gradle/maven/java, so it should be > easy to combine). > > Here is the itest workflow > 1/ create a cordova app via cli (using to-be-release-version plugin) > 2/ build app > 3/ start android emulator/connect to real device > 4/ deploy ups (or use openshift instance) > 5/ install app > 6/ execute test > a/ check app is registered > b/ send message > c/ check message is received - various variants (foreground, > background, etc) > 7/ cleanup (uninstall, stop, etc) > I?ve automated step 1 as well, let?s merge our efforts and make a cool gradle script out of this. I think it would also make sense to release all plugins at one and not a single one at a time. > All but step 1/ are currently automated for Cordova/Android. For iOS is it more > complicated, given the fact you can't test APNs in simulator. > > Karel > > From lholmqui at redhat.com Tue Apr 1 08:14:57 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 1 Apr 2014 08:14:57 -0400 Subject: [aerogear-dev] AeroGear Controller In-Reply-To: References: Message-ID: <9501820E-A75A-4C10-9021-63C72ED3EDCB@redhat.com> +1 to removal. FINISH THEM!! On Apr 1, 2014, at 2:50 AM, Daniel Bevenius wrote: > Hi, > > was going over aerogear.org and found the following information about AeroGear Controller: > > http://aerogear.org/download/ > http://aerogear.org/docs/specs/aerogear-controller/ > http://aerogear.org/docs/guides/aerogear-controller/ > http://aerogear.org/docs/planning/roadmaps/AeroGearController/ > > I think removing these from the site would simplify things and make one less thing for new users to "have" to read about, only to find that it is not being actively developed. > > Are there any objections about removing this content? > > /Dan > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/cf372524/attachment.html From miguel21op at gmail.com Tue Apr 1 08:17:58 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Tue, 1 Apr 2014 13:17:58 +0100 Subject: [aerogear-dev] Cordova and iOS new issue In-Reply-To: References: <724639B0-7694-4A63-AD7E-30C8BBC7F056@gmail.com> <51630639-2215-4A00-9655-A0DBC03AB851@redhat.com> <900F8FF6-1025-4BCB-8EC9-6EDD1D5952B3@gmail.com> <2074AB33-EC61-4B28-A1CD-0ADAD5785296@redhat.com> <8F6FEB68-6D1E-405B-85B8-9F0F46BC703C@redhat.com> <554D7D8B-7730-4C35-BB3D-45027CFE952A@gmail.com> <6AF0AA50-52D3-473C-BAFA-8F2D28D25F64@redhat.com> Message-ID: Hi! I downloaded the Cordova plugin with the last "updates", but apparently the corrections you did previously aren't there yet. I had to download the revised PushPlugin.m "by hand". On Wed, Mar 19, 2014 at 2:08 PM, Miguel Lemos wrote: > OK. I just pasted the PushPlugin.m but I picked the yesterday's version. > > I already tested it and now it's working correctly, thanks. > > Thanks > > > On Wed, Mar 19, 2014 at 1:47 PM, Erik Jan de Wit wrote: > >> I did >> https://github.com/edewit/aerogear-pushplugin-cordova/commit/1df1adcaa76aa0a740d6e9c02ec2b02b3b0b990a >> >> >> checkout my branch: >> >> git checkout -b edewit-payload-missing master >> git pull git at github.com:edewit/aerogear-pushplugin-cordova.git payload-missing >> >> >> >> On 19 Mar,2014, at 14:43 , Miguel Lemos wrote: >> >> Erik, >> >> I think you didn't update the code... >> >> >> On Wed, Mar 19, 2014 at 9:28 AM, Miguel Lemos wrote: >> >>> Yes, I see it now. I'll test it as soon as I can again. >>> >>> M >>> >>> Enviado do meu iPhone >>> >>> No dia 19/03/2014, ?s 07:47, Erik Jan de Wit >>> escreveu: >>> >>> Yeah didn?t test all possibilities apparently, there is a ? missing on >>> the foreground property. Fixed now. >>> >>> On 19 Mar,2014, at 0:08 , Miguel Lemos wrote: >>> >>> Now: if the app is not in the foreground, but it was not removed (still >>> running), when a notification is sent and I press the status bar, the >>> Safari debugger throws this error: SyntaxError: Unexpected number '0' >>> and no window is opened. >>> >>> All I have in my code is: >>> >>> alert(e.alert); >>> >>> The string that arrives to the device is like this: >>> >>> >>> >>> *Msg: {"badge":"1","alert":"hlhlkhkl","payload": >>> {"cp":"","cd":"","av":"hlhlkhkl","ul":"","ln":"","en":"598","at":"Aviso","rd":"","lt":"",},"foreground:"0"} >>> * >>> >>> Hope it helps. >>> >>> >>> On Tue, Mar 18, 2014 at 10:23 PM, Miguel Lemos wrote: >>> >>>> Not 100% yet. >>>> >>>> If the app is running in the foreground, now the Json array is formed >>>> in a different way, and the alert window shows correctly and loads all the >>>> paramaters: >>>> >>>> >>>> >>>> *2014-03-18 22:00:12.980 SmartDrifter[4011:60b] Msg: {"alert":"Ol?! >>>> Benvindo aos Armaz?ns do Chiado","badge":"1","payload": >>>> {"lt":"0.00000000000","cd":"","av":"Ol?! Benvindo aos Armaz?ns do >>>> Chiado","ul":"http://metal-pr.net/c/?79 >>>> ","ln":"0.00000000000","en":"598","at":"Aviso","cp":"79","rd":"0",},"foreground":"1"} >>>> *But if the message arrives first to the status bar (meaning: the app >>>> is not available), then nothing happens when I press the notification: the >>>> app opens indeed, but no alert window shows. Unfortunately I could not >>>> trace any errors, neither through the Safari debugger (the problem happens >>>> too soon, maybe before the index.html is fully available), nor through >>>> Xcode. But the problem has nothing to do with the previously faulty >>>> parameters because an alert(e.alert) doesn't trigger nothing either... >>>> >>>> >>>> On Tue, Mar 18, 2014 at 9:56 PM, Miguel Lemos wrote: >>>> >>>>> Too soon, unfortunately ! >>>>> >>>>> Isn't yet 100% perfect. There's still a problem if the app is running >>>>> in the background. I must dig further to understand why it happens :-( >>>>> >>>>> >>>>> On Tue, Mar 18, 2014 at 9:50 PM, Sebastien Blanc wrote: >>>>> >>>>>> Cool ! >>>>>> Would be nice if you could add a comment here >>>>>> https://github.com/aerogear/aerogear-pushplugin-cordova/pull/20 like >>>>>> "+1 it's working" , assuming you have a github account. >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Mar 18, 2014 at 10:46 PM, Miguel Lemos wrote: >>>>>> >>>>>>> Thanks Seb :-) >>>>>>> >>>>>>> I had already notice that and installed the new file "? la main". >>>>>>> I't working ! >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 18, 2014 at 9:45 PM, Miguel Lemos wrote: >>>>>>> >>>>>>>> Forget my previous post! Done ;-) >>>>>>>> >>>>>>>> I uploaded and installed directly the PushPugin.m to its location. >>>>>>>> I didn't pay attention to what you wrote... >>>>>>>> It's working OK now and there's no error. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Mar 18, 2014 at 9:30 PM, Miguel Lemos >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Erik, >>>>>>>>> >>>>>>>>> I just uninstalled and installed again the Aerogear plugin, >>>>>>>>> removed and installed again the Ios platform, I compiled the program, but >>>>>>>>> the result didn't change: >>>>>>>>> >>>>>>>>> >>>>>>>>> XCode debugger: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *2014-03-18 21:24:11.983 SmartDrifter[3892:60b] Msg: >>>>>>>>> {en:'598',cd:'',badge:'1',alert:'Teste',av:'Teste',ul:'',ln:'',at:'Aviso',cp:'',rd:'',lt:'',foreground:'1',} >>>>>>>>> * >>>>>>>>> >>>>>>>>> cordova plugin add org.jboss.aerogear.cordova.push >>>>>>>>> >>>>>>>>> Maybe you didn't uploaded it yet? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> M >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Mar 18, 2014 at 4:41 PM, Miguel Lemos < >>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Yes. That "trick" has to be used sometimes. That's a very >>>>>>>>>> annoying Cordova issue. Thanks. >>>>>>>>>> >>>>>>>>>> Enviado do meu iPhone >>>>>>>>>> >>>>>>>>>> No dia 18/03/2014, ?s 16:37, Sebastien Blanc >>>>>>>>>> escreveu: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Mar 18, 2014 at 5:34 PM, Miguel Lemos < >>>>>>>>>> miguel21op at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks Erik. I know that; the total payload never surpasses 256 >>>>>>>>>>> byes and the av parameter (the notification itself) 107 characters. >>>>>>>>>>> >>>>>>>>>>> After the correction I just have the reinstall the plugin? >>>>>>>>>>> >>>>>>>>>> That should be enough but it has sometime failed for me , in this >>>>>>>>>> case you will need to do a : >>>>>>>>>> >>>>>>>>>> cordova platform remove ios >>>>>>>>>> cordova platform add ios >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> M >>>>>>>>>>> >>>>>>>>>>> Enviado do meu iPhone >>>>>>>>>>> >>>>>>>>>>> No dia 18/03/2014, ?s 16:24, Erik Jan de Wit >>>>>>>>>>> escreveu: >>>>>>>>>>> >>>>>>>>>>> BTW Miguel I see that you are sending a lot of extras in the >>>>>>>>>>> message, be careful that Apple doesn?t allow the message to become to big >>>>>>>>>>> the max is 256 bytes. >>>>>>>>>>> >>>>>>>>>>> On 18 Mar,2014, at 17:08 , Erik Jan de Wit >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> PR submitted >>>>>>>>>>> https://github.com/aerogear/aerogear-pushplugin-cordova/pull/20 >>>>>>>>>>> >>>>>>>>>>> On 18 Mar,2014, at 15:49 , Miguel Lemos >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Fine, Erik! >>>>>>>>>>> >>>>>>>>>>> Nice to know it's easy to fix. >>>>>>>>>>> >>>>>>>>>>> A small issue, that caused - almost - everything to fail... >>>>>>>>>>> >>>>>>>>>>> I'm glad I could help in the role of "bug buster" ;-) >>>>>>>>>>> >>>>>>>>>>> Miguel >>>>>>>>>>> >>>>>>>>>>> Enviado do meu iPhone >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/69081189/attachment-0001.html From antoine.matyja at worldline.com Tue Apr 1 09:00:21 2014 From: antoine.matyja at worldline.com (A577127) Date: Tue, 1 Apr 2014 06:00:21 -0700 (PDT) Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1396019263157-7159.post@n5.nabble.com> References: <1396019263157-7159.post@n5.nabble.com> Message-ID: <1396357221121-7220.post@n5.nabble.com> Thanks for the answers, the situation is clearer now. However when I try to deploy the project with maven, I get errors. Here are a few logs of what I get when I try the command "mvn package jboss-as:deploy" (from the project directory, with my jboss server running) I looked on Google for these warnings and it looks like it's an old issue not that important.. Anyway. Then I get "Reactor summary" with everything skipped and this error : I googled it again and tryed a few things (check my proxy settings in maven, add ...) but nothing worked. Hope someone can help. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7220.html Sent from the aerogear-dev mailing list archive at Nabble.com. From edewit at redhat.com Tue Apr 1 08:29:53 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 1 Apr 2014 14:29:53 +0200 Subject: [aerogear-dev] Cordova and iOS new issue In-Reply-To: References: <724639B0-7694-4A63-AD7E-30C8BBC7F056@gmail.com> <51630639-2215-4A00-9655-A0DBC03AB851@redhat.com> <900F8FF6-1025-4BCB-8EC9-6EDD1D5952B3@gmail.com> <2074AB33-EC61-4B28-A1CD-0ADAD5785296@redhat.com> <8F6FEB68-6D1E-405B-85B8-9F0F46BC703C@redhat.com> <554D7D8B-7730-4C35-BB3D-45027CFE952A@gmail.com> <6AF0AA50-52D3-473C-BAFA-8F2D28D25F64@redhat.com> Message-ID: <77862359-BC03-4C13-AB74-5AFF541D1DF0@redhat.com> Sorry Miguel, If you are talking about the missing payload I?ve fixed that on the master branch and on the new ?simplification? branch in this commit https://github.com/aerogear/aerogear-pushplugin-cordova/commit/1aa8683e6431503b02b0e3dce8c84a4d8c2130be The reason the PushPlugin looks different is that instead of using our own logic to convert it to json it now uses cordovas. If this is not what you are talking about could you clarify what you seem to be missing? Cheers, Erik Jan On 1 Apr,2014, at 14:17 , Miguel Lemos wrote: > Hi! > > I downloaded the Cordova plugin with the last "updates", but apparently the corrections you did previously aren't there yet. I had to download the revised PushPlugin.m "by hand". -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/5f202fc8/attachment.html From supittma at redhat.com Tue Apr 1 09:12:58 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 01 Apr 2014 09:12:58 -0400 Subject: [aerogear-dev] AeroGear Controller In-Reply-To: References: Message-ID: <533ABB5A.6000001@redhat.com> On 04/01/2014 02:50 AM, Daniel Bevenius wrote: > Hi, > > was going over aerogear.org and found the > following information about AeroGear Controller: > > http://aerogear.org/download/ > http://aerogear.org/docs/specs/aerogear-controller/ > http://aerogear.org/docs/guides/aerogear-controller/ > http://aerogear.org/docs/planning/roadmaps/AeroGearController/ > > I think removing these from the site would simplify things and make > one less thing for new users to "have" to read about, only to find > that it is not being actively developed. > > Are there any objections about removing this content? No, kill it with fire > > /Dan > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/0511a627/attachment.html From supittma at redhat.com Tue Apr 1 09:14:08 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 01 Apr 2014 09:14:08 -0400 Subject: [aerogear-dev] Modularization and Push In-Reply-To: <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> Message-ID: <533ABBA0.7040803@redhat.com> On 03/31/2014 02:03 PM, Miiguel Lemos wrote: > Using the GCM for push notifications has a very important advantage: it minimizes the battery consumption, since it reduces the processor overload, it's not needed to open a socket to check the server on a regular basis, etc. In my opinion this a critical matter, minimizing the probability of the user turning the notifications off. On Android you can't turn notifications off in the same way as iOS. > > > Enviado do meu iPad > > No dia 31/03/2014, ?s 18:51, Bruno Oliveira escreveu: > >> I would vote for A >> >> -- >> abstractj >> >> On March 31, 2014 at 10:59:01 AM, Summers Pittman (supittma at redhat.com) wrote: >>>> Y'all, >>> So there has been some concerns with the complexity of the build >>> especially where including the Google GCM (push) libraries >>> are >>> concerned. Additionally there have been some requests for a >>> separate >>> "push" module which won't need the full aerogear android library. >>> >>> The full modularization of the library along with several other >>> improvements is scheduled for the "2.0" epic. >>> >>> So my question is a) Should we make a 2.0 which is only the >>> modularization sooner and iterate on that a few times before >>> we include >>> our improvements in a 3.0 or b) Should we create a "fork" project >>> which >>> is only a push module? This new project will get merged back into >>> the >>> main project when we have our complete modularizations. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From lholmqui at redhat.com Tue Apr 1 09:17:14 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 1 Apr 2014 09:17:14 -0400 Subject: [aerogear-dev] AeroGear.js without jQuery Discussion In-Reply-To: References: <6D6F35A3-BF5F-431E-A916-C5FB7966189E@redhat.com> <97A36F35-7C1C-4078-9594-ABD2A82A1D38@redhat.com> <20140325122659.38fb4055@kapy-ntb-x220> Message-ID: in the canary branch i started looking at removing jQuery from the UnifiedPush client code, since it only uses jQuery.Ajax. https://github.com/aerogear/aerogear-js/tree/canary i was thinking this would be a 2.0 thing, but for this particular module/adapter/whatevs, i think we can update it before that since we marked it "experimental" in datamanager we have the IndexedDB and WebSQL adapters marked as experimental, so we could do those, but since the other 2 adapters are not, we should probably wait. Just want to see what the team thought about that, before i started to go cray-cray -Luke On Mar 25, 2014, at 8:58 AM, Lucas Holmquist wrote: > > On Mar 25, 2014, at 8:15 AM, Luk?? Fry? wrote: > >> Side note: getting integration with jQuery{ajax,promises} right was one of the pain points when integrating with AeroGear.js / Angular (uses q.js, and custom http service). >> > i know they include their "own" version of jQuery > >> We must be sure whatever we choose is compatible with frameworks out there (at least it should not hard-nut to make it work). In terms of promises implementation. In the end people may even end up using 2-3 promise approaches in one project that makes code pretty disgusting. >> >> So: >> >> +1 getting rid of jQuery.ajax >> +1 getting rid of jQuery promises (they are just wrong anyway ;-) >> >> >> Btw in terms of polyfilling, I would suggest: >> >> 1) use whatever standard is as long as supported by majority of mainstream browsers >> >> 2) use whatever standard will be and compile polyfill into aerogear.js (as long as it's not too bloated; not necessary for bower users) >> > the polyfill i was thinking about is here https://github.com/jakearchibald/es6-promise > > it is just the spec and 2kb gzipped, which is nice > > and i think this could be an external( compiled in ) dep of the library > > >> Wdyt? >> >> >> >> On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko wrote: >> Given number of supported browsers is quite low - http://caniuse.com/promises, I >> believe that polyfill will be needed even with version 2.0. >> >> On Mon, 24 Mar 2014 12:01:38 -0400 >> Lucas Holmquist wrote: >> >> > >> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc wrote: >> > >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf >> > > wrote: >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc >> > > wrote: >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist >> > > wrote: >> > > >> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis >> > > wrote: >> > > >> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf : >> > >> >> > >> >> > >> >> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist >> > >> wrote: >> > >>> I agree that it would be nice to implement AGJS-70 (Investigate removing >> > >>> jQuery requirement). Meanwhile, there is an open source project on GitHub >> > >>> that claims to offer a custom builder for jQuery in order to include only >> > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we could >> > >>> create a custom jQuery build which includes only the parts currently >> > >>> needed in AeroGear. This would mean a smaller size of the jQuery >> > >>> dependency. >> > >> >> > >> The AG lib depends on a few parts of jQuery, the biggest being jQuery.Ajax >> > >> and the promise implementation. >> > >> >> > >> i know we can make custom builds of jQuery pretty easily( building from >> > >> source ), but i don't really want to bundle it within our lib. >> > >> >> > >> and i don't think with bower we can do this easily. although they did just >> > >> add a post install hook, so perhaps that could be something to look at. >> > >> >> > >> Datamanager only uses the promise implementation of jQuery( and some >> > >> random thing for the filter method, which could probably be updated ). >> > >> >> > >> >> > >> Promises are starting to become available natively in browsers and jQuery >> > >> doesn't use the Promise/A+ spec, so it could be harder to fallback >> > >> without a shim of some kind >> > >> >> > >> Good to know. Thanks for providing this info. >> > >> >> > >> >> > >> sounds reasonable to 'wait' on the promise side of things, and use that >> > >> bit in the datamanager >> > >> >> > >> +1 >> > > >> > > there are other promise implementations that we could use, that are to >> > > spec, such as Q and RSVP, here is the link to the HTML5 rocks article >> > > http://www.html5rocks.com/en/tutorials/es6/promises/ >> > > >> > > These last days I have been playing with the library When provided by Cujo, >> > > it's maybe also worth looking https://github.com/cujojs/when >> > > >> > > not sure I see value in using a different library as a temporary thing. >> > > Once the API is part of the browser platform, the need for [yet another js >> > > lib] goes away. I know but I'm more concerned about "Once the API is part >> > > of the browser platform" When will that happen and does it match with our >> > > roadmap ? Was also to offer a polyfill for older browser if we want to keep >> > > supporting them. >> > > >> > i will have to update the roadmap. >> > >> > 2.0 would be a nice time to "fully" switch, but we can start experimenting >> > now and maybe for 1.5 can have some implemenation for data manager only. >> > >> > Current Chrome has Promise's enable by default and it looks like FireFox >> > 29( next version ) will too. Safari and IE are in dev i believe >> > >> > for fallback we can still make use of jQuery i think because of this method >> > here "Promise.cast", although the closest lib to the spec is RSVP( maybe >> > this could be the 2.0 fallback if we remove jQuery from the whole lib ) >> > >> > >> > >> > > >> > > >> > > >> > > >> > >> >> > >> >> > >> >> > >> while i don't really want to reinvent the wheel in terms of Ajax, it >> > >> might be interesting to take a look. >> > >> >> > >> Yeah, IMO worth to look there, for reducing dependencies >> > >> >> > >> -M >> > >> >> > >> >> > >> >> > >> >> > >> I think in a previous ML thread about what 2.0 looked like, that >> > >> Pipeline would maybe just be a JSON only thing, with exception for >> > >> multipart >> > >> >> > >> >> > >> >> > >> @Lucas Thanks for making things clear >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at 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 >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at 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 >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/010e6321/attachment-0001.html From miguel21op at gmail.com Tue Apr 1 09:20:35 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Tue, 1 Apr 2014 14:20:35 +0100 Subject: [aerogear-dev] Cordova and iOS new issue In-Reply-To: <77862359-BC03-4C13-AB74-5AFF541D1DF0@redhat.com> References: <724639B0-7694-4A63-AD7E-30C8BBC7F056@gmail.com> <51630639-2215-4A00-9655-A0DBC03AB851@redhat.com> <900F8FF6-1025-4BCB-8EC9-6EDD1D5952B3@gmail.com> <2074AB33-EC61-4B28-A1CD-0ADAD5785296@redhat.com> <8F6FEB68-6D1E-405B-85B8-9F0F46BC703C@redhat.com> <554D7D8B-7730-4C35-BB3D-45027CFE952A@gmail.com> <6AF0AA50-52D3-473C-BAFA-8F2D28D25F64@redhat.com> <77862359-BC03-4C13-AB74-5AFF541D1DF0@redhat.com> Message-ID: Yes, that's it, thanks. I got the fix anyway, as I told you before. But then this means that people shouldn't use anymore the "cordova plugin add org.jboss.aerogear.cordova.push"? On Tue, Apr 1, 2014 at 1:29 PM, Erik Jan de Wit wrote: > Sorry Miguel, > > If you are talking about the missing payload I?ve fixed that on the master > branch and on the new ?simplification? branch in this commit > https://github.com/aerogear/aerogear-pushplugin-cordova/commit/1aa8683e6431503b02b0e3dce8c84a4d8c2130be > > > The reason the PushPlugin looks different is that instead of using our own > logic to convert it to json it now uses cordovas. > > If this is not what you are talking about could you clarify what you seem > to be missing? > > Cheers, > Erik Jan > > On 1 Apr,2014, at 14:17 , Miguel Lemos wrote: > > Hi! > > I downloaded the Cordova plugin with the last "updates", but apparently > the corrections you did previously aren't there yet. I had to download the > revised PushPlugin.m "by hand". > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/5163e4ea/attachment.html From miguel21op at gmail.com Tue Apr 1 09:22:45 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Tue, 1 Apr 2014 14:22:45 +0100 Subject: [aerogear-dev] Modularization and Push In-Reply-To: <533ABBA0.7040803@redhat.com> References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> <533ABBA0.7040803@redhat.com> Message-ID: ?! I can do it worse: uninstall the app because it drains the battery. On Tue, Apr 1, 2014 at 2:14 PM, Summers Pittman wrote: > On 03/31/2014 02:03 PM, Miiguel Lemos wrote: > > Using the GCM for push notifications has a very important advantage: it > minimizes the battery consumption, since it reduces the processor overload, > it's not needed to open a socket to check the server on a regular basis, > etc. In my opinion this a critical matter, minimizing the probability of > the user turning the notifications off. > On Android you can't turn notifications off in the same way as iOS. > > > > > > Enviado do meu iPad > > > > No dia 31/03/2014, ?s 18:51, Bruno Oliveira > escreveu: > > > >> I would vote for A > >> > >> -- > >> abstractj > >> > >> On March 31, 2014 at 10:59:01 AM, Summers Pittman (supittma at redhat.com) > wrote: > >>>> Y'all, > >>> So there has been some concerns with the complexity of the build > >>> especially where including the Google GCM (push) libraries > >>> are > >>> concerned. Additionally there have been some requests for a > >>> separate > >>> "push" module which won't need the full aerogear android library. > >>> > >>> The full modularization of the library along with several other > >>> improvements is scheduled for the "2.0" epic. > >>> > >>> So my question is a) Should we make a 2.0 which is only the > >>> modularization sooner and iterate on that a few times before > >>> we include > >>> our improvements in a 3.0 or b) Should we create a "fork" project > >>> which > >>> is only a push module? This new project will get merged back into > >>> the > >>> main project when we have our complete modularizations. > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/7b202f0e/attachment.html From lholmqui at redhat.com Tue Apr 1 09:23:15 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 1 Apr 2014 09:23:15 -0400 Subject: [aerogear-dev] AeroGear.js without jQuery Discussion In-Reply-To: References: <6D6F35A3-BF5F-431E-A916-C5FB7966189E@redhat.com> <97A36F35-7C1C-4078-9594-ABD2A82A1D38@redhat.com> <20140325122659.38fb4055@kapy-ntb-x220> Message-ID: On Apr 1, 2014, at 9:17 AM, Lucas Holmquist wrote: > in the canary branch i started looking at removing jQuery from the UnifiedPush client code, since it only uses jQuery.Ajax. > > https://github.com/aerogear/aerogear-js/tree/canary > > i was thinking this would be a 2.0 thing, but for this particular module/adapter/whatevs, i think we can update it before that since we marked it "experimental" > it's not just an internal change, since it returns a jQuery Defered object, so the return value would be different > in datamanager we have the IndexedDB and WebSQL adapters marked as experimental, so we could do those, but since the other 2 adapters are not, we should probably wait. > > Just want to see what the team thought about that, before i started to go cray-cray > > > -Luke > > > On Mar 25, 2014, at 8:58 AM, Lucas Holmquist wrote: > >> >> On Mar 25, 2014, at 8:15 AM, Luk?? Fry? wrote: >> >>> Side note: getting integration with jQuery{ajax,promises} right was one of the pain points when integrating with AeroGear.js / Angular (uses q.js, and custom http service). >>> >> i know they include their "own" version of jQuery >> >>> We must be sure whatever we choose is compatible with frameworks out there (at least it should not hard-nut to make it work). In terms of promises implementation. In the end people may even end up using 2-3 promise approaches in one project that makes code pretty disgusting. >>> >>> So: >>> >>> +1 getting rid of jQuery.ajax >>> +1 getting rid of jQuery promises (they are just wrong anyway ;-) >>> >>> >>> Btw in terms of polyfilling, I would suggest: >>> >>> 1) use whatever standard is as long as supported by majority of mainstream browsers >>> >>> 2) use whatever standard will be and compile polyfill into aerogear.js (as long as it's not too bloated; not necessary for bower users) >>> >> the polyfill i was thinking about is here https://github.com/jakearchibald/es6-promise >> >> it is just the spec and 2kb gzipped, which is nice >> >> and i think this could be an external( compiled in ) dep of the library >> >> >>> Wdyt? >>> >>> >>> >>> On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko wrote: >>> Given number of supported browsers is quite low - http://caniuse.com/promises, I >>> believe that polyfill will be needed even with version 2.0. >>> >>> On Mon, 24 Mar 2014 12:01:38 -0400 >>> Lucas Holmquist wrote: >>> >>> > >>> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc wrote: >>> > >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf >>> > > wrote: >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc >>> > > wrote: >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist >>> > > wrote: >>> > > >>> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis >>> > > wrote: >>> > > >>> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf : >>> > >> >>> > >> >>> > >> >>> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist >>> > >> wrote: >>> > >>> I agree that it would be nice to implement AGJS-70 (Investigate removing >>> > >>> jQuery requirement). Meanwhile, there is an open source project on GitHub >>> > >>> that claims to offer a custom builder for jQuery in order to include only >>> > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we could >>> > >>> create a custom jQuery build which includes only the parts currently >>> > >>> needed in AeroGear. This would mean a smaller size of the jQuery >>> > >>> dependency. >>> > >> >>> > >> The AG lib depends on a few parts of jQuery, the biggest being jQuery.Ajax >>> > >> and the promise implementation. >>> > >> >>> > >> i know we can make custom builds of jQuery pretty easily( building from >>> > >> source ), but i don't really want to bundle it within our lib. >>> > >> >>> > >> and i don't think with bower we can do this easily. although they did just >>> > >> add a post install hook, so perhaps that could be something to look at. >>> > >> >>> > >> Datamanager only uses the promise implementation of jQuery( and some >>> > >> random thing for the filter method, which could probably be updated ). >>> > >> >>> > >> >>> > >> Promises are starting to become available natively in browsers and jQuery >>> > >> doesn't use the Promise/A+ spec, so it could be harder to fallback >>> > >> without a shim of some kind >>> > >> >>> > >> Good to know. Thanks for providing this info. >>> > >> >>> > >> >>> > >> sounds reasonable to 'wait' on the promise side of things, and use that >>> > >> bit in the datamanager >>> > >> >>> > >> +1 >>> > > >>> > > there are other promise implementations that we could use, that are to >>> > > spec, such as Q and RSVP, here is the link to the HTML5 rocks article >>> > > http://www.html5rocks.com/en/tutorials/es6/promises/ >>> > > >>> > > These last days I have been playing with the library When provided by Cujo, >>> > > it's maybe also worth looking https://github.com/cujojs/when >>> > > >>> > > not sure I see value in using a different library as a temporary thing. >>> > > Once the API is part of the browser platform, the need for [yet another js >>> > > lib] goes away. I know but I'm more concerned about "Once the API is part >>> > > of the browser platform" When will that happen and does it match with our >>> > > roadmap ? Was also to offer a polyfill for older browser if we want to keep >>> > > supporting them. >>> > > >>> > i will have to update the roadmap. >>> > >>> > 2.0 would be a nice time to "fully" switch, but we can start experimenting >>> > now and maybe for 1.5 can have some implemenation for data manager only. >>> > >>> > Current Chrome has Promise's enable by default and it looks like FireFox >>> > 29( next version ) will too. Safari and IE are in dev i believe >>> > >>> > for fallback we can still make use of jQuery i think because of this method >>> > here "Promise.cast", although the closest lib to the spec is RSVP( maybe >>> > this could be the 2.0 fallback if we remove jQuery from the whole lib ) >>> > >>> > >>> > >>> > > >>> > > >>> > > >>> > > >>> > >> >>> > >> >>> > >> >>> > >> while i don't really want to reinvent the wheel in terms of Ajax, it >>> > >> might be interesting to take a look. >>> > >> >>> > >> Yeah, IMO worth to look there, for reducing dependencies >>> > >> >>> > >> -M >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> I think in a previous ML thread about what 2.0 looked like, that >>> > >> Pipeline would maybe just be a JSON only thing, with exception for >>> > >> multipart >>> > >> >>> > >> >>> > >> >>> > >> @Lucas Thanks for making things clear >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at 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 >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at 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 >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/40532780/attachment-0001.html From miguel21op at gmail.com Tue Apr 1 09:27:27 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Tue, 1 Apr 2014 14:27:27 +0100 Subject: [aerogear-dev] Modularization and Push In-Reply-To: References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> <533ABBA0.7040803@redhat.com> Message-ID: Besides, that: a) Every app should have a suspend or stop notifications option; b) In modern Android versions (at least from 4.0 on) you can stop notifications on a app basis: http://www.talkandroid.com/guides/beginner/how-to-disable-annoying-android-notifications/ On Tue, Apr 1, 2014 at 2:22 PM, Miguel Lemos wrote: > ?! I can do it worse: uninstall the app because it drains the battery. > > > On Tue, Apr 1, 2014 at 2:14 PM, Summers Pittman wrote: > >> On 03/31/2014 02:03 PM, Miiguel Lemos wrote: >> > Using the GCM for push notifications has a very important advantage: it >> minimizes the battery consumption, since it reduces the processor overload, >> it's not needed to open a socket to check the server on a regular basis, >> etc. In my opinion this a critical matter, minimizing the probability of >> the user turning the notifications off. >> On Android you can't turn notifications off in the same way as iOS. >> > >> > >> > Enviado do meu iPad >> > >> > No dia 31/03/2014, ?s 18:51, Bruno Oliveira >> escreveu: >> > >> >> I would vote for A >> >> >> >> -- >> >> abstractj >> >> >> >> On March 31, 2014 at 10:59:01 AM, Summers Pittman (supittma at redhat.com) >> wrote: >> >>>> Y'all, >> >>> So there has been some concerns with the complexity of the build >> >>> especially where including the Google GCM (push) libraries >> >>> are >> >>> concerned. Additionally there have been some requests for a >> >>> separate >> >>> "push" module which won't need the full aerogear android library. >> >>> >> >>> The full modularization of the library along with several other >> >>> improvements is scheduled for the "2.0" epic. >> >>> >> >>> So my question is a) Should we make a 2.0 which is only the >> >>> modularization sooner and iterate on that a few times before >> >>> we include >> >>> our improvements in a 3.0 or b) Should we create a "fork" project >> >>> which >> >>> is only a push module? This new project will get merged back into >> >>> the >> >>> main project when we have our complete modularizations. >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> Summers Pittman >> >>Phone:404 941 4698 >> >>Java is my crack. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/ce4b0e49/attachment.html From tolisemm at gmail.com Tue Apr 1 09:35:54 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Tue, 1 Apr 2014 16:35:54 +0300 Subject: [aerogear-dev] AeroGear.js without jQuery Discussion In-Reply-To: References: <6D6F35A3-BF5F-431E-A916-C5FB7966189E@redhat.com> <97A36F35-7C1C-4078-9594-ABD2A82A1D38@redhat.com> <20140325122659.38fb4055@kapy-ntb-x220> Message-ID: 2014-04-01 16:23 GMT+03:00 Lucas Holmquist : > > On Apr 1, 2014, at 9:17 AM, Lucas Holmquist wrote: > > in the canary branch i started looking at removing jQuery from the > UnifiedPush client code, since it only uses jQuery.Ajax. > > https://github.com/aerogear/aerogear-js/tree/canary > > i was thinking this would be a 2.0 thing, but for this particular > module/adapter/whatevs, i think we can update it before that since we > marked it "experimental" > > it's not just an internal change, since it returns a jQuery Defered > object, so the return value would be different > sounds reasonable. we could return the ES6 Promise using the polyfill discussed previously in the current thread > > in datamanager we have the IndexedDB and WebSQL adapters marked as > experimental, so we could do those, but since the other 2 adapters are > not, we should probably wait. > > Just want to see what the team thought about that, before i started to go > cray-cray > > > -Luke > > > On Mar 25, 2014, at 8:58 AM, Lucas Holmquist wrote: > > > On Mar 25, 2014, at 8:15 AM, Luk?? Fry? wrote: > > Side note: getting integration with jQuery{ajax,promises} right was one of > the pain points when integrating with AeroGear.js / Angular (uses q.js, and > custom http service). > > i know they include their "own" version of jQuery > > We must be sure whatever we choose is compatible with frameworks out there > (at least it should not hard-nut to make it work). In terms of promises > implementation. In the end people may even end up using 2-3 promise > approaches in one project that makes code pretty disgusting. > > So: > > +1 getting rid of jQuery.ajax > +1 getting rid of jQuery promises (they are just wrong anyway ;-) > > > Btw in terms of polyfilling, I would suggest: > > 1) use whatever standard *is* as long as supported by majority of > mainstream browsers > > 2) use whatever standard *will be *and compile polyfill into aerogear.js > (as long as it's not too bloated; not necessary for bower users) > > > the polyfill i was thinking about is here > https://github.com/jakearchibald/es6-promise > > it is just the spec and 2kb gzipped, which is nice > > and i think this could be an external( compiled in ) dep of the library > > > Wdyt? > > > > On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko wrote: > >> Given number of supported browsers is quite low - >> http://caniuse.com/promises, I >> believe that polyfill will be needed even with version 2.0. >> >> On Mon, 24 Mar 2014 12:01:38 -0400 >> Lucas Holmquist wrote: >> >> > >> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc >> wrote: >> > >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf < >> matzew at apache.org> >> > > wrote: >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc > > >> > > wrote: >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist > > >> > > wrote: >> > > >> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis > > >> > > wrote: >> > > >> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf : >> > >> >> > >> >> > >> >> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist < >> lholmqui at redhat.com> >> > >> wrote: >> > >>> I agree that it would be nice to implement AGJS-70 (Investigate >> removing >> > >>> jQuery requirement). Meanwhile, there is an open source project on >> GitHub >> > >>> that claims to offer a custom builder for jQuery in order to >> include only >> > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we >> could >> > >>> create a custom jQuery build which includes only the parts currently >> > >>> needed in AeroGear. This would mean a smaller size of the jQuery >> > >>> dependency. >> > >> >> > >> The AG lib depends on a few parts of jQuery, the biggest being >> jQuery.Ajax >> > >> and the promise implementation. >> > >> >> > >> i know we can make custom builds of jQuery pretty easily( building >> from >> > >> source ), but i don't really want to bundle it within our lib. >> > >> >> > >> and i don't think with bower we can do this easily. although they >> did just >> > >> add a post install hook, so perhaps that could be something to look >> at. >> > >> >> > >> Datamanager only uses the promise implementation of jQuery( and some >> > >> random thing for the filter method, which could probably be updated >> ). >> > >> >> > >> >> > >> Promises are starting to become available natively in browsers and >> jQuery >> > >> doesn't use the Promise/A+ spec, so it could be harder to fallback >> > >> without a shim of some kind >> > >> >> > >> Good to know. Thanks for providing this info. >> > >> >> > >> >> > >> sounds reasonable to 'wait' on the promise side of things, and use >> that >> > >> bit in the datamanager >> > >> >> > >> +1 >> > > >> > > there are other promise implementations that we could use, that are to >> > > spec, such as Q and RSVP, here is the link to the HTML5 rocks >> article >> > > http://www.html5rocks.com/en/tutorials/es6/promises/ >> > > >> > > These last days I have been playing with the library When provided by >> Cujo, >> > > it's maybe also worth looking https://github.com/cujojs/when >> > > >> > > not sure I see value in using a different library as a temporary >> thing. >> > > Once the API is part of the browser platform, the need for [yet >> another js >> > > lib] goes away. I know but I'm more concerned about "Once the API is >> part >> > > of the browser platform" When will that happen and does it match with >> our >> > > roadmap ? Was also to offer a polyfill for older browser if we want >> to keep >> > > supporting them. >> > > >> > i will have to update the roadmap. >> > >> > 2.0 would be a nice time to "fully" switch, but we can start >> experimenting >> > now and maybe for 1.5 can have some implemenation for data manager only. >> > >> > Current Chrome has Promise's enable by default and it looks like FireFox >> > 29( next version ) will too. Safari and IE are in dev i believe >> > >> > for fallback we can still make use of jQuery i think because of this >> method >> > here "Promise.cast", although the closest lib to the spec is RSVP( >> maybe >> > this could be the 2.0 fallback if we remove jQuery from the whole lib ) >> > >> > >> > >> > > >> > > >> > > >> > > >> > >> >> > >> >> > >> >> > >> while i don't really want to reinvent the wheel in terms of Ajax, it >> > >> might be interesting to take a look. >> > >> >> > >> Yeah, IMO worth to look there, for reducing dependencies >> > >> >> > >> -M >> > >> >> > >> >> > >> >> > >> >> > >> I think in a previous ML thread about what 2.0 looked like, that >> > >> Pipeline would maybe just be a JSON only thing, with exception for >> > >> multipart >> > >> >> > >> >> > >> >> > >> @Lucas Thanks for making things clear >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at 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 >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at 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 >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/8f827e53/attachment-0001.html From scm.blanc at gmail.com Tue Apr 1 09:36:46 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 1 Apr 2014 15:36:46 +0200 Subject: [aerogear-dev] AeroGear.js without jQuery Discussion In-Reply-To: References: <6D6F35A3-BF5F-431E-A916-C5FB7966189E@redhat.com> <97A36F35-7C1C-4078-9594-ABD2A82A1D38@redhat.com> <20140325122659.38fb4055@kapy-ntb-x220> Message-ID: On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist wrote: > in the canary branch i started looking at removing jQuery from the > UnifiedPush client code, since it only uses jQuery.Ajax. > > https://github.com/aerogear/aerogear-js/tree/canary > That's really cool and I will probably use this in my experimental FirefoxOS support for the Cordova Push Plugin > > i was thinking this would be a 2.0 thing, but for this particular > module/adapter/whatevs, i think we can update it before that since we > marked it "experimental" > > in datamanager we have the IndexedDB and WebSQL adapters marked as > experimental, so we could do those, but since the other 2 adapters are > not, we should probably wait. > > Just want to see what the team thought about that, before i started to go > cray-cray > > > -Luke > > > On Mar 25, 2014, at 8:58 AM, Lucas Holmquist wrote: > > > On Mar 25, 2014, at 8:15 AM, Luk?? Fry? wrote: > > Side note: getting integration with jQuery{ajax,promises} right was one of > the pain points when integrating with AeroGear.js / Angular (uses q.js, and > custom http service). > > i know they include their "own" version of jQuery > > We must be sure whatever we choose is compatible with frameworks out there > (at least it should not hard-nut to make it work). In terms of promises > implementation. In the end people may even end up using 2-3 promise > approaches in one project that makes code pretty disgusting. > > So: > > +1 getting rid of jQuery.ajax > +1 getting rid of jQuery promises (they are just wrong anyway ;-) > > > Btw in terms of polyfilling, I would suggest: > > 1) use whatever standard *is* as long as supported by majority of > mainstream browsers > > 2) use whatever standard *will be *and compile polyfill into aerogear.js > (as long as it's not too bloated; not necessary for bower users) > > > the polyfill i was thinking about is here > https://github.com/jakearchibald/es6-promise > > it is just the spec and 2kb gzipped, which is nice > > and i think this could be an external( compiled in ) dep of the library > > > Wdyt? > > > > On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko wrote: > >> Given number of supported browsers is quite low - >> http://caniuse.com/promises, I >> believe that polyfill will be needed even with version 2.0. >> >> On Mon, 24 Mar 2014 12:01:38 -0400 >> Lucas Holmquist wrote: >> >> > >> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc >> wrote: >> > >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf < >> matzew at apache.org> >> > > wrote: >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc > > >> > > wrote: >> > > >> > > >> > > >> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist > > >> > > wrote: >> > > >> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis > > >> > > wrote: >> > > >> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf : >> > >> >> > >> >> > >> >> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist < >> lholmqui at redhat.com> >> > >> wrote: >> > >>> I agree that it would be nice to implement AGJS-70 (Investigate >> removing >> > >>> jQuery requirement). Meanwhile, there is an open source project on >> GitHub >> > >>> that claims to offer a custom builder for jQuery in order to >> include only >> > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we >> could >> > >>> create a custom jQuery build which includes only the parts currently >> > >>> needed in AeroGear. This would mean a smaller size of the jQuery >> > >>> dependency. >> > >> >> > >> The AG lib depends on a few parts of jQuery, the biggest being >> jQuery.Ajax >> > >> and the promise implementation. >> > >> >> > >> i know we can make custom builds of jQuery pretty easily( building >> from >> > >> source ), but i don't really want to bundle it within our lib. >> > >> >> > >> and i don't think with bower we can do this easily. although they >> did just >> > >> add a post install hook, so perhaps that could be something to look >> at. >> > >> >> > >> Datamanager only uses the promise implementation of jQuery( and some >> > >> random thing for the filter method, which could probably be updated >> ). >> > >> >> > >> >> > >> Promises are starting to become available natively in browsers and >> jQuery >> > >> doesn't use the Promise/A+ spec, so it could be harder to fallback >> > >> without a shim of some kind >> > >> >> > >> Good to know. Thanks for providing this info. >> > >> >> > >> >> > >> sounds reasonable to 'wait' on the promise side of things, and use >> that >> > >> bit in the datamanager >> > >> >> > >> +1 >> > > >> > > there are other promise implementations that we could use, that are to >> > > spec, such as Q and RSVP, here is the link to the HTML5 rocks >> article >> > > http://www.html5rocks.com/en/tutorials/es6/promises/ >> > > >> > > These last days I have been playing with the library When provided by >> Cujo, >> > > it's maybe also worth looking https://github.com/cujojs/when >> > > >> > > not sure I see value in using a different library as a temporary >> thing. >> > > Once the API is part of the browser platform, the need for [yet >> another js >> > > lib] goes away. I know but I'm more concerned about "Once the API is >> part >> > > of the browser platform" When will that happen and does it match with >> our >> > > roadmap ? Was also to offer a polyfill for older browser if we want >> to keep >> > > supporting them. >> > > >> > i will have to update the roadmap. >> > >> > 2.0 would be a nice time to "fully" switch, but we can start >> experimenting >> > now and maybe for 1.5 can have some implemenation for data manager only. >> > >> > Current Chrome has Promise's enable by default and it looks like FireFox >> > 29( next version ) will too. Safari and IE are in dev i believe >> > >> > for fallback we can still make use of jQuery i think because of this >> method >> > here "Promise.cast", although the closest lib to the spec is RSVP( >> maybe >> > this could be the 2.0 fallback if we remove jQuery from the whole lib ) >> > >> > >> > >> > > >> > > >> > > >> > > >> > >> >> > >> >> > >> >> > >> while i don't really want to reinvent the wheel in terms of Ajax, it >> > >> might be interesting to take a look. >> > >> >> > >> Yeah, IMO worth to look there, for reducing dependencies >> > >> >> > >> -M >> > >> >> > >> >> > >> >> > >> >> > >> I think in a previous ML thread about what 2.0 looked like, that >> > >> Pipeline would maybe just be a JSON only thing, with exception for >> > >> multipart >> > >> >> > >> >> > >> >> > >> @Lucas Thanks for making things clear >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at 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 >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at 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 >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/f2aa2169/attachment.html From supittma at redhat.com Tue Apr 1 09:39:40 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 01 Apr 2014 09:39:40 -0400 Subject: [aerogear-dev] Modularization and Push In-Reply-To: References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> <533ABBA0.7040803@redhat.com> Message-ID: <533AC19C.2010607@redhat.com> On 04/01/2014 09:27 AM, Miguel Lemos wrote: > Besides, that: > > a) Every app should have a suspend or stop notifications option; Should yes. It isn't part of the app. > b) In modern Android versions (at least from 4.0 on) you can stop > notifications on a app basis: > > http://www.talkandroid.com/guides/beginner/how-to-disable-annoying-android-notifications/ Notifications != push messages. > > > On Tue, Apr 1, 2014 at 2:22 PM, Miguel Lemos > wrote: > > ?! I can do it worse: uninstall the app because it drains the battery. > > > On Tue, Apr 1, 2014 at 2:14 PM, Summers Pittman > > wrote: > > On 03/31/2014 02:03 PM, Miiguel Lemos wrote: > > Using the GCM for push notifications has a very important > advantage: it minimizes the battery consumption, since it > reduces the processor overload, it's not needed to open a > socket to check the server on a regular basis, etc. In my > opinion this a critical matter, minimizing the probability of > the user turning the notifications off. > On Android you can't turn notifications off in the same way as > iOS. > > > > > > Enviado do meu iPad > > > > No dia 31/03/2014, ?s 18:51, Bruno Oliveira > > escreveu: > > > >> I would vote for A > >> > >> -- > >> abstractj > >> > >> On March 31, 2014 at 10:59:01 AM, Summers Pittman > (supittma at redhat.com ) wrote: > >>>> Y'all, > >>> So there has been some concerns with the complexity of the > build > >>> especially where including the Google GCM (push) libraries > >>> are > >>> concerned. Additionally there have been some requests for a > >>> separate > >>> "push" module which won't need the full aerogear android > library. > >>> > >>> The full modularization of the library along with several > other > >>> improvements is scheduled for the "2.0" epic. > >>> > >>> So my question is a) Should we make a 2.0 which is only the > >>> modularization sooner and iterate on that a few times before > >>> we include > >>> our improvements in a 3.0 or b) Should we create a "fork" > project > >>> which > >>> is only a push module? This new project will get merged > back into > >>> the > >>> main project when we have our complete modularizations. > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/8a252d65/attachment-0001.html From supittma at redhat.com Tue Apr 1 09:41:21 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 01 Apr 2014 09:41:21 -0400 Subject: [aerogear-dev] Modularization and Push In-Reply-To: References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> <533ABBA0.7040803@redhat.com> Message-ID: <533AC201.8090401@redhat.com> On 04/01/2014 09:22 AM, Miguel Lemos wrote: > ?! I can do it worse: uninstall the app because it drains the battery. Push messages don't drain the battery that much. They all come in over the GCM socket which is refresh every 15 minutes or so. Keeping an open socket doesn't drain the battery that badly. IN a (contrived) experiment I had a socket which sent a packet every 5 minutes to the device. Over the course of 5 hours the app didn't even register on things which had drained the battery. > > > On Tue, Apr 1, 2014 at 2:14 PM, Summers Pittman > wrote: > > On 03/31/2014 02:03 PM, Miiguel Lemos wrote: > > Using the GCM for push notifications has a very important > advantage: it minimizes the battery consumption, since it reduces > the processor overload, it's not needed to open a socket to check > the server on a regular basis, etc. In my opinion this a critical > matter, minimizing the probability of the user turning the > notifications off. > On Android you can't turn notifications off in the same way as iOS. > > > > > > Enviado do meu iPad > > > > No dia 31/03/2014, ?s 18:51, Bruno Oliveira > escreveu: > > > >> I would vote for A > >> > >> -- > >> abstractj > >> > >> On March 31, 2014 at 10:59:01 AM, Summers Pittman > (supittma at redhat.com ) wrote: > >>>> Y'all, > >>> So there has been some concerns with the complexity of the build > >>> especially where including the Google GCM (push) libraries > >>> are > >>> concerned. Additionally there have been some requests for a > >>> separate > >>> "push" module which won't need the full aerogear android library. > >>> > >>> The full modularization of the library along with several other > >>> improvements is scheduled for the "2.0" epic. > >>> > >>> So my question is a) Should we make a 2.0 which is only the > >>> modularization sooner and iterate on that a few times before > >>> we include > >>> our improvements in a 3.0 or b) Should we create a "fork" project > >>> which > >>> is only a push module? This new project will get merged back into > >>> the > >>> main project when we have our complete modularizations. > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/b8d9165c/attachment.html From miguel21op at gmail.com Tue Apr 1 10:01:13 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Tue, 1 Apr 2014 15:01:13 +0100 Subject: [aerogear-dev] Modularization and Push In-Reply-To: <533AC201.8090401@redhat.com> References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> <533ABBA0.7040803@redhat.com> <533AC201.8090401@redhat.com> Message-ID: That's not the experience we have... There are hundreds (thousands?) of posts about this matter. There are several strategies to keep the processor alive to do its work and Android (using GCM) minimizes the overload, it's more or less a consensual idea. You'll find in the Internet several articles about this too. On Tue, Apr 1, 2014 at 2:41 PM, Summers Pittman wrote: > On 04/01/2014 09:22 AM, Miguel Lemos wrote: > > ?! I can do it worse: uninstall the app because it drains the battery. > > Push messages don't drain the battery that much. They all come in over > the GCM socket which is refresh every 15 minutes or so. > > Keeping an open socket doesn't drain the battery that badly. IN a > (contrived) experiment I had a socket which sent a packet every 5 minutes > to the device. Over the course of 5 hours the app didn't even register on > things which had drained the battery. > > > > > On Tue, Apr 1, 2014 at 2:14 PM, Summers Pittman wrote: > >> On 03/31/2014 02:03 PM, Miiguel Lemos wrote: >> > Using the GCM for push notifications has a very important advantage: it >> minimizes the battery consumption, since it reduces the processor overload, >> it's not needed to open a socket to check the server on a regular basis, >> etc. In my opinion this a critical matter, minimizing the probability of >> the user turning the notifications off. >> On Android you can't turn notifications off in the same way as iOS. >> > >> > >> > Enviado do meu iPad >> > >> > No dia 31/03/2014, ?s 18:51, Bruno Oliveira >> escreveu: >> > >> >> I would vote for A >> >> >> >> -- >> >> abstractj >> >> >> >> On March 31, 2014 at 10:59:01 AM, Summers Pittman (supittma at redhat.com) >> wrote: >> >>>> Y'all, >> >>> So there has been some concerns with the complexity of the build >> >>> especially where including the Google GCM (push) libraries >> >>> are >> >>> concerned. Additionally there have been some requests for a >> >>> separate >> >>> "push" module which won't need the full aerogear android library. >> >>> >> >>> The full modularization of the library along with several other >> >>> improvements is scheduled for the "2.0" epic. >> >>> >> >>> So my question is a) Should we make a 2.0 which is only the >> >>> modularization sooner and iterate on that a few times before >> >>> we include >> >>> our improvements in a 3.0 or b) Should we create a "fork" project >> >>> which >> >>> is only a push module? This new project will get merged back into >> >>> the >> >>> main project when we have our complete modularizations. >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> Summers Pittman >> >>Phone:404 941 4698 >> >>Java is my crack. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/fef00f96/attachment.html From bruno at abstractj.org Tue Apr 1 10:11:08 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 1 Apr 2014 11:11:08 -0300 Subject: [aerogear-dev] Modularization and Push In-Reply-To: References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> <533ABBA0.7040803@redhat.com> <533AC201.8090401@redhat.com> Message-ID: Miguel, do you have any references? If there are hundreds posts about it, I would love to read. On Tue, Apr 1, 2014 at 11:01 AM, Miguel Lemos wrote: > That's not the experience we have... There are hundreds (thousands?) of > posts about this matter. There are several strategies to keep the processor > alive to do its work and Android (using GCM) minimizes the overload, it's > more or less a consensual idea. You'll find in the Internet several > articles about this too. > > > > On Tue, Apr 1, 2014 at 2:41 PM, Summers Pittman wrote: > >> On 04/01/2014 09:22 AM, Miguel Lemos wrote: >> >> ?! I can do it worse: uninstall the app because it drains the battery. >> >> Push messages don't drain the battery that much. They all come in over >> the GCM socket which is refresh every 15 minutes or so. >> >> Keeping an open socket doesn't drain the battery that badly. IN a >> (contrived) experiment I had a socket which sent a packet every 5 minutes >> to the device. Over the course of 5 hours the app didn't even register on >> things which had drained the battery. >> >> >> >> >> On Tue, Apr 1, 2014 at 2:14 PM, Summers Pittman wrote: >> >>> On 03/31/2014 02:03 PM, Miiguel Lemos wrote: >>> > Using the GCM for push notifications has a very important advantage: >>> it minimizes the battery consumption, since it reduces the processor >>> overload, it's not needed to open a socket to check the server on a regular >>> basis, etc. In my opinion this a critical matter, minimizing the >>> probability of the user turning the notifications off. >>> On Android you can't turn notifications off in the same way as iOS. >>> > >>> > >>> > Enviado do meu iPad >>> > >>> > No dia 31/03/2014, ?s 18:51, Bruno Oliveira >>> escreveu: >>> > >>> >> I would vote for A >>> >> >>> >> -- >>> >> abstractj >>> >> >>> >> On March 31, 2014 at 10:59:01 AM, Summers Pittman ( >>> supittma at redhat.com) wrote: >>> >>>> Y'all, >>> >>> So there has been some concerns with the complexity of the build >>> >>> especially where including the Google GCM (push) libraries >>> >>> are >>> >>> concerned. Additionally there have been some requests for a >>> >>> separate >>> >>> "push" module which won't need the full aerogear android library. >>> >>> >>> >>> The full modularization of the library along with several other >>> >>> improvements is scheduled for the "2.0" epic. >>> >>> >>> >>> So my question is a) Should we make a 2.0 which is only the >>> >>> modularization sooner and iterate on that a few times before >>> >>> we include >>> >>> our improvements in a 3.0 or b) Should we create a "fork" project >>> >>> which >>> >>> is only a push module? This new project will get merged back into >>> >>> the >>> >>> main project when we have our complete modularizations. >>> >> _______________________________________________ >>> >> aerogear-dev mailing list >>> >> aerogear-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> -- >>> Summers Pittman >>> >>Phone:404 941 4698 >>> >>Java is my crack. >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> _______________________________________________ >> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Summers Pittman >> >>Phone:404 941 4698 >> >>Java is my crack. >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/2a86cde5/attachment-0001.html From matzew at apache.org Tue Apr 1 10:20:46 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Apr 2014 16:20:46 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1396357221121-7220.post@n5.nabble.com> References: <1396019263157-7159.post@n5.nabble.com> <1396357221121-7220.post@n5.nabble.com> Message-ID: 1) mvn clean install (on root level) 2) cd server 3) mvn package jboss-as:deploy -M On Tue, Apr 1, 2014 at 3:00 PM, A577127 wrote: > Thanks for the answers, the situation is clearer now. > > However when I try to deploy the project with maven, I get errors. Here are > a few logs of what I get when I try the command "mvn package > jboss-as:deploy" (from the project directory, with my jboss server running) > > > > > > I looked on Google for these warnings and it looks like it's an old issue > not that important.. Anyway. > > Then I get "Reactor summary" with everything skipped and this error : > > > > I googled it again and tryed a few things (check my proxy settings in > maven, > add ...) but nothing worked. > > Hope someone can help. > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7220.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/c7ff7997/attachment.html From matzew at apache.org Tue Apr 1 10:22:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Apr 2014 16:22:28 +0200 Subject: [aerogear-dev] Cordova and iOS new issue In-Reply-To: References: <724639B0-7694-4A63-AD7E-30C8BBC7F056@gmail.com> <51630639-2215-4A00-9655-A0DBC03AB851@redhat.com> <900F8FF6-1025-4BCB-8EC9-6EDD1D5952B3@gmail.com> <2074AB33-EC61-4B28-A1CD-0ADAD5785296@redhat.com> <8F6FEB68-6D1E-405B-85B8-9F0F46BC703C@redhat.com> <554D7D8B-7730-4C35-BB3D-45027CFE952A@gmail.com> <6AF0AA50-52D3-473C-BAFA-8F2D28D25F64@redhat.com> <77862359-BC03-4C13-AB74-5AFF541D1DF0@redhat.com> Message-ID: On Tue, Apr 1, 2014 at 3:20 PM, Miguel Lemos wrote: > > But then this means that people shouldn't use anymore the "cordova plugin > add org.jboss.aerogear.cordova.push"? > Huh, that would be really nasty! > > > > On Tue, Apr 1, 2014 at 1:29 PM, Erik Jan de Wit wrote: > >> Sorry Miguel, >> >> If you are talking about the missing payload I've fixed that on the >> master branch and on the new 'simplification' branch in this commit >> https://github.com/aerogear/aerogear-pushplugin-cordova/commit/1aa8683e6431503b02b0e3dce8c84a4d8c2130be >> >> >> The reason the PushPlugin looks different is that instead of using our >> own logic to convert it to json it now uses cordovas. >> >> If this is not what you are talking about could you clarify what you seem >> to be missing? >> >> Cheers, >> Erik Jan >> >> On 1 Apr,2014, at 14:17 , Miguel Lemos wrote: >> >> Hi! >> >> I downloaded the Cordova plugin with the last "updates", but apparently >> the corrections you did previously aren't there yet. I had to download the >> revised PushPlugin.m "by hand". >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/1f57c152/attachment.html From miguel21op at gmail.com Tue Apr 1 10:28:39 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Tue, 1 Apr 2014 15:28:39 +0100 Subject: [aerogear-dev] Modularization and Push In-Reply-To: References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> <533ABBA0.7040803@redhat.com> <533AC201.8090401@redhat.com> Message-ID: +"disable push notifications" +"battery life" +"android" > Google, for instance (I presume you use this). There are also several companies clamming that their push notifications services (including geo-fencing) drain less battery, etc., etc. On Tue, Apr 1, 2014 at 3:11 PM, Bruno Oliveira wrote: > Miguel, do you have any references? If there are hundreds posts about it, > I would love to read. > > > On Tue, Apr 1, 2014 at 11:01 AM, Miguel Lemos wrote: > >> That's not the experience we have... There are hundreds (thousands?) of >> posts about this matter. There are several strategies to keep the processor >> alive to do its work and Android (using GCM) minimizes the overload, it's >> more or less a consensual idea. You'll find in the Internet several >> articles about this too. >> >> >> >> On Tue, Apr 1, 2014 at 2:41 PM, Summers Pittman wrote: >> >>> On 04/01/2014 09:22 AM, Miguel Lemos wrote: >>> >>> ?! I can do it worse: uninstall the app because it drains the battery. >>> >>> Push messages don't drain the battery that much. They all come in over >>> the GCM socket which is refresh every 15 minutes or so. >>> >>> Keeping an open socket doesn't drain the battery that badly. IN a >>> (contrived) experiment I had a socket which sent a packet every 5 minutes >>> to the device. Over the course of 5 hours the app didn't even register on >>> things which had drained the battery. >>> >>> >>> >>> >>> On Tue, Apr 1, 2014 at 2:14 PM, Summers Pittman wrote: >>> >>>> On 03/31/2014 02:03 PM, Miiguel Lemos wrote: >>>> > Using the GCM for push notifications has a very important advantage: >>>> it minimizes the battery consumption, since it reduces the processor >>>> overload, it's not needed to open a socket to check the server on a regular >>>> basis, etc. In my opinion this a critical matter, minimizing the >>>> probability of the user turning the notifications off. >>>> On Android you can't turn notifications off in the same way as iOS. >>>> > >>>> > >>>> > Enviado do meu iPad >>>> > >>>> > No dia 31/03/2014, ?s 18:51, Bruno Oliveira >>>> escreveu: >>>> > >>>> >> I would vote for A >>>> >> >>>> >> -- >>>> >> abstractj >>>> >> >>>> >> On March 31, 2014 at 10:59:01 AM, Summers Pittman ( >>>> supittma at redhat.com) wrote: >>>> >>>> Y'all, >>>> >>> So there has been some concerns with the complexity of the build >>>> >>> especially where including the Google GCM (push) libraries >>>> >>> are >>>> >>> concerned. Additionally there have been some requests for a >>>> >>> separate >>>> >>> "push" module which won't need the full aerogear android library. >>>> >>> >>>> >>> The full modularization of the library along with several other >>>> >>> improvements is scheduled for the "2.0" epic. >>>> >>> >>>> >>> So my question is a) Should we make a 2.0 which is only the >>>> >>> modularization sooner and iterate on that a few times before >>>> >>> we include >>>> >>> our improvements in a 3.0 or b) Should we create a "fork" project >>>> >>> which >>>> >>> is only a push module? This new project will get merged back into >>>> >>> the >>>> >>> main project when we have our complete modularizations. >>>> >> _______________________________________________ >>>> >> aerogear-dev mailing list >>>> >> aerogear-dev at lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> -- >>>> Summers Pittman >>>> >>Phone:404 941 4698 >>>> >>Java is my crack. >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Summers Pittman >>> >>Phone:404 941 4698 >>> >>Java is my crack. >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/502a96ff/attachment-0001.html From miguel21op at gmail.com Tue Apr 1 10:31:03 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Tue, 1 Apr 2014 15:31:03 +0100 Subject: [aerogear-dev] Cordova and iOS new issue In-Reply-To: References: <724639B0-7694-4A63-AD7E-30C8BBC7F056@gmail.com> <51630639-2215-4A00-9655-A0DBC03AB851@redhat.com> <900F8FF6-1025-4BCB-8EC9-6EDD1D5952B3@gmail.com> <2074AB33-EC61-4B28-A1CD-0ADAD5785296@redhat.com> <8F6FEB68-6D1E-405B-85B8-9F0F46BC703C@redhat.com> <554D7D8B-7730-4C35-BB3D-45027CFE952A@gmail.com> <6AF0AA50-52D3-473C-BAFA-8F2D28D25F64@redhat.com> <77862359-BC03-4C13-AB74-5AFF541D1DF0@redhat.com> Message-ID: If so, then you must update the sources, because if we do it know the old bugs will be downloaded too. Just try it... On Tue, Apr 1, 2014 at 3:22 PM, Matthias Wessendorf wrote: > > > > On Tue, Apr 1, 2014 at 3:20 PM, Miguel Lemos wrote: > >> >> > But then this means that people shouldn't use anymore the "cordova plugin >> add org.jboss.aerogear.cordova.push"? >> > > > Huh, that would be really nasty! > > >> >> >> >> On Tue, Apr 1, 2014 at 1:29 PM, Erik Jan de Wit wrote: >> >>> Sorry Miguel, >>> >>> If you are talking about the missing payload I?ve fixed that on the >>> master branch and on the new ?simplification? branch in this commit >>> https://github.com/aerogear/aerogear-pushplugin-cordova/commit/1aa8683e6431503b02b0e3dce8c84a4d8c2130be >>> >>> >>> The reason the PushPlugin looks different is that instead of using our >>> own logic to convert it to json it now uses cordovas. >>> >>> If this is not what you are talking about could you clarify what you >>> seem to be missing? >>> >>> Cheers, >>> Erik Jan >>> >>> On 1 Apr,2014, at 14:17 , Miguel Lemos wrote: >>> >>> Hi! >>> >>> I downloaded the Cordova plugin with the last "updates", but apparently >>> the corrections you did previously aren't there yet. I had to download the >>> revised PushPlugin.m "by hand". >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/4fa91d78/attachment.html From edewit at redhat.com Tue Apr 1 10:33:38 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 1 Apr 2014 16:33:38 +0200 Subject: [aerogear-dev] Cordova and iOS new issue In-Reply-To: References: <724639B0-7694-4A63-AD7E-30C8BBC7F056@gmail.com> <51630639-2215-4A00-9655-A0DBC03AB851@redhat.com> <900F8FF6-1025-4BCB-8EC9-6EDD1D5952B3@gmail.com> <2074AB33-EC61-4B28-A1CD-0ADAD5785296@redhat.com> <8F6FEB68-6D1E-405B-85B8-9F0F46BC703C@redhat.com> <554D7D8B-7730-4C35-BB3D-45027CFE952A@gmail.com> <6AF0AA50-52D3-473C-BAFA-8F2D28D25F64@redhat.com> <77862359-BC03-4C13-AB74-5AFF541D1DF0@redhat.com> Message-ID: <754CD2B4-44D6-4330-8F1E-CD91D47ECD2F@redhat.com> Hi Miguel, Try and flushing the plugman cache (~/.plugman/cache) and install it again. Cheers, Erik Jan On 1 Apr,2014, at 16:31 , Miguel Lemos wrote: > If so, then you must update the sources, because if we do it know the old bugs will be downloaded too. Just try it... > > > On Tue, Apr 1, 2014 at 3:22 PM, Matthias Wessendorf wrote: > > > > On Tue, Apr 1, 2014 at 3:20 PM, Miguel Lemos wrote: > > But then this means that people shouldn't use anymore the "cordova plugin add org.jboss.aerogear.cordova.push"? > > > Huh, that would be really nasty! > > > > > > On Tue, Apr 1, 2014 at 1:29 PM, Erik Jan de Wit wrote: > Sorry Miguel, > > If you are talking about the missing payload I?ve fixed that on the master branch and on the new ?simplification? branch in this commit https://github.com/aerogear/aerogear-pushplugin-cordova/commit/1aa8683e6431503b02b0e3dce8c84a4d8c2130be > > The reason the PushPlugin looks different is that instead of using our own logic to convert it to json it now uses cordovas. > > If this is not what you are talking about could you clarify what you seem to be missing? > > Cheers, > Erik Jan > > On 1 Apr,2014, at 14:17 , Miguel Lemos wrote: > >> Hi! >> >> I downloaded the Cordova plugin with the last "updates", but apparently the corrections you did previously aren't there yet. I had to download the revised PushPlugin.m "by hand". > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/6cdf53e1/attachment.html From antoine.matyja at worldline.com Tue Apr 1 10:33:53 2014 From: antoine.matyja at worldline.com (A577127) Date: Tue, 1 Apr 2014 07:33:53 -0700 (PDT) Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: References: <1396019263157-7159.post@n5.nabble.com> <1396357221121-7220.post@n5.nabble.com> Message-ID: <1396362833092-7239.post@n5.nabble.com> Thank you ! I thought I've already tryed to run the command from the server directory but I just tryed it and it worked perfectly. Awesome. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7239.html Sent from the aerogear-dev mailing list archive at Nabble.com. From bruno at abstractj.org Tue Apr 1 10:34:04 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 1 Apr 2014 11:34:04 -0300 Subject: [aerogear-dev] Modularization and Push In-Reply-To: References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> <533ABBA0.7040803@redhat.com> <533AC201.8090401@redhat.com> Message-ID: "Several" is very accurate :) I would say so that 99% of the companies disagree on that On Tue, Apr 1, 2014 at 11:28 AM, Miguel Lemos wrote: > +"disable push notifications" +"battery life" +"android" > Google, for > instance (I presume you use this). > > There are also several companies clamming that their push notifications > services (including geo-fencing) drain less battery, etc., etc. > > > On Tue, Apr 1, 2014 at 3:11 PM, Bruno Oliveira wrote: > >> Miguel, do you have any references? If there are hundreds posts about it, >> I would love to read. >> >> >> On Tue, Apr 1, 2014 at 11:01 AM, Miguel Lemos wrote: >> >>> That's not the experience we have... There are hundreds (thousands?) of >>> posts about this matter. There are several strategies to keep the processor >>> alive to do its work and Android (using GCM) minimizes the overload, it's >>> more or less a consensual idea. You'll find in the Internet several >>> articles about this too. >>> >>> >>> >>> On Tue, Apr 1, 2014 at 2:41 PM, Summers Pittman wrote: >>> >>>> On 04/01/2014 09:22 AM, Miguel Lemos wrote: >>>> >>>> ?! I can do it worse: uninstall the app because it drains the battery. >>>> >>>> Push messages don't drain the battery that much. They all come in over >>>> the GCM socket which is refresh every 15 minutes or so. >>>> >>>> Keeping an open socket doesn't drain the battery that badly. IN a >>>> (contrived) experiment I had a socket which sent a packet every 5 minutes >>>> to the device. Over the course of 5 hours the app didn't even register on >>>> things which had drained the battery. >>>> >>>> >>>> >>>> >>>> On Tue, Apr 1, 2014 at 2:14 PM, Summers Pittman wrote: >>>> >>>>> On 03/31/2014 02:03 PM, Miiguel Lemos wrote: >>>>> > Using the GCM for push notifications has a very important advantage: >>>>> it minimizes the battery consumption, since it reduces the processor >>>>> overload, it's not needed to open a socket to check the server on a regular >>>>> basis, etc. In my opinion this a critical matter, minimizing the >>>>> probability of the user turning the notifications off. >>>>> On Android you can't turn notifications off in the same way as iOS. >>>>> > >>>>> > >>>>> > Enviado do meu iPad >>>>> > >>>>> > No dia 31/03/2014, ?s 18:51, Bruno Oliveira >>>>> escreveu: >>>>> > >>>>> >> I would vote for A >>>>> >> >>>>> >> -- >>>>> >> abstractj >>>>> >> >>>>> >> On March 31, 2014 at 10:59:01 AM, Summers Pittman ( >>>>> supittma at redhat.com) wrote: >>>>> >>>> Y'all, >>>>> >>> So there has been some concerns with the complexity of the build >>>>> >>> especially where including the Google GCM (push) libraries >>>>> >>> are >>>>> >>> concerned. Additionally there have been some requests for a >>>>> >>> separate >>>>> >>> "push" module which won't need the full aerogear android library. >>>>> >>> >>>>> >>> The full modularization of the library along with several other >>>>> >>> improvements is scheduled for the "2.0" epic. >>>>> >>> >>>>> >>> So my question is a) Should we make a 2.0 which is only the >>>>> >>> modularization sooner and iterate on that a few times before >>>>> >>> we include >>>>> >>> our improvements in a 3.0 or b) Should we create a "fork" project >>>>> >>> which >>>>> >>> is only a push module? This new project will get merged back into >>>>> >>> the >>>>> >>> main project when we have our complete modularizations. >>>>> >> _______________________________________________ >>>>> >> aerogear-dev mailing list >>>>> >> aerogear-dev at lists.jboss.org >>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> > _______________________________________________ >>>>> > aerogear-dev mailing list >>>>> > aerogear-dev at lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> -- >>>>> Summers Pittman >>>>> >>Phone:404 941 4698 >>>>> >>Java is my crack. >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Summers Pittman >>>> >>Phone:404 941 4698 >>>> >>Java is my crack. >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> >> -- >> "The measure of a man is what he does with power" - Plato >> - >> @abstractj >> - >> Volenti Nihil Difficile >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/4b5a7f03/attachment-0001.html From matzew at apache.org Tue Apr 1 10:45:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Apr 2014 16:45:25 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1396362833092-7239.post@n5.nabble.com> References: <1396019263157-7159.post@n5.nabble.com> <1396357221121-7220.post@n5.nabble.com> <1396362833092-7239.post@n5.nabble.com> Message-ID: yay! glad it works!! On Tue, Apr 1, 2014 at 4:33 PM, A577127 wrote: > Thank you ! I thought I've already tryed to run the command from the server > directory but I just tryed it and it worked perfectly. Awesome. > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7239.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/c9a11a1b/attachment.html From miguel21op at gmail.com Tue Apr 1 11:04:42 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Tue, 1 Apr 2014 16:04:42 +0100 Subject: [aerogear-dev] Modularization and Push In-Reply-To: References: <533974A1.1020406@redhat.com> <45CFD6B3-70E6-421F-A5F5-1FEB5CC7B2A0@gmail.com> <533ABBA0.7040803@redhat.com> <533AC201.8090401@redhat.com> Message-ID: Whatever. If you think power consumption is not a matter of concern on choosing a push notifications technology (as well as other mobile services) what can I do? Enviado do meu iPhone No dia 01/04/2014, ?s 15:34, Bruno Oliveira escreveu: > "Several" is very accurate :) I would say so that 99% of the companies disagree on that > > >> On Tue, Apr 1, 2014 at 11:28 AM, Miguel Lemos wrote: >> +"disable push notifications" +"battery life" +"android" > Google, for instance (I presume you use this). >> >> There are also several companies clamming that their push notifications services (including geo-fencing) drain less battery, etc., etc. >> >> >>> On Tue, Apr 1, 2014 at 3:11 PM, Bruno Oliveira wrote: >>> Miguel, do you have any references? If there are hundreds posts about it, I would love to read. >>> >>> >>>> On Tue, Apr 1, 2014 at 11:01 AM, Miguel Lemos wrote: >>>> That's not the experience we have... There are hundreds (thousands?) of posts about this matter. There are several strategies to keep the processor alive to do its work and Android (using GCM) minimizes the overload, it's more or less a consensual idea. You'll find in the Internet several articles about this too. >>>> >>>> >>>> >>>>> On Tue, Apr 1, 2014 at 2:41 PM, Summers Pittman wrote: >>>>>> On 04/01/2014 09:22 AM, Miguel Lemos wrote: >>>>>> ?! I can do it worse: uninstall the app because it drains the battery. >>>>> Push messages don't drain the battery that much. They all come in over the GCM socket which is refresh every 15 minutes or so. >>>>> >>>>> Keeping an open socket doesn't drain the battery that badly. IN a (contrived) experiment I had a socket which sent a packet every 5 minutes to the device. Over the course of 5 hours the app didn't even register on things which had drained the battery. >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 1, 2014 at 2:14 PM, Summers Pittman wrote: >>>>>>> On 03/31/2014 02:03 PM, Miiguel Lemos wrote: >>>>>>> > Using the GCM for push notifications has a very important advantage: it minimizes the battery consumption, since it reduces the processor overload, it's not needed to open a socket to check the server on a regular basis, etc. In my opinion this a critical matter, minimizing the probability of the user turning the notifications off. >>>>>>> On Android you can't turn notifications off in the same way as iOS. >>>>>>> > >>>>>>> > >>>>>>> > Enviado do meu iPad >>>>>>> > >>>>>>> > No dia 31/03/2014, ?s 18:51, Bruno Oliveira escreveu: >>>>>>> > >>>>>>> >> I would vote for A >>>>>>> >> >>>>>>> >> -- >>>>>>> >> abstractj >>>>>>> >> >>>>>>> >> On March 31, 2014 at 10:59:01 AM, Summers Pittman (supittma at redhat.com) wrote: >>>>>>> >>>> Y'all, >>>>>>> >>> So there has been some concerns with the complexity of the build >>>>>>> >>> especially where including the Google GCM (push) libraries >>>>>>> >>> are >>>>>>> >>> concerned. Additionally there have been some requests for a >>>>>>> >>> separate >>>>>>> >>> "push" module which won't need the full aerogear android library. >>>>>>> >>> >>>>>>> >>> The full modularization of the library along with several other >>>>>>> >>> improvements is scheduled for the "2.0" epic. >>>>>>> >>> >>>>>>> >>> So my question is a) Should we make a 2.0 which is only the >>>>>>> >>> modularization sooner and iterate on that a few times before >>>>>>> >>> we include >>>>>>> >>> our improvements in a 3.0 or b) Should we create a "fork" project >>>>>>> >>> which >>>>>>> >>> is only a push module? This new project will get merged back into >>>>>>> >>> the >>>>>>> >>> main project when we have our complete modularizations. >>>>>>> >> _______________________________________________ >>>>>>> >> aerogear-dev mailing list >>>>>>> >> aerogear-dev at lists.jboss.org >>>>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> > _______________________________________________ >>>>>>> > aerogear-dev mailing list >>>>>>> > aerogear-dev at lists.jboss.org >>>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Summers Pittman >>>>>>> >>Phone:404 941 4698 >>>>>>> >>Java is my crack. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> -- >>>>> Summers Pittman >>>>> >>Phone:404 941 4698 >>>>> >>Java is my crack. >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> >>> -- >>> "The measure of a man is what he does with power" - Plato >>> - >>> @abstractj >>> - >>> Volenti Nihil Difficile >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/df6afb16/attachment.html From kpiwko at redhat.com Tue Apr 1 12:14:44 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 1 Apr 2014 18:14:44 +0200 Subject: [aerogear-dev] automated plugin release In-Reply-To: <1256FE9B-0E31-4EBA-86A1-56E622FF8B38@redhat.com> References: <20140401132748.1a406a27@kapy-ntb-x220> <1256FE9B-0E31-4EBA-86A1-56E622FF8B38@redhat.com> Message-ID: <20140401181444.284995b4@kapy-ntb-x220> On Tue, 1 Apr 2014 14:13:26 +0200 Erik Jan de Wit wrote: > On 1 Apr,2014, at 13:27 , Karel Piwko wrote: > > > Sounds great. > > > > I'd like to contribute with integration tests (for Android part) we have > > and add them to the release process script (we use gradle/maven/java, so it > > should be easy to combine). > > > > Here is the itest workflow > > 1/ create a cordova app via cli (using to-be-release-version plugin) > > 2/ build app > > 3/ start android emulator/connect to real device > > 4/ deploy ups (or use openshift instance) > > 5/ install app > > 6/ execute test > > a/ check app is registered > > b/ send message > > c/ check message is received - various variants (foreground, > > background, etc) > > 7/ cleanup (uninstall, stop, etc) > > > > I?ve automated step 1 as well, let?s merge our efforts and make a cool gradle > script out of this. I think it would also make sense to release all plugins > at one and not a single one at a time. Awesome. Just let me know where I can find your script so I can start adding integration tests there. > > > All but step 1/ are currently automated for Cordova/Android. For iOS is it > > more complicated, given the fact you can't test APNs in simulator. > > > > Karel > > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Apr 1 12:27:18 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Apr 2014 18:27:18 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: Hello, here are the JIRAs (tasks and epics (which have sub-tasks) for this, so far: Github repo work: https://issues.jboss.org/browse/AGPUSH-586 https://issues.jboss.org/browse/AGPUSH-587 Hello-World Example work (epic): https://issues.jboss.org/browse/AGPUSH-588 Quickstart-server (epic): https://issues.jboss.org/browse/AGPUSH-596 Quickstart-client (epic): https://issues.jboss.org/browse/AGPUSH-604 It's totally valid to: - add more sub-tasks, or break sub-tasks out into epics (e.g. if they have several work units). Greetings, Matthias On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf wrote: > Hello there, > > we recently had talks about creating some simplified quickstarts and > hello-word demos, related to the UnifiedPush Server and JBoss AS developers: > > * Hello World (No Server Code - just client receiving push, no fancy > (complex) UI on the client, nor integrated into a Cookbook or something > that has "dependencies") > ** Cordova > ** Android > > For iOS that is already there: > https://github.com/aerogear/aerogear-push-ios-demo > > Yes, just usage of the "Push Registration SDKs", is the goal here: keep it > simple, since native push can be a complicated use-case all on its own and > so it will be good to make sure we cover the basics here. > > > Beyond the Hello-World, we wanted some different quickstarts. The "server" > components that come to mind would be: > > *Secured CRUD + Push Integration (Java Sender) > ** JAX-RS + PicketLink > ** SpringMVC/Spring Security > ** JAX-RS + Apache Camel > > These need to function on both JBoss AS 7.X and EAP. > > Josh, from the JDF team, has already said he wants to help on the server > projects (especially the JAX-RS/PL and Spring ones). yay! > Note: Josh already has a simple backend started that is used in JDF > quickstarts that would be good to re-use to make it easier for developers > to transition from one to other. > > > The goal would be the SERVER acts same to outside (identical REST > endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. > Camel)) > > For these different servers, there would be mobile apps needed: > * Android > * Cordova > * iOS > > > The idea would be to keep them simple and straightforward as well, e.g. > for iOS that means plain usage of NSURLConnection / NSURLSession. But for > the "push registration" of the client, > the iOS-push SDK would be used (same/similar would apply to Cordova or > Android). Similar to the above 'Hello World', the quickstarts are going to > be focused only on Push functionality, so for these we would leave out > pipes and such until later versions. > > > I will be creating Epics and subtasks in JIRA for this. > > For the location of all these projects, I had this "uber repo" location in > mind: > * https://github.com/aerogear/aerogear-push-helloworld > * https://github.com/aerogear/aerogear-push-quickstarts > > Greetings, > Matthias > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/3025c23a/attachment-0001.html From bruno at abstractj.org Tue Apr 1 13:04:14 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 01 Apr 2014 10:04:14 -0700 (PDT) Subject: [aerogear-dev] automated plugin release In-Reply-To: References: Message-ID: <1396371853300.42d3f3d9@Nodemailer> Go for it? abstractj On Tue, Apr 1, 2014 at 4:54 AM, Erik Jan de Wit wrote: > Hi, > Because the release process for cordova plugins has a lot of steps and because it?s a source distribution I would like to suggest an automated process for releasing and testing the plugins. > What I would like to suggest is that we create a gradle script (for instance can be something else) that will execute the tests, merge the development branch create a tag and publish to plugins.cordova.io. I?ve already experimented with it a bit and it seems very doable. > So what do you think? > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/af65ebeb/attachment.html From michi.oshima at gmail.com Tue Apr 1 14:50:17 2014 From: michi.oshima at gmail.com (Michi Oshima) Date: Tue, 1 Apr 2014 14:50:17 -0400 Subject: [aerogear-dev] Stuck in spConnect() Message-ID: Hi, I'm trying to adapt the sample code under aerogear-simplepush-unifiedpush-quickstartfor my application. I'm having a problem inside spConnect() function . When I first ran my code PushManager.register() call was successful, and it returned a pushEndpoint. But I had mistyped the code somewhere below and I never got to call UPClient.registerWithPushServer(...) . Every subsequent run of the spConnect() function skips the line to call UPClient.registerWithPushServer(...), because PushManager.register() call doesn't return a pushEndpoint. (That's what you check in this line, correct?) I'm guessing that I am somehow successfully registered with the simple push server, but not with the unified push server. I'm very new to AeroGear, so I'm not at all sure. 1. How should I best recover from this? 2. If I'm correct about what's going on, how should I rearrange the code so that I can properly handle the situation where I'm registered with the simple push server but not with the unified push server? Thank you, Michi Oshima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/183e3cd1/attachment.html From matzew at apache.org Tue Apr 1 15:05:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Apr 2014 21:05:17 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> Message-ID: On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: > still exploring > :-) any recent thoughts on 'encodeURIComponent()' ? > > On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: > > > > > On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: > >> i might have a couple thoughts, but i need to try some things out first >> > > Any update on that or does the solution proposed by Matzew (using encodeURIComponent() > ) could be enough ? > >> >> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >> >> >> >> >> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >> >>> Ok, >>> I've been doing some tests by using the PushEndpoint as device token. >>> For registration it works but I just faced an issue by trying to unregister >>> because the URL for the DELETE looks like : >>> >>> >>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[ >>> >>> And the REST endpoint get a bit crazy by the extra "/" present in the >>> endpoint URL. Therefore, I think we must just use the last URL fragment as >>> deviceToken. >>> >> >> Ok answering to myself ;) That won't work neither since if we do that UPS >> won't have the compllete push endpoint URL. >> So how do we deal with that ? >> >>> >>> >>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc < >>>>>>> scm.blanc at gmail.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> While playing today with my Firefox Device and its native Simple >>>>>>>> Push support I noticed some differences between our implementation and the >>>>>>>> native Push regarding the success callback after a register : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> //Native FFOS Push >>>>>>>> broadcastRequest = navigator.push.register(); >>>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> //Aerogear Push Adapter >>>>>>>> broadcastRequest = navigator.push.register(); >>>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>>>>>>> channelID = broadcastRequest.result.channelID; >>>>>>>> version = broadcastRequest.result.version; >>>>>>>> status = broadcastRequest.result.status >>>>>>>> } >>>>>>>> >>>>>>>> So, the AeroGear Push exposes much more in the callback that it >>>>>>>> should suppose to do : just exposing the pushEndpoint. >>>>>>>> >>>>>>>> The reason we do that I suppose, but Luke or Kris could confirm >>>>>>>> that, is that we thought respecting the SPS protocol, which indeed returns >>>>>>>> a whole object containing all the info. It is just that the Native Push >>>>>>>> Client API filter that out in the callback response. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Did they change that recently? Or was theirs always like it is now ? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> After discussing that on the #push channel with the Mozilla >>>>>>>> people they confirmed me that we should only expoe the pushEndpoint. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> yep, I agree on changing our JS polyfil >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> If we keep it as is, this can be problematic when we want to use >>>>>>>> the same code both for native and with the adapter when, for instance, >>>>>>>> registering to the UPS : >>>>>>>> >>>>>>>> broadcastRequest = navigator.push.register(); >>>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>>> broadcastEndpoint = event.target.result; >>>>>>>> var broadCastSettings = { >>>>>>>> metadata: { >>>>>>>> deviceToken: broadcastEndpoint.channelID, >>>>>>>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>>>>>>> } >>>>>>>> } >>>>>>>> UPClient.registerWithPushServer(broadCastSettings); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This won't work with the native push since "broadcastEndpoint.channelID" >>>>>>>> will be undefined. >>>>>>>> >>>>>>> >>>>>>> sweet :-) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> So I propose that we change the behaviour, to return only the >>>>>>>> pushEndpoint in the callback, even if that means a bit of String >>>>>>>> manipulation when we want to perform the registration to the UPS : >>>>>>>> >>>>>>>> var broadCastSettings = { >>>>>>>> metadata: { >>>>>>>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>>>>>>> simplePushEndpoint: broadcastEndpoint >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> well, that's not really good for security reasons, since their >>>>>>> looooong 'substring' was done for that. Also that's just redundant. >>>>>>> >>>>>>> The I guess, the deviceToken (channelID registration) might be a bit >>>>>>> bogus, for SimplePush. Let me think about it.... >>>>>>> >>>>>> >>>>>> >>>>>> Right now we use the channelID as the deviceToken, but we should not >>>>>> really 'leak' the channelID (see [1]), so I guess the here proposed change >>>>>> makes sense. Don't recall exactly why we did it in the past, but yeah - >>>>>> let's change it. >>>>>> >>>>>> >>>>>> Thinking about the consequence: I think we should use store the value >>>>>> of the returned 'pushEndpoint' string as our device-token. At the end the >>>>>> device-token is really the thing that identifies a device w/in the target >>>>>> network. Apple/Google uses a unique string, and if Mozilla uses a URL, >>>>>> that's totally fine. >>>>>> >>>>>> Reading the protocol definitions (see [1]) for the 'endpoint' I think >>>>>> it is fair to use that (unique) URL string as the device-token; And we >>>>>> could use this token value as well for the unregister calls, instead of the >>>>>> channelIDs. >>>>>> >>>>> >>>>> After reading your comment on the PR >>>>> https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732I understand that you just want to use the deviceToken and not pass the >>>>> simplePushEndpoint to UPS anymore, is that right ? >>>>> >>>> >>>> >>>> yep >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> Any thoughts ? >>>>>> >>>>>> >>>>>> -Matthias >>>>>> >>>>>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> That said, we still have no clue how to proper clean-up 'out dated' >>>>>>> channels, since the SimplePush Server/Protocol is silent on that (unlike >>>>>>> APNs / GCM). but that's really a different thread (yep, we have a future >>>>>>> JIRA for that) >>>>>>> >>>>>>> >>>>>>> -M >>>>>>> >>>>>>> >>>>>>> >>>>>>>> wdyt ? >>>>>>>> >>>>>>>> Seb >>>>>>>> >>>>>>>> >>>>>>>> ps : our SPS Server implementation stays correct and returns what >>>>>>>> should be returned, it's really just the client part and how we expose the >>>>>>>> result >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at 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 >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at 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 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/fdc9240f/attachment-0001.html From matzew at apache.org Tue Apr 1 15:06:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Apr 2014 21:06:44 +0200 Subject: [aerogear-dev] Stuck in spConnect() In-Reply-To: References: Message-ID: Hello, Michi, I *think* you hit a spot, where we are currently having some issues (see [1]). Once we agreed on a solution there, it should not be to hard to get that fixed in both: 'master' and the 0.10.x branch of the UnifiedPush Server. [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html On Tue, Apr 1, 2014 at 8:50 PM, Michi Oshima wrote: > Hi, > > I'm trying to adapt the sample code under > aerogear-simplepush-unifiedpush-quickstartfor my application. I'm having a problem inside spConnect() > function > . > > When I first ran my code PushManager.register() call was successful, and > it returned a pushEndpoint. But I had mistyped the code somewhere below > and I never got to call UPClient.registerWithPushServer(...) > . > > Every subsequent run of the spConnect() function skips the line to call > UPClient.registerWithPushServer(...), because PushManager.register() call > doesn't return a pushEndpoint. (That's what you check in this line, > correct?) > > I'm guessing that I am somehow successfully registered with the simple > push server, but not with the unified push server. I'm very new to > AeroGear, so I'm not at all sure. > > > 1. How should I best recover from this? > 2. If I'm correct about what's going on, how should I rearrange the > code so that I can properly handle the situation where I'm registered with > the simple push server but not with the unified push server? > > Thank you, > > Michi Oshima > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/e35fc4fe/attachment.html From lholmqui at redhat.com Tue Apr 1 15:33:10 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 1 Apr 2014 15:33:10 -0400 Subject: [aerogear-dev] Stuck in spConnect() In-Reply-To: References: Message-ID: <19BE0A44-87E1-4A2C-875A-8E14D327F593@redhat.com> we store some things in local-storage, so you would need to delete that record. if you are using chrome, you can use the dev tools and go to the resources tab and delete the record that is aerogear-push(?), i think thats the name, i don't have it in front of me On Apr 1, 2014, at 2:50 PM, Michi Oshima wrote: > Hi, > > I'm trying to adapt the sample code under aerogear-simplepush-unifiedpush-quickstart for my application. I'm having a problem inside spConnect() function. > > When I first ran my code PushManager.register() call was successful, and it returned a pushEndpoint. But I had mistyped the code somewhere below and I never got to call UPClient.registerWithPushServer(...). > > Every subsequent run of the spConnect() function skips the line to call UPClient.registerWithPushServer(...), because PushManager.register() call doesn't return a pushEndpoint. (That's what you check in this line, correct?) > > I'm guessing that I am somehow successfully registered with the simple push server, but not with the unified push server. I'm very new to AeroGear, so I'm not at all sure. > > How should I best recover from this? > If I'm correct about what's going on, how should I rearrange the code so that I can properly handle the situation where I'm registered with the simple push server but not with the unified push server? > Thank you, > > Michi Oshima > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/8239044d/attachment.html From lholmqui at redhat.com Tue Apr 1 15:34:06 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 1 Apr 2014 15:34:06 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> Message-ID: i had something, now i forgot what it was, need to go back and check On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: > > On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: > still exploring > > :-) any recent thoughts on 'encodeURIComponent()' ? > > > On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: > >> >> >> >> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >> i might have a couple thoughts, but i need to try some things out first >> >> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >> >> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >> >>> >>> >>> >>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>> Ok, >>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>> >>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>> >>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>> >>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>> So how do we deal with that ? >>> >>> >>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: >>> >>> >>> >>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: >>> Hi, >>> While playing today with my Firefox Device and its native Simple Push support I noticed some differences between our implementation and the native Push regarding the success callback after a register : >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> //Native FFOS Push >>> broadcastRequest = navigator.push.register(); >>> broadcastRequest.onsuccess = function (event) { >>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>> } >>> >>> >>> //Aerogear Push Adapter >>> broadcastRequest = navigator.push.register(); >>> broadcastRequest.onsuccess = function (event) { >>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>> channelID = broadcastRequest.result.channelID; >>> version = broadcastRequest.result.version; >>> status = broadcastRequest.result.status >>> } >>> So, the AeroGear Push exposes much more in the callback that it should suppose to do : just exposing the pushEndpoint. >>> >>> The reason we do that I suppose, but Luke or Kris could confirm that, is that we thought respecting the SPS protocol, which indeed returns a whole object containing all the info. It is just that the Native Push Client API filter that out in the callback response. >>> >>> >>> Did they change that recently? Or was theirs always like it is now ? >>> >>> >>> After discussing that on the #push channel with the Mozilla people they confirmed me that we should only expoe the pushEndpoint. >>> >>> >>> yep, I agree on changing our JS polyfil >>> >>> >>> >>> If we keep it as is, this can be problematic when we want to use the same code both for native and with the adapter when, for instance, registering to the UPS : >>> >>> broadcastRequest = navigator.push.register(); >>> broadcastRequest.onsuccess = function (event) { >>> broadcastEndpoint = event.target.result; >>> var broadCastSettings = { >>> metadata: { >>> deviceToken: broadcastEndpoint.channelID, >>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>> } >>> } >>> UPClient.registerWithPushServer(broadCastSettings); >>> } >>> >>> >>> This won't work with the native push since "broadcastEndpoint.channelID" will be undefined. >>> >>> sweet :-) >>> >>> >>> So I propose that we change the behaviour, to return only the pushEndpoint in the callback, even if that means a bit of String manipulation when we want to perform the registration to the UPS : >>> >>> var broadCastSettings = { >>> metadata: { >>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>> simplePushEndpoint: broadcastEndpoint >>> } >>> } >>> >>> >>> well, that's not really good for security reasons, since their looooong 'substring' was done for that. Also that's just redundant. >>> >>> The I guess, the deviceToken (channelID registration) might be a bit bogus, for SimplePush. Let me think about it.... >>> >>> >>> Right now we use the channelID as the deviceToken, but we should not really 'leak' the channelID (see [1]), so I guess the here proposed change makes sense. Don't recall exactly why we did it in the past, but yeah - let's change it. >>> >>> >>> Thinking about the consequence: I think we should use store the value of the returned 'pushEndpoint' string as our device-token. At the end the device-token is really the thing that identifies a device w/in the target network. Apple/Google uses a unique string, and if Mozilla uses a URL, that's totally fine. >>> >>> Reading the protocol definitions (see [1]) for the 'endpoint' I think it is fair to use that (unique) URL string as the device-token; And we could use this token value as well for the unregister calls, instead of the channelIDs. >>> >>> After reading your comment on the PR https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732 I understand that you just want to use the deviceToken and not pass the simplePushEndpoint to UPS anymore, is that right ? >>> >>> >>> yep >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Any thoughts ? >>> >>> >>> -Matthias >>> >>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >>> >>> >>> >>> >>> That said, we still have no clue how to proper clean-up 'out dated' channels, since the SimplePush Server/Protocol is silent on that (unlike APNs / GCM). but that's really a different thread (yep, we have a future JIRA for that) >>> >>> >>> -M >>> >>> >>> wdyt ? >>> >>> Seb >>> >>> >>> ps : our SPS Server implementation stays correct and returns what should be returned, it's really just the client part and how we expose the result >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/1bf48f94/attachment-0001.html From michi.oshima at gmail.com Tue Apr 1 15:47:05 2014 From: michi.oshima at gmail.com (Michi Oshima) Date: Tue, 1 Apr 2014 15:47:05 -0400 Subject: [aerogear-dev] Stuck in spConnect() In-Reply-To: <19BE0A44-87E1-4A2C-875A-8E14D327F593@redhat.com> References: <19BE0A44-87E1-4A2C-875A-8E14D327F593@redhat.com> Message-ID: Thank you, Lucas. It worked. The key was 'ag-push-store'. I deleted it, and I'm good to go. Michi Oshima On Tue, Apr 1, 2014 at 3:33 PM, Lucas Holmquist wrote: > we store some things in local-storage, so you would need to delete that > record. > > if you are using chrome, you can use the dev tools and go to the resources > tab and delete the record that is aerogear-push(?), i think thats the > name, i don't have it in front of me > > > On Apr 1, 2014, at 2:50 PM, Michi Oshima wrote: > > Hi, > > I'm trying to adapt the sample code under > aerogear-simplepush-unifiedpush-quickstartfor my application. I'm having a problem inside spConnect() > function > . > > When I first ran my code PushManager.register() call was successful, and > it returned a pushEndpoint. But I had mistyped the code somewhere below > and I never got to call UPClient.registerWithPushServer(...) > . > > Every subsequent run of the spConnect() function skips the line to call > UPClient.registerWithPushServer(...), because PushManager.register() call > doesn't return a pushEndpoint. (That's what you check in this line, > correct?) > > I'm guessing that I am somehow successfully registered with the simple > push server, but not with the unified push server. I'm very new to > AeroGear, so I'm not at all sure. > > > 1. How should I best recover from this? > 2. If I'm correct about what's going on, how should I rearrange the > code so that I can properly handle the situation where I'm registered with > the simple push server but not with the unified push server? > > Thank you, > > Michi Oshima > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/4e4fef5b/attachment.html From scm.blanc at gmail.com Tue Apr 1 15:47:20 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 1 Apr 2014 21:47:20 +0200 Subject: [aerogear-dev] Stuck in spConnect() In-Reply-To: <19BE0A44-87E1-4A2C-875A-8E14D327F593@redhat.com> References: <19BE0A44-87E1-4A2C-875A-8E14D327F593@redhat.com> Message-ID: And in the mean time, while we find a proper way to fix that, you can remove the check you mention here = > in this line , this way it will always call the registration, the first time it will create a new installation in UPS but after that it will just do an update. Might not be the most efficient as you do a call each time you connect your app but it's not that big impact (And this way you are sure it updates the UPS in case you add a category, change the alias ...) On Tue, Apr 1, 2014 at 9:33 PM, Lucas Holmquist wrote: > we store some things in local-storage, so you would need to delete that > record. > > if you are using chrome, you can use the dev tools and go to the resources > tab and delete the record that is aerogear-push(?), i think thats the > name, i don't have it in front of me > > > On Apr 1, 2014, at 2:50 PM, Michi Oshima wrote: > > Hi, > > I'm trying to adapt the sample code under > aerogear-simplepush-unifiedpush-quickstartfor my application. I'm having a problem inside spConnect() > function > . > > When I first ran my code PushManager.register() call was successful, and > it returned a pushEndpoint. But I had mistyped the code somewhere below > and I never got to call UPClient.registerWithPushServer(...) > . > > Every subsequent run of the spConnect() function skips the line to call > UPClient.registerWithPushServer(...), because PushManager.register() call > doesn't return a pushEndpoint. (That's what you check in this line, > correct?) > > I'm guessing that I am somehow successfully registered with the simple > push server, but not with the unified push server. I'm very new to > AeroGear, so I'm not at all sure. > > > 1. How should I best recover from this? > 2. If I'm correct about what's going on, how should I rearrange the > code so that I can properly handle the situation where I'm registered with > the simple push server but not with the unified push server? > > Thank you, > > Michi Oshima > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/a9bb86de/attachment.html From michi.oshima at gmail.com Tue Apr 1 15:57:41 2014 From: michi.oshima at gmail.com (Michi Oshima) Date: Tue, 1 Apr 2014 15:57:41 -0400 Subject: [aerogear-dev] Stuck in spConnect() In-Reply-To: References: <19BE0A44-87E1-4A2C-875A-8E14D327F593@redhat.com> Message-ID: Hi Sebastian, It makes sense, but I do need the value of pushEndpoint in this another line. After the initial call to register(), pushEndpoint doesn't get returned any more by the subsequent register() calls. Hm. Is the endpoint object what's stored in the local store? That'd make sense, yes. - ag-push-store {"channels":[{"requestObject":{},"channelID":"68e000dd-c0d9-42f1-9527-06b1c149d7f6","state":"used"}],"uaid":"5c557248-ed2d-4af3-8e9e-2ea2889e9730"} On Tue, Apr 1, 2014 at 3:47 PM, Sebastien Blanc wrote: > And in the mean time, while we find a proper way to fix that, you can > remove the check you mention here = > in this line , > this way it will always call the registration, the first time it will > create a new installation in UPS but after that it will just do an update. > Might not be the most efficient as you do a call each time you connect your > app but it's not that big impact (And this way you are sure it updates the > UPS in case you add a category, change the alias ...) > > > On Tue, Apr 1, 2014 at 9:33 PM, Lucas Holmquist wrote: > >> we store some things in local-storage, so you would need to delete that >> record. >> >> if you are using chrome, you can use the dev tools and go to the >> resources tab and delete the record that is aerogear-push(?), i think >> thats the name, i don't have it in front of me >> >> >> On Apr 1, 2014, at 2:50 PM, Michi Oshima wrote: >> >> Hi, >> >> I'm trying to adapt the sample code under >> aerogear-simplepush-unifiedpush-quickstartfor my application. I'm having a problem inside spConnect() >> function >> . >> >> When I first ran my code PushManager.register() call was successful, and >> it returned a pushEndpoint. But I had mistyped the code somewhere below >> and I never got to call UPClient.registerWithPushServer(...) >> . >> >> Every subsequent run of the spConnect() function skips the line to call >> UPClient.registerWithPushServer(...), because PushManager.register() call >> doesn't return a pushEndpoint. (That's what you check in this line, >> correct?) >> >> I'm guessing that I am somehow successfully registered with the simple >> push server, but not with the unified push server. I'm very new to >> AeroGear, so I'm not at all sure. >> >> >> 1. How should I best recover from this? >> 2. If I'm correct about what's going on, how should I rearrange the >> code so that I can properly handle the situation where I'm registered with >> the simple push server but not with the unified push server? >> >> Thank you, >> >> Michi Oshima >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/b1739c1e/attachment.html From matzew at apache.org Tue Apr 1 16:00:41 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Apr 2014 22:00:41 +0200 Subject: [aerogear-dev] Stuck in spConnect() In-Reply-To: References: <19BE0A44-87E1-4A2C-875A-8E14D327F593@redhat.com> Message-ID: On Tue, Apr 1, 2014 at 9:57 PM, Michi Oshima wrote: > Hi Sebastian, > > It makes sense, but I do need the value of pushEndpoint in this another > line. > After the initial call to register(), pushEndpoint doesn't get returned > any more by the subsequent register() calls. > I *think* it was done for security reasons (pushEndpoint only on initial register, and not on re-registering). > > Hm. Is the endpoint object what's stored in the local store? That'd make > sense, yes. > > > - ag-push-store > {"channels":[{"requestObject":{},"channelID":"68e000dd-c0d9-42f1-9527-06b1c149d7f6","state":"used"}],"uaid":"5c557248-ed2d-4af3-8e9e-2ea2889e9730"} > > > > On Tue, Apr 1, 2014 at 3:47 PM, Sebastien Blanc wrote: > >> And in the mean time, while we find a proper way to fix that, you can >> remove the check you mention here = > in this line , >> this way it will always call the registration, the first time it will >> create a new installation in UPS but after that it will just do an update. >> Might not be the most efficient as you do a call each time you connect your >> app but it's not that big impact (And this way you are sure it updates the >> UPS in case you add a category, change the alias ...) >> >> >> On Tue, Apr 1, 2014 at 9:33 PM, Lucas Holmquist wrote: >> >>> we store some things in local-storage, so you would need to delete that >>> record. >>> >>> if you are using chrome, you can use the dev tools and go to the >>> resources tab and delete the record that is aerogear-push(?), i think >>> thats the name, i don't have it in front of me >>> >>> >>> On Apr 1, 2014, at 2:50 PM, Michi Oshima wrote: >>> >>> Hi, >>> >>> I'm trying to adapt the sample code under >>> aerogear-simplepush-unifiedpush-quickstartfor my application. I'm having a problem inside spConnect() >>> function >>> . >>> >>> When I first ran my code PushManager.register() call was successful, and >>> it returned a pushEndpoint. But I had mistyped the code somewhere below >>> and I never got to call UPClient.registerWithPushServer(...) >>> . >>> >>> Every subsequent run of the spConnect() function skips the line to call >>> UPClient.registerWithPushServer(...), because PushManager.register() call >>> doesn't return a pushEndpoint. (That's what you check in this line, >>> correct?) >>> >>> I'm guessing that I am somehow successfully registered with the simple >>> push server, but not with the unified push server. I'm very new to >>> AeroGear, so I'm not at all sure. >>> >>> >>> 1. How should I best recover from this? >>> 2. If I'm correct about what's going on, how should I rearrange the >>> code so that I can properly handle the situation where I'm registered with >>> the simple push server but not with the unified push server? >>> >>> Thank you, >>> >>> Michi Oshima >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/ce699578/attachment-0001.html From scm.blanc at gmail.com Tue Apr 1 16:04:22 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 1 Apr 2014 22:04:22 +0200 Subject: [aerogear-dev] Stuck in spConnect() In-Reply-To: References: <19BE0A44-87E1-4A2C-875A-8E14D327F593@redhat.com> Message-ID: Hum, That makes me think that we should maybe implement the push.registrations() function as Mozilla does : https://developer.mozilla.org/en-US/docs/Web/API/PushManager.registrations This is really helpful to iterate over existing registrations, not sure about the security implications but yeah they provide it ... On Tue, Apr 1, 2014 at 10:00 PM, Matthias Wessendorf wrote: > > > > On Tue, Apr 1, 2014 at 9:57 PM, Michi Oshima wrote: > >> Hi Sebastian, >> >> It makes sense, but I do need the value of pushEndpoint in this another >> line. >> After the initial call to register(), pushEndpoint doesn't get returned >> any more by the subsequent register() calls. >> > > I *think* it was done for security reasons (pushEndpoint only on initial > register, and not on re-registering). > > > >> >> Hm. Is the endpoint object what's stored in the local store? That'd >> make sense, yes. >> >> >> - ag-push-store >> {"channels":[{"requestObject":{},"channelID":"68e000dd-c0d9-42f1-9527-06b1c149d7f6","state":"used"}],"uaid":"5c557248-ed2d-4af3-8e9e-2ea2889e9730"} >> >> >> >> On Tue, Apr 1, 2014 at 3:47 PM, Sebastien Blanc wrote: >> >>> And in the mean time, while we find a proper way to fix that, you can >>> remove the check you mention here = > in this line , >>> this way it will always call the registration, the first time it will >>> create a new installation in UPS but after that it will just do an update. >>> Might not be the most efficient as you do a call each time you connect your >>> app but it's not that big impact (And this way you are sure it updates the >>> UPS in case you add a category, change the alias ...) >>> >>> >>> On Tue, Apr 1, 2014 at 9:33 PM, Lucas Holmquist wrote: >>> >>>> we store some things in local-storage, so you would need to delete >>>> that record. >>>> >>>> if you are using chrome, you can use the dev tools and go to the >>>> resources tab and delete the record that is aerogear-push(?), i think >>>> thats the name, i don't have it in front of me >>>> >>>> >>>> On Apr 1, 2014, at 2:50 PM, Michi Oshima >>>> wrote: >>>> >>>> Hi, >>>> >>>> I'm trying to adapt the sample code under >>>> aerogear-simplepush-unifiedpush-quickstartfor my application. I'm having a problem inside spConnect() >>>> function >>>> . >>>> >>>> When I first ran my code PushManager.register() call was successful, >>>> and it returned a pushEndpoint. But I had mistyped the code somewhere >>>> below and I never got to call UPClient.registerWithPushServer(...) >>>> . >>>> >>>> Every subsequent run of the spConnect() function skips the line to call >>>> UPClient.registerWithPushServer(...), because PushManager.register() call >>>> doesn't return a pushEndpoint. (That's what you check in this line, >>>> correct?) >>>> >>>> I'm guessing that I am somehow successfully registered with the simple >>>> push server, but not with the unified push server. I'm very new to >>>> AeroGear, so I'm not at all sure. >>>> >>>> >>>> 1. How should I best recover from this? >>>> 2. If I'm correct about what's going on, how should I rearrange the >>>> code so that I can properly handle the situation where I'm registered with >>>> the simple push server but not with the unified push server? >>>> >>>> Thank you, >>>> >>>> Michi Oshima >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/173c68bb/attachment.html From matzew at apache.org Tue Apr 1 16:08:47 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Apr 2014 22:08:47 +0200 Subject: [aerogear-dev] Stuck in spConnect() In-Reply-To: References: <19BE0A44-87E1-4A2C-875A-8E14D327F593@redhat.com> Message-ID: On Tue, Apr 1, 2014 at 10:04 PM, Sebastien Blanc wrote: > Hum, > That makes me think that we should maybe implement the > push.registrations() function as Mozilla does : > > https://developer.mozilla.org/en-US/docs/Web/API/PushManager.registrations > yes, see older thread, where Luke and I just chatted :) > > > This is really helpful to iterate over existing registrations, not sure > about the security implications but yeah they provide it ... > > > On Tue, Apr 1, 2014 at 10:00 PM, Matthias Wessendorf wrote: > >> >> >> >> On Tue, Apr 1, 2014 at 9:57 PM, Michi Oshima wrote: >> >>> Hi Sebastian, >>> >>> It makes sense, but I do need the value of pushEndpoint in this another >>> line. >>> After the initial call to register(), pushEndpoint doesn't get returned >>> any more by the subsequent register() calls. >>> >> >> I *think* it was done for security reasons (pushEndpoint only on initial >> register, and not on re-registering). >> >> >> >>> >>> Hm. Is the endpoint object what's stored in the local store? That'd >>> make sense, yes. >>> >>> >>> - ag-push-store >>> {"channels":[{"requestObject":{},"channelID":"68e000dd-c0d9-42f1-9527-06b1c149d7f6","state":"used"}],"uaid":"5c557248-ed2d-4af3-8e9e-2ea2889e9730"} >>> >>> >>> >>> On Tue, Apr 1, 2014 at 3:47 PM, Sebastien Blanc wrote: >>> >>>> And in the mean time, while we find a proper way to fix that, you can >>>> remove the check you mention here = > in this line , >>>> this way it will always call the registration, the first time it will >>>> create a new installation in UPS but after that it will just do an update. >>>> Might not be the most efficient as you do a call each time you connect your >>>> app but it's not that big impact (And this way you are sure it updates the >>>> UPS in case you add a category, change the alias ...) >>>> >>>> >>>> On Tue, Apr 1, 2014 at 9:33 PM, Lucas Holmquist wrote: >>>> >>>>> we store some things in local-storage, so you would need to delete >>>>> that record. >>>>> >>>>> if you are using chrome, you can use the dev tools and go to the >>>>> resources tab and delete the record that is aerogear-push(?), i think >>>>> thats the name, i don't have it in front of me >>>>> >>>>> >>>>> On Apr 1, 2014, at 2:50 PM, Michi Oshima >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm trying to adapt the sample code under >>>>> aerogear-simplepush-unifiedpush-quickstartfor my application. I'm having a problem inside spConnect() >>>>> function >>>>> . >>>>> >>>>> When I first ran my code PushManager.register() call was successful, >>>>> and it returned a pushEndpoint. But I had mistyped the code somewhere >>>>> below and I never got to call UPClient.registerWithPushServer(...) >>>>> . >>>>> >>>>> Every subsequent run of the spConnect() function skips the line to >>>>> call UPClient.registerWithPushServer(...), because PushManager.register() >>>>> call doesn't return a pushEndpoint. (That's what you check in this >>>>> line, >>>>> correct?) >>>>> >>>>> I'm guessing that I am somehow successfully registered with the simple >>>>> push server, but not with the unified push server. I'm very new to >>>>> AeroGear, so I'm not at all sure. >>>>> >>>>> >>>>> 1. How should I best recover from this? >>>>> 2. If I'm correct about what's going on, how should I rearrange >>>>> the code so that I can properly handle the situation where I'm registered >>>>> with the simple push server but not with the unified push server? >>>>> >>>>> Thank you, >>>>> >>>>> Michi Oshima >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/70c5bfc9/attachment-0001.html From john at goabits.com Tue Apr 1 16:37:51 2014 From: john at goabits.com (johnbran) Date: Tue, 1 Apr 2014 13:37:51 -0700 (PDT) Subject: [aerogear-dev] Aero push iOS 64bit? Message-ID: <1396384671802-7258.post@n5.nabble.com> Hello, I am running xcode 5.1 and cordova 3.4. When I test my app on an iPhone 4 it works without issue. When I run it on an 5s (64bits) or in the 64bit iphone simulator I get the following errors... ld: warning: ignoring file /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a, missing required architecture x86_64 in file /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a (3 slices) Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_AGDeviceRegistration", referenced from: objc-class-ref in PushPlugin.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) If I choose to compile only to 32bits using $(ARCHS_STANDARD_32_BIT) in the Architecture build settings, Cordova throws errors. Does Aero push for iOS support 64bits? I got it working nicely in Android and would like to use the same system for iOS. Thanks -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aero-push-iOS-64bit-tp7258.html Sent from the aerogear-dev mailing list archive at Nabble.com. From marc at slintes.net Tue Apr 1 16:54:54 2014 From: marc at slintes.net (Marc Sluiter) Date: Tue, 01 Apr 2014 22:54:54 +0200 Subject: [aerogear-dev] Android Studio / Gradle support In-Reply-To: References: Message-ID: <533B279E.2070105@slintes.net> Hi all, some time ago there was already a discussion about using Android Studio / Gradle [1], but as far as I can see nothing happened afterwards. So I was curious if I can get the cookbook application running with Android's new build system, and want to share what I found out so far: My first approach was to migrate the cookbook first, and using the library as dependency only. But that didn't work out, because the Androd dependencies in the pom.xml of the lib could not be found. I really didn't want to install them with the maven-android-sdk-deployer, because that's not needed anymore with the new build system, it accesses directly the installed Android SDK. So I migrated the lib first. The first issue was: how do I get the aar into my local maven repository? Solution: the Gradle Android Maven plugin [2]. After some configuration I could install the lib into my local maven repo with "gradlew clean install". Nice. Then I looked how I can run the Robolectric tests in the lib. That seems to be a problem, because the Android Gradle plugin team seems to be focused on running tests in AVDs or on real devices only [3]. Then I found another Gradle plugin to the rescue... at least I thought: the Robolectric team itself maintains the Gradle Android Unit Testing plugin [4], which should run JUnit and Robolectric tests, but unfortunatly it was broken by the latest Android Gradle plugin update... [5]. So I prepared running the tests, but had to comment out the plugin for the moment. So back to the cookbook: here I had to use a workaround now for accessing my local maven repo, because the official and easy way is broken in Gradle itself atm [6]. But with the workaround I could run the cookbook app on my device with "gradle clean installDebug"... finally :) (And with the OpenShift Push Server it was easy to test the push functionality, great!) So my resume of this adventure: before that I liked Android Studio very much, I used it for some little private fun apps already, and had only few problems. It has features (e.g. product flavors) which were more difficult to handle with maven. But I tested only by deploying and using the apps on my own devices (shame on me, I know...), so missing JUnit/Robolectric support was not an issue for me. And my library project was part of the app's project (works nice with Gradle!), so no local maven issues. But now I think that there is still some work to do with Android Studio and the Android Gradle plugin. Some gaps can be filled with 3rd party plugins, but the chance that they get broken by new versions of the build system is not low, development is very fast. One point I forgot: I did not have a look into the Travis stuff, because I don't know it yet. If you are interested in my results, see here: https://github.com/slintes/aerogear-android/tree/gradle https://github.com/slintes/aerogear-android-cookbook/tree/gradle Kind regards, Marc [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Google-s-Gradle-build-tool-and-AAR-td4508.html [2] https://github.com/dcendents/android-maven-plugin [3] http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Testing [4] https://github.com/robolectric/gradle-android-test-plugin [5] https://github.com/robolectric/gradle-android-test-plugin/issues/8 [6] https://code.google.com/p/android/issues/detail?id=63908 From marc at slintes.net Tue Apr 1 17:00:55 2014 From: marc at slintes.net (Marc Sluiter) Date: Tue, 01 Apr 2014 23:00:55 +0200 Subject: [aerogear-dev] Android Studio / Gradle support Message-ID: <533B2907.8070303@slintes.net> (next try, sorry again) Hi all, some time ago there was already a discussion about using Android Studio / Gradle [1], but as far as I can see nothing happened afterwards. So I was curious if I can get the cookbook application running with Android's new build system, and want to share what I found out so far: My first approach was to migrate the cookbook first, and using the library as dependency only. But that didn't work out, because the Androd dependencies in the pom.xml of the lib could not be found. I really didn't want to install them with the maven-android-sdk-deployer, because that's not needed anymore with the new build system, it accesses directly the installed Android SDK. So I migrated the lib first. The first issue was: how do I get the aar into my local maven repository? Solution: the Gradle Android Maven plugin [2]. After some configuration I could install the lib into my local maven repo with "gradlew clean install". Nice. Then I looked how I can run the Robolectric tests in the lib. That seems to be a problem, because the Android Gradle plugin team seems to be focused on running tests in AVDs or on real devices only [3]. Then I found another Gradle plugin to the rescue... at least I thought: the Robolectric team itself maintains the Gradle Android Unit Testing plugin [4], which should run JUnit and Robolectric tests, but unfortunatly it was broken by the latest Android Gradle plugin update... [5]. So I prepared running the tests, but had to comment out the plugin for the moment. So back to the cookbook: here I had to use a workaround now for accessing my local maven repo, because the official and easy way is broken in Gradle itself atm [6]. But with the workaround I could run the cookbook app on my device with "gradle clean installDebug"... finally (And with the OpenShift Push Server it was easy to test the push functionality, great!) So my resume of this adventure: before that I liked Android Studio very much, I used it for some little private fun apps already, and had only few problems. It has features (e.g. product flavors) which were more difficult to handle with maven. But I tested only by deploying and using the apps on my own devices (shame on me, I know...), so missing JUnit/Robolectric support was not an issue for me. And my library project was part of the app's project (works nice with Gradle!), so no local maven issues. But now I think that there is still some work to do with Android Studio and the Android Gradle plugin. Some gaps can be filled with 3rd party plugins, but the chance that they get broken by new versions of the build system is not low, development is very fast. One point I forgot: I did not have a look into the Travis stuff, because I don't know it yet. If you are interested in my results, see here: https://github.com/slintes/aerogear-android/tree/gradle https://github.com/slintes/aerogear-android-cookbook/tree/gradle Kind regards, Marc [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Google-s-Gradle-build-tool-and-AAR-td4508.html [2] https://github.com/dcendents/android-maven-plugin [3] http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Testing [4] https://github.com/robolectric/gradle-android-test-plugin [5] https://github.com/robolectric/gradle-android-test-plugin/issues/8 [6] https://code.google.com/p/android/issues/detail?id=63908 _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From lukas.fryc at gmail.com Tue Apr 1 17:05:23 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Tue, 1 Apr 2014 23:05:23 +0200 Subject: [aerogear-dev] AeroGear.js without jQuery Discussion In-Reply-To: References: <6D6F35A3-BF5F-431E-A916-C5FB7966189E@redhat.com> <97A36F35-7C1C-4078-9594-ABD2A82A1D38@redhat.com> <20140325122659.38fb4055@kapy-ntb-x220> Message-ID: I'm all for using promises that actually make sense, but have you considered consistency? Are you suggesting some modules will return jQuery.Deferred while others will use ES6 promises? I would vote for all or nothing. ;-) What about allow a developer to override what promise will be returned? We can pass all promises through singleton (that can be overwritten/plugged-in by the developer), and that will decide what promise to return. In 1.x it can return jQuery.Deferred by default (but can be rewritten to Promise). In 2.x it can return Promise (as in ES6) by default (but can be rewritten to jQuery.Deferred). On Tue, Apr 1, 2014 at 3:36 PM, Sebastien Blanc wrote: > > > > On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist wrote: > >> in the canary branch i started looking at removing jQuery from the >> UnifiedPush client code, since it only uses jQuery.Ajax. >> >> https://github.com/aerogear/aerogear-js/tree/canary >> > > That's really cool and I will probably use this in my experimental > FirefoxOS support for the Cordova Push Plugin > >> >> i was thinking this would be a 2.0 thing, but for this particular >> module/adapter/whatevs, i think we can update it before that since we >> marked it "experimental" >> >> in datamanager we have the IndexedDB and WebSQL adapters marked as >> experimental, so we could do those, but since the other 2 adapters are >> not, we should probably wait. >> >> Just want to see what the team thought about that, before i started to go >> cray-cray >> >> >> -Luke >> >> >> On Mar 25, 2014, at 8:58 AM, Lucas Holmquist wrote: >> >> >> On Mar 25, 2014, at 8:15 AM, Luk?? Fry? wrote: >> >> Side note: getting integration with jQuery{ajax,promises} right was one >> of the pain points when integrating with AeroGear.js / Angular (uses q.js, >> and custom http service). >> >> i know they include their "own" version of jQuery >> >> We must be sure whatever we choose is compatible with frameworks out >> there (at least it should not hard-nut to make it work). In terms of >> promises implementation. In the end people may even end up using 2-3 >> promise approaches in one project that makes code pretty disgusting. >> >> So: >> >> +1 getting rid of jQuery.ajax >> +1 getting rid of jQuery promises (they are just wrong anyway ;-) >> >> >> Btw in terms of polyfilling, I would suggest: >> >> 1) use whatever standard *is* as long as supported by majority of >> mainstream browsers >> >> 2) use whatever standard *will be *and compile polyfill into aerogear.js >> (as long as it's not too bloated; not necessary for bower users) >> >> >> the polyfill i was thinking about is here >> https://github.com/jakearchibald/es6-promise >> >> it is just the spec and 2kb gzipped, which is nice >> >> and i think this could be an external( compiled in ) dep of the library >> >> >> Wdyt? >> >> >> >> On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko wrote: >> >>> Given number of supported browsers is quite low - >>> http://caniuse.com/promises, I >>> believe that polyfill will be needed even with version 2.0. >>> >>> On Mon, 24 Mar 2014 12:01:38 -0400 >>> Lucas Holmquist wrote: >>> >>> > >>> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc >>> wrote: >>> > >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf < >>> matzew at apache.org> >>> > > wrote: >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc < >>> scm.blanc at gmail.com> >>> > > wrote: >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist < >>> lholmqui at redhat.com> >>> > > wrote: >>> > > >>> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis < >>> tolisemm at gmail.com> >>> > > wrote: >>> > > >>> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf : >>> > >> >>> > >> >>> > >> >>> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist < >>> lholmqui at redhat.com> >>> > >> wrote: >>> > >>> I agree that it would be nice to implement AGJS-70 (Investigate >>> removing >>> > >>> jQuery requirement). Meanwhile, there is an open source project on >>> GitHub >>> > >>> that claims to offer a custom builder for jQuery in order to >>> include only >>> > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we >>> could >>> > >>> create a custom jQuery build which includes only the parts >>> currently >>> > >>> needed in AeroGear. This would mean a smaller size of the jQuery >>> > >>> dependency. >>> > >> >>> > >> The AG lib depends on a few parts of jQuery, the biggest being >>> jQuery.Ajax >>> > >> and the promise implementation. >>> > >> >>> > >> i know we can make custom builds of jQuery pretty easily( building >>> from >>> > >> source ), but i don't really want to bundle it within our lib. >>> > >> >>> > >> and i don't think with bower we can do this easily. although they >>> did just >>> > >> add a post install hook, so perhaps that could be something to look >>> at. >>> > >> >>> > >> Datamanager only uses the promise implementation of jQuery( and some >>> > >> random thing for the filter method, which could probably be >>> updated ). >>> > >> >>> > >> >>> > >> Promises are starting to become available natively in browsers and >>> jQuery >>> > >> doesn't use the Promise/A+ spec, so it could be harder to fallback >>> > >> without a shim of some kind >>> > >> >>> > >> Good to know. Thanks for providing this info. >>> > >> >>> > >> >>> > >> sounds reasonable to 'wait' on the promise side of things, and use >>> that >>> > >> bit in the datamanager >>> > >> >>> > >> +1 >>> > > >>> > > there are other promise implementations that we could use, that are >>> to >>> > > spec, such as Q and RSVP, here is the link to the HTML5 rocks >>> article >>> > > http://www.html5rocks.com/en/tutorials/es6/promises/ >>> > > >>> > > These last days I have been playing with the library When provided >>> by Cujo, >>> > > it's maybe also worth looking https://github.com/cujojs/when >>> > > >>> > > not sure I see value in using a different library as a temporary >>> thing. >>> > > Once the API is part of the browser platform, the need for [yet >>> another js >>> > > lib] goes away. I know but I'm more concerned about "Once the API >>> is part >>> > > of the browser platform" When will that happen and does it match >>> with our >>> > > roadmap ? Was also to offer a polyfill for older browser if we want >>> to keep >>> > > supporting them. >>> > > >>> > i will have to update the roadmap. >>> > >>> > 2.0 would be a nice time to "fully" switch, but we can start >>> experimenting >>> > now and maybe for 1.5 can have some implemenation for data manager >>> only. >>> > >>> > Current Chrome has Promise's enable by default and it looks like >>> FireFox >>> > 29( next version ) will too. Safari and IE are in dev i believe >>> > >>> > for fallback we can still make use of jQuery i think because of this >>> method >>> > here "Promise.cast", although the closest lib to the spec is RSVP( >>> maybe >>> > this could be the 2.0 fallback if we remove jQuery from the whole lib ) >>> > >>> > >>> > >>> > > >>> > > >>> > > >>> > > >>> > >> >>> > >> >>> > >> >>> > >> while i don't really want to reinvent the wheel in terms of Ajax, >>> it >>> > >> might be interesting to take a look. >>> > >> >>> > >> Yeah, IMO worth to look there, for reducing dependencies >>> > >> >>> > >> -M >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> I think in a previous ML thread about what 2.0 looked like, that >>> > >> Pipeline would maybe just be a JSON only thing, with exception for >>> > >> multipart >>> > >> >>> > >> >>> > >> >>> > >> @Lucas Thanks for making things clear >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at 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 >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at 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 >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/833f38a4/attachment-0001.html From marc at slintes.net Tue Apr 1 17:08:15 2014 From: marc at slintes.net (Marc Sluiter) Date: Tue, 01 Apr 2014 23:08:15 +0200 Subject: [aerogear-dev] Android Studio / Gradle support In-Reply-To: <533B279E.2070105@slintes.net> References: <533B279E.2070105@slintes.net> Message-ID: <533B2ABF.6010309@slintes.net> oh sh*t, sorry for disturbing this thread, I reposted my mail... Marc Sluiter schrieb am 01.04.2014 22:54: > Hi all, > > some time ago there was already a discussion about using Android Studio / Gradle > [1], but as far as I can see nothing happened afterwards. > > So I was curious if I can get the cookbook application running with Android's > new build system, and want to share what I found out so far: > > My first approach was to migrate the cookbook first, and using the library as > dependency only. But that didn't work out, because the Androd dependencies in > the pom.xml of the lib could not be found. I really didn't want to install them > with the maven-android-sdk-deployer, because that's not needed anymore with the > new build system, it accesses directly the installed Android SDK. > > So I migrated the lib first. The first issue was: how do I get the aar into my > local maven repository? Solution: the Gradle Android Maven plugin [2]. After > some configuration I could install the lib into my local maven repo with > "gradlew clean install". Nice. > > Then I looked how I can run the Robolectric tests in the lib. That seems to be a > problem, because the Android Gradle plugin team seems to be focused on running > tests in AVDs or on real devices only [3]. Then I found another Gradle plugin to > the rescue... at least I thought: the Robolectric team itself maintains the > Gradle Android Unit Testing plugin [4], which should run JUnit and Robolectric > tests, but unfortunatly it was broken by the latest Android Gradle plugin > update... [5]. So I prepared running the tests, but had to comment out the > plugin for the moment. > > So back to the cookbook: here I had to use a workaround now for accessing my > local maven repo, because the official and easy way is broken in Gradle itself > atm [6]. But with the workaround I could run the cookbook app on my device with > "gradle clean installDebug"... finally :) (And with the OpenShift Push Server it > was easy to test the push functionality, great!) > > So my resume of this adventure: > before that I liked Android Studio very much, I used it for some little private > fun apps already, and had only few problems. It has features (e.g. product > flavors) which were more difficult to handle with maven. But I tested only by > deploying and using the apps on my own devices (shame on me, I know...), so > missing JUnit/Robolectric support was not an issue for me. And my library > project was part of the app's project (works nice with Gradle!), so no local > maven issues. > But now I think that there is still some work to do with Android Studio and the > Android Gradle plugin. Some gaps can be filled with 3rd party plugins, but the > chance that they get broken by new versions of the build system is not low, > development is very fast. > > One point I forgot: I did not have a look into the Travis stuff, because I don't > know it yet. > > If you are interested in my results, see here: > > https://github.com/slintes/aerogear-android/tree/gradle > https://github.com/slintes/aerogear-android-cookbook/tree/gradle > > Kind regards, > > Marc > > > [1] > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Google-s-Gradle-build-tool-and-AAR-td4508.html > [2] https://github.com/dcendents/android-maven-plugin > [3] http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Testing > [4] https://github.com/robolectric/gradle-android-test-plugin > [5] https://github.com/robolectric/gradle-android-test-plugin/issues/8 > [6] https://code.google.com/p/android/issues/detail?id=63908 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From lholmqui at redhat.com Tue Apr 1 20:08:48 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 1 Apr 2014 20:08:48 -0400 Subject: [aerogear-dev] AeroGear.js without jQuery Discussion In-Reply-To: References: <6D6F35A3-BF5F-431E-A916-C5FB7966189E@redhat.com> <97A36F35-7C1C-4078-9594-ABD2A82A1D38@redhat.com> <20140325122659.38fb4055@kapy-ntb-x220> Message-ID: <46FDD9DA-7305-444D-A1B2-4D0D2F4A9938@redhat.com> On Apr 1, 2014, at 5:05 PM, Luk?? Fry? wrote: > I'm all for using promises that actually make sense, > but have you considered consistency? > > Are you suggesting some modules will return jQuery.Deferred while others will use ES6 promises? i re read what i wrote and i think i wrote it very confusingly(?), not sure that is a word, but i'm going with it I would like to start with the UnifiedPushClient and remove the jQuery dependency from that. It would then return an ES6 promise instead, or you can still use callbacks. i think this might be ok for a next release, 1.5.0, since the api is labeled experimental. For datamanager, 2 out of the 4 adapters are labeled experimental, so we would not change the promises return type until 2.0 what i previously wrote sounded like i wanted to change 2 data manager adapters while keeping the other 2 the same. > > I would vote for all or nothing. ;-) > > > What about allow a developer to override what promise will be returned? > We can pass all promises through singleton (that can be overwritten/plugged-in by the developer), > and that will decide what promise to return. This could be interesting, but i would like to keep things simple first > > In 1.x it can return jQuery.Deferred by default (but can be rewritten to Promise). > In 2.x it can return Promise (as in ES6) by default (but can be rewritten to jQuery.Deferred). > > > > > On Tue, Apr 1, 2014 at 3:36 PM, Sebastien Blanc wrote: > > > > On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist wrote: > in the canary branch i started looking at removing jQuery from the UnifiedPush client code, since it only uses jQuery.Ajax. > > https://github.com/aerogear/aerogear-js/tree/canary > > That's really cool and I will probably use this in my experimental FirefoxOS support for the Cordova Push Plugin > > i was thinking this would be a 2.0 thing, but for this particular module/adapter/whatevs, i think we can update it before that since we marked it "experimental" > > in datamanager we have the IndexedDB and WebSQL adapters marked as experimental, so we could do those, but since the other 2 adapters are not, we should probably wait. > > Just want to see what the team thought about that, before i started to go cray-cray > > > -Luke > > > On Mar 25, 2014, at 8:58 AM, Lucas Holmquist wrote: > >> >> On Mar 25, 2014, at 8:15 AM, Luk?? Fry? wrote: >> >>> Side note: getting integration with jQuery{ajax,promises} right was one of the pain points when integrating with AeroGear.js / Angular (uses q.js, and custom http service). >>> >> i know they include their "own" version of jQuery >> >>> We must be sure whatever we choose is compatible with frameworks out there (at least it should not hard-nut to make it work). In terms of promises implementation. In the end people may even end up using 2-3 promise approaches in one project that makes code pretty disgusting. >>> >>> So: >>> >>> +1 getting rid of jQuery.ajax >>> +1 getting rid of jQuery promises (they are just wrong anyway ;-) >>> >>> >>> Btw in terms of polyfilling, I would suggest: >>> >>> 1) use whatever standard is as long as supported by majority of mainstream browsers >>> >>> 2) use whatever standard will be and compile polyfill into aerogear.js (as long as it's not too bloated; not necessary for bower users) >>> >> the polyfill i was thinking about is here https://github.com/jakearchibald/es6-promise >> >> it is just the spec and 2kb gzipped, which is nice >> >> and i think this could be an external( compiled in ) dep of the library >> >> >>> Wdyt? >>> >>> >>> >>> On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko wrote: >>> Given number of supported browsers is quite low - http://caniuse.com/promises, I >>> believe that polyfill will be needed even with version 2.0. >>> >>> On Mon, 24 Mar 2014 12:01:38 -0400 >>> Lucas Holmquist wrote: >>> >>> > >>> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc wrote: >>> > >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf >>> > > wrote: >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc >>> > > wrote: >>> > > >>> > > >>> > > >>> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist >>> > > wrote: >>> > > >>> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis >>> > > wrote: >>> > > >>> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf : >>> > >> >>> > >> >>> > >> >>> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist >>> > >> wrote: >>> > >>> I agree that it would be nice to implement AGJS-70 (Investigate removing >>> > >>> jQuery requirement). Meanwhile, there is an open source project on GitHub >>> > >>> that claims to offer a custom builder for jQuery in order to include only >>> > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we could >>> > >>> create a custom jQuery build which includes only the parts currently >>> > >>> needed in AeroGear. This would mean a smaller size of the jQuery >>> > >>> dependency. >>> > >> >>> > >> The AG lib depends on a few parts of jQuery, the biggest being jQuery.Ajax >>> > >> and the promise implementation. >>> > >> >>> > >> i know we can make custom builds of jQuery pretty easily( building from >>> > >> source ), but i don't really want to bundle it within our lib. >>> > >> >>> > >> and i don't think with bower we can do this easily. although they did just >>> > >> add a post install hook, so perhaps that could be something to look at. >>> > >> >>> > >> Datamanager only uses the promise implementation of jQuery( and some >>> > >> random thing for the filter method, which could probably be updated ). >>> > >> >>> > >> >>> > >> Promises are starting to become available natively in browsers and jQuery >>> > >> doesn't use the Promise/A+ spec, so it could be harder to fallback >>> > >> without a shim of some kind >>> > >> >>> > >> Good to know. Thanks for providing this info. >>> > >> >>> > >> >>> > >> sounds reasonable to 'wait' on the promise side of things, and use that >>> > >> bit in the datamanager >>> > >> >>> > >> +1 >>> > > >>> > > there are other promise implementations that we could use, that are to >>> > > spec, such as Q and RSVP, here is the link to the HTML5 rocks article >>> > > http://www.html5rocks.com/en/tutorials/es6/promises/ >>> > > >>> > > These last days I have been playing with the library When provided by Cujo, >>> > > it's maybe also worth looking https://github.com/cujojs/when >>> > > >>> > > not sure I see value in using a different library as a temporary thing. >>> > > Once the API is part of the browser platform, the need for [yet another js >>> > > lib] goes away. I know but I'm more concerned about "Once the API is part >>> > > of the browser platform" When will that happen and does it match with our >>> > > roadmap ? Was also to offer a polyfill for older browser if we want to keep >>> > > supporting them. >>> > > >>> > i will have to update the roadmap. >>> > >>> > 2.0 would be a nice time to "fully" switch, but we can start experimenting >>> > now and maybe for 1.5 can have some implemenation for data manager only. >>> > >>> > Current Chrome has Promise's enable by default and it looks like FireFox >>> > 29( next version ) will too. Safari and IE are in dev i believe >>> > >>> > for fallback we can still make use of jQuery i think because of this method >>> > here "Promise.cast", although the closest lib to the spec is RSVP( maybe >>> > this could be the 2.0 fallback if we remove jQuery from the whole lib ) >>> > >>> > >>> > >>> > > >>> > > >>> > > >>> > > >>> > >> >>> > >> >>> > >> >>> > >> while i don't really want to reinvent the wheel in terms of Ajax, it >>> > >> might be interesting to take a look. >>> > >> >>> > >> Yeah, IMO worth to look there, for reducing dependencies >>> > >> >>> > >> -M >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> I think in a previous ML thread about what 2.0 looked like, that >>> > >> Pipeline would maybe just be a JSON only thing, with exception for >>> > >> multipart >>> > >> >>> > >> >>> > >> >>> > >> @Lucas Thanks for making things clear >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at 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 >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at 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 >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140401/a9a98f46/attachment-0001.html From scm.blanc at gmail.com Wed Apr 2 03:40:47 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 2 Apr 2014 09:40:47 +0200 Subject: [aerogear-dev] Creating a Cordova Project in Jira Message-ID: Hi, For all the projects we have a specific Project : AGPUSH, AGJS, AGSEC etc ... I think it would be nice to have also one for Cordova and I propose : AGCORDOVA wdyt ? JIRA : https://issues.jboss.org/browse/AEROGEAR-1464 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/1d33e44a/attachment.html From corinnekrych at gmail.com Wed Apr 2 03:45:12 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 2 Apr 2014 09:45:12 +0200 Subject: [aerogear-dev] Creating a Cordova Project in Jira In-Reply-To: References: Message-ID: <46B79FBB-832A-4193-8E38-C9BBF1ABD2BE@gmail.com> +1000 cordova has its own specific issue too ++ Corinne On 02 Apr 2014, at 09:40, Sebastien Blanc wrote: > Hi, > > For all the projects we have a specific Project : AGPUSH, AGJS, AGSEC etc ... > I think it would be nice to have also one for Cordova and I propose : AGCORDOVA > > > wdyt ? > > JIRA : https://issues.jboss.org/browse/AEROGEAR-1464 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From edewit at redhat.com Wed Apr 2 03:54:30 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 2 Apr 2014 09:54:30 +0200 Subject: [aerogear-dev] Aero push iOS 64bit? In-Reply-To: <1396384671802-7258.post@n5.nabble.com> References: <1396384671802-7258.post@n5.nabble.com> Message-ID: <8AF21682-C2A0-4A05-A67E-0E4A62F3D864@redhat.com> Hi, Thanks for trying our project, currently Cordova doesn?t support 64 bit builds (see the very long discussion about it). When that is fixed we?ll need to update our push library to also support 64 bit (I?ve create an issue). Cordova already fixed their issue we just need to wait for a release and then you are good to go. Hope you can wait for that to happen, Cheers, Erik Jan On 1 Apr,2014, at 22:37 , johnbran wrote: > Hello, > I am running xcode 5.1 and cordova 3.4. When I test my app on an iPhone 4 > it works without issue. When I run it on an 5s (64bits) or in the 64bit > iphone simulator I get the following errors... > > ld: warning: ignoring file > /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a, > missing required architecture x86_64 in file > /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a > (3 slices) > Undefined symbols for architecture x86_64: > "_OBJC_CLASS_$_AGDeviceRegistration", referenced from: > objc-class-ref in PushPlugin.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > If I choose to compile only to 32bits using $(ARCHS_STANDARD_32_BIT) in the > Architecture build settings, Cordova throws errors. > > Does Aero push for iOS support 64bits? I got it working nicely in Android > and would like to use the same system for iOS. > > Thanks > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aero-push-iOS-64bit-tp7258.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/ba9420ea/attachment.html From tolisemm at gmail.com Wed Apr 2 04:08:46 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Wed, 2 Apr 2014 11:08:46 +0300 Subject: [aerogear-dev] Creating a Cordova Project in Jira In-Reply-To: <46B79FBB-832A-4193-8E38-C9BBF1ABD2BE@gmail.com> References: <46B79FBB-832A-4193-8E38-C9BBF1ABD2BE@gmail.com> Message-ID: +1 I had the same idea in the past. it seems there is a cordova component under AEROGEAR http://lists.jboss.org/pipermail/aerogear-dev/2013-October/005164.html 2014-04-02 10:45 GMT+03:00 Corinne Krych : > +1000 > cordova has its own specific issue too > ++ > Corinne > On 02 Apr 2014, at 09:40, Sebastien Blanc wrote: > > > Hi, > > > > For all the projects we have a specific Project : AGPUSH, AGJS, AGSEC > etc ... > > I think it would be nice to have also one for Cordova and I propose : > AGCORDOVA > > > > > > wdyt ? > > > > JIRA : https://issues.jboss.org/browse/AEROGEAR-1464 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/1b69705e/attachment.html From edewit at redhat.com Wed Apr 2 04:11:33 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 2 Apr 2014 10:11:33 +0200 Subject: [aerogear-dev] Creating a Cordova Project in Jira In-Reply-To: References: <46B79FBB-832A-4193-8E38-C9BBF1ABD2BE@gmail.com> Message-ID: <3B0F1F09-87B9-49E4-971E-1AE436454B98@redhat.com> On 2 Apr,2014, at 10:08 , tolis emmanouilidis wrote: > +1 I had the same idea in the past. it seems there is a cordova component under AEROGEAR Right that is the one I use now, isn?t that enough? From matzew at apache.org Wed Apr 2 04:21:18 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Apr 2014 10:21:18 +0200 Subject: [aerogear-dev] Creating a Cordova Project in Jira In-Reply-To: References: Message-ID: yeah, sounds reasonable to me, to track cordova specific items under a separate JIRA - also it helps for individual release schedules On Wed, Apr 2, 2014 at 9:40 AM, Sebastien Blanc wrote: > Hi, > > For all the projects we have a specific Project : AGPUSH, AGJS, AGSEC etc > ... > I think it would be nice to have also one for Cordova and I propose : > AGCORDOVA > > > wdyt ? > > JIRA : https://issues.jboss.org/browse/AEROGEAR-1464 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/3f291b20/attachment.html From miguel21op at gmail.com Wed Apr 2 05:05:22 2014 From: miguel21op at gmail.com (Miiguel Lemos) Date: Wed, 2 Apr 2014 10:05:22 +0100 Subject: [aerogear-dev] Aero push iOS 64bit? In-Reply-To: <8AF21682-C2A0-4A05-A67E-0E4A62F3D864@redhat.com> References: <1396384671802-7258.post@n5.nabble.com> <8AF21682-C2A0-4A05-A67E-0E4A62F3D864@redhat.com> Message-ID: It works with 64 bits processors, but you must change the compilation parameters in Xcode. My test profile is: IPhone 5 Cordova 3.4 Xcode 5.1 There are several ways to do that. The easiest one is to remove the ios platform: cordova platform remove ios And then add it again, and afterwards cordova prepare etc. This is not a permanent basis solution, but works well. Enviado do meu iPad No dia 02/04/2014, ?s 08:54, Erik Jan de Wit escreveu: > Hi, > > Thanks for trying our project, currently Cordova doesn?t support 64 bit builds (see the very long discussion about it). When that is fixed we?ll need to update our push library to also support 64 bit (I?ve create an issue). Cordova already fixed their issue we just need to wait for a release and then you are good to go. > > Hope you can wait for that to happen, > Cheers, > Erik Jan > >> On 1 Apr,2014, at 22:37 , johnbran wrote: >> >> Hello, >> I am running xcode 5.1 and cordova 3.4. When I test my app on an iPhone 4 >> it works without issue. When I run it on an 5s (64bits) or in the 64bit >> iphone simulator I get the following errors... >> >> ld: warning: ignoring file >> /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a, >> missing required architecture x86_64 in file >> /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a >> (3 slices) >> Undefined symbols for architecture x86_64: >> "_OBJC_CLASS_$_AGDeviceRegistration", referenced from: >> objc-class-ref in PushPlugin.o >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> If I choose to compile only to 32bits using $(ARCHS_STANDARD_32_BIT) in the >> Architecture build settings, Cordova throws errors. >> >> Does Aero push for iOS support 64bits? I got it working nicely in Android >> and would like to use the same system for iOS. >> >> Thanks >> >> >> >> -- >> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aero-push-iOS-64bit-tp7258.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/85eac03d/attachment-0001.html From miguel21op at gmail.com Wed Apr 2 05:06:17 2014 From: miguel21op at gmail.com (Miiguel Lemos) Date: Wed, 2 Apr 2014 10:06:17 +0100 Subject: [aerogear-dev] Creating a Cordova Project in Jira In-Reply-To: References: Message-ID: <9878038C-DA9F-4235-8694-1A9D01E6EDC8@gmail.com> Yes, of course ;-) Enviado do meu iPad No dia 02/04/2014, ?s 08:40, Sebastien Blanc escreveu: > Hi, > > For all the projects we have a specific Project : AGPUSH, AGJS, AGSEC etc ... > I think it would be nice to have also one for Cordova and I propose : AGCORDOVA > > > wdyt ? > > JIRA : https://issues.jboss.org/browse/AEROGEAR-1464 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/3808273a/attachment.html From miguel21op at gmail.com Wed Apr 2 05:26:06 2014 From: miguel21op at gmail.com (Miiguel Lemos) Date: Wed, 2 Apr 2014 10:26:06 +0100 Subject: [aerogear-dev] Aero push iOS 64bit? In-Reply-To: <8AF21682-C2A0-4A05-A67E-0E4A62F3D864@redhat.com> References: <1396384671802-7258.post@n5.nabble.com> <8AF21682-C2A0-4A05-A67E-0E4A62F3D864@redhat.com> Message-ID: Of course, don't forget to change your project target before compiling it. By the way: I use to compile my iPhone apps through the console directly to the device, and not through XCode. This way some auto features of the SDK will not be called, thus avoiding some errors that will "hurt" Cordova. Miguel Enviado do meu iPad No dia 02/04/2014, ?s 08:54, Erik Jan de Wit escreveu: > Hi, > > Thanks for trying our project, currently Cordova doesn?t support 64 bit builds (see the very long discussion about it). When that is fixed we?ll need to update our push library to also support 64 bit (I?ve create an issue). Cordova already fixed their issue we just need to wait for a release and then you are good to go. > > Hope you can wait for that to happen, > Cheers, > Erik Jan > >> On 1 Apr,2014, at 22:37 , johnbran wrote: >> >> Hello, >> I am running xcode 5.1 and cordova 3.4. When I test my app on an iPhone 4 >> it works without issue. When I run it on an 5s (64bits) or in the 64bit >> iphone simulator I get the following errors... >> >> ld: warning: ignoring file >> /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a, >> missing required architecture x86_64 in file >> /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a >> (3 slices) >> Undefined symbols for architecture x86_64: >> "_OBJC_CLASS_$_AGDeviceRegistration", referenced from: >> objc-class-ref in PushPlugin.o >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> If I choose to compile only to 32bits using $(ARCHS_STANDARD_32_BIT) in the >> Architecture build settings, Cordova throws errors. >> >> Does Aero push for iOS support 64bits? I got it working nicely in Android >> and would like to use the same system for iOS. >> >> Thanks >> >> >> >> -- >> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aero-push-iOS-64bit-tp7258.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/cebd4796/attachment.html From matzew at apache.org Wed Apr 2 05:49:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Apr 2014 11:49:27 +0200 Subject: [aerogear-dev] Passphrase encryption and clients In-Reply-To: References: <1D451839-8F08-4C3B-942A-E39D46E160E3@redhat.com> Message-ID: Ahoy! On Mon, Mar 31, 2014 at 7:54 PM, Bruno Oliveira wrote: > Feel free to post your questions here, sorry about that. > > My question is: Should the sender implement certificate upload as a > feature? > Ok, looked at this again: https://gist.github.com/abstractj/ef1e3d53619796f4e87e#http-request-2 So, I am not sure why the sender would actually need to upload the Apple certificate - I feel I am missing something. As suggested earlier, let's have a google hangout and discuss this. I'll volunteer to write a summary of it, and will post it here. -Matthias > > -- > abstractj > > On March 31, 2014 at 2:52:05 PM, Lucas Holmquist (lholmqui at redhat.com) > wrote: > > > wasn't sure where to put the question, so i'll do it here > > > > > > so are you asking if our "sender" clients should also do registration > > of apps/variants too? > > > > well, since the sender clients are just really replacing curl, > > then that would probably work > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/2f1da490/attachment.html From lukas.fryc at gmail.com Wed Apr 2 07:07:13 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 2 Apr 2014 13:07:13 +0200 Subject: [aerogear-dev] AeroGear.js without jQuery Discussion In-Reply-To: <46FDD9DA-7305-444D-A1B2-4D0D2F4A9938@redhat.com> References: <6D6F35A3-BF5F-431E-A916-C5FB7966189E@redhat.com> <97A36F35-7C1C-4078-9594-ABD2A82A1D38@redhat.com> <20140325122659.38fb4055@kapy-ntb-x220> <46FDD9DA-7305-444D-A1B2-4D0D2F4A9938@redhat.com> Message-ID: On Wed, Apr 2, 2014 at 2:08 AM, Lucas Holmquist wrote: > > On Apr 1, 2014, at 5:05 PM, Luk?? Fry? wrote: > > I'm all for using promises that actually make sense, > but have you considered consistency? > > Are you suggesting some modules will return jQuery.Deferred while others > will use ES6 promises? > > > i re read what i wrote and i think i wrote it very confusingly(?), not > sure that is a word, but i'm going with it > > I would like to start with the UnifiedPushClient and remove the jQuery > dependency from that. It would then return an ES6 promise instead, or you > can still use callbacks. > Good point, jQuery fans who will start to use ES6 promises won't receive just few additional parameters, but otherwise they can keep using a then(success, error) syntax. > > i think this might be ok for a next release, 1.5.0, since the api is > labeled experimental. > > > For datamanager, 2 out of the 4 adapters are labeled experimental, so we > would not change the promises return type until 2.0 > > what i previously wrote sounded like i wanted to change 2 data manager > adapters while keeping the other 2 the same. > Yea, that's what I heard, thanks for explanation. :-) > > > > I would vote for all or nothing. ;-) > > > What about allow a developer to override what promise will be returned? > We can pass all promises through singleton (that can be > overwritten/plugged-in by the developer), > and that will decide what promise to return. > > > This could be interesting, but i would like to keep things simple first > +1 for simplicity So just to re-iterate, the plan is to keep stable 1.x APIs as they are, but in new APIs, leverage promises and offer people a polyfill. In 2.x, we can fully embrace ES6 promises. > > > In 1.x it can return jQuery.Deferred by default (but can be rewritten to > Promise). > In 2.x it can return Promise (as in ES6) by default (but can be rewritten > to jQuery.Deferred). > > > > > On Tue, Apr 1, 2014 at 3:36 PM, Sebastien Blanc wrote: > >> >> >> >> On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist wrote: >> >>> in the canary branch i started looking at removing jQuery from the >>> UnifiedPush client code, since it only uses jQuery.Ajax. >>> >>> https://github.com/aerogear/aerogear-js/tree/canary >>> >> >> That's really cool and I will probably use this in my experimental >> FirefoxOS support for the Cordova Push Plugin >> >>> >>> i was thinking this would be a 2.0 thing, but for this particular >>> module/adapter/whatevs, i think we can update it before that since we >>> marked it "experimental" >>> >>> in datamanager we have the IndexedDB and WebSQL adapters marked as >>> experimental, so we could do those, but since the other 2 adapters are >>> not, we should probably wait. >>> >>> Just want to see what the team thought about that, before i started to >>> go cray-cray >>> >>> >>> -Luke >>> >>> >>> On Mar 25, 2014, at 8:58 AM, Lucas Holmquist >>> wrote: >>> >>> >>> On Mar 25, 2014, at 8:15 AM, Luk?? Fry? wrote: >>> >>> Side note: getting integration with jQuery{ajax,promises} right was one >>> of the pain points when integrating with AeroGear.js / Angular (uses q.js, >>> and custom http service). >>> >>> i know they include their "own" version of jQuery >>> >>> We must be sure whatever we choose is compatible with frameworks out >>> there (at least it should not hard-nut to make it work). In terms of >>> promises implementation. In the end people may even end up using 2-3 >>> promise approaches in one project that makes code pretty disgusting. >>> >>> So: >>> >>> +1 getting rid of jQuery.ajax >>> +1 getting rid of jQuery promises (they are just wrong anyway ;-) >>> >>> >>> Btw in terms of polyfilling, I would suggest: >>> >>> 1) use whatever standard *is* as long as supported by majority of >>> mainstream browsers >>> >>> 2) use whatever standard *will be *and compile polyfill into >>> aerogear.js (as long as it's not too bloated; not necessary for bower users) >>> >>> >>> the polyfill i was thinking about is here >>> https://github.com/jakearchibald/es6-promise >>> >>> it is just the spec and 2kb gzipped, which is nice >>> >>> and i think this could be an external( compiled in ) dep of the library >>> >>> >>> Wdyt? >>> >>> >>> >>> On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko wrote: >>> >>>> Given number of supported browsers is quite low - >>>> http://caniuse.com/promises, I >>>> believe that polyfill will be needed even with version 2.0. >>>> >>>> On Mon, 24 Mar 2014 12:01:38 -0400 >>>> Lucas Holmquist wrote: >>>> >>>> > >>>> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc >>>> wrote: >>>> > >>>> > > >>>> > > >>>> > > >>>> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf < >>>> matzew at apache.org> >>>> > > wrote: >>>> > > >>>> > > >>>> > > >>>> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc < >>>> scm.blanc at gmail.com> >>>> > > wrote: >>>> > > >>>> > > >>>> > > >>>> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist < >>>> lholmqui at redhat.com> >>>> > > wrote: >>>> > > >>>> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis < >>>> tolisemm at gmail.com> >>>> > > wrote: >>>> > > >>>> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf >>> >: >>>> > >> >>>> > >> >>>> > >> >>>> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist < >>>> lholmqui at redhat.com> >>>> > >> wrote: >>>> > >>> I agree that it would be nice to implement AGJS-70 (Investigate >>>> removing >>>> > >>> jQuery requirement). Meanwhile, there is an open source project >>>> on GitHub >>>> > >>> that claims to offer a custom builder for jQuery in order to >>>> include only >>>> > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we >>>> could >>>> > >>> create a custom jQuery build which includes only the parts >>>> currently >>>> > >>> needed in AeroGear. This would mean a smaller size of the jQuery >>>> > >>> dependency. >>>> > >> >>>> > >> The AG lib depends on a few parts of jQuery, the biggest being >>>> jQuery.Ajax >>>> > >> and the promise implementation. >>>> > >> >>>> > >> i know we can make custom builds of jQuery pretty easily( building >>>> from >>>> > >> source ), but i don't really want to bundle it within our lib. >>>> > >> >>>> > >> and i don't think with bower we can do this easily. although they >>>> did just >>>> > >> add a post install hook, so perhaps that could be something to >>>> look at. >>>> > >> >>>> > >> Datamanager only uses the promise implementation of jQuery( and >>>> some >>>> > >> random thing for the filter method, which could probably be >>>> updated ). >>>> > >> >>>> > >> >>>> > >> Promises are starting to become available natively in browsers and >>>> jQuery >>>> > >> doesn't use the Promise/A+ spec, so it could be harder to fallback >>>> > >> without a shim of some kind >>>> > >> >>>> > >> Good to know. Thanks for providing this info. >>>> > >> >>>> > >> >>>> > >> sounds reasonable to 'wait' on the promise side of things, and use >>>> that >>>> > >> bit in the datamanager >>>> > >> >>>> > >> +1 >>>> > > >>>> > > there are other promise implementations that we could use, that are >>>> to >>>> > > spec, such as Q and RSVP, here is the link to the HTML5 rocks >>>> article >>>> > > http://www.html5rocks.com/en/tutorials/es6/promises/ >>>> > > >>>> > > These last days I have been playing with the library When provided >>>> by Cujo, >>>> > > it's maybe also worth looking https://github.com/cujojs/when >>>> > > >>>> > > not sure I see value in using a different library as a temporary >>>> thing. >>>> > > Once the API is part of the browser platform, the need for [yet >>>> another js >>>> > > lib] goes away. I know but I'm more concerned about "Once the API >>>> is part >>>> > > of the browser platform" When will that happen and does it match >>>> with our >>>> > > roadmap ? Was also to offer a polyfill for older browser if we want >>>> to keep >>>> > > supporting them. >>>> > > >>>> > i will have to update the roadmap. >>>> > >>>> > 2.0 would be a nice time to "fully" switch, but we can start >>>> experimenting >>>> > now and maybe for 1.5 can have some implemenation for data manager >>>> only. >>>> > >>>> > Current Chrome has Promise's enable by default and it looks like >>>> FireFox >>>> > 29( next version ) will too. Safari and IE are in dev i believe >>>> > >>>> > for fallback we can still make use of jQuery i think because of this >>>> method >>>> > here "Promise.cast", although the closest lib to the spec is RSVP( >>>> maybe >>>> > this could be the 2.0 fallback if we remove jQuery from the whole lib >>>> ) >>>> > >>>> > >>>> > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > >> >>>> > >> >>>> > >> >>>> > >> while i don't really want to reinvent the wheel in terms of Ajax, >>>> it >>>> > >> might be interesting to take a look. >>>> > >> >>>> > >> Yeah, IMO worth to look there, for reducing dependencies >>>> > >> >>>> > >> -M >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> I think in a previous ML thread about what 2.0 looked like, that >>>> > >> Pipeline would maybe just be a JSON only thing, with exception for >>>> > >> multipart >>>> > >> >>>> > >> >>>> > >> >>>> > >> @Lucas Thanks for making things clear >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> _______________________________________________ >>>> > >> aerogear-dev mailing list >>>> > >> aerogear-dev at 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 >>>> > >> >>>> > >> _______________________________________________ >>>> > >> aerogear-dev mailing list >>>> > >> aerogear-dev at lists.jboss.org >>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > >> >>>> > >> _______________________________________________ >>>> > >> aerogear-dev mailing list >>>> > >> aerogear-dev at lists.jboss.org >>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > aerogear-dev mailing list >>>> > > aerogear-dev at lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > aerogear-dev mailing list >>>> > > aerogear-dev at 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 >>>> > > >>>> > > _______________________________________________ >>>> > > aerogear-dev mailing list >>>> > > aerogear-dev at lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > > >>>> > > _______________________________________________ >>>> > > aerogear-dev mailing list >>>> > > aerogear-dev at lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/212e6f95/attachment-0001.html From lholmqui at redhat.com Wed Apr 2 08:22:25 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 2 Apr 2014 08:22:25 -0400 Subject: [aerogear-dev] AeroGear.js without jQuery Discussion In-Reply-To: References: <6D6F35A3-BF5F-431E-A916-C5FB7966189E@redhat.com> <97A36F35-7C1C-4078-9594-ABD2A82A1D38@redhat.com> <20140325122659.38fb4055@kapy-ntb-x220> <46FDD9DA-7305-444D-A1B2-4D0D2F4A9938@redhat.com> Message-ID: <80C896A5-E530-45FA-833F-18CFC5B3468B@redhat.com> On Apr 2, 2014, at 7:07 AM, Luk?? Fry? wrote: > > > > On Wed, Apr 2, 2014 at 2:08 AM, Lucas Holmquist wrote: > > On Apr 1, 2014, at 5:05 PM, Luk?? Fry? wrote: > >> I'm all for using promises that actually make sense, >> but have you considered consistency? >> >> Are you suggesting some modules will return jQuery.Deferred while others will use ES6 promises? > > i re read what i wrote and i think i wrote it very confusingly(?), not sure that is a word, but i'm going with it > > I would like to start with the UnifiedPushClient and remove the jQuery dependency from that. It would then return an ES6 promise instead, or you can still use callbacks. > > Good point, jQuery fans who will start to use ES6 promises won't receive just few additional parameters, but otherwise they can keep using a then(success, error) syntax. > > > i think this might be ok for a next release, 1.5.0, since the api is labeled experimental. > > > For datamanager, 2 out of the 4 adapters are labeled experimental, so we would not change the promises return type until 2.0 > > what i previously wrote sounded like i wanted to change 2 data manager adapters while keeping the other 2 the same. > > Yea, that's what I heard, thanks for explanation. :-) > > > > >> >> I would vote for all or nothing. ;-) >> >> >> What about allow a developer to override what promise will be returned? >> We can pass all promises through singleton (that can be overwritten/plugged-in by the developer), >> and that will decide what promise to return. > > This could be interesting, but i would like to keep things simple first > > +1 for simplicity > > > So just to re-iterate, the plan is to keep stable 1.x APIs as they are, > but in new APIs, leverage promises and offer people a polyfill. > > In 2.x, we can fully embrace ES6 promises. correct > > >> >> In 1.x it can return jQuery.Deferred by default (but can be rewritten to Promise). >> In 2.x it can return Promise (as in ES6) by default (but can be rewritten to jQuery.Deferred). >> >> >> >> >> On Tue, Apr 1, 2014 at 3:36 PM, Sebastien Blanc wrote: >> >> >> >> On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist wrote: >> in the canary branch i started looking at removing jQuery from the UnifiedPush client code, since it only uses jQuery.Ajax. >> >> https://github.com/aerogear/aerogear-js/tree/canary >> >> That's really cool and I will probably use this in my experimental FirefoxOS support for the Cordova Push Plugin >> >> i was thinking this would be a 2.0 thing, but for this particular module/adapter/whatevs, i think we can update it before that since we marked it "experimental" >> >> in datamanager we have the IndexedDB and WebSQL adapters marked as experimental, so we could do those, but since the other 2 adapters are not, we should probably wait. >> >> Just want to see what the team thought about that, before i started to go cray-cray >> >> >> -Luke >> >> >> On Mar 25, 2014, at 8:58 AM, Lucas Holmquist wrote: >> >>> >>> On Mar 25, 2014, at 8:15 AM, Luk?? Fry? wrote: >>> >>>> Side note: getting integration with jQuery{ajax,promises} right was one of the pain points when integrating with AeroGear.js / Angular (uses q.js, and custom http service). >>>> >>> i know they include their "own" version of jQuery >>> >>>> We must be sure whatever we choose is compatible with frameworks out there (at least it should not hard-nut to make it work). In terms of promises implementation. In the end people may even end up using 2-3 promise approaches in one project that makes code pretty disgusting. >>>> >>>> So: >>>> >>>> +1 getting rid of jQuery.ajax >>>> +1 getting rid of jQuery promises (they are just wrong anyway ;-) >>>> >>>> >>>> Btw in terms of polyfilling, I would suggest: >>>> >>>> 1) use whatever standard is as long as supported by majority of mainstream browsers >>>> >>>> 2) use whatever standard will be and compile polyfill into aerogear.js (as long as it's not too bloated; not necessary for bower users) >>>> >>> the polyfill i was thinking about is here https://github.com/jakearchibald/es6-promise >>> >>> it is just the spec and 2kb gzipped, which is nice >>> >>> and i think this could be an external( compiled in ) dep of the library >>> >>> >>>> Wdyt? >>>> >>>> >>>> >>>> On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko wrote: >>>> Given number of supported browsers is quite low - http://caniuse.com/promises, I >>>> believe that polyfill will be needed even with version 2.0. >>>> >>>> On Mon, 24 Mar 2014 12:01:38 -0400 >>>> Lucas Holmquist wrote: >>>> >>>> > >>>> > On Mar 24, 2014, at 11:55 AM, Sebastien Blanc wrote: >>>> > >>>> > > >>>> > > >>>> > > >>>> > > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf >>>> > > wrote: >>>> > > >>>> > > >>>> > > >>>> > > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc >>>> > > wrote: >>>> > > >>>> > > >>>> > > >>>> > > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist >>>> > > wrote: >>>> > > >>>> > > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis >>>> > > wrote: >>>> > > >>>> > >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf : >>>> > >> >>>> > >> >>>> > >> >>>> > >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist >>>> > >> wrote: >>>> > >>> I agree that it would be nice to implement AGJS-70 (Investigate removing >>>> > >>> jQuery requirement). Meanwhile, there is an open source project on GitHub >>>> > >>> that claims to offer a custom builder for jQuery in order to include only >>>> > >>> the modules needed [1] [2]. I haven't tried it yet but maybe we could >>>> > >>> create a custom jQuery build which includes only the parts currently >>>> > >>> needed in AeroGear. This would mean a smaller size of the jQuery >>>> > >>> dependency. >>>> > >> >>>> > >> The AG lib depends on a few parts of jQuery, the biggest being jQuery.Ajax >>>> > >> and the promise implementation. >>>> > >> >>>> > >> i know we can make custom builds of jQuery pretty easily( building from >>>> > >> source ), but i don't really want to bundle it within our lib. >>>> > >> >>>> > >> and i don't think with bower we can do this easily. although they did just >>>> > >> add a post install hook, so perhaps that could be something to look at. >>>> > >> >>>> > >> Datamanager only uses the promise implementation of jQuery( and some >>>> > >> random thing for the filter method, which could probably be updated ). >>>> > >> >>>> > >> >>>> > >> Promises are starting to become available natively in browsers and jQuery >>>> > >> doesn't use the Promise/A+ spec, so it could be harder to fallback >>>> > >> without a shim of some kind >>>> > >> >>>> > >> Good to know. Thanks for providing this info. >>>> > >> >>>> > >> >>>> > >> sounds reasonable to 'wait' on the promise side of things, and use that >>>> > >> bit in the datamanager >>>> > >> >>>> > >> +1 >>>> > > >>>> > > there are other promise implementations that we could use, that are to >>>> > > spec, such as Q and RSVP, here is the link to the HTML5 rocks article >>>> > > http://www.html5rocks.com/en/tutorials/es6/promises/ >>>> > > >>>> > > These last days I have been playing with the library When provided by Cujo, >>>> > > it's maybe also worth looking https://github.com/cujojs/when >>>> > > >>>> > > not sure I see value in using a different library as a temporary thing. >>>> > > Once the API is part of the browser platform, the need for [yet another js >>>> > > lib] goes away. I know but I'm more concerned about "Once the API is part >>>> > > of the browser platform" When will that happen and does it match with our >>>> > > roadmap ? Was also to offer a polyfill for older browser if we want to keep >>>> > > supporting them. >>>> > > >>>> > i will have to update the roadmap. >>>> > >>>> > 2.0 would be a nice time to "fully" switch, but we can start experimenting >>>> > now and maybe for 1.5 can have some implemenation for data manager only. >>>> > >>>> > Current Chrome has Promise's enable by default and it looks like FireFox >>>> > 29( next version ) will too. Safari and IE are in dev i believe >>>> > >>>> > for fallback we can still make use of jQuery i think because of this method >>>> > here "Promise.cast", although the closest lib to the spec is RSVP( maybe >>>> > this could be the 2.0 fallback if we remove jQuery from the whole lib ) >>>> > >>>> > >>>> > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > >> >>>> > >> >>>> > >> >>>> > >> while i don't really want to reinvent the wheel in terms of Ajax, it >>>> > >> might be interesting to take a look. >>>> > >> >>>> > >> Yeah, IMO worth to look there, for reducing dependencies >>>> > >> >>>> > >> -M >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> I think in a previous ML thread about what 2.0 looked like, that >>>> > >> Pipeline would maybe just be a JSON only thing, with exception for >>>> > >> multipart >>>> > >> >>>> > >> >>>> > >> >>>> > >> @Lucas Thanks for making things clear >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> _______________________________________________ >>>> > >> aerogear-dev mailing list >>>> > >> aerogear-dev at 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 >>>> > >> >>>> > >> _______________________________________________ >>>> > >> aerogear-dev mailing list >>>> > >> aerogear-dev at lists.jboss.org >>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > >> >>>> > >> _______________________________________________ >>>> > >> aerogear-dev mailing list >>>> > >> aerogear-dev at lists.jboss.org >>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > aerogear-dev mailing list >>>> > > aerogear-dev at lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > aerogear-dev mailing list >>>> > > aerogear-dev at 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 >>>> > > >>>> > > _______________________________________________ >>>> > > aerogear-dev mailing list >>>> > > aerogear-dev at lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > > >>>> > > _______________________________________________ >>>> > > aerogear-dev mailing list >>>> > > aerogear-dev at lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/8f545338/attachment-0001.html From supittma at redhat.com Wed Apr 2 08:58:13 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 02 Apr 2014 08:58:13 -0400 Subject: [aerogear-dev] Android Studio / Gradle support In-Reply-To: <533B2907.8070303@slintes.net> References: <533B2907.8070303@slintes.net> Message-ID: <533C0965.2040305@redhat.com> Congrats! I've given some feed back inline with your post. On 04/01/2014 05:00 PM, Marc Sluiter wrote: > (next try, sorry again) > > Hi all, > > some time ago there was already a discussion about using Android Studio / Gradle > [1], but as far as I can see nothing happened afterwards. Well lots of stuff happened. We ended up deciding to do it, and ran into the Robolectric problems you described. Also we were still going to have to maintain a maven build to get apk libs working and integrate with our various build systems. Then the maven-android-plugin project added aar support so we went with that instead. > > So I was curious if I can get the cookbook application running with Android's > new build system, and want to share what I found out so far: > > My first approach was to migrate the cookbook first, and using the library as > dependency only. But that didn't work out, because the Androd dependencies in > the pom.xml of the lib could not be found. I really didn't want to install them > with the maven-android-sdk-deployer, because that's not needed anymore with the > new build system, it accesses directly the installed Android SDK. > > So I migrated the lib first. The first issue was: how do I get the aar into my > local maven repository? Solution: the Gradle Android Maven plugin [2]. After > some configuration I could install the lib into my local maven repo with > "gradlew clean install". Nice. It is very nice. mvn clean install should install an aar into your local repository as well however. If it didn't do that can you file a JIRA? > > Then I looked how I can run the Robolectric tests in the lib. That seems to be a > problem, because the Android Gradle plugin team seems to be focused on running > tests in AVDs or on real devices only [3]. Then I found another Gradle plugin to > the rescue... at least I thought: the Robolectric team itself maintains the > Gradle Android Unit Testing plugin [4], which should run JUnit and Robolectric > tests, but unfortunatly it was broken by the latest Android Gradle plugin > update... [5]. So I prepared running the tests, but had to comment out the > plugin for the moment. > > So back to the cookbook: here I had to use a workaround now for accessing my > local maven repo, because the official and easy way is broken in Gradle itself > atm [6]. But with the workaround I could run the cookbook app on my device with > "gradle clean installDebug"... finally (And with the OpenShift Push Server it > was easy to test the push functionality, great!) Huzzah! > > So my resume of this adventure: > before that I liked Android Studio very much, I used it for some little private > fun apps already, and had only few problems. It has features (e.g. product > flavors) which were more difficult to handle with maven. But I tested only by > deploying and using the apps on my own devices (shame on me, I know...), so > missing JUnit/Robolectric support was not an issue for me. And my library > project was part of the app's project (works nice with Gradle!), so no local > maven issues. > But now I think that there is still some work to do with Android Studio and the > Android Gradle plugin. Some gaps can be filled with 3rd party plugins, but the > chance that they get broken by new versions of the build system is not low, > development is very fast. Yeah. The fast moving target was a downer for us as well. > > One point I forgot: I did not have a look into the Travis stuff, because I don't > know it yet. > > If you are interested in my results, see here: > > https://github.com/slintes/aerogear-android/tree/gradle > https://github.com/slintes/aerogear-android-cookbook/tree/gradle > > Kind regards, > > Marc Thanks! > > > [1] > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Google-s-Gradle-build-tool-and-AAR-td4508.html > [2] https://github.com/dcendents/android-maven-plugin > [3] http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Testing > [4] https://github.com/robolectric/gradle-android-test-plugin > [5] https://github.com/robolectric/gradle-android-test-plugin/issues/8 > [6] https://code.google.com/p/android/issues/detail?id=63908 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From marc at slintes.net Wed Apr 2 09:26:37 2014 From: marc at slintes.net (Marc Sluiter) Date: Wed, 02 Apr 2014 15:26:37 +0200 Subject: [aerogear-dev] Android Studio / Gradle support In-Reply-To: <533C0965.2040305@redhat.com> References: <533B2907.8070303@slintes.net> <533C0965.2040305@redhat.com> Message-ID: <533C100D.1040404@slintes.net> Thanks for your feedback. Some comments inline. Am 02.04.2014 14:58, schrieb Summers Pittman: > Congrats! I've given some feed back inline with your post. > > On 04/01/2014 05:00 PM, Marc Sluiter wrote: >> (next try, sorry again) >> >> Hi all, >> >> some time ago there was already a discussion about using Android Studio / Gradle >> [1], but as far as I can see nothing happened afterwards. > Well lots of stuff happened. We ended up deciding to do it, and ran > into the Robolectric problems you described. Also we were still going > to have to maintain a maven build to get apk libs working and integrate > with our various build systems. Then the maven-android-plugin project > added aar support so we went with that instead. Ok, good point. It seems to be possible to create apklibs with Gradle too: https://plus.google.com/+ChristopherBroadfoot/posts/7uyipf8DTau. I think I will give it a try in my setup the next days. >> >> So I was curious if I can get the cookbook application running with Android's >> new build system, and want to share what I found out so far: >> >> My first approach was to migrate the cookbook first, and using the library as >> dependency only. But that didn't work out, because the Androd dependencies in >> the pom.xml of the lib could not be found. I really didn't want to install them >> with the maven-android-sdk-deployer, because that's not needed anymore with the >> new build system, it accesses directly the installed Android SDK. >> >> So I migrated the lib first. The first issue was: how do I get the aar into my >> local maven repository? Solution: the Gradle Android Maven plugin [2]. After >> some configuration I could install the lib into my local maven repo with >> "gradlew clean install". Nice. > It is very nice. mvn clean install should install an aar into your > local repository as well however. If it didn't do that can you file a JIRA? I did not even try it with maven and took directly the migration-to-gradle approach. But I can test that, too. >> >> Then I looked how I can run the Robolectric tests in the lib. That seems to be a >> problem, because the Android Gradle plugin team seems to be focused on running >> tests in AVDs or on real devices only [3]. Then I found another Gradle plugin to >> the rescue... at least I thought: the Robolectric team itself maintains the >> Gradle Android Unit Testing plugin [4], which should run JUnit and Robolectric >> tests, but unfortunatly it was broken by the latest Android Gradle plugin >> update... [5]. So I prepared running the tests, but had to comment out the >> plugin for the moment. >> >> So back to the cookbook: here I had to use a workaround now for accessing my >> local maven repo, because the official and easy way is broken in Gradle itself >> atm [6]. But with the workaround I could run the cookbook app on my device with >> "gradle clean installDebug"... finally (And with the OpenShift Push Server it >> was easy to test the push functionality, great!) > Huzzah! >> >> So my resume of this adventure: >> before that I liked Android Studio very much, I used it for some little private >> fun apps already, and had only few problems. It has features (e.g. product >> flavors) which were more difficult to handle with maven. But I tested only by >> deploying and using the apps on my own devices (shame on me, I know...), so >> missing JUnit/Robolectric support was not an issue for me. And my library >> project was part of the app's project (works nice with Gradle!), so no local >> maven issues. >> But now I think that there is still some work to do with Android Studio and the >> Android Gradle plugin. Some gaps can be filled with 3rd party plugins, but the >> chance that they get broken by new versions of the build system is not low, >> development is very fast. > Yeah. The fast moving target was a downer for us as well. >> >> One point I forgot: I did not have a look into the Travis stuff, because I don't >> know it yet. >> >> If you are interested in my results, see here: >> >> https://github.com/slintes/aerogear-android/tree/gradle >> https://github.com/slintes/aerogear-android-cookbook/tree/gradle >> >> Kind regards, >> >> Marc > Thanks! You're welcome >> >> >> [1] >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Google-s-Gradle-build-tool-and-AAR-td4508.html >> [2] https://github.com/dcendents/android-maven-plugin >> [3] http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Testing >> [4] https://github.com/robolectric/gradle-android-test-plugin >> [5] https://github.com/robolectric/gradle-android-test-plugin/issues/8 >> [6] https://code.google.com/p/android/issues/detail?id=63908 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > From michi.oshima at gmail.com Wed Apr 2 11:02:08 2014 From: michi.oshima at gmail.com (Michi Oshima) Date: Wed, 2 Apr 2014 11:02:08 -0400 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? Message-ID: Hi, Yesterday I managed to send my first message to a browser. Thanks for all your help. I've tried sending a few different types of messages, and it so far appears to me the only thing I can send to a simple push client is a version number. Can a simple push client receive anything else other than version numbers? If so, what does the sender need to do, and what does the client need to do? (If there is a good example somewhere online I can work from that also.) My client application (javascript on browser) holds multiple types of data. It would be nice if I can send a notification saying "there's an update for this data type", rather than just "there's an update". Or, in general it'd be nice if I can send more information than just a monotonically increasing number. Here's my setup: - AeroGear Push Server 0.10.0 hosted on OpenShift. - Sender is a JBoss app using org.jboss.aerogear.unifiedpush.JavaSender (unifiedpush-java-client-0.5.0.jar). - Client is a web browser using aerogear.js 1.4.0. I read this documentation, but my wishful thinking refused to interpret it as saying: SimplePush variants use the "extra simple-push object" only. Thank you, Michi Oshima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/31456d34/attachment.html From lholmqui at redhat.com Wed Apr 2 11:04:23 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 2 Apr 2014 11:04:23 -0400 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: Message-ID: SimplePush works only as a "door bell" to tell your app, hey, you should go look on your server. this is the spec https://wiki.mozilla.org/WebAPI/SimplePush On Apr 2, 2014, at 11:02 AM, Michi Oshima wrote: > Hi, > > Yesterday I managed to send my first message to a browser. Thanks for all your help. > > I've tried sending a few different types of messages, and it so far appears to me the only thing I can send to a simple push client is a version number. Can a simple push client receive anything else other than version numbers? If so, what does the sender need to do, and what does the client need to do? (If there is a good example somewhere online I can work from that also.) > > My client application (javascript on browser) holds multiple types of data. It would be nice if I can send a notification saying "there's an update for this data type", rather than just "there's an update". Or, in general it'd be nice if I can send more information than just a monotonically increasing number. > > Here's my setup: > > AeroGear Push Server 0.10.0 hosted on OpenShift. > Sender is a JBoss app using org.jboss.aerogear.unifiedpush.JavaSender (unifiedpush-java-client-0.5.0.jar). > Client is a web browser using aerogear.js 1.4.0. > > I read this documentation, but my wishful thinking refused to interpret it as saying: SimplePush variants use the "extra simple-push object" only. > > Thank you, > > Michi Oshima > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/aa31960f/attachment.html From lholmqui at redhat.com Wed Apr 2 10:59:59 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 2 Apr 2014 10:59:59 -0400 Subject: [aerogear-dev] JS Team meet up highlights Message-ID: <6DE3B900-29B9-49B5-A461-A45A5235CFF3@redhat.com> Hello, here is a little summary of some of the things the JS team discussed -Luke JS Cool Team Stuff 1.5.0 - Early May MQTT WS adapter code cleanup More Cookbook examples https://issues.jboss.org/browse/AGJS-41 UnifiedPushClient jQuery Removal we need to polyfill it - pack that into client https://github.com/jakearchibald/es6-promise 1.6.0 - Mid July Data Sync(?) stalled, conversations started again is going liveoak to work on data sync? Keycloak(?) keycloak examples mention private key in a client code 1.7.0 - Late September Offline(?) service workers? application cache is still a douchebag 2.0.0 ES6 modules(?) - transpile maybe include in 1.6/1.7 we could leverage in custom builder, possibly challenge: compatibility w/ AMD / commonjs (UMD?) No jQuery Current Road Map http://aerogear.org/docs/planning/roadmaps/AeroGearJS/ 1.5.0 JIRA?s https://issues.jboss.org/issues/?jql=project%20%3D%20AGJS%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%221.5.0%22%20ORDER%20BY%20priority%20DESC Random Stuff 2.0 collect ideas what people might struggle with? pipelines - frameworks use usually own stuff improving documentation and getting started experience getting started with AG + particular web frameworks examples -> cookbook (complete stack) move tests to jasmine or something other than qunit(?) - not sure what the benefit could be https://issues.jboss.org/browse/AGJS-147 move docs to something other than jsdoc, ex: yui doc - not sure what the benefit could be https://issues.jboss.org/browse/AGJS-143 polymer components dataManager dataSync authentication buttons -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/4e000860/attachment-0001.html From michi.oshima at gmail.com Wed Apr 2 11:38:55 2014 From: michi.oshima at gmail.com (Michi Oshima) Date: Wed, 2 Apr 2014 11:38:55 -0400 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: Message-ID: Thanks, Lucas. I read the spec yesterday and ended up looking at disturbing auctions for 30 minutes. I'll read it again. Another question, is there a way to send a "door bell" message *in one shot* to all iOS, Android, and SimplePush variants? (m:) On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist wrote: > SimplePush works only as a "door bell" to tell your app, hey, you should > go look on your server. > > this is the spec https://wiki.mozilla.org/WebAPI/SimplePush > > > On Apr 2, 2014, at 11:02 AM, Michi Oshima wrote: > > Hi, > > Yesterday I managed to send my first message to a browser. Thanks for all > your help. > > I've tried sending a few different types of messages, and it so far > appears to me the only thing I can send to a simple push client is a > version number. Can a simple push client receive anything else other than > version numbers? If so, what does the sender need to do, and what does the > client need to do? (If there is a good example somewhere online I can work > from that also.) > > My client application (javascript on browser) holds multiple types of > data. It would be nice if I can send a notification saying "there's an > update for this data type", rather than just "there's an update". Or, in > general it'd be nice if I can send more information than just a > monotonically increasing number. > > Here's my setup: > > > - AeroGear Push Server 0.10.0 hosted on OpenShift. > - Sender is a JBoss app using > org.jboss.aerogear.unifiedpush.JavaSender > (unifiedpush-java-client-0.5.0.jar). > - Client is a web browser using aerogear.js 1.4.0. > > > I read this documentation, > but my wishful thinking refused to interpret it as saying: SimplePush > variants use the "extra simple-push object" only. > > Thank you, > > Michi Oshima > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/38e4e13c/attachment.html From lholmqui at redhat.com Wed Apr 2 11:44:14 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 2 Apr 2014 11:44:14 -0400 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: Message-ID: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> On Apr 2, 2014, at 11:38 AM, Michi Oshima wrote: > Thanks, Lucas. I read the spec yesterday and ended up looking at disturbing auctions for 30 minutes. I'll read it again. > > Another question, is there a way to send a "door bell" message *in one shot* to all iOS, Android, and SimplePush variants? well, iOS and Android notifications aren't really doorbells, but you can send a "message" to all clients that are registered in your Push Server. we have a Java client http://aerogear.org/docs/guides/GetStartedwithJavaSender/ and a node.js client for this https://www.npmjs.org/package/aerogear-sender-client > > (m:) > > > On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist wrote: > SimplePush works only as a "door bell" to tell your app, hey, you should go look on your server. > > this is the spec https://wiki.mozilla.org/WebAPI/SimplePush > > > On Apr 2, 2014, at 11:02 AM, Michi Oshima wrote: > >> Hi, >> >> Yesterday I managed to send my first message to a browser. Thanks for all your help. >> >> I've tried sending a few different types of messages, and it so far appears to me the only thing I can send to a simple push client is a version number. Can a simple push client receive anything else other than version numbers? If so, what does the sender need to do, and what does the client need to do? (If there is a good example somewhere online I can work from that also.) >> >> My client application (javascript on browser) holds multiple types of data. It would be nice if I can send a notification saying "there's an update for this data type", rather than just "there's an update". Or, in general it'd be nice if I can send more information than just a monotonically increasing number. >> >> Here's my setup: >> >> AeroGear Push Server 0.10.0 hosted on OpenShift. >> Sender is a JBoss app using org.jboss.aerogear.unifiedpush.JavaSender (unifiedpush-java-client-0.5.0.jar). >> Client is a web browser using aerogear.js 1.4.0. >> >> I read this documentation, but my wishful thinking refused to interpret it as saying: SimplePush variants use the "extra simple-push object" only. >> >> Thank you, >> >> Michi Oshima >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140402/def4da8c/attachment.html From edewit at redhat.com Thu Apr 3 02:11:06 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 3 Apr 2014 08:11:06 +0200 Subject: [aerogear-dev] cordova plugin release Message-ID: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> Hi, I would like to release another version of the cordova push plugin (next week thursday), the major feature will be the new simplified API that is already on the master branch and there have already been successful builds. Releasing it will update the version to 0.0.4 and make it available on the registry, it would also provide a test for the gradle release script. Cheers, Erik Jan From scm.blanc at gmail.com Thu Apr 3 02:38:01 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Thu, 3 Apr 2014 08:38:01 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> Message-ID: <4D8A9ABE-2DC1-439E-80E1-2C9C68BD22D2@gmail.com> +9001 Envoy? de mon iPhone > Le 3 avr. 2014 ? 08:11, Erik Jan de Wit a ?crit : > > Hi, > > I would like to release another version of the cordova push plugin (next week thursday), the major feature will be the new simplified API that is already on the master branch and there have already been successful builds. Releasing it will update the version to 0.0.4 and make it available on the registry, it would also provide a test for the gradle release script. > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Apr 3 03:15:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 3 Apr 2014 09:15:29 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> Message-ID: +1 on a release how about increasing the version number to something more major? e.g. 0.4.0 ? I don't feel that 0.0.x is the right versioning for the plugin On Thu, Apr 3, 2014 at 8:11 AM, Erik Jan de Wit wrote: > Hi, > > I would like to release another version of the cordova push plugin (next > week thursday), the major feature will be the new simplified API that is > already on the master branch and there have already been successful builds. > Releasing it will update the version to 0.0.4 and make it available on the > registry, it would also provide a test for the gradle release script. > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/c06426fa/attachment.html From scm.blanc at gmail.com Thu Apr 3 03:24:27 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 3 Apr 2014 09:24:27 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> Message-ID: On Thu, Apr 3, 2014 at 9:15 AM, Matthias Wessendorf wrote: > +1 on a release > > how about increasing the version number to something more major? e.g. > 0.4.0 ? I don't feel that 0.0.x is the right versioning for the plugin > +1 since we are also changing the api (onNotification passed as function and not as string anymore). And speaking about versions, we are pretty close to feature complete plugin. Do we have any roadmap ? (Yes :) I have 1.0 in mind ) > > > On Thu, Apr 3, 2014 at 8:11 AM, Erik Jan de Wit wrote: > >> Hi, >> >> I would like to release another version of the cordova push plugin (next >> week thursday), the major feature will be the new simplified API that is >> already on the master branch and there have already been successful builds. >> Releasing it will update the version to 0.0.4 and make it available on the >> registry, it would also provide a test for the gradle release script. >> >> Cheers, >> Erik Jan >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/798f4cb6/attachment-0001.html From corinnekrych at gmail.com Thu Apr 3 05:00:55 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 3 Apr 2014 11:00:55 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> Message-ID: <688DD2FC-4862-4C40-8CD2-C268755492A5@gmail.com> Will it be based on lib push-sdk-0.9.0 ? ++ Corinne On 03 Apr 2014, at 08:11, Erik Jan de Wit wrote: > Hi, > > I would like to release another version of the cordova push plugin (next week thursday), the major feature will be the new simplified API that is already on the master branch and there have already been successful builds. Releasing it will update the version to 0.0.4 and make it available on the registry, it would also provide a test for the gradle release script. > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Apr 3 05:05:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 3 Apr 2014 11:05:52 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: <688DD2FC-4862-4C40-8CD2-C268755492A5@gmail.com> References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> <688DD2FC-4862-4C40-8CD2-C268755492A5@gmail.com> Message-ID: On Thu, Apr 3, 2014 at 11:00 AM, Corinne Krych wrote: > Will it be based on lib push-sdk-0.9.0 ? > I'd say: yes > ++ > Corinne > On 03 Apr 2014, at 08:11, Erik Jan de Wit wrote: > > > Hi, > > > > I would like to release another version of the cordova push plugin (next > week thursday), the major feature will be the new simplified API that is > already on the master branch and there have already been successful builds. > Releasing it will update the version to 0.0.4 and make it available on the > registry, it would also provide a test for the gradle release script. > > > > Cheers, > > Erik Jan > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/14739114/attachment.html From edewit at redhat.com Thu Apr 3 05:11:11 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 3 Apr 2014 11:11:11 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> Message-ID: <565481F6-8324-4C20-9414-521C5C8866CE@redhat.com> Right good point let?s make it version 1.0, I would also like to propose to something that Sebastien also said to leave the master branch on a snapshot version so that we know what people have installed and that we can add bug fixes strait to master and continue development on branches. And the build will need to create the binary for iOS and android as well so that the latest version of these dependencies are always included On 3 Apr,2014, at 9:24 , Sebastien Blanc wrote: > > > > On Thu, Apr 3, 2014 at 9:15 AM, Matthias Wessendorf wrote: > +1 on a release > > how about increasing the version number to something more major? e.g. 0.4.0 ? I don't feel that 0.0.x is the right versioning for the plugin > > +1 since we are also changing the api (onNotification passed as function and not as string anymore). And speaking about versions, we are pretty close to feature complete plugin. Do we have any roadmap ? (Yes :) I have 1.0 in mind ) > > > > > On Thu, Apr 3, 2014 at 8:11 AM, Erik Jan de Wit wrote: > Hi, > > I would like to release another version of the cordova push plugin (next week thursday), the major feature will be the new simplified API that is already on the master branch and there have already been successful builds. Releasing it will update the version to 0.0.4 and make it available on the registry, it would also provide a test for the gradle release script. > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/7d379bca/attachment.html From corinnekrych at gmail.com Thu Apr 3 05:14:35 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 3 Apr 2014 11:14:35 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: <565481F6-8324-4C20-9414-521C5C8866CE@redhat.com> References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> <565481F6-8324-4C20-9414-521C5C8866CE@redhat.com> Message-ID: And as we discussed in this other thread [1], we will also need a 64bits static lib version to target iPhone5S architecture. ++ Corinne [1] http://aerogear-dev.1069024.n5.nabble.com/Aero-push-iOS-64bit-td7258.html On 03 Apr 2014, at 11:11, Erik Jan de Wit wrote: > > Right good point let?s make it version 1.0, I would also like to propose to something that Sebastien also said to leave the master branch on a snapshot version so that we know what people have installed and that we can add bug fixes strait to master and continue development on branches. And the build will need to create the binary for iOS and android as well so that the latest version of these dependencies are always included > > On 3 Apr,2014, at 9:24 , Sebastien Blanc wrote: > >> >> >> >> On Thu, Apr 3, 2014 at 9:15 AM, Matthias Wessendorf wrote: >> +1 on a release >> >> how about increasing the version number to something more major? e.g. 0.4.0 ? I don't feel that 0.0.x is the right versioning for the plugin >> >> +1 since we are also changing the api (onNotification passed as function and not as string anymore). And speaking about versions, we are pretty close to feature complete plugin. Do we have any roadmap ? (Yes :) I have 1.0 in mind ) >> >> >> >> >> On Thu, Apr 3, 2014 at 8:11 AM, Erik Jan de Wit wrote: >> Hi, >> >> I would like to release another version of the cordova push plugin (next week thursday), the major feature will be the new simplified API that is already on the master branch and there have already been successful builds. Releasing it will update the version to 0.0.4 and make it available on the registry, it would also provide a test for the gradle release script. >> >> Cheers, >> Erik Jan >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Apr 3 05:17:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 3 Apr 2014 11:17:16 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: <565481F6-8324-4C20-9414-521C5C8866CE@redhat.com> References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> <565481F6-8324-4C20-9414-521C5C8866CE@redhat.com> Message-ID: On Thu, Apr 3, 2014 at 11:11 AM, Erik Jan de Wit wrote: > > Right good point let's make it version 1.0, > let's wait a bit for the 1.0.0 ... but let's make it close to 1.0 (e.g. 0.8 or something like that) > I would also like to propose to something that Sebastien also said to > leave the master branch on a snapshot version so that we know what people > have installed and that we can add bug fixes strait to master and continue > development on branches. And the build will need to create the binary for > iOS and android as well so that the latest version of these dependencies > are always included > > On 3 Apr,2014, at 9:24 , Sebastien Blanc wrote: > > > > > On Thu, Apr 3, 2014 at 9:15 AM, Matthias Wessendorf > wrote: > >> +1 on a release >> >> how about increasing the version number to something more major? e.g. >> 0.4.0 ? I don't feel that 0.0.x is the right versioning for the plugin >> > > +1 since we are also changing the api (onNotification passed as function > and not as string anymore). And speaking about versions, we are pretty > close to feature complete plugin. Do we have any roadmap ? (Yes :) I have > 1.0 in mind ) > > > >> >> >> On Thu, Apr 3, 2014 at 8:11 AM, Erik Jan de Wit >> wrote: >> >>> Hi, >>> >>> I would like to release another version of the cordova push plugin (next >>> week thursday), the major feature will be the new simplified API that is >>> already on the master branch and there have already been successful builds. >>> Releasing it will update the version to 0.0.4 and make it available on the >>> registry, it would also provide a test for the gradle release script. >>> >>> Cheers, >>> Erik Jan >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/5b55ca38/attachment-0001.html From miguel21op at gmail.com Thu Apr 3 05:56:09 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Thu, 3 Apr 2014 10:56:09 +0100 Subject: [aerogear-dev] Aero push iOS 64bit? In-Reply-To: References: <1396384671802-7258.post@n5.nabble.com> <8AF21682-C2A0-4A05-A67E-0E4A62F3D864@redhat.com> Message-ID: My confusion: iPhone 5 is a 32 bit processor, of course. The "mistake" was caused by the fact that when you compile your program with XCode 5.1 and Cordova, one of the things you must do is to add the Arm64 bit processor to the architectures setup. When compiling the program without it, Aerogear (and other plugins) throw a bunch of compiling errors. But I found out that it's easier to remove the iOS platform and reinstall it again, and then just change the target profile in XCode... On Wed, Apr 2, 2014 at 10:26 AM, Miiguel Lemos wrote: > Of course, don't forget to change your project target before compiling it. > > By the way: I use to compile my iPhone apps through the console directly > to the device, and not through XCode. This way some auto features of the > SDK will not be called, thus avoiding some errors that will "hurt" Cordova. > > Miguel > > Enviado do meu iPad > > No dia 02/04/2014, ?s 08:54, Erik Jan de Wit escreveu: > > Hi, > > Thanks for trying our project, currently Cordova doesn?t support 64 bit > builds (see the very long discussion about > it). When that is fixed we?ll need to update our push library to also > support 64 bit (I?ve create an issue). > Cordova already fixed their issue we just need to wait for a release and > then you are good to go. > > Hope you can wait for that to happen, > Cheers, > Erik Jan > > On 1 Apr,2014, at 22:37 , johnbran wrote: > > Hello, > I am running xcode 5.1 and cordova 3.4. When I test my app on an iPhone 4 > it works without issue. When I run it on an 5s (64bits) or in the 64bit > iphone simulator I get the following errors... > > ld: warning: ignoring file > > /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a, > missing required architecture x86_64 in file > > /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a > (3 slices) > Undefined symbols for architecture x86_64: > "_OBJC_CLASS_$_AGDeviceRegistration", referenced from: > objc-class-ref in PushPlugin.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > If I choose to compile only to 32bits using $(ARCHS_STANDARD_32_BIT) in the > Architecture build settings, Cordova throws errors. > > Does Aero push for iOS support 64bits? I got it working nicely in Android > and would like to use the same system for iOS. > > Thanks > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Aero-push-iOS-64bit-tp7258.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/5fd1e603/attachment.html From bsutter at redhat.com Thu Apr 3 06:25:38 2014 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 3 Apr 2014 06:25:38 -0400 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> <565481F6-8324-4C20-9414-521C5C8866CE@redhat.com> Message-ID: <5A900401-F15E-48A7-8903-860FAEDCD5B6@redhat.com> I agree, 1.0 means we think it is ready but we know we have a couple of more iterations and a couple of more months to get to a 1.0 On Apr 3, 2014, at 5:17 AM, Matthias Wessendorf wrote: > > > > On Thu, Apr 3, 2014 at 11:11 AM, Erik Jan de Wit wrote: > > Right good point let?s make it version 1.0, > > let's wait a bit for the 1.0.0 ... but let's make it close to 1.0 (e.g. 0.8 or something like that) > > I would also like to propose to something that Sebastien also said to leave the master branch on a snapshot version so that we know what people have installed and that we can add bug fixes strait to master and continue development on branches. And the build will need to create the binary for iOS and android as well so that the latest version of these dependencies are always included > > On 3 Apr,2014, at 9:24 , Sebastien Blanc wrote: > >> >> >> >> On Thu, Apr 3, 2014 at 9:15 AM, Matthias Wessendorf wrote: >> +1 on a release >> >> how about increasing the version number to something more major? e.g. 0.4.0 ? I don't feel that 0.0.x is the right versioning for the plugin >> >> +1 since we are also changing the api (onNotification passed as function and not as string anymore). And speaking about versions, we are pretty close to feature complete plugin. Do we have any roadmap ? (Yes :) I have 1.0 in mind ) >> >> >> >> >> On Thu, Apr 3, 2014 at 8:11 AM, Erik Jan de Wit wrote: >> Hi, >> >> I would like to release another version of the cordova push plugin (next week thursday), the major feature will be the new simplified API that is already on the master branch and there have already been successful builds. Releasing it will update the version to 0.0.4 and make it available on the registry, it would also provide a test for the gradle release script. >> >> Cheers, >> Erik Jan >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/e843957d/attachment.html From corinnekrych at gmail.com Thu Apr 3 07:57:11 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 3 Apr 2014 13:57:11 +0200 Subject: [aerogear-dev] iOS AeroGear 1.5 is out! Message-ID: Hello iOS lovers, Today is the day: we shipped release 1.5, please check out all the details: http://corinnekrych.org/2014/04/new-ios7-love-for-aerogear-libs.html Carefully crafted and tested, I?m sure you will share the love of iOS7 with us. ++ Corinne From michi.oshima at gmail.com Thu Apr 3 10:41:48 2014 From: michi.oshima at gmail.com (Michi Oshima) Date: Thu, 3 Apr 2014 10:41:48 -0400 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Hi Lucas, Following might do what I want (sending a "door bell" message in one shot to all variants)? Send a unified message like the following one: - '{ "message": { "version":"123" }, "simple-push": "version=123" }' One slight deviation is that mobile variants like iOS and Android will get the message regardless of whether the the version number is "old" or not. Is this correct? So I revisited the SimplePush spec, and I noticed it describes support for subscription to multiple channels. Aerogear doesn't allow multiple channels per installation, correct? I dug up an old post from Matthias: - http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none If an installation can subscribe to multiple channels, then it would allow me to get what I originally asked about: Me: 'My client application (javascript on browser) holds multiple types of data. It would be nice if I can send a notification saying "there's an update for this data type", rather than just "there's an update". Or, in general it'd be nice if I can send more information than just a monotonically increasing number. ' What do you think? On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist wrote: > On Apr 2, 2014, at 11:38 AM, Michi Oshima wrote: > > Thanks, Lucas. I read the spec yesterday and ended up looking at > disturbing auctions for 30 minutes. I'll read it again. > > Another question, is there a way to send a "door bell" message *in one > shot* to all iOS, Android, and SimplePush variants? > > > well, iOS and Android notifications aren't really doorbells, but you can > send a "message" to all clients that are registered in your Push Server. > > we have a Java client > http://aerogear.org/docs/guides/GetStartedwithJavaSender/ > > and a node.js client for this > https://www.npmjs.org/package/aerogear-sender-client > > > > > (m:) > > > On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist wrote: > >> SimplePush works only as a "door bell" to tell your app, hey, you >> should go look on your server. >> >> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >> >> >> On Apr 2, 2014, at 11:02 AM, Michi Oshima wrote: >> >> Hi, >> >> Yesterday I managed to send my first message to a browser. Thanks for >> all your help. >> >> I've tried sending a few different types of messages, and it so far >> appears to me the only thing I can send to a simple push client is a >> version number. Can a simple push client receive anything else other than >> version numbers? If so, what does the sender need to do, and what does the >> client need to do? (If there is a good example somewhere online I can work >> from that also.) >> >> My client application (javascript on browser) holds multiple types of >> data. It would be nice if I can send a notification saying "there's an >> update for this data type", rather than just "there's an update". Or, in >> general it'd be nice if I can send more information than just a >> monotonically increasing number. >> >> Here's my setup: >> >> >> - AeroGear Push Server 0.10.0 hosted on OpenShift. >> - Sender is a JBoss app using >> org.jboss.aerogear.unifiedpush.JavaSender >> (unifiedpush-java-client-0.5.0.jar). >> - Client is a web browser using aerogear.js 1.4.0. >> >> >> I read this documentation, >> but my wishful thinking refused to interpret it as saying: SimplePush >> variants use the "extra simple-push object" only. >> >> Thank you, >> >> Michi Oshima >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/f2a66375/attachment.html From scm.blanc at gmail.com Thu Apr 3 10:53:32 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 3 Apr 2014 16:53:32 +0200 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima wrote: > Hi Lucas, > > Following might do what I want (sending a "door bell" message in one shot > to all variants)? Send a unified message like the following one: > > > - '{ "message": { "version":"123" }, "simple-push": "version=123" }' > > > One slight deviation is that mobile variants like iOS and Android will get > the message regardless of whether the the version number is "old" or not. > Is this correct? > Yes iOS/Android ignore the version since that is really something tied to Simple Push > > So I revisited the SimplePush spec, > and I noticed it describes support for subscription to multiple channels. > > Aerogear doesn't allow multiple channels per installation, correct? I dug > up an old post from Matthias: > > > - > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none > > Well yes, but multiple installations can belong to the same SPS Client. You can register multiple time, differentiate them by passing them a category for instance. > > - > > > If an installation can subscribe to multiple channels, then it would allow > me to get what I originally asked about: > > Me: 'My client application (javascript on browser) holds multiple types > of data. It would be nice if I can send a notification saying "there's an > update for this data type", rather than just "there's an update". Or, in > general it'd be nice if I can send more information than just a > monotonically increasing number. ' > > > What do you think? > That would be quite a breaking change and we need to discuss that, in the same time, as said before, you can still register a single client to multiple channels (and es you will have multiple installations but that do not really matter) > > > > On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist wrote: > >> On Apr 2, 2014, at 11:38 AM, Michi Oshima wrote: >> >> Thanks, Lucas. I read the spec yesterday and ended up looking at >> disturbing auctions for 30 minutes. I'll read it again. >> >> Another question, is there a way to send a "door bell" message *in one >> shot* to all iOS, Android, and SimplePush variants? >> >> >> well, iOS and Android notifications aren't really doorbells, but you can >> send a "message" to all clients that are registered in your Push Server. >> >> we have a Java client >> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >> >> and a node.js client for this >> https://www.npmjs.org/package/aerogear-sender-client >> >> >> >> >> (m:) >> >> >> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist wrote: >> >>> SimplePush works only as a "door bell" to tell your app, hey, you >>> should go look on your server. >>> >>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>> >>> >>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>> wrote: >>> >>> Hi, >>> >>> Yesterday I managed to send my first message to a browser. Thanks for >>> all your help. >>> >>> I've tried sending a few different types of messages, and it so far >>> appears to me the only thing I can send to a simple push client is a >>> version number. Can a simple push client receive anything else other than >>> version numbers? If so, what does the sender need to do, and what does the >>> client need to do? (If there is a good example somewhere online I can work >>> from that also.) >>> >>> My client application (javascript on browser) holds multiple types of >>> data. It would be nice if I can send a notification saying "there's an >>> update for this data type", rather than just "there's an update". Or, in >>> general it'd be nice if I can send more information than just a >>> monotonically increasing number. >>> >>> Here's my setup: >>> >>> >>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>> - Sender is a JBoss app using >>> org.jboss.aerogear.unifiedpush.JavaSender >>> (unifiedpush-java-client-0.5.0.jar). >>> - Client is a web browser using aerogear.js 1.4.0. >>> >>> >>> I read this documentation, >>> but my wishful thinking refused to interpret it as saying: SimplePush >>> variants use the "extra simple-push object" only. >>> >>> Thank you, >>> >>> Michi Oshima >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/7048dcf8/attachment-0001.html From kpiwko at redhat.com Thu Apr 3 11:41:32 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 3 Apr 2014 17:41:32 +0200 Subject: [aerogear-dev] Community release checklists Message-ID: <20140403174132.78601ba0@kapy-ntb-x220> Hi, I've drafted a few checklists for QE to go through for community releases (UPS, OS Cart, Cordova Push Plugin). I've put them there: https://gist.github.com/kpiwko/9956724 Any feedback on their content is very welcomed. As for the location, I think the best way would be to put them directly into GH repositories, for instance into RELEASE.ad / RELEASE.md file, together with release process instructions (not existing yet). General testing instructions, applicable for any project, can go to aerogear-parent or aerogear-testing-tools and be crosslinked. Thoughts? Thanks, Karel From michi.oshima at gmail.com Thu Apr 3 14:03:54 2014 From: michi.oshima at gmail.com (Michi Oshima) Date: Thu, 3 Apr 2014 14:03:54 -0400 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Thank you, Sebastien. I'll try multiple registration. Although, I'm a bit confused. Because: 1. As far as I can see from the quick start example, per SPS Client, there'll be one registration with the SimplePush server. That means I only get one endpoint. 2. So I'd use the same endpoint to register multiple times with the unified push server using different category each time. 3. When the SPS client receives a version number, how can it associate a given version number to a particular category? (I've not seen categories reaching the client.) Am I wrong somewhere above? On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc wrote: > > > > On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima wrote: > >> Hi Lucas, >> >> Following might do what I want (sending a "door bell" message in one shot >> to all variants)? Send a unified message like the following one: >> >> >> - '{ "message": { "version":"123" }, "simple-push": "version=123" }' >> >> >> One slight deviation is that mobile variants like iOS and Android will >> get the message regardless of whether the the version number is "old" or >> not. Is this correct? >> > > Yes iOS/Android ignore the version since that is really something tied to > Simple Push > >> >> So I revisited the SimplePush spec, >> and I noticed it describes support for subscription to multiple channels. >> >> Aerogear doesn't allow multiple channels per installation, correct? I >> dug up an old post from Matthias: >> >> >> - >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >> >> Well yes, but multiple installations can belong to the same SPS Client. > You can register multiple time, differentiate them by passing them a > category for instance. > > >> >> - >> >> >> If an installation can subscribe to multiple channels, then it would >> allow me to get what I originally asked about: >> >> Me: 'My client application (javascript on browser) holds multiple types >> of data. It would be nice if I can send a notification saying "there's an >> update for this data type", rather than just "there's an update". Or, in >> general it'd be nice if I can send more information than just a >> monotonically increasing number. ' >> >> >> What do you think? >> > > That would be quite a breaking change and we need to discuss that, in the > same time, as said before, you can still register a single client to > multiple channels (and es you will have multiple installations but that do > not really matter) > > >> >> >> >> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist wrote: >> >>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>> wrote: >>> >>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>> disturbing auctions for 30 minutes. I'll read it again. >>> >>> Another question, is there a way to send a "door bell" message *in one >>> shot* to all iOS, Android, and SimplePush variants? >>> >>> >>> well, iOS and Android notifications aren't really doorbells, but you >>> can send a "message" to all clients that are registered in your Push Server. >>> >>> we have a Java client >>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>> >>> and a node.js client for this >>> https://www.npmjs.org/package/aerogear-sender-client >>> >>> >>> >>> >>> (m:) >>> >>> >>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist wrote: >>> >>>> SimplePush works only as a "door bell" to tell your app, hey, you >>>> should go look on your server. >>>> >>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>> >>>> >>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>> wrote: >>>> >>>> Hi, >>>> >>>> Yesterday I managed to send my first message to a browser. Thanks for >>>> all your help. >>>> >>>> I've tried sending a few different types of messages, and it so far >>>> appears to me the only thing I can send to a simple push client is a >>>> version number. Can a simple push client receive anything else other than >>>> version numbers? If so, what does the sender need to do, and what does the >>>> client need to do? (If there is a good example somewhere online I can work >>>> from that also.) >>>> >>>> My client application (javascript on browser) holds multiple types of >>>> data. It would be nice if I can send a notification saying "there's an >>>> update for this data type", rather than just "there's an update". Or, in >>>> general it'd be nice if I can send more information than just a >>>> monotonically increasing number. >>>> >>>> Here's my setup: >>>> >>>> >>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>> - Sender is a JBoss app using >>>> org.jboss.aerogear.unifiedpush.JavaSender >>>> (unifiedpush-java-client-0.5.0.jar). >>>> - Client is a web browser using aerogear.js 1.4.0. >>>> >>>> >>>> I read this documentation, >>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>> variants use the "extra simple-push object" only. >>>> >>>> Thank you, >>>> >>>> Michi Oshima >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/a9539ef1/attachment.html From michi.oshima at gmail.com Thu Apr 3 14:20:17 2014 From: michi.oshima at gmail.com (Michi Oshima) Date: Thu, 3 Apr 2014 14:20:17 -0400 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Sorry I should have just asked for help in doing what you recommend. An example, pseudo-code, or bullet points would help. Is it possible? On Thu, Apr 3, 2014 at 2:03 PM, Michi Oshima wrote: > Thank you, Sebastien. I'll try multiple registration. Although, I'm a > bit confused. Because: > > > 1. As far as I can see from the quick start example, > per SPS Client, there'll be one registration with the SimplePush server. > That means I only get one endpoint. > 2. So I'd use the same endpoint to register multiple times with the > unified push server using different category each time. > 3. When the SPS client receives a version number, how can it associate > a given version number to a particular category? (I've not seen categories > reaching the client.) > > > Am I wrong somewhere above? > > > > On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc wrote: > >> >> >> >> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima wrote: >> >>> Hi Lucas, >>> >>> Following might do what I want (sending a "door bell" message in one >>> shot to all variants)? Send a unified message like the following one: >>> >>> >>> - '{ "message": { "version":"123" }, "simple-push": "version=123" }' >>> >>> >>> One slight deviation is that mobile variants like iOS and Android will >>> get the message regardless of whether the the version number is "old" or >>> not. Is this correct? >>> >> >> Yes iOS/Android ignore the version since that is really something tied to >> Simple Push >> >>> >>> So I revisited the SimplePush spec, >>> and I noticed it describes support for subscription to multiple channels. >>> >>> Aerogear doesn't allow multiple channels per installation, correct? I >>> dug up an old post from Matthias: >>> >>> >>> - >>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>> >>> Well yes, but multiple installations can belong to the same SPS Client. >> You can register multiple time, differentiate them by passing them a >> category for instance. >> >> >>> >>> - >>> >>> >>> If an installation can subscribe to multiple channels, then it would >>> allow me to get what I originally asked about: >>> >>> Me: 'My client application (javascript on browser) holds multiple types >>> of data. It would be nice if I can send a notification saying "there's an >>> update for this data type", rather than just "there's an update". Or, in >>> general it'd be nice if I can send more information than just a >>> monotonically increasing number. ' >>> >>> >>> What do you think? >>> >> >> That would be quite a breaking change and we need to discuss that, in the >> same time, as said before, you can still register a single client to >> multiple channels (and es you will have multiple installations but that do >> not really matter) >> >> >>> >>> >>> >>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist wrote: >>> >>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>> wrote: >>>> >>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>> disturbing auctions for 30 minutes. I'll read it again. >>>> >>>> Another question, is there a way to send a "door bell" message *in one >>>> shot* to all iOS, Android, and SimplePush variants? >>>> >>>> >>>> well, iOS and Android notifications aren't really doorbells, but you >>>> can send a "message" to all clients that are registered in your Push Server. >>>> >>>> we have a Java client >>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>> >>>> and a node.js client for this >>>> https://www.npmjs.org/package/aerogear-sender-client >>>> >>>> >>>> >>>> >>>> (m:) >>>> >>>> >>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist wrote: >>>> >>>>> SimplePush works only as a "door bell" to tell your app, hey, you >>>>> should go look on your server. >>>>> >>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>> >>>>> >>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Yesterday I managed to send my first message to a browser. Thanks for >>>>> all your help. >>>>> >>>>> I've tried sending a few different types of messages, and it so far >>>>> appears to me the only thing I can send to a simple push client is a >>>>> version number. Can a simple push client receive anything else other than >>>>> version numbers? If so, what does the sender need to do, and what does the >>>>> client need to do? (If there is a good example somewhere online I can work >>>>> from that also.) >>>>> >>>>> My client application (javascript on browser) holds multiple types of >>>>> data. It would be nice if I can send a notification saying "there's an >>>>> update for this data type", rather than just "there's an update". Or, in >>>>> general it'd be nice if I can send more information than just a >>>>> monotonically increasing number. >>>>> >>>>> Here's my setup: >>>>> >>>>> >>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>> - Sender is a JBoss app using >>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>> (unifiedpush-java-client-0.5.0.jar). >>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>> >>>>> >>>>> I read this documentation, >>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>> variants use the "extra simple-push object" only. >>>>> >>>>> Thank you, >>>>> >>>>> Michi Oshima >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/1607055d/attachment-0001.html From scm.blanc at gmail.com Thu Apr 3 14:53:15 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 3 Apr 2014 20:53:15 +0200 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Looks at this more advanced example here https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js You will see that we register 2 times and we get 2 different endpoints. Then you have to keep somewhere a link between your endpoint and let's say the service you want to associate to , like using the localStorage : localStorage.setItem(theEndpoint, "scoreService"); Then when you receive a message, besides the version (which is btw not mandatory to be used) you also receive the channelId, then you can choose which service to call : navigator.setMessageHandler("push", function(message) { var myService = localStorage.get(message.channelID); //now based on this you can call your specific log }); I Hope this will help you. On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima wrote: > Thank you, Sebastien. I'll try multiple registration. Although, I'm a > bit confused. Because: > > > 1. As far as I can see from the quick start example, > per SPS Client, there'll be one registration with the SimplePush server. > That means I only get one endpoint. > 2. So I'd use the same endpoint to register multiple times with the > unified push server using different category each time. > 3. When the SPS client receives a version number, how can it associate > a given version number to a particular category? (I've not seen categories > reaching the client.) > > > Am I wrong somewhere above? > > > > On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc wrote: > >> >> >> >> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima wrote: >> >>> Hi Lucas, >>> >>> Following might do what I want (sending a "door bell" message in one >>> shot to all variants)? Send a unified message like the following one: >>> >>> >>> - '{ "message": { "version":"123" }, "simple-push": "version=123" }' >>> >>> >>> One slight deviation is that mobile variants like iOS and Android will >>> get the message regardless of whether the the version number is "old" or >>> not. Is this correct? >>> >> >> Yes iOS/Android ignore the version since that is really something tied to >> Simple Push >> >>> >>> So I revisited the SimplePush spec, >>> and I noticed it describes support for subscription to multiple channels. >>> >>> Aerogear doesn't allow multiple channels per installation, correct? I >>> dug up an old post from Matthias: >>> >>> >>> - >>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>> >>> Well yes, but multiple installations can belong to the same SPS Client. >> You can register multiple time, differentiate them by passing them a >> category for instance. >> >> >>> >>> - >>> >>> >>> If an installation can subscribe to multiple channels, then it would >>> allow me to get what I originally asked about: >>> >>> Me: 'My client application (javascript on browser) holds multiple types >>> of data. It would be nice if I can send a notification saying "there's an >>> update for this data type", rather than just "there's an update". Or, in >>> general it'd be nice if I can send more information than just a >>> monotonically increasing number. ' >>> >>> >>> What do you think? >>> >> >> That would be quite a breaking change and we need to discuss that, in the >> same time, as said before, you can still register a single client to >> multiple channels (and es you will have multiple installations but that do >> not really matter) >> >> >>> >>> >>> >>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist wrote: >>> >>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>> wrote: >>>> >>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>> disturbing auctions for 30 minutes. I'll read it again. >>>> >>>> Another question, is there a way to send a "door bell" message *in one >>>> shot* to all iOS, Android, and SimplePush variants? >>>> >>>> >>>> well, iOS and Android notifications aren't really doorbells, but you >>>> can send a "message" to all clients that are registered in your Push Server. >>>> >>>> we have a Java client >>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>> >>>> and a node.js client for this >>>> https://www.npmjs.org/package/aerogear-sender-client >>>> >>>> >>>> >>>> >>>> (m:) >>>> >>>> >>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist wrote: >>>> >>>>> SimplePush works only as a "door bell" to tell your app, hey, you >>>>> should go look on your server. >>>>> >>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>> >>>>> >>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Yesterday I managed to send my first message to a browser. Thanks for >>>>> all your help. >>>>> >>>>> I've tried sending a few different types of messages, and it so far >>>>> appears to me the only thing I can send to a simple push client is a >>>>> version number. Can a simple push client receive anything else other than >>>>> version numbers? If so, what does the sender need to do, and what does the >>>>> client need to do? (If there is a good example somewhere online I can work >>>>> from that also.) >>>>> >>>>> My client application (javascript on browser) holds multiple types of >>>>> data. It would be nice if I can send a notification saying "there's an >>>>> update for this data type", rather than just "there's an update". Or, in >>>>> general it'd be nice if I can send more information than just a >>>>> monotonically increasing number. >>>>> >>>>> Here's my setup: >>>>> >>>>> >>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>> - Sender is a JBoss app using >>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>> (unifiedpush-java-client-0.5.0.jar). >>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>> >>>>> >>>>> I read this documentation, >>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>> variants use the "extra simple-push object" only. >>>>> >>>>> Thank you, >>>>> >>>>> Michi Oshima >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140403/5fce977b/attachment.html From bruno at abstractj.org Fri Apr 4 03:55:28 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 4 Apr 2014 04:55:28 -0300 Subject: [aerogear-dev] Community release checklists In-Reply-To: <20140403174132.78601ba0@kapy-ntb-x220> References: <20140403174132.78601ba0@kapy-ntb-x220> Message-ID: Hi Karel, maybe I missed the purpose of the gist, but I only can see UPS and Cordova there. What about the projects on Android (aerogear-android, aerogear-otp-java, aerogear-crypto-java), JS (aerogear-js), iOS(aerogear-ios, aerogear-otp-ios, aerogear-crypto-ios) and also Simple Push Server? -- abstractj On April 3, 2014 at 12:41:41 PM, Karel Piwko (kpiwko at redhat.com) wrote: > > Hi, > > I've drafted a few checklists for QE to go through for community > releases > (UPS, OS Cart, Cordova Push Plugin). I've put them there: > > https://gist.github.com/kpiwko/9956724 > > Any feedback on their content is very welcomed. > As for the location, I think the best way would be to put them directly > into > GH repositories, for instance into RELEASE.ad / RELEASE.md > file, together with > release process instructions (not existing yet). General testing > instructions, > applicable for any project, can go to aerogear-parent or aerogear-testing-tools > and be crosslinked. > > Thoughts? > > Thanks, > > Karel From bruno at abstractj.org Fri Apr 4 04:00:44 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 4 Apr 2014 05:00:44 -0300 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> <565481F6-8324-4C20-9414-521C5C8866CE@redhat.com> Message-ID: My two cents here, change from 0.0.3 to 0.8 is a big jump, in my option. I would move to 0.1.0, or if you guys really want to move to 0.8, don?t drop the patch number and make it 0.8.0. -- abstractj On April 3, 2014 at 6:17:24 AM, Matthias Wessendorf (matzew at apache.org) wrote: > > let's wait a bit for the 1.0.0 ... but let's make it close to 1.0 > (e.g. 0.8 or something like that) From corinnekrych at gmail.com Fri Apr 4 04:01:18 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 4 Apr 2014 10:01:18 +0200 Subject: [aerogear-dev] Community release checklists In-Reply-To: References: <20140403174132.78601ba0@kapy-ntb-x220> Message-ID: Same question than abstractj, when doing iOS AeroGear 1.5 release I gisted this checklist. https://gist.github.com/corinnekrych/9504704 It might be helpfull to you ++ Corinne On 04 Apr 2014, at 09:55, Bruno Oliveira wrote: > Hi Karel, maybe I missed the purpose of the gist, but I only can see UPS and Cordova there. What about the projects on Android (aerogear-android, aerogear-otp-java, aerogear-crypto-java), JS (aerogear-js), iOS(aerogear-ios, aerogear-otp-ios, aerogear-crypto-ios) and also Simple Push Server? > > -- > abstractj > > On April 3, 2014 at 12:41:41 PM, Karel Piwko (kpiwko at redhat.com) wrote: >>> Hi, >> >> I've drafted a few checklists for QE to go through for community >> releases >> (UPS, OS Cart, Cordova Push Plugin). I've put them there: >> >> https://gist.github.com/kpiwko/9956724 >> >> Any feedback on their content is very welcomed. >> As for the location, I think the best way would be to put them directly >> into >> GH repositories, for instance into RELEASE.ad / RELEASE.md >> file, together with >> release process instructions (not existing yet). General testing >> instructions, >> applicable for any project, can go to aerogear-parent or aerogear-testing-tools >> and be crosslinked. >> >> Thoughts? >> >> Thanks, >> >> Karel > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From scm.blanc at gmail.com Fri Apr 4 04:02:25 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 4 Apr 2014 10:02:25 +0200 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Hey Michi, I realized that the code I pointed you to could be a bit confusing and also contains a small bug. I wrote this gist based on the quickstart example. Basically we register to 2 channels : mail and news, we store the channelID and map that with a String containing the service name, then in the onNotification we check which service to call : https://gist.github.com/sebastienblanc/9970129 Hope this example will make more sense ! Seb On Thu, Apr 3, 2014 at 8:53 PM, Sebastien Blanc wrote: > Looks at this more advanced example here > https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js > > > You will see that we register 2 times and we get 2 different endpoints. > Then you have to keep somewhere a link between your endpoint and let's say > the service you want to associate to , like using the localStorage : > localStorage.setItem(theEndpoint, "scoreService"); > > Then when you receive a message, besides the version (which is btw not > mandatory to be used) you also receive the channelId, then you can choose > which service to call : > > > navigator.setMessageHandler("push", function(message) { > var myService = localStorage.get(message.channelID); > //now based on this you can call your specific log > }); > > I Hope this will help you. > > > > > > On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima wrote: > >> Thank you, Sebastien. I'll try multiple registration. Although, I'm a >> bit confused. Because: >> >> >> 1. As far as I can see from the quick start example, >> per SPS Client, there'll be one registration with the SimplePush server. >> That means I only get one endpoint. >> 2. So I'd use the same endpoint to register multiple times with the >> unified push server using different category each time. >> 3. When the SPS client receives a version number, how can it >> associate a given version number to a particular category? (I've not seen >> categories reaching the client.) >> >> >> Am I wrong somewhere above? >> >> >> >> On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc wrote: >> >>> >>> >>> >>> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima wrote: >>> >>>> Hi Lucas, >>>> >>>> Following might do what I want (sending a "door bell" message in one >>>> shot to all variants)? Send a unified message like the following one: >>>> >>>> >>>> - '{ "message": { "version":"123" }, "simple-push": "version=123" }' >>>> >>>> >>>> One slight deviation is that mobile variants like iOS and Android will >>>> get the message regardless of whether the the version number is "old" or >>>> not. Is this correct? >>>> >>> >>> Yes iOS/Android ignore the version since that is really something tied >>> to Simple Push >>> >>>> >>>> So I revisited the SimplePush spec, >>>> and I noticed it describes support for subscription to multiple channels. >>>> >>>> Aerogear doesn't allow multiple channels per installation, correct? I >>>> dug up an old post from Matthias: >>>> >>>> >>>> - >>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>>> >>>> Well yes, but multiple installations can belong to the same SPS >>> Client. You can register multiple time, differentiate them by passing them >>> a category for instance. >>> >>> >>>> >>>> - >>>> >>>> >>>> If an installation can subscribe to multiple channels, then it would >>>> allow me to get what I originally asked about: >>>> >>>> Me: 'My client application (javascript on browser) holds multiple >>>> types of data. It would be nice if I can send a notification saying >>>> "there's an update for this data type", rather than just "there's an >>>> update". Or, in general it'd be nice if I can send more information than >>>> just a monotonically increasing number. ' >>>> >>>> >>>> What do you think? >>>> >>> >>> That would be quite a breaking change and we need to discuss that, in >>> the same time, as said before, you can still register a single client to >>> multiple channels (and es you will have multiple installations but that do >>> not really matter) >>> >>> >>>> >>>> >>>> >>>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist wrote: >>>> >>>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>>> wrote: >>>>> >>>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>>> disturbing auctions for 30 minutes. I'll read it again. >>>>> >>>>> Another question, is there a way to send a "door bell" message *in one >>>>> shot* to all iOS, Android, and SimplePush variants? >>>>> >>>>> >>>>> well, iOS and Android notifications aren't really doorbells, but you >>>>> can send a "message" to all clients that are registered in your Push Server. >>>>> >>>>> we have a Java client >>>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>> >>>>> and a node.js client for this >>>>> https://www.npmjs.org/package/aerogear-sender-client >>>>> >>>>> >>>>> >>>>> >>>>> (m:) >>>>> >>>>> >>>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist wrote: >>>>> >>>>>> SimplePush works only as a "door bell" to tell your app, hey, you >>>>>> should go look on your server. >>>>>> >>>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>>> >>>>>> >>>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Yesterday I managed to send my first message to a browser. Thanks >>>>>> for all your help. >>>>>> >>>>>> I've tried sending a few different types of messages, and it so far >>>>>> appears to me the only thing I can send to a simple push client is a >>>>>> version number. Can a simple push client receive anything else other than >>>>>> version numbers? If so, what does the sender need to do, and what does the >>>>>> client need to do? (If there is a good example somewhere online I can work >>>>>> from that also.) >>>>>> >>>>>> My client application (javascript on browser) holds multiple types of >>>>>> data. It would be nice if I can send a notification saying "there's an >>>>>> update for this data type", rather than just "there's an update". Or, in >>>>>> general it'd be nice if I can send more information than just a >>>>>> monotonically increasing number. >>>>>> >>>>>> Here's my setup: >>>>>> >>>>>> >>>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>>> - Sender is a JBoss app using >>>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>>> (unifiedpush-java-client-0.5.0.jar). >>>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>>> >>>>>> >>>>>> I read this documentation, >>>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>>> variants use the "extra simple-push object" only. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Michi Oshima >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/40b02834/attachment.html From matzew at apache.org Fri Apr 4 04:04:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Apr 2014 10:04:09 +0200 Subject: [aerogear-dev] Community release checklists In-Reply-To: References: <20140403174132.78601ba0@kapy-ntb-x220> Message-ID: On Fri, Apr 4, 2014 at 9:55 AM, Bruno Oliveira wrote: > Hi Karel, maybe I missed the purpose of the gist, but I only can see UPS > and Cordova there. What about the projects on Android (aerogear-android, > aerogear-otp-java, aerogear-crypto-java), JS (aerogear-js), > iOS(aerogear-ios, aerogear-otp-ios, aerogear-crypto-ios) and iOS-push SDK :-) but yeah, I feel the same: this document lacks a lot of our community projects. And they (e.g. iOS this week) have their regular releases as well > and also Simple Push Server? > > -- > abstractj > > On April 3, 2014 at 12:41:41 PM, Karel Piwko (kpiwko at redhat.com) wrote: > > > Hi, > > > > I've drafted a few checklists for QE to go through for community > > releases > > (UPS, OS Cart, Cordova Push Plugin). I've put them there: > > > > https://gist.github.com/kpiwko/9956724 > > > > Any feedback on their content is very welcomed. > > As for the location, I think the best way would be to put them directly > > into > > GH repositories, for instance into RELEASE.ad / RELEASE.md > > file, together with > > release process instructions (not existing yet). General testing > > instructions, > > applicable for any project, can go to aerogear-parent or > aerogear-testing-tools > > and be crosslinked. > > > > Thoughts? > > > > Thanks, > > > > Karel > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/6ec3a98e/attachment-0001.html From matzew at apache.org Fri Apr 4 04:10:36 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Apr 2014 10:10:36 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: <4436BEB0-067B-4FFE-8D4D-698C71D6E1E6@redhat.com> <565481F6-8324-4C20-9414-521C5C8866CE@redhat.com> Message-ID: On Fri, Apr 4, 2014 at 10:00 AM, Bruno Oliveira wrote: > My two cents here, change from 0.0.3 to 0.8 is a big jump, in my option. I > would move to 0.1.0, or if you guys really want to move to 0.8, don't drop > the patch number and make it 0.8.0. > perhaps something in between of 0.1.0 and 1.0.0 :) > > -- > abstractj > > On April 3, 2014 at 6:17:24 AM, Matthias Wessendorf (matzew at apache.org) > wrote: > > > let's wait a bit for the 1.0.0 ... but let's make it close to 1.0 > > (e.g. 0.8 or something like that) > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/7e24c7fb/attachment.html From bruno at abstractj.org Fri Apr 4 04:18:52 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 4 Apr 2014 05:18:52 -0300 Subject: [aerogear-dev] JS Team meet up highlights In-Reply-To: <6DE3B900-29B9-49B5-A461-A45A5235CFF3@redhat.com> References: <6DE3B900-29B9-49B5-A461-A45A5235CFF3@redhat.com> Message-ID: Hi Luke, answers inline. -- abstractj On April 2, 2014 at 12:06:54 PM, Lucas Holmquist (lholmqui at redhat.com) wrote: > JS Cool Team Stuff I liked the name > > 1.5.0 - Early May > > MQTT WS adapter > code cleanup > More Cookbook examples > https://issues.jboss.org/browse/AGJS-41 > UnifiedPushClient jQuery Removal > we need to polyfill it - pack that into client https://github.com/jakearchibald/es6-promise? +1 > 1.6.0 - Mid July > > Data Sync(?) I would say yes, and the primary focus (https://issues.jboss.org/browse/AEROGEAR-1462) Also, I reorganized our spec?https://github.com/aerogear/aerogear.org/pull/290. We must start simple, to move forward. > stalled, conversations started again > is going liveoak to work on data sync? No idea, maybe you should talk with Jay or Burr. > Keycloak(?) > keycloak examples mention private key in a client code I started a discussion here?http://lists.jboss.org/pipermail/keycloak-dev/2014-April/001621.html. Keycloak team don?t have any plans to change the server, but we can figure out together how to protect it, maybe, contribute back to the project. > 1.7.0 - Late September >? Please add encrypted cache, that?s a douchebag but at least we have to try. Probably Webcrypto (/me looking to the sky and praying) will be ready ?til there. > Offline(?) +1 Also add encrypted storage. > service workers? This ->?https://developer.mozilla.org/en-US/docs/Social_API/Service_worker_API_reference Seems cool, but I have no idea. > application cache is still a douchebag > 2.0.0 > > ES6 modules(?) - transpile > maybe include in 1.6/1.7 > we could leverage in custom builder, possibly > challenge: compatibility w/ AMD / commonjs (UMD?) YAY! > No jQuery Yay! > Current Road Map > > http://aerogear.org/docs/planning/roadmaps/AeroGearJS/ > 1.5.0 JIRA?s > > https://issues.jboss.org/issues/?jql=project%20%3D%20AGJS%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%221.5.0%22%20ORDER%20BY%20priority%20DESC > Random Stuff > > 2.0 collect ideas what people might struggle with? > > pipelines - frameworks use usually own stuff > improving documentation and getting started experience > > getting started with AG + particular web frameworks > > examples -> cookbook (complete stack) > move tests to jasmine or something other than qunit(?) - not sure what the benefit could > be > > https://issues.jboss.org/browse/AGJS-147 > move docs to something other than jsdoc, ex: yui doc - not sure what the benefit could be > > https://issues.jboss.org/browse/AGJS-143 > polymer components > > dataManager > dataSync > > authentication buttons Nice ideas. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Fri Apr 4 04:22:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Apr 2014 10:22:57 +0200 Subject: [aerogear-dev] [JavaScript] UnifiedPush client lib Message-ID: Hello, atm the ups.js bits need the complete URL for the device registration endpoint: UPClient = AeroGear.UnifiedPushClient(variantId, variantSecret, unifiedPushUrl + "/rest/registry/device"); The interesting part is, that the "/rest/registry/device" part is always the same (unless someone builds the server from scratch and changes all the URLs, but why should one do that?) On Android and iOS, the registration APIs, just require the "root url" (e.g. http(s)//host:port/contex). BTW. the JS bits for Cordova are following that same convention, see: http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_sample_example I was wondering if we should do the same on the CORE-JS library ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/7c6e5e1f/attachment.html From daniel.bevenius at gmail.com Fri Apr 4 04:24:02 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 4 Apr 2014 10:24:02 +0200 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Hi Michi, just wanted to chime in that the SimplePush server does support multiple registrations like Seb has described. If your clients have WebSocket support there will only be a single WebSocket connection and messages will flow over it. You can see the information that is returned from a registration here [1], and the format of the notification is described here [2]. If you'd like to verify the behaviour of the SimplePush Server there is a very basic client that I use for manual testing which you can try[3]. Using your browsers debug utilities you should be able to inspect the WebSocket frames and hence the information in the registrations and notifications. Hope this helps. Let us know if you have any other questions. Regards, /Dan [1] https://github.com/aerogear/aerogear-simplepush-server/tree/master/server-core#register [2] https://github.com/aerogear/aerogear-simplepush-server/tree/master/server-core#notification [3] https://github.com/aerogear/aerogear-simplepush-server/tree/master/server-netty#python-webserver On 4 April 2014 10:02, Sebastien Blanc wrote: > Hey Michi, > I realized that the code I pointed you to could be a bit confusing and > also contains a small bug. > > I wrote this gist based on the quickstart example. Basically we register > to 2 channels : mail and news, we store the channelID and map that with a > String containing the service name, then in the onNotification we check > which service to call : > > https://gist.github.com/sebastienblanc/9970129 > > Hope this example will make more sense ! > > Seb > > > > > On Thu, Apr 3, 2014 at 8:53 PM, Sebastien Blanc wrote: > >> Looks at this more advanced example here >> https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js >> >> >> You will see that we register 2 times and we get 2 different endpoints. >> Then you have to keep somewhere a link between your endpoint and let's say >> the service you want to associate to , like using the localStorage : >> localStorage.setItem(theEndpoint, "scoreService"); >> >> Then when you receive a message, besides the version (which is btw not >> mandatory to be used) you also receive the channelId, then you can choose >> which service to call : >> >> >> navigator.setMessageHandler("push", function(message) { >> >> var myService = localStorage.get(message.channelID); >> //now based on this you can call your specific log >> }); >> >> >> I Hope this will help you. >> >> >> >> >> >> On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima wrote: >> >>> Thank you, Sebastien. I'll try multiple registration. Although, I'm a >>> bit confused. Because: >>> >>> >>> 1. As far as I can see from the quick start example, >>> per SPS Client, there'll be one registration with the SimplePush server. >>> That means I only get one endpoint. >>> 2. So I'd use the same endpoint to register multiple times with the >>> unified push server using different category each time. >>> 3. When the SPS client receives a version number, how can it >>> associate a given version number to a particular category? (I've not seen >>> categories reaching the client.) >>> >>> >>> Am I wrong somewhere above? >>> >>> >>> >>> On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc wrote: >>> >>>> >>>> >>>> >>>> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima wrote: >>>> >>>>> Hi Lucas, >>>>> >>>>> Following might do what I want (sending a "door bell" message in one >>>>> shot to all variants)? Send a unified message like the following one: >>>>> >>>>> >>>>> - '{ "message": { "version":"123" }, "simple-push": "version=123" >>>>> }' >>>>> >>>>> >>>>> One slight deviation is that mobile variants like iOS and Android will >>>>> get the message regardless of whether the the version number is "old" or >>>>> not. Is this correct? >>>>> >>>> >>>> Yes iOS/Android ignore the version since that is really something tied >>>> to Simple Push >>>> >>>>> >>>>> So I revisited the SimplePush spec, >>>>> and I noticed it describes support for subscription to multiple channels. >>>>> >>>>> Aerogear doesn't allow multiple channels per installation, correct? I >>>>> dug up an old post from Matthias: >>>>> >>>>> >>>>> - >>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>>>> >>>>> Well yes, but multiple installations can belong to the same SPS >>>> Client. You can register multiple time, differentiate them by passing them >>>> a category for instance. >>>> >>>> >>>>> >>>>> - >>>>> >>>>> >>>>> If an installation can subscribe to multiple channels, then it would >>>>> allow me to get what I originally asked about: >>>>> >>>>> Me: 'My client application (javascript on browser) holds multiple >>>>> types of data. It would be nice if I can send a notification saying >>>>> "there's an update for this data type", rather than just "there's an >>>>> update". Or, in general it'd be nice if I can send more information than >>>>> just a monotonically increasing number. ' >>>>> >>>>> >>>>> What do you think? >>>>> >>>> >>>> That would be quite a breaking change and we need to discuss that, in >>>> the same time, as said before, you can still register a single client to >>>> multiple channels (and es you will have multiple installations but that do >>>> not really matter) >>>> >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist wrote: >>>>> >>>>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>>>> wrote: >>>>>> >>>>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>>>> disturbing auctions for 30 minutes. I'll read it again. >>>>>> >>>>>> Another question, is there a way to send a "door bell" message *in >>>>>> one shot* to all iOS, Android, and SimplePush variants? >>>>>> >>>>>> >>>>>> well, iOS and Android notifications aren't really doorbells, but you >>>>>> can send a "message" to all clients that are registered in your Push Server. >>>>>> >>>>>> we have a Java client >>>>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>> >>>>>> and a node.js client for this >>>>>> https://www.npmjs.org/package/aerogear-sender-client >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> (m:) >>>>>> >>>>>> >>>>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist >>>>> > wrote: >>>>>> >>>>>>> SimplePush works only as a "door bell" to tell your app, hey, you >>>>>>> should go look on your server. >>>>>>> >>>>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>>>> >>>>>>> >>>>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Yesterday I managed to send my first message to a browser. Thanks >>>>>>> for all your help. >>>>>>> >>>>>>> I've tried sending a few different types of messages, and it so far >>>>>>> appears to me the only thing I can send to a simple push client is a >>>>>>> version number. Can a simple push client receive anything else other than >>>>>>> version numbers? If so, what does the sender need to do, and what does the >>>>>>> client need to do? (If there is a good example somewhere online I can work >>>>>>> from that also.) >>>>>>> >>>>>>> My client application (javascript on browser) holds multiple types >>>>>>> of data. It would be nice if I can send a notification saying "there's an >>>>>>> update for this data type", rather than just "there's an update". Or, in >>>>>>> general it'd be nice if I can send more information than just a >>>>>>> monotonically increasing number. >>>>>>> >>>>>>> Here's my setup: >>>>>>> >>>>>>> >>>>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>>>> - Sender is a JBoss app using >>>>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>>>> (unifiedpush-java-client-0.5.0.jar). >>>>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>>>> >>>>>>> >>>>>>> I read this documentation, >>>>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>>>> variants use the "extra simple-push object" only. >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> Michi Oshima >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/43715902/attachment-0001.html From scm.blanc at gmail.com Fri Apr 4 05:04:30 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 4 Apr 2014 11:04:30 +0200 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Hey Again ! To make it even easier I've deployed a "multi-channel" version of the quickstart here : http://mutlichannels-sblanc.rhcloud.com/ Then you can fire the CURLs for each category to see how it can handle different channels : curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ "categories" :["mail"], "simple-push": "version=1111" }' https://hackergartenups-sblanc.rhcloud.com/rest/sender curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ "categories" :["news"], "simple-push": "version=1112" }' https://hackergartenups-sblanc.rhcloud.com/rest/sender If you fire these multiple time don't forget to change the version value ! On Fri, Apr 4, 2014 at 10:02 AM, Sebastien Blanc wrote: > Hey Michi, > I realized that the code I pointed you to could be a bit confusing and > also contains a small bug. > > I wrote this gist based on the quickstart example. Basically we register > to 2 channels : mail and news, we store the channelID and map that with a > String containing the service name, then in the onNotification we check > which service to call : > > https://gist.github.com/sebastienblanc/9970129 > > Hope this example will make more sense ! > > Seb > > > > > On Thu, Apr 3, 2014 at 8:53 PM, Sebastien Blanc wrote: > >> Looks at this more advanced example here >> https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js >> >> >> You will see that we register 2 times and we get 2 different endpoints. >> Then you have to keep somewhere a link between your endpoint and let's say >> the service you want to associate to , like using the localStorage : >> localStorage.setItem(theEndpoint, "scoreService"); >> >> Then when you receive a message, besides the version (which is btw not >> mandatory to be used) you also receive the channelId, then you can choose >> which service to call : >> >> >> navigator.setMessageHandler("push", function(message) { >> >> var myService = localStorage.get(message.channelID); >> //now based on this you can call your specific log >> }); >> >> >> I Hope this will help you. >> >> >> >> >> >> On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima wrote: >> >>> Thank you, Sebastien. I'll try multiple registration. Although, I'm a >>> bit confused. Because: >>> >>> >>> 1. As far as I can see from the quick start example, >>> per SPS Client, there'll be one registration with the SimplePush server. >>> That means I only get one endpoint. >>> 2. So I'd use the same endpoint to register multiple times with the >>> unified push server using different category each time. >>> 3. When the SPS client receives a version number, how can it >>> associate a given version number to a particular category? (I've not seen >>> categories reaching the client.) >>> >>> >>> Am I wrong somewhere above? >>> >>> >>> >>> On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc wrote: >>> >>>> >>>> >>>> >>>> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima wrote: >>>> >>>>> Hi Lucas, >>>>> >>>>> Following might do what I want (sending a "door bell" message in one >>>>> shot to all variants)? Send a unified message like the following one: >>>>> >>>>> >>>>> - '{ "message": { "version":"123" }, "simple-push": "version=123" >>>>> }' >>>>> >>>>> >>>>> One slight deviation is that mobile variants like iOS and Android will >>>>> get the message regardless of whether the the version number is "old" or >>>>> not. Is this correct? >>>>> >>>> >>>> Yes iOS/Android ignore the version since that is really something tied >>>> to Simple Push >>>> >>>>> >>>>> So I revisited the SimplePush spec, >>>>> and I noticed it describes support for subscription to multiple channels. >>>>> >>>>> Aerogear doesn't allow multiple channels per installation, correct? I >>>>> dug up an old post from Matthias: >>>>> >>>>> >>>>> - >>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>>>> >>>>> Well yes, but multiple installations can belong to the same SPS >>>> Client. You can register multiple time, differentiate them by passing them >>>> a category for instance. >>>> >>>> >>>>> >>>>> - >>>>> >>>>> >>>>> If an installation can subscribe to multiple channels, then it would >>>>> allow me to get what I originally asked about: >>>>> >>>>> Me: 'My client application (javascript on browser) holds multiple >>>>> types of data. It would be nice if I can send a notification saying >>>>> "there's an update for this data type", rather than just "there's an >>>>> update". Or, in general it'd be nice if I can send more information than >>>>> just a monotonically increasing number. ' >>>>> >>>>> >>>>> What do you think? >>>>> >>>> >>>> That would be quite a breaking change and we need to discuss that, in >>>> the same time, as said before, you can still register a single client to >>>> multiple channels (and es you will have multiple installations but that do >>>> not really matter) >>>> >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist wrote: >>>>> >>>>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>>>> wrote: >>>>>> >>>>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>>>> disturbing auctions for 30 minutes. I'll read it again. >>>>>> >>>>>> Another question, is there a way to send a "door bell" message *in >>>>>> one shot* to all iOS, Android, and SimplePush variants? >>>>>> >>>>>> >>>>>> well, iOS and Android notifications aren't really doorbells, but you >>>>>> can send a "message" to all clients that are registered in your Push Server. >>>>>> >>>>>> we have a Java client >>>>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>> >>>>>> and a node.js client for this >>>>>> https://www.npmjs.org/package/aerogear-sender-client >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> (m:) >>>>>> >>>>>> >>>>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist >>>>> > wrote: >>>>>> >>>>>>> SimplePush works only as a "door bell" to tell your app, hey, you >>>>>>> should go look on your server. >>>>>>> >>>>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>>>> >>>>>>> >>>>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Yesterday I managed to send my first message to a browser. Thanks >>>>>>> for all your help. >>>>>>> >>>>>>> I've tried sending a few different types of messages, and it so far >>>>>>> appears to me the only thing I can send to a simple push client is a >>>>>>> version number. Can a simple push client receive anything else other than >>>>>>> version numbers? If so, what does the sender need to do, and what does the >>>>>>> client need to do? (If there is a good example somewhere online I can work >>>>>>> from that also.) >>>>>>> >>>>>>> My client application (javascript on browser) holds multiple types >>>>>>> of data. It would be nice if I can send a notification saying "there's an >>>>>>> update for this data type", rather than just "there's an update". Or, in >>>>>>> general it'd be nice if I can send more information than just a >>>>>>> monotonically increasing number. >>>>>>> >>>>>>> Here's my setup: >>>>>>> >>>>>>> >>>>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>>>> - Sender is a JBoss app using >>>>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>>>> (unifiedpush-java-client-0.5.0.jar). >>>>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>>>> >>>>>>> >>>>>>> I read this documentation, >>>>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>>>> variants use the "extra simple-push object" only. >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> Michi Oshima >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/b5fd9e1c/attachment-0001.html From matzew at apache.org Fri Apr 4 05:13:46 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Apr 2014 11:13:46 +0200 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Hello Michi, IMO the version number string is a bit odd for most backend applications. :-) If you don't want to maintain a "version per channel", I'd just do the current timestamp (e.g. Date.now() in JS) -M On Fri, Apr 4, 2014 at 11:04 AM, Sebastien Blanc wrote: > Hey Again ! > > To make it even easier I've deployed a "multi-channel" version of the > quickstart here : http://mutlichannels-sblanc.rhcloud.com/ > Then you can fire the CURLs for each category to see how it can handle > different channels : > > curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ > "categories" :["mail"], > "simple-push": "version=1111" > > }' https://hackergartenups-sblanc.rhcloud.com/rest/sender > > > > curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ > > "categories" :["news"], > "simple-push": "version=1112" > }' https://hackergartenups-sblanc.rhcloud.com/rest/sender > > > If you fire these multiple time don't forget to change the version value ! > > > > > > On Fri, Apr 4, 2014 at 10:02 AM, Sebastien Blanc wrote: > >> Hey Michi, >> I realized that the code I pointed you to could be a bit confusing and >> also contains a small bug. >> >> I wrote this gist based on the quickstart example. Basically we register >> to 2 channels : mail and news, we store the channelID and map that with a >> String containing the service name, then in the onNotification we check >> which service to call : >> >> https://gist.github.com/sebastienblanc/9970129 >> >> Hope this example will make more sense ! >> >> Seb >> >> >> >> >> On Thu, Apr 3, 2014 at 8:53 PM, Sebastien Blanc wrote: >> >>> Looks at this more advanced example here >>> https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js >>> >>> >>> You will see that we register 2 times and we get 2 different endpoints. >>> Then you have to keep somewhere a link between your endpoint and let's say >>> the service you want to associate to , like using the localStorage : >>> localStorage.setItem(theEndpoint, "scoreService"); >>> >>> Then when you receive a message, besides the version (which is btw not >>> mandatory to be used) you also receive the channelId, then you can choose >>> which service to call : >>> >>> >>> navigator.setMessageHandler("push", function(message) { >>> >>> >>> var myService = localStorage.get(message.channelID); >>> //now based on this you can call your specific log >>> }); >>> >>> >>> >>> I Hope this will help you. >>> >>> >>> >>> >>> >>> On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima wrote: >>> >>>> Thank you, Sebastien. I'll try multiple registration. Although, I'm a >>>> bit confused. Because: >>>> >>>> >>>> 1. As far as I can see from the quick start example, >>>> per SPS Client, there'll be one registration with the SimplePush server. >>>> That means I only get one endpoint. >>>> 2. So I'd use the same endpoint to register multiple times with the >>>> unified push server using different category each time. >>>> 3. When the SPS client receives a version number, how can it >>>> associate a given version number to a particular category? (I've not seen >>>> categories reaching the client.) >>>> >>>> >>>> Am I wrong somewhere above? >>>> >>>> >>>> >>>> On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima wrote: >>>>> >>>>>> Hi Lucas, >>>>>> >>>>>> Following might do what I want (sending a "door bell" message in one >>>>>> shot to all variants)? Send a unified message like the following one: >>>>>> >>>>>> >>>>>> - '{ "message": { "version":"123" }, "simple-push": "version=123" >>>>>> }' >>>>>> >>>>>> >>>>>> One slight deviation is that mobile variants like iOS and Android >>>>>> will get the message regardless of whether the the version number is "old" >>>>>> or not. Is this correct? >>>>>> >>>>> >>>>> Yes iOS/Android ignore the version since that is really something tied >>>>> to Simple Push >>>>> >>>>>> >>>>>> So I revisited the SimplePush spec, >>>>>> and I noticed it describes support for subscription to multiple channels. >>>>>> >>>>>> Aerogear doesn't allow multiple channels per installation, correct? >>>>>> I dug up an old post from Matthias: >>>>>> >>>>>> >>>>>> - >>>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>>>>> >>>>>> Well yes, but multiple installations can belong to the same SPS >>>>> Client. You can register multiple time, differentiate them by passing them >>>>> a category for instance. >>>>> >>>>> >>>>>> >>>>>> - >>>>>> >>>>>> >>>>>> If an installation can subscribe to multiple channels, then it would >>>>>> allow me to get what I originally asked about: >>>>>> >>>>>> Me: 'My client application (javascript on browser) holds multiple >>>>>> types of data. It would be nice if I can send a notification saying >>>>>> "there's an update for this data type", rather than just "there's an >>>>>> update". Or, in general it'd be nice if I can send more information than >>>>>> just a monotonically increasing number. ' >>>>>> >>>>>> >>>>>> What do you think? >>>>>> >>>>> >>>>> That would be quite a breaking change and we need to discuss that, in >>>>> the same time, as said before, you can still register a single client to >>>>> multiple channels (and es you will have multiple installations but that do >>>>> not really matter) >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist >>>>> > wrote: >>>>>> >>>>>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>>>>> wrote: >>>>>>> >>>>>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>>>>> disturbing auctions for 30 minutes. I'll read it again. >>>>>>> >>>>>>> Another question, is there a way to send a "door bell" message *in >>>>>>> one shot* to all iOS, Android, and SimplePush variants? >>>>>>> >>>>>>> >>>>>>> well, iOS and Android notifications aren't really doorbells, but >>>>>>> you can send a "message" to all clients that are registered in your Push >>>>>>> Server. >>>>>>> >>>>>>> we have a Java client >>>>>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>>> >>>>>>> and a node.js client for this >>>>>>> https://www.npmjs.org/package/aerogear-sender-client >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> (m:) >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist < >>>>>>> lholmqui at redhat.com> wrote: >>>>>>> >>>>>>>> SimplePush works only as a "door bell" to tell your app, hey, you >>>>>>>> should go look on your server. >>>>>>>> >>>>>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>>>>> >>>>>>>> >>>>>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Yesterday I managed to send my first message to a browser. Thanks >>>>>>>> for all your help. >>>>>>>> >>>>>>>> I've tried sending a few different types of messages, and it so far >>>>>>>> appears to me the only thing I can send to a simple push client is a >>>>>>>> version number. Can a simple push client receive anything else other than >>>>>>>> version numbers? If so, what does the sender need to do, and what does the >>>>>>>> client need to do? (If there is a good example somewhere online I can work >>>>>>>> from that also.) >>>>>>>> >>>>>>>> My client application (javascript on browser) holds multiple types >>>>>>>> of data. It would be nice if I can send a notification saying "there's an >>>>>>>> update for this data type", rather than just "there's an update". Or, in >>>>>>>> general it'd be nice if I can send more information than just a >>>>>>>> monotonically increasing number. >>>>>>>> >>>>>>>> Here's my setup: >>>>>>>> >>>>>>>> >>>>>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>>>>> - Sender is a JBoss app using >>>>>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>>>>> (unifiedpush-java-client-0.5.0.jar). >>>>>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>>>>> >>>>>>>> >>>>>>>> I read this documentation, >>>>>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>>>>> variants use the "extra simple-push object" only. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> >>>>>>>> Michi Oshima >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/d832db2a/attachment-0001.html From kpiwko at redhat.com Fri Apr 4 06:35:30 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Fri, 4 Apr 2014 12:35:30 +0200 Subject: [aerogear-dev] Community release checklists In-Reply-To: References: <20140403174132.78601ba0@kapy-ntb-x220> Message-ID: <20140404123530.2dd00b3a@kapy-ntb-x220> On Fri, 4 Apr 2014 10:01:18 +0200 Corinne Krych wrote: > Same question than abstractj, when doing iOS AeroGear 1.5 release I gisted > this checklist. https://gist.github.com/corinnekrych/9504704 > It might be helpfull to you I've just drafted a few of them, as mentioned in my email to raise the discussion and gather more details about content and location of checklists. Thanks Corinne, I'll definitely use that information for iOS! > > ++ > Corinne > On 04 Apr 2014, at 09:55, Bruno Oliveira wrote: > > > Hi Karel, maybe I missed the purpose of the gist, but I only can see UPS > > and Cordova there. What about the projects on Android (aerogear-android, > > aerogear-otp-java, aerogear-crypto-java), JS (aerogear-js), > > iOS(aerogear-ios, aerogear-otp-ios, aerogear-crypto-ios) and also Simple > > Push Server? > > > > -- > > abstractj > > > > On April 3, 2014 at 12:41:41 PM, Karel Piwko (kpiwko at redhat.com) wrote: > >>> Hi, > >> > >> I've drafted a few checklists for QE to go through for community > >> releases > >> (UPS, OS Cart, Cordova Push Plugin). I've put them there: > >> > >> https://gist.github.com/kpiwko/9956724 > >> > >> Any feedback on their content is very welcomed. > >> As for the location, I think the best way would be to put them directly > >> into > >> GH repositories, for instance into RELEASE.ad / RELEASE.md > >> file, together with > >> release process instructions (not existing yet). General testing > >> instructions, > >> applicable for any project, can go to aerogear-parent or > >> aerogear-testing-tools and be crosslinked. > >> > >> Thoughts? > >> > >> Thanks, > >> > >> Karel > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From lholmqui at redhat.com Fri Apr 4 08:16:35 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 4 Apr 2014 08:16:35 -0400 Subject: [aerogear-dev] [JavaScript] UnifiedPush client lib In-Reply-To: References: Message-ID: On Apr 4, 2014, at 4:22 AM, Matthias Wessendorf wrote: > Hello, > > atm the ups.js bits need the complete URL for the device registration endpoint: > > > UPClient = AeroGear.UnifiedPushClient(variantId, variantSecret, unifiedPushUrl + "/rest/registry/device"); > > > The interesting part is, that the "/rest/registry/device" part is always the same (unless someone builds the server from scratch and changes all the URLs, but why should one do that?) > > On Android and iOS, the registration APIs, just require the "root url" (e.g. http(s)//host:port/contex). > > BTW. the JS bits for Cordova are following that same convention, see: > http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_sample_example > > I was wondering if we should do the same on the CORE-JS library ? this makes sense, i think it was probably left over from when we were doing development. let me JIRA that > > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/eb9ee9b1/attachment.html From lholmqui at redhat.com Fri Apr 4 08:27:08 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 4 Apr 2014 08:27:08 -0400 Subject: [aerogear-dev] [JavaScript] UnifiedPush client lib In-Reply-To: References: Message-ID: <4D468679-CD1F-4962-BCEA-AD897A2838AF@redhat.com> JIRA'd https://issues.jboss.org/browse/AGJS-158 On Apr 4, 2014, at 8:16 AM, Lucas Holmquist wrote: > > On Apr 4, 2014, at 4:22 AM, Matthias Wessendorf wrote: > >> Hello, >> >> atm the ups.js bits need the complete URL for the device registration endpoint: >> >> >> UPClient = AeroGear.UnifiedPushClient(variantId, variantSecret, unifiedPushUrl + "/rest/registry/device"); >> >> >> The interesting part is, that the "/rest/registry/device" part is always the same (unless someone builds the server from scratch and changes all the URLs, but why should one do that?) >> >> On Android and iOS, the registration APIs, just require the "root url" (e.g. http(s)//host:port/contex). >> >> BTW. the JS bits for Cordova are following that same convention, see: >> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_sample_example >> >> I was wondering if we should do the same on the CORE-JS library ? > > this makes sense, i think it was probably left over from when we were doing development. > > let me JIRA that > > >> >> >> -Matthias >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/13ada0fa/attachment.html From bruno at abstractj.org Fri Apr 4 09:49:53 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 4 Apr 2014 10:49:53 -0300 Subject: [aerogear-dev] Passphrase encryption - round III Message-ID: Good morning slackland, yesterday I had a hangout with Matthias and we agreed that the whole key agreement thing would bring more complexity from the developer?s pespective. That?s the reason why the client with airline was dropped. Here comes the new proposal:?https://gist.github.com/abstractj/ef1e3d53619796f4e87e # Passphrase encryption for UPS **Note**: This is NOT a replacement for SSL ## Scenario - Developers wants to upload passphrase and certificate for iOS variants. The passphrase must be stored encrypted and restored in clear while sending messages. ## Jira references - https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout with Matthias, we agreed that would complicate the developer's workflow. - https://issues.jboss.org/browse/AGPUSH-358 ## Proposal Today we can't guarantee that our developers will have an [HSM](http://en.wikipedia.org/wiki/Hardware_security_module) to manage encryption keys. Neither we can store the private keys in a separated database, for the push server. If somehow the database is compromised, private keys could be exposed and most of the sensitive data decrypted.? The suggestion is to make use of a *KDF function* per application to encrypt passphrases, not perfect, but helps (like we did in the past for password reset). Where encryption key means: ``` PK = PBKDF2(Secret Key, Salt) ``` *Secret Key*: In the ideal world, users would be required to provide a password for encryption. In this scenario we don't want them to be prompted to input the password, or add extra parameters to the UPS endpoints. So the suggestion is to provide secret key configured on the server and protected by the ACL's from the operating system *Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the server per application and stored into the database. ![](http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg) ### Secret key configuration The file can be generated and checked if something exists during the application start up. - config.properties ``` secret_key = "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ ? ? ? ? ? ? ? ?"18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" ``` or - config.json ``` {"secret_key":"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ ? ? ? ? ? ? ? ?"18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"} ?``` ### Sending push messages Passphrases must be reversible for Apple, that's why we make use of symmetric encryption here. ![](http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg) # REST API ## Register push app ```POST ? ?| ? ?rest/applications``` ### HTTP request? ? Remain unchanged? ### HTTP response? ? Remain unchanged ?? ## iOS Variant? ### HTTP request? ? Remain unchanged? ### HTTP response? ? Remain unchanged ## Sender? ### HTTP request? ? Remain unchanged? ### HTTP response? ? Remain unchanged # Clients? No changes at the client side. Thoughts? -- abstractj From kpiwko at redhat.com Fri Apr 4 11:07:21 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Fri, 4 Apr 2014 17:07:21 +0200 Subject: [aerogear-dev] Passphrase encryption - round III In-Reply-To: References: Message-ID: <20140404170721.7fc4e28d@kapy-ntb-x220> On Fri, 4 Apr 2014 10:49:53 -0300 Bruno Oliveira wrote: > Good morning slackland, yesterday I had a hangout with Matthias and we agreed > that the whole key agreement thing would bring more complexity from the > developer?s pespective. That?s the reason why the client with airline was > dropped. > > Here comes the new > proposal:?https://gist.github.com/abstractj/ef1e3d53619796f4e87e > > # Passphrase encryption for UPS > > **Note**: This is NOT a replacement for SSL > > ## Scenario > > - Developers wants to upload passphrase and certificate for iOS variants. The > passphrase must be stored encrypted and restored in clear while sending > messages. > > ## Jira references > > - https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout > with Matthias, we agreed that would complicate the developer's workflow. > - https://issues.jboss.org/browse/AGPUSH-358 > > ## Proposal > > Today we can't guarantee that our developers will have an > [HSM](http://en.wikipedia.org/wiki/Hardware_security_module) to manage > encryption keys. Neither we can store the private keys in a separated > database, for the push server. > > If somehow the database is compromised, private keys could be exposed and > most of the sensitive data decrypted.? > > The suggestion is to make use of a *KDF function* per application to encrypt > passphrases, not perfect, but helps (like we did in the past for password > reset). Where encryption key means: > > ``` > PK = PBKDF2(Secret Key, Salt) > ``` > > *Secret Key*: In the ideal world, users would be required to provide a > password for encryption. In this scenario we don't want them to be prompted > to input the password, or add extra parameters to the UPS endpoints. So the > suggestion is to provide secret key configured on the server and protected by > the ACL's from the operating system I believe this should be pluggable, not only FS based. For instance, on AS7/EAP/WF, you'd likely want to use Vault to store sensitive information: https://access.redhat.com/site/documentation//en-US/JBoss_Enterprise_Application_Platform/6.2/html/Security_Guide/sect-Password_Vaults_for_Sensitive_Strings.html On other containers/platforms, you might have different options. FileSystem is a good start, but flexibility of such mechanism rocks. > > *Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the > server per application and stored into the database. > > ![](http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg) > > ### Secret key configuration > > The file can be generated and checked if something exists during the > application start up. > > - config.properties > > ``` > secret_key = > "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ > "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" ``` > > or > > - config.json > > ``` > {"secret_key":"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" > \ "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"} > ?``` > > ### Sending push messages > > Passphrases must be reversible for Apple, that's why we make use of symmetric > encryption here. > > ![](http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg) > > # REST API > > > ## Register push app > > ```POST ? ?| ? ?rest/applications``` > > ### HTTP request? > > ? Remain unchanged? > > ### HTTP response? > > ? Remain unchanged > ?? > ## iOS Variant? > > ### HTTP request? > > ? Remain unchanged? > > ### HTTP response? > > ? Remain unchanged > > ## Sender? > > ### HTTP request? > > ? Remain unchanged? > > ### HTTP response? > > ? Remain unchanged > > > # Clients? > > No changes at the client side. > > > Thoughts? > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Fri Apr 4 12:22:12 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Apr 2014 18:22:12 +0200 Subject: [aerogear-dev] Passphrase encryption - round III In-Reply-To: References: Message-ID: Quick question: the config.json/property file is something the UPS generates, right ? User has not to build the WAR and put it into the application, right ? On Fri, Apr 4, 2014 at 3:49 PM, Bruno Oliveira wrote: > Good morning slackland, yesterday I had a hangout with Matthias and we > agreed that the whole key agreement thing would bring more complexity from > the developer's pespective. That's the reason why the client with airline > was dropped. > > Here comes the new proposal: > https://gist.github.com/abstractj/ef1e3d53619796f4e87e > > # Passphrase encryption for UPS > > **Note**: This is NOT a replacement for SSL > > ## Scenario > > - Developers wants to upload passphrase and certificate for iOS variants. > The passphrase must be stored encrypted and restored in clear while sending > messages. > > ## Jira references > > - https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout > with Matthias, we agreed that would complicate the developer's workflow. > - https://issues.jboss.org/browse/AGPUSH-358 > > ## Proposal > > Today we can't guarantee that our developers will have an [HSM]( > http://en.wikipedia.org/wiki/Hardware_security_module) to manage > encryption keys. Neither we can store the private keys in a separated > database, for the push server. > > If somehow the database is compromised, private keys could be exposed and > most of the sensitive data decrypted. > > The suggestion is to make use of a *KDF function* per application to > encrypt passphrases, not perfect, but helps (like we did in the past for > password reset). Where encryption key means: > > ``` > PK = PBKDF2(Secret Key, Salt) > ``` > > *Secret Key*: In the ideal world, users would be required to provide a > password for encryption. In this scenario we don't want them to be prompted > to input the password, or add extra parameters to the UPS endpoints. So the > suggestion is to provide secret key configured on the server and protected > by the ACL's from the operating system > > *Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the > server per application and stored into the database. > > ![]( > http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg > ) > > ### Secret key configuration > > The file can be generated and checked if something exists during the > application start up. > > - config.properties > > ``` > secret_key = > "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ > > "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" > ``` > > or > > - config.json > > ``` > {"secret_key":"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" > \ > > "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"} > ``` > > ### Sending push messages > > Passphrases must be reversible for Apple, that's why we make use of > symmetric encryption here. > > ![]( > http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg > ) > > # REST API > > > ## Register push app > > ```POST | rest/applications``` > > ### HTTP request > > Remain unchanged > > ### HTTP response > > Remain unchanged > > ## iOS Variant > > ### HTTP request > > Remain unchanged > > ### HTTP response > > Remain unchanged > > ## Sender > > ### HTTP request > > Remain unchanged > > ### HTTP response > > Remain unchanged > > > # Clients > > No changes at the client side. > > > Thoughts? > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/84f4e362/attachment.html From bruno at abstractj.org Fri Apr 4 13:21:37 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 04 Apr 2014 10:21:37 -0700 (PDT) Subject: [aerogear-dev] Passphrase encryption - round III In-Reply-To: References: Message-ID: <1396632096800.398767d3@Nodemailer> total korrekt!? abstractj On Fri, Apr 4, 2014 at 1:22 PM, Matthias Wessendorf wrote: > Quick question: the config.json/property file is something the UPS > generates, right ? User has not to build the WAR and put it into the > application, right ? > On Fri, Apr 4, 2014 at 3:49 PM, Bruno Oliveira wrote: >> Good morning slackland, yesterday I had a hangout with Matthias and we >> agreed that the whole key agreement thing would bring more complexity from >> the developer's pespective. That's the reason why the client with airline >> was dropped. >> >> Here comes the new proposal: >> https://gist.github.com/abstractj/ef1e3d53619796f4e87e >> >> # Passphrase encryption for UPS >> >> **Note**: This is NOT a replacement for SSL >> >> ## Scenario >> >> - Developers wants to upload passphrase and certificate for iOS variants. >> The passphrase must be stored encrypted and restored in clear while sending >> messages. >> >> ## Jira references >> >> - https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout >> with Matthias, we agreed that would complicate the developer's workflow. >> - https://issues.jboss.org/browse/AGPUSH-358 >> >> ## Proposal >> >> Today we can't guarantee that our developers will have an [HSM]( >> http://en.wikipedia.org/wiki/Hardware_security_module) to manage >> encryption keys. Neither we can store the private keys in a separated >> database, for the push server. >> >> If somehow the database is compromised, private keys could be exposed and >> most of the sensitive data decrypted. >> >> The suggestion is to make use of a *KDF function* per application to >> encrypt passphrases, not perfect, but helps (like we did in the past for >> password reset). Where encryption key means: >> >> ``` >> PK = PBKDF2(Secret Key, Salt) >> ``` >> >> *Secret Key*: In the ideal world, users would be required to provide a >> password for encryption. In this scenario we don't want them to be prompted >> to input the password, or add extra parameters to the UPS endpoints. So the >> suggestion is to provide secret key configured on the server and protected >> by the ACL's from the operating system >> >> *Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the >> server per application and stored into the database. >> >> ![]( >> http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg >> ) >> >> ### Secret key configuration >> >> The file can be generated and checked if something exists during the >> application start up. >> >> - config.properties >> >> ``` >> secret_key = >> "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ >> >> "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" >> ``` >> >> or >> >> - config.json >> >> ``` >> {"secret_key":"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" >> \ >> >> "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"} >> ``` >> >> ### Sending push messages >> >> Passphrases must be reversible for Apple, that's why we make use of >> symmetric encryption here. >> >> ![]( >> http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg >> ) >> >> # REST API >> >> >> ## Register push app >> >> ```POST | rest/applications``` >> >> ### HTTP request >> >> Remain unchanged >> >> ### HTTP response >> >> Remain unchanged >> >> ## iOS Variant >> >> ### HTTP request >> >> Remain unchanged >> >> ### HTTP response >> >> Remain unchanged >> >> ## Sender >> >> ### HTTP request >> >> Remain unchanged >> >> ### HTTP response >> >> Remain unchanged >> >> >> # Clients >> >> No changes at the client side. >> >> >> Thoughts? >> >> -- >> abstractj >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/d75b511e/attachment-0001.html From bruno at abstractj.org Fri Apr 4 13:22:25 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 04 Apr 2014 10:22:25 -0700 (PDT) Subject: [aerogear-dev] Passphrase encryption - round III In-Reply-To: <20140404170721.7fc4e28d@kapy-ntb-x220> References: <20140404170721.7fc4e28d@kapy-ntb-x220> Message-ID: <1396632145110.c4f9d984@Nodemailer> Cool, I'll look at this? abstractj On Fri, Apr 4, 2014 at 12:07 PM, Karel Piwko wrote: > On Fri, 4 Apr 2014 10:49:53 -0300 > Bruno Oliveira wrote: >> Good morning slackland, yesterday I had a hangout with Matthias and we agreed >> that the whole key agreement thing would bring more complexity from the >> developer?s pespective. That?s the reason why the client with airline was >> dropped. >> >> Here comes the new >> proposal:?https://gist.github.com/abstractj/ef1e3d53619796f4e87e >> >> # Passphrase encryption for UPS >> >> **Note**: This is NOT a replacement for SSL >> >> ## Scenario >> >> - Developers wants to upload passphrase and certificate for iOS variants. The >> passphrase must be stored encrypted and restored in clear while sending >> messages. >> >> ## Jira references >> >> - https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout >> with Matthias, we agreed that would complicate the developer's workflow. >> - https://issues.jboss.org/browse/AGPUSH-358 >> >> ## Proposal >> >> Today we can't guarantee that our developers will have an >> [HSM](http://en.wikipedia.org/wiki/Hardware_security_module) to manage >> encryption keys. Neither we can store the private keys in a separated >> database, for the push server. >> >> If somehow the database is compromised, private keys could be exposed and >> most of the sensitive data decrypted.? >> >> The suggestion is to make use of a *KDF function* per application to encrypt >> passphrases, not perfect, but helps (like we did in the past for password >> reset). Where encryption key means: >> >> ``` >> PK = PBKDF2(Secret Key, Salt) >> ``` >> >> *Secret Key*: In the ideal world, users would be required to provide a >> password for encryption. In this scenario we don't want them to be prompted >> to input the password, or add extra parameters to the UPS endpoints. So the >> suggestion is to provide secret key configured on the server and protected by >> the ACL's from the operating system > I believe this should be pluggable, not only FS based. For instance, on > AS7/EAP/WF, you'd likely want to use Vault to store sensitive information: > https://access.redhat.com/site/documentation//en-US/JBoss_Enterprise_Application_Platform/6.2/html/Security_Guide/sect-Password_Vaults_for_Sensitive_Strings.html > On other containers/platforms, you might have different options. FileSystem is a > good start, but flexibility of such mechanism rocks. >> >> *Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the >> server per application and stored into the database. >> >> ![](http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg) >> >> ### Secret key configuration >> >> The file can be generated and checked if something exists during the >> application start up. >> >> - config.properties >> >> ``` >> secret_key = >> "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ >> "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" ``` >> >> or >> >> - config.json >> >> ``` >> {"secret_key":"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" >> \ "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"} >> ?``` >> >> ### Sending push messages >> >> Passphrases must be reversible for Apple, that's why we make use of symmetric >> encryption here. >> >> ![](http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg) >> >> # REST API >> >> >> ## Register push app >> >> ```POST ? ?| ? ?rest/applications``` >> >> ### HTTP request? >> >> ? Remain unchanged? >> >> ### HTTP response? >> >> ? Remain unchanged >> ?? >> ## iOS Variant? >> >> ### HTTP request? >> >> ? Remain unchanged? >> >> ### HTTP response? >> >> ? Remain unchanged >> >> ## Sender? >> >> ### HTTP request? >> >> ? Remain unchanged? >> >> ### HTTP response? >> >> ? Remain unchanged >> >> >> # Clients? >> >> No changes at the client side. >> >> >> Thoughts? >> >> -- >> abstractj >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140404/cd7ac418/attachment.html From marceloheck at gmail.com Fri Apr 4 14:45:19 2014 From: marceloheck at gmail.com (marceloheck) Date: Fri, 4 Apr 2014 11:45:19 -0700 (PDT) Subject: [aerogear-dev] aerogear security and android In-Reply-To: References: <1394467743631-6703.post@n5.nabble.com> <1394558729969-6747.post@n5.nabble.com> <1394624522273-6750.post@n5.nabble.com> <1394642857598-6762.post@n5.nabble.com> Message-ID: <1396637119777-7335.post@n5.nabble.com> hello bruno thanks for the reply I tested what we did and managed to make it work on my program but the problem is with two users, one role simple and the other role admin different tablet a just login and get the rest, there is another login and get the rest when I go back to using the first has lost the use work for as many simultaneous users? -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-security-and-android-tp6703p7335.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Sat Apr 5 08:27:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 5 Apr 2014 14:27:22 +0200 Subject: [aerogear-dev] Passphrase encryption - round III In-Reply-To: References: Message-ID: +1 Oh, the same generated config file could be used for encrypting things for other variants (e.g. the Google API key), at a later time, right ? On Fri, Apr 4, 2014 at 3:49 PM, Bruno Oliveira wrote: > Good morning slackland, yesterday I had a hangout with Matthias and we > agreed that the whole key agreement thing would bring more complexity from > the developer's pespective. That's the reason why the client with airline > was dropped. > > Here comes the new proposal: > https://gist.github.com/abstractj/ef1e3d53619796f4e87e > > # Passphrase encryption for UPS > > **Note**: This is NOT a replacement for SSL > > ## Scenario > > - Developers wants to upload passphrase and certificate for iOS variants. > The passphrase must be stored encrypted and restored in clear while sending > messages. > > ## Jira references > > - https://issues.jboss.org/browse/AGPUSH-565 (*Dropped*). After a hangout > with Matthias, we agreed that would complicate the developer's workflow. > - https://issues.jboss.org/browse/AGPUSH-358 > > ## Proposal > > Today we can't guarantee that our developers will have an [HSM]( > http://en.wikipedia.org/wiki/Hardware_security_module) to manage > encryption keys. Neither we can store the private keys in a separated > database, for the push server. > > If somehow the database is compromised, private keys could be exposed and > most of the sensitive data decrypted. > > The suggestion is to make use of a *KDF function* per application to > encrypt passphrases, not perfect, but helps (like we did in the past for > password reset). Where encryption key means: > > ``` > PK = PBKDF2(Secret Key, Salt) > ``` > > *Secret Key*: In the ideal world, users would be required to provide a > password for encryption. In this scenario we don't want them to be prompted > to input the password, or add extra parameters to the UPS endpoints. So the > suggestion is to provide secret key configured on the server and protected > by the ACL's from the operating system > > *Salt*: 16 bytes non-deterministic used to encrypt/decrypt the data on the > server per application and stored into the database. > > ![]( > http://photon.abstractj.org/cdraw_460528_pixels_20140404_103644_20140404_103648.jpg > ) > > ### Secret key configuration > > The file can be generated and checked if something exists during the > application start up. > > - config.properties > > ``` > secret_key = > "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \ > > "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b" > ``` > > or > > - config.json > > ``` > {"secret_key":"d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" > \ > > "18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"} > ``` > > ### Sending push messages > > Passphrases must be reversible for Apple, that's why we make use of > symmetric encryption here. > > ![]( > http://photon.abstractj.org/cdraw_537346_pixels_20140404_104245_20140404_104247.jpg > ) > > # REST API > > > ## Register push app > > ```POST | rest/applications``` > > ### HTTP request > > Remain unchanged > > ### HTTP response > > Remain unchanged > > ## iOS Variant > > ### HTTP request > > Remain unchanged > > ### HTTP response > > Remain unchanged > > ## Sender > > ### HTTP request > > Remain unchanged > > ### HTTP response > > Remain unchanged > > > # Clients > > No changes at the client side. > > > Thoughts? > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140405/c10ad98d/attachment.html From matzew at apache.org Sat Apr 5 08:27:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 5 Apr 2014 14:27:52 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Using JBoss Logging ? Message-ID: Hello, right now we are using JUL for logging. That works fine, so far :-) However related projects (e.g. Keycloak / LiveOak) are using JBoss Logging. I somewhat feel that it's perhaps not a bad idea if we would use JBoss logging as well... I know there are a gazillion different Java logging frameworks out there (yikes), but my question is really: keep JUL or go with JBoss-Logging :) Thanks! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140405/94dc0fc1/attachment-0001.html From scm.blanc at gmail.com Sat Apr 5 14:50:07 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Sat, 5 Apr 2014 20:50:07 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Using JBoss Logging ? In-Reply-To: References: Message-ID: <50D16891-EA7E-4B30-A22A-78172203B7E5@gmail.com> +1 Envoy? de mon iPhone > Le 5 avr. 2014 ? 14:27, Matthias Wessendorf a ?crit : > > Hello, > > right now we are using JUL for logging. That works fine, so far :-) > > However related projects (e.g. Keycloak / LiveOak) are using JBoss Logging. I somewhat feel that it's perhaps not a bad idea if we would use JBoss logging as well... > > I know there are a gazillion different Java logging frameworks out there (yikes), but my question is really: keep JUL or go with JBoss-Logging :) > > > Thanks! > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140405/ab3a8514/attachment.html From bruno at abstractj.org Sat Apr 5 15:27:35 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Sat, 05 Apr 2014 12:27:35 -0700 (PDT) Subject: [aerogear-dev] [UnifiedPush Server] Using JBoss Logging ? In-Reply-To: References: Message-ID: <1396726054604.5010e572@Nodemailer> +1? abstractj On Sat, Apr 5, 2014 at 9:28 AM, Matthias Wessendorf wrote: > Hello, > right now we are using JUL for logging. That works fine, so far :-) > However related projects (e.g. Keycloak / LiveOak) are using JBoss Logging. > I somewhat feel that it's perhaps not a bad idea if we would use JBoss > logging as well... > I know there are a gazillion different Java logging frameworks out there > (yikes), but my question is really: keep JUL or go with JBoss-Logging :) > Thanks! > Matthias > -- > Matthias Wessendorf > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140405/9b4acceb/attachment.html From matzew at apache.org Mon Apr 7 01:17:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 07:17:01 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics Message-ID: Hello, for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. Overall, I see one major area of interest: *metrics around push messages being sent: - time of sending (using timezone of the server?) - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) - payload (the entire payload, including custom keys - not only alert, sound, badge etc) This is a nice feature, and would enrich the UPS. However, I can see also some interest around device specific metrics: Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). Something that would be interesting as well, might be the following data: - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) While the initial focus should be around the message related metrics, capturing some device data is nice too. Any thoughts ? -Matthias PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! [1] https://issues.jboss.org/browse/AGPUSH-116 [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/00728455/attachment.html From matzew at apache.org Mon Apr 7 01:19:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 07:19:38 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Using JBoss Logging ? In-Reply-To: <1396726054604.5010e572@Nodemailer> References: <1396726054604.5010e572@Nodemailer> Message-ID: cool created this JIRA to track the bits: https://issues.jboss.org/browse/AGPUSH-613 On Sat, Apr 5, 2014 at 9:27 PM, Bruno Oliveira wrote: > +1 > -- > abstractj > > > On Sat, Apr 5, 2014 at 9:28 AM, Matthias Wessendorf wrote: > >> Hello, >> >> right now we are using JUL for logging. That works fine, so far :-) >> >> However related projects (e.g. Keycloak / LiveOak) are using JBoss >> Logging. I somewhat feel that it's perhaps not a bad idea if we would use >> JBoss logging as well... >> >> I know there are a gazillion different Java logging frameworks out there >> (yikes), but my question is really: keep JUL or go with JBoss-Logging :) >> >> >> Thanks! >> Matthias >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/580f0c8b/attachment.html From scm.blanc at gmail.com Mon Apr 7 02:25:59 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 7 Apr 2014 08:25:59 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: References: Message-ID: Sounds good ! Some comments inline On Mon, Apr 7, 2014 at 7:17 AM, Matthias Wessendorf wrote: > Hello, > > for a first round of collection some more data around the usage of the > push server (aka analytics/metrics), I'd propose we keep it very simple. > > Overall, I see one major area of interest: > *metrics around push messages being sent: > - time of sending (using timezone of the server?) > - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, > categories,...)) > - payload (the entire payload, including custom keys - not only alert, > sound, badge etc) > + Response / Status of the submitted message I suppose (response status to the "sender" and info it's has been dispatched to the 3rd Push network) ? It would also be nice to see who has initiated the send request : cURL, backend app or Compose Message Page ? Not sure how to do this but could be useful IMO. > > > This is a nice feature, and would enrich the UPS. > For sure. But how will someone access these metrics ? Is the plan to have some kind of metric/usage page (with charts etc ...) on the console and/or just raw data in the form of json/xml/txt ? > > > However, I can see also some interest around device specific metrics: > > Today we obivously store all the registered devices, but we also remove > them from the database table if needed (to not send messages to phones that > would no longer receive them anyways). > > Something that would be interesting as well, might be the following data: > - how often was an app has reached the push server (note: every time the > app starts, the metadata of the server is being updated (see [2]) > - number of device-tokens / registrationIDs that have been removed, when > receiving errors from Apple/Google (see [3] or [4]) > - number of devices, that were activly removed using our APIs (supported > only on Android/SimplePush due to Apple policy, see [5]) > Yes, that is a tricky one even going beyond the scope of metrics. For instance with Android there is no way to unregister when you desinstall the app. > > > While the initial focus should be around the message related metrics, > capturing some device data is nice too. > > > Any thoughts ? > > -Matthias > > > PS: Oh, for the longer run(...), I'd also like to see metrics like "was > mobile app opened due to a push notification". BUT that also requires some > more work/reseach on the client Push SDKs. But seriously, this is not a > priority for the next few months! > > > > > [1] https://issues.jboss.org/browse/AGPUSH-116 > [2] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 > [3] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 > [4] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 > [5] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/d26e2d8a/attachment-0001.html From matzew at apache.org Mon Apr 7 02:36:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 08:36:23 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: References: Message-ID: On Mon, Apr 7, 2014 at 8:25 AM, Sebastien Blanc wrote: > Sounds good ! > Some comments inline > > > On Mon, Apr 7, 2014 at 7:17 AM, Matthias Wessendorf wrote: > >> Hello, >> >> for a first round of collection some more data around the usage of the >> push server (aka analytics/metrics), I'd propose we keep it very simple. >> >> Overall, I see one major area of interest: >> *metrics around push messages being sent: >> - time of sending (using timezone of the server?) >> - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, >> categories,...)) >> - payload (the entire payload, including custom keys - not only alert, >> sound, badge etc) >> > + Response / Status of the submitted message I suppose (response status to > the "sender" and info it's has been dispatched to the 3rd Push network) ? > It would also be nice to see who has initiated the send request : cURL, > backend app or Compose Message Page ? Not sure how to do this but could be > useful IMO. > >> >> >> This is a nice feature, and would enrich the UPS. >> > > For sure. But how will someone access these metrics ? Is the plan to have > some kind of metric/usage page (with charts etc ...) on the console and/or > just raw data in the form of json/xml/txt ? > Console, via REST endpoint. See this epic: https://issues.jboss.org/browse/AGPUSH-116 > >> >> However, I can see also some interest around device specific metrics: >> >> Today we obivously store all the registered devices, but we also remove >> them from the database table if needed (to not send messages to phones that >> would no longer receive them anyways). >> >> Something that would be interesting as well, might be the following data: >> - how often was an app has reached the push server (note: every time the >> app starts, the metadata of the server is being updated (see [2]) >> - number of device-tokens / registrationIDs that have been removed, when >> receiving errors from Apple/Google (see [3] or [4]) >> - number of devices, that were activly removed using our APIs (supported >> only on Android/SimplePush due to Apple policy, see [5]) >> > Yes, that is a tricky one even going beyond the scope of metrics. For > instance with Android there is no way to unregister when you desinstall the > app. > well, we have ways to capture that as well (see [4]). > >> >> While the initial focus should be around the message related metrics, >> capturing some device data is nice too. >> >> >> Any thoughts ? >> >> -Matthias >> >> >> PS: Oh, for the longer run(...), I'd also like to see metrics like "was >> mobile app opened due to a push notification". BUT that also requires some >> more work/reseach on the client Push SDKs. But seriously, this is not a >> priority for the next few months! >> >> >> >> >> [1] https://issues.jboss.org/browse/AGPUSH-116 >> [2] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 >> [3] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 >> [4] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 >> [5] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/00755ad2/attachment.html From daniel.bevenius at gmail.com Mon Apr 7 02:58:21 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 7 Apr 2014 08:58:21 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140407 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/abee59a7/attachment.html From kpiwko at redhat.com Mon Apr 7 03:31:12 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 7 Apr 2014 09:31:12 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Using JBoss Logging ? In-Reply-To: References: Message-ID: <20140407093112.7ab34985@kapy-ntb-x220> I like JUL because it has no dependencies, stable API (albeit not feature complete) and no class path clashes. If you go with JBoss Logging, what would be the strategy for: 1/ Running UPS on Server in application platform that does not provide JBoss Logging? 2/ JBossLogging version conflicts - WF provides version 3.2, UPS needs 3.1+ and KC needs 3.0+? Thanks, Karel On Sat, 5 Apr 2014 14:27:52 +0200 Matthias Wessendorf wrote: > Hello, > > right now we are using JUL for logging. That works fine, so far :-) > > However related projects (e.g. Keycloak / LiveOak) are using JBoss Logging. > I somewhat feel that it's perhaps not a bad idea if we would use JBoss > logging as well... > > I know there are a gazillion different Java logging frameworks out there > (yikes), but my question is really: keep JUL or go with JBoss-Logging :) > > > Thanks! > Matthias > From matzew at apache.org Mon Apr 7 03:49:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 09:49:52 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Using JBoss Logging ? In-Reply-To: <20140407093112.7ab34985@kapy-ntb-x220> References: <20140407093112.7ab34985@kapy-ntb-x220> Message-ID: Oh, yeah - those are valid concerns. Let's stick to JUL ? On Mon, Apr 7, 2014 at 9:31 AM, Karel Piwko wrote: > I like JUL because it has no dependencies, stable API (albeit not feature > complete) and no class path clashes. > > If you go with JBoss Logging, what would be the strategy for: > > 1/ Running UPS on Server in application platform that does not provide > JBoss > Logging? > 2/ JBossLogging version conflicts - WF provides version 3.2, UPS needs > 3.1+ and > KC needs 3.0+? > > Thanks, > > Karel > > > > On Sat, 5 Apr 2014 14:27:52 +0200 > Matthias Wessendorf wrote: > > > Hello, > > > > right now we are using JUL for logging. That works fine, so far :-) > > > > However related projects (e.g. Keycloak / LiveOak) are using JBoss > Logging. > > I somewhat feel that it's perhaps not a bad idea if we would use JBoss > > logging as well... > > > > I know there are a gazillion different Java logging frameworks out there > > (yikes), but my question is really: keep JUL or go with JBoss-Logging :) > > > > > > Thanks! > > Matthias > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/c6e71f0b/attachment.html From avibelli at redhat.com Mon Apr 7 04:53:48 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Mon, 7 Apr 2014 04:53:48 -0400 (EDT) Subject: [aerogear-dev] Creation of static library and framework for aerogear-push-ios-registration In-Reply-To: <184236802.2044867.1396626948670.JavaMail.zimbra@redhat.com> Message-ID: <1245166869.239034.1396860828464.JavaMail.zimbra@redhat.com> Hi all, for those who are not able or willing to use Cocoapods, it would be nice to distribute a static binary library of aerogear-push-ios-registration. In order to support multiple platforms without the need to create multiple configurations or build products, I think that the best way would be to create a universal binary (aka fat library) that contains the object code for both architectures (device + simulator) and the public headers files. Going further, from the universal library it could be possible to create a framework, that would bring everything together into one package (a directory with a known structure). Packaging a library as a framework simplifies things for developers because it not only provides a binary to link against but it includes all of the necessary header files to reference as well. I have tried to create a script that builds a universal static library first and then a framework (putting together some links [1],[2],[3],[4]), is anybody willing to help to check it and test the built bits inside the cordova-push-plugin? You can find the script here: https://github.com/vibe13/aerogear-push-ios-registration/blob/master/universal_lib-framework_build.sh The script should be placed inside the project root and run: ./universal_lib-framework_build.sh Thank you Andrea [1] http://www.meonbinary.com/2013/07/creating-universal-ios-framework [2] http://spin.atomicobject.com/2011/12/13/building-a-universal-framework-for-ios/ [3] https://github.com/jverkoey/iOS-Framework [4] http://www.cocoanetics.com/2010/04/making-your-own-iphone-frameworks/ From matzew at apache.org Mon Apr 7 05:08:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 11:08:48 +0200 Subject: [aerogear-dev] UnifiedPush roadmap Message-ID: Good morning folks! I propose the following update to the UnifiedPush Server roadmap: https://github.com/aerogear/aerogear.org/pull/293 If you have any concern, let me know! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/c8d7a55f/attachment-0001.html From edewit at redhat.com Mon Apr 7 05:37:58 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 7 Apr 2014 11:37:58 +0200 Subject: [aerogear-dev] Creation of static library and framework for aerogear-push-ios-registration In-Reply-To: <8F9ED9DA-504C-426E-B8FB-377171F74243@redhat.com> References: <1245166869.239034.1396860828464.JavaMail.zimbra@redhat.com> <8F9ED9DA-504C-426E-B8FB-377171F74243@redhat.com> Message-ID: <6A30793B-8075-4604-BFAB-096C07E86CC1@redhat.com> This error is because of the CONFIGURATION_BUILD_DIR try TARGET_BUILD_DIR instead On 7 Apr,2014, at 11:20 , Erik Jan de Wit wrote: > I?ve tried to build with this script but it doesn?t work. I was also in the progress of creating a script that would do exactly the same to release the push plugin and always include the latest aerogear-push-ios-registation release as a binary > > This is the error I get: > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: -dynamic not specified the following flags are invalid: -ObjC > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lPods > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lPods is not an object file (not allowed in a library) > Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool failed with exit code 1 > > > On 7 Apr,2014, at 10:53 , Andrea Vibelli wrote: > >> Hi all, >> for those who are not able or willing to use Cocoapods, it would be nice to distribute a static binary library of aerogear-push-ios-registration. >> In order to support multiple platforms without the need to create multiple configurations or build products, I think that the best way would be to create a universal binary (aka fat library) that contains the object code for both architectures (device + simulator) and the public headers files. >> >> Going further, from the universal library it could be possible to create a framework, that would bring everything together into one package (a directory with a known structure). Packaging a library as a framework simplifies things for developers because it not only provides a binary to link against but it includes all of the necessary header files to reference as well. >> >> I have tried to create a script that builds a universal static library first and then a framework (putting together some links [1],[2],[3],[4]), is anybody willing to help to check it and test the built bits inside the cordova-push-plugin? >> >> You can find the script here: https://github.com/vibe13/aerogear-push-ios-registration/blob/master/universal_lib-framework_build.sh >> >> The script should be placed inside the project root and run: ./universal_lib-framework_build.sh >> >> Thank you >> Andrea >> >> [1] http://www.meonbinary.com/2013/07/creating-universal-ios-framework >> [2] http://spin.atomicobject.com/2011/12/13/building-a-universal-framework-for-ios/ >> [3] https://github.com/jverkoey/iOS-Framework >> [4] http://www.cocoanetics.com/2010/04/making-your-own-iphone-frameworks/ >> >> >> >> >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/6b455ff0/attachment.html From edewit at redhat.com Mon Apr 7 05:20:22 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 7 Apr 2014 11:20:22 +0200 Subject: [aerogear-dev] Creation of static library and framework for aerogear-push-ios-registration In-Reply-To: <1245166869.239034.1396860828464.JavaMail.zimbra@redhat.com> References: <1245166869.239034.1396860828464.JavaMail.zimbra@redhat.com> Message-ID: <8F9ED9DA-504C-426E-B8FB-377171F74243@redhat.com> I?ve tried to build with this script but it doesn?t work. I was also in the progress of creating a script that would do exactly the same to release the push plugin and always include the latest aerogear-push-ios-registation release as a binary This is the error I get: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: -dynamic not specified the following flags are invalid: -ObjC /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lPods /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lPods is not an object file (not allowed in a library) Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool failed with exit code 1 On 7 Apr,2014, at 10:53 , Andrea Vibelli wrote: > Hi all, > for those who are not able or willing to use Cocoapods, it would be nice to distribute a static binary library of aerogear-push-ios-registration. > In order to support multiple platforms without the need to create multiple configurations or build products, I think that the best way would be to create a universal binary (aka fat library) that contains the object code for both architectures (device + simulator) and the public headers files. > > Going further, from the universal library it could be possible to create a framework, that would bring everything together into one package (a directory with a known structure). Packaging a library as a framework simplifies things for developers because it not only provides a binary to link against but it includes all of the necessary header files to reference as well. > > I have tried to create a script that builds a universal static library first and then a framework (putting together some links [1],[2],[3],[4]), is anybody willing to help to check it and test the built bits inside the cordova-push-plugin? > > You can find the script here: https://github.com/vibe13/aerogear-push-ios-registration/blob/master/universal_lib-framework_build.sh > > The script should be placed inside the project root and run: ./universal_lib-framework_build.sh > > Thank you > Andrea > > [1] http://www.meonbinary.com/2013/07/creating-universal-ios-framework > [2] http://spin.atomicobject.com/2011/12/13/building-a-universal-framework-for-ios/ > [3] https://github.com/jverkoey/iOS-Framework > [4] http://www.cocoanetics.com/2010/04/making-your-own-iphone-frameworks/ > > > > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/e8a6b10c/attachment.html From bsutter at redhat.com Mon Apr 7 08:09:01 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 7 Apr 2014 08:09:01 -0400 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: References: Message-ID: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf wrote: > Hello, > > for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. > > Overall, I see one major area of interest: > *metrics around push messages being sent: > - time of sending (using timezone of the server?) > - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) > - payload (the entire payload, including custom keys - not only alert, sound, badge etc) > As a developer, I wish to know if my 3 test devices all registered properly. As a developer, I wish to know if the push notification was sent to all 3 test devices properly (at least delivered to Apple/Google properly) As a developer, I would like to know what were my past messages As a push administrator, a business unit representative (e.g head of sales, warehouse manager) is going ask me if a particular message was sent to a particular user (alias) or user group (aliases or category). > > This is a nice feature, and would enrich the UPS. > > > However, I can see also some interest around device specific metrics: > > Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). I can see people wanting to just archive instead of delete those records - interesting data points would be: - any commonality in device type - a trend in date/time of removal - ratio of added/removed (user opted in vs out) Is it possible to distinguish between app uninstall vs push notification disable (where the app remains installed)? > > Something that would be interesting as well, might be the following data: > - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) would this be a good proxy for letting me know how often an end-user is using the app? > - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) > - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) > > > While the initial focus should be around the message related metrics, capturing some device data is nice too. > > > Any thoughts ? > > -Matthias > > > PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! > > > > > [1] https://issues.jboss.org/browse/AGPUSH-116 > [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 > [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 > [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 > [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/57d75c80/attachment-0001.html From bsutter at redhat.com Mon Apr 7 08:11:02 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 7 Apr 2014 08:11:02 -0400 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: References: Message-ID: On Apr 7, 2014, at 2:25 AM, Sebastien Blanc wrote: > Sounds good ! > Some comments inline > > > On Mon, Apr 7, 2014 at 7:17 AM, Matthias Wessendorf wrote: > Hello, > > for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. > > Overall, I see one major area of interest: > *metrics around push messages being sent: > - time of sending (using timezone of the server?) > - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) > - payload (the entire payload, including custom keys - not only alert, sound, badge etc) > + Response / Status of the submitted message I suppose (response status to the "sender" and info it's has been dispatched to the 3rd Push network) ? > It would also be nice to see who has initiated the send request : cURL, backend app or Compose Message Page ? Not sure how to do this but could be useful IMO. +1 organizations will wish to know how many, how often senders are sending (who might be abusing the system, who to chargeback) > > > This is a nice feature, and would enrich the UPS. > > For sure. But how will someone access these metrics ? Is the plan to have some kind of metric/usage page (with charts etc ...) on the console and/or just raw data in the form of json/xml/txt ? > > > However, I can see also some interest around device specific metrics: > > Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). > > Something that would be interesting as well, might be the following data: > - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) > - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) > - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) > Yes, that is a tricky one even going beyond the scope of metrics. For instance with Android there is no way to unregister when you desinstall the app. > > > While the initial focus should be around the message related metrics, capturing some device data is nice too. > > > Any thoughts ? > > -Matthias > > > PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! > > > > > [1] https://issues.jboss.org/browse/AGPUSH-116 > [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 > [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 > [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 > [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/9ba1cad7/attachment.html From miguel21op at gmail.com Mon Apr 7 08:16:19 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Mon, 7 Apr 2014 13:16:19 +0100 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> References: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> Message-ID: <7A42B7B1-39AB-426E-A8AF-5D369634AF65@gmail.com> I think developers must build their own back-ends and keep track of what they do. This will be always the more flexible solution. IMHO you must focus on the core of building a reliable and powerful push send service (includind the documentation part). Enviado do meu iPhone No dia 07/04/2014, ?s 13:09, Burr Sutter escreveu: > >> On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf wrote: >> >> Hello, >> >> for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. >> >> Overall, I see one major area of interest: >> *metrics around push messages being sent: >> - time of sending (using timezone of the server?) > >> - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) >> - payload (the entire payload, including custom keys - not only alert, sound, badge etc) > As a developer, I wish to know if my 3 test devices all registered properly. > As a developer, I wish to know if the push notification was sent to all 3 test devices properly (at least delivered to Apple/Google properly) > As a developer, I would like to know what were my past messages > As a push administrator, a business unit representative (e.g head of sales, warehouse manager) is going ask me if a particular message was sent to a particular user (alias) or user group (aliases or category). >> >> This is a nice feature, and would enrich the UPS. >> >> >> However, I can see also some interest around device specific metrics: >> >> Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). > I can see people wanting to just archive instead of delete those records - interesting data points would be: > - any commonality in device type > - a trend in date/time of removal > - ratio of added/removed (user opted in vs out) > > Is it possible to distinguish between app uninstall vs push notification disable (where the app remains installed)? > >> >> Something that would be interesting as well, might be the following data: >> - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) > would this be a good proxy for letting me know how often an end-user is using the app? >> - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) >> - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) >> >> >> While the initial focus should be around the message related metrics, capturing some device data is nice too. >> >> >> Any thoughts ? >> >> -Matthias >> >> >> PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! >> >> >> >> >> [1] https://issues.jboss.org/browse/AGPUSH-116 >> [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 >> [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 >> [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 >> [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/538b408c/attachment.html From bruno at abstractj.org Mon Apr 7 08:24:05 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 7 Apr 2014 09:24:05 -0300 Subject: [aerogear-dev] Passphrase encryption - round III In-Reply-To: References: Message-ID: Correct -- abstractj On April 5, 2014 at 9:27:31 AM, Matthias Wessendorf (matzew at apache.org) wrote: > > Oh, the same generated config file could be used for encrypting > things for other variants (e.g. the Google API key), at a later > time, right ? From bsutter at redhat.com Mon Apr 7 08:28:59 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 7 Apr 2014 08:28:59 -0400 Subject: [aerogear-dev] [UnifiedPush Server] Using JBoss Logging ? In-Reply-To: References: <20140407093112.7ab34985@kapy-ntb-x220> Message-ID: I can see UPS needing to run on other containers (Tomcat, WF Core, etc) and I was assuming that JBoss Logging could be picked and carried around like other logging frameworks. On Apr 7, 2014, at 3:49 AM, Matthias Wessendorf wrote: > Oh, yeah - those are valid concerns. > > Let's stick to JUL ? > > > > > On Mon, Apr 7, 2014 at 9:31 AM, Karel Piwko wrote: > I like JUL because it has no dependencies, stable API (albeit not feature > complete) and no class path clashes. > > If you go with JBoss Logging, what would be the strategy for: > > 1/ Running UPS on Server in application platform that does not provide JBoss > Logging? > 2/ JBossLogging version conflicts - WF provides version 3.2, UPS needs 3.1+ and > KC needs 3.0+? > > Thanks, > > Karel > > > > On Sat, 5 Apr 2014 14:27:52 +0200 > Matthias Wessendorf wrote: > > > Hello, > > > > right now we are using JUL for logging. That works fine, so far :-) > > > > However related projects (e.g. Keycloak / LiveOak) are using JBoss Logging. > > I somewhat feel that it's perhaps not a bad idea if we would use JBoss > > logging as well... > > > > I know there are a gazillion different Java logging frameworks out there > > (yikes), but my question is really: keep JUL or go with JBoss-Logging :) > > > > > > Thanks! > > Matthias > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/3b6669d9/attachment.html From matzew at apache.org Mon Apr 7 08:31:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 14:31:22 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Using JBoss Logging ? In-Reply-To: References: <20140407093112.7ab34985@kapy-ntb-x220> Message-ID: JUL it is ;-) unless we are forced to not use JUL ;-) On Mon, Apr 7, 2014 at 2:28 PM, Burr Sutter wrote: > I can see UPS needing to run on other containers (Tomcat, WF Core, etc) > and I was assuming that JBoss Logging could be picked and carried around > like other logging frameworks. > > > > On Apr 7, 2014, at 3:49 AM, Matthias Wessendorf wrote: > > Oh, yeah - those are valid concerns. > > Let's stick to JUL ? > > > > > On Mon, Apr 7, 2014 at 9:31 AM, Karel Piwko wrote: > >> I like JUL because it has no dependencies, stable API (albeit not feature >> complete) and no class path clashes. >> >> If you go with JBoss Logging, what would be the strategy for: >> >> 1/ Running UPS on Server in application platform that does not provide >> JBoss >> Logging? >> 2/ JBossLogging version conflicts - WF provides version 3.2, UPS needs >> 3.1+ and >> KC needs 3.0+? >> >> Thanks, >> >> Karel >> >> >> >> On Sat, 5 Apr 2014 14:27:52 +0200 >> Matthias Wessendorf wrote: >> >> > Hello, >> > >> > right now we are using JUL for logging. That works fine, so far :-) >> > >> > However related projects (e.g. Keycloak / LiveOak) are using JBoss >> Logging. >> > I somewhat feel that it's perhaps not a bad idea if we would use JBoss >> > logging as well... >> > >> > I know there are a gazillion different Java logging frameworks out there >> > (yikes), but my question is really: keep JUL or go with JBoss-Logging :) >> > >> > >> > Thanks! >> > Matthias >> > >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/73a1bf1b/attachment.html From bsutter at redhat.com Mon Apr 7 08:37:31 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 7 Apr 2014 08:37:31 -0400 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: <7A42B7B1-39AB-426E-A8AF-5D369634AF65@gmail.com> References: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> <7A42B7B1-39AB-426E-A8AF-5D369634AF65@gmail.com> Message-ID: On Apr 7, 2014, at 8:16 AM, Miguel Lemos wrote: > I think developers must build their own back-ends and keep track of what they do. While I agree in theory, it is more difficult in practice. A single push server may be used by several developers across several different app teams, in that case, you will want some metrics/logging captured at the central point. Any given developer/team may misbehave quite badly. Our experience with multi-developer services has demonstrated that customers like having centralized logging/metric capture. > > This will be always the more flexible solution. > > IMHO you must focus on the core of building a reliable and powerful push send service (includind the documentation part). > > Enviado do meu iPhone > > No dia 07/04/2014, ?s 13:09, Burr Sutter escreveu: > >> >> On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf wrote: >> >>> Hello, >>> >>> for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. >>> >>> Overall, I see one major area of interest: >>> *metrics around push messages being sent: >>> - time of sending (using timezone of the server?) >> >>> - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) >>> - payload (the entire payload, including custom keys - not only alert, sound, badge etc) >>> >> As a developer, I wish to know if my 3 test devices all registered properly. >> As a developer, I wish to know if the push notification was sent to all 3 test devices properly (at least delivered to Apple/Google properly) >> As a developer, I would like to know what were my past messages >> As a push administrator, a business unit representative (e.g head of sales, warehouse manager) is going ask me if a particular message was sent to a particular user (alias) or user group (aliases or category). >>> >>> This is a nice feature, and would enrich the UPS. >>> >>> >>> However, I can see also some interest around device specific metrics: >>> >>> Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). >> I can see people wanting to just archive instead of delete those records - interesting data points would be: >> - any commonality in device type >> - a trend in date/time of removal >> - ratio of added/removed (user opted in vs out) >> >> Is it possible to distinguish between app uninstall vs push notification disable (where the app remains installed)? >> >>> >>> Something that would be interesting as well, might be the following data: >>> - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) >> would this be a good proxy for letting me know how often an end-user is using the app? >>> - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) >>> - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) >>> >>> >>> While the initial focus should be around the message related metrics, capturing some device data is nice too. >>> >>> >>> Any thoughts ? >>> >>> -Matthias >>> >>> >>> PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! >>> >>> >>> >>> >>> [1] https://issues.jboss.org/browse/AGPUSH-116 >>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 >>> [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 >>> [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 >>> [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/0ab9aa47/attachment-0001.html From matzew at apache.org Mon Apr 7 08:44:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 14:44:21 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: the GH repos have been created: * https://github.com/aerogear/aerogear-push-helloworld * https://github.com/aerogear/aerogear-push-quickstarts I edited the README to 'define' the (sub)folder structure On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf wrote: > Hello, > > here are the JIRAs (tasks and epics (which have sub-tasks) for this, so > far: > > Github repo work: > https://issues.jboss.org/browse/AGPUSH-586 > https://issues.jboss.org/browse/AGPUSH-587 > > Hello-World Example work (epic): > https://issues.jboss.org/browse/AGPUSH-588 > > > Quickstart-server (epic): > https://issues.jboss.org/browse/AGPUSH-596 > > Quickstart-client (epic): > https://issues.jboss.org/browse/AGPUSH-604 > > > > It's totally valid to: > - add more sub-tasks, or break sub-tasks out into epics (e.g. if they have > several work units). > > > Greetings, > Matthias > > > > > > > > > > On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf wrote: > >> Hello there, >> >> we recently had talks about creating some simplified quickstarts and >> hello-word demos, related to the UnifiedPush Server and JBoss AS developers: >> >> * Hello World (No Server Code - just client receiving push, no fancy >> (complex) UI on the client, nor integrated into a Cookbook or something >> that has "dependencies") >> ** Cordova >> ** Android >> >> For iOS that is already there: >> https://github.com/aerogear/aerogear-push-ios-demo >> >> Yes, just usage of the "Push Registration SDKs", is the goal here: keep >> it simple, since native push can be a complicated use-case all on its own >> and so it will be good to make sure we cover the basics here. >> >> >> Beyond the Hello-World, we wanted some different quickstarts. The >> "server" components that come to mind would be: >> >> *Secured CRUD + Push Integration (Java Sender) >> ** JAX-RS + PicketLink >> ** SpringMVC/Spring Security >> ** JAX-RS + Apache Camel >> >> These need to function on both JBoss AS 7.X and EAP. >> >> Josh, from the JDF team, has already said he wants to help on the server >> projects (especially the JAX-RS/PL and Spring ones). yay! >> Note: Josh already has a simple backend started that is used in JDF >> quickstarts that would be good to re-use to make it easier for developers >> to transition from one to other. >> >> >> The goal would be the SERVER acts same to outside (identical REST >> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >> Camel)) >> >> For these different servers, there would be mobile apps needed: >> * Android >> * Cordova >> * iOS >> >> >> The idea would be to keep them simple and straightforward as well, e.g. >> for iOS that means plain usage of NSURLConnection / NSURLSession. But for >> the "push registration" of the client, >> the iOS-push SDK would be used (same/similar would apply to Cordova or >> Android). Similar to the above 'Hello World', the quickstarts are going to >> be focused only on Push functionality, so for these we would leave out >> pipes and such until later versions. >> >> >> I will be creating Epics and subtasks in JIRA for this. >> >> For the location of all these projects, I had this "uber repo" location >> in mind: >> * https://github.com/aerogear/aerogear-push-helloworld >> * https://github.com/aerogear/aerogear-push-quickstarts >> >> Greetings, >> Matthias >> >> >> >> -- >> 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/cffa33c1/attachment.html From matzew at apache.org Mon Apr 7 08:54:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 14:54:09 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: Since we start w/ the Hello World example, let's make sure we agree on a name :-) I'd suggest we name it "AeroGear UnifiedPush HelloWorld". For packages / bundle Identifier, I'd vote for "org.jboss.aerogear.unifiedpush.HelloWorld" -Matthias On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf wrote: > the GH repos have been created: > * https://github.com/aerogear/aerogear-push-helloworld > * https://github.com/aerogear/aerogear-push-quickstarts > > I edited the README to 'define' the (sub)folder structure > > > > On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf wrote: > >> Hello, >> >> here are the JIRAs (tasks and epics (which have sub-tasks) for this, so >> far: >> >> Github repo work: >> https://issues.jboss.org/browse/AGPUSH-586 >> https://issues.jboss.org/browse/AGPUSH-587 >> >> Hello-World Example work (epic): >> https://issues.jboss.org/browse/AGPUSH-588 >> >> >> Quickstart-server (epic): >> https://issues.jboss.org/browse/AGPUSH-596 >> >> Quickstart-client (epic): >> https://issues.jboss.org/browse/AGPUSH-604 >> >> >> >> It's totally valid to: >> - add more sub-tasks, or break sub-tasks out into epics (e.g. if they >> have several work units). >> >> >> Greetings, >> Matthias >> >> >> >> >> >> >> >> >> >> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf wrote: >> >>> Hello there, >>> >>> we recently had talks about creating some simplified quickstarts and >>> hello-word demos, related to the UnifiedPush Server and JBoss AS developers: >>> >>> * Hello World (No Server Code - just client receiving push, no fancy >>> (complex) UI on the client, nor integrated into a Cookbook or something >>> that has "dependencies") >>> ** Cordova >>> ** Android >>> >>> For iOS that is already there: >>> https://github.com/aerogear/aerogear-push-ios-demo >>> >>> Yes, just usage of the "Push Registration SDKs", is the goal here: keep >>> it simple, since native push can be a complicated use-case all on its own >>> and so it will be good to make sure we cover the basics here. >>> >>> >>> Beyond the Hello-World, we wanted some different quickstarts. The >>> "server" components that come to mind would be: >>> >>> *Secured CRUD + Push Integration (Java Sender) >>> ** JAX-RS + PicketLink >>> ** SpringMVC/Spring Security >>> ** JAX-RS + Apache Camel >>> >>> These need to function on both JBoss AS 7.X and EAP. >>> >>> Josh, from the JDF team, has already said he wants to help on the server >>> projects (especially the JAX-RS/PL and Spring ones). yay! >>> Note: Josh already has a simple backend started that is used in JDF >>> quickstarts that would be good to re-use to make it easier for developers >>> to transition from one to other. >>> >>> >>> The goal would be the SERVER acts same to outside (identical REST >>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>> Camel)) >>> >>> For these different servers, there would be mobile apps needed: >>> * Android >>> * Cordova >>> * iOS >>> >>> >>> The idea would be to keep them simple and straightforward as well, e.g. >>> for iOS that means plain usage of NSURLConnection / NSURLSession. But for >>> the "push registration" of the client, >>> the iOS-push SDK would be used (same/similar would apply to Cordova or >>> Android). Similar to the above 'Hello World', the quickstarts are going to >>> be focused only on Push functionality, so for these we would leave out >>> pipes and such until later versions. >>> >>> >>> I will be creating Epics and subtasks in JIRA for this. >>> >>> For the location of all these projects, I had this "uber repo" location >>> in mind: >>> * https://github.com/aerogear/aerogear-push-helloworld >>> * https://github.com/aerogear/aerogear-push-quickstarts >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> -- >>> 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 >> > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/4b32e9a3/attachment.html From scm.blanc at gmail.com Mon Apr 7 08:57:47 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 7 Apr 2014 14:57:47 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: +1 On Mon, Apr 7, 2014 at 2:54 PM, Matthias Wessendorf wrote: > Since we start w/ the Hello World example, let's make sure we agree on a > name :-) > > I'd suggest we name it "AeroGear UnifiedPush HelloWorld". > > For packages / bundle Identifier, I'd vote for > "org.jboss.aerogear.unifiedpush.HelloWorld" > > > -Matthias > > > On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf wrote: > >> the GH repos have been created: >> * https://github.com/aerogear/aerogear-push-helloworld >> * https://github.com/aerogear/aerogear-push-quickstarts >> >> I edited the README to 'define' the (sub)folder structure >> >> >> >> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf wrote: >> >>> Hello, >>> >>> here are the JIRAs (tasks and epics (which have sub-tasks) for this, so >>> far: >>> >>> Github repo work: >>> https://issues.jboss.org/browse/AGPUSH-586 >>> https://issues.jboss.org/browse/AGPUSH-587 >>> >>> Hello-World Example work (epic): >>> https://issues.jboss.org/browse/AGPUSH-588 >>> >>> >>> Quickstart-server (epic): >>> https://issues.jboss.org/browse/AGPUSH-596 >>> >>> Quickstart-client (epic): >>> https://issues.jboss.org/browse/AGPUSH-604 >>> >>> >>> >>> It's totally valid to: >>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if they >>> have several work units). >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf wrote: >>> >>>> Hello there, >>>> >>>> we recently had talks about creating some simplified quickstarts and >>>> hello-word demos, related to the UnifiedPush Server and JBoss AS developers: >>>> >>>> * Hello World (No Server Code - just client receiving push, no fancy >>>> (complex) UI on the client, nor integrated into a Cookbook or something >>>> that has "dependencies") >>>> ** Cordova >>>> ** Android >>>> >>>> For iOS that is already there: >>>> https://github.com/aerogear/aerogear-push-ios-demo >>>> >>>> Yes, just usage of the "Push Registration SDKs", is the goal here: keep >>>> it simple, since native push can be a complicated use-case all on its own >>>> and so it will be good to make sure we cover the basics here. >>>> >>>> >>>> Beyond the Hello-World, we wanted some different quickstarts. The >>>> "server" components that come to mind would be: >>>> >>>> *Secured CRUD + Push Integration (Java Sender) >>>> ** JAX-RS + PicketLink >>>> ** SpringMVC/Spring Security >>>> ** JAX-RS + Apache Camel >>>> >>>> These need to function on both JBoss AS 7.X and EAP. >>>> >>>> Josh, from the JDF team, has already said he wants to help on the >>>> server projects (especially the JAX-RS/PL and Spring ones). yay! >>>> Note: Josh already has a simple backend started that is used in JDF >>>> quickstarts that would be good to re-use to make it easier for developers >>>> to transition from one to other. >>>> >>>> >>>> The goal would be the SERVER acts same to outside (identical REST >>>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>>> Camel)) >>>> >>>> For these different servers, there would be mobile apps needed: >>>> * Android >>>> * Cordova >>>> * iOS >>>> >>>> >>>> The idea would be to keep them simple and straightforward as well, e.g. >>>> for iOS that means plain usage of NSURLConnection / NSURLSession. But for >>>> the "push registration" of the client, >>>> the iOS-push SDK would be used (same/similar would apply to Cordova or >>>> Android). Similar to the above 'Hello World', the quickstarts are going to >>>> be focused only on Push functionality, so for these we would leave out >>>> pipes and such until later versions. >>>> >>>> >>>> I will be creating Epics and subtasks in JIRA for this. >>>> >>>> For the location of all these projects, I had this "uber repo" location >>>> in mind: >>>> * https://github.com/aerogear/aerogear-push-helloworld >>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> >>>> -- >>>> 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 >>> >> >> >> >> -- >> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/26fe9607/attachment-0001.html From corinnekrych at gmail.com Mon Apr 7 08:57:48 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 7 Apr 2014 14:57:48 +0200 Subject: [aerogear-dev] Usage of gh submodule for cookbook central repo for all demos/quickstart Message-ID: <540FAD02-C2A8-41B2-A190-3B007AC0EAD1@gmail.com> Hello Guys We have started cookbook repositories for JaveScript [1], iOS [2] and Android[3]. As we go and add more features, we add demo app/recipe to them. But sometimes the demo app will not fit with the cookbook format. I think it?s still nice to have linked to it. For example, the upcoming Push-Helloworld and Push-Quickstart could be linked back to our cookbook repos. For iOS, we have links in the README file, for JavaScript it?s gh linked repos. I actually like the idea fo gh sub-repo, and I?d like to use the same or iOS cookbook. wdyt? ++ Corinne [1] https://github.com/aerogear/aerogear-js-cookbook [2] https://github.com/aerogear/aerogear-ios-cookbook [3] https://github.com/aerogear/aerogear-android-cookbook From daniel.bevenius at gmail.com Mon Apr 7 08:59:06 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 7 Apr 2014 14:59:06 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: For the package name, was that meant to be uppercase? "org.jboss.aerogear.unifiedpush.HelloWorld" On 7 April 2014 14:54, Matthias Wessendorf wrote: > Since we start w/ the Hello World example, let's make sure we agree on a > name :-) > > I'd suggest we name it "AeroGear UnifiedPush HelloWorld". > > For packages / bundle Identifier, I'd vote for > "org.jboss.aerogear.unifiedpush.HelloWorld" > > > -Matthias > > > On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf wrote: > >> the GH repos have been created: >> * https://github.com/aerogear/aerogear-push-helloworld >> * https://github.com/aerogear/aerogear-push-quickstarts >> >> I edited the README to 'define' the (sub)folder structure >> >> >> >> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf wrote: >> >>> Hello, >>> >>> here are the JIRAs (tasks and epics (which have sub-tasks) for this, so >>> far: >>> >>> Github repo work: >>> https://issues.jboss.org/browse/AGPUSH-586 >>> https://issues.jboss.org/browse/AGPUSH-587 >>> >>> Hello-World Example work (epic): >>> https://issues.jboss.org/browse/AGPUSH-588 >>> >>> >>> Quickstart-server (epic): >>> https://issues.jboss.org/browse/AGPUSH-596 >>> >>> Quickstart-client (epic): >>> https://issues.jboss.org/browse/AGPUSH-604 >>> >>> >>> >>> It's totally valid to: >>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if they >>> have several work units). >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf wrote: >>> >>>> Hello there, >>>> >>>> we recently had talks about creating some simplified quickstarts and >>>> hello-word demos, related to the UnifiedPush Server and JBoss AS developers: >>>> >>>> * Hello World (No Server Code - just client receiving push, no fancy >>>> (complex) UI on the client, nor integrated into a Cookbook or something >>>> that has "dependencies") >>>> ** Cordova >>>> ** Android >>>> >>>> For iOS that is already there: >>>> https://github.com/aerogear/aerogear-push-ios-demo >>>> >>>> Yes, just usage of the "Push Registration SDKs", is the goal here: keep >>>> it simple, since native push can be a complicated use-case all on its own >>>> and so it will be good to make sure we cover the basics here. >>>> >>>> >>>> Beyond the Hello-World, we wanted some different quickstarts. The >>>> "server" components that come to mind would be: >>>> >>>> *Secured CRUD + Push Integration (Java Sender) >>>> ** JAX-RS + PicketLink >>>> ** SpringMVC/Spring Security >>>> ** JAX-RS + Apache Camel >>>> >>>> These need to function on both JBoss AS 7.X and EAP. >>>> >>>> Josh, from the JDF team, has already said he wants to help on the >>>> server projects (especially the JAX-RS/PL and Spring ones). yay! >>>> Note: Josh already has a simple backend started that is used in JDF >>>> quickstarts that would be good to re-use to make it easier for developers >>>> to transition from one to other. >>>> >>>> >>>> The goal would be the SERVER acts same to outside (identical REST >>>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>>> Camel)) >>>> >>>> For these different servers, there would be mobile apps needed: >>>> * Android >>>> * Cordova >>>> * iOS >>>> >>>> >>>> The idea would be to keep them simple and straightforward as well, e.g. >>>> for iOS that means plain usage of NSURLConnection / NSURLSession. But for >>>> the "push registration" of the client, >>>> the iOS-push SDK would be used (same/similar would apply to Cordova or >>>> Android). Similar to the above 'Hello World', the quickstarts are going to >>>> be focused only on Push functionality, so for these we would leave out >>>> pipes and such until later versions. >>>> >>>> >>>> I will be creating Epics and subtasks in JIRA for this. >>>> >>>> For the location of all these projects, I had this "uber repo" location >>>> in mind: >>>> * https://github.com/aerogear/aerogear-push-helloworld >>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> >>>> -- >>>> 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 >>> >> >> >> >> -- >> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/d31a8070/attachment.html From miguel21op at gmail.com Mon Apr 7 09:00:23 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Mon, 7 Apr 2014 14:00:23 +0100 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: References: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> <7A42B7B1-39AB-426E-A8AF-5D369634AF65@gmail.com> Message-ID: Yes, my friend. But the variety of what customers need is so wide, that you'll never meet all demands. I see your service being used in the scope - in one end - of a full customized service that developers must build. The developers are supposed to develop. For instance in my case, i'll be happy if I know if the message has been forwarded to Google or Apple service. The filtering (analytics) you offer is too narrow, but I don't complain about it... On the other hand, your core service has yet some things that must be fixed / perfectionated (I'm talking only about Cordova). I also think that you should consider geo-tagged notifications, which is a very important need. IMHO the solutions Mathias wrote for using it some weeks ago (the phone sending its location to the server) is not the best one... But, again, this is only a opinion, the work you are doing so far is great, and I much appreciate it. Cheers Miguel On Mon, Apr 7, 2014 at 1:37 PM, Burr Sutter wrote: > > On Apr 7, 2014, at 8:16 AM, Miguel Lemos wrote: > > I think developers must build their own back-ends and keep track of what > they do. > > > While I agree in theory, it is more difficult in practice. A single push > server may be used by several developers across several different app > teams, in that case, you will want some metrics/logging captured at the > central point. Any given developer/team may misbehave quite badly. Our > experience with multi-developer services has demonstrated that customers > like having centralized logging/metric capture. > > > This will be always the more flexible solution. > > IMHO you must focus on the core of building a reliable and powerful push > send service (includind the documentation part). > > Enviado do meu iPhone > > No dia 07/04/2014, ?s 13:09, Burr Sutter escreveu: > > > On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf wrote: > > Hello, > > for a first round of collection some more data around the usage of the > push server (aka analytics/metrics), I'd propose we keep it very simple. > > Overall, I see one major area of interest: > *metrics around push messages being sent: > - time of sending (using timezone of the server?) > > - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, > categories,...)) > - payload (the entire payload, including custom keys - not only alert, > sound, badge etc) > > As a developer, I wish to know if my 3 test devices all registered > properly. > As a developer, I wish to know if the push notification was sent to all 3 > test devices properly (at least delivered to Apple/Google properly) > As a developer, I would like to know what were my past messages > As a push administrator, a business unit representative (e.g head of > sales, warehouse manager) is going ask me if a particular message was sent > to a particular user (alias) or user group (aliases or category). > > > This is a nice feature, and would enrich the UPS. > > > However, I can see also some interest around device specific metrics: > > Today we obivously store all the registered devices, but we also remove > them from the database table if needed (to not send messages to phones that > would no longer receive them anyways). > > I can see people wanting to just archive instead of delete those records - > interesting data points would be: > - any commonality in device type > - a trend in date/time of removal > - ratio of added/removed (user opted in vs out) > > Is it possible to distinguish between app uninstall vs push notification > disable (where the app remains installed)? > > > Something that would be interesting as well, might be the following data: > - how often was an app has reached the push server (note: every time the > app starts, the metadata of the server is being updated (see [2]) > > would this be a good proxy for letting me know how often an end-user is > using the app? > > - number of device-tokens / registrationIDs that have been removed, when > receiving errors from Apple/Google (see [3] or [4]) > - number of devices, that were activly removed using our APIs (supported > only on Android/SimplePush due to Apple policy, see [5]) > > > While the initial focus should be around the message related metrics, > capturing some device data is nice too. > > > Any thoughts ? > > -Matthias > > > PS: Oh, for the longer run(...), I'd also like to see metrics like "was > mobile app opened due to a push notification". BUT that also requires some > more work/reseach on the client Push SDKs. But seriously, this is not a > priority for the next few months! > > > > > [1] https://issues.jboss.org/browse/AGPUSH-116 > [2] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 > [3] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 > [4] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 > [5] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/c2d05c43/attachment-0001.html From bruno at abstractj.org Mon Apr 7 09:04:13 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 7 Apr 2014 10:04:13 -0300 Subject: [aerogear-dev] aerogear security and android In-Reply-To: <1396637119777-7335.post@n5.nabble.com> References: <1394467743631-6703.post@n5.nabble.com> <1394558729969-6747.post@n5.nabble.com> <1394624522273-6750.post@n5.nabble.com> <1394642857598-6762.post@n5.nabble.com> <1396637119777-7335.post@n5.nabble.com> Message-ID: Not sure if I?m following you this Marcelo, but what are the detailed steps to reproduce the issue?? -- abstractj On April 4, 2014 at 3:45:27 PM, marceloheck (marceloheck at gmail.com) wrote: > > but the problem is with two users, one role simple and the other > role admin > different tablet a just login and get the rest, there is another > login and > get the rest when I go back to using the first has lost the use > > work for as many simultaneous users? From lholmqui at redhat.com Mon Apr 7 09:04:55 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 7 Apr 2014 09:04:55 -0400 Subject: [aerogear-dev] Usage of gh submodule for cookbook central repo for all demos/quickstart In-Reply-To: <540FAD02-C2A8-41B2-A190-3B007AC0EAD1@gmail.com> References: <540FAD02-C2A8-41B2-A190-3B007AC0EAD1@gmail.com> Message-ID: <791AEDB8-928C-42DD-9512-38C5E7DAC950@redhat.com> On Apr 7, 2014, at 8:57 AM, Corinne Krych wrote: > Hello Guys > > We have started cookbook repositories for JaveScript [1], iOS [2] and Android[3]. As we go and add more features, we add demo app/recipe to them. But sometimes the demo app will not fit with the cookbook format. I think it?s still nice to have linked to it. For example, the upcoming Push-Helloworld and Push-Quickstart could be linked back to our cookbook repos. > > For iOS, we have links in the README file, for JavaScript it?s gh linked repos. I actually like the idea fo gh sub-repo, and I?d like to use the same or iOS cookbook. wdyt? +1 the only thing i worried about when using sub-repos is that the user might mss the instructions on how to pull them down. > > ++ > Corinne > [1] https://github.com/aerogear/aerogear-js-cookbook > [2] https://github.com/aerogear/aerogear-ios-cookbook > [3] https://github.com/aerogear/aerogear-android-cookbook > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Mon Apr 7 09:05:58 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 15:05:58 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: On Mon, Apr 7, 2014 at 2:59 PM, Daniel Bevenius wrote: > For the package name, was that meant to be uppercase? > "org.jboss.aerogear.unifiedpush.HelloWorld" > nope - not really; iOS app:name -> HelloWord; package "o.j.a.u" > > > > > On 7 April 2014 14:54, Matthias Wessendorf wrote: > >> Since we start w/ the Hello World example, let's make sure we agree on a >> name :-) >> >> I'd suggest we name it "AeroGear UnifiedPush HelloWorld". >> >> For packages / bundle Identifier, I'd vote for >> "org.jboss.aerogear.unifiedpush.HelloWorld" >> >> >> -Matthias >> >> >> On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf wrote: >> >>> the GH repos have been created: >>> * https://github.com/aerogear/aerogear-push-helloworld >>> * https://github.com/aerogear/aerogear-push-quickstarts >>> >>> I edited the README to 'define' the (sub)folder structure >>> >>> >>> >>> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf wrote: >>> >>>> Hello, >>>> >>>> here are the JIRAs (tasks and epics (which have sub-tasks) for this, so >>>> far: >>>> >>>> Github repo work: >>>> https://issues.jboss.org/browse/AGPUSH-586 >>>> https://issues.jboss.org/browse/AGPUSH-587 >>>> >>>> Hello-World Example work (epic): >>>> https://issues.jboss.org/browse/AGPUSH-588 >>>> >>>> >>>> Quickstart-server (epic): >>>> https://issues.jboss.org/browse/AGPUSH-596 >>>> >>>> Quickstart-client (epic): >>>> https://issues.jboss.org/browse/AGPUSH-604 >>>> >>>> >>>> >>>> It's totally valid to: >>>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if they >>>> have several work units). >>>> >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> Hello there, >>>>> >>>>> we recently had talks about creating some simplified quickstarts and >>>>> hello-word demos, related to the UnifiedPush Server and JBoss AS developers: >>>>> >>>>> * Hello World (No Server Code - just client receiving push, no fancy >>>>> (complex) UI on the client, nor integrated into a Cookbook or something >>>>> that has "dependencies") >>>>> ** Cordova >>>>> ** Android >>>>> >>>>> For iOS that is already there: >>>>> https://github.com/aerogear/aerogear-push-ios-demo >>>>> >>>>> Yes, just usage of the "Push Registration SDKs", is the goal here: >>>>> keep it simple, since native push can be a complicated use-case all on its >>>>> own and so it will be good to make sure we cover the basics here. >>>>> >>>>> >>>>> Beyond the Hello-World, we wanted some different quickstarts. The >>>>> "server" components that come to mind would be: >>>>> >>>>> *Secured CRUD + Push Integration (Java Sender) >>>>> ** JAX-RS + PicketLink >>>>> ** SpringMVC/Spring Security >>>>> ** JAX-RS + Apache Camel >>>>> >>>>> These need to function on both JBoss AS 7.X and EAP. >>>>> >>>>> Josh, from the JDF team, has already said he wants to help on the >>>>> server projects (especially the JAX-RS/PL and Spring ones). yay! >>>>> Note: Josh already has a simple backend started that is used in JDF >>>>> quickstarts that would be good to re-use to make it easier for developers >>>>> to transition from one to other. >>>>> >>>>> >>>>> The goal would be the SERVER acts same to outside (identical REST >>>>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>>>> Camel)) >>>>> >>>>> For these different servers, there would be mobile apps needed: >>>>> * Android >>>>> * Cordova >>>>> * iOS >>>>> >>>>> >>>>> The idea would be to keep them simple and straightforward as well, >>>>> e.g. for iOS that means plain usage of NSURLConnection / NSURLSession. But >>>>> for the "push registration" of the client, >>>>> the iOS-push SDK would be used (same/similar would apply to Cordova or >>>>> Android). Similar to the above 'Hello World', the quickstarts are going to >>>>> be focused only on Push functionality, so for these we would leave out >>>>> pipes and such until later versions. >>>>> >>>>> >>>>> I will be creating Epics and subtasks in JIRA for this. >>>>> >>>>> For the location of all these projects, I had this "uber repo" >>>>> location in mind: >>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>> >>>>> Greetings, >>>>> Matthias >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/45b4643d/attachment.html From matzew at apache.org Mon Apr 7 09:08:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 15:08:13 +0200 Subject: [aerogear-dev] Usage of gh submodule for cookbook central repo for all demos/quickstart In-Reply-To: <791AEDB8-928C-42DD-9512-38C5E7DAC950@redhat.com> References: <540FAD02-C2A8-41B2-A190-3B007AC0EAD1@gmail.com> <791AEDB8-928C-42DD-9512-38C5E7DAC950@redhat.com> Message-ID: On Mon, Apr 7, 2014 at 3:04 PM, Lucas Holmquist wrote: > > On Apr 7, 2014, at 8:57 AM, Corinne Krych wrote: > > > Hello Guys > > > > We have started cookbook repositories for JaveScript [1], iOS [2] and > Android[3]. As we go and add more features, we add demo app/recipe to them. > But sometimes the demo app will not fit with the cookbook format. I think > it's still nice to have linked to it. For example, the upcoming > Push-Helloworld and Push-Quickstart could be linked back to our cookbook > repos. > > > > For iOS, we have links in the README file, for JavaScript it's gh linked > repos. I actually like the idea fo gh sub-repo, and I'd like to use the > same or iOS cookbook. wdyt? > +1 on linking/including via submodules > > +1 > > the only thing i worried about when using sub-repos is that the user might > mss the instructions on how to pull them down. > yep, that's a valid concern > > > > > > ++ > > Corinne > > [1] https://github.com/aerogear/aerogear-js-cookbook > > [2] https://github.com/aerogear/aerogear-ios-cookbook > > [3] https://github.com/aerogear/aerogear-android-cookbook > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/452078c5/attachment-0001.html From corinnekrych at gmail.com Mon Apr 7 09:13:33 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 7 Apr 2014 15:13:33 +0200 Subject: [aerogear-dev] Usage of gh submodule for cookbook central repo for all demos/quickstart In-Reply-To: References: <540FAD02-C2A8-41B2-A190-3B007AC0EAD1@gmail.com> <791AEDB8-928C-42DD-9512-38C5E7DAC950@redhat.com> Message-ID: <10F81C44-DC66-4AF3-82FB-BAE70688242D@gmail.com> Yep valid concerns but "read the manual? could be the answer https://github.com/aerogear/aerogear-js-cookbook#recipes I will add a section like yours in the README ++ Corinne On 07 Apr 2014, at 15:08, Matthias Wessendorf wrote: > > > > On Mon, Apr 7, 2014 at 3:04 PM, Lucas Holmquist wrote: > > On Apr 7, 2014, at 8:57 AM, Corinne Krych wrote: > > > Hello Guys > > > > We have started cookbook repositories for JaveScript [1], iOS [2] and Android[3]. As we go and add more features, we add demo app/recipe to them. But sometimes the demo app will not fit with the cookbook format. I think it?s still nice to have linked to it. For example, the upcoming Push-Helloworld and Push-Quickstart could be linked back to our cookbook repos. > > > > For iOS, we have links in the README file, for JavaScript it?s gh linked repos. I actually like the idea fo gh sub-repo, and I?d like to use the same or iOS cookbook. wdyt? > > +1 on linking/including via submodules > > > +1 > > the only thing i worried about when using sub-repos is that the user might mss the instructions on how to pull them down. > > yep, that's a valid concern > > > > > > > ++ > > Corinne > > [1] https://github.com/aerogear/aerogear-js-cookbook > > [2] https://github.com/aerogear/aerogear-ios-cookbook > > [3] https://github.com/aerogear/aerogear-android-cookbook > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Mon Apr 7 09:16:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 15:16:15 +0200 Subject: [aerogear-dev] Usage of gh submodule for cookbook central repo for all demos/quickstart In-Reply-To: <10F81C44-DC66-4AF3-82FB-BAE70688242D@gmail.com> References: <540FAD02-C2A8-41B2-A190-3B007AC0EAD1@gmail.com> <791AEDB8-928C-42DD-9512-38C5E7DAC950@redhat.com> <10F81C44-DC66-4AF3-82FB-BAE70688242D@gmail.com> Message-ID: sounds goood! On Mon, Apr 7, 2014 at 3:13 PM, Corinne Krych wrote: > Yep valid concerns but "read the manual" could be the answer > https://github.com/aerogear/aerogear-js-cookbook#recipes > I will add a section like yours in the README > > ++ > Corinne > On 07 Apr 2014, at 15:08, Matthias Wessendorf wrote: > > > > > > > > > On Mon, Apr 7, 2014 at 3:04 PM, Lucas Holmquist > wrote: > > > > On Apr 7, 2014, at 8:57 AM, Corinne Krych > wrote: > > > > > Hello Guys > > > > > > We have started cookbook repositories for JaveScript [1], iOS [2] and > Android[3]. As we go and add more features, we add demo app/recipe to them. > But sometimes the demo app will not fit with the cookbook format. I think > it's still nice to have linked to it. For example, the upcoming > Push-Helloworld and Push-Quickstart could be linked back to our cookbook > repos. > > > > > > For iOS, we have links in the README file, for JavaScript it's gh > linked repos. I actually like the idea fo gh sub-repo, and I'd like to use > the same or iOS cookbook. wdyt? > > > > +1 on linking/including via submodules > > > > > > +1 > > > > the only thing i worried about when using sub-repos is that the user > might mss the instructions on how to pull them down. > > > > yep, that's a valid concern > > > > > > > > > > > > ++ > > > Corinne > > > [1] https://github.com/aerogear/aerogear-js-cookbook > > > [2] https://github.com/aerogear/aerogear-ios-cookbook > > > [3] https://github.com/aerogear/aerogear-android-cookbook > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at 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 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/7f26af93/attachment.html From daniel.bevenius at gmail.com Mon Apr 7 09:21:21 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 7 Apr 2014 15:21:21 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: Ah my bad. I was assuming the quickstarts were in Java. On 7 April 2014 15:05, Matthias Wessendorf wrote: > > > > On Mon, Apr 7, 2014 at 2:59 PM, Daniel Bevenius > wrote: > >> For the package name, was that meant to be uppercase? >> "org.jboss.aerogear.unifiedpush.HelloWorld" >> > > nope - not really; iOS app:name -> HelloWord; package "o.j.a.u" > > >> >> >> >> >> On 7 April 2014 14:54, Matthias Wessendorf wrote: >> >>> Since we start w/ the Hello World example, let's make sure we agree on a >>> name :-) >>> >>> I'd suggest we name it "AeroGear UnifiedPush HelloWorld". >>> >>> For packages / bundle Identifier, I'd vote for >>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>> >>> >>> -Matthias >>> >>> >>> On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf wrote: >>> >>>> the GH repos have been created: >>>> * https://github.com/aerogear/aerogear-push-helloworld >>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>> >>>> I edited the README to 'define' the (sub)folder structure >>>> >>>> >>>> >>>> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf wrote: >>>> >>>>> Hello, >>>>> >>>>> here are the JIRAs (tasks and epics (which have sub-tasks) for this, >>>>> so far: >>>>> >>>>> Github repo work: >>>>> https://issues.jboss.org/browse/AGPUSH-586 >>>>> https://issues.jboss.org/browse/AGPUSH-587 >>>>> >>>>> Hello-World Example work (epic): >>>>> https://issues.jboss.org/browse/AGPUSH-588 >>>>> >>>>> >>>>> Quickstart-server (epic): >>>>> https://issues.jboss.org/browse/AGPUSH-596 >>>>> >>>>> Quickstart-client (epic): >>>>> https://issues.jboss.org/browse/AGPUSH-604 >>>>> >>>>> >>>>> >>>>> It's totally valid to: >>>>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if they >>>>> have several work units). >>>>> >>>>> >>>>> Greetings, >>>>> Matthias >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> Hello there, >>>>>> >>>>>> we recently had talks about creating some simplified quickstarts and >>>>>> hello-word demos, related to the UnifiedPush Server and JBoss AS developers: >>>>>> >>>>>> * Hello World (No Server Code - just client receiving push, no fancy >>>>>> (complex) UI on the client, nor integrated into a Cookbook or something >>>>>> that has "dependencies") >>>>>> ** Cordova >>>>>> ** Android >>>>>> >>>>>> For iOS that is already there: >>>>>> https://github.com/aerogear/aerogear-push-ios-demo >>>>>> >>>>>> Yes, just usage of the "Push Registration SDKs", is the goal here: >>>>>> keep it simple, since native push can be a complicated use-case all on its >>>>>> own and so it will be good to make sure we cover the basics here. >>>>>> >>>>>> >>>>>> Beyond the Hello-World, we wanted some different quickstarts. The >>>>>> "server" components that come to mind would be: >>>>>> >>>>>> *Secured CRUD + Push Integration (Java Sender) >>>>>> ** JAX-RS + PicketLink >>>>>> ** SpringMVC/Spring Security >>>>>> ** JAX-RS + Apache Camel >>>>>> >>>>>> These need to function on both JBoss AS 7.X and EAP. >>>>>> >>>>>> Josh, from the JDF team, has already said he wants to help on the >>>>>> server projects (especially the JAX-RS/PL and Spring ones). yay! >>>>>> Note: Josh already has a simple backend started that is used in JDF >>>>>> quickstarts that would be good to re-use to make it easier for developers >>>>>> to transition from one to other. >>>>>> >>>>>> >>>>>> The goal would be the SERVER acts same to outside (identical REST >>>>>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>>>>> Camel)) >>>>>> >>>>>> For these different servers, there would be mobile apps needed: >>>>>> * Android >>>>>> * Cordova >>>>>> * iOS >>>>>> >>>>>> >>>>>> The idea would be to keep them simple and straightforward as well, >>>>>> e.g. for iOS that means plain usage of NSURLConnection / NSURLSession. But >>>>>> for the "push registration" of the client, >>>>>> the iOS-push SDK would be used (same/similar would apply to Cordova >>>>>> or Android). Similar to the above 'Hello World', the quickstarts are going >>>>>> to be focused only on Push functionality, so for these we would leave out >>>>>> pipes and such until later versions. >>>>>> >>>>>> >>>>>> I will be creating Epics and subtasks in JIRA for this. >>>>>> >>>>>> For the location of all these projects, I had this "uber repo" >>>>>> location in mind: >>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>> >>>>>> Greetings, >>>>>> Matthias >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/a61aeea6/attachment-0001.html From kpiwko at redhat.com Mon Apr 7 09:36:23 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 7 Apr 2014 15:36:23 +0200 Subject: [aerogear-dev] Usage of gh submodule for cookbook central repo for all demos/quickstart In-Reply-To: <540FAD02-C2A8-41B2-A190-3B007AC0EAD1@gmail.com> References: <540FAD02-C2A8-41B2-A190-3B007AC0EAD1@gmail.com> Message-ID: <20140407153623.0091455f@kapy-ntb-x220> Sounds good. On Mon, 7 Apr 2014 14:57:48 +0200 Corinne Krych wrote: > Hello Guys > > We have started cookbook repositories for JaveScript [1], iOS [2] and > Android[3]. As we go and add more features, we add demo app/recipe to them. > But sometimes the demo app will not fit with the cookbook format. I think > it?s still nice to have linked to it. For example, the upcoming > Push-Helloworld and Push-Quickstart could be linked back to our cookbook > repos. > > For iOS, we have links in the README file, for JavaScript it?s gh linked > repos. I actually like the idea fo gh sub-repo, and I?d like to use the same > or iOS cookbook. wdyt? > > ++ > Corinne > [1] https://github.com/aerogear/aerogear-js-cookbook > [2] https://github.com/aerogear/aerogear-ios-cookbook > [3] https://github.com/aerogear/aerogear-android-cookbook > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From edewit at redhat.com Mon Apr 7 09:39:55 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 7 Apr 2014 15:39:55 +0200 Subject: [aerogear-dev] cordova hello world Message-ID: How about a list that looks like this: https://www.dropbox.com/s/d8cn0xm7lfm5mts/cordova%20list%20screenshot.png From matzew at apache.org Mon Apr 7 09:41:11 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 15:41:11 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: yes/no :-) HelloWorld: just clients -no server code - https://issues.jboss.org/browse/AGPUSH-588 Quickstarts: server/client Quickstart-server (epic): https://issues.jboss.org/browse/AGPUSH-596 Quickstart-client (epic): https://issues.jboss.org/browse/AGPUSH-604 but atm, we focus on the HelloWorld; once they are done and documented, we will get to the Quickstarts On Mon, Apr 7, 2014 at 3:21 PM, Daniel Bevenius wrote: > Ah my bad. I was assuming the quickstarts were in Java. > > > On 7 April 2014 15:05, Matthias Wessendorf wrote: > >> >> >> >> On Mon, Apr 7, 2014 at 2:59 PM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> For the package name, was that meant to be uppercase? >>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>> >> >> nope - not really; iOS app:name -> HelloWord; package "o.j.a.u" >> >> >>> >>> >>> >>> >>> On 7 April 2014 14:54, Matthias Wessendorf wrote: >>> >>>> Since we start w/ the Hello World example, let's make sure we agree on >>>> a name :-) >>>> >>>> I'd suggest we name it "AeroGear UnifiedPush HelloWorld". >>>> >>>> For packages / bundle Identifier, I'd vote for >>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>> >>>> >>>> -Matthias >>>> >>>> >>>> On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf wrote: >>>> >>>>> the GH repos have been created: >>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>> >>>>> I edited the README to 'define' the (sub)folder structure >>>>> >>>>> >>>>> >>>>> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf >>>> > wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> here are the JIRAs (tasks and epics (which have sub-tasks) for this, >>>>>> so far: >>>>>> >>>>>> Github repo work: >>>>>> https://issues.jboss.org/browse/AGPUSH-586 >>>>>> https://issues.jboss.org/browse/AGPUSH-587 >>>>>> >>>>>> Hello-World Example work (epic): >>>>>> https://issues.jboss.org/browse/AGPUSH-588 >>>>>> >>>>>> >>>>>> Quickstart-server (epic): >>>>>> https://issues.jboss.org/browse/AGPUSH-596 >>>>>> >>>>>> Quickstart-client (epic): >>>>>> https://issues.jboss.org/browse/AGPUSH-604 >>>>>> >>>>>> >>>>>> >>>>>> It's totally valid to: >>>>>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if they >>>>>> have several work units). >>>>>> >>>>>> >>>>>> Greetings, >>>>>> Matthias >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> Hello there, >>>>>>> >>>>>>> we recently had talks about creating some simplified quickstarts and >>>>>>> hello-word demos, related to the UnifiedPush Server and JBoss AS developers: >>>>>>> >>>>>>> * Hello World (No Server Code - just client receiving push, no fancy >>>>>>> (complex) UI on the client, nor integrated into a Cookbook or something >>>>>>> that has "dependencies") >>>>>>> ** Cordova >>>>>>> ** Android >>>>>>> >>>>>>> For iOS that is already there: >>>>>>> https://github.com/aerogear/aerogear-push-ios-demo >>>>>>> >>>>>>> Yes, just usage of the "Push Registration SDKs", is the goal here: >>>>>>> keep it simple, since native push can be a complicated use-case all on its >>>>>>> own and so it will be good to make sure we cover the basics here. >>>>>>> >>>>>>> >>>>>>> Beyond the Hello-World, we wanted some different quickstarts. The >>>>>>> "server" components that come to mind would be: >>>>>>> >>>>>>> *Secured CRUD + Push Integration (Java Sender) >>>>>>> ** JAX-RS + PicketLink >>>>>>> ** SpringMVC/Spring Security >>>>>>> ** JAX-RS + Apache Camel >>>>>>> >>>>>>> These need to function on both JBoss AS 7.X and EAP. >>>>>>> >>>>>>> Josh, from the JDF team, has already said he wants to help on the >>>>>>> server projects (especially the JAX-RS/PL and Spring ones). yay! >>>>>>> Note: Josh already has a simple backend started that is used in JDF >>>>>>> quickstarts that would be good to re-use to make it easier for developers >>>>>>> to transition from one to other. >>>>>>> >>>>>>> >>>>>>> The goal would be the SERVER acts same to outside (identical REST >>>>>>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>>>>>> Camel)) >>>>>>> >>>>>>> For these different servers, there would be mobile apps needed: >>>>>>> * Android >>>>>>> * Cordova >>>>>>> * iOS >>>>>>> >>>>>>> >>>>>>> The idea would be to keep them simple and straightforward as well, >>>>>>> e.g. for iOS that means plain usage of NSURLConnection / NSURLSession. But >>>>>>> for the "push registration" of the client, >>>>>>> the iOS-push SDK would be used (same/similar would apply to Cordova >>>>>>> or Android). Similar to the above 'Hello World', the quickstarts are going >>>>>>> to be focused only on Push functionality, so for these we would leave out >>>>>>> pipes and such until later versions. >>>>>>> >>>>>>> >>>>>>> I will be creating Epics and subtasks in JIRA for this. >>>>>>> >>>>>>> For the location of all these projects, I had this "uber repo" >>>>>>> location in mind: >>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>> >>>>>>> Greetings, >>>>>>> Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/68759c68/attachment.html From matzew at apache.org Mon Apr 7 09:41:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 15:41:50 +0200 Subject: [aerogear-dev] cordova hello world In-Reply-To: References: Message-ID: yeah, looks pretty nice :-) On Mon, Apr 7, 2014 at 3:39 PM, Erik Jan de Wit wrote: > How about a list that looks like this: > > https://www.dropbox.com/s/d8cn0xm7lfm5mts/cordova%20list%20screenshot.png > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/1e4fc16a/attachment-0001.html From cvasilak at gmail.com Mon Apr 7 09:42:25 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 7 Apr 2014 16:42:25 +0300 Subject: [aerogear-dev] iOS Team Meeting Message-ID: <99DE4975-0D25-4947-B510-656E07734C1D@gmail.com> Hi everyone, tomorrow will have our iOS team meeting agenda can be found here[1] feel free to join us! - Christos [1] http://oksoclap.com/p/aerogear-team-mgt-20140407 From edewit at redhat.com Mon Apr 7 09:43:46 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 7 Apr 2014 15:43:46 +0200 Subject: [aerogear-dev] cordova hello world In-Reply-To: References: Message-ID: <25A9245F-0DFE-4FE9-88B5-0C1994582661@redhat.com> and what do we use for a splash screen? On 7 Apr,2014, at 15:41 , Matthias Wessendorf wrote: > yeah, looks pretty nice :-) > > > > > On Mon, Apr 7, 2014 at 3:39 PM, Erik Jan de Wit wrote: > How about a list that looks like this: > > https://www.dropbox.com/s/d8cn0xm7lfm5mts/cordova%20list%20screenshot.png > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/069b5af6/attachment.html From michi.oshima at gmail.com Mon Apr 7 09:50:12 2014 From: michi.oshima at gmail.com (Michi Oshima) Date: Mon, 7 Apr 2014 09:50:12 -0400 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Hi. Thank you all. I successfully got multiple registration working last week. 1. Sebastien, what is the purpose of using the local storage to store the mapping between channel ID and category? I'm at this time keeping the map in memory. 2. Matthias, using the current time makes sense. I'll do that. Why didn't I think about that? Thank you all again for your attention and advice thus far. Michi On Fri, Apr 4, 2014 at 5:13 AM, Matthias Wessendorf wrote: > Hello Michi, > > IMO the version number string is a bit odd for most backend applications. > :-) If you don't want to maintain a "version per channel", I'd just do the > current timestamp (e.g. Date.now() in JS) > > -M > > > On Fri, Apr 4, 2014 at 11:04 AM, Sebastien Blanc wrote: > >> Hey Again ! >> >> To make it even easier I've deployed a "multi-channel" version of the >> quickstart here : http://mutlichannels-sblanc.rhcloud.com/ >> Then you can fire the CURLs for each category to see how it can handle >> different channels : >> >> curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ >> "categories" :["mail"], >> "simple-push": "version=1111" >> >> }' https://hackergartenups-sblanc.rhcloud.com/rest/sender >> >> >> >> curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ >> >> "categories" :["news"], >> "simple-push": "version=1112" >> }' https://hackergartenups-sblanc.rhcloud.com/rest/sender >> >> >> >> If you fire these multiple time don't forget to change the version value ! >> >> >> >> >> >> On Fri, Apr 4, 2014 at 10:02 AM, Sebastien Blanc wrote: >> >>> Hey Michi, >>> I realized that the code I pointed you to could be a bit confusing and >>> also contains a small bug. >>> >>> I wrote this gist based on the quickstart example. Basically we register >>> to 2 channels : mail and news, we store the channelID and map that with a >>> String containing the service name, then in the onNotification we check >>> which service to call : >>> >>> https://gist.github.com/sebastienblanc/9970129 >>> >>> Hope this example will make more sense ! >>> >>> Seb >>> >>> >>> >>> >>> On Thu, Apr 3, 2014 at 8:53 PM, Sebastien Blanc wrote: >>> >>>> Looks at this more advanced example here >>>> https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js >>>> >>>> >>>> You will see that we register 2 times and we get 2 different endpoints. >>>> Then you have to keep somewhere a link between your endpoint and let's say >>>> the service you want to associate to , like using the localStorage : >>>> localStorage.setItem(theEndpoint, "scoreService"); >>>> >>>> Then when you receive a message, besides the version (which is btw not >>>> mandatory to be used) you also receive the channelId, then you can choose >>>> which service to call : >>>> >>>> >>>> navigator.setMessageHandler("push", function(message) { >>>> >>>> >>>> >>>> var myService = localStorage.get(message.channelID); >>>> //now based on this you can call your specific log >>>> }); >>>> >>>> >>>> >>>> >>>> I Hope this will help you. >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima wrote: >>>> >>>>> Thank you, Sebastien. I'll try multiple registration. Although, I'm >>>>> a bit confused. Because: >>>>> >>>>> >>>>> 1. As far as I can see from the quick start example, >>>>> per SPS Client, there'll be one registration with the SimplePush server. >>>>> That means I only get one endpoint. >>>>> 2. So I'd use the same endpoint to register multiple times with >>>>> the unified push server using different category each time. >>>>> 3. When the SPS client receives a version number, how can it >>>>> associate a given version number to a particular category? (I've not seen >>>>> categories reaching the client.) >>>>> >>>>> >>>>> Am I wrong somewhere above? >>>>> >>>>> >>>>> >>>>> On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima wrote: >>>>>> >>>>>>> Hi Lucas, >>>>>>> >>>>>>> Following might do what I want (sending a "door bell" message in one >>>>>>> shot to all variants)? Send a unified message like the following one: >>>>>>> >>>>>>> >>>>>>> - '{ "message": { "version":"123" }, "simple-push": >>>>>>> "version=123" }' >>>>>>> >>>>>>> >>>>>>> One slight deviation is that mobile variants like iOS and Android >>>>>>> will get the message regardless of whether the the version number is "old" >>>>>>> or not. Is this correct? >>>>>>> >>>>>> >>>>>> Yes iOS/Android ignore the version since that is really something >>>>>> tied to Simple Push >>>>>> >>>>>>> >>>>>>> So I revisited the SimplePush spec, >>>>>>> and I noticed it describes support for subscription to multiple channels. >>>>>>> >>>>>>> Aerogear doesn't allow multiple channels per installation, correct? >>>>>>> I dug up an old post from Matthias: >>>>>>> >>>>>>> >>>>>>> - >>>>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>>>>>> >>>>>>> Well yes, but multiple installations can belong to the same SPS >>>>>> Client. You can register multiple time, differentiate them by passing them >>>>>> a category for instance. >>>>>> >>>>>> >>>>>>> >>>>>>> - >>>>>>> >>>>>>> >>>>>>> If an installation can subscribe to multiple channels, then it would >>>>>>> allow me to get what I originally asked about: >>>>>>> >>>>>>> Me: 'My client application (javascript on browser) holds multiple >>>>>>> types of data. It would be nice if I can send a notification saying >>>>>>> "there's an update for this data type", rather than just "there's an >>>>>>> update". Or, in general it'd be nice if I can send more information than >>>>>>> just a monotonically increasing number. ' >>>>>>> >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>> >>>>>> That would be quite a breaking change and we need to discuss that, in >>>>>> the same time, as said before, you can still register a single client to >>>>>> multiple channels (and es you will have multiple installations but that do >>>>>> not really matter) >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist < >>>>>>> lholmqui at redhat.com> wrote: >>>>>>> >>>>>>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>>>>>> disturbing auctions for 30 minutes. I'll read it again. >>>>>>>> >>>>>>>> Another question, is there a way to send a "door bell" message *in >>>>>>>> one shot* to all iOS, Android, and SimplePush variants? >>>>>>>> >>>>>>>> >>>>>>>> well, iOS and Android notifications aren't really doorbells, but >>>>>>>> you can send a "message" to all clients that are registered in your Push >>>>>>>> Server. >>>>>>>> >>>>>>>> we have a Java client >>>>>>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>>>> >>>>>>>> and a node.js client for this >>>>>>>> https://www.npmjs.org/package/aerogear-sender-client >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (m:) >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist < >>>>>>>> lholmqui at redhat.com> wrote: >>>>>>>> >>>>>>>>> SimplePush works only as a "door bell" to tell your app, hey, >>>>>>>>> you should go look on your server. >>>>>>>>> >>>>>>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Yesterday I managed to send my first message to a browser. Thanks >>>>>>>>> for all your help. >>>>>>>>> >>>>>>>>> I've tried sending a few different types of messages, and it so >>>>>>>>> far appears to me the only thing I can send to a simple push client is a >>>>>>>>> version number. Can a simple push client receive anything else other than >>>>>>>>> version numbers? If so, what does the sender need to do, and what does the >>>>>>>>> client need to do? (If there is a good example somewhere online I can work >>>>>>>>> from that also.) >>>>>>>>> >>>>>>>>> My client application (javascript on browser) holds multiple types >>>>>>>>> of data. It would be nice if I can send a notification saying "there's an >>>>>>>>> update for this data type", rather than just "there's an update". Or, in >>>>>>>>> general it'd be nice if I can send more information than just a >>>>>>>>> monotonically increasing number. >>>>>>>>> >>>>>>>>> Here's my setup: >>>>>>>>> >>>>>>>>> >>>>>>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>>>>>> - Sender is a JBoss app using >>>>>>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>>>>>> (unifiedpush-java-client-0.5.0.jar). >>>>>>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>>>>>> >>>>>>>>> >>>>>>>>> I read this documentation, >>>>>>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>>>>>> variants use the "extra simple-push object" only. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> >>>>>>>>> Michi Oshima >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/2f6d1e07/attachment-0001.html From matzew at apache.org Mon Apr 7 09:52:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 15:52:57 +0200 Subject: [aerogear-dev] cordova hello world In-Reply-To: <25A9245F-0DFE-4FE9-88B5-0C1994582661@redhat.com> References: <25A9245F-0DFE-4FE9-88B5-0C1994582661@redhat.com> Message-ID: On Mon, Apr 7, 2014 at 3:43 PM, Erik Jan de Wit wrote: > and what do we use for a splash screen? > hrm - all white as well ? and simple the AeroGear logo ? > > On 7 Apr,2014, at 15:41 , Matthias Wessendorf wrote: > > yeah, looks pretty nice :-) > > > > > On Mon, Apr 7, 2014 at 3:39 PM, Erik Jan de Wit wrote: > >> How about a list that looks like this: >> >> https://www.dropbox.com/s/d8cn0xm7lfm5mts/cordova%20list%20screenshot.png >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/80eac1b6/attachment.html From bsutter at redhat.com Mon Apr 7 09:54:45 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 7 Apr 2014 09:54:45 -0400 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: References: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> <7A42B7B1-39AB-426E-A8AF-5D369634AF65@gmail.com> Message-ID: <530B54FC-52EB-46CF-9983-9E24859FCE91@redhat.com> On Apr 7, 2014, at 9:00 AM, Miguel Lemos wrote: > Yes, my friend. But the variety of what customers need is so wide, that you'll never meet all demands. > > I see your service being used in the scope - in one end - of a full customized service that developers must build. The developers are supposed to develop. For instance in my case, i'll be happy if I know if the message has been forwarded to Google or Apple service. The filtering (analytics) you offer is too narrow, but I don't complain about it... At this time, we do not tell the user if the message was forwarded or not - the UI has no indication that a message has moved through the system. A newbie would like to know that something happened. Some basic metrics/analytics is helpful to giving a new user that warm-fuzzy feeling that the UPS is actually doing something, even if the push message does not make it out to the phone itself. > > On the other hand, your core service has yet some things that must be fixed / perfectionated (I'm talking only about Cordova). I also think that you should consider geo-tagged notifications, which is a very important need. I agree - but these things are not necessarily mutually exclusive :-) On the Cordova side of things, I would like to know more about what needs fine-tuning. Docs? definitely need work And our push plugin is a wee bit fat for Android, needs to go on a diet, dexing takes a while And the JS API needed some clean-up, you have seen Erik's proposals on that item We should have a thread to more fully flesh out geo-tagging/geo-fencing requirements - I also love that idea/feature and think it is critical. I know that Erik already produced an early prototype but I have not yet explored how it works, to see if it is cross-platform, battery efficient and relatively accurate (within a few KM of distance). > > IMHO the solutions Mathias wrote for using it some weeks ago (the phone sending its location to the server) is not the best one... Was this in the Aerodoc example? I can see a scenario where a developer would want this - basically, allow the end-user to set his "home" geo-location and perhaps "work" geo-location and not attempt to track the physical movement of the phone on a recurring basis. For instance, a sales rep often has specific geographic boundary that he works within (as seen in Aerodoc) but a consumer, visiting different malls, does not. > But, again, this is only a opinion, the work you are doing so far is great, and I much appreciate it. > > Cheers > > Miguel > > > > On Mon, Apr 7, 2014 at 1:37 PM, Burr Sutter wrote: > > On Apr 7, 2014, at 8:16 AM, Miguel Lemos wrote: > >> I think developers must build their own back-ends and keep track of what they do. > > While I agree in theory, it is more difficult in practice. A single push server may be used by several developers across several different app teams, in that case, you will want some metrics/logging captured at the central point. Any given developer/team may misbehave quite badly. Our experience with multi-developer services has demonstrated that customers like having centralized logging/metric capture. > >> >> This will be always the more flexible solution. >> >> IMHO you must focus on the core of building a reliable and powerful push send service (includind the documentation part). >> >> Enviado do meu iPhone >> >> No dia 07/04/2014, ?s 13:09, Burr Sutter escreveu: >> >>> >>> On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf wrote: >>> >>>> Hello, >>>> >>>> for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. >>>> >>>> Overall, I see one major area of interest: >>>> *metrics around push messages being sent: >>>> - time of sending (using timezone of the server?) >>> >>>> - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) >>>> - payload (the entire payload, including custom keys - not only alert, sound, badge etc) >>>> >>> As a developer, I wish to know if my 3 test devices all registered properly. >>> As a developer, I wish to know if the push notification was sent to all 3 test devices properly (at least delivered to Apple/Google properly) >>> As a developer, I would like to know what were my past messages >>> As a push administrator, a business unit representative (e.g head of sales, warehouse manager) is going ask me if a particular message was sent to a particular user (alias) or user group (aliases or category). >>>> >>>> This is a nice feature, and would enrich the UPS. >>>> >>>> >>>> However, I can see also some interest around device specific metrics: >>>> >>>> Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). >>> I can see people wanting to just archive instead of delete those records - interesting data points would be: >>> - any commonality in device type >>> - a trend in date/time of removal >>> - ratio of added/removed (user opted in vs out) >>> >>> Is it possible to distinguish between app uninstall vs push notification disable (where the app remains installed)? >>> >>>> >>>> Something that would be interesting as well, might be the following data: >>>> - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) >>> would this be a good proxy for letting me know how often an end-user is using the app? >>>> - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) >>>> - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) >>>> >>>> >>>> While the initial focus should be around the message related metrics, capturing some device data is nice too. >>>> >>>> >>>> Any thoughts ? >>>> >>>> -Matthias >>>> >>>> >>>> PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! >>>> >>>> >>>> >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-116 >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 >>>> [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 >>>> [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 >>>> [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/6fb36958/attachment-0001.html From matzew at apache.org Mon Apr 7 09:55:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 15:55:03 +0200 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: On Mon, Apr 7, 2014 at 3:50 PM, Michi Oshima wrote: > Hi. Thank you all. I successfully got multiple registration working last > week. > > > 1. Sebastien, what is the purpose of using the local storage to store > the mapping between channel ID and category? I'm at this time keeping the > map in memory. > 2. Matthias, using the current time makes sense. I'll do that. Why > didn't I think about that? > > eventually, the Mozilla guys figured that out as well. The newest/latest spec (of SimplePush) contains that now: no body; server will use the current timestamp; Note: our SPS server is being updated to do that too - we will do the same for UPS and our java client > > Thank you all again for your attention and advice thus far. > > Michi > > > On Fri, Apr 4, 2014 at 5:13 AM, Matthias Wessendorf wrote: > >> Hello Michi, >> >> IMO the version number string is a bit odd for most backend applications. >> :-) If you don't want to maintain a "version per channel", I'd just do the >> current timestamp (e.g. Date.now() in JS) >> >> -M >> >> >> On Fri, Apr 4, 2014 at 11:04 AM, Sebastien Blanc wrote: >> >>> Hey Again ! >>> >>> To make it even easier I've deployed a "multi-channel" version of the >>> quickstart here : http://mutlichannels-sblanc.rhcloud.com/ >>> Then you can fire the CURLs for each category to see how it can handle >>> different channels : >>> >>> curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ >>> "categories" :["mail"], >>> "simple-push": "version=1111" >>> >>> }' https://hackergartenups-sblanc.rhcloud.com/rest/sender >>> >>> >>> >>> curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ >>> >>> "categories" :["news"], >>> "simple-push": "version=1112" >>> }' https://hackergartenups-sblanc.rhcloud.com/rest/sender >>> >>> >>> >>> >>> If you fire these multiple time don't forget to change the version value ! >>> >>> >>> >>> >>> >>> On Fri, Apr 4, 2014 at 10:02 AM, Sebastien Blanc wrote: >>> >>>> Hey Michi, >>>> I realized that the code I pointed you to could be a bit confusing and >>>> also contains a small bug. >>>> >>>> I wrote this gist based on the quickstart example. Basically we >>>> register to 2 channels : mail and news, we store the channelID and map that >>>> with a String containing the service name, then in the onNotification we >>>> check which service to call : >>>> >>>> https://gist.github.com/sebastienblanc/9970129 >>>> >>>> Hope this example will make more sense ! >>>> >>>> Seb >>>> >>>> >>>> >>>> >>>> On Thu, Apr 3, 2014 at 8:53 PM, Sebastien Blanc wrote: >>>> >>>>> Looks at this more advanced example here >>>>> https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js >>>>> >>>>> >>>>> You will see that we register 2 times and we get 2 different >>>>> endpoints. Then you have to keep somewhere a link between your endpoint and >>>>> let's say the service you want to associate to , like using the >>>>> localStorage : localStorage.setItem(theEndpoint, "scoreService"); >>>>> >>>>> Then when you receive a message, besides the version (which is btw not >>>>> mandatory to be used) you also receive the channelId, then you can choose >>>>> which service to call : >>>>> >>>>> >>>>> navigator.setMessageHandler("push", function(message) { >>>>> >>>>> >>>>> >>>>> >>>>> var myService = localStorage.get(message.channelID); >>>>> //now based on this you can call your specific log >>>>> }); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I Hope this will help you. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima wrote: >>>>> >>>>>> Thank you, Sebastien. I'll try multiple registration. Although, I'm >>>>>> a bit confused. Because: >>>>>> >>>>>> >>>>>> 1. As far as I can see from the quick start example, >>>>>> per SPS Client, there'll be one registration with the SimplePush server. >>>>>> That means I only get one endpoint. >>>>>> 2. So I'd use the same endpoint to register multiple times with >>>>>> the unified push server using different category each time. >>>>>> 3. When the SPS client receives a version number, how can it >>>>>> associate a given version number to a particular category? (I've not seen >>>>>> categories reaching the client.) >>>>>> >>>>>> >>>>>> Am I wrong somewhere above? >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima >>>>>> > wrote: >>>>>>> >>>>>>>> Hi Lucas, >>>>>>>> >>>>>>>> Following might do what I want (sending a "door bell" message in >>>>>>>> one shot to all variants)? Send a unified message like the following one: >>>>>>>> >>>>>>>> >>>>>>>> - '{ "message": { "version":"123" }, "simple-push": >>>>>>>> "version=123" }' >>>>>>>> >>>>>>>> >>>>>>>> One slight deviation is that mobile variants like iOS and Android >>>>>>>> will get the message regardless of whether the the version number is "old" >>>>>>>> or not. Is this correct? >>>>>>>> >>>>>>> >>>>>>> Yes iOS/Android ignore the version since that is really something >>>>>>> tied to Simple Push >>>>>>> >>>>>>>> >>>>>>>> So I revisited the SimplePush spec, >>>>>>>> and I noticed it describes support for subscription to multiple channels. >>>>>>>> >>>>>>>> Aerogear doesn't allow multiple channels per installation, correct? >>>>>>>> I dug up an old post from Matthias: >>>>>>>> >>>>>>>> >>>>>>>> - >>>>>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>>>>>>> >>>>>>>> Well yes, but multiple installations can belong to the same SPS >>>>>>> Client. You can register multiple time, differentiate them by passing them >>>>>>> a category for instance. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> - >>>>>>>> >>>>>>>> >>>>>>>> If an installation can subscribe to multiple channels, then it >>>>>>>> would allow me to get what I originally asked about: >>>>>>>> >>>>>>>> Me: 'My client application (javascript on browser) holds multiple >>>>>>>> types of data. It would be nice if I can send a notification saying >>>>>>>> "there's an update for this data type", rather than just "there's an >>>>>>>> update". Or, in general it'd be nice if I can send more information than >>>>>>>> just a monotonically increasing number. ' >>>>>>>> >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>> >>>>>>> That would be quite a breaking change and we need to discuss that, >>>>>>> in the same time, as said before, you can still register a single client to >>>>>>> multiple channels (and es you will have multiple installations but that do >>>>>>> not really matter) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist < >>>>>>>> lholmqui at redhat.com> wrote: >>>>>>>> >>>>>>>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>>>>>>> disturbing auctions for 30 minutes. I'll read it again. >>>>>>>>> >>>>>>>>> Another question, is there a way to send a "door bell" message *in >>>>>>>>> one shot* to all iOS, Android, and SimplePush variants? >>>>>>>>> >>>>>>>>> >>>>>>>>> well, iOS and Android notifications aren't really doorbells, but >>>>>>>>> you can send a "message" to all clients that are registered in your Push >>>>>>>>> Server. >>>>>>>>> >>>>>>>>> we have a Java client >>>>>>>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>>>>> >>>>>>>>> and a node.js client for this >>>>>>>>> https://www.npmjs.org/package/aerogear-sender-client >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (m:) >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist < >>>>>>>>> lholmqui at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> SimplePush works only as a "door bell" to tell your app, hey, >>>>>>>>>> you should go look on your server. >>>>>>>>>> >>>>>>>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Yesterday I managed to send my first message to a browser. >>>>>>>>>> Thanks for all your help. >>>>>>>>>> >>>>>>>>>> I've tried sending a few different types of messages, and it so >>>>>>>>>> far appears to me the only thing I can send to a simple push client is a >>>>>>>>>> version number. Can a simple push client receive anything else other than >>>>>>>>>> version numbers? If so, what does the sender need to do, and what does the >>>>>>>>>> client need to do? (If there is a good example somewhere online I can work >>>>>>>>>> from that also.) >>>>>>>>>> >>>>>>>>>> My client application (javascript on browser) holds multiple >>>>>>>>>> types of data. It would be nice if I can send a notification saying >>>>>>>>>> "there's an update for this data type", rather than just "there's an >>>>>>>>>> update". Or, in general it'd be nice if I can send more information than >>>>>>>>>> just a monotonically increasing number. >>>>>>>>>> >>>>>>>>>> Here's my setup: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>>>>>>> - Sender is a JBoss app using >>>>>>>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>>>>>>> (unifiedpush-java-client-0.5.0.jar). >>>>>>>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I read this documentation, >>>>>>>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>>>>>>> variants use the "extra simple-push object" only. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> >>>>>>>>>> Michi Oshima >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/1ed18bdc/attachment-0001.html From bsutter at redhat.com Mon Apr 7 08:40:25 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 7 Apr 2014 08:40:25 -0400 Subject: [aerogear-dev] [UnifiedPush Server] Using JBoss Logging ? In-Reply-To: References: <20140407093112.7ab34985@kapy-ntb-x220> Message-ID: Like with any dependency....we use it, we own it :-) On Apr 7, 2014, at 8:31 AM, Matthias Wessendorf wrote: > JUL it is ;-) > > unless we are forced to not use JUL ;-) > > > On Mon, Apr 7, 2014 at 2:28 PM, Burr Sutter wrote: > I can see UPS needing to run on other containers (Tomcat, WF Core, etc) and I was assuming that JBoss Logging could be picked and carried around like other logging frameworks. > > > > On Apr 7, 2014, at 3:49 AM, Matthias Wessendorf wrote: > >> Oh, yeah - those are valid concerns. >> >> Let's stick to JUL ? >> >> >> >> >> On Mon, Apr 7, 2014 at 9:31 AM, Karel Piwko wrote: >> I like JUL because it has no dependencies, stable API (albeit not feature >> complete) and no class path clashes. >> >> If you go with JBoss Logging, what would be the strategy for: >> >> 1/ Running UPS on Server in application platform that does not provide JBoss >> Logging? >> 2/ JBossLogging version conflicts - WF provides version 3.2, UPS needs 3.1+ and >> KC needs 3.0+? >> >> Thanks, >> >> Karel >> >> >> >> On Sat, 5 Apr 2014 14:27:52 +0200 >> Matthias Wessendorf wrote: >> >> > Hello, >> > >> > right now we are using JUL for logging. That works fine, so far :-) >> > >> > However related projects (e.g. Keycloak / LiveOak) are using JBoss Logging. >> > I somewhat feel that it's perhaps not a bad idea if we would use JBoss >> > logging as well... >> > >> > I know there are a gazillion different Java logging frameworks out there >> > (yikes), but my question is really: keep JUL or go with JBoss-Logging :) >> > >> > >> > Thanks! >> > Matthias >> > >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/e79b2af3/attachment.html From matzew at apache.org Mon Apr 7 09:55:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 15:55:51 +0200 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: Oh, btw. if you don't mind - feel free to share (if you can) what you are building :) We are always interested in that ;-) -Matthias On Mon, Apr 7, 2014 at 3:55 PM, Matthias Wessendorf wrote: > > > > On Mon, Apr 7, 2014 at 3:50 PM, Michi Oshima wrote: > >> Hi. Thank you all. I successfully got multiple registration working >> last week. >> >> >> 1. Sebastien, what is the purpose of using the local storage to store >> the mapping between channel ID and category? I'm at this time keeping the >> map in memory. >> 2. Matthias, using the current time makes sense. I'll do that. Why >> didn't I think about that? >> >> eventually, the Mozilla guys figured that out as well. > The newest/latest spec (of SimplePush) contains that now: no body; server > will use the current timestamp; > > Note: our SPS server is being updated to do that too - we will do the same > for UPS and our java client > > > >> >> Thank you all again for your attention and advice thus far. >> >> Michi >> >> >> On Fri, Apr 4, 2014 at 5:13 AM, Matthias Wessendorf wrote: >> >>> Hello Michi, >>> >>> IMO the version number string is a bit odd for most backend >>> applications. :-) If you don't want to maintain a "version per channel", >>> I'd just do the current timestamp (e.g. Date.now() in JS) >>> >>> -M >>> >>> >>> On Fri, Apr 4, 2014 at 11:04 AM, Sebastien Blanc wrote: >>> >>>> Hey Again ! >>>> >>>> To make it even easier I've deployed a "multi-channel" version of the >>>> quickstart here : http://mutlichannels-sblanc.rhcloud.com/ >>>> Then you can fire the CURLs for each category to see how it can handle >>>> different channels : >>>> >>>> curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ >>>> "categories" :["mail"], >>>> "simple-push": "version=1111" >>>> >>>> }' https://hackergartenups-sblanc.rhcloud.com/rest/sender >>>> >>>> >>>> >>>> curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ >>>> >>>> "categories" :["news"], >>>> "simple-push": "version=1112" >>>> }' https://hackergartenups-sblanc.rhcloud.com/rest/sender >>>> >>>> >>>> >>>> >>>> >>>> If you fire these multiple time don't forget to change the version value ! >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Apr 4, 2014 at 10:02 AM, Sebastien Blanc wrote: >>>> >>>>> Hey Michi, >>>>> I realized that the code I pointed you to could be a bit confusing and >>>>> also contains a small bug. >>>>> >>>>> I wrote this gist based on the quickstart example. Basically we >>>>> register to 2 channels : mail and news, we store the channelID and map that >>>>> with a String containing the service name, then in the onNotification we >>>>> check which service to call : >>>>> >>>>> https://gist.github.com/sebastienblanc/9970129 >>>>> >>>>> Hope this example will make more sense ! >>>>> >>>>> Seb >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Apr 3, 2014 at 8:53 PM, Sebastien Blanc wrote: >>>>> >>>>>> Looks at this more advanced example here >>>>>> https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js >>>>>> >>>>>> >>>>>> You will see that we register 2 times and we get 2 different >>>>>> endpoints. Then you have to keep somewhere a link between your endpoint and >>>>>> let's say the service you want to associate to , like using the >>>>>> localStorage : localStorage.setItem(theEndpoint, "scoreService"); >>>>>> >>>>>> Then when you receive a message, besides the version (which is btw >>>>>> not mandatory to be used) you also receive the channelId, then you can >>>>>> choose which service to call : >>>>>> >>>>>> >>>>>> navigator.setMessageHandler("push", function(message) { >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> var myService = localStorage.get(message.channelID); >>>>>> //now based on this you can call your specific log >>>>>> }); >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I Hope this will help you. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima wrote: >>>>>> >>>>>>> Thank you, Sebastien. I'll try multiple registration. Although, >>>>>>> I'm a bit confused. Because: >>>>>>> >>>>>>> >>>>>>> 1. As far as I can see from the quick start example, >>>>>>> per SPS Client, there'll be one registration with the SimplePush server. >>>>>>> That means I only get one endpoint. >>>>>>> 2. So I'd use the same endpoint to register multiple times with >>>>>>> the unified push server using different category each time. >>>>>>> 3. When the SPS client receives a version number, how can it >>>>>>> associate a given version number to a particular category? (I've not seen >>>>>>> categories reaching the client.) >>>>>>> >>>>>>> >>>>>>> Am I wrong somewhere above? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc < >>>>>>> scm.blanc at gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima < >>>>>>>> michi.oshima at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Lucas, >>>>>>>>> >>>>>>>>> Following might do what I want (sending a "door bell" message in >>>>>>>>> one shot to all variants)? Send a unified message like the following one: >>>>>>>>> >>>>>>>>> >>>>>>>>> - '{ "message": { "version":"123" }, "simple-push": >>>>>>>>> "version=123" }' >>>>>>>>> >>>>>>>>> >>>>>>>>> One slight deviation is that mobile variants like iOS and Android >>>>>>>>> will get the message regardless of whether the the version number is "old" >>>>>>>>> or not. Is this correct? >>>>>>>>> >>>>>>>> >>>>>>>> Yes iOS/Android ignore the version since that is really something >>>>>>>> tied to Simple Push >>>>>>>> >>>>>>>>> >>>>>>>>> So I revisited the SimplePush spec, >>>>>>>>> and I noticed it describes support for subscription to multiple channels. >>>>>>>>> >>>>>>>>> Aerogear doesn't allow multiple channels per installation, >>>>>>>>> correct? I dug up an old post from Matthias: >>>>>>>>> >>>>>>>>> >>>>>>>>> - >>>>>>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>>>>>>>> >>>>>>>>> Well yes, but multiple installations can belong to the same SPS >>>>>>>> Client. You can register multiple time, differentiate them by passing them >>>>>>>> a category for instance. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> - >>>>>>>>> >>>>>>>>> >>>>>>>>> If an installation can subscribe to multiple channels, then it >>>>>>>>> would allow me to get what I originally asked about: >>>>>>>>> >>>>>>>>> Me: 'My client application (javascript on browser) holds multiple >>>>>>>>> types of data. It would be nice if I can send a notification saying >>>>>>>>> "there's an update for this data type", rather than just "there's an >>>>>>>>> update". Or, in general it'd be nice if I can send more information than >>>>>>>>> just a monotonically increasing number. ' >>>>>>>>> >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>> >>>>>>>> That would be quite a breaking change and we need to discuss that, >>>>>>>> in the same time, as said before, you can still register a single client to >>>>>>>> multiple channels (and es you will have multiple installations but that do >>>>>>>> not really matter) >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist < >>>>>>>>> lholmqui at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>>>>>>>> disturbing auctions for 30 minutes. I'll read it again. >>>>>>>>>> >>>>>>>>>> Another question, is there a way to send a "door bell" message >>>>>>>>>> *in one shot* to all iOS, Android, and SimplePush variants? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> well, iOS and Android notifications aren't really doorbells, but >>>>>>>>>> you can send a "message" to all clients that are registered in your Push >>>>>>>>>> Server. >>>>>>>>>> >>>>>>>>>> we have a Java client >>>>>>>>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>>>>>> >>>>>>>>>> and a node.js client for this >>>>>>>>>> https://www.npmjs.org/package/aerogear-sender-client >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (m:) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist < >>>>>>>>>> lholmqui at redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> SimplePush works only as a "door bell" to tell your app, hey, >>>>>>>>>>> you should go look on your server. >>>>>>>>>>> >>>>>>>>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima < >>>>>>>>>>> michi.oshima at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Yesterday I managed to send my first message to a browser. >>>>>>>>>>> Thanks for all your help. >>>>>>>>>>> >>>>>>>>>>> I've tried sending a few different types of messages, and it so >>>>>>>>>>> far appears to me the only thing I can send to a simple push client is a >>>>>>>>>>> version number. Can a simple push client receive anything else other than >>>>>>>>>>> version numbers? If so, what does the sender need to do, and what does the >>>>>>>>>>> client need to do? (If there is a good example somewhere online I can work >>>>>>>>>>> from that also.) >>>>>>>>>>> >>>>>>>>>>> My client application (javascript on browser) holds multiple >>>>>>>>>>> types of data. It would be nice if I can send a notification saying >>>>>>>>>>> "there's an update for this data type", rather than just "there's an >>>>>>>>>>> update". Or, in general it'd be nice if I can send more information than >>>>>>>>>>> just a monotonically increasing number. >>>>>>>>>>> >>>>>>>>>>> Here's my setup: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>>>>>>>> - Sender is a JBoss app using >>>>>>>>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>>>>>>>> (unifiedpush-java-client-0.5.0.jar). >>>>>>>>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I read this documentation, >>>>>>>>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>>>>>>>> variants use the "extra simple-push object" only. >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> >>>>>>>>>>> Michi Oshima >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/bcafcfad/attachment-0001.html From bsutter at redhat.com Mon Apr 7 09:56:13 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 7 Apr 2014 09:56:13 -0400 Subject: [aerogear-dev] cordova hello world In-Reply-To: References: Message-ID: I assume the list is a representation of all push messages received within a given "session"? On Apr 7, 2014, at 9:39 AM, Erik Jan de Wit wrote: > How about a list that looks like this: > > https://www.dropbox.com/s/d8cn0xm7lfm5mts/cordova%20list%20screenshot.png > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From scm.blanc at gmail.com Mon Apr 7 09:59:26 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 7 Apr 2014 15:59:26 +0200 Subject: [aerogear-dev] cordova hello world In-Reply-To: <25A9245F-0DFE-4FE9-88B5-0C1994582661@redhat.com> References: <25A9245F-0DFE-4FE9-88B5-0C1994582661@redhat.com> Message-ID: On Mon, Apr 7, 2014 at 3:43 PM, Erik Jan de Wit wrote: > and what do we use for a splash screen? > > I think we could use the same as the one used in JDBS, have to check that. > On 7 Apr,2014, at 15:41 , Matthias Wessendorf wrote: > > yeah, looks pretty nice :-) > > > > > On Mon, Apr 7, 2014 at 3:39 PM, Erik Jan de Wit wrote: > >> How about a list that looks like this: >> >> https://www.dropbox.com/s/d8cn0xm7lfm5mts/cordova%20list%20screenshot.png >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/6983c3b6/attachment.html From edewit at redhat.com Mon Apr 7 10:00:42 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 7 Apr 2014 16:00:42 +0200 Subject: [aerogear-dev] cordova hello world In-Reply-To: References: Message-ID: You assume correct, I tried to make it look a bit like the others (android and iOS) On 7 Apr,2014, at 15:56 , Burr Sutter wrote: > I assume the list is a representation of all push messages received within a given "session"? > > > On Apr 7, 2014, at 9:39 AM, Erik Jan de Wit wrote: > >> How about a list that looks like this: >> >> https://www.dropbox.com/s/d8cn0xm7lfm5mts/cordova%20list%20screenshot.png >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Mon Apr 7 10:14:05 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 7 Apr 2014 17:14:05 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi our meeting minutes: Meeting ended Mon Apr 7 13:58:33 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-07-13.47.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-07-13.47.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-07-13.47.log.html On Apr 7, 2014, at 9:58 AM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140407 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/ad378abd/attachment.html From edewit at redhat.com Mon Apr 7 10:51:44 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 7 Apr 2014 16:51:44 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: <530B54FC-52EB-46CF-9983-9E24859FCE91@redhat.com> References: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> <7A42B7B1-39AB-426E-A8AF-5D369634AF65@gmail.com> <530B54FC-52EB-46CF-9983-9E24859FCE91@redhat.com> Message-ID: >> >> On the other hand, your core service has yet some things that must be fixed / perfectionated (I'm talking only about Cordova). I also think that you should consider geo-tagged notifications, which is a very important need. > I agree - but these things are not necessarily mutually exclusive :-) Our aerodoc demo has an example of this use case. > > On the Cordova side of things, I would like to know more about what needs fine-tuning. Docs? definitely need work > And our push plugin is a wee bit fat for Android, needs to go on a diet, dexing takes a while Once the modularisation of android is complete the push plugin will be the first to benefit from that. > And the JS API needed some clean-up, you have seen Erik's proposals on that item > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/20f5a855/attachment.html From scm.blanc at gmail.com Mon Apr 7 11:22:41 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 7 Apr 2014 17:22:41 +0200 Subject: [aerogear-dev] Possible to send anything other than version number to simple push? In-Reply-To: References: <7DA73010-8948-451F-8B64-1487C280CE53@redhat.com> Message-ID: On Mon, Apr 7, 2014 at 3:50 PM, Michi Oshima wrote: > Hi. Thank you all. I successfully got multiple registration working last > week. > > > 1. Sebastien, what is the purpose of using the local storage to store > the mapping between channel ID and category? I'm at this time keeping the > map in memory. > > Sure, you can keep it in memory , no particular purpose for storing it into LS :) > > 1. Matthias, using the current time makes sense. I'll do that. Why > didn't I think about that? > > > Thank you all again for your attention and advice thus far. > > Michi > > > On Fri, Apr 4, 2014 at 5:13 AM, Matthias Wessendorf wrote: > >> Hello Michi, >> >> IMO the version number string is a bit odd for most backend applications. >> :-) If you don't want to maintain a "version per channel", I'd just do the >> current timestamp (e.g. Date.now() in JS) >> >> -M >> >> >> On Fri, Apr 4, 2014 at 11:04 AM, Sebastien Blanc wrote: >> >>> Hey Again ! >>> >>> To make it even easier I've deployed a "multi-channel" version of the >>> quickstart here : http://mutlichannels-sblanc.rhcloud.com/ >>> Then you can fire the CURLs for each category to see how it can handle >>> different channels : >>> >>> curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ >>> "categories" :["mail"], >>> "simple-push": "version=1111" >>> >>> }' https://hackergartenups-sblanc.rhcloud.com/rest/sender >>> >>> >>> >>> curl -3 -u "a0f6a30e-0cda-49a4-9901-bcfdc30e5c7a:b986c86e-4092-4728-a1ed-7ac68f6d0f7a" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ >>> >>> "categories" :["news"], >>> "simple-push": "version=1112" >>> }' https://hackergartenups-sblanc.rhcloud.com/rest/sender >>> >>> >>> >>> >>> If you fire these multiple time don't forget to change the version value ! >>> >>> >>> >>> >>> >>> On Fri, Apr 4, 2014 at 10:02 AM, Sebastien Blanc wrote: >>> >>>> Hey Michi, >>>> I realized that the code I pointed you to could be a bit confusing and >>>> also contains a small bug. >>>> >>>> I wrote this gist based on the quickstart example. Basically we >>>> register to 2 channels : mail and news, we store the channelID and map that >>>> with a String containing the service name, then in the onNotification we >>>> check which service to call : >>>> >>>> https://gist.github.com/sebastienblanc/9970129 >>>> >>>> Hope this example will make more sense ! >>>> >>>> Seb >>>> >>>> >>>> >>>> >>>> On Thu, Apr 3, 2014 at 8:53 PM, Sebastien Blanc wrote: >>>> >>>>> Looks at this more advanced example here >>>>> https://github.com/aerogear/aerogear-aerodoc-web/blob/master/scripts/services/notifierService.js >>>>> >>>>> >>>>> You will see that we register 2 times and we get 2 different >>>>> endpoints. Then you have to keep somewhere a link between your endpoint and >>>>> let's say the service you want to associate to , like using the >>>>> localStorage : localStorage.setItem(theEndpoint, "scoreService"); >>>>> >>>>> Then when you receive a message, besides the version (which is btw not >>>>> mandatory to be used) you also receive the channelId, then you can choose >>>>> which service to call : >>>>> >>>>> >>>>> navigator.setMessageHandler("push", function(message) { >>>>> >>>>> >>>>> >>>>> >>>>> var myService = localStorage.get(message.channelID); >>>>> //now based on this you can call your specific log >>>>> }); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I Hope this will help you. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Apr 3, 2014 at 8:03 PM, Michi Oshima wrote: >>>>> >>>>>> Thank you, Sebastien. I'll try multiple registration. Although, I'm >>>>>> a bit confused. Because: >>>>>> >>>>>> >>>>>> 1. As far as I can see from the quick start example, >>>>>> per SPS Client, there'll be one registration with the SimplePush server. >>>>>> That means I only get one endpoint. >>>>>> 2. So I'd use the same endpoint to register multiple times with >>>>>> the unified push server using different category each time. >>>>>> 3. When the SPS client receives a version number, how can it >>>>>> associate a given version number to a particular category? (I've not seen >>>>>> categories reaching the client.) >>>>>> >>>>>> >>>>>> Am I wrong somewhere above? >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 3, 2014 at 10:53 AM, Sebastien Blanc >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 3, 2014 at 4:41 PM, Michi Oshima >>>>>> > wrote: >>>>>>> >>>>>>>> Hi Lucas, >>>>>>>> >>>>>>>> Following might do what I want (sending a "door bell" message in >>>>>>>> one shot to all variants)? Send a unified message like the following one: >>>>>>>> >>>>>>>> >>>>>>>> - '{ "message": { "version":"123" }, "simple-push": >>>>>>>> "version=123" }' >>>>>>>> >>>>>>>> >>>>>>>> One slight deviation is that mobile variants like iOS and Android >>>>>>>> will get the message regardless of whether the the version number is "old" >>>>>>>> or not. Is this correct? >>>>>>>> >>>>>>> >>>>>>> Yes iOS/Android ignore the version since that is really something >>>>>>> tied to Simple Push >>>>>>> >>>>>>>> >>>>>>>> So I revisited the SimplePush spec, >>>>>>>> and I noticed it describes support for subscription to multiple channels. >>>>>>>> >>>>>>>> Aerogear doesn't allow multiple channels per installation, correct? >>>>>>>> I dug up an old post from Matthias: >>>>>>>> >>>>>>>> >>>>>>>> - >>>>>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-SimplePush-Registration-of-quot-Mobile-Variant-instance-quot-w-Unified-Push-Server-tt2805.html#none >>>>>>>> >>>>>>>> Well yes, but multiple installations can belong to the same SPS >>>>>>> Client. You can register multiple time, differentiate them by passing them >>>>>>> a category for instance. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> - >>>>>>>> >>>>>>>> >>>>>>>> If an installation can subscribe to multiple channels, then it >>>>>>>> would allow me to get what I originally asked about: >>>>>>>> >>>>>>>> Me: 'My client application (javascript on browser) holds multiple >>>>>>>> types of data. It would be nice if I can send a notification saying >>>>>>>> "there's an update for this data type", rather than just "there's an >>>>>>>> update". Or, in general it'd be nice if I can send more information than >>>>>>>> just a monotonically increasing number. ' >>>>>>>> >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>> >>>>>>> That would be quite a breaking change and we need to discuss that, >>>>>>> in the same time, as said before, you can still register a single client to >>>>>>> multiple channels (and es you will have multiple installations but that do >>>>>>> not really matter) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 2, 2014 at 11:44 AM, Lucas Holmquist < >>>>>>>> lholmqui at redhat.com> wrote: >>>>>>>> >>>>>>>>> On Apr 2, 2014, at 11:38 AM, Michi Oshima >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Thanks, Lucas. I read the spec yesterday and ended up looking at >>>>>>>>> disturbing auctions for 30 minutes. I'll read it again. >>>>>>>>> >>>>>>>>> Another question, is there a way to send a "door bell" message *in >>>>>>>>> one shot* to all iOS, Android, and SimplePush variants? >>>>>>>>> >>>>>>>>> >>>>>>>>> well, iOS and Android notifications aren't really doorbells, but >>>>>>>>> you can send a "message" to all clients that are registered in your Push >>>>>>>>> Server. >>>>>>>>> >>>>>>>>> we have a Java client >>>>>>>>> http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>>>>> >>>>>>>>> and a node.js client for this >>>>>>>>> https://www.npmjs.org/package/aerogear-sender-client >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (m:) >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Apr 2, 2014 at 11:04 AM, Lucas Holmquist < >>>>>>>>> lholmqui at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> SimplePush works only as a "door bell" to tell your app, hey, >>>>>>>>>> you should go look on your server. >>>>>>>>>> >>>>>>>>>> this is the spec https://wiki.mozilla.org/WebAPI/SimplePush >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Apr 2, 2014, at 11:02 AM, Michi Oshima >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Yesterday I managed to send my first message to a browser. >>>>>>>>>> Thanks for all your help. >>>>>>>>>> >>>>>>>>>> I've tried sending a few different types of messages, and it so >>>>>>>>>> far appears to me the only thing I can send to a simple push client is a >>>>>>>>>> version number. Can a simple push client receive anything else other than >>>>>>>>>> version numbers? If so, what does the sender need to do, and what does the >>>>>>>>>> client need to do? (If there is a good example somewhere online I can work >>>>>>>>>> from that also.) >>>>>>>>>> >>>>>>>>>> My client application (javascript on browser) holds multiple >>>>>>>>>> types of data. It would be nice if I can send a notification saying >>>>>>>>>> "there's an update for this data type", rather than just "there's an >>>>>>>>>> update". Or, in general it'd be nice if I can send more information than >>>>>>>>>> just a monotonically increasing number. >>>>>>>>>> >>>>>>>>>> Here's my setup: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - AeroGear Push Server 0.10.0 hosted on OpenShift. >>>>>>>>>> - Sender is a JBoss app using >>>>>>>>>> org.jboss.aerogear.unifiedpush.JavaSender >>>>>>>>>> (unifiedpush-java-client-0.5.0.jar). >>>>>>>>>> - Client is a web browser using aerogear.js 1.4.0. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I read this documentation, >>>>>>>>>> but my wishful thinking refused to interpret it as saying: SimplePush >>>>>>>>>> variants use the "extra simple-push object" only. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> >>>>>>>>>> Michi Oshima >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/ed60f5c8/attachment-0001.html From scm.blanc at gmail.com Mon Apr 7 11:27:04 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 7 Apr 2014 17:27:04 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: Hi, The repo for the UnifiedPush Helloworld has been created : https://github.com/aerogear/aerogear-push-helloworld This repo will be divided into 3 folders , one for each client, let's agree on the names of these. I propose : - aerogear-push-helloworld-android - aerogear-push-helloworld-cordova - aerogear-push-helloworld-ios wdyt ? On Mon, Apr 7, 2014 at 3:41 PM, Matthias Wessendorf wrote: > yes/no :-) > > HelloWorld: just clients -no server code - > https://issues.jboss.org/browse/AGPUSH-588 > > > Quickstarts: server/client > Quickstart-server (epic): > https://issues.jboss.org/browse/AGPUSH-596 > > Quickstart-client (epic): > https://issues.jboss.org/browse/AGPUSH-604 > > but atm, we focus on the HelloWorld; once they are done and documented, we > will get to the Quickstarts > > > > On Mon, Apr 7, 2014 at 3:21 PM, Daniel Bevenius > wrote: > >> Ah my bad. I was assuming the quickstarts were in Java. >> >> >> On 7 April 2014 15:05, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Mon, Apr 7, 2014 at 2:59 PM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> For the package name, was that meant to be uppercase? >>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>> >>> >>> nope - not really; iOS app:name -> HelloWord; package "o.j.a.u" >>> >>> >>>> >>>> >>>> >>>> >>>> On 7 April 2014 14:54, Matthias Wessendorf wrote: >>>> >>>>> Since we start w/ the Hello World example, let's make sure we agree on >>>>> a name :-) >>>>> >>>>> I'd suggest we name it "AeroGear UnifiedPush HelloWorld". >>>>> >>>>> For packages / bundle Identifier, I'd vote for >>>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf >>>> > wrote: >>>>> >>>>>> the GH repos have been created: >>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>> >>>>>> I edited the README to 'define' the (sub)folder structure >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> here are the JIRAs (tasks and epics (which have sub-tasks) for this, >>>>>>> so far: >>>>>>> >>>>>>> Github repo work: >>>>>>> https://issues.jboss.org/browse/AGPUSH-586 >>>>>>> https://issues.jboss.org/browse/AGPUSH-587 >>>>>>> >>>>>>> Hello-World Example work (epic): >>>>>>> https://issues.jboss.org/browse/AGPUSH-588 >>>>>>> >>>>>>> >>>>>>> Quickstart-server (epic): >>>>>>> https://issues.jboss.org/browse/AGPUSH-596 >>>>>>> >>>>>>> Quickstart-client (epic): >>>>>>> https://issues.jboss.org/browse/AGPUSH-604 >>>>>>> >>>>>>> >>>>>>> >>>>>>> It's totally valid to: >>>>>>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if >>>>>>> they have several work units). >>>>>>> >>>>>>> >>>>>>> Greetings, >>>>>>> Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> Hello there, >>>>>>>> >>>>>>>> we recently had talks about creating some simplified quickstarts >>>>>>>> and hello-word demos, related to the UnifiedPush Server and JBoss AS >>>>>>>> developers: >>>>>>>> >>>>>>>> * Hello World (No Server Code - just client receiving push, no >>>>>>>> fancy (complex) UI on the client, nor integrated into a Cookbook or >>>>>>>> something that has "dependencies") >>>>>>>> ** Cordova >>>>>>>> ** Android >>>>>>>> >>>>>>>> For iOS that is already there: >>>>>>>> https://github.com/aerogear/aerogear-push-ios-demo >>>>>>>> >>>>>>>> Yes, just usage of the "Push Registration SDKs", is the goal here: >>>>>>>> keep it simple, since native push can be a complicated use-case all on its >>>>>>>> own and so it will be good to make sure we cover the basics here. >>>>>>>> >>>>>>>> >>>>>>>> Beyond the Hello-World, we wanted some different quickstarts. The >>>>>>>> "server" components that come to mind would be: >>>>>>>> >>>>>>>> *Secured CRUD + Push Integration (Java Sender) >>>>>>>> ** JAX-RS + PicketLink >>>>>>>> ** SpringMVC/Spring Security >>>>>>>> ** JAX-RS + Apache Camel >>>>>>>> >>>>>>>> These need to function on both JBoss AS 7.X and EAP. >>>>>>>> >>>>>>>> Josh, from the JDF team, has already said he wants to help on the >>>>>>>> server projects (especially the JAX-RS/PL and Spring ones). yay! >>>>>>>> Note: Josh already has a simple backend started that is used in JDF >>>>>>>> quickstarts that would be good to re-use to make it easier for developers >>>>>>>> to transition from one to other. >>>>>>>> >>>>>>>> >>>>>>>> The goal would be the SERVER acts same to outside (identical REST >>>>>>>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>>>>>>> Camel)) >>>>>>>> >>>>>>>> For these different servers, there would be mobile apps needed: >>>>>>>> * Android >>>>>>>> * Cordova >>>>>>>> * iOS >>>>>>>> >>>>>>>> >>>>>>>> The idea would be to keep them simple and straightforward as well, >>>>>>>> e.g. for iOS that means plain usage of NSURLConnection / NSURLSession. But >>>>>>>> for the "push registration" of the client, >>>>>>>> the iOS-push SDK would be used (same/similar would apply to Cordova >>>>>>>> or Android). Similar to the above 'Hello World', the quickstarts are going >>>>>>>> to be focused only on Push functionality, so for these we would leave out >>>>>>>> pipes and such until later versions. >>>>>>>> >>>>>>>> >>>>>>>> I will be creating Epics and subtasks in JIRA for this. >>>>>>>> >>>>>>>> For the location of all these projects, I had this "uber repo" >>>>>>>> location in mind: >>>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>> >>>>>>>> Greetings, >>>>>>>> Matthias >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/6c4e56c4/attachment.html From matzew at apache.org Mon Apr 7 11:28:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 17:28:29 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: keep it simple? -android -cordova -ios the ag-push-hello is redundant, IMO On Mon, Apr 7, 2014 at 5:27 PM, Sebastien Blanc wrote: > Hi, > The repo for the UnifiedPush Helloworld has been created : > https://github.com/aerogear/aerogear-push-helloworld > This repo will be divided into 3 folders , one for each client, let's > agree on the names of these. I propose : > > - aerogear-push-helloworld-android > - aerogear-push-helloworld-cordova > - aerogear-push-helloworld-ios > > wdyt ? > > > > > On Mon, Apr 7, 2014 at 3:41 PM, Matthias Wessendorf wrote: > >> yes/no :-) >> >> HelloWorld: just clients -no server code - >> https://issues.jboss.org/browse/AGPUSH-588 >> >> >> Quickstarts: server/client >> Quickstart-server (epic): >> https://issues.jboss.org/browse/AGPUSH-596 >> >> Quickstart-client (epic): >> https://issues.jboss.org/browse/AGPUSH-604 >> >> but atm, we focus on the HelloWorld; once they are done and documented, >> we will get to the Quickstarts >> >> >> >> On Mon, Apr 7, 2014 at 3:21 PM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Ah my bad. I was assuming the quickstarts were in Java. >>> >>> >>> On 7 April 2014 15:05, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Mon, Apr 7, 2014 at 2:59 PM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> For the package name, was that meant to be uppercase? >>>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>>> >>>> >>>> nope - not really; iOS app:name -> HelloWord; package "o.j.a.u" >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 7 April 2014 14:54, Matthias Wessendorf wrote: >>>>> >>>>>> Since we start w/ the Hello World example, let's make sure we agree >>>>>> on a name :-) >>>>>> >>>>>> I'd suggest we name it "AeroGear UnifiedPush HelloWorld". >>>>>> >>>>>> For packages / bundle Identifier, I'd vote for >>>>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>>>> >>>>>> >>>>>> -Matthias >>>>>> >>>>>> >>>>>> On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> the GH repos have been created: >>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>> >>>>>>> I edited the README to 'define' the (sub)folder structure >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> here are the JIRAs (tasks and epics (which have sub-tasks) for >>>>>>>> this, so far: >>>>>>>> >>>>>>>> Github repo work: >>>>>>>> https://issues.jboss.org/browse/AGPUSH-586 >>>>>>>> https://issues.jboss.org/browse/AGPUSH-587 >>>>>>>> >>>>>>>> Hello-World Example work (epic): >>>>>>>> https://issues.jboss.org/browse/AGPUSH-588 >>>>>>>> >>>>>>>> >>>>>>>> Quickstart-server (epic): >>>>>>>> https://issues.jboss.org/browse/AGPUSH-596 >>>>>>>> >>>>>>>> Quickstart-client (epic): >>>>>>>> https://issues.jboss.org/browse/AGPUSH-604 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It's totally valid to: >>>>>>>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if >>>>>>>> they have several work units). >>>>>>>> >>>>>>>> >>>>>>>> Greetings, >>>>>>>> Matthias >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> Hello there, >>>>>>>>> >>>>>>>>> we recently had talks about creating some simplified quickstarts >>>>>>>>> and hello-word demos, related to the UnifiedPush Server and JBoss AS >>>>>>>>> developers: >>>>>>>>> >>>>>>>>> * Hello World (No Server Code - just client receiving push, no >>>>>>>>> fancy (complex) UI on the client, nor integrated into a Cookbook or >>>>>>>>> something that has "dependencies") >>>>>>>>> ** Cordova >>>>>>>>> ** Android >>>>>>>>> >>>>>>>>> For iOS that is already there: >>>>>>>>> https://github.com/aerogear/aerogear-push-ios-demo >>>>>>>>> >>>>>>>>> Yes, just usage of the "Push Registration SDKs", is the goal here: >>>>>>>>> keep it simple, since native push can be a complicated use-case all on its >>>>>>>>> own and so it will be good to make sure we cover the basics here. >>>>>>>>> >>>>>>>>> >>>>>>>>> Beyond the Hello-World, we wanted some different quickstarts. The >>>>>>>>> "server" components that come to mind would be: >>>>>>>>> >>>>>>>>> *Secured CRUD + Push Integration (Java Sender) >>>>>>>>> ** JAX-RS + PicketLink >>>>>>>>> ** SpringMVC/Spring Security >>>>>>>>> ** JAX-RS + Apache Camel >>>>>>>>> >>>>>>>>> These need to function on both JBoss AS 7.X and EAP. >>>>>>>>> >>>>>>>>> Josh, from the JDF team, has already said he wants to help on the >>>>>>>>> server projects (especially the JAX-RS/PL and Spring ones). yay! >>>>>>>>> Note: Josh already has a simple backend started that is used in >>>>>>>>> JDF quickstarts that would be good to re-use to make it easier for >>>>>>>>> developers to transition from one to other. >>>>>>>>> >>>>>>>>> >>>>>>>>> The goal would be the SERVER acts same to outside (identical REST >>>>>>>>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>>>>>>>> Camel)) >>>>>>>>> >>>>>>>>> For these different servers, there would be mobile apps needed: >>>>>>>>> * Android >>>>>>>>> * Cordova >>>>>>>>> * iOS >>>>>>>>> >>>>>>>>> >>>>>>>>> The idea would be to keep them simple and straightforward as well, >>>>>>>>> e.g. for iOS that means plain usage of NSURLConnection / NSURLSession. But >>>>>>>>> for the "push registration" of the client, >>>>>>>>> the iOS-push SDK would be used (same/similar would apply to >>>>>>>>> Cordova or Android). Similar to the above 'Hello World', the quickstarts >>>>>>>>> are going to be focused only on Push functionality, so for these we would >>>>>>>>> leave out pipes and such until later versions. >>>>>>>>> >>>>>>>>> >>>>>>>>> I will be creating Epics and subtasks in JIRA for this. >>>>>>>>> >>>>>>>>> For the location of all these projects, I had this "uber repo" >>>>>>>>> location in mind: >>>>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at 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 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/f685f37e/attachment-0001.html From scm.blanc at gmail.com Mon Apr 7 11:33:09 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 7 Apr 2014 17:33:09 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: You're right , KIS FTW On Mon, Apr 7, 2014 at 5:28 PM, Matthias Wessendorf wrote: > keep it simple? > > -android > -cordova > -ios > > the ag-push-hello is redundant, IMO > > > On Mon, Apr 7, 2014 at 5:27 PM, Sebastien Blanc wrote: > >> Hi, >> The repo for the UnifiedPush Helloworld has been created : >> https://github.com/aerogear/aerogear-push-helloworld >> This repo will be divided into 3 folders , one for each client, let's >> agree on the names of these. I propose : >> >> - aerogear-push-helloworld-android >> - aerogear-push-helloworld-cordova >> - aerogear-push-helloworld-ios >> >> wdyt ? >> >> >> >> >> On Mon, Apr 7, 2014 at 3:41 PM, Matthias Wessendorf wrote: >> >>> yes/no :-) >>> >>> HelloWorld: just clients -no server code - >>> https://issues.jboss.org/browse/AGPUSH-588 >>> >>> >>> Quickstarts: server/client >>> Quickstart-server (epic): >>> https://issues.jboss.org/browse/AGPUSH-596 >>> >>> Quickstart-client (epic): >>> https://issues.jboss.org/browse/AGPUSH-604 >>> >>> but atm, we focus on the HelloWorld; once they are done and documented, >>> we will get to the Quickstarts >>> >>> >>> >>> On Mon, Apr 7, 2014 at 3:21 PM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Ah my bad. I was assuming the quickstarts were in Java. >>>> >>>> >>>> On 7 April 2014 15:05, Matthias Wessendorf wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 7, 2014 at 2:59 PM, Daniel Bevenius < >>>>> daniel.bevenius at gmail.com> wrote: >>>>> >>>>>> For the package name, was that meant to be uppercase? >>>>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>>>> >>>>> >>>>> nope - not really; iOS app:name -> HelloWord; package "o.j.a.u" >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 7 April 2014 14:54, Matthias Wessendorf wrote: >>>>>> >>>>>>> Since we start w/ the Hello World example, let's make sure we agree >>>>>>> on a name :-) >>>>>>> >>>>>>> I'd suggest we name it "AeroGear UnifiedPush HelloWorld". >>>>>>> >>>>>>> For packages / bundle Identifier, I'd vote for >>>>>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>>>>> >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> the GH repos have been created: >>>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>> >>>>>>>> I edited the README to 'define' the (sub)folder structure >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> here are the JIRAs (tasks and epics (which have sub-tasks) for >>>>>>>>> this, so far: >>>>>>>>> >>>>>>>>> Github repo work: >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-586 >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-587 >>>>>>>>> >>>>>>>>> Hello-World Example work (epic): >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-588 >>>>>>>>> >>>>>>>>> >>>>>>>>> Quickstart-server (epic): >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-596 >>>>>>>>> >>>>>>>>> Quickstart-client (epic): >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-604 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> It's totally valid to: >>>>>>>>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if >>>>>>>>> they have several work units). >>>>>>>>> >>>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf < >>>>>>>>> matzew at apache.org> wrote: >>>>>>>>> >>>>>>>>>> Hello there, >>>>>>>>>> >>>>>>>>>> we recently had talks about creating some simplified quickstarts >>>>>>>>>> and hello-word demos, related to the UnifiedPush Server and JBoss AS >>>>>>>>>> developers: >>>>>>>>>> >>>>>>>>>> * Hello World (No Server Code - just client receiving push, no >>>>>>>>>> fancy (complex) UI on the client, nor integrated into a Cookbook or >>>>>>>>>> something that has "dependencies") >>>>>>>>>> ** Cordova >>>>>>>>>> ** Android >>>>>>>>>> >>>>>>>>>> For iOS that is already there: >>>>>>>>>> https://github.com/aerogear/aerogear-push-ios-demo >>>>>>>>>> >>>>>>>>>> Yes, just usage of the "Push Registration SDKs", is the goal >>>>>>>>>> here: keep it simple, since native push can be a complicated use-case all >>>>>>>>>> on its own and so it will be good to make sure we cover the basics here. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Beyond the Hello-World, we wanted some different quickstarts. The >>>>>>>>>> "server" components that come to mind would be: >>>>>>>>>> >>>>>>>>>> *Secured CRUD + Push Integration (Java Sender) >>>>>>>>>> ** JAX-RS + PicketLink >>>>>>>>>> ** SpringMVC/Spring Security >>>>>>>>>> ** JAX-RS + Apache Camel >>>>>>>>>> >>>>>>>>>> These need to function on both JBoss AS 7.X and EAP. >>>>>>>>>> >>>>>>>>>> Josh, from the JDF team, has already said he wants to help on the >>>>>>>>>> server projects (especially the JAX-RS/PL and Spring ones). yay! >>>>>>>>>> Note: Josh already has a simple backend started that is used in >>>>>>>>>> JDF quickstarts that would be good to re-use to make it easier for >>>>>>>>>> developers to transition from one to other. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The goal would be the SERVER acts same to outside (identical REST >>>>>>>>>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>>>>>>>>> Camel)) >>>>>>>>>> >>>>>>>>>> For these different servers, there would be mobile apps needed: >>>>>>>>>> * Android >>>>>>>>>> * Cordova >>>>>>>>>> * iOS >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The idea would be to keep them simple and straightforward as >>>>>>>>>> well, e.g. for iOS that means plain usage of NSURLConnection / >>>>>>>>>> NSURLSession. But for the "push registration" of the client, >>>>>>>>>> the iOS-push SDK would be used (same/similar would apply to >>>>>>>>>> Cordova or Android). Similar to the above 'Hello World', the quickstarts >>>>>>>>>> are going to be focused only on Push functionality, so for these we would >>>>>>>>>> leave out pipes and such until later versions. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I will be creating Epics and subtasks in JIRA for this. >>>>>>>>>> >>>>>>>>>> For the location of all these projects, I had this "uber repo" >>>>>>>>>> location in mind: >>>>>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>>>> >>>>>>>>>> Greetings, >>>>>>>>>> Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at 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 >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/24077025/attachment-0001.html From edewit at redhat.com Mon Apr 7 11:33:08 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 7 Apr 2014 17:33:08 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: Message-ID: <2017946A-5FBC-48FE-9F48-B4ED8D50CF54@redhat.com> As I already called mine cordova +1 on that ;) On 7 Apr,2014, at 17:28 , Matthias Wessendorf wrote: > keep it simple? > > -android > -cordova > -ios > > the ag-push-hello is redundant, IMO > > > On Mon, Apr 7, 2014 at 5:27 PM, Sebastien Blanc wrote: > Hi, > The repo for the UnifiedPush Helloworld has been created : https://github.com/aerogear/aerogear-push-helloworld > This repo will be divided into 3 folders , one for each client, let's agree on the names of these. I propose : > > - aerogear-push-helloworld-android > - aerogear-push-helloworld-cordova > - aerogear-push-helloworld-ios > > wdyt ? > > > > > On Mon, Apr 7, 2014 at 3:41 PM, Matthias Wessendorf wrote: > yes/no :-) > > HelloWorld: just clients -no server code - > https://issues.jboss.org/browse/AGPUSH-588 > > > Quickstarts: server/client > Quickstart-server (epic): > https://issues.jboss.org/browse/AGPUSH-596 > > Quickstart-client (epic): > https://issues.jboss.org/browse/AGPUSH-604 > > but atm, we focus on the HelloWorld; once they are done and documented, we will get to the Quickstarts > > > > On Mon, Apr 7, 2014 at 3:21 PM, Daniel Bevenius wrote: > Ah my bad. I was assuming the quickstarts were in Java. > > > On 7 April 2014 15:05, Matthias Wessendorf wrote: > > > > On Mon, Apr 7, 2014 at 2:59 PM, Daniel Bevenius wrote: > For the package name, was that meant to be uppercase? > "org.jboss.aerogear.unifiedpush.HelloWorld" > > nope - not really; iOS app:name -> HelloWord; package "o.j.a.u" > > > > > > On 7 April 2014 14:54, Matthias Wessendorf wrote: > Since we start w/ the Hello World example, let's make sure we agree on a name :-) > > I'd suggest we name it "AeroGear UnifiedPush HelloWorld". > > For packages / bundle Identifier, I'd vote for "org.jboss.aerogear.unifiedpush.HelloWorld" > > > -Matthias > > > On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf wrote: > the GH repos have been created: > * https://github.com/aerogear/aerogear-push-helloworld > * https://github.com/aerogear/aerogear-push-quickstarts > > I edited the README to 'define' the (sub)folder structure > > > > On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf wrote: > Hello, > > here are the JIRAs (tasks and epics (which have sub-tasks) for this, so far: > > Github repo work: > https://issues.jboss.org/browse/AGPUSH-586 > https://issues.jboss.org/browse/AGPUSH-587 > > Hello-World Example work (epic): > https://issues.jboss.org/browse/AGPUSH-588 > > > Quickstart-server (epic): > https://issues.jboss.org/browse/AGPUSH-596 > > Quickstart-client (epic): > https://issues.jboss.org/browse/AGPUSH-604 > > > > It's totally valid to: > - add more sub-tasks, or break sub-tasks out into epics (e.g. if they have several work units). > > > Greetings, > Matthias > > > > > > > > > > On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf wrote: > Hello there, > > we recently had talks about creating some simplified quickstarts and hello-word demos, related to the UnifiedPush Server and JBoss AS developers: > > * Hello World (No Server Code - just client receiving push, no fancy (complex) UI on the client, nor integrated into a Cookbook or something that has "dependencies") > ** Cordova > ** Android > > For iOS that is already there: > https://github.com/aerogear/aerogear-push-ios-demo > > Yes, just usage of the "Push Registration SDKs", is the goal here: keep it simple, since native push can be a complicated use-case all on its own and so it will be good to make sure we cover the basics here. > > > Beyond the Hello-World, we wanted some different quickstarts. The "server" components that come to mind would be: > > *Secured CRUD + Push Integration (Java Sender) > ** JAX-RS + PicketLink > ** SpringMVC/Spring Security > ** JAX-RS + Apache Camel > > These need to function on both JBoss AS 7.X and EAP. > > Josh, from the JDF team, has already said he wants to help on the server projects (especially the JAX-RS/PL and Spring ones). yay! > Note: Josh already has a simple backend started that is used in JDF quickstarts that would be good to re-use to make it easier for developers to transition from one to other. > > > The goal would be the SERVER acts same to outside (identical REST endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. Camel)) > > For these different servers, there would be mobile apps needed: > * Android > * Cordova > * iOS > > > The idea would be to keep them simple and straightforward as well, e.g. for iOS that means plain usage of NSURLConnection / NSURLSession. But for the "push registration" of the client, > the iOS-push SDK would be used (same/similar would apply to Cordova or Android). Similar to the above 'Hello World', the quickstarts are going to be focused only on Push functionality, so for these we would leave out pipes and such until later versions. > > > I will be creating Epics and subtasks in JIRA for this. > > For the location of all these projects, I had this "uber repo" location in mind: > * https://github.com/aerogear/aerogear-push-helloworld > * https://github.com/aerogear/aerogear-push-quickstarts > > Greetings, > Matthias > > > > -- > 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 > > > > -- > 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/dafb0440/attachment.html From lholmqui at redhat.com Mon Apr 7 11:47:20 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 7 Apr 2014 11:47:20 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> Message-ID: <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> so i went back to look at what i had, i don't think we need to get to complicated here, reading the spec stuff, and this example https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple it is also recommended that the channelID is never exposed to the application. On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: > i had something, now i forgot what it was, need to go back and check > On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: > >> >> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >> still exploring >> >> :-) any recent thoughts on 'encodeURIComponent()' ? >> >> >> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >> >>> >>> >>> >>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>> i might have a couple thoughts, but i need to try some things out first >>> >>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>> >>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>> >>>> >>>> >>>> >>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>> Ok, >>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>> >>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>> >>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>> >>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>> So how do we deal with that ? >>>> >>>> >>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc wrote: >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc wrote: >>>> Hi, >>>> While playing today with my Firefox Device and its native Simple Push support I noticed some differences between our implementation and the native Push regarding the success callback after a register : >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> //Native FFOS Push >>>> broadcastRequest = navigator.push.register(); >>>> broadcastRequest.onsuccess = function (event) { >>>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>>> } >>>> >>>> >>>> //Aerogear Push Adapter >>>> broadcastRequest = navigator.push.register(); >>>> broadcastRequest.onsuccess = function (event) { >>>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>>> channelID = broadcastRequest.result.channelID; >>>> version = broadcastRequest.result.version; >>>> status = broadcastRequest.result.status >>>> } >>>> So, the AeroGear Push exposes much more in the callback that it should suppose to do : just exposing the pushEndpoint. >>>> >>>> The reason we do that I suppose, but Luke or Kris could confirm that, is that we thought respecting the SPS protocol, which indeed returns a whole object containing all the info. It is just that the Native Push Client API filter that out in the callback response. >>>> >>>> >>>> Did they change that recently? Or was theirs always like it is now ? >>>> >>>> >>>> After discussing that on the #push channel with the Mozilla people they confirmed me that we should only expoe the pushEndpoint. >>>> >>>> >>>> yep, I agree on changing our JS polyfil >>>> >>>> >>>> >>>> If we keep it as is, this can be problematic when we want to use the same code both for native and with the adapter when, for instance, registering to the UPS : >>>> >>>> broadcastRequest = navigator.push.register(); >>>> broadcastRequest.onsuccess = function (event) { >>>> broadcastEndpoint = event.target.result; >>>> var broadCastSettings = { >>>> metadata: { >>>> deviceToken: broadcastEndpoint.channelID, >>>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>>> } >>>> } >>>> UPClient.registerWithPushServer(broadCastSettings); >>>> } >>>> >>>> >>>> This won't work with the native push since "broadcastEndpoint.channelID" will be undefined. >>>> >>>> sweet :-) >>>> >>>> >>>> So I propose that we change the behaviour, to return only the pushEndpoint in the callback, even if that means a bit of String manipulation when we want to perform the registration to the UPS : >>>> >>>> var broadCastSettings = { >>>> metadata: { >>>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>>> simplePushEndpoint: broadcastEndpoint >>>> } >>>> } >>>> >>>> >>>> well, that's not really good for security reasons, since their looooong 'substring' was done for that. Also that's just redundant. >>>> >>>> The I guess, the deviceToken (channelID registration) might be a bit bogus, for SimplePush. Let me think about it.... >>>> >>>> >>>> Right now we use the channelID as the deviceToken, but we should not really 'leak' the channelID (see [1]), so I guess the here proposed change makes sense. Don't recall exactly why we did it in the past, but yeah - let's change it. >>>> >>>> >>>> Thinking about the consequence: I think we should use store the value of the returned 'pushEndpoint' string as our device-token. At the end the device-token is really the thing that identifies a device w/in the target network. Apple/Google uses a unique string, and if Mozilla uses a URL, that's totally fine. >>>> >>>> Reading the protocol definitions (see [1]) for the 'endpoint' I think it is fair to use that (unique) URL string as the device-token; And we could use this token value as well for the unregister calls, instead of the channelIDs. >>>> >>>> After reading your comment on the PR https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732 I understand that you just want to use the deviceToken and not pass the simplePushEndpoint to UPS anymore, is that right ? >>>> >>>> >>>> yep >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Any thoughts ? >>>> >>>> >>>> -Matthias >>>> >>>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >>>> >>>> >>>> >>>> >>>> That said, we still have no clue how to proper clean-up 'out dated' channels, since the SimplePush Server/Protocol is silent on that (unlike APNs / GCM). but that's really a different thread (yep, we have a future JIRA for that) >>>> >>>> >>>> -M >>>> >>>> >>>> wdyt ? >>>> >>>> Seb >>>> >>>> >>>> ps : our SPS Server implementation stays correct and returns what should be returned, it's really just the client part and how we expose the result >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/2e576197/attachment-0001.html From marceloheck at gmail.com Mon Apr 7 12:23:09 2014 From: marceloheck at gmail.com (marceloheck) Date: Mon, 7 Apr 2014 09:23:09 -0700 (PDT) Subject: [aerogear-dev] aerogear security and android In-Reply-To: References: <1394467743631-6703.post@n5.nabble.com> <1394558729969-6747.post@n5.nabble.com> <1394624522273-6750.post@n5.nabble.com> <1394642857598-6762.post@n5.nabble.com> <1396637119777-7335.post@n5.nabble.com> Message-ID: <1396887789427-7397.post@n5.nabble.com> hello , sorry , i will try to explain a changed project jaxrs shiro to running WildFly 8.0.0.Final: remove interface IdentityManagement interceptor jar web.xml org.jboss.aerogear.security.interceptor.SecurityInterceptor and change IdentityManagementImpl @ShiroSecurity //for Secure.java @Default @ApplicationScoped public class* IdentityManagementImpl* implements IdentityManagement { @Override public boolean hasRoles(Set roles) { return subject.hasAllRoles(roles); } ... i changed service/ @GET @Path("/bacon") @Produces(MediaType.APPLICATION_JSON) @Secure("simple") public List bacons() { return Arrays.asList(new String[]{"bacon", "Jowl", "Canadian", "Speck", "Pancetta"}); } @GET @Path("/livre") @Produces(MediaType.APPLICATION_JSON) public List livre() { return Arrays.asList(new String[]{"livre", "Jowl", "Canadian", "Speck", "Pancetta"}); } @GET @Path("/cerveja") @Produces(MediaType.APPLICATION_JSON) @Secure("admin") public List beers() { return Arrays.asList(new String[]{"cerveja", "California", "Michigan", "Ireland", "British"}); } my problem in login and autorization service i login (mar is role "simple") curl -3 -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -d '{"loginName":"mar","password":"123"}' -X POST http://localhost:8080/appteste/rest/auth/login HTTP 200: Authorized curl -b --cookie -v -X GET http://localhost:8080/appteste/rest/list/bacon HTTP 401: Unauthorized curl -b --cookie -v -X GET http://localhost:8080/appteste/rest/list/cerveja and is ok but another pc i login (adm is role "adm") curl -3 -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -d '{"loginName":"adm","password":"123"}' -X POST http://localhost:8080/appteste/rest/auth/login HTTP 200: Authorized curl -b --cookie -v -X GET http://localhost:8080/appteste/rest/list/cerveja HTTP 401: Unauthorized curl -b --cookie -v -X GET http://localhost:8080/appteste/rest/list/bacon is ok now i request again user mar , mar not access rest two users not login in one application in mobile too -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-security-and-android-tp6703p7397.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Mon Apr 7 12:52:58 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Apr 2014 18:52:58 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> Message-ID: Ok, So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? -Matthias On Monday, April 7, 2014, Lucas Holmquist wrote: > so i went back to look at what i had, > > > i don't think we need to get to complicated here, > > reading the spec stuff, and this example > > https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code > > they show sending the pushEndpoint to the "App server", so i think we > could just use and keep it simple > > it is also recommended that the channelID is never exposed to the > application. > > > On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: > > i had something, now i forgot what it was, need to go back and check > On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: > > > On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: > > still exploring > > > :-) any recent thoughts on 'encodeURIComponent()' ? > > > > On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: > > > > > On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: > > i might have a couple thoughts, but i need to try some things out first > > > Any update on that or does the solution proposed by Matzew (using encodeURIComponent() > ) could be enough ? > > > On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: > > > > > On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: > > Ok, > I've been doing some tests by using the PushEndpoint as device token. For > registration it works but I just faced an issue by trying to unregister > because the URL for the DELETE looks like : > > > https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[ > > And the REST endpoint get a bit crazy by the extra "/" present in the > endpoint URL. Therefore, I think we must just use the last URL fragment as > deviceToken. > > > Ok answering to myself ;) That won't work neither since if we do that UPS > won't have the compllete push endpoint URL. > So how do we deal with that ? > > > > On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: > > > > > On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/8547a9f4/attachment.html From bruno at abstractj.org Mon Apr 7 13:00:25 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 7 Apr 2014 14:00:25 -0300 Subject: [aerogear-dev] aerogear security and android In-Reply-To: <1396887789427-7397.post@n5.nabble.com> References: <1394467743631-6703.post@n5.nabble.com> <1394558729969-6747.post@n5.nabble.com> <1394624522273-6750.post@n5.nabble.com> <1394642857598-6762.post@n5.nabble.com> <1396637119777-7335.post@n5.nabble.com> <1396887789427-7397.post@n5.nabble.com> Message-ID: Hi Marcelo, that example is not fully complete, was just to showcase that the same could be achieved without AG Security. Also, I strongly recommend you to change and adapt to your real scenario. I did the test to reproduce the issue here (https://github.com/abstractj/example-jaxrs-shiro): - Register Lisa and Bart curl -3 -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -d '{"loginName":"bart","password":"123"}' -X POST http://localhost:8080/example-jaxrs-shiro/rest/auth/enroll curl -3 -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -d '{"loginName":"lisa","password":"123"}' -X POST http://localhost:8080/example-jaxrs-shiro/rest/auth/enroll - Login with Lisa and Bart curl -3 -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -d '{"loginName":"bart","password":"123"}' -X POST http://localhost:8080/example-jaxrs-shiro/rest/auth/login curl -3 -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -d '{"loginName":"lisa","password":"123"}' -X POST http://localhost:8080/example-jaxrs-shiro/rest/auth/login Maybe the session is not being closed during logout, not sure. For specifics to Shiro, please ask at?http://shiro-user.582556.n2.nabble.com -- abstractj On April 7, 2014 at 1:24:03 PM, marceloheck (marceloheck at gmail.com) wrote: > hello , sorry , i will try to explain > > a changed project jaxrs shiro to running WildFly 8.0.0.Final: > > remove interface IdentityManagement > > interceptor jar web.xml > > > org.jboss.aerogear.security.interceptor.SecurityInterceptor > > > and change IdentityManagementImpl > > > @ShiroSecurity //for Secure.java > @Default > @ApplicationScoped > public class* IdentityManagementImpl* implements IdentityManagement { > > > @Override > public boolean hasRoles(Set roles) { > > return subject.hasAllRoles(roles); > } > ... > > i changed service/ > > @GET > @Path("/bacon") > @Produces(MediaType.APPLICATION_JSON) > @Secure("simple") > public List bacons() { > return Arrays.asList(new String[]{"bacon", "Jowl", "Canadian", > "Speck", "Pancetta"}); > } > > @GET > @Path("/livre") > @Produces(MediaType.APPLICATION_JSON) > public List livre() { > return Arrays.asList(new String[]{"livre", "Jowl", "Canadian", > "Speck", "Pancetta"}); > } > > @GET > @Path("/cerveja") > @Produces(MediaType.APPLICATION_JSON) > @Secure("admin") > public List beers() { > return Arrays.asList(new String[]{"cerveja", "California", > "Michigan", "Ireland", "British"}); > } > > > my problem in login and autorization service > > i login (mar is role "simple") > curl -3 -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H > "Content-type: application/json" -d '{"loginName":"mar","password":"123"}' > -X POST http://localhost:8080/appteste/rest/auth/login > HTTP 200: Authorized > curl -b --cookie -v -X GET http://localhost:8080/appteste/rest/list/bacon > HTTP 401: Unauthorized > curl -b --cookie -v -X GET http://localhost:8080/appteste/rest/list/cerveja > and is ok > but > another pc > i login (adm is role "adm") > curl -3 -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H > "Content-type: application/json" -d '{"loginName":"adm","password":"123"}' > -X POST http://localhost:8080/appteste/rest/auth/login > HTTP 200: Authorized > curl -b --cookie -v -X GET http://localhost:8080/appteste/rest/list/cerveja > HTTP 401: Unauthorized > curl -b --cookie -v -X GET http://localhost:8080/appteste/rest/list/bacon > is ok > > now i request again user mar , mar not access rest > > two users not login in one application > > in mobile too > > > > > > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-security-and-android-tp6703p7397.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From miguel21op at gmail.com Mon Apr 7 13:53:01 2014 From: miguel21op at gmail.com (Miiguel Lemos) Date: Mon, 7 Apr 2014 18:53:01 +0100 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: <530B54FC-52EB-46CF-9983-9E24859FCE91@redhat.com> References: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> <7A42B7B1-39AB-426E-A8AF-5D369634AF65@gmail.com> <530B54FC-52EB-46CF-9983-9E24859FCE91@redhat.com> Message-ID: <71CB1D15-90D3-4B43-932E-A593E18D8AE1@gmail.com> About geo-fencing, yes you are right: it's critical! Now I've not spare time for it but one of these days I'll come back with what I think about this, and what should / must be done, and why (in the user / service point of view). See ya ;) Enviado do meu iPad No dia 07/04/2014, ?s 14:54, Burr Sutter escreveu: > >> On Apr 7, 2014, at 9:00 AM, Miguel Lemos wrote: >> >> Yes, my friend. But the variety of what customers need is so wide, that you'll never meet all demands. >> >> I see your service being used in the scope - in one end - of a full customized service that developers must build. The developers are supposed to develop. For instance in my case, i'll be happy if I know if the message has been forwarded to Google or Apple service. The filtering (analytics) you offer is too narrow, but I don't complain about it... > > At this time, we do not tell the user if the message was forwarded or not - the UI has no indication that a message has moved through the system. A newbie would like to know that something happened. Some basic metrics/analytics is helpful to giving a new user that warm-fuzzy feeling that the UPS is actually doing something, even if the push message does not make it out to the phone itself. > >> >> On the other hand, your core service has yet some things that must be fixed / perfectionated (I'm talking only about Cordova). I also think that you should consider geo-tagged notifications, which is a very important need. > I agree - but these things are not necessarily mutually exclusive :-) > > On the Cordova side of things, I would like to know more about what needs fine-tuning. Docs? definitely need work > And our push plugin is a wee bit fat for Android, needs to go on a diet, dexing takes a while > And the JS API needed some clean-up, you have seen Erik's proposals on that item > > We should have a thread to more fully flesh out geo-tagging/geo-fencing requirements - I also love that idea/feature and think it is critical. I know that Erik already produced an early prototype but I have not yet explored how it works, to see if it is cross-platform, battery efficient and relatively accurate (within a few KM of distance). > > >> >> IMHO the solutions Mathias wrote for using it some weeks ago (the phone sending its location to the server) is not the best one... > > Was this in the Aerodoc example? I can see a scenario where a developer would want this - basically, allow the end-user to set his "home" geo-location and perhaps "work" geo-location and not attempt to track the physical movement of the phone on a recurring basis. For instance, a sales rep often has specific geographic boundary that he works within (as seen in Aerodoc) but a consumer, visiting different malls, does not. > > >> But, again, this is only a opinion, the work you are doing so far is great, and I much appreciate it. >> >> Cheers >> >> Miguel >> >> >> >>> On Mon, Apr 7, 2014 at 1:37 PM, Burr Sutter wrote: >>> >>>> On Apr 7, 2014, at 8:16 AM, Miguel Lemos wrote: >>>> >>>> I think developers must build their own back-ends and keep track of what they do. >>> >>> While I agree in theory, it is more difficult in practice. A single push server may be used by several developers across several different app teams, in that case, you will want some metrics/logging captured at the central point. Any given developer/team may misbehave quite badly. Our experience with multi-developer services has demonstrated that customers like having centralized logging/metric capture. >>> >>>> >>>> This will be always the more flexible solution. >>>> >>>> IMHO you must focus on the core of building a reliable and powerful push send service (includind the documentation part). >>>> >>>> Enviado do meu iPhone >>>> >>>> No dia 07/04/2014, ?s 13:09, Burr Sutter escreveu: >>>> >>>>> >>>>>> On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> for a first round of collection some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple. >>>>>> >>>>>> Overall, I see one major area of interest: >>>>>> *metrics around push messages being sent: >>>>>> - time of sending (using timezone of the server?) >>>>> >>>>>> - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) >>>>>> - payload (the entire payload, including custom keys - not only alert, sound, badge etc) >>>>> As a developer, I wish to know if my 3 test devices all registered properly. >>>>> As a developer, I wish to know if the push notification was sent to all 3 test devices properly (at least delivered to Apple/Google properly) >>>>> As a developer, I would like to know what were my past messages >>>>> As a push administrator, a business unit representative (e.g head of sales, warehouse manager) is going ask me if a particular message was sent to a particular user (alias) or user group (aliases or category). >>>>>> >>>>>> This is a nice feature, and would enrich the UPS. >>>>>> >>>>>> >>>>>> However, I can see also some interest around device specific metrics: >>>>>> >>>>>> Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). >>>>> I can see people wanting to just archive instead of delete those records - interesting data points would be: >>>>> - any commonality in device type >>>>> - a trend in date/time of removal >>>>> - ratio of added/removed (user opted in vs out) >>>>> >>>>> Is it possible to distinguish between app uninstall vs push notification disable (where the app remains installed)? >>>>> >>>>>> >>>>>> Something that would be interesting as well, might be the following data: >>>>>> - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) >>>>> would this be a good proxy for letting me know how often an end-user is using the app? >>>>>> - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) >>>>>> - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) >>>>>> >>>>>> >>>>>> While the initial focus should be around the message related metrics, capturing some device data is nice too. >>>>>> >>>>>> >>>>>> Any thoughts ? >>>>>> >>>>>> -Matthias >>>>>> >>>>>> >>>>>> PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [1] https://issues.jboss.org/browse/AGPUSH-116 >>>>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 >>>>>> [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 >>>>>> [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 >>>>>> [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/80ee4152/attachment-0001.html From lholmqui at redhat.com Mon Apr 7 14:09:48 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 7 Apr 2014 14:09:48 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> Message-ID: On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: > Ok, > > So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. > > -Matthias > > On Monday, April 7, 2014, Lucas Holmquist wrote: > so i went back to look at what i had, > > > i don't think we need to get to complicated here, > > reading the spec stuff, and this example > > https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code > > they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple > > it is also recommended that the channelID is never exposed to the application. > > > On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: > >> i had something, now i forgot what it was, need to go back and check >> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >> >>> >>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>> still exploring >>> >>> :-) any recent thoughts on 'encodeURIComponent()' ? >>> >>> >>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>> >>>> >>>> >>>> >>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>> i might have a couple thoughts, but i need to try some things out first >>>> >>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>> >>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>> Ok, >>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>> >>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>> >>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>> >>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>> So how do we deal with that ? >>>>> >>>>> >>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc > > > -- > Sent from Gmail Mobile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/37b1ea90/attachment.html From miguel21op at gmail.com Mon Apr 7 14:16:01 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Mon, 7 Apr 2014 19:16:01 +0100 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: <71CB1D15-90D3-4B43-932E-A593E18D8AE1@gmail.com> References: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> <7A42B7B1-39AB-426E-A8AF-5D369634AF65@gmail.com> <530B54FC-52EB-46CF-9983-9E24859FCE91@redhat.com> <71CB1D15-90D3-4B43-932E-A593E18D8AE1@gmail.com> Message-ID: Meanwhile I thing it's very good the idea of opening a thread just about the geo-fencing subject. On Mon, Apr 7, 2014 at 6:53 PM, Miiguel Lemos wrote: > About geo-fencing, yes you are right: it's critical! Now I've not spare > time for it but one of these days I'll come back with what I think about > this, and what should / must be done, and why (in the user / service point > of view). > > See ya ;) > > Enviado do meu iPad > > No dia 07/04/2014, ?s 14:54, Burr Sutter escreveu: > > > On Apr 7, 2014, at 9:00 AM, Miguel Lemos wrote: > > Yes, my friend. But the variety of what customers need is so wide, that > you'll never meet all demands. > > I see your service being used in the scope - in one end - of a full > customized service that developers must build. The developers are supposed > to develop. For instance in my case, i'll be happy if I know if the message > has been forwarded to Google or Apple service. The filtering (analytics) > you offer is too narrow, but I don't complain about it... > > > At this time, we do not tell the user if the message was forwarded or not > - the UI has no indication that a message has moved through the system. A > newbie would like to know that something happened. Some basic > metrics/analytics is helpful to giving a new user that warm-fuzzy feeling > that the UPS is actually doing something, even if the push message does not > make it out to the phone itself. > > > On the other hand, your core service has yet some things that must be > fixed / perfectionated (I'm talking only about Cordova). I also think that > you should consider geo-tagged notifications, which is a very important > need. > > I agree - but these things are not necessarily mutually exclusive :-) > > On the Cordova side of things, I would like to know more about what needs > fine-tuning. Docs? definitely need work > And our push plugin is a wee bit fat for Android, needs to go on a diet, > dexing takes a while > And the JS API needed some clean-up, you have seen Erik's proposals on > that item > > We should have a thread to more fully flesh out geo-tagging/geo-fencing > requirements - I also love that idea/feature and think it is critical. I > know that Erik already produced an early prototype but I have not yet > explored how it works, to see if it is cross-platform, battery efficient > and relatively accurate (within a few KM of distance). > > > > IMHO the solutions Mathias wrote for using it some weeks ago (the phone > sending its location to the server) is not the best one... > > > Was this in the Aerodoc example? I can see a scenario where a developer > would want this - basically, allow the end-user to set his "home" > geo-location and perhaps "work" geo-location and not attempt to track the > physical movement of the phone on a recurring basis. For instance, a > sales rep often has specific geographic boundary that he works within (as > seen in Aerodoc) but a consumer, visiting different malls, does not. > > > But, again, this is only a opinion, the work you are doing so far is > great, and I much appreciate it. > > > Cheers > > Miguel > > > > On Mon, Apr 7, 2014 at 1:37 PM, Burr Sutter wrote: > >> >> On Apr 7, 2014, at 8:16 AM, Miguel Lemos wrote: >> >> I think developers must build their own back-ends and keep track of what >> they do. >> >> >> While I agree in theory, it is more difficult in practice. A single push >> server may be used by several developers across several different app >> teams, in that case, you will want some metrics/logging captured at the >> central point. Any given developer/team may misbehave quite badly. Our >> experience with multi-developer services has demonstrated that customers >> like having centralized logging/metric capture. >> >> >> This will be always the more flexible solution. >> >> IMHO you must focus on the core of building a reliable and powerful push >> send service (includind the documentation part). >> >> Enviado do meu iPhone >> >> No dia 07/04/2014, ?s 13:09, Burr Sutter escreveu: >> >> >> On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf >> wrote: >> >> Hello, >> >> for a first round of collection some more data around the usage of the >> push server (aka analytics/metrics), I'd propose we keep it very simple. >> >> Overall, I see one major area of interest: >> *metrics around push messages being sent: >> - time of sending (using timezone of the server?) >> >> - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, >> categories,...)) >> - payload (the entire payload, including custom keys - not only alert, >> sound, badge etc) >> >> As a developer, I wish to know if my 3 test devices all registered >> properly. >> As a developer, I wish to know if the push notification was sent to all 3 >> test devices properly (at least delivered to Apple/Google properly) >> As a developer, I would like to know what were my past messages >> As a push administrator, a business unit representative (e.g head of >> sales, warehouse manager) is going ask me if a particular message was sent >> to a particular user (alias) or user group (aliases or category). >> >> >> This is a nice feature, and would enrich the UPS. >> >> >> However, I can see also some interest around device specific metrics: >> >> Today we obivously store all the registered devices, but we also remove >> them from the database table if needed (to not send messages to phones that >> would no longer receive them anyways). >> >> I can see people wanting to just archive instead of delete those records >> - interesting data points would be: >> - any commonality in device type >> - a trend in date/time of removal >> - ratio of added/removed (user opted in vs out) >> >> Is it possible to distinguish between app uninstall vs push notification >> disable (where the app remains installed)? >> >> >> Something that would be interesting as well, might be the following data: >> - how often was an app has reached the push server (note: every time the >> app starts, the metadata of the server is being updated (see [2]) >> >> would this be a good proxy for letting me know how often an end-user is >> using the app? >> >> - number of device-tokens / registrationIDs that have been removed, when >> receiving errors from Apple/Google (see [3] or [4]) >> - number of devices, that were activly removed using our APIs (supported >> only on Android/SimplePush due to Apple policy, see [5]) >> >> >> While the initial focus should be around the message related metrics, >> capturing some device data is nice too. >> >> >> Any thoughts ? >> >> -Matthias >> >> >> PS: Oh, for the longer run(...), I'd also like to see metrics like "was >> mobile app opened due to a push notification". BUT that also requires some >> more work/reseach on the client Push SDKs. But seriously, this is not a >> priority for the next few months! >> >> >> >> >> [1] https://issues.jboss.org/browse/AGPUSH-116 >> [2] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 >> [3] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 >> [4] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 >> [5] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140407/9e1977e5/attachment-0001.html From marceloheck at gmail.com Mon Apr 7 14:31:49 2014 From: marceloheck at gmail.com (marceloheck) Date: Mon, 7 Apr 2014 11:31:49 -0700 (PDT) Subject: [aerogear-dev] aerogear security and android In-Reply-To: References: <1394558729969-6747.post@n5.nabble.com> <1394624522273-6750.post@n5.nabble.com> <1394642857598-6762.post@n5.nabble.com> <1396637119777-7335.post@n5.nabble.com> <1396887789427-7397.post@n5.nabble.com> Message-ID: <1396895509171-7400.post@n5.nabble.com> yes i understand in your sample i removed AG security now my app is ok for 2 users , but lisa e bart is role equal (simple) but if lisa is admin , for error test in 2 computer list bart user (simple) and lisa admin curl -b --cookie -v -X GET http://localhost:8080/example-jaxrs-shiro/rest/grocery/bacons curl -b --cookie -v -X GET http://localhost:8080/example-jaxrs-shiro/rest/grocery/beers bart view bacons and lisa view beers but error is this, not functional bart block lisa or lisa block bart in server sorry do not know if I'm able to explain -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-security-and-android-tp6703p7400.html Sent from the aerogear-dev mailing list archive at Nabble.com. From corinnekrych at gmail.com Mon Apr 7 14:46:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 7 Apr 2014 20:46:05 +0200 Subject: [aerogear-dev] Creation of static library and framework for aerogear-push-ios-registration In-Reply-To: <6A30793B-8075-4604-BFAB-096C07E86CC1@redhat.com> References: <1245166869.239034.1396860828464.JavaMail.zimbra@redhat.com> <8F9ED9DA-504C-426E-B8FB-377171F74243@redhat.com> <6A30793B-8075-4604-BFAB-096C07E86CC1@redhat.com> Message-ID: <4ADA512E-D6A0-4C49-A40C-39BEA3F18A06@gmail.com> Hello Andrea, I?ve tested the static build and use it in push demo [1] with a new certificate and the UPS openshift instance (quickstarts created by Sebi). I?ve transformed xcodeproject not to link to any cocopods artifacts. Then, I?ve used Method 1 described in raywenderlich blog [2] to link to the built static lib. It works well out of the box. I haven?t tested it on 64bits device yet. +1 on using fwk as you said it simplifies the end user experience. But as jverkoeyen stated it its the readme [3] instruction "Building a static iOS framework is a pain??, well, it requires more work ;) In the meantime, we can use your static lib with headers file, are we going to store the fat lib in the demo repo? ++ Corinne [1] https://github.com/corinnekrych/aerogear-push-ios-demo/compare/static.lib?expand=1 [2] http://www.raywenderlich.com/41377/creating-a-static-library-in-ios-tutorial [3] https://github.com/jverkoey/iOS-Framework/blob/master/README.mdown On 07 Apr 2014, at 11:37, Erik Jan de Wit wrote: > This error is because of the CONFIGURATION_BUILD_DIR try TARGET_BUILD_DIR instead > On 7 Apr,2014, at 11:20 , Erik Jan de Wit wrote: > >> I?ve tried to build with this script but it doesn?t work. I was also in the progress of creating a script that would do exactly the same to release the push plugin and always include the latest aerogear-push-ios-registation release as a binary >> >> This is the error I get: >> >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: -dynamic not specified the following flags are invalid: -ObjC >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lPods >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lPods is not an object file (not allowed in a library) >> Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool failed with exit code 1 >> >> >> On 7 Apr,2014, at 10:53 , Andrea Vibelli wrote: >> >>> Hi all, >>> for those who are not able or willing to use Cocoapods, it would be nice to distribute a static binary library of aerogear-push-ios-registration. >>> In order to support multiple platforms without the need to create multiple configurations or build products, I think that the best way would be to create a universal binary (aka fat library) that contains the object code for both architectures (device + simulator) and the public headers files. >>> >>> Going further, from the universal library it could be possible to create a framework, that would bring everything together into one package (a directory with a known structure). Packaging a library as a framework simplifies things for developers because it not only provides a binary to link against but it includes all of the necessary header files to reference as well. >>> >>> I have tried to create a script that builds a universal static library first and then a framework (putting together some links [1],[2],[3],[4]), is anybody willing to help to check it and test the built bits inside the cordova-push-plugin? >>> >>> You can find the script here: https://github.com/vibe13/aerogear-push-ios-registration/blob/master/universal_lib-framework_build.sh >>> >>> The script should be placed inside the project root and run: ./universal_lib-framework_build.sh >>> >>> Thank you >>> Andrea >>> >>> [1] http://www.meonbinary.com/2013/07/creating-universal-ios-framework >>> [2] http://spin.atomicobject.com/2011/12/13/building-a-universal-framework-for-ios/ >>> [3] https://github.com/jverkoey/iOS-Framework >>> [4] http://www.cocoanetics.com/2010/04/making-your-own-iphone-frameworks/ >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From avibelli at redhat.com Mon Apr 7 15:56:07 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Mon, 7 Apr 2014 15:56:07 -0400 (EDT) Subject: [aerogear-dev] Creation of static library and framework for aerogear-push-ios-registration In-Reply-To: <792289734.555382.1396900465540.JavaMail.zimbra@redhat.com> Message-ID: <972764197.556047.1396900567322.JavaMail.zimbra@redhat.com> Hi Erik, thanks for pointing this out, I have modified the script and committed to : https://github.com/vibe13/aerogear-push-ios-registration/blob/master/universal_lib-framework_build.sh Let me know if it works now, thank you! Andrea From matzew at apache.org Tue Apr 8 01:30:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Apr 2014 07:30:56 +0200 Subject: [aerogear-dev] iOS Team Meeting In-Reply-To: <99DE4975-0D25-4947-B510-656E07734C1D@gmail.com> References: <99DE4975-0D25-4947-B510-656E07734C1D@gmail.com> Message-ID: Hi Christos, I think that's the wrong URL :) On Mon, Apr 7, 2014 at 3:42 PM, Christos Vasilakis wrote: > Hi everyone, > > tomorrow will have our iOS team meeting agenda can be found here[1] > > feel free to join us! > > - > Christos > > [1] http://oksoclap.com/p/aerogear-team-mgt-20140407 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/77db4550/attachment.html From cvasilak at gmail.com Tue Apr 8 02:40:24 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 8 Apr 2014 09:40:24 +0300 Subject: [aerogear-dev] iOS Team Meeting In-Reply-To: References: <99DE4975-0D25-4947-B510-656E07734C1D@gmail.com> Message-ID: <6D8579F9-F506-4D70-BDD1-EDC0E7C1F8A7@gmail.com> On Apr 8, 2014, at 8:30 AM, Matthias Wessendorf wrote: > Hi Christos, > > I think that's the wrong URL :) oops copy paste is evil the right one: http://oksoclap.com/p/iOSMeeting-07.04.14 Thanks, Christos > > > On Mon, Apr 7, 2014 at 3:42 PM, Christos Vasilakis wrote: > Hi everyone, > > tomorrow will have our iOS team meeting agenda can be found here[1] > > feel free to join us! > > - > Christos > > [1] http://oksoclap.com/p/aerogear-team-mgt-20140407 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/3e4f12cc/attachment.html From scm.blanc at gmail.com Tue Apr 8 04:47:55 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 8 Apr 2014 10:47:55 +0200 Subject: [aerogear-dev] security updates In-Reply-To: References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> Message-ID: Ok, I just gave give it another try with the security fix applied and the impact is way bigger than just having the right cordova version. In fact, your Android OS version must be at least 4.4 otherwise it don't work. So I'm not sure we only support Android 4.4 right ? Seb On Fri, Mar 14, 2014 at 10:21 AM, Matthias Wessendorf wrote: > +1 > > meeting to discuss this sounds good > > > > On Fri, Mar 14, 2014 at 9:58 AM, Bruno Oliveira wrote: > >> Apples and oranges my friend. Let's schedule a meeting for it. >> >> -- >> abstractj >> >> On March 14, 2014 at 5:56:42 AM, Erik Jan de Wit (edewit at redhat.com) >> wrote: >> > > But, this doesn't address a security fix in our products, we >> > can't be held responsible for the platform our plugin runs on.Like >> > Tolis said if we take this route we might as well only support the >> > latest cordova version. >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/21d791c2/attachment.html From matzew at apache.org Tue Apr 8 04:59:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Apr 2014 10:59:45 +0200 Subject: [aerogear-dev] security updates In-Reply-To: References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> Message-ID: If this means, that Cordova 3.4.0 does only work with Android 4.4, than we should revisit that. I am surprised that Cordova 3.4.0 requires Android 4.4 :-( On Tue, Apr 8, 2014 at 10:47 AM, Sebastien Blanc wrote: > Ok, > > I just gave give it another try with the security fix applied and the > impact is way bigger than just having the right cordova version. In fact, > your Android OS version must be at least 4.4 otherwise it don't work. > > So I'm not sure we only support Android 4.4 right ? > > Seb > > > > > On Fri, Mar 14, 2014 at 10:21 AM, Matthias Wessendorf wrote: > >> +1 >> >> meeting to discuss this sounds good >> >> >> >> On Fri, Mar 14, 2014 at 9:58 AM, Bruno Oliveira wrote: >> >>> Apples and oranges my friend. Let's schedule a meeting for it. >>> >>> -- >>> abstractj >>> >>> On March 14, 2014 at 5:56:42 AM, Erik Jan de Wit (edewit at redhat.com) >>> wrote: >>> > > But, this doesn't address a security fix in our products, we >>> > can't be held responsible for the platform our plugin runs on.Like >>> > Tolis said if we take this route we might as well only support the >>> > latest cordova version. >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/d5e4d3ab/attachment-0001.html From scm.blanc at gmail.com Tue Apr 8 05:03:26 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 8 Apr 2014 11:03:26 +0200 Subject: [aerogear-dev] security updates In-Reply-To: References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> Message-ID: On Tue, Apr 8, 2014 at 10:59 AM, Matthias Wessendorf wrote: > If this means, that Cordova 3.4.0 does only work with Android 4.4, than we > should revisit that. > > I am surprised that Cordova 3.4.0 requires Android 4.4 :-( > Well until now I was using Cordova 3.4.0 with my Android 4.04 without any issues. It just seems that cordova 3.4.0 also exposes an API that failed if used with Android < 4.4 , in occurence : org.apache.cordova.CordovaWebView.evaluateJavascript > > On Tue, Apr 8, 2014 at 10:47 AM, Sebastien Blanc wrote: > >> Ok, >> >> I just gave give it another try with the security fix applied and the >> impact is way bigger than just having the right cordova version. In fact, >> your Android OS version must be at least 4.4 otherwise it don't work. >> >> So I'm not sure we only support Android 4.4 right ? >> >> Seb >> >> >> >> >> On Fri, Mar 14, 2014 at 10:21 AM, Matthias Wessendorf wrote: >> >>> +1 >>> >>> meeting to discuss this sounds good >>> >>> >>> >>> On Fri, Mar 14, 2014 at 9:58 AM, Bruno Oliveira wrote: >>> >>>> Apples and oranges my friend. Let's schedule a meeting for it. >>>> >>>> -- >>>> abstractj >>>> >>>> On March 14, 2014 at 5:56:42 AM, Erik Jan de Wit (edewit at redhat.com) >>>> wrote: >>>> > > But, this doesn't address a security fix in our products, we >>>> > can't be held responsible for the platform our plugin runs on.Like >>>> > Tolis said if we take this route we might as well only support the >>>> > latest cordova version. >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/83d8e05b/attachment.html From miguel21op at gmail.com Tue Apr 8 05:04:34 2014 From: miguel21op at gmail.com (Miiguel Lemos) Date: Tue, 8 Apr 2014 10:04:34 +0100 Subject: [aerogear-dev] security updates In-Reply-To: References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> Message-ID: No, it does not! I have Cordova 3.4 rumning on Android 4.1. Enviado do meu iPad No dia 08/04/2014, ?s 09:59, Matthias Wessendorf escreveu: > If this means, that Cordova 3.4.0 does only work with Android 4.4, than we should revisit that. > > I am surprised that Cordova 3.4.0 requires Android 4.4 :-( > > >> On Tue, Apr 8, 2014 at 10:47 AM, Sebastien Blanc wrote: >> Ok, >> >> I just gave give it another try with the security fix applied and the impact is way bigger than just having the right cordova version. In fact, your Android OS version must be at least 4.4 otherwise it don't work. >> >> So I'm not sure we only support Android 4.4 right ? >> >> Seb >> >> >> >> >>> On Fri, Mar 14, 2014 at 10:21 AM, Matthias Wessendorf wrote: >>> +1 >>> >>> meeting to discuss this sounds good >>> >>> >>> >>>> On Fri, Mar 14, 2014 at 9:58 AM, Bruno Oliveira wrote: >>>> Apples and oranges my friend. Let?s schedule a meeting for it. >>>> >>>> -- >>>> abstractj >>>> >>>> On March 14, 2014 at 5:56:42 AM, Erik Jan de Wit (edewit at redhat.com) wrote: >>>> > > But, this doesn?t address a security fix in our products, we >>>> > can?t be held responsible for the platform our plugin runs on.Like >>>> > Tolis said if we take this route we might as well only support the >>>> > latest cordova version. >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/c3148ba0/attachment.html From matzew at apache.org Tue Apr 8 05:17:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Apr 2014 11:17:07 +0200 Subject: [aerogear-dev] security updates In-Reply-To: References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> Message-ID: On Tue, Apr 8, 2014 at 11:03 AM, Sebastien Blanc wrote: > > > > On Tue, Apr 8, 2014 at 10:59 AM, Matthias Wessendorf wrote: > >> If this means, that Cordova 3.4.0 does only work with Android 4.4, than >> we should revisit that. >> >> I am surprised that Cordova 3.4.0 requires Android 4.4 :-( >> > > Well until now I was using Cordova 3.4.0 with my Android 4.04 without any > issues. > > It just seems that cordova 3.4.0 also exposes an API that failed if used > with Android < 4.4 , in occurence : > > org.apache.cordova.CordovaWebView.evaluateJavascript > Hrm, that's a huge surprise here - I was never expecting, when moving to Cordova 3.4.0, we rely on Android 4.4 (and later). We need to support way older versions (e.g. 2.3.x) Wondering if we can avoid the 'evaluateJavascript' method ? Others I'd actually prefer to go with "older" Cordova version, at least on a branch > > > > >> >> On Tue, Apr 8, 2014 at 10:47 AM, Sebastien Blanc wrote: >> >>> Ok, >>> >>> I just gave give it another try with the security fix applied and the >>> impact is way bigger than just having the right cordova version. In fact, >>> your Android OS version must be at least 4.4 otherwise it don't work. >>> >>> So I'm not sure we only support Android 4.4 right ? >>> >>> Seb >>> >>> >>> >>> >>> On Fri, Mar 14, 2014 at 10:21 AM, Matthias Wessendorf >> > wrote: >>> >>>> +1 >>>> >>>> meeting to discuss this sounds good >>>> >>>> >>>> >>>> On Fri, Mar 14, 2014 at 9:58 AM, Bruno Oliveira wrote: >>>> >>>>> Apples and oranges my friend. Let's schedule a meeting for it. >>>>> >>>>> -- >>>>> abstractj >>>>> >>>>> On March 14, 2014 at 5:56:42 AM, Erik Jan de Wit (edewit at redhat.com) >>>>> wrote: >>>>> > > But, this doesn't address a security fix in our products, we >>>>> > can't be held responsible for the platform our plugin runs on.Like >>>>> > Tolis said if we take this route we might as well only support the >>>>> > latest cordova version. >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at 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 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/1a606608/attachment-0001.html From edewit at redhat.com Tue Apr 8 05:17:47 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 8 Apr 2014 11:17:47 +0200 Subject: [aerogear-dev] security updates In-Reply-To: References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> Message-ID: <25263486-9BC6-4149-B1FF-18DCB6FE66E9@redhat.com> Hi, The simplified plugin is using evaluateJavascript in favour of sendJavascript, but this method is only available in 4.4 as this is a new method introduced by the chrome web view we can change this by using sendJavascript method again. Don?t know if this will introduce security errors, but I guess not. I think the actual fix is not using the old web view. Cheers, Erik Jan From matzew at apache.org Tue Apr 8 05:21:06 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Apr 2014 11:21:06 +0200 Subject: [aerogear-dev] security updates In-Reply-To: <25263486-9BC6-4149-B1FF-18DCB6FE66E9@redhat.com> References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> <25263486-9BC6-4149-B1FF-18DCB6FE66E9@redhat.com> Message-ID: On Tue, Apr 8, 2014 at 11:17 AM, Erik Jan de Wit wrote: > Hi, > > The simplified plugin is using evaluateJavascript in favour of > sendJavascript, but this method is only available in 4.4 Ah! Thanks for clarification! But this, than, automatically means: the Push-Plugin requires 4.4 ? That's a huge impact. We have to support way older versions, w/ the plugin. > as this is a new method introduced by the chrome web view we can change > this by using sendJavascript method again. Don't know if this will > introduce security errors, but I guess not. That would be worth to investigate. Not only for security - also for 'love' of older Android versions! Thanks for the details, Erik! -Matthias > I think the actual fix is not using the old web view. > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/0425eccc/attachment.html From antoine.matyja at worldline.com Tue Apr 8 05:22:18 2014 From: antoine.matyja at worldline.com (A577127) Date: Tue, 8 Apr 2014 02:22:18 -0700 (PDT) Subject: [aerogear-dev] Redirecting http requests Message-ID: <1396948938278-7416.post@n5.nabble.com> Hello, I want to bench the AeroGear UnifiedPush Server. I've decided to make it quickly (and dirty) by editing the URL for GCM push notifications (https://android.googleapis.com/gcm/send) to another (localhost:1234). Since the UnifiedPush Server uses Google's java gcm server library, I've downloaded the original code ( here ) and edited the Constants.java to replace the "GCM_SEND_ENDPOINT" constant. It seems ok, I create my .jar (gcm-server.jar) and install it locally with maven. Then I edited the file unifiedpush-push/pom.xml to add the dependancy instead of the old jar (com.ganyo). Everything seems ok, I deployed my .war file. But surprise ! I can still send push notifications to my device... (it's the first time I've been sad that sending a push notification worked :)) I even checked inside the .war file (jboss-eap-6.2\standalone\deployments\ag-push.war\WEB-INF\lib\gcm-server-1.0.2.jar\com\google\android\gcm\server\), the file Constants.class contains my custom URL instead of the classic gcm send url. How is that possible ? Is the gcm send endpoint url stored somewhere I missed ? Thanks in advance -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Redirecting-http-requests-tp7416.html Sent from the aerogear-dev mailing list archive at Nabble.com. From kpiwko at redhat.com Tue Apr 8 06:59:18 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 8 Apr 2014 12:59:18 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Analytics / Metrics In-Reply-To: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> References: <7EA41F12-CB4B-4914-8449-92BA4D55BB9D@redhat.com> Message-ID: <20140408125918.18577ee3@kapy-ntb-x220> On Mon, 7 Apr 2014 08:09:01 -0400 Burr Sutter wrote: > > On Apr 7, 2014, at 1:17 AM, Matthias Wessendorf wrote: > > > Hello, > > > > for a first round of collection some more data around the usage of the push > > server (aka analytics/metrics), I'd propose we keep it very simple. > > > > Overall, I see one major area of interest: > > *metrics around push messages being sent: > > - time of sending (using timezone of the server?) > > > - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, > > categories,...)) > > - payload (the entire payload, including custom keys - not only alert, > > sound, badge etc) > > > As a developer, I wish to know if my 3 test devices all registered properly. > As a developer, I wish to know if the push notification was sent to all 3 > test devices properly (at least delivered to Apple/Google properly) Definitely a great feature. We already have such endpoint in integration tests: https://github.com/aerogear/aerogear-unifiedpush-server-integration-tests/blob/master/src/test/java/org/jboss/aerogear/unifiedpush/utils/SenderStatisticsEndpoint.java > As a > developer, I would like to know what were my past messages As a push > administrator, a business unit representative (e.g head of sales, warehouse > manager) is going ask me if a particular message was sent to a particular > user (alias) or user group (aliases or category). > > > > This is a nice feature, and would enrich the UPS. > > > > > > However, I can see also some interest around device specific metrics: > > > > Today we obivously store all the registered devices, but we also remove > > them from the database table if needed (to not send messages to phones that > > would no longer receive them anyways). > I can see people wanting to just archive instead of delete those records - > interesting data points would be: > - any commonality in device type > - a trend in date/time of removal > - ratio of added/removed (user opted in vs out) > > Is it possible to distinguish between app uninstall vs push notification > disable (where the app remains installed)? > > > > > Something that would be interesting as well, might be the following data: > > - how often was an app has reached the push server (note: every time the > > app starts, the metadata of the server is being updated (see [2]) > would this be a good proxy for letting me know how often an end-user is using > the app? > > - number of device-tokens / registrationIDs that have been removed, when > > receiving errors from Apple/Google (see [3] or [4]) > > - number of devices, that were activly removed using our APIs (supported > > only on Android/SimplePush due to Apple policy, see [5]) > > > > > > While the initial focus should be around the message related metrics, > > capturing some device data is nice too. > > > > > > Any thoughts ? > > > > -Matthias > > > > > > PS: Oh, for the longer run(...), I'd also like to see metrics like "was > > mobile app opened due to a push notification". BUT that also requires some > > more work/reseach on the client Push SDKs. But seriously, this is not a > > priority for the next few months! > > > > > > > > > > [1] https://issues.jboss.org/browse/AGPUSH-116 > > [2] > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 > > [3] > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 > > [4] > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 > > [5] > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From scm.blanc at gmail.com Tue Apr 8 08:36:33 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 8 Apr 2014 14:36:33 +0200 Subject: [aerogear-dev] security updates In-Reply-To: References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> <25263486-9BC6-4149-B1FF-18DCB6FE66E9@redhat.com> Message-ID: On Tue, Apr 8, 2014 at 11:21 AM, Matthias Wessendorf wrote: > > > > On Tue, Apr 8, 2014 at 11:17 AM, Erik Jan de Wit wrote: > >> Hi, >> >> The simplified plugin is using evaluateJavascript in favour of >> sendJavascript, but this method is only available in 4.4 > > > > Ah! Thanks for clarification! But this, than, automatically means: the > Push-Plugin requires 4.4 ? That's a huge impact. We have to support way > older versions, w/ the plugin. > > >> as this is a new method introduced by the chrome web view we can change >> this by using sendJavascript method again. Don't know if this will >> introduce security errors, but I guess not. > > > That would be worth to investigate. Not only for security - also for > 'love' of older Android versions! > +9001, I would even say that this is quite critical and we should find a solution before we release any new version of the plugin. > > > Thanks for the details, Erik! > > -Matthias > > > >> I think the actual fix is not using the old web view. >> >> Cheers, >> Erik Jan >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/638549a2/attachment.html From cvasilak at gmail.com Tue Apr 8 08:52:38 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 8 Apr 2014 15:52:38 +0300 Subject: [aerogear-dev] iOS Team Meeting In-Reply-To: <99DE4975-0D25-4947-B510-656E07734C1D@gmail.com> References: <99DE4975-0D25-4947-B510-656E07734C1D@gmail.com> Message-ID: fyi meeting minutes: Meeting ended Tue Apr 8 12:34:08 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-08-11.46.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-08-11.46.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-08-11.46.log.html On Apr 7, 2014, at 4:42 PM, Christos Vasilakis wrote: > Hi everyone, > > tomorrow will have our iOS team meeting agenda can be found here[1] > > feel free to join us! > > - > Christos > > [1] http://oksoclap.com/p/aerogear-team-mgt-20140407 > > From kpiwko at redhat.com Tue Apr 8 10:13:48 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 8 Apr 2014 16:13:48 +0200 Subject: [aerogear-dev] Obsolote JBDS5 guide Message-ID: <20140408161348.473385d5@kapy-ntb-x220> Hey, what is the plan with this guide http://aerogear.org/docs/guides/aerogear-cordova/CordovaAndroidDevJBDS/ ? It is outdated, using Cordova 2 and JBDS5. Will it be updated or removed altogether? Karel From matzew at apache.org Tue Apr 8 10:14:26 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Apr 2014 16:14:26 +0200 Subject: [aerogear-dev] security updates In-Reply-To: References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> <25263486-9BC6-4149-B1FF-18DCB6FE66E9@redhat.com> Message-ID: On Tue, Apr 8, 2014 at 2:36 PM, Sebastien Blanc wrote: > > > > On Tue, Apr 8, 2014 at 11:21 AM, Matthias Wessendorf wrote: > >> >> >> >> On Tue, Apr 8, 2014 at 11:17 AM, Erik Jan de Wit wrote: >> >>> Hi, >>> >>> The simplified plugin is using evaluateJavascript in favour of >>> sendJavascript, but this method is only available in 4.4 >> >> >> >> Ah! Thanks for clarification! But this, than, automatically means: the >> Push-Plugin requires 4.4 ? That's a huge impact. We have to support way >> older versions, w/ the plugin. >> >> >>> as this is a new method introduced by the chrome web view we can change >>> this by using sendJavascript method again. Don't know if this will >>> introduce security errors, but I guess not. >> >> >> That would be worth to investigate. Not only for security - also for >> 'love' of older Android versions! >> > +9001, I would even say that this is quite critical and we should find a > solution before we release any new version of the plugin. > +1 IMO it's a must criteria to not rely on newer Android versions like 4.4 (or later) -M > >> >> Thanks for the details, Erik! >> >> -Matthias >> >> >> >>> I think the actual fix is not using the old web view. >>> >>> Cheers, >>> Erik Jan >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/2d1c6c6b/attachment.html From edewit at redhat.com Tue Apr 8 10:16:40 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 8 Apr 2014 16:16:40 +0200 Subject: [aerogear-dev] Obsolote JBDS5 guide In-Reply-To: <20140408161348.473385d5@kapy-ntb-x220> References: <20140408161348.473385d5@kapy-ntb-x220> Message-ID: +1 for removing it, the new tooling is much nicer and doesn?t need a guide like this one On 8 Apr,2014, at 16:13 , Karel Piwko wrote: > Hey, > > what is the plan with this guide > http://aerogear.org/docs/guides/aerogear-cordova/CordovaAndroidDevJBDS/ ? > > It is outdated, using Cordova 2 and JBDS5. Will it be updated or removed > altogether? > > Karel > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Apr 8 10:21:12 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Apr 2014 16:21:12 +0200 Subject: [aerogear-dev] Obsolote JBDS5 guide In-Reply-To: <20140408161348.473385d5@kapy-ntb-x220> References: <20140408161348.473385d5@kapy-ntb-x220> Message-ID: On Tue, Apr 8, 2014 at 4:13 PM, Karel Piwko wrote: > Hey, > > what is the plan with this guide > http://aerogear.org/docs/guides/aerogear-cordova/CordovaAndroidDevJBDS/ ? > > It is outdated, using Cordova 2 and JBDS5. let's get rid of it > Will it be updated or removed > altogether? > not sure if anyone is planing on an update to that guide > > Karel > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/1f7b09bd/attachment.html From daniel.bevenius at gmail.com Tue Apr 8 10:22:25 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 8 Apr 2014 16:22:25 +0200 Subject: [aerogear-dev] Obsolote JBDS5 guide In-Reply-To: References: <20140408161348.473385d5@kapy-ntb-x220> Message-ID: +1 for removing it. On 8 April 2014 16:21, Matthias Wessendorf wrote: > > > > On Tue, Apr 8, 2014 at 4:13 PM, Karel Piwko wrote: > >> Hey, >> >> what is the plan with this guide >> http://aerogear.org/docs/guides/aerogear-cordova/CordovaAndroidDevJBDS/ ? >> >> It is outdated, using Cordova 2 and JBDS5. > > > let's get rid of it > > >> Will it be updated or removed >> altogether? >> > > not sure if anyone is planing on an update to that guide > > > >> >> Karel >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/5e596e64/attachment.html From matzew at apache.org Tue Apr 8 10:49:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Apr 2014 16:49:13 +0200 Subject: [aerogear-dev] UPS UX updates In-Reply-To: <53344919.3090506@redhat.com> References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> Message-ID: On Thu, Mar 27, 2014 at 4:51 PM, Hylke Bons wrote: > On 27/03/2014 14:00, Matthias Wessendorf wrote: > > > > > great! I'd don't see a huge problem here in pagination of the variatns; > I doubt that one PushApp has a gazillion different variants > > > I don't think it will be a problem either. When variants are going into > the bazillion numbers there will be many other problems in managing apart > from pagination. Managing them will practically become impossible. > > > > > > >> >> >> >> The Code Snippets : Yeah A button/link would be needed >> >> >> This are the "What's this for?" links. We might want to reconsider the >> name for that. >> > > Now, I open the details of a variant (by clicking on it), and I see the > LINK > > Clicking on it will give me a "popup" with the different code-snippet > (note: we need Cordova + native), per variant, right ? > > > > >> >> >> >> >>> >>> - Sidebar: is that specific to an application? See notes on >>> "applications.png" >>> - The "Notifications" on the sidebar, what's that? >>> - What's the "gear-wheel" for ? >>> >> >> The gear menu will have contextual actions like "Rename" and "Delete". >> It's less cluttered than having them as links or icons on every row. >> > > > > ah!!! Took a bit to realize that :-) > > > > >> >> >> >>> * "dialogs.png" >>> - For an application construct, that's good enough; Creating a variant >>> is a bit more complex (see current UI) >>> - Is there no side bar for this? >>> >> >> I assume that for delete app/variant or reset id/secrets we will use >> the same dialogs >> >>> >>> >>> * installations.png >>> - Is there no side bar for this? >>> - If I understand the view/page correctly, its a list of ALL >>> installations for one PushApplication. However, we should list the variants >>> PER variant (see current UI). The Navigation path on the bread-crumbs >>> would be "Applications >> Mobile HR >> Demo (iOS) >> Installations >>> (number)" >>> >> +1 but I think that was also Hylke's initial idea because on the >> application details screen you see that the link to installations is on the >> "variant" level. I think it was just a glitch in his bread-crumbs. >> >> >> I wasn't too sure about what we could do here. In some cases it's good >> to have installations per variant, in others you want to see them per >> application. >> > > for now, I think, let's list them only per variant - feels (for me) > a bit more clean > > I'm fine with that. > > > > Thanks for the reply. I hope we are now all on the same page. > > Oh, any chance to get a bit rid of that blue; replacing by a different > colour ? :-)) > > > This is the blue from patternfly.org, but we can discuss different > options. What about yellow and black stripes? :P > besides the black/yellow ;-) I think we all agreed on this design, right ? Just wondering what's the state of this. For me feels like: yeah, and all questions/suggestion were answered, and we seems to agree on the mentioned items. At least I get that impression after re-reading this thread, 12 days later :) So, yeah +1 the outcome of this thread; > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140408/2e9e7503/attachment-0001.html From corinnekrych at gmail.com Wed Apr 9 03:57:42 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 9 Apr 2014 09:57:42 +0200 Subject: [aerogear-dev] HelloWorld images Message-ID: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> Hello All, For our HelloWorld demo apps, we agreed on an unified Ui looks, although really simple. It would be nice to have unified images. As discussed with @edewit sticking to png is easier for native app. We need icon and launch image. we have an icon image but what could be used for launch screen? For iOS7 here is the size needed: icon 58x58 icon 80x80 icon 120x120 launch image 640x960 launch image 640x1136 What about Android? So who feel like doing the images for all clients? (looking for an artist) ++ Corinne From edewit at redhat.com Wed Apr 9 04:08:33 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 9 Apr 2014 10:08:33 +0200 Subject: [aerogear-dev] HelloWorld images In-Reply-To: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> References: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> Message-ID: <0E82A29D-6CD6-4397-A106-21A8BC539D04@redhat.com> Hi, After this discussion I?ve adde AeroGear icons to the hello world Cordova app: https://github.com/edewit/aerogear-push-helloworld/tree/cordova/cordova/resources/icon Are these fine or do we need something exotic? I?ll work on some splash screens today. Cheers, Erik Jan On 9 Apr,2014, at 9:57 , Corinne Krych wrote: > Hello All, > > For our HelloWorld demo apps, we agreed on an unified Ui looks, although really simple. It would be nice to have unified images. > As discussed with @edewit sticking to png is easier for native app. We need icon and launch image. > we have an icon image but what could be used for launch screen? > > For iOS7 here is the size needed: > icon 58x58 > icon 80x80 > icon 120x120 > launch image 640x960 > launch image 640x1136 > > What about Android? > So who feel like doing the images for all clients? (looking for an artist) > > ++ > Corinne > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/67a12b91/attachment.html From corinnekrych at gmail.com Wed Apr 9 04:11:38 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 9 Apr 2014 10:11:38 +0200 Subject: [aerogear-dev] HelloWorld images In-Reply-To: <0E82A29D-6CD6-4397-A106-21A8BC539D04@redhat.com> References: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> <0E82A29D-6CD6-4397-A106-21A8BC539D04@redhat.com> Message-ID: Cool Erik If I can have the size specified for iOS I'd be very happy ;) ++ Corinne On 9 April 2014 10:08, Erik Jan de Wit wrote: > Hi, > > After this discussion I've adde AeroGear icons to the hello world Cordova > app: > > > https://github.com/edewit/aerogear-push-helloworld/tree/cordova/cordova/resources/icon > > Are these fine or do we need something exotic? I'll work on some splash > screens today. > > Cheers, > Erik Jan > > On 9 Apr,2014, at 9:57 , Corinne Krych wrote: > > Hello All, > > For our HelloWorld demo apps, we agreed on an unified Ui looks, although > really simple. It would be nice to have unified images. > As discussed with @edewit sticking to png is easier for native app. We > need icon and launch image. > we have an icon image but what could be used for launch screen? > > For iOS7 here is the size needed: > icon 58x58 > icon 80x80 > icon 120x120 > launch image 640x960 > launch image 640x1136 > > What about Android? > So who feel like doing the images for all clients? (looking for an artist) > > ++ > Corinne > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/21746614/attachment.html From scm.blanc at gmail.com Wed Apr 9 04:11:39 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 9 Apr 2014 10:11:39 +0200 Subject: [aerogear-dev] HelloWorld images In-Reply-To: <0E82A29D-6CD6-4397-A106-21A8BC539D04@redhat.com> References: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> <0E82A29D-6CD6-4397-A106-21A8BC539D04@redhat.com> Message-ID: On Wed, Apr 9, 2014 at 10:08 AM, Erik Jan de Wit wrote: > Hi, > > After this discussion I've adde AeroGear icons to the hello world Cordova > app: > > > https://github.com/edewit/aerogear-push-helloworld/tree/cordova/cordova/resources/icon > > Are these fine or do we need something exotic? > IMO these are fine ! > I'll work on some splash screens today. > Awesome ! > > Cheers, > Erik Jan > > On 9 Apr,2014, at 9:57 , Corinne Krych wrote: > > Hello All, > > For our HelloWorld demo apps, we agreed on an unified Ui looks, although > really simple. It would be nice to have unified images. > As discussed with @edewit sticking to png is easier for native app. We > need icon and launch image. > we have an icon image but what could be used for launch screen? > > For iOS7 here is the size needed: > icon 58x58 > icon 80x80 > icon 120x120 > launch image 640x960 > launch image 640x1136 > > What about Android? > So who feel like doing the images for all clients? (looking for an artist) > > ++ > Corinne > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/eea21f4d/attachment.html From kpiwko at redhat.com Wed Apr 9 04:37:05 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 9 Apr 2014 10:37:05 +0200 Subject: [aerogear-dev] security updates In-Reply-To: References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> <25263486-9BC6-4149-B1FF-18DCB6FE66E9@redhat.com> Message-ID: <20140409103705.69c4b465@kapy-ntb-x220> On Tue, 8 Apr 2014 16:14:26 +0200 Matthias Wessendorf wrote: > On Tue, Apr 8, 2014 at 2:36 PM, Sebastien Blanc wrote: > > > > > > > > > On Tue, Apr 8, 2014 at 11:21 AM, Matthias Wessendorf > > wrote: > > > >> > >> > >> > >> On Tue, Apr 8, 2014 at 11:17 AM, Erik Jan de Wit wrote: > >> > >>> Hi, > >>> > >>> The simplified plugin is using evaluateJavascript in favour of > >>> sendJavascript, but this method is only available in 4.4 > >> > >> > >> > >> Ah! Thanks for clarification! But this, than, automatically means: the > >> Push-Plugin requires 4.4 ? That's a huge impact. We have to support way > >> older versions, w/ the plugin. > >> > >> > >>> as this is a new method introduced by the chrome web view we can change > >>> this by using sendJavascript method again. Don't know if this will > >>> introduce security errors, but I guess not. > >> > >> > >> That would be worth to investigate. Not only for security - also for > >> 'love' of older Android versions! > >> > > +9001, I would even say that this is quite critical and we should find a > > solution before we release any new version of the plugin. > > > > +1 IMO it's a must criteria to not rely on newer Android versions like 4.4 > (or later) > +3 as well. > -M > > > > > >> > >> Thanks for the details, Erik! > >> > >> -Matthias > >> > >> > >> > >>> I think the actual fix is not using the old web view. > >>> > >>> Cheers, > >>> Erik Jan > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at 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 > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > From scm.blanc at gmail.com Wed Apr 9 04:42:25 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 9 Apr 2014 10:42:25 +0200 Subject: [aerogear-dev] security updates In-Reply-To: <20140409103705.69c4b465@kapy-ntb-x220> References: <7ED42B41-92DC-468A-8923-636B5334EEB3@redhat.com> <25263486-9BC6-4149-B1FF-18DCB6FE66E9@redhat.com> <20140409103705.69c4b465@kapy-ntb-x220> Message-ID: On Wed, Apr 9, 2014 at 10:37 AM, Karel Piwko wrote: > On Tue, 8 Apr 2014 16:14:26 +0200 > Matthias Wessendorf wrote: > > > On Tue, Apr 8, 2014 at 2:36 PM, Sebastien Blanc > wrote: > > > > > > > > > > > > > > On Tue, Apr 8, 2014 at 11:21 AM, Matthias Wessendorf > > > wrote: > > > > > >> > > >> > > >> > > >> On Tue, Apr 8, 2014 at 11:17 AM, Erik Jan de Wit >wrote: > > >> > > >>> Hi, > > >>> > > >>> The simplified plugin is using evaluateJavascript in favour of > > >>> sendJavascript, but this method is only available in 4.4 > > >> > > >> > > >> > > >> Ah! Thanks for clarification! But this, than, automatically means: the > > >> Push-Plugin requires 4.4 ? That's a huge impact. We have to support > way > > >> older versions, w/ the plugin. > > >> > > >> > > >>> as this is a new method introduced by the chrome web view we can > change > > >>> this by using sendJavascript method again. Don't know if this will > > >>> introduce security errors, but I guess not. > > >> > > >> > > >> That would be worth to investigate. Not only for security - also for > > >> 'love' of older Android versions! > > >> > > > +9001, I would even say that this is quite critical and we should find > a > > > solution before we release any new version of the plugin. > > > > > > > +1 IMO it's a must criteria to not rely on newer Android versions like > 4.4 > > (or later) > > > +3 as well. > Things have gone back to normal ;) https://github.com/aerogear/aerogear-pushplugin-cordova/commit/4a26b801f4b41637ed6808358a11f2b61fbfd180 But like I suggested on IRC, let's wait for the Cordova 3.4.1 release (which could happen today and that contains the xcode 5.1 fix) before releasing a new version of the plugin > > > -M > > > > > > > > > >> > > >> Thanks for the details, Erik! > > >> > > >> -Matthias > > >> > > >> > > >> > > >>> I think the actual fix is not using the old web view. > > >>> > > >>> Cheers, > > >>> Erik Jan > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at 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 > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/911b529d/attachment-0001.html From matzew at apache.org Wed Apr 9 04:44:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Apr 2014 10:44:14 +0200 Subject: [aerogear-dev] Redirecting http requests In-Reply-To: <1396948938278-7416.post@n5.nabble.com> References: <1396948938278-7416.post@n5.nabble.com> Message-ID: I think, I am afraid, that I don't understand what you mean :) In worst case, do a grep and see if the URL is somewhere else ;-) On Tue, Apr 8, 2014 at 11:22 AM, A577127 wrote: > Hello, > > I want to bench the AeroGear UnifiedPush Server. I've decided to make it > quickly (and dirty) by editing the URL for GCM push notifications > (https://android.googleapis.com/gcm/send) to another (localhost:1234). > > Since the UnifiedPush Server uses Google's java gcm server library, I've > downloaded the original code ( here > ) and edited the > Constants.java to replace the "GCM_SEND_ENDPOINT" constant. It seems ok, I > create my .jar (gcm-server.jar) and install it locally with maven. Then I > edited the file unifiedpush-push/pom.xml to add the dependancy instead of > the old jar (com.ganyo). > > Everything seems ok, I deployed my .war file. But surprise ! I can still > send push notifications to my device... (it's the first time I've been sad > that sending a push notification worked :)) > I even checked inside the .war file > > (jboss-eap-6.2\standalone\deployments\ag-push.war\WEB-INF\lib\gcm-server-1.0.2.jar\com\google\android\gcm\server\), > the file Constants.class contains my custom URL instead of the classic gcm > send url. > > How is that possible ? Is the gcm send endpoint url stored somewhere I > missed ? > > Thanks in advance > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Redirecting-http-requests-tp7416.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/741f1e14/attachment.html From bruno at abstractj.org Wed Apr 9 05:11:30 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 09 Apr 2014 06:11:30 -0300 Subject: [aerogear-dev] HelloWorld images In-Reply-To: <0E82A29D-6CD6-4397-A106-21A8BC539D04@redhat.com> References: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> <0E82A29D-6CD6-4397-A106-21A8BC539D04@redhat.com> Message-ID: <53450EC2.1030204@abstractj.org> Looks good. > Erik Jan de Wit > April 9, 2014 at 5:08 AM > Hi, > > After this discussion I?ve adde AeroGear icons to the hello world > Cordova app: > > https://github.com/edewit/aerogear-push-helloworld/tree/cordova/cordova/resources/icon > > Are these fine or do we need something exotic? I?ll work on some > splash screens today. > > Cheers, > Erik Jan > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > Corinne Krych > April 9, 2014 at 4:57 AM > Hello All, > > For our HelloWorld demo apps, we agreed on an unified Ui looks, > although really simple. It would be nice to have unified images. > As discussed with @edewit sticking to png is easier for native app. We > need icon and launch image. > we have an icon image but what could be used for launch screen? > > For iOS7 here is the size needed: > icon 58x58 > icon 80x80 > icon 120x120 > launch image 640x960 > launch image 640x1136 > > What about Android? > So who feel like doing the images for all clients? (looking for an artist) > > ++ > Corinne > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/595abcf1/attachment.bin From daniel at passos.me Wed Apr 9 09:06:58 2014 From: daniel at passos.me (Daniel Passos) Date: Wed, 9 Apr 2014 10:06:58 -0300 Subject: [aerogear-dev] HelloWorld images In-Reply-To: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> References: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> Message-ID: Well, android needs a lot of sizes :) from mdpi to xxxhdpi[1] but, we always use Android asset Studio[2] :D Btw, we already have that in other example apps. [1] http://developer.android.com/design/style/iconography.html [2] http://android-ui-utils.googlecode.com/hg/asset-studio/dist/icons-launcher.html -- Passos On Wed, Apr 9, 2014 at 4:57 AM, Corinne Krych wrote: > Hello All, > > For our HelloWorld demo apps, we agreed on an unified Ui looks, although > really simple. It would be nice to have unified images. > As discussed with @edewit sticking to png is easier for native app. We > need icon and launch image. > we have an icon image but what could be used for launch screen? > > For iOS7 here is the size needed: > icon 58x58 > icon 80x80 > icon 120x120 > launch image 640x960 > launch image 640x1136 > > What about Android? > So who feel like doing the images for all clients? (looking for an artist) > > ++ > Corinne > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/7bdf8d13/attachment.html From matzew at apache.org Wed Apr 9 10:31:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Apr 2014 16:31:43 +0200 Subject: [aerogear-dev] A new -user mailing list ? Message-ID: Hi, Hylke brought up a good point: a new -user mailing list (as we are deleting the (never used) forum). Maybe it's a good idea to have a "-user" mailing list as well? This would reduce noise for both developers and users (though I suspect developers will be on both anyway). Hylke IMO that's a good suggestion. +1 on having a new list for -user centric questions -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/e3f08eeb/attachment.html From scm.blanc at gmail.com Wed Apr 9 11:07:18 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 9 Apr 2014 17:07:18 +0200 Subject: [aerogear-dev] A new -user mailing list ? In-Reply-To: References: Message-ID: +1 Make sense, most of the projects have a dev and a user list On Wed, Apr 9, 2014 at 4:31 PM, Matthias Wessendorf wrote: > Hi, > > Hylke brought up a good point: a new -user mailing list (as we are > deleting the (never used) forum). > > > > Maybe it's a good idea to have a "-user" mailing list as well? > This would reduce noise for both developers and users (though I suspect > developers will be on both anyway). > > Hylke > > > IMO that's a good suggestion. +1 on having a new list for -user centric > questions > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/a7245e9f/attachment.html From jbalunas at redhat.com Wed Apr 9 11:20:27 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Wed, 9 Apr 2014 11:20:27 -0400 Subject: [aerogear-dev] A new -user mailing list ? In-Reply-To: References: Message-ID: <24746B43-9163-4597-A4CE-6C63E14B0B03@redhat.com> +1 On Apr 9, 2014, at 11:07 AM, Sebastien Blanc wrote: > +1 > Make sense, most of the projects have a dev and a user list > > > > > On Wed, Apr 9, 2014 at 4:31 PM, Matthias Wessendorf wrote: > Hi, > > Hylke brought up a good point: a new -user mailing list (as we are deleting the (never used) forum). > > > > Maybe it's a good idea to have a "-user" mailing list as well? > This would reduce noise for both developers and users (though I suspect > developers will be on both anyway). > > Hylke > > > IMO that's a good suggestion. +1 on having a new list for -user centric questions > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/16202cce/attachment-0001.html From scm.blanc at gmail.com Wed Apr 9 11:30:05 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 9 Apr 2014 17:30:05 +0200 Subject: [aerogear-dev] HelloWorld images In-Reply-To: References: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> Message-ID: Erik has started on the Splash Screens : https://github.com/aerogear/aerogear-push-helloworld/pull/3 It's nice and lean but I wonder if we want more info on the splash screen, like the app name ? On Wed, Apr 9, 2014 at 3:06 PM, Daniel Passos wrote: > Well, android needs a lot of sizes :) from mdpi to xxxhdpi[1] but, we > always use Android asset Studio[2] :D > > Btw, we already have that in other example apps. > > [1] http://developer.android.com/design/style/iconography.html > [2] > http://android-ui-utils.googlecode.com/hg/asset-studio/dist/icons-launcher.html > > -- Passos > > > On Wed, Apr 9, 2014 at 4:57 AM, Corinne Krych wrote: > >> Hello All, >> >> For our HelloWorld demo apps, we agreed on an unified Ui looks, although >> really simple. It would be nice to have unified images. >> As discussed with @edewit sticking to png is easier for native app. We >> need icon and launch image. >> we have an icon image but what could be used for launch screen? >> >> For iOS7 here is the size needed: >> icon 58x58 >> icon 80x80 >> icon 120x120 >> launch image 640x960 >> launch image 640x1136 >> >> What about Android? >> So who feel like doing the images for all clients? (looking for an artist) >> >> ++ >> Corinne >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/bffacc4b/attachment.html From scm.blanc at gmail.com Wed Apr 9 11:44:17 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 9 Apr 2014 17:44:17 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: <2017946A-5FBC-48FE-9F48-B4ED8D50CF54@redhat.com> References: <2017946A-5FBC-48FE-9F48-B4ED8D50CF54@redhat.com> Message-ID: Hi All ! A quick update for the different mobile clients, concerning the HelloWorld : - We got the Cordova PR : https://github.com/aerogear/aerogear-push-helloworld/pull/1 - We got the iOS PR : https://github.com/aerogear/aerogear-push-helloworld/pull/2 - Android is almost there but we have a trailer ! https://www.dropbox.com/s/hiy6soifldcntbl/ag-push-helloworld.mp4 Erik is also working on the splash screen : https://github.com/aerogear/aerogear-push-helloworld/pull/3 Next week, we should be able to start on polishing the documentation. Great Work team ! Sebi On Mon, Apr 7, 2014 at 5:33 PM, Erik Jan de Wit wrote: > As I already called mine cordova +1 on that ;) > > On 7 Apr,2014, at 17:28 , Matthias Wessendorf wrote: > > keep it simple? > > -android > -cordova > -ios > > the ag-push-hello is redundant, IMO > > > On Mon, Apr 7, 2014 at 5:27 PM, Sebastien Blanc wrote: > >> Hi, >> The repo for the UnifiedPush Helloworld has been created : >> https://github.com/aerogear/aerogear-push-helloworld >> This repo will be divided into 3 folders , one for each client, let's >> agree on the names of these. I propose : >> >> - aerogear-push-helloworld-android >> - aerogear-push-helloworld-cordova >> - aerogear-push-helloworld-ios >> >> wdyt ? >> >> >> >> >> On Mon, Apr 7, 2014 at 3:41 PM, Matthias Wessendorf wrote: >> >>> yes/no :-) >>> >>> HelloWorld: just clients -no server code - >>> https://issues.jboss.org/browse/AGPUSH-588 >>> >>> >>> Quickstarts: server/client >>> Quickstart-server (epic): >>> https://issues.jboss.org/browse/AGPUSH-596 >>> >>> Quickstart-client (epic): >>> https://issues.jboss.org/browse/AGPUSH-604 >>> >>> but atm, we focus on the HelloWorld; once they are done and documented, >>> we will get to the Quickstarts >>> >>> >>> >>> On Mon, Apr 7, 2014 at 3:21 PM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Ah my bad. I was assuming the quickstarts were in Java. >>>> >>>> >>>> On 7 April 2014 15:05, Matthias Wessendorf wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 7, 2014 at 2:59 PM, Daniel Bevenius < >>>>> daniel.bevenius at gmail.com> wrote: >>>>> >>>>>> For the package name, was that meant to be uppercase? >>>>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>>>> >>>>> >>>>> nope - not really; iOS app:name -> HelloWord; package "o.j.a.u" >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 7 April 2014 14:54, Matthias Wessendorf wrote: >>>>>> >>>>>>> Since we start w/ the Hello World example, let's make sure we agree >>>>>>> on a name :-) >>>>>>> >>>>>>> I'd suggest we name it "AeroGear UnifiedPush HelloWorld". >>>>>>> >>>>>>> For packages / bundle Identifier, I'd vote for >>>>>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>>>>> >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> the GH repos have been created: >>>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>> >>>>>>>> I edited the README to 'define' the (sub)folder structure >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> here are the JIRAs (tasks and epics (which have sub-tasks) for >>>>>>>>> this, so far: >>>>>>>>> >>>>>>>>> Github repo work: >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-586 >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-587 >>>>>>>>> >>>>>>>>> Hello-World Example work (epic): >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-588 >>>>>>>>> >>>>>>>>> >>>>>>>>> Quickstart-server (epic): >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-596 >>>>>>>>> >>>>>>>>> Quickstart-client (epic): >>>>>>>>> https://issues.jboss.org/browse/AGPUSH-604 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> It's totally valid to: >>>>>>>>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if >>>>>>>>> they have several work units). >>>>>>>>> >>>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf < >>>>>>>>> matzew at apache.org> wrote: >>>>>>>>> >>>>>>>>>> Hello there, >>>>>>>>>> >>>>>>>>>> we recently had talks about creating some simplified quickstarts >>>>>>>>>> and hello-word demos, related to the UnifiedPush Server and JBoss AS >>>>>>>>>> developers: >>>>>>>>>> >>>>>>>>>> * Hello World (No Server Code - just client receiving push, no >>>>>>>>>> fancy (complex) UI on the client, nor integrated into a Cookbook or >>>>>>>>>> something that has "dependencies") >>>>>>>>>> ** Cordova >>>>>>>>>> ** Android >>>>>>>>>> >>>>>>>>>> For iOS that is already there: >>>>>>>>>> https://github.com/aerogear/aerogear-push-ios-demo >>>>>>>>>> >>>>>>>>>> Yes, just usage of the "Push Registration SDKs", is the goal >>>>>>>>>> here: keep it simple, since native push can be a complicated use-case all >>>>>>>>>> on its own and so it will be good to make sure we cover the basics here. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Beyond the Hello-World, we wanted some different quickstarts. The >>>>>>>>>> "server" components that come to mind would be: >>>>>>>>>> >>>>>>>>>> *Secured CRUD + Push Integration (Java Sender) >>>>>>>>>> ** JAX-RS + PicketLink >>>>>>>>>> ** SpringMVC/Spring Security >>>>>>>>>> ** JAX-RS + Apache Camel >>>>>>>>>> >>>>>>>>>> These need to function on both JBoss AS 7.X and EAP. >>>>>>>>>> >>>>>>>>>> Josh, from the JDF team, has already said he wants to help on the >>>>>>>>>> server projects (especially the JAX-RS/PL and Spring ones). yay! >>>>>>>>>> Note: Josh already has a simple backend started that is used in >>>>>>>>>> JDF quickstarts that would be good to re-use to make it easier for >>>>>>>>>> developers to transition from one to other. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The goal would be the SERVER acts same to outside (identical REST >>>>>>>>>> endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs. >>>>>>>>>> Camel)) >>>>>>>>>> >>>>>>>>>> For these different servers, there would be mobile apps needed: >>>>>>>>>> * Android >>>>>>>>>> * Cordova >>>>>>>>>> * iOS >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The idea would be to keep them simple and straightforward as >>>>>>>>>> well, e.g. for iOS that means plain usage of NSURLConnection / >>>>>>>>>> NSURLSession. But for the "push registration" of the client, >>>>>>>>>> the iOS-push SDK would be used (same/similar would apply to >>>>>>>>>> Cordova or Android). Similar to the above 'Hello World', the quickstarts >>>>>>>>>> are going to be focused only on Push functionality, so for these we would >>>>>>>>>> leave out pipes and such until later versions. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I will be creating Epics and subtasks in JIRA for this. >>>>>>>>>> >>>>>>>>>> For the location of all these projects, I had this "uber repo" >>>>>>>>>> location in mind: >>>>>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>>>> >>>>>>>>>> Greetings, >>>>>>>>>> Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at 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 >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/3c59876a/attachment-0001.html From matzew at apache.org Wed Apr 9 12:15:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Apr 2014 18:15:52 +0200 Subject: [aerogear-dev] UnifiedPush Server: Hello World- and Quickstart Examples In-Reply-To: References: <2017946A-5FBC-48FE-9F48-B4ED8D50CF54@redhat.com> Message-ID: That's awesome! On Wed, Apr 9, 2014 at 5:44 PM, Sebastien Blanc wrote: > Hi All ! > > A quick update for the different mobile clients, concerning the HelloWorld > : > > - We got the Cordova PR : > https://github.com/aerogear/aerogear-push-helloworld/pull/1 > - We got the iOS PR : > https://github.com/aerogear/aerogear-push-helloworld/pull/2 > - Android is almost there but we have a trailer ! > https://www.dropbox.com/s/hiy6soifldcntbl/ag-push-helloworld.mp4 > > Erik is also working on the splash screen : > https://github.com/aerogear/aerogear-push-helloworld/pull/3 > > Next week, we should be able to start on polishing the documentation. > > Great Work team ! > > Sebi > > > > > On Mon, Apr 7, 2014 at 5:33 PM, Erik Jan de Wit wrote: > >> As I already called mine cordova +1 on that ;) >> >> On 7 Apr,2014, at 17:28 , Matthias Wessendorf wrote: >> >> keep it simple? >> >> -android >> -cordova >> -ios >> >> the ag-push-hello is redundant, IMO >> >> >> On Mon, Apr 7, 2014 at 5:27 PM, Sebastien Blanc wrote: >> >>> Hi, >>> The repo for the UnifiedPush Helloworld has been created : >>> https://github.com/aerogear/aerogear-push-helloworld >>> This repo will be divided into 3 folders , one for each client, let's >>> agree on the names of these. I propose : >>> >>> - aerogear-push-helloworld-android >>> - aerogear-push-helloworld-cordova >>> - aerogear-push-helloworld-ios >>> >>> wdyt ? >>> >>> >>> >>> >>> On Mon, Apr 7, 2014 at 3:41 PM, Matthias Wessendorf wrote: >>> >>>> yes/no :-) >>>> >>>> HelloWorld: just clients -no server code - >>>> https://issues.jboss.org/browse/AGPUSH-588 >>>> >>>> >>>> Quickstarts: server/client >>>> Quickstart-server (epic): >>>> https://issues.jboss.org/browse/AGPUSH-596 >>>> >>>> Quickstart-client (epic): >>>> https://issues.jboss.org/browse/AGPUSH-604 >>>> >>>> but atm, we focus on the HelloWorld; once they are done and documented, >>>> we will get to the Quickstarts >>>> >>>> >>>> >>>> On Mon, Apr 7, 2014 at 3:21 PM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> Ah my bad. I was assuming the quickstarts were in Java. >>>>> >>>>> >>>>> On 7 April 2014 15:05, Matthias Wessendorf wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Apr 7, 2014 at 2:59 PM, Daniel Bevenius < >>>>>> daniel.bevenius at gmail.com> wrote: >>>>>> >>>>>>> For the package name, was that meant to be uppercase? >>>>>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>>>>> >>>>>> >>>>>> nope - not really; iOS app:name -> HelloWord; package "o.j.a.u" >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7 April 2014 14:54, Matthias Wessendorf wrote: >>>>>>> >>>>>>>> Since we start w/ the Hello World example, let's make sure we agree >>>>>>>> on a name :-) >>>>>>>> >>>>>>>> I'd suggest we name it "AeroGear UnifiedPush HelloWorld". >>>>>>>> >>>>>>>> For packages / bundle Identifier, I'd vote for >>>>>>>> "org.jboss.aerogear.unifiedpush.HelloWorld" >>>>>>>> >>>>>>>> >>>>>>>> -Matthias >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Apr 7, 2014 at 2:44 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> the GH repos have been created: >>>>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>>> >>>>>>>>> I edited the README to 'define' the (sub)folder structure >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Apr 1, 2014 at 6:27 PM, Matthias Wessendorf < >>>>>>>>> matzew at apache.org> wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> here are the JIRAs (tasks and epics (which have sub-tasks) for >>>>>>>>>> this, so far: >>>>>>>>>> >>>>>>>>>> Github repo work: >>>>>>>>>> https://issues.jboss.org/browse/AGPUSH-586 >>>>>>>>>> https://issues.jboss.org/browse/AGPUSH-587 >>>>>>>>>> >>>>>>>>>> Hello-World Example work (epic): >>>>>>>>>> https://issues.jboss.org/browse/AGPUSH-588 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Quickstart-server (epic): >>>>>>>>>> https://issues.jboss.org/browse/AGPUSH-596 >>>>>>>>>> >>>>>>>>>> Quickstart-client (epic): >>>>>>>>>> https://issues.jboss.org/browse/AGPUSH-604 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It's totally valid to: >>>>>>>>>> - add more sub-tasks, or break sub-tasks out into epics (e.g. if >>>>>>>>>> they have several work units). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Greetings, >>>>>>>>>> Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Mar 31, 2014 at 3:25 PM, Matthias Wessendorf < >>>>>>>>>> matzew at apache.org> wrote: >>>>>>>>>> >>>>>>>>>>> Hello there, >>>>>>>>>>> >>>>>>>>>>> we recently had talks about creating some simplified quickstarts >>>>>>>>>>> and hello-word demos, related to the UnifiedPush Server and JBoss AS >>>>>>>>>>> developers: >>>>>>>>>>> >>>>>>>>>>> * Hello World (No Server Code - just client receiving push, no >>>>>>>>>>> fancy (complex) UI on the client, nor integrated into a Cookbook or >>>>>>>>>>> something that has "dependencies") >>>>>>>>>>> ** Cordova >>>>>>>>>>> ** Android >>>>>>>>>>> >>>>>>>>>>> For iOS that is already there: >>>>>>>>>>> https://github.com/aerogear/aerogear-push-ios-demo >>>>>>>>>>> >>>>>>>>>>> Yes, just usage of the "Push Registration SDKs", is the goal >>>>>>>>>>> here: keep it simple, since native push can be a complicated use-case all >>>>>>>>>>> on its own and so it will be good to make sure we cover the basics here. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Beyond the Hello-World, we wanted some different quickstarts. >>>>>>>>>>> The "server" components that come to mind would be: >>>>>>>>>>> >>>>>>>>>>> *Secured CRUD + Push Integration (Java Sender) >>>>>>>>>>> ** JAX-RS + PicketLink >>>>>>>>>>> ** SpringMVC/Spring Security >>>>>>>>>>> ** JAX-RS + Apache Camel >>>>>>>>>>> >>>>>>>>>>> These need to function on both JBoss AS 7.X and EAP. >>>>>>>>>>> >>>>>>>>>>> Josh, from the JDF team, has already said he wants to help on >>>>>>>>>>> the server projects (especially the JAX-RS/PL and Spring ones). yay! >>>>>>>>>>> Note: Josh already has a simple backend started that is used in >>>>>>>>>>> JDF quickstarts that would be good to re-use to make it easier for >>>>>>>>>>> developers to transition from one to other. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The goal would be the SERVER acts same to outside (identical >>>>>>>>>>> REST endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring >>>>>>>>>>> vs. Camel)) >>>>>>>>>>> >>>>>>>>>>> For these different servers, there would be mobile apps needed: >>>>>>>>>>> * Android >>>>>>>>>>> * Cordova >>>>>>>>>>> * iOS >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The idea would be to keep them simple and straightforward as >>>>>>>>>>> well, e.g. for iOS that means plain usage of NSURLConnection / >>>>>>>>>>> NSURLSession. But for the "push registration" of the client, >>>>>>>>>>> the iOS-push SDK would be used (same/similar would apply to >>>>>>>>>>> Cordova or Android). Similar to the above 'Hello World', the quickstarts >>>>>>>>>>> are going to be focused only on Push functionality, so for these we would >>>>>>>>>>> leave out pipes and such until later versions. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I will be creating Epics and subtasks in JIRA for this. >>>>>>>>>>> >>>>>>>>>>> For the location of all these projects, I had this "uber repo" >>>>>>>>>>> location in mind: >>>>>>>>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>>>>>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>>>>> >>>>>>>>>>> Greetings, >>>>>>>>>>> Matthias >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at 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 >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at 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 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/58908ae4/attachment-0001.html From daniel at passos.me Wed Apr 9 12:15:41 2014 From: daniel at passos.me (Daniel Passos) Date: Wed, 9 Apr 2014 13:15:41 -0300 Subject: [aerogear-dev] HelloWorld images In-Reply-To: References: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> Message-ID: Like this? http://take.ms/hFM0Y On Wed, Apr 9, 2014 at 12:30 PM, Sebastien Blanc wrote: > Erik has started on the Splash Screens : > https://github.com/aerogear/aerogear-push-helloworld/pull/3 > It's nice and lean but I wonder if we want more info on the splash screen, > like the app name ? > > > > On Wed, Apr 9, 2014 at 3:06 PM, Daniel Passos wrote: > >> Well, android needs a lot of sizes :) from mdpi to xxxhdpi[1] but, we >> always use Android asset Studio[2] :D >> >> Btw, we already have that in other example apps. >> >> [1] http://developer.android.com/design/style/iconography.html >> [2] >> http://android-ui-utils.googlecode.com/hg/asset-studio/dist/icons-launcher.html >> >> -- Passos >> >> >> On Wed, Apr 9, 2014 at 4:57 AM, Corinne Krych wrote: >> >>> Hello All, >>> >>> For our HelloWorld demo apps, we agreed on an unified Ui looks, although >>> really simple. It would be nice to have unified images. >>> As discussed with @edewit sticking to png is easier for native app. We >>> need icon and launch image. >>> we have an icon image but what could be used for launch screen? >>> >>> For iOS7 here is the size needed: >>> icon 58x58 >>> icon 80x80 >>> icon 120x120 >>> launch image 640x960 >>> launch image 640x1136 >>> >>> What about Android? >>> So who feel like doing the images for all clients? (looking for an >>> artist) >>> >>> ++ >>> Corinne >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/c84fe378/attachment.html From hbons at redhat.com Wed Apr 9 14:29:53 2014 From: hbons at redhat.com (Hylke Bons) Date: Wed, 09 Apr 2014 19:29:53 +0100 Subject: [aerogear-dev] UPS UX updates In-Reply-To: References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> Message-ID: <534591A1.2040500@redhat.com> On 08/04/2014 15:49, Matthias Wessendorf wrote: > > > > besides the black/yellow ;-) I think we all agreed on this design, > right ? > > > Just wondering what's the state of this. For me feels like: yeah, and > all questions/suggestion were answered, and we seems to agree on the > mentioned items. At least I get that impression after re-reading this > thread, 12 days later :) > > > So, yeah +1 the outcome of this thread; > > > Great. I've cleaned up the document a bit: https://github.com/hbons/aerogear-design/tree/master/Unified%20Push%20Server/Export I've also added a pagination widget design on the last page (on "Installations") as Sebastien requested. If we agree on that I will update the wireframes with the changes from the visual designs. It will take too much time making pixelperfect mockups for every page and dialog, so I'm just going to do that in the wireframes and we'll work from there. Most of the styling is common and can be shared, so there's no need to create a visual reference for everything. Thanks. Hylke From bruno at abstractj.org Wed Apr 9 15:18:44 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 09 Apr 2014 12:18:44 -0700 (PDT) Subject: [aerogear-dev] A new -user mailing list ? In-Reply-To: References: Message-ID: <1397071123393.f8a63b25@Nodemailer> +1? abstractj On Wed, Apr 9, 2014 at 11:31 AM, Matthias Wessendorf wrote: > Hi, > Hylke brought up a good point: a new -user mailing list (as we are deleting > the (never used) forum). > > Maybe it's a good idea to have a "-user" mailing list as well? > This would reduce noise for both developers and users (though I suspect > developers will be on both anyway). > Hylke > > IMO that's a good suggestion. +1 on having a new list for -user centric > questions > -- > Matthias Wessendorf > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/25b0add2/attachment.html From matzew at apache.org Wed Apr 9 15:34:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Apr 2014 21:34:35 +0200 Subject: [aerogear-dev] UPS UX updates In-Reply-To: <534591A1.2040500@redhat.com> References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> <534591A1.2040500@redhat.com> Message-ID: On Wed, Apr 9, 2014 at 8:29 PM, Hylke Bons wrote: > On 08/04/2014 15:49, Matthias Wessendorf wrote: > > > > > > > > besides the black/yellow ;-) I think we all agreed on this design, > > right ? > > > > > > Just wondering what's the state of this. For me feels like: yeah, and > > all questions/suggestion were answered, and we seems to agree on the > > mentioned items. At least I get that impression after re-reading this > > thread, 12 days later :) > > > > > > So, yeah +1 the outcome of this thread; > > > > > > > > Great. I've cleaned up the document a bit: > > https://github.com/hbons/aerogear-design/tree/master/Unified%20Push%20Server/Export > > I've also added a pagination widget design on the last page (on > "Installations") as Sebastien requested. > As said before, this looks really good!!! Oh, one thing I am missing is a 'screen' for the code snippets: Clicking on the "What's this for" links will give me a "popup" with the different code-snippet (note: we need Cordova + native), per variant, right ? (re-reading this thread again, I noticed that my question was never answered) Or will these screens (or popups) be 'similar' screens you were designing ? If we agree on that I will update the wireframes with the changes from > the visual designs. It will take too much time making pixelperfect > mockups for every page and dialog, so I'm just going to do that in the > wireframes and we'll work from there. Most of the styling is common and > can be shared, so there's no need to create a visual reference for > everything. > +1 the overall guide is good, and getting HTML mockup for a few screens will make it easy to transform it to similar/identical screens. Looking really forward it! Again, great work! -Matthias > > Thanks. > > Hylke > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140409/e7c0f459/attachment.html From daniel.bevenius at gmail.com Thu Apr 10 01:01:42 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 10 Apr 2014 07:01:42 +0200 Subject: [aerogear-dev] A new -user mailing list ? In-Reply-To: <1397071123393.f8a63b25@Nodemailer> References: <1397071123393.f8a63b25@Nodemailer> Message-ID: +1 sounds good On 9 April 2014 21:18, Bruno Oliveira wrote: > +1 > -- > abstractj > > > On Wed, Apr 9, 2014 at 11:31 AM, Matthias Wessendorf wrote: > >> Hi, >> >> Hylke brought up a good point: a new -user mailing list (as we are >> deleting the (never used) forum). >> >> >> >> Maybe it's a good idea to have a "-user" mailing list as well? >> This would reduce noise for both developers and users (though I suspect >> developers will be on both anyway). >> >> Hylke >> >> >> IMO that's a good suggestion. +1 on having a new list for -user centric >> questions >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/12fdd16c/attachment-0001.html From qmx at qmx.me Thu Apr 10 02:08:28 2014 From: qmx at qmx.me (Douglas Campos) Date: Thu, 10 Apr 2014 03:08:28 -0300 Subject: [aerogear-dev] A new -user mailing list ? In-Reply-To: References: Message-ID: <20140410060828.GM44433@rohan.local> let's do this, +1 -- qmx From miguel21op at gmail.com Thu Apr 10 02:33:22 2014 From: miguel21op at gmail.com (Miiguel Lemos) Date: Thu, 10 Apr 2014 07:33:22 +0100 Subject: [aerogear-dev] A new -user mailing list ? In-Reply-To: <20140410060828.GM44433@rohan.local> References: <20140410060828.GM44433@rohan.local> Message-ID: Yes. I agree. For users (like me) many discussions have no interest. On the other hand, usability, bugs, characteristics and functionalities of the product, etc. deserve a space of its own with the due relevance and well organized. Enviado do meu iPad No dia 10/04/2014, ?s 07:08, Douglas Campos escreveu: > let's do this, +1 > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From miguel21op at gmail.com Thu Apr 10 06:22:31 2014 From: miguel21op at gmail.com (Miiguel Lemos) Date: Thu, 10 Apr 2014 11:22:31 +0100 Subject: [aerogear-dev] Geotagged notifications Message-ID: <4F74473F-8E5A-4C56-9162-C8D11A9AACF1@gmail.com> Geotagged notifications are a very relevant component of any service of push notifications. First of all, because of marketing reasons: when a notfication is received in the scope of a given geofence (for instance the proximity to a venue, store, etc.) the probability of the user react to it is much bigger. Using other technologies (other than GPS, cell towers, Wi-FI, etc) - I can come back to this later - you can also use location based services for automated in-house check-ins and subsequent events (many...). Basically there are two ways of managing geotagged - I'd prefer to say location based - notifications: A) The phone sends periodically its location to a server and the backend sends to the phone - via Google, Apple, whatever - the push not; B) The server sends to the phone all the geotagged notifications it has for a given user or group, and te terminal itself checks locally if the location criteria are matched, triggering the local notification if that match occurs (considerang also the radius, accuracy of the coordinates, etc.) At this moment I'll not elaborate more ore on this, but the second way has several advantages over the first. Of course the second method has several implications, namelly in the flow of the service, but if you want we can talk about this later. Other issues, like battery drainage, privacy matters, etc. must also be taken into account in the solution implemented... Miguel Enviado do meu iPad From hbons at redhat.com Thu Apr 10 06:48:19 2014 From: hbons at redhat.com (Hylke Bons) Date: Thu, 10 Apr 2014 11:48:19 +0100 Subject: [aerogear-dev] UPS UX updates In-Reply-To: References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> <534591A1.2040500@redhat.com> Message-ID: <534676F3.60102@redhat.com> Here's the page for code snippets: https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/9.png I've also updated the Application Detail page to change the links that say "What's this for?" to "Example implementation": https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/6.png Let me know if this is alright. Hylke On 09/04/2014 20:34, Matthias Wessendorf wrote: > > > > On Wed, Apr 9, 2014 at 8:29 PM, Hylke Bons > wrote: > > On 08/04/2014 15:49, Matthias Wessendorf wrote: > > > > > > > > besides the black/yellow ;-) I think we all agreed on this design, > > right ? > > > > > > Just wondering what's the state of this. For me feels like: > yeah, and > > all questions/suggestion were answered, and we seems to agree on the > > mentioned items. At least I get that impression after re-reading > this > > thread, 12 days later :) > > > > > > So, yeah +1 the outcome of this thread; > > > > > > > > Great. I've cleaned up the document a bit: > https://github.com/hbons/aerogear-design/tree/master/Unified%20Push%20Server/Export > > I've also added a pagination widget design on the last page (on > "Installations") as Sebastien requested. > > > > As said before, this looks really good!!! > > > Oh, one thing I am missing is a 'screen' for the code snippets: > Clicking on the "What's this for" links will give me a "popup" with > the different code-snippet (note: we need Cordova + native), per > variant, right ? > (re-reading this thread again, I noticed that my question was never > answered) > > Or will these screens (or popups) be 'similar' screens you were > designing ? > > > If we agree on that I will update the wireframes with the changes from > the visual designs. It will take too much time making pixelperfect > mockups for every page and dialog, so I'm just going to do that in the > wireframes and we'll work from there. Most of the styling is > common and > can be shared, so there's no need to create a visual reference for > everything. > > > +1 the overall guide is good, and getting HTML mockup for a few > screens will make it easy to transform it to similar/identical screens. > Looking really forward it! > > Again, great work! > > -Matthias > > > Thanks. > > Hylke > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/5a2bad1e/attachment.html From matzew at apache.org Thu Apr 10 07:35:58 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Apr 2014 13:35:58 +0200 Subject: [aerogear-dev] UPS UX updates In-Reply-To: <534676F3.60102@redhat.com> References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> <534591A1.2040500@redhat.com> <534676F3.60102@redhat.com> Message-ID: On Thu, Apr 10, 2014 at 12:48 PM, Hylke Bons wrote: > Here's the page for code snippets: > > https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/9.png > > I've also updated the Application Detail page to change the links that say > "What's this for?" to "Example implementation": > https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/6.png > > A click on "Example implementation" brings you to the screen of 9.png, right ? > Let me know if this is alright. > > Hylke > > > > > On 09/04/2014 20:34, Matthias Wessendorf wrote: > > > > > On Wed, Apr 9, 2014 at 8:29 PM, Hylke Bons wrote: > >> On 08/04/2014 15:49, Matthias Wessendorf wrote: >> > >> > >> > >> > besides the black/yellow ;-) I think we all agreed on this design, >> > right ? >> > >> > >> > Just wondering what's the state of this. For me feels like: yeah, and >> > all questions/suggestion were answered, and we seems to agree on the >> > mentioned items. At least I get that impression after re-reading this >> > thread, 12 days later :) >> > >> > >> > So, yeah +1 the outcome of this thread; >> > >> > >> > >> >> Great. I've cleaned up the document a bit: >> >> https://github.com/hbons/aerogear-design/tree/master/Unified%20Push%20Server/Export >> >> I've also added a pagination widget design on the last page (on >> "Installations") as Sebastien requested. >> > > > As said before, this looks really good!!! > > > Oh, one thing I am missing is a 'screen' for the code snippets: > Clicking on the "What's this for" links will give me a "popup" with the > different code-snippet (note: we need Cordova + native), per variant, right > ? > (re-reading this thread again, I noticed that my question was never > answered) > > Or will these screens (or popups) be 'similar' screens you were > designing ? > > > If we agree on that I will update the wireframes with the changes from >> the visual designs. It will take too much time making pixelperfect >> mockups for every page and dialog, so I'm just going to do that in the >> wireframes and we'll work from there. Most of the styling is common and >> can be shared, so there's no need to create a visual reference for >> everything. >> > > +1 the overall guide is good, and getting HTML mockup for a few screens > will make it easy to transform it to similar/identical screens. > Looking really forward it! > > Again, great work! > > -Matthias > > >> >> Thanks. >> >> Hylke >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/85dc7d07/attachment-0001.html From hbons at redhat.com Thu Apr 10 08:28:10 2014 From: hbons at redhat.com (Hylke Bons) Date: Thu, 10 Apr 2014 13:28:10 +0100 Subject: [aerogear-dev] UPS UX updates In-Reply-To: References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> <534591A1.2040500@redhat.com> <534676F3.60102@redhat.com> Message-ID: <53468E5A.4040303@redhat.com> On 10/04/2014 12:35, Matthias Wessendorf wrote: > > > > On Thu, Apr 10, 2014 at 12:48 PM, Hylke Bons > wrote: > > Here's the page for code snippets: > https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/9.png > > I've also updated the Application Detail page to change the links > that say "What's this for?" to "Example implementation": > https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/6.png > > > A click on "Example implementation" brings you to the screen of 9.png, > right ? > > Yes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/14ce6bef/attachment.html From matzew at apache.org Thu Apr 10 08:38:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Apr 2014 14:38:53 +0200 Subject: [aerogear-dev] UPS UX updates In-Reply-To: <53468E5A.4040303@redhat.com> References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> <534591A1.2040500@redhat.com> <534676F3.60102@redhat.com> <53468E5A.4040303@redhat.com> Message-ID: On Thu, Apr 10, 2014 at 2:28 PM, Hylke Bons wrote: > On 10/04/2014 12:35, Matthias Wessendorf wrote: > > > > > On Thu, Apr 10, 2014 at 12:48 PM, Hylke Bons wrote: > >> Here's the page for code snippets: >> >> https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/9.png >> >> I've also updated the Application Detail page to change the links that >> say "What's this for?" to "Example implementation": >> https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/6.png >> >> > A click on "Example implementation" brings you to the screen of 9.png, > right ? > > > Yes. > Awesome! Thanks for the update! -Matthias > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/ab5ee237/attachment.html From lholmqui at redhat.com Thu Apr 10 11:22:01 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 10 Apr 2014 11:22:01 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> Message-ID: <3B256910-96B3-4F55-8456-D890F4B37B2B@redhat.com> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. this works: https://gist.github.com/lholmquist/10393357 this doesn't: https://gist.github.com/lholmquist/10393450 On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: > > On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: > >> Ok, >> >> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? > > i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. > > > >> >> -Matthias >> >> On Monday, April 7, 2014, Lucas Holmquist wrote: >> so i went back to look at what i had, >> >> >> i don't think we need to get to complicated here, >> >> reading the spec stuff, and this example >> >> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >> >> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >> >> it is also recommended that the channelID is never exposed to the application. >> >> >> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >> >>> i had something, now i forgot what it was, need to go back and check >>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>> >>>> >>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>> still exploring >>>> >>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>> >>>> >>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>> i might have a couple thoughts, but i need to try some things out first >>>>> >>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>> >>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>> Ok, >>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>> >>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>> >>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>> >>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>> So how do we deal with that ? >>>>>> >>>>>> >>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >> >> >> -- >> Sent from Gmail Mobile >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/62e080b2/attachment.html From matzew at apache.org Thu Apr 10 11:26:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Apr 2014 17:26:13 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <3B256910-96B3-4F55-8456-D890F4B37B2B@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B@redhat.com> Message-ID: hrm. what about this something like this? unescape(encodeURIComponent(URL)) On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: > so after testing this thing out with encodeURIComponent, the delete does > work, however, we need to "double up" the encode. > > this works: > > https://gist.github.com/lholmquist/10393357 > > > this doesn't: > > https://gist.github.com/lholmquist/10393450 > > > > On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: > > > On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf > wrote: > > Ok, > > So as token, we use the endpointURL, and on client we perform the encodeURIComponent() > function ? > > > i think so( as suggested 2 months ago :) ) i just need to see how this > will affect how we store stuff in LS. > > > > > -Matthias > > On Monday, April 7, 2014, Lucas Holmquist wrote: > >> so i went back to look at what i had, >> >> >> i don't think we need to get to complicated here, >> >> reading the spec stuff, and this example >> >> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >> >> they show sending the pushEndpoint to the "App server", so i think we >> could just use and keep it simple >> >> it is also recommended that the channelID is never exposed to the >> application. >> >> >> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >> >> i had something, now i forgot what it was, need to go back and check >> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf >> wrote: >> >> >> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >> >> still exploring >> >> >> :-) any recent thoughts on 'encodeURIComponent()' ? >> >> >> >> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >> >> >> >> >> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >> >> i might have a couple thoughts, but i need to try some things out first >> >> >> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() >> ) could be enough ? >> >> >> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >> >> >> >> >> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >> >> Ok, >> I've been doing some tests by using the PushEndpoint as device token. For >> registration it works but I just faced an issue by trying to unregister >> because the URL for the DELETE looks like : >> >> >> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[ >> >> And the REST endpoint get a bit crazy by the extra "/" present in the >> endpoint URL. Therefore, I think we must just use the last URL fragment as >> deviceToken. >> >> >> Ok answering to myself ;) That won't work neither since if we do that UPS >> won't have the compllete push endpoint URL. >> So how do we deal with that ? >> >> >> >> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >> >> >> >> >> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >> >> > > -- > Sent from Gmail Mobile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/30711263/attachment-0001.html From lholmqui at redhat.com Thu Apr 10 11:28:50 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 10 Apr 2014 11:28:50 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B! @redhat.com> Message-ID: <91541FC8-1C38-491B-B732-FBF060FEA425@redhat.com> On Apr 10, 2014, at 11:26 AM, Matthias Wessendorf wrote: > hrm. > > what about this something like this? unescape(encodeURIComponent(URL)) > haven't tried it, but it should matter since this is hidden from the user anyway > > > > > On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: > so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. > > this works: > > https://gist.github.com/lholmquist/10393357 > > > this doesn't: > > https://gist.github.com/lholmquist/10393450 > > > > On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: > >> >> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >> >>> Ok, >>> >>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >> >> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >> >> >> >>> >>> -Matthias >>> >>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>> so i went back to look at what i had, >>> >>> >>> i don't think we need to get to complicated here, >>> >>> reading the spec stuff, and this example >>> >>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>> >>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>> >>> it is also recommended that the channelID is never exposed to the application. >>> >>> >>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>> >>>> i had something, now i forgot what it was, need to go back and check >>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>> >>>>> >>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>> still exploring >>>>> >>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>> >>>>> >>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>> >>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>> >>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>> Ok, >>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>> >>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>> >>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>> >>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>> So how do we deal with that ? >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>> >>> >>> -- >>> Sent from Gmail Mobile >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/015c864c/attachment.html From marti1003 at hotmail.com Thu Apr 10 12:47:34 2014 From: marti1003 at hotmail.com (Willy Martin Aguirre Rodriguez) Date: Thu, 10 Apr 2014 11:47:34 -0500 Subject: [aerogear-dev] A new -user mailing list ? In-Reply-To: References: , <20140410060828.GM44433@rohan.local>, Message-ID: +1 agree with you :) > From: miguel21op at gmail.com > Date: Thu, 10 Apr 2014 07:33:22 +0100 > To: aerogear-dev at lists.jboss.org > Subject: Re: [aerogear-dev] A new -user mailing list ? > > Yes. I agree. For users (like me) many discussions have no interest. > On the other hand, usability, bugs, characteristics and functionalities of the product, etc. deserve a space of its own with the due relevance and well organized. > > Enviado do meu iPad > > No dia 10/04/2014, ?s 07:08, Douglas Campos escreveu: > > > let's do this, +1 > > > > -- > > qmx > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/5f6cdf21/attachment.html From lholmqui at redhat.com Thu Apr 10 12:59:19 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 10 Apr 2014 12:59:19 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <91541FC8-1C38-491B-B732-FBF060FEA425@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B! ! @redhat.com> <91541FC8-1C38-491B-B732-FBF060FEA425@redhat.com> Message-ID: On Apr 10, 2014, at 11:28 AM, Lucas Holmquist wrote: > > On Apr 10, 2014, at 11:26 AM, Matthias Wessendorf wrote: > >> hrm. >> >> what about this something like this? unescape(encodeURIComponent(URL)) >> also, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/unescape shit be deprecated > haven't tried it, but it should matter since this is hidden from the user anyway > > > >> >> >> >> >> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: >> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. >> >> this works: >> >> https://gist.github.com/lholmquist/10393357 >> >> >> this doesn't: >> >> https://gist.github.com/lholmquist/10393450 >> >> >> >> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >> >>> >>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >>> >>>> Ok, >>>> >>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >>> >>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >>> >>> >>> >>>> >>>> -Matthias >>>> >>>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>>> so i went back to look at what i had, >>>> >>>> >>>> i don't think we need to get to complicated here, >>>> >>>> reading the spec stuff, and this example >>>> >>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>> >>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>>> >>>> it is also recommended that the channelID is never exposed to the application. >>>> >>>> >>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>>> >>>>> i had something, now i forgot what it was, need to go back and check >>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>>> >>>>>> >>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>>> still exploring >>>>>> >>>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>>> >>>>>> >>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>>> >>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>>> >>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>>> Ok, >>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>>> >>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>>> >>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>>> >>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>>> So how do we deal with that ? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>> >>>> >>>> -- >>>> Sent from Gmail Mobile >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/5ed170e7/attachment-0001.html From matzew at apache.org Thu Apr 10 13:20:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Apr 2014 19:20:17 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <91541FC8-1C38-491B-B732-FBF060FEA425@redhat.com> Message-ID: On Thu, Apr 10, 2014 at 6:59 PM, Lucas Holmquist wrote: > > On Apr 10, 2014, at 11:28 AM, Lucas Holmquist wrote: > > > On Apr 10, 2014, at 11:26 AM, Matthias Wessendorf > wrote: > > hrm. > > what about this something like this? unescape(encodeURIComponent(URL)) > > > also, > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/unescape > > shit be deprecated > :-) > > haven't tried it, but it should matter since this is hidden from the > user anyway > > > > > > > > On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: > >> so after testing this thing out with encodeURIComponent, the delete does >> work, however, we need to "double up" the encode. >> >> this works: >> >> https://gist.github.com/lholmquist/10393357 >> >> >> this doesn't: >> >> https://gist.github.com/lholmquist/10393450 >> >> >> >> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >> >> >> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf >> wrote: >> >> Ok, >> >> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() >> function ? >> >> >> i think so( as suggested 2 months ago :) ) i just need to see how this >> will affect how we store stuff in LS. >> >> >> >> >> -Matthias >> >> On Monday, April 7, 2014, Lucas Holmquist wrote: >> >>> so i went back to look at what i had, >>> >>> >>> i don't think we need to get to complicated here, >>> >>> reading the spec stuff, and this example >>> >>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>> >>> they show sending the pushEndpoint to the "App server", so i think we >>> could just use and keep it simple >>> >>> it is also recommended that the channelID is never exposed to the >>> application. >>> >>> >>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>> >>> i had something, now i forgot what it was, need to go back and check >>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>> >>> still exploring >>> >>> >>> :-) any recent thoughts on 'encodeURIComponent()' ? >>> >>> >>> >>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>> >>> i might have a couple thoughts, but i need to try some things out first >>> >>> >>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() >>> ) could be enough ? >>> >>> >>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>> >>> Ok, >>> I've been doing some tests by using the PushEndpoint as device token. >>> For registration it works but I just faced an issue by trying to unregister >>> because the URL for the DELETE looks like : >>> >>> >>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[ >>> >>> And the REST endpoint get a bit crazy by the extra "/" present in the >>> endpoint URL. Therefore, I think we must just use the last URL fragment as >>> deviceToken. >>> >>> >>> Ok answering to myself ;) That won't work neither since if we do that >>> UPS won't have the compllete push endpoint URL. >>> So how do we deal with that ? >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>> >>> >> >> -- >> Sent from Gmail Mobile >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/a93fb1f1/attachment.html From matzew at apache.org Thu Apr 10 14:09:20 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Apr 2014 20:09:20 +0200 Subject: [aerogear-dev] UnifiedPush WAR file -> Maven Central Message-ID: Hello, we got asked by QE before, and now by LiveOak, if possible to put our WAR file to Maven Central. It makes things easier for others that are _integrating_ with out bits. any thoughts ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/4f5e24ac/attachment.html From daniel at passos.me Thu Apr 10 15:08:34 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 10 Apr 2014 16:08:34 -0300 Subject: [aerogear-dev] HelloWorld images In-Reply-To: References: <3643125D-5E8E-457D-B4F5-45276ED4A702@gmail.com> Message-ID: https://vimeo.com/91332890 On Wed, Apr 9, 2014 at 1:15 PM, Daniel Passos wrote: > Like this? http://take.ms/hFM0Y > > > On Wed, Apr 9, 2014 at 12:30 PM, Sebastien Blanc wrote: > >> Erik has started on the Splash Screens : >> https://github.com/aerogear/aerogear-push-helloworld/pull/3 >> It's nice and lean but I wonder if we want more info on the splash >> screen, like the app name ? >> >> >> >> On Wed, Apr 9, 2014 at 3:06 PM, Daniel Passos wrote: >> >>> Well, android needs a lot of sizes :) from mdpi to xxxhdpi[1] but, we >>> always use Android asset Studio[2] :D >>> >>> Btw, we already have that in other example apps. >>> >>> [1] http://developer.android.com/design/style/iconography.html >>> [2] >>> http://android-ui-utils.googlecode.com/hg/asset-studio/dist/icons-launcher.html >>> >>> -- Passos >>> >>> >>> On Wed, Apr 9, 2014 at 4:57 AM, Corinne Krych wrote: >>> >>>> Hello All, >>>> >>>> For our HelloWorld demo apps, we agreed on an unified Ui looks, >>>> although really simple. It would be nice to have unified images. >>>> As discussed with @edewit sticking to png is easier for native app. We >>>> need icon and launch image. >>>> we have an icon image but what could be used for launch screen? >>>> >>>> For iOS7 here is the size needed: >>>> icon 58x58 >>>> icon 80x80 >>>> icon 120x120 >>>> launch image 640x960 >>>> launch image 640x1136 >>>> >>>> What about Android? >>>> So who feel like doing the images for all clients? (looking for an >>>> artist) >>>> >>>> ++ >>>> Corinne >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140410/524ece47/attachment-0001.html From daniel.bevenius at gmail.com Thu Apr 10 23:39:26 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 11 Apr 2014 05:39:26 +0200 Subject: [aerogear-dev] UnifiedPush WAR file -> Maven Central In-Reply-To: References: Message-ID: +1 Sounds reasonable to me. On 10 April 2014 20:09, Matthias Wessendorf wrote: > Hello, > > we got asked by QE before, and now by LiveOak, if possible to put our WAR > file to Maven Central. > > It makes things easier for others that are _integrating_ with out bits. > > > > any thoughts ? > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140411/bf612a4a/attachment.html From kpiwko at redhat.com Fri Apr 11 03:05:27 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Fri, 11 Apr 2014 09:05:27 +0200 Subject: [aerogear-dev] UnifiedPush WAR file -> Maven Central In-Reply-To: References: Message-ID: <20140411090527.289235b5@kapy-ntb-x220> +1, this still holds true. Temporary workaround we are using is to use Bintray/matzew's repo as a Maven Repository [1]. The other benefit of using Maven Central is staging feature through JBoss Nexus. So it would be easier to test staged release. Karel [1] https://github.com/aerogear/aerogear-unifiedpush-server-integration-tests/blob/junit-rule/src/test/java/org/jboss/aerogear/unifiedpush/test/Deployments.java#L167 On Thu, 10 Apr 2014 20:09:20 +0200 Matthias Wessendorf wrote: > Hello, > > we got asked by QE before, and now by LiveOak, if possible to put our WAR > file to Maven Central. > > It makes things easier for others that are _integrating_ with out bits. > > > > any thoughts ? > > -Matthias > From edewit at redhat.com Fri Apr 11 04:28:27 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 11 Apr 2014 10:28:27 +0200 Subject: [aerogear-dev] Aero push iOS 64bit? In-Reply-To: <1396384671802-7258.post@n5.nabble.com> References: <1396384671802-7258.post@n5.nabble.com> Message-ID: <8C617DAA-3CD8-4C95-B849-2E723FE340E2@redhat.com> Hi, Just to let you know things have been resolved, cordova released their new version of cordova that fixes the issues they had with Xcode 5.1 and we have updated our library to include 64bit (rebuild it with Xcode 5.1) You can give it a go by installing the plugin from the git repository: cordova plugin add https://github.com/aerogear/aerogear-pushplugin-cordova.git Cheers, Erik Jan On 1 Apr,2014, at 22:37 , johnbran wrote: > Hello, > I am running xcode 5.1 and cordova 3.4. When I test my app on an iPhone 4 > it works without issue. When I run it on an 5s (64bits) or in the 64bit > iphone simulator I get the following errors... > > ld: warning: ignoring file > /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a, > missing required architecture x86_64 in file > /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a > (3 slices) > Undefined symbols for architecture x86_64: > "_OBJC_CLASS_$_AGDeviceRegistration", referenced from: > objc-class-ref in PushPlugin.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > If I choose to compile only to 32bits using $(ARCHS_STANDARD_32_BIT) in the > Architecture build settings, Cordova throws errors. > > Does Aero push for iOS support 64bits? I got it working nicely in Android > and would like to use the same system for iOS. > > Thanks > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aero-push-iOS-64bit-tp7258.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140411/7c40b141/attachment.html From bsutter at redhat.com Fri Apr 11 07:52:46 2014 From: bsutter at redhat.com (Burr Sutter) Date: Fri, 11 Apr 2014 07:52:46 -0400 Subject: [aerogear-dev] Aero push iOS 64bit? In-Reply-To: <8C617DAA-3CD8-4C95-B849-2E723FE340E2@redhat.com> References: <1396384671802-7258.post@n5.nabble.com> <8C617DAA-3CD8-4C95-B849-2E723FE340E2@redhat.com> Message-ID: <34153744-5914-4F00-A119-36B70B8F58C9@redhat.com> What is the version - 3.4.1? On Apr 11, 2014, at 4:28 AM, Erik Jan de Wit wrote: > Hi, > > Just to let you know things have been resolved, cordova released their new version of cordova that fixes the issues they had with Xcode 5.1 and we have updated our library to include 64bit (rebuild it with Xcode 5.1) > > You can give it a go by installing the plugin from the git repository: > > cordova plugin add https://github.com/aerogear/aerogear-pushplugin-cordova.git > > Cheers, > Erik Jan > > On 1 Apr,2014, at 22:37 , johnbran wrote: > >> Hello, >> I am running xcode 5.1 and cordova 3.4. When I test my app on an iPhone 4 >> it works without issue. When I run it on an 5s (64bits) or in the 64bit >> iphone simulator I get the following errors... >> >> ld: warning: ignoring file >> /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a, >> missing required architecture x86_64 in file >> /Users/johnbran/cordova/z1/platforms/ios/z1/Plugins/org.jboss.aerogear.cordova.push/libpush-sdk-0.8.1.a >> (3 slices) >> Undefined symbols for architecture x86_64: >> "_OBJC_CLASS_$_AGDeviceRegistration", referenced from: >> objc-class-ref in PushPlugin.o >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> If I choose to compile only to 32bits using $(ARCHS_STANDARD_32_BIT) in the >> Architecture build settings, Cordova throws errors. >> >> Does Aero push for iOS support 64bits? I got it working nicely in Android >> and would like to use the same system for iOS. >> >> Thanks >> >> >> >> -- >> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aero-push-iOS-64bit-tp7258.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140411/00bbccc7/attachment.html From edewit at redhat.com Fri Apr 11 07:57:22 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 11 Apr 2014 13:57:22 +0200 Subject: [aerogear-dev] Aero push iOS 64bit? In-Reply-To: <34153744-5914-4F00-A119-36B70B8F58C9@redhat.com> References: <1396384671802-7258.post@n5.nabble.com> <8C617DAA-3CD8-4C95-B849-2E723FE340E2@redhat.com> <34153744-5914-4F00-A119-36B70B8F58C9@redhat.com> Message-ID: On 11 Apr,2014, at 13:52 , Burr Sutter wrote: > What is the version - 3.4.1? Cordova From hbons at redhat.com Fri Apr 11 12:06:44 2014 From: hbons at redhat.com (Hylke Bons) Date: Fri, 11 Apr 2014 17:06:44 +0100 Subject: [aerogear-dev] UPS UX updates In-Reply-To: References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> <534591A1.2040500@redhat.com> <534676F3.60102@redhat.com> <53468E5A.4040303@redhat.com> Message-ID: <53481314.5020204@redhat.com> Hey, Here are the updated wireframes with the changes we made in the visual design: https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/applications-spec.png I've separated out all the user management, auth, and proxy stuff to keep things manageable. These are now in separate files in the repo, but I don't think we'll need to look at the other ones for this release. There shouldn't be any surprises. One thing that did change though is the "Add Variant" dialog page where I added bigger icons and placed "SimplePush" under "Other" instead of "Web", as "Web" was a bit confusing as a platform. Let me know what you think about that dialog as I'm not quite sure about it myself. Hopefully this will help Sebastien to create all the pages and data hooks that we need. Thanks, Hylke On 10/04/2014 13:38, Matthias Wessendorf wrote: > > > > On Thu, Apr 10, 2014 at 2:28 PM, Hylke Bons > wrote: > > On 10/04/2014 12:35, Matthias Wessendorf wrote: >> >> >> >> On Thu, Apr 10, 2014 at 12:48 PM, Hylke Bons > > wrote: >> >> Here's the page for code snippets: >> https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/9.png >> >> I've also updated the Application Detail page to change the >> links that say "What's this for?" to "Example >> implementation": >> https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/6.png >> >> >> A click on "Example implementation" brings you to the screen of >> 9.png, right ? >> >> > Yes. > > > Awesome! > > Thanks for the update! > > -Matthias > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140411/04bc77ce/attachment-0001.html From scm.blanc at gmail.com Fri Apr 11 12:26:10 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 11 Apr 2014 18:26:10 +0200 Subject: [aerogear-dev] UPS UX updates In-Reply-To: <53481314.5020204@redhat.com> References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> <534591A1.2040500@redhat.com> <534676F3.60102@redhat.com> <53468E5A.4040303@redhat.com> <53481314.5020204@redhat.com> Message-ID: Nice work Hylke ! I really like it. Seb On Fri, Apr 11, 2014 at 6:06 PM, Hylke Bons wrote: > Hey, > > Here are the updated wireframes with the changes we made in the visual > design: > > https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/applications-spec.png > > I've separated out all the user management, auth, and proxy stuff to keep > things manageable. These are now in separate files in the repo, but I don't > think we'll need to look at the other ones for this release. > > There shouldn't be any surprises. One thing that did change though is the > "Add Variant" dialog page where I added bigger icons and placed > "SimplePush" under "Other" instead of "Web", as "Web" was a bit confusing > as a platform. Let me know what you think about that dialog as I'm not > quite sure about it myself. > > Hopefully this will help Sebastien to create all the pages and data hooks > that we need. > > Thanks, > > Hylke > > > > > > On 10/04/2014 13:38, Matthias Wessendorf wrote: > > > > > On Thu, Apr 10, 2014 at 2:28 PM, Hylke Bons wrote: > >> On 10/04/2014 12:35, Matthias Wessendorf wrote: >> >> >> >> >> On Thu, Apr 10, 2014 at 12:48 PM, Hylke Bons wrote: >> >>> Here's the page for code snippets: >>> >>> https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/9.png >>> >>> I've also updated the Application Detail page to change the links that >>> say "What's this for?" to "Example implementation": >>> https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/6.png >>> >>> >> A click on "Example implementation" brings you to the screen of 9.png, >> right ? >> >> >> Yes. >> > > Awesome! > > Thanks for the update! > > -Matthias > > > >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140411/8130a4b2/attachment.html From matzew at apache.org Fri Apr 11 12:30:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 11 Apr 2014 18:30:24 +0200 Subject: [aerogear-dev] UPS UX updates In-Reply-To: <53481314.5020204@redhat.com> References: <5331B750.1060609@redhat.com> <5331CDA5.1050405@redhat.com> <53342282.5000801@redhat.com> <53344919.3090506@redhat.com> <534591A1.2040500@redhat.com> <534676F3.60102@redhat.com> <53468E5A.4040303@redhat.com> <53481314.5020204@redhat.com> Message-ID: Howdy On Fri, Apr 11, 2014 at 6:06 PM, Hylke Bons wrote: > Hey, > > Here are the updated wireframes with the changes we made in the visual > design: > > https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/applications-spec.png > > I've separated out all the user management, auth, > user managament, auth -> Perfect! It is not needed at all. (keycloak is the solution here) > and proxy stuff to keep things manageable. > proxy, as mentioned several weeks ago: moved out > These are now in separate files in the repo, but I don't think we'll need > to look at the other ones for this release. > > There shouldn't be any surprises. One thing that did change though is the > "Add Variant" dialog page where I added bigger icons and placed > "SimplePush" under "Other" instead of "Web", as "Web" was a bit confusing > as a platform. Let me know what you think about that dialog as I'm not > quite sure about it myself. > I like it > > Hopefully this will help Sebastien to create all the pages and data hooks > that we need. > > Thanks, > Really like em ! Have a good weekend! -Matthias > > Hylke > > > > > > On 10/04/2014 13:38, Matthias Wessendorf wrote: > > > > > On Thu, Apr 10, 2014 at 2:28 PM, Hylke Bons wrote: > >> On 10/04/2014 12:35, Matthias Wessendorf wrote: >> >> >> >> >> On Thu, Apr 10, 2014 at 12:48 PM, Hylke Bons wrote: >> >>> Here's the page for code snippets: >>> >>> https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/9.png >>> >>> I've also updated the Application Detail page to change the links that >>> say "What's this for?" to "Example implementation": >>> https://github.com/hbons/aerogear-design/blob/master/Unified%20Push%20Server/Export/6.png >>> >>> >> A click on "Example implementation" brings you to the screen of 9.png, >> right ? >> >> >> Yes. >> > > Awesome! > > Thanks for the update! > > -Matthias > > > >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140411/61226717/attachment.html From daniel.bevenius at gmail.com Mon Apr 14 02:54:00 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 14 Apr 2014 08:54:00 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140414 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140414/1c57131d/attachment.html From cvasilak at gmail.com Mon Apr 14 10:06:50 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 14 Apr 2014 17:06:50 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: <5CD721A8-C059-4843-8E97-CEDE4CEA5287@gmail.com> fyi meeting minutes: Meeting ended Mon Apr 14 13:51:14 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-14-13.46.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-14-13.46.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-14-13.46.log.html On Apr 14, 2014, at 9:54 AM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140414 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140414/929703db/attachment-0001.html From bruno at abstractj.com Wed Apr 16 01:06:35 2014 From: bruno at abstractj.com (Bruno Oliveira) Date: Wed, 16 Apr 2014 02:06:35 -0300 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal Message-ID: <534E0FDB.70104@abstractj.com> Good morning, while I was working on "that" passphrase encryption thing, I found some improvements for UPS. But would like to discuss before. 1. Currently UPS stores master secret and secrets (from Variants) into the database. IMO this information should never be persisted into the database and such kind of information only belongs to the owner of that application. How? https://github.com/abstractj/aerogear-unifiedpush-server/tree/master-secret 2. Master secret and Secret make use of UUID from Java, not truly a PRNG once some attributes are predictable, you are not collision free. "WTF are you saying Bruno!?". From JDK 7: |public static UUID randomUUID() { SecureRandom ng = numberGenerator; if (ng == null) { numberGenerator = ng = new SecureRandom(); } byte[] randomBytes = new byte[16]; ng.nextBytes(randomBytes); randomBytes[6] &= 0x0f; /* clear version */ randomBytes[6] |= 0x40; /* set to version 4 */ randomBytes[8] &= 0x3f; /* clear variant */ randomBytes[8] |= 0x80; /* set to IETF variant */ return new UUID(randomBytes); }| Solution: https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293#diff-dc07653bd3c83d4e82c45b70d8ad34dfR47 3. I noticed the fact that PushApplication and Variant have some duplicated attributes with different names. public abstract class Variant extends BaseModel { private String variantID = UUID.randomUUID().toString(); private String secret = UUID.randomUUID().toString(); .... } public class PushApplication extends BaseModel { private String pushApplicationID = UUID.randomUUID().toString(); private String masterSecret = UUID.randomUUID().toString(); ... } I can see two alternatives to avoid it: - Move these attributes to an |Embeddable| class, something like: |@Embeddable *public class ApplicationKey*{ | private String id = UUID.randomUUID().toString(); private String secret = UUID.randomUUID().toString(); | }| public abstract class Variant extends BaseModel { | @Embedded @AttributeOverrides( { @AttributeOverride(name="variantID")), @AttributeOverride(name="secret")) }) *private ApplicationKey*key;| .... } public class PushApplication extends BaseModel { |@Embedded @AttributeOverrides( { @AttributeOverride(name="pushApplicationID")), @AttributeOverride(name="masterSecret")) }) *private ApplicationKey*key;| ... } - Second alternative (more simple) pull up the attributes to BaseModel public abstract class BaseModel implements Serializable { private String id = UUID.randomUUID().toString(); private String secret = UUID.randomUUID().toString(); ... } Why this is important? 1. Avoid sensitive data to be stored into the database, make use of KDF functions to store secrets, master secrets.... 2. Avoid code duplication. With the inclusion of encryption for passphrases and other kind of sensitive data, I pretty much have to duplicate code like this (https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293) between both classes. Wdyt? -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/1b3c353f/attachment.bin From scm.blanc at gmail.com Wed Apr 16 03:10:37 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 16 Apr 2014 09:10:37 +0200 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <534E0FDB.70104@abstractj.com> References: <534E0FDB.70104@abstractj.com> Message-ID: Hi Bruno ! Cool stuff some comments inline On Wed, Apr 16, 2014 at 7:06 AM, Bruno Oliveira wrote: > Good morning, while I was working on "that" passphrase encryption thing, > I found some improvements for UPS. But would like to discuss before. > > 1. Currently UPS stores master secret and secrets (from Variants) into > the database. IMO this information should never be persisted into the > database and such kind of information only belongs to the owner of that > application. How? > https://github.com/abstractj/aerogear-unifiedpush-server/tree/master-secret I tried out your branch and created some applications. This is what I see now when browsing to my app details, is this the valid ID/Secret pair that the application owner / administrator can use to send psuh notifications ? [image: secret] > > > 2. Master secret and Secret make use of UUID from Java, not truly a PRNG > once some attributes are predictable, you are not collision free. "WTF > are you saying Bruno!?". From JDK 7: > > |public static UUID randomUUID() { > SecureRandom ng = numberGenerator; > if (ng == null) { > numberGenerator = ng = new SecureRandom(); > } > > byte[] randomBytes = new byte[16]; > ng.nextBytes(randomBytes); > randomBytes[6] &= 0x0f; /* clear version */ > randomBytes[6] |= 0x40; /* set to version 4 */ > randomBytes[8] &= 0x3f; /* clear variant */ > randomBytes[8] |= 0x80; /* set to IETF variant */ > return new UUID(randomBytes); > }| > > Solution: > > https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293#diff-dc07653bd3c83d4e82c45b70d8ad34dfR47 Nice improvement > > > 3. I noticed the fact that PushApplication and Variant have some > duplicated attributes with different names. > > public abstract class Variant extends BaseModel { > > private String variantID = UUID.randomUUID().toString(); > > private String secret = UUID.randomUUID().toString(); > > .... > } > > public class PushApplication extends BaseModel { > > private String pushApplicationID = UUID.randomUUID().toString(); > > private String masterSecret = UUID.randomUUID().toString(); > ... > } > > I can see two alternatives to avoid it: > > - Move these attributes to an |Embeddable| class, something like: > > |@Embeddable > *public class ApplicationKey*{ > > | private String id = UUID.randomUUID().toString(); > > private String secret = UUID.randomUUID().toString(); > | > }| > > public abstract class Variant extends BaseModel { > > | @Embedded > @AttributeOverrides( { > @AttributeOverride(name="variantID")), > @AttributeOverride(name="secret")) > }) > *private ApplicationKey*key;| > > .... > } > > public class PushApplication extends BaseModel { > > |@Embedded > @AttributeOverrides( { > @AttributeOverride(name="pushApplicationID")), > @AttributeOverride(name="masterSecret")) > }) > *private ApplicationKey*key;| > ... > } > > - Second alternative (more simple) pull up the attributes to BaseModel > > public abstract class BaseModel implements Serializable { > > private String id = UUID.randomUUID().toString(); > > private String secret = UUID.randomUUID().toString(); > ... > } > Make sense > > Why this is important? > > 1. Avoid sensitive data to be stored into the database, make use of KDF > functions to store secrets, master secrets.... > 2. Avoid code duplication. With the inclusion of encryption for > passphrases and other kind of sensitive data, I pretty much have to > duplicate code like this > ( > https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293 > ) > between both classes. > > Wdyt? > > > -- > abstractj > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/ece5f37b/attachment.html From kpiwko at redhat.com Wed Apr 16 07:14:44 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 16 Apr 2014 13:14:44 +0200 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <534E0FDB.70104@abstractj.com> References: <534E0FDB.70104@abstractj.com> Message-ID: <20140416131444.030fa5c9@kapy-ntb-x220> Good stuff. Comments inline: On Wed, 16 Apr 2014 02:06:35 -0300 Bruno Oliveira wrote: > Good morning, while I was working on "that" passphrase encryption thing, > I found some improvements for UPS. But would like to discuss before. > > 1. Currently UPS stores master secret and secrets (from Variants) into > the database. IMO this information should never be persisted into the > database and such kind of information only belongs to the owner of that > application. How? > https://github.com/abstractj/aerogear-unifiedpush-server/tree/master-secret > Sorry my ignorance, does it mean that if I restart application server or redeploy UPS, master secret will be changed? For master secret, that's not that big concern, I believe. People just need to grab master secret from UPS before adding variants from CLI. But if variant secrets are recomputed as well, all existing application installations will cease to work! > > 2. Master secret and Secret make use of UUID from Java, not truly a PRNG > once some attributes are predictable, you are not collision free. "WTF > are you saying Bruno!?". From JDK 7: > > |public static UUID randomUUID() { > SecureRandom ng = numberGenerator; > if (ng == null) { > numberGenerator = ng = new SecureRandom(); > } > > byte[] randomBytes = new byte[16]; > ng.nextBytes(randomBytes); > randomBytes[6] &= 0x0f; /* clear version */ > randomBytes[6] |= 0x40; /* set to version 4 */ > randomBytes[8] &= 0x3f; /* clear variant */ > randomBytes[8] |= 0x80; /* set to IETF variant */ > return new UUID(randomBytes); > }| > > Solution: > https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293#diff-dc07653bd3c83d4e82c45b70d8ad34dfR47 > +1 > 3. I noticed the fact that PushApplication and Variant have some > duplicated attributes with different names. > > public abstract class Variant extends BaseModel { > > private String variantID = UUID.randomUUID().toString(); > > private String secret = UUID.randomUUID().toString(); > > .... > } > > public class PushApplication extends BaseModel { > > private String pushApplicationID = UUID.randomUUID().toString(); > > private String masterSecret = UUID.randomUUID().toString(); > ... > } > > I can see two alternatives to avoid it: > > - Move these attributes to an |Embeddable| class, something like: > > |@Embeddable > *public class ApplicationKey*{ > > | private String id = UUID.randomUUID().toString(); > > private String secret = UUID.randomUUID().toString(); > | > }| > > public abstract class Variant extends BaseModel { > > | @Embedded > @AttributeOverrides( { > @AttributeOverride(name="variantID")), > @AttributeOverride(name="secret")) > }) > *private ApplicationKey*key;| > > .... > } > > public class PushApplication extends BaseModel { > > |@Embedded > @AttributeOverrides( { > @AttributeOverride(name="pushApplicationID")), > @AttributeOverride(name="masterSecret")) > }) > *private ApplicationKey*key;| > ... > } > > - Second alternative (more simple) pull up the attributes to BaseModel > > public abstract class BaseModel implements Serializable { > > private String id = UUID.randomUUID().toString(); > > private String secret = UUID.randomUUID().toString(); > ... > } +1 to this alternative. @Embedded and (@Embeddable) is a JPA specific stuff - might be more complicated to migrate to NoSQL DB or to other JPA provides (EclipseLink) in future. > > Why this is important? > > 1. Avoid sensitive data to be stored into the database, make use of KDF > functions to store secrets, master secrets.... > 2. Avoid code duplication. With the inclusion of encryption for > passphrases and other kind of sensitive data, I pretty much have to > duplicate code like this > (https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293) > between both classes. > > Wdyt? > > From florian.schrofner at outlook.com Wed Apr 16 08:53:28 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Wed, 16 Apr 2014 05:53:28 -0700 (PDT) Subject: [aerogear-dev] Allow Push Without Master-Secret? Message-ID: <1397652808858-7474.post@n5.nabble.com> Hey there guys! We are currently working on our semester project which allows you to sync notifications across different devices. The notifications themselves are stored on a separate webserver, but we are using the aerogear unified pushserver to start a sync. All the devices which should receive the push (and start the sync) are using the same alias, the push will be triggered by one of these devices On Android it should work fine, since we are able to use the Java Client and the secret without a problem (at least i think the secret would not be visible to anyone on Android). But we are also planning to implement a Chrome Addon and we don't really like the idea to make the master-secret visible to everyone. We know that the unified push server is not intended to be used as client-to-client push server atm, but since the pushes don't contain any important data it would be a sufficient solution to just disable the need for a master-secret if an alias is given (this would at least prevent broadcasts from being sent by third persons). So we wanted to ask you guys which lines of code we should modify inorder to allow pushes without master-secret, if an alias is given? It should only be an additional "if", I guess.. or does it get more complicated? We are currently hosting our unified pushserver on OpenShift (would be nice if you could also roughly tell us how to push the changes onto the server.. do we need to recompile everything?) Cheers, Florian -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Allow-Push-Without-Master-Secret-tp7474.html Sent from the aerogear-dev mailing list archive at Nabble.com. From bruno at abstractj.org Wed Apr 16 11:27:15 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 Apr 2014 12:27:15 -0300 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: References: <534E0FDB.70104@abstractj.com> Message-ID: <534EA153.7050509@abstractj.org> Hi Sebi, I didn't get any image here. Sebastien Blanc wrote: > I tried out your branch and created some applications. > This is what I see now when browsing to my app details, is this the valid > ID/Secret pair that the application owner / administrator can use to send > psuh notifications ? > > [image: secret] -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/a180f4cb/attachment-0001.bin From scm.blanc at gmail.com Wed Apr 16 11:29:29 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 16 Apr 2014 17:29:29 +0200 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <534EA153.7050509@abstractj.org> References: <534E0FDB.70104@abstractj.com> <534EA153.7050509@abstractj.org> Message-ID: Here you go ! http://s9.postimg.org/516up7p0v/secret.png On Wed, Apr 16, 2014 at 5:27 PM, Bruno Oliveira wrote: > Hi Sebi, I didn't get any image here. > > Sebastien Blanc wrote: > > I tried out your branch and created some applications. > > This is what I see now when browsing to my app details, is this the valid > > ID/Secret pair that the application owner / administrator can use to send > > psuh notifications ? > > > > [image: secret] > > -- > abstractj > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/e7d8fb6c/attachment.html From bruno at abstractj.org Wed Apr 16 11:39:13 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 Apr 2014 12:39:13 -0300 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <20140416131444.030fa5c9@kapy-ntb-x220> References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> Message-ID: <534EA421.4010508@abstractj.org> Chillax and feel free to ask. Master secret must be kept with our user/developer/client, technically it will only generated a new secret if we got a new PushApplication. If the server is restarted the *salt* and *secret key* will be still there into the database. So basically on the next request we execute the following function: keyForComparison = PBKDF2(masterSecret, salt) Then we check against the database if the key matches with the stored into the database. Does it make sense to you? Karel Piwko wrote: > Sorry my ignorance, does it mean that if I restart application server or > redeploy UPS, master secret will be changed? > > For master secret, that's not that big concern, I believe. People just need to > grab master secret from UPS before adding variants from CLI. > > But if variant secrets are recomputed as well, all existing application > installations will cease to work! -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/9e07ab8b/attachment.bin From bruno at abstractj.org Wed Apr 16 11:40:11 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 Apr 2014 12:40:11 -0300 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: References: <534E0FDB.70104@abstractj.com> <534EA153.7050509@abstractj.org> Message-ID: <534EA45B.4020802@abstractj.org> That's correct Sebi, I changed it to Base64 but if you guys don't feel comfortable, we can change. Sebastien Blanc wrote: > Here you go ! > http://s9.postimg.org/516up7p0v/secret.png -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/6a92ae24/attachment.bin From kpiwko at redhat.com Wed Apr 16 12:02:12 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 16 Apr 2014 18:02:12 +0200 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <534EA421.4010508@abstractj.org> References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> Message-ID: <20140416180212.48d2a5ed@kapy-ntb-x220> Still not there. If we store *secret key* and *salt* in DB, whoever gets access to DB can compute derived key via PDKDF2, right? Is the security increased because hackers need to acquire two values instead of one? On Wed, 16 Apr 2014 12:39:13 -0300 Bruno Oliveira wrote: > Chillax and feel free to ask. Master secret must be kept with our > user/developer/client, technically it will only generated a new secret > if we got a new PushApplication. > > If the server is restarted the *salt* and *secret key* will be still > there into the database. So basically on the next request we execute the > following function: > > keyForComparison = PBKDF2(masterSecret, salt) > > Then we check against the database if the key matches with the stored > into the database. Does it make sense to you? > > Karel Piwko wrote: > > Sorry my ignorance, does it mean that if I restart application server or > > redeploy UPS, master secret will be changed? > > > > For master secret, that's not that big concern, I believe. People just need > > to grab master secret from UPS before adding variants from CLI. > > > > But if variant secrets are recomputed as well, all existing application > > installations will cease to work! > From bruno at abstractj.org Wed Apr 16 12:57:13 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 Apr 2014 13:57:13 -0300 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <20140416180212.48d2a5ed@kapy-ntb-x220> References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> Message-ID: <534EB669.5030906@abstractj.org> Hi Karel, this not bullet proof but let me try to explain. Currently you can only send push messages if you have the master secret, currently I can see two points of vulnerability: 1) client side in possession of master secret, 2) database storing master secret. We can't do so much about the former, but we can try to fix the latter. What we are trying to avoid here is: if someone have access to the database, this person should not be able to send push messages ? because master secret is not there. How? Look at this snippet please: https://github.com/abstractj/aerogear-unifiedpush-server/commit/a2cb2c6f135aab6d85e1e60e6271ceae445ece1e#diff-9ce4033a33f0606bf0c35537a1fd95bdL84 Previously we had a comparison against the database: if (pushApplication != null && pushApplication.getMasterSecret().equals(secret)) The proposal doesn't store the master secret and makes use of a derivation function which means: given a salt and a password (master secret), I was supposed to be able to compute the key for further comparisons ? to check if they match. Let's see how it works: 1. The server generates a salt and a master secret (111111) 2. The salt is stored into the database. Master secret, not. 3. Given the master secret we compute the key (https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293#diff-dc07653bd3c83d4e82c45b70d8ad34dfR177) 4. Store it for further comparisons 5. The following key is generated: FPj+xcfeoR5vJdi6SsqxiT0WK8cv4PesQ0jpDMYdTYk= What would happen if someone get access to DB? 1. Evil gets access to the database 2. Manage to retrieve the key: FPj+xcfeoR5vJdi6SsqxiT0WK8cv4PesQ0jpDMYdTYk= 3. Now Evil try to send push messages 4. The following code will attempt to validate: FPj+xcfeoR5vJdi6SsqxiT0WK8cv4PesQ0jpDMYdTYk= but the password was 111111 You can see the simulation with the following code: @Test public void testEvilScenario() throws Exception { Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); String masterSecret = "111111"; byte[] salt = RandomUtils.randomBytes(); //Master secret is never stored into the database byte[] applicationSecret = pbkdf2.encrypt(masterSecret); // Now Evil stole the applicationSecret. // Providing String pushApplicationID = credentials[0]; String secret = credentials[1]; // First the is stored in an array of bytes and validate method do not support byte array as parameter // No problem, we can attempt to convert to BASE64 String evilMasterSecret = Base64.BASE64.encode(applicationSecret); //Now lets try to compute the key assertTrue("Key is not valid", pbkdf2.validate(evilMasterSecret, applicationSecret, salt)); } Let me know if you have more questions. Karel Piwko wrote: > Still not there. > > If we store *secret key* and *salt* in DB, whoever gets access to DB can > compute derived key via PDKDF2, right? > > Is the security increased because hackers need to acquire two values instead of > one? -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/b9322863/attachment.bin From scm.blanc at gmail.com Wed Apr 16 13:34:54 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 16 Apr 2014 19:34:54 +0200 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <534EB669.5030906@abstractj.org> References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> <534EB669.5030906@abstractj.org> Message-ID: Sorry dummy question but at application creation time (and when resetting the secret), in the response of the POST , the master secret should be returned to the user, right ? Otherwise he will never get it. And second question, I know Security is not often a good mate with UX but , the console will never show the master/variant secret anymore ? On Wed, Apr 16, 2014 at 6:57 PM, Bruno Oliveira wrote: > Hi Karel, this not bullet proof but let me try to explain. Currently you > can only send push messages if you have the master secret, currently I > can see two points of vulnerability: 1) client side in possession of > master secret, 2) database storing master secret. We can't do so much > about the former, but we can try to fix the latter. > > What we are trying to avoid here is: if someone have access to the > database, this person should not be able to send push messages ? because > master secret is not there. How? Look at this snippet please: > > https://github.com/abstractj/aerogear-unifiedpush-server/commit/a2cb2c6f135aab6d85e1e60e6271ceae445ece1e#diff-9ce4033a33f0606bf0c35537a1fd95bdL84 > > Previously we had a comparison against the database: > > if (pushApplication != null && > pushApplication.getMasterSecret().equals(secret)) > > The proposal doesn't store the master secret and makes use of a > derivation function which means: given a salt and a password (master > secret), I was supposed to be able to compute the key for further > comparisons ? to check if they match. > > Let's see how it works: > > 1. The server generates a salt and a master secret (111111) > 2. The salt is stored into the database. Master secret, not. > 3. Given the master secret we compute the key > ( > https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293#diff-dc07653bd3c83d4e82c45b70d8ad34dfR177 > ) > 4. Store it for further comparisons > 5. The following key is generated: > FPj+xcfeoR5vJdi6SsqxiT0WK8cv4PesQ0jpDMYdTYk= > > What would happen if someone get access to DB? > > 1. Evil gets access to the database > 2. Manage to retrieve the key: FPj+xcfeoR5vJdi6SsqxiT0WK8cv4PesQ0jpDMYdTYk= > 3. Now Evil try to send push messages > 4. The following code will attempt to validate: > FPj+xcfeoR5vJdi6SsqxiT0WK8cv4PesQ0jpDMYdTYk= but the password was 111111 > > You can see the simulation with the following code: > > @Test > public void testEvilScenario() throws Exception { > Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2(); > String masterSecret = "111111"; > byte[] salt = RandomUtils.randomBytes(); > //Master secret is never stored into the database > byte[] applicationSecret = pbkdf2.encrypt(masterSecret); > // Now Evil stole the applicationSecret. > // Providing String pushApplicationID = credentials[0]; String secret = > credentials[1]; > // First the is stored in an array of bytes and validate method do not > support byte array as parameter > // No problem, we can attempt to convert to BASE64 > String evilMasterSecret = Base64.BASE64.encode(applicationSecret); > //Now lets try to compute the key > assertTrue("Key is not valid", pbkdf2.validate(evilMasterSecret, > applicationSecret, salt)); > } > > Let me know if you have more questions. > > > > > > > > > Karel Piwko wrote: > > Still not there. > > > > If we store *secret key* and *salt* in DB, whoever gets access to DB can > > compute derived key via PDKDF2, right? > > > > Is the security increased because hackers need to acquire two values > instead of > > one? > > -- > abstractj > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/ebe16618/attachment-0001.html From bruno at abstractj.org Wed Apr 16 13:51:48 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 Apr 2014 14:51:48 -0300 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> <534EB669.5030906@abstractj.org> Message-ID: <534EC334.30202@abstractj.org> Ahoy, answers inline Sebastien Blanc wrote: > Sorry dummy question but at application creation time (and when resetting > the secret), in the response of the POST , the master secret should be > returned to the user, right ? Otherwise he will never get it. You are correct. > And second question, I know Security is not often a good mate with UX but , > the console will never show the master/variant secret anymore ? Also correct. There is nothing set in stone, is just a proposal, because atm anyone with read access do the database could impersonate push applications. Another alternative would be to have a single key to the whole database and only derive the IV, but that would defeat the purpose. In addition I discussed the possibility of make use of vaults from Wildfly, but it's not ready yet (http://lists.jboss.org/pipermail/security-dev/2014-April/001557.html). Is only available for datasources. That's why I would like to hear about the impact of this change and why the master secret/secret must be persisted. -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/66d68b6c/attachment.bin From scm.blanc at gmail.com Wed Apr 16 13:58:06 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 16 Apr 2014 19:58:06 +0200 Subject: [aerogear-dev] Allow Push Without Master-Secret? In-Reply-To: <1397652808858-7474.post@n5.nabble.com> References: <1397652808858-7474.post@n5.nabble.com> Message-ID: Hi, Thanks for your interest and your project sounds interesting. Please reconsider twice before removing this security, you should really not do this But, here is where it happens https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L64 or https://github.com/aerogear/aerogear-unifiedpush-server/blob/0.10.x/server/src/main/java/org/jboss/aerogear/unifiedpush/rest/sender/PushNotificationSenderEndpoint.java#L55-L67for the 0.10.x version. The code is pretty straighforward and remember your alias will be in UnifiedMessage. Are you using the cartdridge for OpenShift ? if yes, you will not able to deploy your "patched" version. You will have to compile it, package a WAR and deploy it on a JBOSS/Wildfly OpenShift cartdridge. On Wed, Apr 16, 2014 at 2:53 PM, Florian Schrofner < florian.schrofner at outlook.com> wrote: > Hey there guys! > > We are currently working on our semester project which allows you to sync > notifications across different devices. The notifications themselves are > stored on a separate webserver, but we are using the aerogear unified > pushserver to start a sync. > All the devices which should receive the push (and start the sync) are > using > the same alias, the push will be triggered by one of these devices > On Android it should work fine, since we are able to use the Java Client > and > the secret without a problem (at least i think the secret would not be > visible to anyone on Android). > But we are also planning to implement a Chrome Addon and we don't really > like the idea to make the master-secret visible to everyone. > > We know that the unified push server is not intended to be used as > client-to-client push server atm, but since the pushes don't contain any > important data it would be a sufficient solution to just disable the need > for a master-secret if an alias is given (this would at least prevent > broadcasts from being sent by third persons). > > So we wanted to ask you guys which lines of code we should modify inorder > to > allow pushes without master-secret, if an alias is given? > It should only be an additional "if", I guess.. or does it get more > complicated? > We are currently hosting our unified pushserver on OpenShift (would be nice > if you could also roughly tell us how to push the changes onto the server.. > do we need to recompile everything?) > > Cheers, > Florian > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Allow-Push-Without-Master-Secret-tp7474.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/0b90d22d/attachment.html From matzew at apache.org Wed Apr 16 14:09:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 16 Apr 2014 11:09:52 -0700 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <534EC334.30202@abstractj.org> References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> <534EB669.5030906@abstractj.org> <534EC334.30202@abstractj.org> Message-ID: Not read the thread - will do next week (traveling atm) But one thing I noticed On Wednesday, April 16, 2014, Bruno Oliveira wrote: > Ahoy, answers inline > > > > And second question, I know Security is not often a good mate with UX > but , > > the console will never show the master/variant secret anymore ? > > Also correct. There is nothing set in stone, is just a proposal, because > atm anyone with read access do the database could impersonate push > applications. I think we would need to continue having IDs/secrets visible on the UI IMO It's very hard to use Push server, w/o that information; again I didnt read the entire thread yet Perhsps, we could hide the key (***************) for read-only users; but I think the overall concern is having them in the DB. My guess is that we need to have them being stored on the DB -Matthias > Another alternative would be to have a single key to the > whole database and only derive the IV, but that would defeat the purpose. > > In addition I discussed the possibility of make use of vaults from > Wildfly, but it's not ready yet > (http://lists.jboss.org/pipermail/security-dev/2014-April/001557.html). > Is only available for datasources. That's why I would like to hear about > the impact of this change and why the master secret/secret must be > persisted. > > -- > abstractj > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/189bc529/attachment.html From bruno at abstractj.org Wed Apr 16 15:29:24 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 Apr 2014 16:29:24 -0300 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> <534EB669.5030906@abstractj.org> <534EC334.30202@abstractj.org> Message-ID: <534EDA14.8000703@abstractj.org> We can discuss on the next week, but even if you define at the application level "read only" users. People still can read from the database. I'm trying to understand why they need to have the master secret displayed into the web page. At first glance, it sounds like the same effect of displaying their passwords at admin. Matthias Wessendorf wrote: > I think we would need to continue having IDs/secrets visible on the UI > > IMO It's very hard to use Push server, w/o that information; again I didnt > read the entire thread yet > > Perhsps, we could hide the key (***************) for read-only users; but I > think the overall concern is having them in the DB. My guess is that we > need to have them being stored on the DB -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140416/5434de4e/attachment.bin From scm.blanc at gmail.com Thu Apr 17 02:50:22 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 17 Apr 2014 08:50:22 +0200 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <534EDA14.8000703@abstractj.org> References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> <534EB669.5030906@abstractj.org> <534EC334.30202@abstractj.org> <534EDA14.8000703@abstractj.org> Message-ID: On Wed, Apr 16, 2014 at 9:29 PM, Bruno Oliveira wrote: > We can discuss on the next week, but even if you define at the > application level "read only" users. People still can read from the > database. > > I'm trying to understand why they need to have the master secret > displayed into the web page. At first glance, it sounds like the same > effect of displaying their passwords at admin. > I compare these secrets with the API keys that Google provides for its services. When you go on their Cloud Console , you can check your API key along with the project number. For sure, it's for convenience but imagine someone (or a team)) having 100 apps, we delegate to them the managing of these keys. But again let's discuss that next week. > Matthias Wessendorf wrote: > > I think we would need to continue having IDs/secrets visible on the UI > > > > IMO It's very hard to use Push server, w/o that information; again I > didnt > > read the entire thread yet > > > > Perhsps, we could hide the key (***************) for read-only users; > but I > > think the overall concern is having them in the DB. My guess is that we > > need to have them being stored on the DB > > -- > abstractj > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140417/39a93380/attachment-0001.html From scm.blanc at gmail.com Thu Apr 17 05:27:07 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 17 Apr 2014 11:27:07 +0200 Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients Message-ID: Hi all, As we are almost done with the HelloWorlds, I think we can we start on the Quickstart clients. As a reminder, the Quickstart will consist in a simple Contact CRUD application with the possibility to send a Push Notification to one of the listed contacts. Please refer to this JIRA to have more information. The clients will have to communicate against secured REST endpoints. Joshua and Pedro have started to work on that but nothing official is released yet. I've tried out their branch and IMHO it's good enough to start using it for building our clients, the restpoints won't change that much I believe. And because I love you, I deployed on OpenShift a version of this secured backend to ease the development of the clients ! If you browse to http://contacts-sblanc.rhcloud.com/ you will even see the mobile web client. This deployed version contains also the Push Message endpoint. The branch of this deployed version can be found here . But let's take a look at the diffrent REST endpoints : CRUD operations I won't detail them here, since there is already a doc for that : https://github.com/jboss-developer/jboss-wfk-quickstarts/blob/2.6.x-develop/contacts-mobile-basic/SERVICES.md Security *DISCLAIMER* : These might change REGISTERregister a new user /rest/security/registration - Request type: POST - Request type: JSON - Return type: JSON - Request example: curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"firstName":"Jaime","lastName":"Lannister","userName":"jaime.lannister at westerlands.com","password":"hearmeroar"}' http://contacts-sblanc.rhcloud.com/rest/security/registration *NOTE* : We should use the convention to use the *email* as userName GET/LOGINRerieve a user and log him in /rest/security/user/info - Request type: GET - Request type: JSON - Auth : Basic Auth - Return type: JSON - Request example: curl -v -b cookies.txt -c cookies.txt -u "jaime.lannister at westerlands.com:hearmeroar" -H "Accept: application/json" -H "Content-type: application/json" -X GET http://contacts-sblanc.rhcloud.com/rest/security/user/info LOGOUTLogout a user /rest/security/user/info - Request type: POST - Request type: JSON - Return type: JSON - Request example: curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -X POST http://contacts-sblanc.rhcloud.com/rest/security/logout Push Rest Endpoint I've added a new endpoint to push a message. In the deployed version, it's hardcoded for now to send to the "quickstart" application created for the https://quickstartsups-sblanc.rhcloud.com/ UPS instance, you will also have to create the appropriate variants. Registration with the UPS instance I think the good flow would be to register with UPS once the login was successfull. As *alias* the *email*should be passed Endpoint /rest/contacts/sendMessage - Request type: POST - Request type: JSON - Return type: JSON - Request example: curl -v -b cookies.txt -c cookies.txt -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"author":"Jaime","receiver":"john.snow at thenorth.com","message":"Winter is coming !"}' http://contacts-sblanc.rhcloud.com/rest/contacts/sendMessage So here we can see that we pass data like : { "author":"jaime.lannister at westerlands.com", "receiver":"john.snow at thenorth.com", "message":"Winter is coming !" } To keep it simple, the client should always pass a hardcoded value for the message , we don't want (for now)to add any complexity to the clients by adding an extra dialog to enter custom messages. author and receiver should contain the emails as we used that for the alias in UPS. So, I hope all this will help to boostrap the client's work. Remarks, questions ? (the content of this email is available here ) Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140417/d8862f4e/attachment.html From bruno at abstractj.org Thu Apr 17 08:39:53 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 17 Apr 2014 09:39:53 -0300 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> <534EB669.5030906@abstractj.org> <534EC334.30202@abstractj.org> <534EDA14.8000703@abstractj.org> Message-ID: <534FCB99.30606@abstractj.org> So maybe "master secret" and "secret" are a bad naming, once it's not secret? And the correct would be "API key" Sebastien Blanc wrote: > I compare these secrets with the API keys that Google provides for its > services. When you go on their Cloud Console , you can check your API key > along with the project number. -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140417/7887a242/attachment-0001.bin From lholmqui at redhat.com Thu Apr 17 09:39:55 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 17 Apr 2014 09:39:55 -0400 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: <534FCB99.30606@abstractj.org> References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> <534EB669.5030906@abstractj.org> <534EC334.30202@abstractj.org> <534EDA14.8000703@abstractj.org> <534FCB99.30606@abstractj.org> Message-ID: On Apr 17, 2014, at 8:39 AM, Bruno Oliveira wrote: > So maybe "master secret" and "secret" are a bad naming, once it's not > secret? And the correct would be "API key" +1 to API key, i believe that is what google might use > > Sebastien Blanc wrote: >> I compare these secrets with the API keys that Google provides for its >> services. When you go on their Cloud Console , you can check your API key >> along with the project number. > > -- > abstractj > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Apr 17 13:37:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Apr 2014 10:37:53 -0700 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> <534EB669.5030906@abstractj.org> <534EC334.30202@abstractj.org> <534EDA14.8000703@abstractj.org> <534FCB99.30606@abstractj.org> Message-ID: On Thursday, April 17, 2014, Lucas Holmquist wrote: > > On Apr 17, 2014, at 8:39 AM, Bruno Oliveira > > wrote: > > > So maybe "master secret" and "secret" are a bad naming, once it's not > > secret? And the correct would be "API key" > > +1 to API key, i believe that is what google might use +1 variantKey (instead if secret) AppKey (instead of masterSecret) Sorry for the bad initial naming :-( > > > > > Sebastien Blanc wrote: > >> I compare these secrets with the API keys that Google provides for its > >> services. When you go on their Cloud Console , you can check your API > key > >> along with the project number. > > > > -- > > abstractj > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140417/d5f23099/attachment.html From florian.schrofner at outlook.com Thu Apr 17 14:44:30 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Thu, 17 Apr 2014 11:44:30 -0700 (PDT) Subject: [aerogear-dev] Allow Push Without Master-Secret? In-Reply-To: References: <1397652808858-7474.post@n5.nabble.com> Message-ID: <1397760270058-7491.post@n5.nabble.com> Thanks for your answer, this has definitely guided us in the right direction! I'll try to patch and deploy it on a wildfly cartridge in the next few days (currently we were using the aerogear cartridge). Still.. would you recommend another solution? I don't think there are a lot of other options at the moment, unless we want to expose the master-secret (which would make it even worse in my opinion). Also aerogear seems to be our best bet in terms of cross-platform compatibility, so we'd really like to stay with it. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Allow-Push-Without-Master-Secret-tp7474p7491.html Sent from the aerogear-dev mailing list archive at Nabble.com. From scm.blanc at gmail.com Thu Apr 17 15:10:18 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Thu, 17 Apr 2014 21:10:18 +0200 Subject: [aerogear-dev] Allow Push Without Master-Secret? In-Reply-To: <1397760270058-7491.post@n5.nabble.com> References: <1397652808858-7474.post@n5.nabble.com> <1397760270058-7491.post@n5.nabble.com> Message-ID: <344704EA-04A4-4498-92AA-27D27F1D6B02@gmail.com> Can't you have a third backend party / broker handling the push sending logic (and thus the only one containing the master secret) and the clients (including the chrome addon) just invoke a rest (secured) endpoint on this broker to trigger the sync? Just an idea, I don't know enough the details of your project ;) Seb Envoy? de mon iPhone > Le 17 avr. 2014 ? 20:44, Florian Schrofner a ?crit : > > Thanks for your answer, this has definitely guided us in the right direction! > I'll try to patch and deploy it on a wildfly cartridge in the next few days > (currently we were using the aerogear cartridge). > > Still.. would you recommend another solution? I don't think there are a lot > of other options at the moment, unless we want to expose the master-secret > (which would make it even worse in my opinion). > > Also aerogear seems to be our best bet in terms of cross-platform > compatibility, so we'd really like to stay with it. > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Allow-Push-Without-Master-Secret-tp7474p7491.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From florian.schrofner at outlook.com Thu Apr 17 15:35:42 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Thu, 17 Apr 2014 12:35:42 -0700 (PDT) Subject: [aerogear-dev] Allow Push Without Master-Secret? In-Reply-To: <344704EA-04A4-4498-92AA-27D27F1D6B02@gmail.com> References: <1397652808858-7474.post@n5.nabble.com> <1397760270058-7491.post@n5.nabble.com> <344704EA-04A4-4498-92AA-27D27F1D6B02@gmail.com> Message-ID: <1397763342415-7493.post@n5.nabble.com> I thought about that too.. but I didn't really see the difference, since everybody who knows the link to the broker can also invoke a push without authentication, can't he? Also setting up another server just for forwarding request seems a bit overpowered to me (and a lot more work).. As long as I don't unintentionally open a huge security hole by patching the server it shouldn't make that much difference, should it? Maybe we'll build the first prototypes using the patched aerogear server and switch to the broker later on. Nodejs would be the best option for the broker, I guess? -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Allow-Push-Without-Master-Secret-tp7474p7493.html Sent from the aerogear-dev mailing list archive at Nabble.com. From bruno at abstractj.org Thu Apr 17 15:41:27 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 17 Apr 2014 16:41:27 -0300 Subject: [aerogear-dev] Push server...master secrets, secrets and some refactoring proposal In-Reply-To: References: <534E0FDB.70104@abstractj.com> <20140416131444.030fa5c9@kapy-ntb-x220> <534EA421.4010508@abstractj.org> <20140416180212.48d2a5ed@kapy-ntb-x220> <534EB669.5030906@abstractj.org> <534EC334.30202@abstractj.org> <534EDA14.8000703@abstractj.org> <534FCB99.30606@abstractj.org> Message-ID: <53502E67.6030200@abstractj.org> It's open source, relax, we are always improving. Matthias Wessendorf wrote: > +1 > > variantKey (instead if secret) > AppKey (instead of masterSecret) > > > Sorry for the bad initial naming :-( -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140417/a69a84d8/attachment.bin From bruno at abstractj.org Thu Apr 17 15:48:03 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 17 Apr 2014 16:48:03 -0300 Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients In-Reply-To: References: Message-ID: <53502FF3.8010809@abstractj.org> If your idea is to be secure, please make sure to use HTTPS and enforce users to be redirected. We did it in the past with HSTS on AG Security, might not be hard to copy & paste. Sebastien Blanc wrote: > And because I love you, I deployed on OpenShift a version of this secured > backend to ease the development of the clients ! > > If you browse to http://contacts-sblanc.rhcloud.com/ you will even see the > mobile web client. This deployed version contains also the Push Message > endpoint. -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140417/263d7304/attachment.bin From scm.blanc at gmail.com Thu Apr 17 17:07:23 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 17 Apr 2014 23:07:23 +0200 Subject: [aerogear-dev] [QUICKSTART] Information for the mobile clients In-Reply-To: <53502FF3.8010809@abstractj.org> References: <53502FF3.8010809@abstractj.org> Message-ID: Sure ! This is just a version to ease the client development. I will ask PL team and Joshua their plans around HSTS and HTTPS. In the mean time we can track all of this with https://issues.jboss.org/browse/AGPUSH-596 Thx for the comment ! Sebi On Thu, Apr 17, 2014 at 9:48 PM, Bruno Oliveira wrote: > If your idea is to be secure, please make sure to use HTTPS and enforce > users to be redirected. We did it in the past with HSTS on AG Security, > might not be hard to copy & paste. > > Sebastien Blanc wrote: > > And because I love you, I deployed on OpenShift a version of this secured > > backend to ease the development of the clients ! > > > > If you browse to http://contacts-sblanc.rhcloud.com/ you will even see > the > > mobile web client. This deployed version contains also the Push Message > > endpoint. > > -- > abstractj > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140417/aa89ae93/attachment-0001.html From scm.blanc at gmail.com Thu Apr 17 17:55:24 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 17 Apr 2014 23:55:24 +0200 Subject: [aerogear-dev] Allow Push Without Master-Secret? In-Reply-To: <1397763342415-7493.post@n5.nabble.com> References: <1397652808858-7474.post@n5.nabble.com> <1397760270058-7491.post@n5.nabble.com> <344704EA-04A4-4498-92AA-27D27F1D6B02@gmail.com> <1397763342415-7493.post@n5.nabble.com> Message-ID: On Thu, Apr 17, 2014 at 9:35 PM, Florian Schrofner < florian.schrofner at outlook.com> wrote: > I thought about that too.. but I didn't really see the difference, since > everybody who knows the link to the broker can also invoke a push without > authentication, can't he? > Right, there is no difference, except that you don't have to patch UPS, that you can later secure this REST endpoint and that you deleguate a generic behaviour (sending push messages) to a single place. > > Also setting up another server just for forwarding request seems a bit > overpowered to me (and a lot more work).. > I understand but put in balance the work to create a simple broker and maintain a patched UPS > > As long as I don't unintentionally open a huge security hole by patching > the > server it shouldn't make that much difference, should it? > Well if someone knows your MasterID he can potentially send millions of notifications to all the devices :) > > Maybe we'll build the first prototypes using the patched aerogear server > and > switch to the broker later on. > Nodejs would be the best option for the broker, I guess? > Yeah NodeJS could be a good option, look at this single NodeJS server page that does almost all what you want : https://github.com/sebastienblanc/hackergarten-messenger/blob/master/server/index.js Thx again for your interest ! > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Allow-Push-Without-Master-Secret-tp7474p7493.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140417/f0cb6c77/attachment.html From scm.blanc at gmail.com Fri Apr 18 13:39:46 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 18 Apr 2014 19:39:46 +0200 Subject: [aerogear-dev] UPS Admin Console - migration to AngularJS Message-ID: Hi all, As you might know, it has been decided to migrate from Ember/TopCoat to AngularJS/Bootsrap/Patterngly for the UPS Admin Console. Hylke is currently working on HTML/CSS mockups, and in the mean time, I started to preparation work for the AngularJS migration. Before I go on PTO, I would like to share that with you ;) In this branch : https://github.com/sebastienblanc/aerogear-unified-push-server/tree/angular I have created a new folder "newadmin" containing an pretty empty Angular project. I kept the old "admin" to make the migration easier but in the end of course, the "newadmin" will be merged with the old one. There is not too much in it but enough to start the migration. It's a layout generated by yeoman for AngularJS. I've adapted the Grunt file the same way Luke did for the old console, meaning that you can point to your deployed WAR and having you changes reloaded live. That make the development a way easier. Don't forget to do a "bower install" and "npm install" before doing "grunt server" , the first time you run it the script will break and you will have to fill in the generated "localConfig.json" file (to point to your Wildfly/jboss UPS deployed WAR). I've just created one Angular Service to do the CRUD operations on Applications and Variants. There is also one controller "MainCtrl" which retrieves the list of Applications and shows them in a table on the view. => That is just to show how the flow should go and help going further. Because we are also migrating to KeyCloak , I did not put any effort into the Login interaction. Therefore when the apps load, it logs in automatically. Be sure to set the right password in "app.js" and also the app expects to have a password that is already "confirmed". If you are using a fresh DB, please do the "first login + reset + confirm" dance with curls. So, I have this will help for starting with the migration. See you later ! Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140418/a20c1a02/attachment.html From kris.borchers at gmail.com Sat Apr 19 10:01:38 2014 From: kris.borchers at gmail.com (Kris Borchers) Date: Sat, 19 Apr 2014 09:01:38 -0500 Subject: [aerogear-dev] PhoneGap Developer App Message-ID: <691679B2-3819-496B-8AEB-1F932AAA2E55@gmail.com> I thought this might interest the tools folks. Use an app for testing Phonegap apps without certs, provisioning, etc. app.phonegap.com/?utm_content=bufferdfee5&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140419/6b9dc356/attachment.html From lholmqui at redhat.com Mon Apr 21 10:01:00 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 21 Apr 2014 10:01:00 -0400 Subject: [aerogear-dev] Team Meeting - 4/21/2014 Message-ID: <9EF9C8F3-9087-415B-8B68-E1558A7ACB5F@redhat.com> There will be no meeting today. April 21st, 2014 that is all From edewit at redhat.com Tue Apr 22 02:44:21 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 22 Apr 2014 08:44:21 +0200 Subject: [aerogear-dev] PhoneGap Developer App In-Reply-To: <691679B2-3819-496B-8AEB-1F932AAA2E55@gmail.com> References: <691679B2-3819-496B-8AEB-1F932AAA2E55@gmail.com> Message-ID: Yeah saw that, it?s a simple yet brilliant idea (wish i would have thought of that) we could make something similar with our plugins preinstalled as well. And maybe even make it even simpler as JBDS could instruct the app to load the right page. On 19 Apr,2014, at 16:01 , Kris Borchers wrote: > I thought this might interest the tools folks. Use an app for testing Phonegap apps without certs, provisioning, etc. > > app.phonegap.com/?utm_content=bufferdfee5&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/ce4727f5/attachment.html From edewit at redhat.com Tue Apr 22 03:02:42 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 22 Apr 2014 09:02:42 +0200 Subject: [aerogear-dev] pushplugin release Message-ID: Hi, I?ve announced it before, but didn?t came around to actually do it and we started discussing the version number. So end of the week I?ll release a new version of the aerogear-pushplugin-cordova (for real this time) with version 0.5.0 this will include the 64 bit support the new API and some small bug fixes. Cheers, Erik Jan From matzew at apache.org Tue Apr 22 03:28:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Apr 2014 09:28:51 +0200 Subject: [aerogear-dev] pushplugin release In-Reply-To: References: Message-ID: Sounds good! I will give the current master branch a test, and will report back here On Tue, Apr 22, 2014 at 9:02 AM, Erik Jan de Wit wrote: > Hi, > > I?ve announced it before, but didn?t came around to actually do it and we > started discussing the version number. So end of the week I?ll release a > new version of the aerogear-pushplugin-cordova (for real this time) with > version 0.5.0 this will include the 64 bit support the new API and some > small bug fixes. > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/01878e49/attachment-0001.html From matzew at apache.org Tue Apr 22 05:24:58 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Apr 2014 11:24:58 +0200 Subject: [aerogear-dev] pushplugin release In-Reply-To: References: Message-ID: Hello, I have tested the plugin (master branch) on both: Android and iOS (using the Cordova HelloWorld PR from Erik). It works great! However, let's get [AGPUSH-622] fixed before we do the release -Matthias [AGPUSH-622] https://issues.jboss.org/browse/AGPUSH-622 On Tue, Apr 22, 2014 at 9:28 AM, Matthias Wessendorf wrote: > Sounds good! > > I will give the current master branch a test, and will report back here > > > On Tue, Apr 22, 2014 at 9:02 AM, Erik Jan de Wit wrote: > >> Hi, >> >> I?ve announced it before, but didn?t came around to actually do it and we >> started discussing the version number. So end of the week I?ll release a >> new version of the aerogear-pushplugin-cordova (for real this time) with >> version 0.5.0 this will include the 64 bit support the new API and some >> small bug fixes. >> >> Cheers, >> Erik Jan >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/6a4f9a7d/attachment.html From matzew at apache.org Tue Apr 22 06:57:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Apr 2014 12:57:31 +0200 Subject: [aerogear-dev] SIMPLE Analytics / Metrics for the UnifiedPush Server Message-ID: Hello, second try - as the first thread was hijacked around other discussions. For a first round of collecting some more data around the usage of the push server (aka analytics/metrics), I'd propose we keep it very simple! Overall, I see one major area of interest: *metrics around push messages being sent: - time of sending (using timezone of the server?) - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, categories,...)) - payload (the entire payload, including custom keys - not only alert, sound, badge etc) - info on: "could we deliver to the 3rd party networks?" This is a nice feature, and would enrich the UPS. The server will have a RESTful endpoint, and an UI for displaying the data. The view would be bascially a history for all the push sent (per "Push Application" construct). However, I can see also some interest around device specific metrics: Today we obivously store all the registered devices, but we also remove them from the database table if needed (to not send messages to phones that would no longer receive them anyways). Something that would be interesting as well, might be the following data: - how often was an app has reached the push server (note: every time the app starts, the metadata of the server is being updated (see [2]) - number of device-tokens / registrationIDs that have been removed, when receiving errors from Apple/Google (see [3] or [4]) - number of devices, that were activly removed using our APIs (supported only on Android/SimplePush due to Apple policy, see [5]) While the initial focus should be around the message related metrics, capturing some device data is nice too. Any thoughts ? -Matthias PS: Oh, for the longer run(...), I'd also like to see metrics like "was mobile app opened due to a push notification". BUT that also requires some more work/reseach on the client Push SDKs. But seriously, this is not a priority for the next few months! [1] https://issues.jboss.org/browse/AGPUSH-116 [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/38a47ca8/attachment.html From bruno at abstractj.org Tue Apr 22 07:40:31 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 22 Apr 2014 08:40:31 -0300 Subject: [aerogear-dev] SIMPLE Analytics / Metrics for the UnifiedPush Server In-Reply-To: References: Message-ID: <5356552F.90407@abstractj.org> Don't you think it might violate user's privacy? Matthias Wessendorf wrote: > While the initial focus should be around the message related metrics, > capturing some device data is nice too. -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/6e0211fd/attachment.bin From matzew at apache.org Tue Apr 22 07:57:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Apr 2014 13:57:53 +0200 Subject: [aerogear-dev] SIMPLE Analytics / Metrics for the UnifiedPush Server In-Reply-To: <5356552F.90407@abstractj.org> References: <5356552F.90407@abstractj.org> Message-ID: On Tue, Apr 22, 2014 at 1:40 PM, Bruno Oliveira wrote: > Don't you think it might violate user's privacy? > No. Because the one that reads the stats is the one that: - hosts the mobile app - has access to all the registered devices - also sends the message > > Matthias Wessendorf wrote: > > While the initial focus should be around the message related metrics, > > capturing some device data is nice too. > > -- > abstractj > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/a30405a9/attachment.html From matzew at apache.org Tue Apr 22 07:58:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Apr 2014 13:58:28 +0200 Subject: [aerogear-dev] SIMPLE Analytics / Metrics for the UnifiedPush Server In-Reply-To: References: <5356552F.90407@abstractj.org> Message-ID: On Tue, Apr 22, 2014 at 1:57 PM, Matthias Wessendorf wrote: > > > > On Tue, Apr 22, 2014 at 1:40 PM, Bruno Oliveira wrote: > >> Don't you think it might violate user's privacy? >> > > No. > > Because the one that reads the stats is the one that: > - hosts the mobile app > - has access to all the registered devices > (meaning the metadata, captured in Installation.java entity) > - also sends the message > > > >> >> Matthias Wessendorf wrote: >> > While the initial focus should be around the message related metrics, >> > capturing some device data is nice too. >> >> -- >> abstractj >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/da528a5f/attachment-0001.html From lukas.fryc at gmail.com Tue Apr 22 07:59:08 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Tue, 22 Apr 2014 04:59:08 -0700 Subject: [aerogear-dev] UPS Admin Console - migration to AngularJS In-Reply-To: References: Message-ID: Hey Sebi, Nice job, I can pick up this ball and run with it once I'm back from travels (effectively tomorrow).. On Apr 18, 2014 7:40 PM, "Sebastien Blanc" wrote: > Hi all, > > As you might know, it has been decided to migrate from Ember/TopCoat to > AngularJS/Bootsrap/Patterngly for the UPS Admin Console. > > Hylke is currently working on HTML/CSS mockups, and in the mean time, I > started to preparation work for the AngularJS migration. > > Before I go on PTO, I would like to share that with you ;) > > In this branch : > > https://github.com/sebastienblanc/aerogear-unified-push-server/tree/angular > > I have created a new folder "newadmin" containing an pretty empty Angular > project. I kept the old "admin" to make the migration easier but in the end > of course, the "newadmin" will be merged with the old one. > > There is not too much in it but enough to start the migration. It's a > layout generated by yeoman for AngularJS. > I've adapted the Grunt file the same way Luke did for the old console, > meaning that you can point to your deployed WAR and having you changes > reloaded live. That make the development a way easier. > > Don't forget to do a "bower install" and "npm install" before doing "grunt > server" , the first time you run it the script will break and you will have > to fill in the generated "localConfig.json" file (to point to your > Wildfly/jboss UPS deployed WAR). > > I've just created one Angular Service to do the CRUD operations on > Applications and Variants. > > There is also one controller "MainCtrl" which retrieves the list of > Applications and shows them in a table on the view. => That is just to show > how the flow should go and help going further. > > Because we are also migrating to KeyCloak , I did not put any effort into > the Login interaction. Therefore when the apps load, it logs in > automatically. Be sure to set the right password in "app.js" and also the > app expects to have a password that is already "confirmed". If you are > using a fresh DB, please do the "first login + reset + confirm" dance with > curls. > > So, I have this will help for starting with the migration. > > See you later ! > > Sebi > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/4ffbdb17/attachment.html From miguel21op at gmail.com Tue Apr 22 08:30:07 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Tue, 22 Apr 2014 13:30:07 +0100 Subject: [aerogear-dev] SIMPLE Analytics / Metrics for the UnifiedPush Server In-Reply-To: References: <5356552F.90407@abstractj.org> Message-ID: Pay attention to this please. Collecting data from users / devices is a very serious matter. Maybe it should exist a setup where the user decides what he / she allows to share. Miguel Enviado do meu iPhone No dia 22/04/2014, ?s 12:58, Matthias Wessendorf escreveu: > > > >> On Tue, Apr 22, 2014 at 1:57 PM, Matthias Wessendorf wrote: >> >> >> >>> On Tue, Apr 22, 2014 at 1:40 PM, Bruno Oliveira wrote: >>> Don't you think it might violate user's privacy? >> >> No. >> >> Because the one that reads the stats is the one that: >> - hosts the mobile app >> - has access to all the registered devices > (meaning the metadata, captured in Installation.java entity) >> - also sends the message >> >> >>> >>> Matthias Wessendorf wrote: >>> > While the initial focus should be around the message related metrics, >>> > capturing some device data is nice too. >>> >>> -- >>> abstractj >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/17d5f022/attachment.html From matzew at apache.org Tue Apr 22 08:46:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Apr 2014 14:46:42 +0200 Subject: [aerogear-dev] SIMPLE Analytics / Metrics for the UnifiedPush Server In-Reply-To: References: <5356552F.90407@abstractj.org> Message-ID: On Tue, Apr 22, 2014 at 2:30 PM, Miguel Lemos wrote: > Pay attention to this please. > > Collecting data from users / devices is a very serious matter. > > Maybe it should exist a setup where the user decides what he / she allows > to share. > well, it's all in the hand of those that write the mobile apps and distribute them to the app-store. If your app, Miguel, collects Geo-Data, it's up on you to be honest to the user NOTE: this feature does NOT increase the amount of metadata we store, besides the things that you are already aware of (e.g. alias, category). This is just giving some stats around: Oh, I did already sent 5 messages this week > > Miguel > > Enviado do meu iPhone > > No dia 22/04/2014, ?s 12:58, Matthias Wessendorf > escreveu: > > > > > On Tue, Apr 22, 2014 at 1:57 PM, Matthias Wessendorf wrote: > >> >> >> >> On Tue, Apr 22, 2014 at 1:40 PM, Bruno Oliveira wrote: >> >>> Don't you think it might violate user's privacy? >>> >> >> No. >> >> Because the one that reads the stats is the one that: >> - hosts the mobile app >> - has access to all the registered devices >> > (meaning the metadata, captured in Installation.java entity) > >> - also sends the message >> >> >> >>> >>> Matthias Wessendorf wrote: >>> > While the initial focus should be around the message related metrics, >>> > capturing some device data is nice too. >>> >>> -- >>> abstractj >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/7c830583/attachment.html From bsutter at redhat.com Tue Apr 22 09:58:27 2014 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 22 Apr 2014 09:58:27 -0400 Subject: [aerogear-dev] PhoneGap Developer App In-Reply-To: References: <691679B2-3819-496B-8AEB-1F932AAA2E55@gmail.com> Message-ID: <2EB10686-E86F-42C0-96F4-F67184DA65F9@redhat.com> Can you craft a jira for the idea and get it on the roadmap? Other Cordova/Phonegap tool vendors have had something similar for a while, so it is not a new idea. After all, we are just dealing with HTML/JS/CSS assets in most cases, should be relatively easy to 'republish' and with our LiveReload feature, it could be even more seamless. On Apr 22, 2014, at 2:44 AM, Erik Jan de Wit wrote: > Yeah saw that, it?s a simple yet brilliant idea (wish i would have thought of that) we could make something similar with our plugins preinstalled as well. And maybe even make it even simpler as JBDS could instruct the app to load the right page. > > On 19 Apr,2014, at 16:01 , Kris Borchers wrote: > >> I thought this might interest the tools folks. Use an app for testing Phonegap apps without certs, provisioning, etc. >> >> app.phonegap.com/?utm_content=bufferdfee5&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/92f48456/attachment-0001.html From matzew at apache.org Tue Apr 22 11:11:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Apr 2014 17:11:53 +0200 Subject: [aerogear-dev] pushplugin release In-Reply-To: References: Message-ID: as 622 has been addressed -> I am +1 On Tue, Apr 22, 2014 at 11:24 AM, Matthias Wessendorf wrote: > Hello, > > > I have tested the plugin (master branch) on both: Android and iOS (using > the Cordova HelloWorld PR from Erik). > > It works great! > > > However, let's get [AGPUSH-622] fixed before we do the release > > -Matthias > > > [AGPUSH-622] https://issues.jboss.org/browse/AGPUSH-622 > > > > > On Tue, Apr 22, 2014 at 9:28 AM, Matthias Wessendorf wrote: > >> Sounds good! >> >> I will give the current master branch a test, and will report back here >> >> >> On Tue, Apr 22, 2014 at 9:02 AM, Erik Jan de Wit wrote: >> >>> Hi, >>> >>> I?ve announced it before, but didn?t came around to actually do it and >>> we started discussing the version number. So end of the week I?ll release a >>> new version of the aerogear-pushplugin-cordova (for real this time) with >>> version 0.5.0 this will include the 64 bit support the new API and some >>> small bug fixes. >>> >>> Cheers, >>> Erik Jan >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/9787beda/attachment.html From gorkem.ercan at gmail.com Tue Apr 22 13:01:23 2014 From: gorkem.ercan at gmail.com (Gorkem Ercan) Date: Tue, 22 Apr 2014 10:01:23 -0700 Subject: [aerogear-dev] PhoneGap Developer App In-Reply-To: <2EB10686-E86F-42C0-96F4-F67184DA65F9@redhat.com> References: <691679B2-3819-496B-8AEB-1F932AAA2E55@gmail.com> <2EB10686-E86F-42C0-96F4-F67184DA65F9@redhat.com> Message-ID: Cordova project already has an app [1]. Of course it does not work for plugins that have native parts. I think we need to take this app, bundle our plugins. Also for best results on iOS we may actually need to put it to the store. [1] https://github.com/apache/cordova-app-harness -- Gorkem On Tuesday, April 22, 2014, Burr Sutter wrote: > Can you craft a jira for the idea and get it on the roadmap? Other > Cordova/Phonegap tool vendors have had something similar for a while, so it > is not a new idea. > > After all, we are just dealing with HTML/JS/CSS assets in most cases, > should be relatively easy to 'republish' and with our LiveReload feature, > it could be even more seamless. > > On Apr 22, 2014, at 2:44 AM, Erik Jan de Wit > > wrote: > > Yeah saw that, it?s a simple yet brilliant idea (wish i would have thought > of that) we could make something similar with our plugins preinstalled as > well. And maybe even make it even simpler as JBDS could instruct the app to > load the right page. > > On 19 Apr,2014, at 16:01 , Kris Borchers > > wrote: > > I thought this might interest the tools folks. Use an app for testing > Phonegap apps without certs, provisioning, etc. > > > app.phonegap.com/?utm_content=bufferdfee5&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140422/7fd4d8cb/attachment.html From miguel21op at gmail.com Wed Apr 23 04:18:11 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 23 Apr 2014 09:18:11 +0100 Subject: [aerogear-dev] Problems sending notifications Cordova Message-ID: Hi, After a couple of weeks without testing the service, I tried to send a push notification, but the device didn't receive nothing. I didn't change nothing... And: - I get a "job submitted" answer; - The device is still registered and is with the "enabled status" at the Aerogear Push Server; - The device itself throws no error; - No problem with the OpenShift DB, as happened before. Has any thing changed? What could it be? Thanks Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/27d7f112/attachment.html From daniel.bevenius at gmail.com Wed Apr 23 04:18:12 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 23 Apr 2014 10:18:12 +0200 Subject: [aerogear-dev] SimplePush Server 0.11.0 Message-ID: Hi all, just wanted to give a heads up that I've rescheduled the release of SimplePush 0.11.0 [1]. There are only two task remaining, but I'll be working on other things for a while which is the reason for there not being more. The main task of interest I think is [2], which allows notifications to be done without a version in the body of the HTTP request. This I believe will simplify the admin ui and perhaps other areas. If you'd like to see an earlier release then let me know and I'll get it done. As of now though, I've set the release date to May 6. /Dan [1] https://issues.jboss.org/browse/AGSMPLPUSH-16?filter=12321270&jql=project%20%3D%20AGSMPLPUSH%20AND%20fixVersion%20%3D%20%220.11.0%22%20AND%20status%20in%20(Open%2C%20%22Coding%20In%20Progress%22%2C%20Reopened%2C%20%22Pull%20Request%20Sent%22) [2] https://issues.jboss.org/browse/AGSMPLPUSH-54 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/deb63a97/attachment.html From florian.schrofner at outlook.com Wed Apr 23 04:32:27 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Wed, 23 Apr 2014 10:32:27 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova Message-ID: Got the same problem here using the library for Android! The server seems to accept the request, but nothing happens.. maybe a problem with GCM? On 23 Apr 2014 10:19, Miguel Lemos wrote: Hi, After a couple of weeks without testing the service, I tried to send a push notification, but the device didn't receive nothing. I didn't change nothing... And: - I get a "job submitted" answer; - The device is still registered and is with the "enabled status" at the Aerogear Push Server; - The device itself throws no error; - No problem with the OpenShift DB, as happened before. Has any thing changed? What could it be? Thanks Miguel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/a882e72c/attachment.html -------------- next part -------------- _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev From miguel21op at gmail.com Wed Apr 23 04:40:33 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 23 Apr 2014 09:40:33 +0100 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: No, I don't think so. GCM "never" fails. And the same problem happened yesterday. Besides, the same problem occurs with a iPhone. On Wed, Apr 23, 2014 at 9:32 AM, Florian Schrofner < florian.schrofner at outlook.com> wrote: > Got the same problem here using the library for Android! > > The server seems to accept the request, but nothing happens.. maybe a > problem with GCM? > On 23 Apr 2014 10:19, Miguel Lemos wrote: > Hi, > > After a couple of weeks without testing the service, I tried to send a > push notification, but the device didn't receive nothing. I didn't change > nothing... > > And: > > - I get a "job submitted" answer; > - The device is still registered and is with the "enabled status" at the > Aerogear Push Server; > - The device itself throws no error; > - No problem with the OpenShift DB, as happened before. > > Has any thing changed? What could it be? > > Thanks > > Miguel > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/79e853b4/attachment-0001.html From matzew at apache.org Wed Apr 23 04:40:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 10:40:38 +0200 Subject: [aerogear-dev] SimplePush Server 0.11.0 In-Reply-To: References: Message-ID: On Wed, Apr 23, 2014 at 10:18 AM, Daniel Bevenius wrote: > Hi all, > > just wanted to give a heads up that I've rescheduled the release of > SimplePush 0.11.0 [1]. There are only two task remaining, but I'll be > working on other things for a while which is the reason for there not being > more. > > The main task of interest I think is [2], which allows notifications to be > done without a version in the body of the HTTP request. This I believe will > simplify the admin ui and perhaps other areas. > yeah, glad to see that being there :-) This will help a lot! > If you'd like to see an earlier release then let me know and I'll get it > done. As of now though, I've set the release date to May 6. > sounds good to me > > /Dan > > > [1] > https://issues.jboss.org/browse/AGSMPLPUSH-16?filter=12321270&jql=project%20%3D%20AGSMPLPUSH%20AND%20fixVersion%20%3D%20%220.11.0%22%20AND%20status%20in%20(Open%2C%20%22Coding%20In%20Progress%22%2C%20Reopened%2C%20%22Pull%20Request%20Sent%22) > > [2] https://issues.jboss.org/browse/AGSMPLPUSH-54 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/d54a433e/attachment.html From matzew at apache.org Wed Apr 23 04:43:20 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 10:43:20 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: Anything inside of the logfiles from JBoss AS ? -Matthias On Wed, Apr 23, 2014 at 10:18 AM, Miguel Lemos wrote: > Hi, > > After a couple of weeks without testing the service, I tried to send a > push notification, but the device didn't receive nothing. I didn't change > nothing... > > And: > > - I get a "job submitted" answer; > - The device is still registered and is with the "enabled status" at the > Aerogear Push Server; > - The device itself throws no error; > - No problem with the OpenShift DB, as happened before. > > Has any thing changed? What could it be? > > Thanks > > Miguel > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/be080fb0/attachment.html From florian.schrofner at outlook.com Wed Apr 23 04:45:57 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Wed, 23 Apr 2014 10:45:57 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova Message-ID: I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. But since it happens on iOS too this doesn't seem to be the matter.. Any other clues? From matzew at apache.org Wed Apr 23 04:52:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 10:52:53 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: One thing to have in mind: Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) @Android: is the app running? I think there are issues w/ the Android process has has been killed On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner < florian.schrofner at outlook.com> wrote: > I didn't mean that GCM failed.. just thought that GCM maybe decided to > block aerogear now or something like that. > But since it happens on iOS too this doesn't seem to be the matter.. > > Any other clues? > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/e591fd35/attachment.html From miguel21op at gmail.com Wed Apr 23 04:58:30 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 23 Apr 2014 09:58:30 +0100 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: Of course I sent several requests... The problem with Openshift (that should never occur...) has disappeared after the correction done some weeks ago. As I told you in my first message, I get a "job submitted" answer from the server. On Wed, Apr 23, 2014 at 9:52 AM, Matthias Wessendorf wrote: > One thing to have in mind: > > Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. > > Than, the next request does boot up the server. In theory that can mean, a > push might be missed, while still booting up the system. > See ? A metrics/Analytics view would give all that information :-) (e.g. > how many push were sent, and delivered to the 3rd party networks) > > > @Android: is the app running? I think there are issues w/ the Android > process has has been killed > > > > On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner < > florian.schrofner at outlook.com> wrote: > >> I didn't mean that GCM failed.. just thought that GCM maybe decided to >> block aerogear now or something like that. >> But since it happens on iOS too this doesn't seem to be the matter.. >> >> Any other clues? >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/0a090a7a/attachment.html From matzew at apache.org Wed Apr 23 05:02:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 11:02:05 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: On Wed, Apr 23, 2014 at 10:58 AM, Miguel Lemos wrote: > Of course I sent several requests... > > The problem with Openshift (that should never occur...) > I am sure they still feel very sorry about that this problem ever could happen > has disappeared after the correction done some weeks ago. > As I told you in my first message, I get a "job submitted" answer from the > server. > OK, so - what does the server-side log file say ? > > > On Wed, Apr 23, 2014 at 9:52 AM, Matthias Wessendorf wrote: > >> One thing to have in mind: >> >> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >> >> Than, the next request does boot up the server. In theory that can mean, >> a push might be missed, while still booting up the system. >> See ? A metrics/Analytics view would give all that information :-) (e.g. >> how many push were sent, and delivered to the 3rd party networks) >> >> >> @Android: is the app running? I think there are issues w/ the Android >> process has has been killed >> >> >> >> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner < >> florian.schrofner at outlook.com> wrote: >> >>> I didn't mean that GCM failed.. just thought that GCM maybe decided to >>> block aerogear now or something like that. >>> But since it happens on iOS too this doesn't seem to be the matter.. >>> >>> Any other clues? >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/4eb9c655/attachment-0001.html From florian.schrofner at outlook.com Wed Apr 23 05:01:41 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Wed, 23 Apr 2014 11:01:41 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova Message-ID: At least the interface for aerogear was reachable while i was testing the pushes.. is it independant from the "real" server? Unfortunately none of the pushes were sent/received, so it's not only the first one. The app on Android was running and the registration was successful. From matzew at apache.org Wed Apr 23 05:08:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 11:08:49 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: Hello Florian, couple of questions: - can you share the code that triggers the push ? (or did you go through the AdminUI) - can you share your client code (registration and the JS function that receives the push) - was your app working at some point ? On Wed, Apr 23, 2014 at 11:01 AM, Florian Schrofner < florian.schrofner at outlook.com> wrote: > At least the interface for aerogear was reachable while i was testing the > pushes.. is it independant from the "real" server? > > Unfortunately none of the pushes were sent/received, so it's not only the > first one. > > The app on Android was running and the registration was successful. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/7ed27f63/attachment.html From miguel21op at gmail.com Wed Apr 23 05:09:17 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 23 Apr 2014 10:09:17 +0100 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: <9D6170CF-F2C2-4C3E-9AEF-2113CDFEFA5A@gmail.com> Now I can't see that... When I'm back in office. Enviado do meu iPhone No dia 23/04/2014, ?s 10:02, Matthias Wessendorf escreveu: > > > >> On Wed, Apr 23, 2014 at 10:58 AM, Miguel Lemos wrote: >> Of course I sent several requests... >> >> The problem with Openshift (that should never occur...) > > I am sure they still feel very sorry about that this problem ever could happen > >> has disappeared after the correction done some weeks ago. >> As I told you in my first message, I get a "job submitted" answer from the server. > > OK, so - what does the server-side log file say ? > > >> >> >>> On Wed, Apr 23, 2014 at 9:52 AM, Matthias Wessendorf wrote: >>> One thing to have in mind: >>> >>> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >>> >>> Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. >>> See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) >>> >>> >>> @Android: is the app running? I think there are issues w/ the Android process has has been killed >>> >>> >>> >>>> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: >>>> I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. >>>> But since it happens on iOS too this doesn't seem to be the matter.. >>>> >>>> Any other clues? >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/aa9c0b97/attachment.html From edewit at redhat.com Wed Apr 23 05:11:07 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 23 Apr 2014 11:11:07 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: <4F1F24A9-7D0A-44E2-9504-91AD65EF4063@redhat.com> I?m testing some messages myself today and I see that the messages appear to be very very slow on GCM at the moment. On 23 Apr,2014, at 11:01 , Florian Schrofner wrote: > At least the interface for aerogear was reachable while i was testing the pushes.. is it independant from the "real" server? > > Unfortunately none of the pushes were sent/received, so it's not only the first one. > > The app on Android was running and the registration was successful. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Wed Apr 23 05:11:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 11:11:21 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <9D6170CF-F2C2-4C3E-9AEF-2113CDFEFA5A@gmail.com> References: <9D6170CF-F2C2-4C3E-9AEF-2113CDFEFA5A@gmail.com> Message-ID: On Wed, Apr 23, 2014 at 11:09 AM, Miguel Lemos wrote: > Now I can't see that... When I'm back in office. > perfect! Just in case... not sure... if the problem persists, I'd recommend to reboot the instance, on Openshift (using the console). -Matthias > > Enviado do meu iPhone > > No dia 23/04/2014, ?s 10:02, Matthias Wessendorf > escreveu: > > > > > On Wed, Apr 23, 2014 at 10:58 AM, Miguel Lemos wrote: > >> Of course I sent several requests... >> >> The problem with Openshift (that should never occur...) >> > > I am sure they still feel very sorry about that this problem ever could > happen > > >> has disappeared after the correction done some weeks ago. >> As I told you in my first message, I get a "job submitted" answer from >> the server. >> > > OK, so - what does the server-side log file say ? > > > >> >> >> On Wed, Apr 23, 2014 at 9:52 AM, Matthias Wessendorf wrote: >> >>> One thing to have in mind: >>> >>> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no >>> traffic. >>> >>> Than, the next request does boot up the server. In theory that can mean, >>> a push might be missed, while still booting up the system. >>> See ? A metrics/Analytics view would give all that information :-) (e.g. >>> how many push were sent, and delivered to the 3rd party networks) >>> >>> >>> @Android: is the app running? I think there are issues w/ the Android >>> process has has been killed >>> >>> >>> >>> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner < >>> florian.schrofner at outlook.com> wrote: >>> >>>> I didn't mean that GCM failed.. just thought that GCM maybe decided to >>>> block aerogear now or something like that. >>>> But since it happens on iOS too this doesn't seem to be the matter.. >>>> >>>> Any other clues? >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/b85715a0/attachment-0001.html From miguel21op at gmail.com Wed Apr 23 05:42:14 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 23 Apr 2014 10:42:14 +0100 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> I made a reset to OShift and it's working again. This is really an issue that one way or another should be solved... Enviado do meu iPhone No dia 23/04/2014, ?s 09:52, Matthias Wessendorf escreveu: > One thing to have in mind: > > Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. > > Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. > See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) > > > @Android: is the app running? I think there are issues w/ the Android process has has been killed > > > >> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: >> I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. >> But since it happens on iOS too this doesn't seem to be the matter.. >> >> Any other clues? >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/c80d53ba/attachment.html From florian.schrofner at outlook.com Wed Apr 23 06:04:52 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Wed, 23 Apr 2014 03:04:52 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: Message-ID: <1398247492069-7531.post@n5.nabble.com> I just wanted to send you parts of my code as I got Miguel's email. For me the push server also works again after a restart. So I guess the code is irrelevant here.. I'll try to send the log your way, when I get to it. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7531.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Wed Apr 23 06:47:47 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 12:47:47 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> Message-ID: Hi Miguel, thanks for the update. If you could share the log, of the JBoss instance on your OpenShift account, that would be great. And yes, as you may expect, we are interested in solving this issues... On Wed, Apr 23, 2014 at 11:42 AM, Miguel Lemos wrote: > I made a reset to OShift and it's working again. > > This is really an issue that one way or another should be solved... > > Enviado do meu iPhone > > No dia 23/04/2014, ?s 09:52, Matthias Wessendorf > escreveu: > > One thing to have in mind: > > Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. > > Than, the next request does boot up the server. In theory that can mean, a > push might be missed, while still booting up the system. > See ? A metrics/Analytics view would give all that information :-) (e.g. > how many push were sent, and delivered to the 3rd party networks) > > > @Android: is the app running? I think there are issues w/ the Android > process has has been killed > > > > On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner < > florian.schrofner at outlook.com> wrote: > >> I didn't mean that GCM failed.. just thought that GCM maybe decided to >> block aerogear now or something like that. >> But since it happens on iOS too this doesn't seem to be the matter.. >> >> Any other clues? >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/1352dd7d/attachment.html From miguel21op at gmail.com Wed Apr 23 07:21:35 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 23 Apr 2014 12:21:35 +0100 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> Message-ID: <362E602F-3D0B-4DEA-ADFE-3CC338BC82D5@gmail.com> Now I can't. Anyway: I already shared the log on a previous similar situation... M Enviado do meu iPhone No dia 23/04/2014, ?s 11:47, Matthias Wessendorf escreveu: > Hi Miguel, > > thanks for the update. If you could share the log, of the JBoss instance on your OpenShift account, that would be great. > And yes, as you may expect, we are interested in solving this issues... > > > >> On Wed, Apr 23, 2014 at 11:42 AM, Miguel Lemos wrote: >> I made a reset to OShift and it's working again. >> >> This is really an issue that one way or another should be solved... >> >> Enviado do meu iPhone >> >> No dia 23/04/2014, ?s 09:52, Matthias Wessendorf escreveu: >> >>> One thing to have in mind: >>> >>> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >>> >>> Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. >>> See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) >>> >>> >>> @Android: is the app running? I think there are issues w/ the Android process has has been killed >>> >>> >>> >>>> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: >>>> I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. >>>> But since it happens on iOS too this doesn't seem to be the matter.. >>>> >>>> Any other clues? >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/57096a0b/attachment.html From edewit at redhat.com Wed Apr 23 07:35:13 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 23 Apr 2014 13:35:13 +0200 Subject: [aerogear-dev] contacts-mobile-basic quick start Message-ID: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com> Hi, I was working on the aerogear-push-quickstarts for Cordova and was wondering what to put for the alias on registration. The version that is there now has users that logs in and contacts that are fetched. What seems to be missing is that everybody gets all contacts instead of just mine (maybe that is fine), but users that sign up for the app are not contacts. So when I want to send a message to a specific mobile user they are not in my list and there is no way to have to define an alias to send to. Also the interface for sending push notifications includes a author. I think it would be better if we remove this and let the service put in the logged in user. That way you can?t pretend to send a message like someone else. What do you think? Cheers, Erik Jan From matzew at apache.org Wed Apr 23 07:39:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 13:39:02 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <362E602F-3D0B-4DEA-ADFE-3CC338BC82D5@gmail.com> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <362E602F-3D0B-4DEA-ADFE-3CC338BC82D5@gmail.com> Message-ID: On Wed, Apr 23, 2014 at 1:21 PM, Miguel Lemos wrote: > Now I can't. > Anyway: I already shared the log on a previous similar situation... > well, just because it acts similar does obviously not mean it is the same issue. Feel free to share whenever you can, as we are interested in getting _this_ particular issue addressed -M > > M > > Enviado do meu iPhone > > No dia 23/04/2014, ?s 11:47, Matthias Wessendorf > escreveu: > > Hi Miguel, > > thanks for the update. If you could share the log, of the JBoss instance > on your OpenShift account, that would be great. > And yes, as you may expect, we are interested in solving this issues... > > > > On Wed, Apr 23, 2014 at 11:42 AM, Miguel Lemos wrote: > >> I made a reset to OShift and it's working again. >> >> This is really an issue that one way or another should be solved... >> >> Enviado do meu iPhone >> >> No dia 23/04/2014, ?s 09:52, Matthias Wessendorf >> escreveu: >> >> One thing to have in mind: >> >> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >> >> Than, the next request does boot up the server. In theory that can mean, >> a push might be missed, while still booting up the system. >> See ? A metrics/Analytics view would give all that information :-) (e.g. >> how many push were sent, and delivered to the 3rd party networks) >> >> >> @Android: is the app running? I think there are issues w/ the Android >> process has has been killed >> >> >> >> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner < >> florian.schrofner at outlook.com> wrote: >> >>> I didn't mean that GCM failed.. just thought that GCM maybe decided to >>> block aerogear now or something like that. >>> But since it happens on iOS too this doesn't seem to be the matter.. >>> >>> Any other clues? >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/7bbcedfc/attachment.html From bruno at abstractj.org Wed Apr 23 07:41:21 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 23 Apr 2014 04:41:21 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> Message-ID: <1398253280436.e1175469@Nodemailer> Hi Miguel, if you make us a favor and send the logs next time, that would help a lot. Is hard to guess, because we don't have control over the OpenShift's infrastructure ? abstractj On Wed, Apr 23, 2014 at 6:42 AM, Miguel Lemos wrote: > I made a reset to OShift and it's working again. > This is really an issue that one way or another should be solved... > Enviado do meu iPhone > No dia 23/04/2014, ?s 09:52, Matthias Wessendorf escreveu: >> One thing to have in mind: >> >> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >> >> Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. >> See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) >> >> >> @Android: is the app running? I think there are issues w/ the Android process has has been killed >> >> >> >>> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: >>> I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. >>> But since it happens on iOS too this doesn't seem to be the matter.. >>> >>> Any other clues? >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/7c80901a/attachment.html From bruno at abstractj.org Wed Apr 23 07:43:00 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 23 Apr 2014 04:43:00 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <362E602F-3D0B-4DEA-ADFE-3CC338BC82D5@gmail.com> References: <362E602F-3D0B-4DEA-ADFE-3CC338BC82D5@gmail.com> Message-ID: <1398253379767.758514c9@Nodemailer> Every situation is different.? abstractj On Wed, Apr 23, 2014 at 8:21 AM, Miguel Lemos wrote: > Now I can't. > Anyway: I already shared the log on a previous similar situation... > M > Enviado do meu iPhone > No dia 23/04/2014, ?s 11:47, Matthias Wessendorf escreveu: >> Hi Miguel, >> >> thanks for the update. If you could share the log, of the JBoss instance on your OpenShift account, that would be great. >> And yes, as you may expect, we are interested in solving this issues... >> >> >> >>> On Wed, Apr 23, 2014 at 11:42 AM, Miguel Lemos wrote: >>> I made a reset to OShift and it's working again. >>> >>> This is really an issue that one way or another should be solved... >>> >>> Enviado do meu iPhone >>> >>> No dia 23/04/2014, ?s 09:52, Matthias Wessendorf escreveu: >>> >>>> One thing to have in mind: >>>> >>>> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >>>> >>>> Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. >>>> See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) >>>> >>>> >>>> @Android: is the app running? I think there are issues w/ the Android process has has been killed >>>> >>>> >>>> >>>>> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: >>>>> I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. >>>>> But since it happens on iOS too this doesn't seem to be the matter.. >>>>> >>>>> Any other clues? >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at 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 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/f766a4d9/attachment-0001.html From miguel21op at gmail.com Wed Apr 23 07:58:18 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 23 Apr 2014 12:58:18 +0100 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <1398253280436.e1175469@Nodemailer> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> Message-ID: <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> No favor. I'm not near a PC.., As I told before, I've already sent a log related to a similar problem a month ago, I think. Anyway: this is a recurring problem that deserves a deep attention, I think. Enviado do meu iPhone No dia 23/04/2014, ?s 12:41, "Bruno Oliveira" escreveu: > Hi Miguel, if you make us a favor and send the logs next time, that would help a lot. > > Is hard to guess, because we don't have control over the OpenShift's infrastructure > ? > abstractj > > >> On Wed, Apr 23, 2014 at 6:42 AM, Miguel Lemos wrote: >> I made a reset to OShift and it's working again. >> >> This is really an issue that one way or another should be solved... >> >> Enviado do meu iPhone >> >> No dia 23/04/2014, ?s 09:52, Matthias Wessendorf escreveu: >> >>> One thing to have in mind: >>> >>> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >>> >>> Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. >>> See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) >>> >>> >>> @Android: is the app running? I think there are issues w/ the Android process has has been killed >>> >>> >>> >>>> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: >>>> I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. >>>> But since it happens on iOS too this doesn't seem to be the matter.. >>>> >>>> Any other clues? >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/df3ffa2b/attachment.html From matzew at apache.org Wed Apr 23 08:02:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 14:02:14 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> Message-ID: On Wed, Apr 23, 2014 at 1:58 PM, Miguel Lemos wrote: > No favor. I'm not near a PC.., > > As I told before, I've already sent a log related to a similar problem a > month ago, I think. > What Bruno and I tried to say: We do think that the UNDERLYING problem of this is NOT necessarily the same as it was in the past. As said, feel free to send the recent log, if you like > > Anyway: this is a recurring problem that deserves a deep attention, I > think. > > Enviado do meu iPhone > > No dia 23/04/2014, ?s 12:41, "Bruno Oliveira" > escreveu: > > Hi Miguel, if you make us a favor and send the logs next time, that would > help a lot. > > Is hard to guess, because we don't have control over the OpenShift's > infrastructure > ? > abstractj > > > On Wed, Apr 23, 2014 at 6:42 AM, Miguel Lemos wrote: > >> I made a reset to OShift and it's working again. >> >> This is really an issue that one way or another should be solved... >> >> Enviado do meu iPhone >> >> No dia 23/04/2014, ?s 09:52, Matthias Wessendorf >> escreveu: >> >> One thing to have in mind: >> >> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >> >> Than, the next request does boot up the server. In theory that can mean, >> a push might be missed, while still booting up the system. >> See ? A metrics/Analytics view would give all that information :-) (e.g. >> how many push were sent, and delivered to the 3rd party networks) >> >> >> @Android: is the app running? I think there are issues w/ the Android >> process has has been killed >> >> >> >> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner < >> florian.schrofner at outlook.com> wrote: >> >>> I didn't mean that GCM failed.. just thought that GCM maybe decided to >>> block aerogear now or something like that. >>> But since it happens on iOS too this doesn't seem to be the matter.. >>> >>> Any other clues? >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at 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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/2499e18b/attachment.html From bruno at abstractj.org Wed Apr 23 08:02:25 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 23 Apr 2014 05:02:25 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> References: <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> Message-ID: <1398254544212.cf8cff71@Nodemailer> No problem, I understand. With more details, we might be able to investigate? abstractj On Wed, Apr 23, 2014 at 8:58 AM, Miguel Lemos wrote: > No favor. I'm not near a PC.., > As I told before, I've already sent a log related to a similar problem a month ago, I think. > Anyway: this is a recurring problem that deserves a deep attention, I think. > Enviado do meu iPhone > No dia 23/04/2014, ?s 12:41, "Bruno Oliveira" escreveu: >> Hi Miguel, if you make us a favor and send the logs next time, that would help a lot. >> >> Is hard to guess, because we don't have control over the OpenShift's infrastructure >> ? >> abstractj >> >> >>> On Wed, Apr 23, 2014 at 6:42 AM, Miguel Lemos wrote: >>> I made a reset to OShift and it's working again. >>> >>> This is really an issue that one way or another should be solved... >>> >>> Enviado do meu iPhone >>> >>> No dia 23/04/2014, ?s 09:52, Matthias Wessendorf escreveu: >>> >>>> One thing to have in mind: >>>> >>>> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >>>> >>>> Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. >>>> See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) >>>> >>>> >>>> @Android: is the app running? I think there are issues w/ the Android process has has been killed >>>> >>>> >>>> >>>>> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: >>>>> I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. >>>>> But since it happens on iOS too this doesn't seem to be the matter.. >>>>> >>>>> Any other clues? >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at 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 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/5cefd770/attachment-0001.html From miguel21op at gmail.com Wed Apr 23 08:26:08 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Wed, 23 Apr 2014 13:26:08 +0100 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> Message-ID: <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> I think I understood... I hope you understand too what I'm trying to say: since I started with Aerogear some months ago I was warned about this situation. This is a recurring problem. Maybe there are already many logs reporting it... Anyway, as you may know, when I can I try to send all the information possible to track these kind of situations, bugs etc. to help your work. Now I just can't. Signing off ;-) M Enviado do meu iPhone No dia 23/04/2014, ?s 13:02, Matthias Wessendorf escreveu: > > > >> On Wed, Apr 23, 2014 at 1:58 PM, Miguel Lemos wrote: >> No favor. I'm not near a PC.., >> >> As I told before, I've already sent a log related to a similar problem a month ago, I think. > > > What Bruno and I tried to say: > We do think that the UNDERLYING problem of this is NOT necessarily the same as it was in the past. > > As said, feel free to send the recent log, if you like > >> >> Anyway: this is a recurring problem that deserves a deep attention, I think. >> >> Enviado do meu iPhone >> >> No dia 23/04/2014, ?s 12:41, "Bruno Oliveira" escreveu: >> >>> Hi Miguel, if you make us a favor and send the logs next time, that would help a lot. >>> >>> Is hard to guess, because we don't have control over the OpenShift's infrastructure >>> ? >>> abstractj >>> >>> >>>> On Wed, Apr 23, 2014 at 6:42 AM, Miguel Lemos wrote: >>>> I made a reset to OShift and it's working again. >>>> >>>> This is really an issue that one way or another should be solved... >>>> >>>> Enviado do meu iPhone >>>> >>>> No dia 23/04/2014, ?s 09:52, Matthias Wessendorf escreveu: >>>> >>>>> One thing to have in mind: >>>>> >>>>> Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. >>>>> >>>>> Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. >>>>> See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) >>>>> >>>>> >>>>> @Android: is the app running? I think there are issues w/ the Android process has has been killed >>>>> >>>>> >>>>> >>>>>> On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: >>>>>> I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. >>>>>> But since it happens on iOS too this doesn't seem to be the matter.. >>>>>> >>>>>> Any other clues? >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at 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 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/a9621193/attachment.html From scm.blanc at gmail.com Wed Apr 23 08:34:00 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Wed, 23 Apr 2014 14:34:00 +0200 Subject: [aerogear-dev] contacts-mobile-basic quick start In-Reply-To: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com> References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com> Message-ID: <5B19161A-39B3-4F60-9F89-722D16A1B513@gmail.com> We should be using the email as alias and the email should also be used as login when registering in the secured part. A registration should also trigger the creation of that user / contact in the application. Author can be left empty By the client and filled by the backend . https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_securedAuthor must stay because the receiver must know who sends the message. Envoy? de mon iPhone > Le 23 avr. 2014 ? 13:35, Erik Jan de Wit a ?crit : > > Hi, > > I was working on the aerogear-push-quickstarts for Cordova and was wondering what to put for the alias on registration. The version that is there now has users that logs in and contacts that are fetched. What seems to be missing is that everybody gets all contacts instead of just mine (maybe that is fine), but users that sign up for the app are not contacts. So when I want to send a message to a specific mobile user they are not in my list and there is no way to have to define an alias to send to. > > Also the interface for sending push notifications includes a author. I think it would be better if we remove this and let the service put in the logged in user. That way you can?t pretend to send a message like someone else. > > What do you think? > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Wed Apr 23 08:36:29 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 23 Apr 2014 14:36:29 +0200 Subject: [aerogear-dev] contacts-mobile-basic quick start In-Reply-To: <5B19161A-39B3-4F60-9F89-722D16A1B513@gmail.com> References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com> <5B19161A-39B3-4F60-9F89-722D16A1B513@gmail.com> Message-ID: +1 but as suggested by Erik, it could be prefilled read-only information for the sender ++ Corinne On 23 April 2014 14:34, S?bastien Blanc wrote: > We should be using the email as alias and the email should also be used as > login when registering in the secured part. A registration should also > trigger the creation of that user / contact in the application. > Author can be left empty By the client and filled by the backend . > https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_securedAuthormust stay because the receiver must know who sends the message. > > Envoy? de mon iPhone > > > Le 23 avr. 2014 ? 13:35, Erik Jan de Wit a ?crit : > > > > Hi, > > > > I was working on the aerogear-push-quickstarts for Cordova and was > wondering what to put for the alias on registration. The version that is > there now has users that logs in and contacts that are fetched. What seems > to be missing is that everybody gets all contacts instead of just mine > (maybe that is fine), but users that sign up for the app are not contacts. > So when I want to send a message to a specific mobile user they are not in > my list and there is no way to have to define an alias to send to. > > > > Also the interface for sending push notifications includes a author. I > think it would be better if we remove this and let the service put in the > logged in user. That way you can?t pretend to send a message like someone > else. > > > > What do you think? > > > > Cheers, > > Erik Jan > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/56c9c2fb/attachment.html From lholmqui at redhat.com Wed Apr 23 08:47:13 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 23 Apr 2014 08:47:13 -0400 Subject: [aerogear-dev] SimplePush Server 0.11.0 In-Reply-To: References: Message-ID: On Apr 23, 2014, at 4:40 AM, Matthias Wessendorf wrote: > > > > On Wed, Apr 23, 2014 at 10:18 AM, Daniel Bevenius wrote: > Hi all, > > just wanted to give a heads up that I've rescheduled the release of SimplePush 0.11.0 [1]. There are only two task remaining, but I'll be working on other things for a while which is the reason for there not being more. > > The main task of interest I think is [2], which allows notifications to be done without a version in the body of the HTTP request. This I believe will simplify the admin ui and perhaps other areas. > > yeah, glad to see that being there :-) > This will help a lot! really looking forward to this feature > > > If you'd like to see an earlier release then let me know and I'll get it done. As of now though, I've set the release date to May 6. > > sounds good to me > > > > /Dan > > > [1] https://issues.jboss.org/browse/AGSMPLPUSH-16?filter=12321270&jql=project%20%3D%20AGSMPLPUSH%20AND%20fixVersion%20%3D%20%220.11.0%22%20AND%20status%20in%20(Open%2C%20%22Coding%20In%20Progress%22%2C%20Reopened%2C%20%22Pull%20Request%20Sent%22) > > [2] https://issues.jboss.org/browse/AGSMPLPUSH-54 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/4f433e51/attachment-0001.html From florian.schrofner at outlook.com Wed Apr 23 09:23:53 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Wed, 23 Apr 2014 15:23:53 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com>, <1398253280436.e1175469@Nodemailer>, <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com>, , <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> Message-ID: These are the server logs I have.. I'm not quite sure which ones you need, so I've added them all.Are attachments working on this mailing list? Cheers,Florian From: miguel21op at gmail.com Date: Wed, 23 Apr 2014 13:26:08 +0100 To: aerogear-dev at lists.jboss.org Subject: Re: [aerogear-dev] Problems sending notifications Cordova I think I understood... I hope you understand too what I'm trying to say: since I started with Aerogear some months ago I was warned about this situation. This is a recurring problem. Maybe there are already many logs reporting it... Anyway, as you may know, when I can I try to send all the information possible to track these kind of situations, bugs etc. to help your work. Now I just can't. Signing off ;-) M Enviado do meu iPhone No dia 23/04/2014, ?s 13:02, Matthias Wessendorf escreveu: On Wed, Apr 23, 2014 at 1:58 PM, Miguel Lemos wrote: No favor. I'm not near a PC.., As I told before, I've already sent a log related to a similar problem a month ago, I think. What Bruno and I tried to say:We do think that the UNDERLYING problem of this is NOT necessarily the same as it was in the past. As said, feel free to send the recent log, if you like Anyway: this is a recurring problem that deserves a deep attention, I think. Enviado do meu iPhone No dia 23/04/2014, ?s 12:41, "Bruno Oliveira" escreveu: Hi Miguel, if you make us a favor and send the logs next time, that would help a lot. Is hard to guess, because we don't have control over the OpenShift's infrastructure? abstractj On Wed, Apr 23, 2014 at 6:42 AM, Miguel Lemos wrote: I made a reset to OShift and it's working again. This is really an issue that one way or another should be solved... Enviado do meu iPhone No dia 23/04/2014, ?s 09:52, Matthias Wessendorf escreveu: One thing to have in mind: Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) @Android: is the app running? I think there are issues w/ the Android process has has been killed On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. But since it happens on iOS too this doesn't seem to be the matter.. Any other clues? _______________________________________________ aerogear-dev mailing list aerogear-dev at 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 _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev at 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 _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/f27ed605/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: aero-logs.zip Type: application/zip Size: 65394 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/f27ed605/attachment-0001.zip From matzew at apache.org Wed Apr 23 09:39:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Apr 2014 15:39:27 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> Message-ID: Florian, thanks a lot !! I extracted the interesting bits to: https://gist.github.com/matzew/11215509 So, there is a problem when issuing a send to Google (Due to some SSL error). I wonder if that's because of a change the applied for the heartbleed issue On Wed, Apr 23, 2014 at 3:23 PM, Florian Schrofner < florian.schrofner at outlook.com> wrote: > These are the server logs I have.. I'm not quite sure which ones you need, > so I've added them all. > Are attachments working on this mailing list? > > Cheers, > Florian > > ------------------------------ > From: miguel21op at gmail.com > Date: Wed, 23 Apr 2014 13:26:08 +0100 > To: aerogear-dev at lists.jboss.org > Subject: Re: [aerogear-dev] Problems sending notifications Cordova > > > I think I understood... > > I hope you understand too what I'm trying to say: since I started with > Aerogear some months ago I was warned about this situation. > > This is a recurring problem. Maybe there are already many logs reporting > it... > > Anyway, as you may know, when I can I try to send all the information > possible to track these kind of situations, bugs etc. to help your work. > > Now I just can't. > > Signing off ;-) > > M > > Enviado do meu iPhone > > No dia 23/04/2014, ?s 13:02, Matthias Wessendorf > escreveu: > > > > > On Wed, Apr 23, 2014 at 1:58 PM, Miguel Lemos wrote: > > No favor. I'm not near a PC.., > > As I told before, I've already sent a log related to a similar problem a > month ago, I think. > > > > What Bruno and I tried to say: > We do think that the UNDERLYING problem of this is NOT necessarily the > same as it was in the past. > > As said, feel free to send the recent log, if you like > > > > Anyway: this is a recurring problem that deserves a deep attention, I > think. > > Enviado do meu iPhone > > No dia 23/04/2014, ?s 12:41, "Bruno Oliveira" > escreveu: > > Hi Miguel, if you make us a favor and send the logs next time, that > would help a lot. > > Is hard to guess, because we don't have control over the OpenShift's > infrastructure > ? > abstractj > > > On Wed, Apr 23, 2014 at 6:42 AM, Miguel Lemos wrote: > > I made a reset to OShift and it's working again. > > This is really an issue that one way or another should be solved... > > Enviado do meu iPhone > > No dia 23/04/2014, ?s 09:52, Matthias Wessendorf > escreveu: > > One thing to have in mind: > > Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. > > Than, the next request does boot up the server. In theory that can mean, a > push might be missed, while still booting up the system. > See ? A metrics/Analytics view would give all that information :-) (e.g. > how many push were sent, and delivered to the 3rd party networks) > > > @Android: is the app running? I think there are issues w/ the Android > process has has been killed > > > > On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner < > florian.schrofner at outlook.com> wrote: > > I didn't mean that GCM failed.. just thought that GCM maybe decided to > block aerogear now or something like that. > But since it happens on iOS too this doesn't seem to be the matter.. > > Any other clues? > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/723220c4/attachment.html From daniel at passos.me Wed Apr 23 09:52:48 2014 From: daniel at passos.me (Daniel Passos) Date: Wed, 23 Apr 2014 10:52:48 -0300 Subject: [aerogear-dev] AeroGear Android Push 0.1 on staging Message-ID: Hi Folks, The android team started modularize[1] the android library. We started with push[2]. It was staged[3] on Nexus and tested using aerogear-push-helloworld[4]. You are probably anxious to test it, so go ahead! I plan release it on thursday. [1] https://issues.jboss.org/browse/AGDROID-236 [2] https://github.com/aerogear/aerogear-android-push [3] http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3087/ [4] https://github.com/aerogear/aerogear-push-helloworld ? Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/24a15672/attachment.html From edewit at redhat.com Wed Apr 23 09:56:44 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 23 Apr 2014 15:56:44 +0200 Subject: [aerogear-dev] contacts-mobile-basic quick start In-Reply-To: <5B19161A-39B3-4F60-9F89-722D16A1B513@gmail.com> References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com> <5B19161A-39B3-4F60-9F89-722D16A1B513@gmail.com> Message-ID: <8DBA0510-C8DE-4390-96A4-B0332DF72E69@redhat.com> Hi, How about merging the User model and the Contact into one entity? Seems like they have a lot in common, do we really need 2? Cheers, Erik Jan On 23 Apr,2014, at 14:34 , S?bastien Blanc wrote: > We should be using the email as alias and the email should also be used as login when registering in the secured part. A registration should also trigger the creation of that user / contact in the application. > Author can be left empty By the client and filled by the backend . https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_securedAuthor must stay because the receiver must know who sends the message. > > Envoy? de mon iPhone > >> Le 23 avr. 2014 ? 13:35, Erik Jan de Wit a ?crit : >> >> Hi, >> >> I was working on the aerogear-push-quickstarts for Cordova and was wondering what to put for the alias on registration. The version that is there now has users that logs in and contacts that are fetched. What seems to be missing is that everybody gets all contacts instead of just mine (maybe that is fine), but users that sign up for the app are not contacts. So when I want to send a message to a specific mobile user they are not in my list and there is no way to have to define an alias to send to. >> >> Also the interface for sending push notifications includes a author. I think it would be better if we remove this and let the service put in the logged in user. That way you can?t pretend to send a message like someone else. >> >> What do you think? >> >> Cheers, >> Erik Jan >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From qmx at qmx.me Wed Apr 23 09:57:01 2014 From: qmx at qmx.me (Douglas Campos) Date: Wed, 23 Apr 2014 10:57:01 -0300 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> Message-ID: <20140423135701.GN1275@rohan.local> Florian, This error is common when you're using a prerelease JDK, or one you have built yourself. What JDK version are you running? On Wed, Apr 23, 2014 at 03:23:53PM +0200, Florian Schrofner wrote: > These are the server logs I have.. I'm not quite sure which ones you need, so I've added them all.Are attachments working on this mailing list? > Cheers,Florian > > From: miguel21op at gmail.com > Date: Wed, 23 Apr 2014 13:26:08 +0100 > To: aerogear-dev at lists.jboss.org > Subject: Re: [aerogear-dev] Problems sending notifications Cordova > > I think I understood... > I hope you understand too what I'm trying to say: since I started with Aerogear some months ago I was warned about this situation. > This is a recurring problem. Maybe there are already many logs reporting it... > Anyway, as you may know, when I can I try to send all the information possible to track these kind of situations, bugs etc. to help your work. > Now I just can't. > Signing off ;-) > M > > Enviado do meu iPhone > No dia 23/04/2014, ?s 13:02, Matthias Wessendorf escreveu: > > > > > On Wed, Apr 23, 2014 at 1:58 PM, Miguel Lemos wrote: > > No favor. I'm not near a PC.., > As I told before, I've already sent a log related to a similar problem a month ago, I think. > > > What Bruno and I tried to say:We do think that the UNDERLYING problem of this is NOT necessarily the same as it was in the past. > As said, feel free to send the recent log, if you like > > Anyway: this is a recurring problem that deserves a deep attention, I think. > > > Enviado do meu iPhone > No dia 23/04/2014, ?s 12:41, "Bruno Oliveira" escreveu: > > > > Hi Miguel, if you make us a favor and send the logs next time, that would help a lot. > > Is hard to guess, because we don't have control over the OpenShift's infrastructure? > abstractj > > > On Wed, Apr 23, 2014 at 6:42 AM, Miguel Lemos wrote: > > > > I made a reset to OShift and it's working again. > > > This is really an issue that one way or another should be solved... > > Enviado do meu iPhone > > > No dia 23/04/2014, ?s 09:52, Matthias Wessendorf escreveu: > > > > One thing to have in mind: > > Openshift does a shutdown of the JBoss AS, after a 48 hours w/ no traffic. > > > Than, the next request does boot up the server. In theory that can mean, a push might be missed, while still booting up the system. > See ? A metrics/Analytics view would give all that information :-) (e.g. how many push were sent, and delivered to the 3rd party networks) > > > > > @Android: is the app running? I think there are issues w/ the Android process has has been killed > > > > > > > On Wed, Apr 23, 2014 at 10:45 AM, Florian Schrofner wrote: > > I didn't mean that GCM failed.. just thought that GCM maybe decided to block aerogear now or something like that. > > > > But since it happens on iOS too this doesn't seem to be the matter.. > > > Any other clues? > > > > _______________________________________________ > > aerogear-dev mailing list > aerogear-dev at 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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > > > aerogear-dev mailing list > > aerogear-dev at 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- qmx From bruno at abstractj.org Wed Apr 23 10:03:16 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 23 Apr 2014 11:03:16 -0300 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> Message-ID: <5357C824.7020802@abstractj.org> File a JIRA please: https://issues.jboss.org/browse/agpush Make sure to include: - Steps to reproduce - Your log file with the current problem - Java version Computer programming is a science, we can't just "guess". Thanks in advance. Matthias Wessendorf wrote: > I think I understood... > > I hope you understand too what I'm trying to say: since I started with Aerogear some months ago I was warned about this situation. > > This is a recurring problem. Maybe there are already many logs reporting it... > > Anyway, as you may know, when I can I try to send all the information possible to track these kind of situations, bugs etc. to help your work. > > Now I just can't. > > Signing off ;-) > > M -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/608d12b6/attachment.bin From bruno at abstractj.org Wed Apr 23 10:10:22 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 23 Apr 2014 11:10:22 -0300 Subject: [aerogear-dev] contacts-mobile-basic quick start In-Reply-To: <8DBA0510-C8DE-4390-96A4-B0332DF72E69@redhat.com> References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com> <5B19161A-39B3-4F60-9F89-722D16A1B513@gmail.com> <8DBA0510-C8DE-4390-96A4-B0332DF72E69@redhat.com> Message-ID: <5357C9CE.70402@abstractj.org> Makes sense. Erik Jan de Wit wrote: > Hi, > > How about merging the User model and the Contact into one entity? Seems like they have a lot in common, do we really need 2? -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/79ab10ff/attachment.bin From scm.blanc at gmail.com Wed Apr 23 10:16:14 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Wed, 23 Apr 2014 16:16:14 +0200 Subject: [aerogear-dev] contacts-mobile-basic quick start In-Reply-To: <8DBA0510-C8DE-4390-96A4-B0332DF72E69@redhat.com> References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com> <5B19161A-39B3-4F60-9F89-722D16A1B513@gmail.com> <8DBA0510-C8DE-4390-96A4-B0332DF72E69@redhat.com> Message-ID: Sure ! Be sure to check this with Joshua as he drives the backend bits S?bi Envoy? de mon iPhone > Le 23 avr. 2014 ? 15:56, Erik Jan de Wit a ?crit : > > Hi, > > How about merging the User model and the Contact into one entity? Seems like they have a lot in common, do we really need 2? > > Cheers, > Erik Jan > >> On 23 Apr,2014, at 14:34 , S?bastien Blanc wrote: >> >> We should be using the email as alias and the email should also be used as login when registering in the secured part. A registration should also trigger the creation of that user / contact in the application. >> Author can be left empty By the client and filled by the backend . https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_securedAuthor must stay because the receiver must know who sends the message. >> >> Envoy? de mon iPhone >> >>> Le 23 avr. 2014 ? 13:35, Erik Jan de Wit a ?crit : >>> >>> Hi, >>> >>> I was working on the aerogear-push-quickstarts for Cordova and was wondering what to put for the alias on registration. The version that is there now has users that logs in and contacts that are fetched. What seems to be missing is that everybody gets all contacts instead of just mine (maybe that is fine), but users that sign up for the app are not contacts. So when I want to send a message to a specific mobile user they are not in my list and there is no way to have to define an alias to send to. >>> >>> Also the interface for sending push notifications includes a author. I think it would be better if we remove this and let the service put in the logged in user. That way you can?t pretend to send a message like someone else. >>> >>> What do you think? >>> >>> Cheers, >>> Erik Jan >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bsutter at redhat.com Wed Apr 23 10:26:08 2014 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 23 Apr 2014 10:26:08 -0400 Subject: [aerogear-dev] contacts-mobile-basic quick start In-Reply-To: References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com> <5B19161A-39B3-4F60-9F89-722D16A1B513@gmail.com> <8DBA0510-C8DE-4390-96A4-B0332DF72E69@redhat.com> Message-ID: These are not strongly held opinions One reason to keep Users & Contacts separate is...because that is normal for the average enterprise app - your have employees (users) and customers (contacts) - employees/users have different roles/privileges from customers. The reason they are separated in the secured (PL) version of contacts-mobile-basic is because it simply evolved that way - contacts came first - users/roles added after the fact. Ideally we would not modify the original too much as it allows a nice learning progression - start with the original contacts-mobile-basic, then upgrade to contacts-mobile-basic-secured, then upgrade to contacts-mobile-basic-secured-cordova (names just made up). On Apr 23, 2014, at 10:16 AM, S?bastien Blanc wrote: > Sure ! > Be sure to check this with Joshua as he drives the backend bits > S?bi > > Envoy? de mon iPhone > >> Le 23 avr. 2014 ? 15:56, Erik Jan de Wit a ?crit : >> >> Hi, >> >> How about merging the User model and the Contact into one entity? Seems like they have a lot in common, do we really need 2? >> >> Cheers, >> Erik Jan >> >>> On 23 Apr,2014, at 14:34 , S?bastien Blanc wrote: >>> >>> We should be using the email as alias and the email should also be used as login when registering in the secured part. A registration should also trigger the creation of that user / contact in the application. >>> Author can be left empty By the client and filled by the backend . https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_securedAuthor must stay because the receiver must know who sends the message. >>> >>> Envoy? de mon iPhone >>> >>>> Le 23 avr. 2014 ? 13:35, Erik Jan de Wit a ?crit : >>>> >>>> Hi, >>>> >>>> I was working on the aerogear-push-quickstarts for Cordova and was wondering what to put for the alias on registration. The version that is there now has users that logs in and contacts that are fetched. What seems to be missing is that everybody gets all contacts instead of just mine (maybe that is fine), but users that sign up for the app are not contacts. So when I want to send a message to a specific mobile user they are not in my list and there is no way to have to define an alias to send to. >>>> >>>> Also the interface for sending push notifications includes a author. I think it would be better if we remove this and let the service put in the logged in user. That way you can?t pretend to send a message like someone else. >>>> >>>> What do you think? >>>> >>>> Cheers, >>>> Erik Jan >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Wed Apr 23 10:28:47 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 23 Apr 2014 11:28:47 -0300 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <20140423135701.GN1275@rohan.local> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> Message-ID: <5357CE1F.7040801@abstractj.org> Florian , In addition could you please let us know if you are running aerogear-unifiedpush-java-client with the latest changes from (https://github.com/aerogear/aerogear-unifiedpush-java-client/commit/38c0ceb678044306ef2403f7d33a29804a3a3fb9)? Douglas Campos wrote: > Florian, > > This error is common when you're using a prerelease JDK, or one you have > built yourself. > > What JDK version are you running? -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/2f1c59b8/attachment.bin From edewit at redhat.com Wed Apr 23 10:43:25 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 23 Apr 2014 16:43:25 +0200 Subject: [aerogear-dev] contacts-mobile-basic quick start In-Reply-To: References: <33FAC87C-F08E-4C86-842F-7A3F7D107D45@redhat.com> <5B19161A-39B3-4F60-9F89-722D16A1B513@gmail.com> <8DBA0510-C8DE-4390-96A4-B0332DF72E69@redhat.com> Message-ID: <1961051A-24C4-4A8F-98FA-F5667B139810@redhat.com> Right, that makes sense, so let?s not join them. The alternate thing to do is to create a contact on sign up, because if you want to receive push notifications at least you should be in the list of contacts. We will still need to change the sign up page a little as we need a phone number and a birth date as well in order to create a contact. On 23 Apr,2014, at 16:26 , Burr Sutter wrote: > These are not strongly held opinions > > One reason to keep Users & Contacts separate is...because that is normal for the average enterprise app - your have employees (users) and customers (contacts) - employees/users have different roles/privileges from customers. > > The reason they are separated in the secured (PL) version of contacts-mobile-basic is because it simply evolved that way - contacts came first - users/roles added after the fact. Ideally we would not modify the original too much as it allows a nice learning progression - start with the original contacts-mobile-basic, then upgrade to contacts-mobile-basic-secured, then upgrade to contacts-mobile-basic-secured-cordova (names just made up). > > > On Apr 23, 2014, at 10:16 AM, S?bastien Blanc wrote: > >> Sure ! >> Be sure to check this with Joshua as he drives the backend bits >> S?bi >> >> Envoy? de mon iPhone >> >>> Le 23 avr. 2014 ? 15:56, Erik Jan de Wit a ?crit : >>> >>> Hi, >>> >>> How about merging the User model and the Contact into one entity? Seems like they have a lot in common, do we really need 2? >>> >>> Cheers, >>> Erik Jan >>> >>>> On 23 Apr,2014, at 14:34 , S?bastien Blanc wrote: >>>> >>>> We should be using the email as alias and the email should also be used as login when registering in the secured part. A registration should also trigger the creation of that user / contact in the application. >>>> Author can be left empty By the client and filled by the backend . https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_securedAuthor must stay because the receiver must know who sends the message. >>>> >>>> Envoy? de mon iPhone >>>> >>>>> Le 23 avr. 2014 ? 13:35, Erik Jan de Wit a ?crit : >>>>> >>>>> Hi, >>>>> >>>>> I was working on the aerogear-push-quickstarts for Cordova and was wondering what to put for the alias on registration. The version that is there now has users that logs in and contacts that are fetched. What seems to be missing is that everybody gets all contacts instead of just mine (maybe that is fine), but users that sign up for the app are not contacts. So when I want to send a message to a specific mobile user they are not in my list and there is no way to have to define an alias to send to. >>>>> >>>>> Also the interface for sending push notifications includes a author. I think it would be better if we remove this and let the service put in the logged in user. That way you can?t pretend to send a message like someone else. >>>>> >>>>> What do you think? >>>>> >>>>> Cheers, >>>>> Erik Jan >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bsutter at redhat.com Wed Apr 23 12:24:13 2014 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 23 Apr 2014 12:24:13 -0400 Subject: [aerogear-dev] PhoneGap Developer App In-Reply-To: References: <691679B2-3819-496B-8AEB-1F932AAA2E55@gmail.com> <2EB10686-E86F-42C0-96F4-F67184DA65F9@redhat.com> Message-ID: <2A5BA99C-8192-4F92-8BD4-E5A24F193986@redhat.com> Yes - for Android and iOS variations should be pushed through the store - sometimes Apple blocks apps that "download their UI/logic" but other tooling vendors have provided these types of apps- so there must be a way through the system. On Apr 22, 2014, at 1:01 PM, Gorkem Ercan wrote: > > Cordova project already has an app [1]. Of course it does not work for plugins that have native parts. > > I think we need to take this app, bundle our plugins. Also for best results on iOS we may actually need to put it to the store. > > [1] https://github.com/apache/cordova-app-harness > > -- > Gorkem > > On Tuesday, April 22, 2014, Burr Sutter wrote: > Can you craft a jira for the idea and get it on the roadmap? Other Cordova/Phonegap tool vendors have had something similar for a while, so it is not a new idea. > > After all, we are just dealing with HTML/JS/CSS assets in most cases, should be relatively easy to 'republish' and with our LiveReload feature, it could be even more seamless. > > On Apr 22, 2014, at 2:44 AM, Erik Jan de Wit wrote: > >> Yeah saw that, it?s a simple yet brilliant idea (wish i would have thought of that) we could make something similar with our plugins preinstalled as well. And maybe even make it even simpler as JBDS could instruct the app to load the right page. >> >> On 19 Apr,2014, at 16:01 , Kris Borchers wrote: >> >>> I thought this might interest the tools folks. Use an app for testing Phonegap apps without certs, provisioning, etc. >>> >>> app.phonegap.com/?utm_content=bufferdfee5&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/2d5f1639/attachment-0001.html From florian.schrofner at outlook.com Wed Apr 23 13:41:35 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Wed, 23 Apr 2014 10:41:35 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <5357CE1F.7040801@abstractj.org> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <5357CE1F.7040801@abstractj.org> Message-ID: <1398274895597-7557.post@n5.nabble.com> I don't know which JDK version the OpenShift server is using.. I just used their pre-built aerogear cartridge. (or do you really mean my JDK? That would be OpenJDK 7.u55_2.4.7-1) Nope, I didn't run the new Java client.. mine was commit "c46b0618ca5602b3cfa74880c393c3e4497b934b". But I also tried using the Node.js client, which didn't work either.. Do you think the client crashed the server? -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7557.html Sent from the aerogear-dev mailing list archive at Nabble.com. From florian.schrofner at outlook.com Wed Apr 23 13:51:02 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Wed, 23 Apr 2014 10:51:02 -0700 (PDT) Subject: [aerogear-dev] Allow Push Without Master-Secret? In-Reply-To: References: <1397652808858-7474.post@n5.nabble.com> <1397760270058-7491.post@n5.nabble.com> <344704EA-04A4-4498-92AA-27D27F1D6B02@gmail.com> <1397763342415-7493.post@n5.nabble.com> Message-ID: <1398275462210-7558.post@n5.nabble.com> Thanks for your link! The broker seems way easier than I thought.. We're going to use the broker, your argumentation convinced us ;) You mentioned a MasterID.. how do I get to know what my MasterID is (in order to block it on the broker)? I thought it's just alias or no alias (=broadcast).. Cheers, Florian -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Allow-Push-Without-Master-Secret-tp7474p7558.html Sent from the aerogear-dev mailing list archive at Nabble.com. From bruno at abstractj.org Wed Apr 23 14:54:10 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 23 Apr 2014 15:54:10 -0300 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <1398274895597-7557.post@n5.nabble.com> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <5357CE1F.7040801@abstractj.org> <1398274895597-7557.post@n5.nabble.com> Message-ID: <53580C52.4070903@abstractj.org> We are still investigating, is too soon to confirm. Thanks a lot for your input. Florian Schrofner wrote: > I don't know which JDK version the OpenShift server is using.. I just used > their pre-built aerogear cartridge. (or do you really mean my JDK? That > would be OpenJDK 7.u55_2.4.7-1) > > Nope, I didn't run the new Java client.. mine was commit > "c46b0618ca5602b3cfa74880c393c3e4497b934b". > > But I also tried using the Node.js client, which didn't work either.. > > Do you think the client crashed the server? -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/2ff33043/attachment.bin From ken at kenfinnigan.me Wed Apr 23 15:10:10 2014 From: ken at kenfinnigan.me (Ken Finnigan) Date: Wed, 23 Apr 2014 15:10:10 -0400 Subject: [aerogear-dev] SIMPLE Analytics / Metrics for the UnifiedPush Server In-Reply-To: References: Message-ID: Would you be able to use the RHQ metrics module for this? Or does it need to be something custom? Ken On Tue, Apr 22, 2014 at 6:57 AM, Matthias Wessendorf wrote: > Hello, > > second try - as the first thread was hijacked around other discussions. > > For a first round of collecting some more data around the usage of the > push server (aka analytics/metrics), I'd propose we keep it very simple! > > Overall, I see one major area of interest: > *metrics around push messages being sent: > - time of sending (using timezone of the server?) > - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, > categories,...)) > - payload (the entire payload, including custom keys - not only alert, > sound, badge etc) > - info on: "could we deliver to the 3rd party networks?" > > > This is a nice feature, and would enrich the UPS. The server will have a > RESTful endpoint, and an UI for displaying the data. The view would be > bascially a history for all the push sent (per "Push Application" > construct). > > > However, I can see also some interest around device specific metrics: > > Today we obivously store all the registered devices, but we also remove > them from the database table if needed (to not send messages to phones that > would no longer receive them anyways). > > Something that would be interesting as well, might be the following data: > - how often was an app has reached the push server (note: every time the > app starts, the metadata of the server is being updated (see [2]) > - number of device-tokens / registrationIDs that have been removed, when > receiving errors from Apple/Google (see [3] or [4]) > - number of devices, that were activly removed using our APIs (supported > only on Android/SimplePush due to Apple policy, see [5]) > > > While the initial focus should be around the message related metrics, > capturing some device data is nice too. > > > Any thoughts ? > > -Matthias > > > PS: Oh, for the longer run(...), I'd also like to see metrics like "was > mobile app opened due to a push notification". BUT that also requires some > more work/reseach on the client Push SDKs. But seriously, this is not a > priority for the next few months! > > > > > [1] https://issues.jboss.org/browse/AGPUSH-116 > [2] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 > [3] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 > [4] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 > [5] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 > > > > > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/520954d9/attachment.html From bruno at abstractj.org Wed Apr 23 15:55:04 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 23 Apr 2014 16:55:04 -0300 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <20140423135701.GN1275@rohan.local> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> Message-ID: <53581A98.9080702@abstractj.org> Qmx, this is the version running on OpenShift: [aerogear-abstractj.rhcloud.com]\> java -version java version "1.7.0_55" OpenJDK Runtime Environment (rhel-2.4.7.1.el6_5-i386 u55-b13) OpenJDK Server VM (build 24.51-b03, mixed mode) Today OpenShift was under maintenance and I also found this http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003479.html. Running the command below: [aerogear-abstractj.rhcloud.com]\> keytool -list keytool error: java.lang.Exception: Keystore file does not exist: /var/lib/openshift/ae84d000ae0/.keystore Might be a clue, but requires more investigation. Florian, would you mind to try with a fresh instance of UPS? Douglas Campos wrote: > Florian, > > This error is common when you're using a prerelease JDK, or one you have > built yourself. > > What JDK version are you running? -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140423/637f2896/attachment.bin From matzew at apache.org Thu Apr 24 01:12:36 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Apr 2014 07:12:36 +0200 Subject: [aerogear-dev] Allow Push Without Master-Secret? In-Reply-To: <1398275462210-7558.post@n5.nabble.com> References: <1397652808858-7474.post@n5.nabble.com> <1397760270058-7491.post@n5.nabble.com> <344704EA-04A4-4498-92AA-27D27F1D6B02@gmail.com> <1397763342415-7493.post@n5.nabble.com> <1398275462210-7558.post@n5.nabble.com> Message-ID: On Wed, Apr 23, 2014 at 7:51 PM, Florian Schrofner < florian.schrofner at outlook.com> wrote: > Thanks for your link! > The broker seems way easier than I thought.. > We're going to use the broker, your argumentation convinced us ;) > > You mentioned a MasterID.. how do I get to know what my MasterID is (in > order to block it on the broker)? > he meant the MasterSecret and PushApplicationID combination - that's required to send out push messages > I thought it's just alias or no alias (=broadcast).. > yes: no criteria (e.g. alias, categories or specific variant IDs) -> broadcast > > Cheers, > Florian > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Allow-Push-Without-Master-Secret-tp7474p7558.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140424/55e32a07/attachment-0001.html From matzew at apache.org Thu Apr 24 01:13:32 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Apr 2014 07:13:32 +0200 Subject: [aerogear-dev] SIMPLE Analytics / Metrics for the UnifiedPush Server In-Reply-To: References: Message-ID: On Wed, Apr 23, 2014 at 9:10 PM, Ken Finnigan wrote: > Would you be able to use the RHQ metrics module for this? > I talked to Heiko about this; my understanding was it's not yet factored out into something that is re-usable. But the long-term goal is using their bits > > Or does it need to be something custom? > > Ken > > > On Tue, Apr 22, 2014 at 6:57 AM, Matthias Wessendorf wrote: > >> Hello, >> >> second try - as the first thread was hijacked around other discussions. >> >> For a first round of collecting some more data around the usage of the >> push server (aka analytics/metrics), I'd propose we keep it very simple! >> >> Overall, I see one major area of interest: >> *metrics around push messages being sent: >> - time of sending (using timezone of the server?) >> - group of receivers (e.g. everyone or the provided cirterias(e.g. alias, >> categories,...)) >> - payload (the entire payload, including custom keys - not only alert, >> sound, badge etc) >> - info on: "could we deliver to the 3rd party networks?" >> >> >> This is a nice feature, and would enrich the UPS. The server will have a >> RESTful endpoint, and an UI for displaying the data. The view would be >> bascially a history for all the push sent (per "Push Application" >> construct). >> >> >> However, I can see also some interest around device specific metrics: >> >> Today we obivously store all the registered devices, but we also remove >> them from the database table if needed (to not send messages to phones that >> would no longer receive them anyways). >> >> Something that would be interesting as well, might be the following data: >> - how often was an app has reached the push server (note: every time the >> app starts, the metadata of the server is being updated (see [2]) >> - number of device-tokens / registrationIDs that have been removed, when >> receiving errors from Apple/Google (see [3] or [4]) >> - number of devices, that were activly removed using our APIs (supported >> only on Android/SimplePush due to Apple policy, see [5]) >> >> >> While the initial focus should be around the message related metrics, >> capturing some device data is nice too. >> >> >> Any thoughts ? >> >> -Matthias >> >> >> PS: Oh, for the longer run(...), I'd also like to see metrics like "was >> mobile app opened due to a push notification". BUT that also requires some >> more work/reseach on the client Push SDKs. But seriously, this is not a >> priority for the next few months! >> >> >> >> >> [1] https://issues.jboss.org/browse/AGPUSH-116 >> [2] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L98-L112 >> [3] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L87-L94 >> [4] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L93-L94 >> [5] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L117-L119 >> >> >> >> >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140424/d237e8a9/attachment.html From edewit at redhat.com Thu Apr 24 02:39:05 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 24 Apr 2014 08:39:05 +0200 Subject: [aerogear-dev] PhoneGap Developer App In-Reply-To: <2A5BA99C-8192-4F92-8BD4-E5A24F193986@redhat.com> References: <691679B2-3819-496B-8AEB-1F932AAA2E55@gmail.com> <2EB10686-E86F-42C0-96F4-F67184DA65F9@redhat.com> <2A5BA99C-8192-4F92-8BD4-E5A24F193986@redhat.com> Message-ID: <4741C3FB-90E9-491E-8044-75A1B85AA226@redhat.com> Created an issue for it? https://issues.jboss.org/browse/AEROGEAR-1467 On 23 Apr,2014, at 18:24 , Burr Sutter wrote: > Yes - for Android and iOS variations should be pushed through the store - sometimes Apple blocks apps that "download their UI/logic" but other tooling vendors have provided these types of apps- so there must be a way through the system. > > > On Apr 22, 2014, at 1:01 PM, Gorkem Ercan wrote: > >> >> Cordova project already has an app [1]. Of course it does not work for plugins that have native parts. >> >> I think we need to take this app, bundle our plugins. Also for best results on iOS we may actually need to put it to the store. >> >> [1] https://github.com/apache/cordova-app-harness >> >> -- >> Gorkem >> >> On Tuesday, April 22, 2014, Burr Sutter wrote: >> Can you craft a jira for the idea and get it on the roadmap? Other Cordova/Phonegap tool vendors have had something similar for a while, so it is not a new idea. >> >> After all, we are just dealing with HTML/JS/CSS assets in most cases, should be relatively easy to 'republish' and with our LiveReload feature, it could be even more seamless. >> >> On Apr 22, 2014, at 2:44 AM, Erik Jan de Wit wrote: >> >>> Yeah saw that, it?s a simple yet brilliant idea (wish i would have thought of that) we could make something similar with our plugins preinstalled as well. And maybe even make it even simpler as JBDS could instruct the app to load the right page. >>> >>> On 19 Apr,2014, at 16:01 , Kris Borchers wrote: >>> >>>> I thought this might interest the tools folks. Use an app for testing Phonegap apps without certs, provisioning, etc. >>>> >>>> app.phonegap.com/?utm_content=bufferdfee5&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140424/11ab7680/attachment.html From matzew at apache.org Thu Apr 24 04:10:11 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Apr 2014 10:10:11 +0200 Subject: [aerogear-dev] AeroGear Android Push 0.1 on staging In-Reply-To: References: Message-ID: +1 on releasing - I have tested it the staged library with the HelloWorld android app On Wed, Apr 23, 2014 at 3:52 PM, Daniel Passos wrote: > Hi Folks, > > The android team started modularize[1] the android library. > > We started with push[2]. It was staged[3] on Nexus and tested using > aerogear-push-helloworld[4]. > > You are probably anxious to test it, so go ahead! > > I plan release it on thursday. > > [1] https://issues.jboss.org/browse/AGDROID-236 > [2] https://github.com/aerogear/aerogear-android-push > [3] > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3087/ > [4] https://github.com/aerogear/aerogear-push-helloworld > > ? Passos > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140424/2b716fbb/attachment.html From florian.schrofner at outlook.com Thu Apr 24 05:51:02 2014 From: florian.schrofner at outlook.com (Florian Schrofner) Date: Thu, 24 Apr 2014 02:51:02 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <53581A98.9080702@abstractj.org> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <53581A98.9080702@abstractj.org> Message-ID: <1398333062008-7566.post@n5.nabble.com> No, I don't mind at all.. Should I just set up a new UPS cartridge and test if the server crashes again, or should I check for the keystore? By the way there really seem to be some problems concerning Google Cloud Messaging itself.. I didn't receive any other push notifications today (except from an Asian messenger my girlfriend made me use, I assume it doesn't use GCM in order to address the Chinese market). Suddenly all notifications (including the aerogear notifications) arrived and my phone started going nuts. So maybe it isn't your fault after all.. Also I don't think it's only my phone, because my colleague also didn't receive any aerogear notifications the day before yesterday (although he had no problems with it today) until I restarted the server. Maybe GCM made the UPS server crash, because it had some problems/unexpected behaviour? -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7566.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Thu Apr 24 05:59:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Apr 2014 11:59:39 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <1398333062008-7566.post@n5.nabble.com> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <53581A98.9080702@abstractj.org> <1398333062008-7566.post@n5.nabble.com> Message-ID: On Thu, Apr 24, 2014 at 11:51 AM, Florian Schrofner < florian.schrofner at outlook.com> wrote: > No, I don't mind at all.. > > Should I just set up a new UPS cartridge and test if the server crashes > again, or should I check for the keystore? > yeah, just spin up a new instance, via the OpenShift UI (using our cartridge there) > > By the way there really seem to be some problems concerning Google Cloud > Messaging itself.. I didn't receive any other push notifications today > (except from an Asian messenger my girlfriend made me use, :-) > I assume it > doesn't use GCM in order to address the Chinese market). Suddenly all > notifications (including the aerogear notifications) arrived and my phone > started going nuts. > > So maybe it isn't your fault after all.. > > Also I don't think it's only my phone, because my colleague also didn't > receive any aerogear notifications the day before yesterday (although he > had > no problems with it today) until I restarted the server. > Maybe GCM made the UPS server crash, because it had some > problems/unexpected > behaviour? > I have added a JIRA to be a bit more lenient: https://issues.jboss.org/browse/AGPUSH-624 > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7566.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140424/cf5dfdd9/attachment.html From edewit at redhat.com Thu Apr 24 06:23:25 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 24 Apr 2014 12:23:25 +0200 Subject: [aerogear-dev] cordova angular quick start demo Message-ID: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> Hi, I was wondering about the Angular version for the quick start demo. I really like the ionic framework and it?s a good combination of Angular together with Cordova plus it has some nice UI widgets as well. Should we use this for our demo or should we stick to plain Angular with topcoat or bootstrap as a UI? What do you think, Cheers, Erik Jan From scm.blanc at gmail.com Thu Apr 24 06:27:44 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Thu, 24 Apr 2014 12:27:44 +0200 Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> Message-ID: <091167A3-4FC3-408F-A33D-A21CCC16E98C@gmail.com> I would love to see a version using ionic but keep in mind the angular version is secondary and we should first put all the effort into the jqm version Envoy? de mon iPhone > Le 24 avr. 2014 ? 12:23, Erik Jan de Wit a ?crit : > > Hi, > > I was wondering about the Angular version for the quick start demo. I really like the ionic framework and it?s a good combination of Angular together with Cordova plus it has some nice UI widgets as well. Should we use this for our demo or should we stick to plain Angular with topcoat or bootstrap as a UI? > > What do you think, > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Apr 24 06:36:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Apr 2014 12:36:43 +0200 Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <091167A3-4FC3-408F-A33D-A21CCC16E98C@gmail.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> <091167A3-4FC3-408F-A33D-A21CCC16E98C@gmail.com> Message-ID: we have to have an Angular version On Thu, Apr 24, 2014 at 12:27 PM, S?bastien Blanc wrote: > I would love to see a version using ionic but keep in mind the angular > version is secondary and we should first put all the effort into the jqm > version > > Envoy? de mon iPhone > > > Le 24 avr. 2014 ? 12:23, Erik Jan de Wit a ?crit : > > > > Hi, > > > > I was wondering about the Angular version for the quick start demo. I > really like the ionic framework and it?s a good combination of Angular > together with Cordova plus it has some nice UI widgets as well. Should we > use this for our demo or should we stick to plain Angular with topcoat or > bootstrap as a UI? > > > > What do you think, > > > > Cheers, > > Erik Jan > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140424/c718ca43/attachment.html From bsutter at redhat.com Thu Apr 24 08:23:51 2014 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 24 Apr 2014 08:23:51 -0400 Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> Message-ID: <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> Do you have time for all 4 options: Angular, Angular+Topcoat, Angular+bootstrap, Angular+Ionic? That would give you an awesome compare & contrast set that would make a great blog series :-) On Apr 24, 2014, at 6:23 AM, Erik Jan de Wit wrote: > Hi, > > I was wondering about the Angular version for the quick start demo. I really like the ionic framework and it?s a good combination of Angular together with Cordova plus it has some nice UI widgets as well. Should we use this for our demo or should we stick to plain Angular with topcoat or bootstrap as a UI? > > What do you think, > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Apr 24 08:49:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Apr 2014 14:49:57 +0200 Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> Message-ID: I'd say we have time for Angular+ionic, or vanilla Angualr; I mean just one version. We still have an UI overhaul ahead On Thu, Apr 24, 2014 at 2:23 PM, Burr Sutter wrote: > Do you have time for all 4 options: Angular, Angular+Topcoat, > Angular+bootstrap, Angular+Ionic? > > That would give you an awesome compare & contrast set that would make a > great blog series :-) > > On Apr 24, 2014, at 6:23 AM, Erik Jan de Wit wrote: > > > Hi, > > > > I was wondering about the Angular version for the quick start demo. I > really like the ionic framework and it?s a good combination of Angular > together with Cordova plus it has some nice UI widgets as well. Should we > use this for our demo or should we stick to plain Angular with topcoat or > bootstrap as a UI? > > > > What do you think, > > > > Cheers, > > Erik Jan > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140424/ea5aec6d/attachment.html From jbalunas at redhat.com Thu Apr 24 08:50:50 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Thu, 24 Apr 2014 08:50:50 -0400 Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> Message-ID: <1D82326B-4F90-4469-B5C4-617E9E2F097F@redhat.com> On Apr 24, 2014, at 8:23 AM, Burr Sutter wrote: > Do you have time for all 4 options: Angular, Angular+Topcoat, Angular+bootstrap, Angular+Ionic? Really! I don't think we have time for that - at least not now.... > > That would give you an awesome compare & contrast set that would make a great blog series :-) Lets get jira's in for tracking, but we need to pick our priorities. > > On Apr 24, 2014, at 6:23 AM, Erik Jan de Wit wrote: > >> Hi, >> >> I was wondering about the Angular version for the quick start demo. I really like the ionic framework and it?s a good combination of Angular together with Cordova plus it has some nice UI widgets as well. Should we use this for our demo or should we stick to plain Angular with topcoat or bootstrap as a UI? >> >> What do you think, >> >> Cheers, >> Erik Jan >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Thu Apr 24 09:13:27 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 24 Apr 2014 09:13:27 -0400 Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <1D82326B-4F90-4469-B5C4-617E9E2F097F@redhat.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> <1D82326B-4F90-4469-B5C4-617E9E2F097F@redhat.com> Message-ID: <409B6E7D-BD13-487E-ABE3-EC40D66DAB40@redhat.com> On Apr 24, 2014, at 8:50 AM, Jay Balunas wrote: > > On Apr 24, 2014, at 8:23 AM, Burr Sutter wrote: > >> Do you have time for all 4 options: Angular, Angular+Topcoat, Angular+bootstrap, Angular+Ionic? > > Really! I don't think we have time for that - at least not now?. http://territrespicio.com/wp-content/uploads/2013/07/Sweet-Brown.png > >> >> That would give you an awesome compare & contrast set that would make a great blog series :-) > > Lets get jira's in for tracking, but we need to pick our priorities. > >> >> On Apr 24, 2014, at 6:23 AM, Erik Jan de Wit wrote: >> >>> Hi, >>> >>> I was wondering about the Angular version for the quick start demo. I really like the ionic framework and it?s a good combination of Angular together with Cordova plus it has some nice UI widgets as well. Should we use this for our demo or should we stick to plain Angular with topcoat or bootstrap as a UI? >>> >>> What do you think, >>> >>> Cheers, >>> Erik Jan >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140424/d27c39bd/attachment.html From bruno at abstractj.org Thu Apr 24 11:16:46 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 24 Apr 2014 12:16:46 -0300 Subject: [aerogear-dev] AeroGear Android Push 0.1 on staging In-Reply-To: References: Message-ID: <53592ADE.8020607@abstractj.org> Ship it! Daniel Passos wrote: > Hi Folks, > > The android team started modularize[1] the android library. > > We started with push[2]. It was staged[3] on Nexus and tested using > aerogear-push-helloworld[4]. > > You are probably anxious to test it, so go ahead! > > I plan release it on thursday. -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140424/b0f0b3ac/attachment.bin From supittma at redhat.com Thu Apr 24 14:25:06 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 24 Apr 2014 14:25:06 -0400 Subject: [aerogear-dev] Android OAuth2 PR Message-ID: <53595702.90900@redhat.com> https://github.com/aerogear/aerogear-android/pull/146 This PR is 1) big and 2) incomplete (https://issues.jboss.org/browse/AGDROID/component/12319553). However, it represents a certain set of functionality and I want to get feedback/cleanup/merge before I continue making it even bigger. I would be EXCITED if someone can review this monster. If it needs to be cut up and submitted piecemeal to make it more digestible I will also take feedback on how to do that. Summers -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From antoine.matyja at worldline.com Fri Apr 25 09:11:49 2014 From: antoine.matyja at worldline.com (A577127) Date: Fri, 25 Apr 2014 06:11:49 -0700 (PDT) Subject: [aerogear-dev] Proxy settings questions Message-ID: <1398431509586-7577.post@n5.nabble.com> Hello, I'm intending to implement the proxy settings for the UPS. However it's not really clear to me how different type of proxies work and what are the different possible configurations. I looked at these mockups : https://issues.jboss.org/secure/attachment/12380178/proxy-config.png And from what I saw, it looks like you only have one global proxy to set. Should it be possible to configure several proxies (like a HTTP proxy for GCM/SimplePush and a SOCKS proxy for APNS) ? At the company I work for, they only have an HTTP proxy. Sending push notifications to the APNS is still possible thanks to a socket tunnel (which is already implemented in java-apns library by the way). But I guess some companies have also a SOCKS proxy. Moreover, since push notification only use HTTP(S) requests and TLS socket, how could a FTP proxy be used ? If you could clarify these points, that would help me a lot. Thanks, -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Proxy-settings-questions-tp7577.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Fri Apr 25 10:23:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Apr 2014 16:23:17 +0200 Subject: [aerogear-dev] Proxy settings questions In-Reply-To: <1398431509586-7577.post@n5.nabble.com> References: <1398431509586-7577.post@n5.nabble.com> Message-ID: On Fri, Apr 25, 2014 at 3:11 PM, A577127 wrote: > Hello, > > I'm intending to implement the proxy settings for the UPS. However it's not > really clear to me how different type of proxies work and what are the > different possible configurations. > > I looked at these mockups : > https://issues.jboss.org/secure/attachment/12380178/proxy-config.png > > And from what I saw, it looks like you only have one global proxy to set. > Should it be possible to configure several proxies (like a HTTP proxy for > GCM/SimplePush and a SOCKS proxy for APNS) ? > > At the company I work for, they only have an HTTP proxy. Sending push > notifications to the APNS is still possible thanks to a socket tunnel > (which > is already implemented in java-apns library by the way). But I guess some > companies have also a SOCKS proxy. > > Moreover, since push notification only use HTTP(S) requests and TLS socket, > how could a FTP proxy be used ? > yeah, we don't need that :-) I think I just pasted the generally allowed types in the java.net package :-) > > If you could clarify these points, that would help me a lot. > > Thanks, > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Proxy-settings-questions-tp7577.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140425/ed2d90cf/attachment.html From matzew at apache.org Fri Apr 25 10:23:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Apr 2014 16:23:45 +0200 Subject: [aerogear-dev] Proxy settings questions In-Reply-To: References: <1398431509586-7577.post@n5.nabble.com> Message-ID: btw. starting with (only) HTTP(s) is very much fine w/ me On Fri, Apr 25, 2014 at 4:23 PM, Matthias Wessendorf wrote: > > > > On Fri, Apr 25, 2014 at 3:11 PM, A577127 wrote: > >> Hello, >> >> I'm intending to implement the proxy settings for the UPS. However it's >> not >> really clear to me how different type of proxies work and what are the >> different possible configurations. >> >> I looked at these mockups : >> https://issues.jboss.org/secure/attachment/12380178/proxy-config.png >> >> And from what I saw, it looks like you only have one global proxy to set. >> Should it be possible to configure several proxies (like a HTTP proxy for >> GCM/SimplePush and a SOCKS proxy for APNS) ? >> >> At the company I work for, they only have an HTTP proxy. Sending push >> notifications to the APNS is still possible thanks to a socket tunnel >> (which >> is already implemented in java-apns library by the way). But I guess some >> companies have also a SOCKS proxy. >> >> Moreover, since push notification only use HTTP(S) requests and TLS >> socket, >> how could a FTP proxy be used ? >> > > yeah, we don't need that :-) > > I think I just pasted the generally allowed types in the java.net package > :-) > > > >> >> If you could clarify these points, that would help me a lot. >> >> Thanks, >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/Proxy-settings-questions-tp7577.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140425/c1d0755c/attachment-0001.html From bruno at abstractj.org Fri Apr 25 16:51:06 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Apr 2014 17:51:06 -0300 Subject: [aerogear-dev] Proxy settings questions In-Reply-To: References: <1398431509586-7577.post@n5.nabble.com> Message-ID: <20140425205106.GA36605@abstractj.org> +1 on it On 2014-04-25, Matthias Wessendorf wrote: > btw. starting with (only) HTTP(s) is very much fine w/ me > > > On Fri, Apr 25, 2014 at 4:23 PM, Matthias Wessendorf wrote: > > > > > > > > > On Fri, Apr 25, 2014 at 3:11 PM, A577127 wrote: > > > >> Hello, > >> > >> I'm intending to implement the proxy settings for the UPS. However it's > >> not > >> really clear to me how different type of proxies work and what are the > >> different possible configurations. > >> > >> I looked at these mockups : > >> https://issues.jboss.org/secure/attachment/12380178/proxy-config.png > >> > >> And from what I saw, it looks like you only have one global proxy to set. > >> Should it be possible to configure several proxies (like a HTTP proxy for > >> GCM/SimplePush and a SOCKS proxy for APNS) ? > >> > >> At the company I work for, they only have an HTTP proxy. Sending push > >> notifications to the APNS is still possible thanks to a socket tunnel > >> (which > >> is already implemented in java-apns library by the way). But I guess some > >> companies have also a SOCKS proxy. > >> > >> Moreover, since push notification only use HTTP(S) requests and TLS > >> socket, > >> how could a FTP proxy be used ? > >> > > > > yeah, we don't need that :-) > > > > I think I just pasted the generally allowed types in the java.net package > > :-) > > > > > > > >> > >> If you could clarify these points, that would help me a lot. > >> > >> Thanks, > >> > >> > >> > >> -- > >> View this message in context: > >> http://aerogear-dev.1069024.n5.nabble.com/Proxy-settings-questions-tp7577.html > >> Sent from the aerogear-dev mailing list archive at Nabble.com. > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From bruno at abstractj.org Fri Apr 25 17:37:55 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Apr 2014 18:37:55 -0300 Subject: [aerogear-dev] Android OAuth2 PR In-Reply-To: <53595702.90900@redhat.com> References: <53595702.90900@redhat.com> Message-ID: <20140425213755.GB36605@abstractj.org> Hi Summers, not sure about the timing. But I would like to review on the next week. On 2014-04-24, Summers Pittman wrote: > > https://github.com/aerogear/aerogear-android/pull/146 > > This PR is 1) big and 2) incomplete > (https://issues.jboss.org/browse/AGDROID/component/12319553). However, > it represents a certain set of functionality and I want to get > feedback/cleanup/merge before I continue making it even bigger. > > I would be EXCITED if someone can review this monster. If it needs to > be cut up and submitted piecemeal to make it more digestible I will also > take feedback on how to do that. > > Summers > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From keith at kdmooreconsulting.com Fri Apr 25 22:28:32 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Fri, 25 Apr 2014 19:28:32 -0700 (PDT) Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <409B6E7D-BD13-487E-ABE3-EC40D66DAB40@redhat.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> <1D82326B-4F90-4469-B5C4-617E9E2F097F@redhat.com> <409B6E7D-BD13-487E-ABE3-EC40D66DAB40@redhat.com> Message-ID: <1398479312724-7582.post@n5.nabble.com> I would be willing to create the ionic+angular quick start demo app. I have been using ionic+angular for the last few months for an app I am building for a client. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-cordova-angular-quick-start-demo-tp7568p7582.html Sent from the aerogear-dev mailing list archive at Nabble.com. From keith at kdmooreconsulting.com Sat Apr 26 01:30:53 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Fri, 25 Apr 2014 22:30:53 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <53581A98.9080702@abstractj.org> <1398333062008-7566.post@n5.nabble.com> Message-ID: <1398490253386-7583.post@n5.nabble.com> I started seeing issues on Friday. For devices that had previously registered, my push notifications were being received. However, when I started changing the alias on those devices, they no longer received push notifications. I am running aerogear-push 0.9 on OpenShift. I restarted the server but the problem still exists. I noticed that I don't have a keystore file. I am using the curl method for sending push notifications on the command line from a mac. I guess I will do what I know one of you is going to suggest and that is to upgrade. I just wanted to let you guys know that it might not be your code. It might be an OpenShift issue, who knows. I don't have any error messages in the log. I even set the logging level to debug and still didnt get any more useful messages. I just see info messages relating the a client registering and a message when I send the push notification. I have both iOS and android devices. I made sure to send the push notification to just a single android device as well as a seperate push notification to send to an iOS device. Both devices had different aliases. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7583.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Sat Apr 26 01:52:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 26 Apr 2014 07:52:42 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <1398490253386-7583.post@n5.nabble.com> References: <1538A737-08B9-4883-8147-622EDA16DE5B@gmail.com> <1398253280436.e1175469@Nodemailer> <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <53581A98.9080702@abstractj.org> <1398333062008-7566.post@n5.nabble.com> <1398490253386-7583.post@n5.nabble.com> Message-ID: Hello Keith, On Sat, Apr 26, 2014 at 7:30 AM, keithdmoore94 wrote: > I started seeing issues on Friday. For devices that had previously > registered, my push notifications were being received. However, when I > started changing the alias on those devices, they no longer received push > notifications. But the 'new' alias shows up on the installations overview, per variant, right ? > I am running aerogear-push 0.9 on OpenShift. I restarted > the server but the problem still exists. I noticed that I don't have a > keystore file. I am using the curl method for sending push notifications > on > the command line from a mac. I guess I will do what I know one of you is > going to suggest and that is to upgrade. My suggestion would be not an upgrade, but I'd try to do an actual reboot of the machine (via the openshift console) > I just wanted to let you guys know > that it might not be your code. It might be an OpenShift issue, who knows. > I don't have any error messages in the log. I even set the logging level > to > debug and still didnt get any more useful messages. I just see info > messages relating the a client registering and a message when I send the > push notification. > That is weird, especially that there are no exceptions. I need to improve the logging there (e.g. sending to n devices) > > I have both iOS and android devices. I made sure to send the push > notification to just a single android device as well as a seperate push > notification to send to an iOS device. Both devices had different aliases. > Thanks for the detailed email, Keith ! > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7583.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140426/fa806e62/attachment.html From matzew at apache.org Sat Apr 26 01:54:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 26 Apr 2014 07:54:38 +0200 Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <1398479312724-7582.post@n5.nabble.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> <1D82326B-4F90-4469-B5C4-617E9E2F097F@redhat.com> <409B6E7D-BD13-487E-ABE3-EC40D66DAB40@redhat.com> <1398479312724-7582.post@n5.nabble.com> Message-ID: Hello Keith On Sat, Apr 26, 2014 at 4:28 AM, keithdmoore94 wrote: > I would be willing to create the ionic+angular quick start demo app. I > have > been using ionic+angular for the last few months for an app I am building > for a client. > Oh, that would be super cool if you are interested in helping to get an Angular+ionic version of our mobile contacts quickstart demo! Thanks for the offer! > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-cordova-angular-quick-start-demo-tp7568p7582.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140426/f9625188/attachment.html From scm.blanc at gmail.com Sat Apr 26 05:43:26 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Sat, 26 Apr 2014 11:43:26 +0200 Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> <1D82326B-4F90-4469-B5C4-617E9E2F097F@redhat.com> <409B6E7D-BD13-487E-ABE3-EC40D66DAB40@redhat.com> <1398479312724-7582.post@n5.nabble.com> Message-ID: <6FB1647F-1F18-4B42-A168-D807BB276D0C@gmail.com> Envoy? de mon iPhone > Le 26 avr. 2014 ? 07:54, Matthias Wessendorf a ?crit : > > Hello Keith > > >> On Sat, Apr 26, 2014 at 4:28 AM, keithdmoore94 wrote: >> I would be willing to create the ionic+angular quick start demo app. I have >> been using ionic+angular for the last few months for an app I am building >> for a client. > > > Oh, that would be super cool if you are interested in helping to get an Angular+ionic version of our mobile contacts quickstart demo! +9001 > > Thanks for the offer! > >> >> >> >> -- >> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-cordova-angular-quick-start-demo-tp7568p7582.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140426/23daa22e/attachment-0001.html From keith at kdmooreconsulting.com Sat Apr 26 17:24:26 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Sat, 26 Apr 2014 14:24:26 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: <02BC023F-AD8D-42A2-B4D9-006612DE7370@gmail.com> <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <53581A98.9080702@abstractj.org> <1398333062008-7566.post@n5.nabble.com> <1398490253386-7583.post@n5.nabble.com> Message-ID: <1398547466903-7587.post@n5.nabble.com> See comments below: On Sat, Apr 26, 2014 at 7:30 AM, keithdmoore94 <[hidden email]> wrote: I started seeing issues on Friday. For devices that had previously registered, my push notifications were being received. However, when I started changing the alias on those devices, they no longer received push notifications. But the 'new' alias shows up on the installations overview, per variant, right ? >>> Correct, the new alias shows up under the variant I am running aerogear-push 0.9 on OpenShift. I restarted the server but the problem still exists. I noticed that I don't have a keystore file. I am using the curl method for sending push notifications on the command line from a mac. I guess I will do what I know one of you is going to suggest and that is to upgrade. My suggestion would be not an upgrade, but I'd try to do an actual reboot of the machine (via the openshift console) >>> I tried this and didn't see any difference in behavior. I would like to >>> point out that with the logging level on debug, I did see where the >>> google library was posting to google cloud messaging. So it looks like >>> it is being sent out. Maybe they are blocking aerogear or open shift >>> posts ? I just wanted to let you guys know that it might not be your code. It might be an OpenShift issue, who knows. I don't have any error messages in the log. I even set the logging level to debug and still didnt get any more useful messages. I just see info messages relating the a client registering and a message when I send the push notification. That is weird, especially that there are no exceptions. I need to improve the logging there (e.g. sending to n devices) >> I did see a fair amount of logging in debug mode. The logging may be >> just fine. Seems as though google got the request but didn't send out >> the notification from some reason. I have both iOS and android devices. I made sure to send the push notification to just a single android device as well as a seperate push notification to send to an iOS device. Both devices had different aliases. Thanks for the detailed email, Keith ! >> No problem. I try. Not sure what else to try at this point. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7587.html Sent from the aerogear-dev mailing list archive at Nabble.com. From keith at kdmooreconsulting.com Sat Apr 26 18:09:20 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Sat, 26 Apr 2014 15:09:20 -0700 (PDT) Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <6FB1647F-1F18-4B42-A168-D807BB276D0C@gmail.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> <1D82326B-4F90-4469-B5C4-617E9E2F097F@redhat.com> <409B6E7D-BD13-487E-ABE3-EC40D66DAB40@redhat.com> <1398479312724-7582.post@n5.nabble.com> <6FB1647F-1F18-4B42-A168-D807BB276D0C@gmail.com> Message-ID: <1398550160919-7588.post@n5.nabble.com> Where can I find the "mobile contacts quickstart demo" you speak of ? On a side note, does anyone know how I can get the "mobile" import folder that has the "Import Cordova Project" option in Eclipse Kepler? I noticed some screenshots of it in the aerogear-push-helloworld-cordova readme page. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-cordova-angular-quick-start-demo-tp7568p7588.html Sent from the aerogear-dev mailing list archive at Nabble.com. From keith at kdmooreconsulting.com Sat Apr 26 19:19:31 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Sat, 26 Apr 2014 16:19:31 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <1398547466903-7587.post@n5.nabble.com> References: <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <53581A98.9080702@abstractj.org> <1398333062008-7566.post@n5.nabble.com> <1398490253386-7583.post@n5.nabble.com> <1398547466903-7587.post@n5.nabble.com> Message-ID: <1398554371318-7589.post@n5.nabble.com> I deployed my app to a virgin android device and the push notifications worked just fine. I also realized a co-worker had upgraded the cordova plugin. Maybe there is a problem with using a newer cordova plugin with an older push server (0.9)? I guess I will go ahead and bite the bullet and upgrade the server to 0.11. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7589.html Sent from the aerogear-dev mailing list archive at Nabble.com. From corinnekrych at gmail.com Sun Apr 27 02:55:22 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Sun, 27 Apr 2014 08:55:22 +0200 Subject: [aerogear-dev] Android OAuth2 PR In-Reply-To: <20140425213755.GB36605@abstractj.org> References: <53595702.90900@redhat.com> <20140425213755.GB36605@abstractj.org> Message-ID: Yep same here i'd love to review it an compare with iOS version. I'll send feedback next week too. ++ Corinne On Friday, April 25, 2014, Bruno Oliveira wrote: > Hi Summers, not sure about the timing. But I would like to review on the > next week. > > On 2014-04-24, Summers Pittman wrote: > > > > https://github.com/aerogear/aerogear-android/pull/146 > > > > This PR is 1) big and 2) incomplete > > (https://issues.jboss.org/browse/AGDROID/component/12319553). However, > > it represents a certain set of functionality and I want to get > > feedback/cleanup/merge before I continue making it even bigger. > > > > I would be EXCITED if someone can review this monster. If it needs to > > be cut up and submitted piecemeal to make it more digestible I will also > > take feedback on how to do that. > > > > Summers > > > > -- > > Summers Pittman > > >>Phone:404 941 4698 > > >>Java is my crack. > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140427/593943dd/attachment.html From edewit at redhat.com Sun Apr 27 08:57:36 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Sun, 27 Apr 2014 14:57:36 +0200 Subject: [aerogear-dev] cordova angular quick start demo In-Reply-To: <1398550160919-7588.post@n5.nabble.com> References: <2F5B8A91-F681-4B8A-9D59-EFEFF8CDEEC4@redhat.com> <3B072A76-B780-496B-97DB-B7ED0C217B91@redhat.com> <1D82326B-4F90-4469-B5C4-617E9E2F097F@redhat.com> <409B6E7D-BD13-487E-ABE3-EC40D66DAB40@redhat.com> <1398479312724-7582.post@n5.nabble.com> <6FB1647F-1F18-4B42-A168-D807BB276D0C@gmail.com> <1398550160919-7588.post@n5.nabble.com> Message-ID: Hi Keith, On 27 Apr,2014, at 0:09 , keithdmoore94 wrote: > Where can I find the "mobile contacts quickstart demo" you speak of ? On a That is part of the JBoss quick starts: https://github.com/jboss-developer/jboss-wfk-quickstarts/tree/2.6.x-develop/contacts-mobile-basic we use the one Sebastien made: https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_secured/contacts-mobile-basic > side note, does anyone know how I can get the "mobile" import folder that > has the "Import Cordova Project" option in Eclipse Kepler? I noticed some > screenshots of it in the aerogear-push-helloworld-cordova > > readme page. It?s part of the JBoss tools you can install it in eclipse as well: https://github.com/jbosstools/jbosstools-aerogear > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-cordova-angular-quick-start-demo-tp7568p7588.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140427/6be8cc73/attachment.html From keith at kdmooreconsulting.com Sun Apr 27 17:08:58 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Sun, 27 Apr 2014 14:08:58 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <1398554371318-7589.post@n5.nabble.com> References: <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <53581A98.9080702@abstractj.org> <1398333062008-7566.post@n5.nabble.com> <1398490253386-7583.post@n5.nabble.com> <1398547466903-7587.post@n5.nabble.com> <1398554371318-7589.post@n5.nabble.com> Message-ID: <1398632938043-7592.post@n5.nabble.com> Update: I managed to get both Android and iOS push notifications working again. I am using the latest aerogear cordova push plugin with a 0.9 aerogear server. Not sure exactly what the problems where. However, I suspect it might have something to do with the issue that Matthias put in a Jira ticket in for. I did find some issues with the Android version when the app is paused or not running. Seems to behave differently between Android 4.2.2 and 4.4. I am going to do some more testing and open Jira tickets as necessary. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7592.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Mon Apr 28 02:35:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Apr 2014 08:35:48 +0200 Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: <1398632938043-7592.post@n5.nabble.com> References: <4EF3DD80-A7B9-4052-8081-B876F2DCE47E@gmail.com> <20140423135701.GN1275@rohan.local> <53581A98.9080702@abstractj.org> <1398333062008-7566.post@n5.nabble.com> <1398490253386-7583.post@n5.nabble.com> <1398547466903-7587.post@n5.nabble.com> <1398554371318-7589.post@n5.nabble.com> <1398632938043-7592.post@n5.nabble.com> Message-ID: On Sun, Apr 27, 2014 at 11:08 PM, keithdmoore94 wrote: > Update: > > I managed to get both Android and iOS push notifications working again. I > am using the latest aerogear cordova push plugin with a 0.9 aerogear > server. > Not sure exactly what the problems where. However, I suspect it might have > something to do with the issue that Matthias put in a Jira ticket in for. Did you mean AGPUSH-624 ? > I > did find some issues with the Android version when the app is paused or not > running. Seems to behave differently between Android 4.2.2 and 4.4. I am > going to do some more testing and open Jira tickets as necessary. > perfect! Thanks for all the help, Keith! We really appreciate it! -M > > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7592.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140428/217b180b/attachment-0001.html From matzew at apache.org Mon Apr 28 02:46:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Apr 2014 08:46:44 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140428 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140428/0e0cb3e6/attachment.html From antoine.matyja at worldline.com Mon Apr 28 08:57:55 2014 From: antoine.matyja at worldline.com (A577127) Date: Mon, 28 Apr 2014 05:57:55 -0700 (PDT) Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> Message-ID: <1398689875828-7595.post@n5.nabble.com> Hey again, I'm trying to edit the user interface. I read the readme and successfully did the steps. I edited the local-config.json file and I can run grunt server and see the modifications on localhost:9000. First question, what are the login and password for testing ? I didn't find it in the readme or in the sources And then, how do you push it on your JBoss server ? Running grunt server modifies files on my server in jboss-eap/standalone/deployments/ag-push.war (and also in server/src/main/webapp), however even if I refresh the page/empty the browser's cache/disable & re-enable the war, it isn't updated in my browser. Thanks, -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7595.html Sent from the aerogear-dev mailing list archive at Nabble.com. From bruno at abstractj.org Mon Apr 28 09:08:21 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 28 Apr 2014 10:08:21 -0300 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1398689875828-7595.post@n5.nabble.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> Message-ID: <20140428130821.GA24149@abstractj.org> Hi Antonie, are you following the instructions here: https://github.com/aerogear/aerogear-unifiedpush-server >From our README: "Temporarily there is a "admin:123" user. On first login, you will need to change the password." I hope it helps. On 2014-04-28, A577127 wrote: > Hey again, > > I'm trying to edit the user interface. I read the readme and successfully > did the steps. I edited the local-config.json file and I can run grunt > server and see the modifications on localhost:9000. > > First question, what are the login and password for testing ? I didn't find > it in the readme or in the sources > > And then, how do you push it on your JBoss server ? Running grunt server > modifies files on my server in jboss-eap/standalone/deployments/ag-push.war > (and also in server/src/main/webapp), however even if I refresh the > page/empty the browser's cache/disable & re-enable the war, it isn't updated > in my browser. > > Thanks, > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7595.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From antoine.matyja at worldline.com Mon Apr 28 09:13:14 2014 From: antoine.matyja at worldline.com (A577127) Date: Mon, 28 Apr 2014 06:13:14 -0700 (PDT) Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <20140428130821.GA24149@abstractj.org> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <20140428130821.GA24149@abstractj.org> Message-ID: <1398690794033-7597.post@n5.nabble.com> Sorry for not providing the link, I try to edit the UI so I use this readme : https://github.com/aerogear/aerogear-unifiedpush-server/tree/master/admin-ui (admin:123 doesn't work here) -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7597.html Sent from the aerogear-dev mailing list archive at Nabble.com. From edewit at redhat.com Mon Apr 28 09:43:27 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 28 Apr 2014 15:43:27 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1398689875828-7595.post@n5.nabble.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> Message-ID: > > And then, how do you push it on your JBoss server ? Running grunt server > modifies files on my server in jboss-eap/standalone/deployments/ag-push.war > (and also in server/src/main/webapp), however even if I refresh the > page/empty the browser's cache/disable & re-enable the war, it isn't updated > in my browser. Grunt updates the html and javascript files in a exploded war file that is in your jboss folder. So to get started, put the exploded war located in server/target/ag-push.war directory and copy that to your jboss > > Thanks, > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7595.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From antoine.matyja at worldline.com Mon Apr 28 10:02:39 2014 From: antoine.matyja at worldline.com (A577127) Date: Mon, 28 Apr 2014 07:02:39 -0700 (PDT) Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> Message-ID: <1398693759040-7599.post@n5.nabble.com> The grunt command updated html and js files in server/src/main/webapp but it didn't update anything in server/target ; should I rebuild the war file every time, and then deploy it manually ? I thought the grunt stuff with jbossweb config was aiming to "live edit" the (already) deployed war file. Thanks for the answers, -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7599.html Sent from the aerogear-dev mailing list archive at Nabble.com. From cvasilak at gmail.com Mon Apr 28 10:09:11 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 28 Apr 2014 17:09:11 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Meeting ended Mon Apr 28 13:52:51 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-28-13.45.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-28-13.45.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-04-28-13.45.log.html On Apr 28, 2014, at 9:46 AM, Matthias Wessendorf wrote: > Agenda: > > http://oksoclap.com/p/aerogear-team-mgt-20140428 > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140428/3da3dfe0/attachment.html From edewit at redhat.com Mon Apr 28 10:15:46 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 28 Apr 2014 16:15:46 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1398693759040-7599.post@n5.nabble.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> Message-ID: <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> On 28 Apr,2014, at 16:02 , A577127 wrote: > The grunt command updated html and js files in server/src/main/webapp but it The grunt task updates the console static (html, javascript and css) files into jboss/standalone/deployments/ag-push.war. To use this first you?ll need to deploy the war directory. The war is build with mvn install, after that copy the war directory ( from server/target/ ) into the jboss/standalone/deployments directory now you?ll have the whole app deployed which can then be updated by grunt. Point your browser to http://localhost:8080/ag-push to see the changes as you live edit them. Hope this helps Erik Jan From scm.blanc at gmail.com Mon Apr 28 10:20:40 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Mon, 28 Apr 2014 16:20:40 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> Message-ID: <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> It must be deployed as an "exploded" WAR to have the live reloading working in jboss as. Envoy? de mon iPhone > Le 28 avr. 2014 ? 16:15, Erik Jan de Wit a ?crit : > > >> On 28 Apr,2014, at 16:02 , A577127 wrote: >> >> The grunt command updated html and js files in server/src/main/webapp but it > > The grunt task updates the console static (html, javascript and css) files into jboss/standalone/deployments/ag-push.war. > > To use this first you?ll need to deploy the war directory. The war is build with mvn install, after that copy the war directory ( from server/target/ ) into the jboss/standalone/deployments directory now you?ll have the whole app deployed which can then be updated by grunt. Point your browser to http://localhost:8080/ag-push to see the changes as you live edit them. > > Hope this helps > Erik Jan > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From antoine.matyja at worldline.com Mon Apr 28 11:14:46 2014 From: antoine.matyja at worldline.com (A577127) Date: Mon, 28 Apr 2014 08:14:46 -0700 (PDT) Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> Message-ID: <1398698086297-7603.post@n5.nabble.com> Ok, now I'm totally lost Since my deployment wasn't updating, I deleted it from my jboss-eap/standalone/deployments directory. Now I can't get again the ag-push.war exploded folder in the deployments with grunt commands. I don't remember what I did this morning to get it... I just tryed "grunt", "grunt server", "grunt test", "grunt build" without any success. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7603.html Sent from the aerogear-dev mailing list archive at Nabble.com. From edewit at redhat.com Mon Apr 28 11:22:16 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 28 Apr 2014 17:22:16 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1398698086297-7603.post@n5.nabble.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> Message-ID: <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> Okay one more time step by step: build the war file and ?exploded? war directory `mvn install` copy server/target/ag-push.war <= the directory not the file over to jboss/standelone/deployments then go to the console module (admin-ui) of the project and type `grunt server` this will watch your changes and copy them over to jboss as you edit them see your changes get applied on http://localhost:8080/ag-push/ if this doesn?t work, pleas tell us what the error was and what you did to get that error. Cheers, Erik Jan On 28 Apr,2014, at 17:14 , A577127 wrote: > Ok, now I'm totally lost > > Since my deployment wasn't updating, I deleted it from my > jboss-eap/standalone/deployments directory. > > Now I can't get again the ag-push.war exploded folder in the deployments > with grunt commands. I don't remember what I did this morning to get it... I > just tryed "grunt", "grunt server", "grunt test", "grunt build" without any > success. > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7603.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From antoine.matyja at worldline.com Mon Apr 28 11:26:51 2014 From: antoine.matyja at worldline.com (A577127) Date: Mon, 28 Apr 2014 08:26:51 -0700 (PDT) Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> Message-ID: <1398698811067-7605.post@n5.nabble.com> Thanks for your patience I will try this, but this morning I managed to get the exploded war in my jboss/standalone/deployments folder without running any maven command or copying stuff. I did it from a grunt command I think, but I can't do it again. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7605.html Sent from the aerogear-dev mailing list archive at Nabble.com. From edewit at redhat.com Mon Apr 28 11:31:55 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 28 Apr 2014 17:31:55 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1398698811067-7605.post@n5.nabble.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> <1398698811067-7605.post@n5.nabble.com> Message-ID: <02BAC22A-A46A-4411-9367-412BF02C8BB5@redhat.com> > Thanks for your patience > > I will try this, but this morning I managed to get the exploded war in my > jboss/standalone/deployments folder without running any maven command or > copying stuff. I did it from a grunt command I think, but I can't do it > again. > No, grunt does not deploy the entire war file only the assets from the admin-ui project. If you don?t create the exploded war file from the maven command line there will be no backend for the admin-ui module to talk to. The grunt task does not create an exploded war file it only updates the console (admin-ui) module of the project within the exploded war. Hope this is clear, Erik Jan From edewit at redhat.com Mon Apr 28 12:00:07 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 28 Apr 2014 18:00:07 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1398698811067-7605.post@n5.nabble.com> References: <1396019263157-7159.post@n5.nabble.com> <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> <1398698811067-7605.post@n5.nabble.com> Message-ID: If this doesn?t get you on your up and running could you please file a JIRA issue how we could create better documentation on building the server. Cheers, Erik Jan From brett.mclain at potashcorp.com Mon Apr 28 16:24:26 2014 From: brett.mclain at potashcorp.com (chinballs) Date: Mon, 28 Apr 2014 13:24:26 -0700 (PDT) Subject: [aerogear-dev] aerogear-push-helloworld cordova version fails to register Message-ID: <1398716666771-7608.post@n5.nabble.com> I am currently unable to get the cordova version of the hello world app to run on my 4.3 android phone. I have built and deployed the android version successfully. It registers with my push server (shows up in the variant) that is hosted on open shift, receives messages that I send out, etc. The cordova version is another story. I ran cordova add android, then cordova plugin add org.jboss.aerogear.cordova.push; both completed successfully. I then used the exact same configuration from the android version to replace the values in index.js to act as my configuration. I then ran cordova build android, and cordova run android. The application installs successfully on my phone, runs, and tells me that is has registered successfully. However, when I look at my variant, I don't see it registered. I have added logging messages to the aerogear-push.js file, and can confirm that the register() function is not returning prematurely. I then verified that nothing funny was showing up in the logs with regards to anything related to aerogear, cordova, or the push service. The only message of any note was this: I/dalvikvm( 6598): Could not find method org.apache.cordova.CordovaWebView.setWebContentsDebuggingEnabled, referenced from method org.apache.cordova.CordovaWebView.setup W/dalvikvm( 6598): VFY: unable to resolve static method 26844: Lorg/apache/cordova/CordovaWebView;.setWebContentsDebuggingEnabled (Z)V Other than that, there are no errors, no warnings, nothing. Does anyone have any ideas for how to debug this further? I'm pretty stumped at this point as to why it's saying it registered successfully when it clearly didn't. Here are the other debugging steps that I took: a.) Created a new application on the push server with a new variant. I was concerned that since I already used the android version on this phone that it wouldn't register with the cordova application. I changed over the details of the cordova application in the index.js file and nothing changed. b.) I tried changing the configuration in index.js to some garbage URL with bogus variant information and the application doesn't hiccup at all, it still says that it registered successfully, and all the log messages indicate that everything went well. This leads me to believe that it's not even bothering to call out at all... -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-push-helloworld-cordova-version-fails-to-register-tp7608.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Mon Apr 28 17:25:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Apr 2014 23:25:56 +0200 Subject: [aerogear-dev] aerogear-push-helloworld cordova version fails to register In-Reply-To: <1398716666771-7608.post@n5.nabble.com> References: <1398716666771-7608.post@n5.nabble.com> Message-ID: Hello Brett, I think the one in the Cordova repo is outdated; the HelloWorls uses an u released version. Clone this: https://github.com/aerogear/aerogear-pushplugin-cordova/ And do a "cordova plugin add $FOLDER" On the existing I think you need to remove the old before; To be safe, I'd just start from scratch Hope this helps, Matthias On Monday, April 28, 2014, chinballs wrote: > I am currently unable to get the cordova version of the hello world app to > run on my 4.3 android phone. I have built and deployed the android version > successfully. It registers with my push server (shows up in the variant) > that is hosted on open shift, receives messages that I send out, etc. > > The cordova version is another story. I ran cordova add android, then > cordova plugin add org.jboss.aerogear.cordova.push; both completed > successfully. I then used the exact same configuration from the android > version to replace the values in index.js to act as my configuration. > > I then ran cordova build android, and cordova run android. The application > installs successfully on my phone, runs, and tells me that is has > registered > successfully. However, when I look at my variant, I don't see it > registered. I have added logging messages to the aerogear-push.js file, > and > can confirm that the register() function is not returning prematurely. > > I then verified that nothing funny was showing up in the logs with regards > to anything related to aerogear, cordova, or the push service. The only > message of any note was this: > > I/dalvikvm( 6598): Could not find method > org.apache.cordova.CordovaWebView.setWebContentsDebuggingEnabled, > referenced > from method org.apache.cordova.CordovaWebView.setup > W/dalvikvm( 6598): VFY: unable to resolve static method 26844: > Lorg/apache/cordova/CordovaWebView;.setWebContentsDebuggingEnabled (Z)V > > Other than that, there are no errors, no warnings, nothing. > > Does anyone have any ideas for how to debug this further? I'm pretty > stumped > at this point as to why it's saying it registered successfully when it > clearly didn't. Here are the other debugging steps that I took: > > a.) Created a new application on the push server with a new variant. I was > concerned that since I already used the android version on this phone that > it wouldn't register with the cordova application. I changed over the > details of the cordova application in the index.js file and nothing > changed. > b.) I tried changing the configuration in index.js to some garbage URL with > bogus variant information and the application doesn't hiccup at all, it > still says that it registered successfully, and all the log messages > indicate that everything went well. This leads me to believe that it's not > even bothering to call out at all... > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-push-helloworld-cordova-version-fails-to-register-tp7608.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140428/29f9e97f/attachment.html From matzew at apache.org Mon Apr 28 17:27:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Apr 2014 23:27:48 +0200 Subject: [aerogear-dev] aerogear-push-helloworld cordova version fails to register In-Reply-To: References: <1398716666771-7608.post@n5.nabble.com> Message-ID: On Monday, April 28, 2014, Matthias Wessendorf wrote: > Hello Brett, > > I think the one in the Cordova repo is outdated; the HelloWorls uses an u > released version. > "unreleased version" I should have written -sent from a tiny and stupid iPhone keyboard > > Clone this: > https://github.com/aerogear/aerogear-pushplugin-cordova/ > > And do a "cordova plugin add $FOLDER" > > On the existing I think you need to remove the old before; To be safe, I'd > just start from scratch > > Hope this helps, > Matthias > > On Monday, April 28, 2014, chinballs > > wrote: > >> I am currently unable to get the cordova version of the hello world app to >> run on my 4.3 android phone. I have built and deployed the android >> version >> successfully. It registers with my push server (shows up in the variant) >> that is hosted on open shift, receives messages that I send out, etc. >> >> The cordova version is another story. I ran cordova add android, then >> cordova plugin add org.jboss.aerogear.cordova.push; both completed >> successfully. I then used the exact same configuration from the android >> version to replace the values in index.js to act as my configuration. >> >> I then ran cordova build android, and cordova run android. The >> application >> installs successfully on my phone, runs, and tells me that is has >> registered >> successfully. However, when I look at my variant, I don't see it >> registered. I have added logging messages to the aerogear-push.js file, >> and >> can confirm that the register() function is not returning prematurely. >> >> I then verified that nothing funny was showing up in the logs with regards >> to anything related to aerogear, cordova, or the push service. The only >> message of any note was this: >> >> I/dalvikvm( 6598): Could not find method >> org.apache.cordova.CordovaWebView.setWebContentsDebuggingEnabled, >> referenced >> from method org.apache.cordova.CordovaWebView.setup >> W/dalvikvm( 6598): VFY: unable to resolve static method 26844: >> Lorg/apache/cordova/CordovaWebView;.setWebContentsDebuggingEnabled (Z)V >> >> Other than that, there are no errors, no warnings, nothing. >> >> Does anyone have any ideas for how to debug this further? I'm pretty >> stumped >> at this point as to why it's saying it registered successfully when it >> clearly didn't. Here are the other debugging steps that I took: >> >> a.) Created a new application on the push server with a new variant. I >> was >> concerned that since I already used the android version on this phone that >> it wouldn't register with the cordova application. I changed over the >> details of the cordova application in the index.js file and nothing >> changed. >> b.) I tried changing the configuration in index.js to some garbage URL >> with >> bogus variant information and the application doesn't hiccup at all, it >> still says that it registered successfully, and all the log messages >> indicate that everything went well. This leads me to believe that it's >> not >> even bothering to call out at all... >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-push-helloworld-cordova-version-fails-to-register-tp7608.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > -- > Sent from Gmail Mobile > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140428/d44ae0b4/attachment-0001.html From keith at kdmooreconsulting.com Mon Apr 28 22:41:43 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Mon, 28 Apr 2014 19:41:43 -0700 (PDT) Subject: [aerogear-dev] Problems sending notifications Cordova In-Reply-To: References: <20140423135701.GN1275@rohan.local> <53581A98.9080702@abstractj.org> <1398333062008-7566.post@n5.nabble.com> <1398490253386-7583.post@n5.nabble.com> <1398547466903-7587.post@n5.nabble.com> <1398554371318-7589.post@n5.nabble.com> <1398632938043-7592.post@n5.nabble.com> Message-ID: <1398739303203-7611.post@n5.nabble.com> @mattias Yes, I was referring to AGPUSH-624. However, I am beginning to think they may not have been my issue after all. Based on today's experience, I think the culprit was my Nexus 7. I deleted the android variant and recreated. I wasn't able to get it to receive push notifications. It would register just fine. Same issue as before. So I updated the Nexus 7 tablet to 4.2.2 (which by the way fixes another issue with launching the app from a push notification). I restarted the device and restarted the OpenShift server. The push notifications work now. Now if I can just get this red spot on my forehead to go away ! -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Problems-sending-notifications-Cordova-tp7515p7611.html Sent from the aerogear-dev mailing list archive at Nabble.com. From antoine.matyja at worldline.com Tue Apr 29 03:44:51 2014 From: antoine.matyja at worldline.com (A577127) Date: Tue, 29 Apr 2014 00:44:51 -0700 (PDT) Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <02BAC22A-A46A-4411-9367-412BF02C8BB5@redhat.com> References: <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> <1398698811067-7605.post@n5.nabble.com> <02BAC22A-A46A-4411-9367-412BF02C8BB5@redhat.com> Message-ID: <1398757491128-7612.post@n5.nabble.com> I followed your instructions and it worked. I copied the ag-push folder to deployments, renamed it to ag-push.war and touched a ag-push.war.dodeploy file. Now it works perfectly. Thanks !! There's just one last issue not solved, when you run grunt server and get a preview on localhost:9000, is it possible to log in ? My password doesn't work (I guess this preview isn't linked to the datasource), but admin:123 doesn't work either and if I try to load /mobileApps (for example) I get redirected to the login form. If there isn't a solution, it's not really important since I can test it on the localhost:8080 but it makes the localhost:9000 feature useless. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7612.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Tue Apr 29 03:51:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Apr 2014 09:51:38 +0200 Subject: [aerogear-dev] pushplugin release In-Reply-To: References: Message-ID: What's the state of the actual release? It would be nice if we could get the newer API live On Tue, Apr 22, 2014 at 5:11 PM, Matthias Wessendorf wrote: > as 622 has been addressed -> I am +1 > > > On Tue, Apr 22, 2014 at 11:24 AM, Matthias Wessendorf wrote: > >> Hello, >> >> >> I have tested the plugin (master branch) on both: Android and iOS (using >> the Cordova HelloWorld PR from Erik). >> >> It works great! >> >> >> However, let's get [AGPUSH-622] fixed before we do the release >> >> -Matthias >> >> >> [AGPUSH-622] https://issues.jboss.org/browse/AGPUSH-622 >> >> >> >> >> On Tue, Apr 22, 2014 at 9:28 AM, Matthias Wessendorf wrote: >> >>> Sounds good! >>> >>> I will give the current master branch a test, and will report back here >>> >>> >>> On Tue, Apr 22, 2014 at 9:02 AM, Erik Jan de Wit wrote: >>> >>>> Hi, >>>> >>>> I?ve announced it before, but didn?t came around to actually do it and >>>> we started discussing the version number. So end of the week I?ll release a >>>> new version of the aerogear-pushplugin-cordova (for real this time) with >>>> version 0.5.0 this will include the 64 bit support the new API and some >>>> small bug fixes. >>>> >>>> Cheers, >>>> Erik Jan >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at 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 >> > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140429/cb12aa5f/attachment.html From edewit at redhat.com Tue Apr 29 03:59:45 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 29 Apr 2014 09:59:45 +0200 Subject: [aerogear-dev] pushplugin release In-Reply-To: References: Message-ID: <6C2A587A-F477-4F85-B648-F10E07FE3D3B@redhat.com> I wanted to wait for the release of the android-push module and the inclusion of https://github.com/aerogear/aerogear-pushplugin-cordova/pull/24 Let?s release this thing. On 29 Apr,2014, at 9:51 , Matthias Wessendorf wrote: > What's the state of the actual release? It would be nice if we could get the newer API live > > > On Tue, Apr 22, 2014 at 5:11 PM, Matthias Wessendorf wrote: > as 622 has been addressed -> I am +1 > > > On Tue, Apr 22, 2014 at 11:24 AM, Matthias Wessendorf wrote: > Hello, > > > I have tested the plugin (master branch) on both: Android and iOS (using the Cordova HelloWorld PR from Erik). > > It works great! > > > However, let's get [AGPUSH-622] fixed before we do the release > > -Matthias > > > [AGPUSH-622] https://issues.jboss.org/browse/AGPUSH-622 > > > > > On Tue, Apr 22, 2014 at 9:28 AM, Matthias Wessendorf wrote: > Sounds good! > > I will give the current master branch a test, and will report back here > > > On Tue, Apr 22, 2014 at 9:02 AM, Erik Jan de Wit wrote: > Hi, > > I?ve announced it before, but didn?t came around to actually do it and we started discussing the version number. So end of the week I?ll release a new version of the aerogear-pushplugin-cordova (for real this time) with version 0.5.0 this will include the 64 bit support the new API and some small bug fixes. > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > > > > -- > 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140429/ba9b1add/attachment.html From matzew at apache.org Tue Apr 29 04:05:26 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Apr 2014 10:05:26 +0200 Subject: [aerogear-dev] pushplugin release In-Reply-To: <6C2A587A-F477-4F85-B648-F10E07FE3D3B@redhat.com> References: <6C2A587A-F477-4F85-B648-F10E07FE3D3B@redhat.com> Message-ID: +1 just tested on my device -> works great On Tue, Apr 29, 2014 at 9:59 AM, Erik Jan de Wit wrote: > I wanted to wait for the release of the android-push module and the > inclusion of > https://github.com/aerogear/aerogear-pushplugin-cordova/pull/24 > > Let?s release this thing. > > On 29 Apr,2014, at 9:51 , Matthias Wessendorf wrote: > > What's the state of the actual release? It would be nice if we could get > the newer API live > > > On Tue, Apr 22, 2014 at 5:11 PM, Matthias Wessendorf wrote: > >> as 622 has been addressed -> I am +1 >> >> >> On Tue, Apr 22, 2014 at 11:24 AM, Matthias Wessendorf wrote: >> >>> Hello, >>> >>> >>> I have tested the plugin (master branch) on both: Android and iOS (using >>> the Cordova HelloWorld PR from Erik). >>> >>> It works great! >>> >>> >>> However, let's get [AGPUSH-622] fixed before we do the release >>> >>> -Matthias >>> >>> >>> [AGPUSH-622] https://issues.jboss.org/browse/AGPUSH-622 >>> >>> >>> >>> >>> On Tue, Apr 22, 2014 at 9:28 AM, Matthias Wessendorf wrote: >>> >>>> Sounds good! >>>> >>>> I will give the current master branch a test, and will report back here >>>> >>>> >>>> On Tue, Apr 22, 2014 at 9:02 AM, Erik Jan de Wit wrote: >>>> >>>>> Hi, >>>>> >>>>> I?ve announced it before, but didn?t came around to actually do it and >>>>> we started discussing the version number. So end of the week I?ll release a >>>>> new version of the aerogear-pushplugin-cordova (for real this time) with >>>>> version 0.5.0 this will include the 64 bit support the new API and some >>>>> small bug fixes. >>>>> >>>>> Cheers, >>>>> Erik Jan >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at 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 >>> >> >> >> >> -- >> 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140429/9b9788e3/attachment-0001.html From matzew at apache.org Tue Apr 29 04:14:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Apr 2014 10:14:52 +0200 Subject: [aerogear-dev] Android: HSTS issue with registration against OpenShift Message-ID: Hi, I was wondering if AGDROID-214 could be addressed w/in the 1.4.0 release of the AG-Droid library. Especially since that release also contains the factored out "push library" apk/jar Thanks! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140429/3d80fd88/attachment.html From scm.blanc at gmail.com Tue Apr 29 04:59:50 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Tue, 29 Apr 2014 10:59:50 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <1398757491128-7612.post@n5.nabble.com> References: <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> <1398698811067-7605.post@n5.nabble.com> <02BAC22A-A46A-4411-9367-412BF02C8BB5@redhat.com> <1398757491128-7612.post@n5.nabble.com> Message-ID: Yes, I think we could remove the server grunt starts , it does not add any value. Envoy? de mon iPhone > Le 29 avr. 2014 ? 09:44, A577127 a ?crit : > > I followed your instructions and it worked. I copied the ag-push folder to > deployments, renamed it to ag-push.war and touched a ag-push.war.dodeploy > file. Now it works perfectly. Thanks !! > > There's just one last issue not solved, when you run grunt server and get a > preview on localhost:9000, is it possible to log in ? My password doesn't > work (I guess this preview isn't linked to the datasource), but admin:123 > doesn't work either and if I try to load /mobileApps (for example) I get > redirected to the login form. > If there isn't a solution, it's not really important since I can test it on > the localhost:8080 but it makes the localhost:9000 feature useless. > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7612.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Apr 29 05:14:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Apr 2014 11:14:09 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: References: <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> <1398698811067-7605.post@n5.nabble.com> <02BAC22A-A46A-4411-9367-412BF02C8BB5@redhat.com> <1398757491128-7612.post@n5.nabble.com> Message-ID: On Tuesday, April 29, 2014, S?bastien Blanc wrote: > Yes, I think we could remove the server grunt starts , it does not add any > value. I never used it; luke added it - perhaps there is some sort of benefit in this; not sure > > Envoy? de mon iPhone > > > Le 29 avr. 2014 ? 09:44, A577127 > > a ?crit : > > > > I followed your instructions and it worked. I copied the ag-push folder > to > > deployments, renamed it to ag-push.war and touched a ag-push.war.dodeploy > > file. Now it works perfectly. Thanks !! > > > > There's just one last issue not solved, when you run grunt server and > get a > > preview on localhost:9000, is it possible to log in ? My password doesn't > > work (I guess this preview isn't linked to the datasource), but admin:123 > > doesn't work either and if I try to load /mobileApps (for example) I get > > redirected to the login form. > > If there isn't a solution, it's not really important since I can test it > on > > the localhost:8080 but it makes the localhost:9000 feature useless. > > > > > > > > -- > > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7612.html > > Sent from the aerogear-dev mailing list archive at Nabble.com. > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140429/de74ff69/attachment.html From kpiwko at redhat.com Tue Apr 29 06:58:27 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 29 Apr 2014 12:58:27 +0200 Subject: [aerogear-dev] SimplePush Server 0.11.0 In-Reply-To: References: Message-ID: <20140429125827.0dfcaa6f@kapy-ntb-x220> Sounds good. Let me know when testing phase will be approaching. Karel On Wed, 23 Apr 2014 10:18:12 +0200 Daniel Bevenius wrote: > Hi all, > > just wanted to give a heads up that I've rescheduled the release of > SimplePush 0.11.0 [1]. There are only two task remaining, but I'll be > working on other things for a while which is the reason for there not being > more. > > The main task of interest I think is [2], which allows notifications to be > done without a version in the body of the HTTP request. This I believe will > simplify the admin ui and perhaps other areas. If you'd like to see an > earlier release then let me know and I'll get it done. As of now though, > I've set the release date to May 6. > > /Dan > > > [1] > https://issues.jboss.org/browse/AGSMPLPUSH-16?filter=12321270&jql=project%20%3D%20AGSMPLPUSH%20AND%20fixVersion%20%3D%20%220.11.0%22%20AND%20status%20in%20(Open%2C%20%22Coding%20In%20Progress%22%2C%20Reopened%2C%20%22Pull%20Request%20Sent%22) > > [2] https://issues.jboss.org/browse/AGSMPLPUSH-54 From lholmqui at redhat.com Tue Apr 29 08:57:53 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 29 Apr 2014 08:57:53 -0400 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: References: <67FE8CD8-DDAD-4AE1-B809-B867E3D41428@redhat.com> <1398689875828-7595.post@n5.nabble.com> <1398693759040-7599.post@n5.nabble.com> <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> <1398698811067-7605.post@n5.nabble.com> <02BAC22A-A46A-4411-9367-412BF02C8BB5@redhat.com> <1398757491128-7612.post@n5.nabble.com> Message-ID: <6342C9BE-E43B-4314-B7B4-B5C433FF9D78@redhat.com> On Apr 29, 2014, at 5:14 AM, Matthias Wessendorf wrote: > > > On Tuesday, April 29, 2014, S?bastien Blanc wrote: > Yes, I think we could remove the server grunt starts , it does not add any value. > > I never used it; luke added it - perhaps there is some sort of benefit in this; not sure it was nice to mock stuff, but can probably be removed > > > Envoy? de mon iPhone > > > Le 29 avr. 2014 ? 09:44, A577127 a ?crit : > > > > I followed your instructions and it worked. I copied the ag-push folder to > > deployments, renamed it to ag-push.war and touched a ag-push.war.dodeploy > > file. Now it works perfectly. Thanks !! > > > > There's just one last issue not solved, when you run grunt server and get a > > preview on localhost:9000, is it possible to log in ? My password doesn't > > work (I guess this preview isn't linked to the datasource), but admin:123 > > doesn't work either and if I try to load /mobileApps (for example) I get > > redirected to the login form. > > If there isn't a solution, it's not really important since I can test it on > > the localhost:8080 but it makes the localhost:9000 feature useless. > > > > > > > > -- > > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7612.html > > Sent from the aerogear-dev mailing list archive at Nabble.com. > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Sent from Gmail Mobile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140429/0a8fa456/attachment.html From bruno at abstractj.org Tue Apr 29 11:48:38 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 29 Apr 2014 12:48:38 -0300 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <6342C9BE-E43B-4314-B7B4-B5C433FF9D78@redhat.com> References: <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> <1398698811067-7605.post@n5.nabble.com> <02BAC22A-A46A-4411-9367-412BF02C8BB5@redhat.com> <1398757491128-7612.post@n5.nabble.com> <6342C9BE-E43B-4314-B7B4-B5C433FF9D78@redhat.com> Message-ID: <20140429154838.GA84607@abstractj.org> +1 removed or deprecation notice, I'm fine On 2014-04-29, Lucas Holmquist wrote: > > On Apr 29, 2014, at 5:14 AM, Matthias Wessendorf wrote: > > > > > > > On Tuesday, April 29, 2014, S?bastien Blanc wrote: > > Yes, I think we could remove the server grunt starts , it does not add any value. > > > > I never used it; luke added it - perhaps there is some sort of benefit in this; not sure > > it was nice to mock stuff, but can probably be removed > > > > > > > Envoy? de mon iPhone > > > > > Le 29 avr. 2014 ? 09:44, A577127 a ?crit : > > > > > > I followed your instructions and it worked. I copied the ag-push folder to > > > deployments, renamed it to ag-push.war and touched a ag-push.war.dodeploy > > > file. Now it works perfectly. Thanks !! > > > > > > There's just one last issue not solved, when you run grunt server and get a > > > preview on localhost:9000, is it possible to log in ? My password doesn't > > > work (I guess this preview isn't linked to the datasource), but admin:123 > > > doesn't work either and if I try to load /mobileApps (for example) I get > > > redirected to the login form. > > > If there isn't a solution, it's not really important since I can test it on > > > the localhost:8080 but it makes the localhost:9000 feature useless. > > > > > > > > > > > > -- > > > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7612.html > > > Sent from the aerogear-dev mailing list archive at Nabble.com. > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > Sent from Gmail Mobile > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From matzew at apache.org Tue Apr 29 11:50:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Apr 2014 17:50:45 +0200 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: <20140429154838.GA84607@abstractj.org> References: <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> <1398698811067-7605.post@n5.nabble.com> <02BAC22A-A46A-4411-9367-412BF02C8BB5@redhat.com> <1398757491128-7612.post@n5.nabble.com> <6342C9BE-E43B-4314-B7B4-B5C433FF9D78@redhat.com> <20140429154838.GA84607@abstractj.org> Message-ID: +1 on removal On Tue, Apr 29, 2014 at 5:48 PM, Bruno Oliveira wrote: > +1 removed or deprecation notice, I'm fine > > On 2014-04-29, Lucas Holmquist wrote: > > > > On Apr 29, 2014, at 5:14 AM, Matthias Wessendorf > wrote: > > > > > > > > > > > On Tuesday, April 29, 2014, S?bastien Blanc > wrote: > > > Yes, I think we could remove the server grunt starts , it does not add > any value. > > > > > > I never used it; luke added it - perhaps there is some sort of benefit > in this; not sure > > > > it was nice to mock stuff, but can probably be removed > > > > > > > > > > > Envoy? de mon iPhone > > > > > > > Le 29 avr. 2014 ? 09:44, A577127 a > ?crit : > > > > > > > > I followed your instructions and it worked. I copied the ag-push > folder to > > > > deployments, renamed it to ag-push.war and touched a > ag-push.war.dodeploy > > > > file. Now it works perfectly. Thanks !! > > > > > > > > There's just one last issue not solved, when you run grunt server > and get a > > > > preview on localhost:9000, is it possible to log in ? My password > doesn't > > > > work (I guess this preview isn't linked to the datasource), but > admin:123 > > > > doesn't work either and if I try to load /mobileApps (for example) I > get > > > > redirected to the login form. > > > > If there isn't a solution, it's not really important since I can > test it on > > > > the localhost:8080 but it makes the localhost:9000 feature useless. > > > > > > > > > > > > > > > > -- > > > > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7612.html > > > > Sent from the aerogear-dev mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > -- > > > Sent from Gmail Mobile > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140429/52afacd5/attachment.html From lholmqui at redhat.com Tue Apr 29 11:57:12 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 29 Apr 2014 11:57:12 -0400 Subject: [aerogear-dev] Building UnifiedPush Server from sources In-Reply-To: References: <74D36FF3-7F33-466E-B4BB-2917B6932C38@redhat.com> <91073B76-D747-421C-B78F-5524BEEFF1B4@gmail.com> <1398698086297-7603.post@n5.nabble.com> <1E0523E5-D9F4-4C36-AF5E-FDE76972DBCF@redhat.com> <1398698811067-7605.post@n5.nabble.com> <02BAC22A-A46A-4411-9367-412BF02C8BB5@redhat.com> <1398757491128-7612.post@n5.nabble.com> <6342C9BE-E43B-4314-B7B4-B5C433FF9D78@redhat.com> <20140429154838.GA84607@abstractj.org> Message-ID: <5D35C5FA-E9F9-4A85-9EE9-1EEFACDF4C17@redhat.com> this is more for development time anyway. it allows for live reload, but since the UI is changing, then the grunt file will most likely be different anyway On Apr 29, 2014, at 11:50 AM, Matthias Wessendorf wrote: > +1 on removal > > > On Tue, Apr 29, 2014 at 5:48 PM, Bruno Oliveira wrote: > +1 removed or deprecation notice, I'm fine > > On 2014-04-29, Lucas Holmquist wrote: > > > > On Apr 29, 2014, at 5:14 AM, Matthias Wessendorf wrote: > > > > > > > > > > > On Tuesday, April 29, 2014, S?bastien Blanc wrote: > > > Yes, I think we could remove the server grunt starts , it does not add any value. > > > > > > I never used it; luke added it - perhaps there is some sort of benefit in this; not sure > > > > it was nice to mock stuff, but can probably be removed > > > > > > > > > > > Envoy? de mon iPhone > > > > > > > Le 29 avr. 2014 ? 09:44, A577127 a ?crit : > > > > > > > > I followed your instructions and it worked. I copied the ag-push folder to > > > > deployments, renamed it to ag-push.war and touched a ag-push.war.dodeploy > > > > file. Now it works perfectly. Thanks !! > > > > > > > > There's just one last issue not solved, when you run grunt server and get a > > > > preview on localhost:9000, is it possible to log in ? My password doesn't > > > > work (I guess this preview isn't linked to the datasource), but admin:123 > > > > doesn't work either and if I try to load /mobileApps (for example) I get > > > > redirected to the login form. > > > > If there isn't a solution, it's not really important since I can test it on > > > > the localhost:8080 but it makes the localhost:9000 feature useless. > > > > > > > > > > > > > > > > -- > > > > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-from-sources-tp7159p7612.html > > > > Sent from the aerogear-dev mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > -- > > > Sent from Gmail Mobile > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140429/0a18a0de/attachment.html From edewit at redhat.com Tue Apr 29 15:24:11 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 29 Apr 2014 21:24:11 +0200 Subject: [aerogear-dev] pushplugin release 0.5.0 Message-ID: <38464F18-3F8F-4FE1-93A9-09453443D2DB@redhat.com> Hi, We?ve released aerogear-pushplugin-cordova version 0.5.0 most important features are the new API, the updated binary dependencies and the support for Xcode 5.1 (64 bit) it?s available on the cordova repository http://plugins.cordova.io/#/package/org.jboss.aerogear.cordova.push Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140429/fae4127f/attachment.html From antoine.matyja at worldline.com Wed Apr 30 08:50:47 2014 From: antoine.matyja at worldline.com (A577127) Date: Wed, 30 Apr 2014 05:50:47 -0700 (PDT) Subject: [aerogear-dev] UPS : JBoss EAP 6.2.0 + MySQL datasource gives me errors Message-ID: <1398862247549-7625.post@n5.nabble.com> Hello everybody, I used to do my tests with the UPS using the H2 database and JBoss EAP 6.2.0 (latest) without any problem. But today I tried to switch to MySQL and got errors when deploying the WAR file. Then I tried again with JBoss AS 7.1.1 and everything worked perfectly. Here is the summary of my tests : OS : Windows 7 H2 MySQL JBoss AS 7.1.1 Final OK OK JBoss EAP 6.2.0 OK Error When I deploy the WAR file, first I get this warning : And then (later) this error : Weird since I did the same things on jboss 7.1.1 and it worked fine (I follow the readme from github). Any ideas ? Thanks, -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/UPS-JBoss-EAP-6-2-0-MySQL-datasource-gives-me-errors-tp7625.html Sent from the aerogear-dev mailing list archive at Nabble.com. From avibelli at redhat.com Wed Apr 30 09:27:19 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Wed, 30 Apr 2014 09:27:19 -0400 (EDT) Subject: [aerogear-dev] Google-play-services version inside Cordova Push Plugin In-Reply-To: <1074978674.9226804.1398863020271.JavaMail.zimbra@redhat.com> Message-ID: <1965805718.9247066.1398864439534.JavaMail.zimbra@redhat.com> Hi all, after some searches, I finally found which version of google-play-services.jar is included inside the Cordova Push Plugin, inside src/android/libs folder. This version comes from: ${ANDROID_HOME}/extras/google/google_play_services_froyo/libproject/google-play-services_lib/libs I have tested the Cordova Push Plugin (tag 0.5.0) on a Android 4.1.1 device and everything works well, then replaced google-play-services.jar inside the src/android/libs folder with the latest version of it, taken from: ${ANDROID_HOME}/extras/google/google_play_services/libproject/google-play-services_lib/libs and that worked also without problems. I would ask if someone can make this test on more old devices as I do not have any (so using the latest version of google-play-services.jar inside the Cordova Push Plugin on devices prior to 4.1.1). If that works I would suggest to replace the old library inside the plugin with the latest one distributed by Google's SDK, what do you think about it? Thanks Andrea From daniel at passos.me Wed Apr 30 10:08:49 2014 From: daniel at passos.me (Daniel Passos) Date: Wed, 30 Apr 2014 11:08:49 -0300 Subject: [aerogear-dev] Google-play-services version inside Cordova Push Plugin In-Reply-To: <1965805718.9247066.1398864439534.JavaMail.zimbra@redhat.com> References: <1074978674.9226804.1398863020271.JavaMail.zimbra@redhat.com> <1965805718.9247066.1398864439534.JavaMail.zimbra@redhat.com> Message-ID: Hi Andrea, Don't makes sense use the Froyo (2.2) version, because is the minimum version that we support is Gingerbread (2.3.3) My suggestion is use the last version too (That is the version we are using in Android land). But before we change that, could some one test it on a real 2.3.3 device ? -- Passos On Wed, Apr 30, 2014 at 10:27 AM, Andrea Vibelli wrote: > Hi all, > after some searches, I finally found which version of > google-play-services.jar is included inside the Cordova Push Plugin, inside > src/android/libs folder. > > This version comes from: > > ${ANDROID_HOME}/extras/google/google_play_services_froyo/libproject/google-play-services_lib/libs > > I have tested the Cordova Push Plugin (tag 0.5.0) on a Android 4.1.1 > device and everything works well, then replaced google-play-services.jar > inside the src/android/libs folder with the latest version of it, taken > from: > > > ${ANDROID_HOME}/extras/google/google_play_services/libproject/google-play-services_lib/libs > > and that worked also without problems. > > I would ask if someone can make this test on more old devices as I do not > have any (so using the latest version of google-play-services.jar inside > the Cordova Push Plugin on devices prior to 4.1.1). If that works I would > suggest to replace the old library inside the plugin with the latest one > distributed by Google's SDK, what do you think about it? > > Thanks > Andrea > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140430/5b3d6f75/attachment.html From daniel at passos.me Wed Apr 30 10:12:44 2014 From: daniel at passos.me (Daniel Passos) Date: Wed, 30 Apr 2014 11:12:44 -0300 Subject: [aerogear-dev] AeroGear Android Push 0.1 on staging In-Reply-To: <53592ADE.8020607@abstractj.org> References: <53592ADE.8020607@abstractj.org> Message-ID: AeroGear Android Push 0.1 available in the central maven [1] \o/ [1] http://search.maven.org/#browse%7C1011889362 -- Passos On Thu, Apr 24, 2014 at 12:16 PM, Bruno Oliveira wrote: > Ship it! > > Daniel Passos wrote: > > Hi Folks, > > > > The android team started modularize[1] the android library. > > > > We started with push[2]. It was staged[3] on Nexus and tested using > > aerogear-push-helloworld[4]. > > > > You are probably anxious to test it, so go ahead! > > > > I plan release it on thursday. > > -- > abstractj > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140430/50b78f33/attachment.html From kpiwko at redhat.com Wed Apr 30 10:25:34 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 30 Apr 2014 16:25:34 +0200 Subject: [aerogear-dev] Google-play-services version inside Cordova Push Plugin In-Reply-To: References: <1074978674.9226804.1398863020271.JavaMail.zimbra@redhat.com> <1965805718.9247066.1398864439534.JavaMail.zimbra@redhat.com> Message-ID: <20140430162534.7047a326@kapy-ntb-x220> Stefan is just updating our Cordova example (and incorporating Cordova HelloPush) to test latest Cordova Push Plugin. Testing on Android 2.3.3 is part of test execution, as we have (real) Android 2.3.3 device. I expect he'll have time to verify that on Monday though, as he's on PTO tomorrow and Friday. Karel On Wed, 30 Apr 2014 11:08:49 -0300 Daniel Passos wrote: > Hi Andrea, > > Don't makes sense use the Froyo (2.2) version, because is the minimum > version that we support is Gingerbread (2.3.3) > > My suggestion is use the last version too (That is the version we are using > in Android land). But before we change that, could some one test it on a > real 2.3.3 device ? > > -- Passos > > > On Wed, Apr 30, 2014 at 10:27 AM, Andrea Vibelli wrote: > > > Hi all, > > after some searches, I finally found which version of > > google-play-services.jar is included inside the Cordova Push Plugin, inside > > src/android/libs folder. > > > > This version comes from: > > > > ${ANDROID_HOME}/extras/google/google_play_services_froyo/libproject/google-play-services_lib/libs > > > > I have tested the Cordova Push Plugin (tag 0.5.0) on a Android 4.1.1 > > device and everything works well, then replaced google-play-services.jar > > inside the src/android/libs folder with the latest version of it, taken > > from: > > > > > > ${ANDROID_HOME}/extras/google/google_play_services/libproject/google-play-services_lib/libs > > > > and that worked also without problems. > > > > I would ask if someone can make this test on more old devices as I do not > > have any (so using the latest version of google-play-services.jar inside > > the Cordova Push Plugin on devices prior to 4.1.1). If that works I would > > suggest to replace the old library inside the plugin with the latest one > > distributed by Google's SDK, what do you think about it? > > > > Thanks > > Andrea > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > From kpiwko at redhat.com Wed Apr 30 10:28:53 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 30 Apr 2014 16:28:53 +0200 Subject: [aerogear-dev] UPS : JBoss EAP 6.2.0 + MySQL datasource gives me errors In-Reply-To: <1398862247549-7625.post@n5.nabble.com> References: <1398862247549-7625.post@n5.nabble.com> Message-ID: <20140430162853.47ea664d@kapy-ntb-x220> Hi, hard to figure that out without stacktrace but my guess is that problem happens due to fact that module structure in AS7 and EAP6.2 is not the same. Modules should be copied to: ${EAP_HOME}/modules/system/layers/base/ Let us know if that helps. Thanks, Karel On Wed, 30 Apr 2014 05:50:47 -0700 (PDT) A577127 wrote: > Hello everybody, > > I used to do my tests with the UPS using the H2 database and JBoss EAP 6.2.0 > (latest) without any problem. But today I tried to switch to MySQL and got > errors when deploying the WAR file. Then I tried again with JBoss AS 7.1.1 > and everything worked perfectly. > > Here is the summary of my tests : > > OS : Windows 7 > > H2 MySQL > JBoss AS 7.1.1 Final OK OK > JBoss EAP 6.2.0 OK Error > > When I deploy the WAR file, first I get this warning : > > > And then (later) this error : > > > Weird since I did the same things on jboss 7.1.1 and it worked fine (I > follow the readme > from github). Any ideas ? > > Thanks, > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/UPS-JBoss-EAP-6-2-0-MySQL-datasource-gives-me-errors-tp7625.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From antoine.matyja at worldline.com Wed Apr 30 11:10:39 2014 From: antoine.matyja at worldline.com (A577127) Date: Wed, 30 Apr 2014 08:10:39 -0700 (PDT) Subject: [aerogear-dev] UPS : JBoss EAP 6.2.0 + MySQL datasource gives me errors In-Reply-To: <20140430162853.47ea664d@kapy-ntb-x220> References: <1398862247549-7625.post@n5.nabble.com> <20140430162853.47ea664d@kapy-ntb-x220> Message-ID: <1398870639710-7631.post@n5.nabble.com> Thanks, I followed the instructions to the letter and didn't notice modules had moved. I moved the mysql connector plugin to the right place :) However I still get the same warnings & errors. Is the old command to install the driver still working with eap ? Here is a bigger copy/paste of the first warning : And after a few similar warnings, the first error : -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/UPS-JBoss-EAP-6-2-0-MySQL-datasource-gives-me-errors-tp7625p7631.html Sent from the aerogear-dev mailing list archive at Nabble.com. From antoine.matyja at worldline.com Wed Apr 30 11:27:58 2014 From: antoine.matyja at worldline.com (A577127) Date: Wed, 30 Apr 2014 08:27:58 -0700 (PDT) Subject: [aerogear-dev] UPS : JBoss EAP 6.2.0 + MySQL datasource gives me errors In-Reply-To: <20140430162853.47ea664d@kapy-ntb-x220> References: <1398862247549-7625.post@n5.nabble.com> <20140430162853.47ea664d@kapy-ntb-x220> Message-ID: <1398871678030-7632.post@n5.nabble.com> By the way, while looking for information about plugin installation with JBoss EAP I found this documentation : https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/Install_a_JDBC_Driver_as_a_Core_Module1.html Which deals with EAP and still gives a "classic" path (EAP_HOME/modules/com/mysql/main/). -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/UPS-JBoss-EAP-6-2-0-MySQL-datasource-gives-me-errors-tp7625p7632.html Sent from the aerogear-dev mailing list archive at Nabble.com. From bruno at abstractj.org Wed Apr 30 12:47:23 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 30 Apr 2014 13:47:23 -0300 Subject: [aerogear-dev] UPS : JBoss EAP 6.2.0 + MySQL datasource gives me errors In-Reply-To: <1398870639710-7631.post@n5.nabble.com> References: <1398862247549-7625.post@n5.nabble.com> <20140430162853.47ea664d@kapy-ntb-x220> <1398870639710-7631.post@n5.nabble.com> Message-ID: <20140430164723.GA96758@abstractj.org> Hi Antonie, your copy & paste is not arriving here. Probably because the mailing list might be blocking it. You can use some of these services to send stack traces: https://gist.github.com or http://pastebin.com On 2014-04-30, A577127 wrote: > Thanks, I followed the instructions to the letter and didn't notice modules > had moved. I moved the mysql connector plugin to the right place :) > > However I still get the same warnings & errors. > > Is the old command to install the driver still working with eap ? > > > > Here is a bigger copy/paste of the first warning : > > > > And after a few similar warnings, the first error : > > > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/UPS-JBoss-EAP-6-2-0-MySQL-datasource-gives-me-errors-tp7625p7631.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From brett.mclain at potashcorp.com Wed Apr 30 13:14:18 2014 From: brett.mclain at potashcorp.com (chinballs) Date: Wed, 30 Apr 2014 10:14:18 -0700 (PDT) Subject: [aerogear-dev] aerogear-push-helloworld cordova version fails to register In-Reply-To: References: <1398716666771-7608.post@n5.nabble.com> Message-ID: <1398878058461-7634.post@n5.nabble.com> Excellent Matt, thanks for the tip. I've got it all running smoothly now. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-push-helloworld-cordova-version-fails-to-register-tp7608p7634.html Sent from the aerogear-dev mailing list archive at Nabble.com. From avibelli at redhat.com Wed Apr 30 15:59:28 2014 From: avibelli at redhat.com (avibelli) Date: Wed, 30 Apr 2014 12:59:28 -0700 (PDT) Subject: [aerogear-dev] Google-play-services version inside Cordova Push Plugin In-Reply-To: <20140430162534.7047a326@kapy-ntb-x220> References: <1965805718.9247066.1398864439534.JavaMail.zimbra@redhat.com> <20140430162534.7047a326@kapy-ntb-x220> Message-ID: <1398887968047-7635.post@n5.nabble.com> To make testing easier, I have created a branch on my repository that I forked from master branch of aerogear-pushplugin-cordova, but containing the latest version of google-play-services.jar. If this works on old devices, I may send a PR from this branch: https://github.com/vibe13/aerogear-pushplugin-cordova/tree/latest-google-play-services Thanks Andrea Karel Piwko wrote > Stefan is just updating our Cordova example (and incorporating Cordova > HelloPush) to test latest Cordova Push Plugin. > > Testing on Android 2.3.3 is part of test execution, as we have (real) > Android > 2.3.3 device. I expect he'll have time to verify that on Monday though, as > he's on PTO tomorrow and Friday. > > Karel > > > On Wed, 30 Apr 2014 11:08:49 -0300 > Daniel Passos < > daniel@ > > wrote: > >> Hi Andrea, >> >> Don't makes sense use the Froyo (2.2) version, because is the minimum >> version that we support is Gingerbread (2.3.3) >> >> My suggestion is use the last version too (That is the version we are >> using >> in Android land). But before we change that, could some one test it on a >> real 2.3.3 device ? >> >> -- Passos >> >> >> On Wed, Apr 30, 2014 at 10:27 AM, Andrea Vibelli < > avibelli@ > >wrote: >> >> > Hi all, >> > after some searches, I finally found which version of >> > google-play-services.jar is included inside the Cordova Push Plugin, >> inside >> > src/android/libs folder. >> > >> > This version comes from: >> > >> > >> ${ANDROID_HOME}/extras/google/google_play_services_froyo/libproject/google-play-services_lib/libs >> > >> > I have tested the Cordova Push Plugin (tag 0.5.0) on a Android 4.1.1 >> > device and everything works well, then replaced >> google-play-services.jar >> > inside the src/android/libs folder with the latest version of it, taken >> > from: >> > >> > >> > >> ${ANDROID_HOME}/extras/google/google_play_services/libproject/google-play-services_lib/libs >> > >> > and that worked also without problems. >> > >> > I would ask if someone can make this test on more old devices as I do >> not >> > have any (so using the latest version of google-play-services.jar >> inside >> > the Cordova Push Plugin on devices prior to 4.1.1). If that works I >> would >> > suggest to replace the old library inside the plugin with the latest >> one >> > distributed by Google's SDK, what do you think about it? >> > >> > Thanks >> > Andrea >> > _______________________________________________ >> > aerogear-dev mailing list >> > > aerogear-dev at .jboss >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at .jboss > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Google-play-services-version-inside-Cordova-Push-Plugin-tp7626p7635.html Sent from the aerogear-dev mailing list archive at Nabble.com.