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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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 <michi.oshima(a)gmail.com&gt; wrote: Hi, I'm trying to adapt the sample code under aerogear-simplepush-unifiedpush-quickstart<https://github.com/aerogear... my application. I'm having a problem inside spConnect() function<https://github.com/aerogear/aerogear-simplepush-unifiedpush-q... . 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(...)<https://github.com/aerogear/aerog... . 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<https://github.com/aerogear/aerogear-simplepush-unifiedpush-quick...;, 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi Sebastian, It makes sense, but I do need the value of pushEndpoint in this another line<https://github.com/aerogear/aerogear-simplepush-unifiedpush-quick...;. 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 <scm.blanc(a)gmail.com&gt;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<https://github.com/aerogear/aerogear-simplepush-unifiedpush-quick... , > 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 <lholmqui(a)redhat.com&gt;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 <michi.oshima(a)gmail.com&gt; wrote: >> >> Hi, >> >> I'm trying to adapt the sample code under >> aerogear-simplepush-unifiedpush-quickstart<https://github.com/aerogear... my application. I'm having a problem inside spConnect() >> function<https://github.com/aerogear/aerogear-simplepush-unifiedpush-q... >> . >> >> 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(...)<https://github.com/aerogear/aerog... >> . >> >> 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<https://github.com/aerogear/aerogear-simplepush-unifiedpush-quick...;, >> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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 <matzew(a)apache.org&gt;wrote: > > > > On Tue, Apr 1, 2014 at 9:57 PM, Michi Oshima <michi.oshima(a)gmail.com&gt;wrote: > >> Hi Sebastian, >> >> It makes sense, but I do need the value of pushEndpoint in this another >> line<https://github.com/aerogear/aerogear-simplepush-unifiedpush-quick...;. >> 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 <scm.blanc(a)gmail.com&gt;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<https://github.com/aerogear/aerogear-simplepush-unifiedpush-quick... , >>> 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 <lholmqui(a)redhat.com&gt;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 <michi.oshima(a)gmail.com&gt; >>>> wrote: >>>> >>>> Hi, >>>> >>>> I'm trying to adapt the sample code under >>>> aerogear-simplepush-unifiedpush-quickstart<https://github.com/aerogear... my application. I'm having a problem inside spConnect() >>>> function<https://github.com/aerogear/aerogear-simplepush-unifiedpush-q... >>>> . >>>> >>>> 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(...)<https://github.com/aerogear/aerog... >>>> . >>>> >>>> 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<https://github.com/aerogear/aerogear-simplepush-unifiedpush-quick...;, >>>> 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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-G... [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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev