March 2013 - aerogear-dev - Jboss List Archives

need help in starting with aerogear controller

by soumik.basu

Hi, I have just started with aerogear controller. I went through http://aerogear.org/docs/guides/aerogear-controller/ link and tried to configure and deploy the MVC ROUTES and RESTful routes in my jbossAS7 server from my eclipse juno environment. In the server console I can see that the war got deployed successfully and it started listening to the CDI also. But while trying to access the MVC or Restful Route from my Chrome browser I got a 404 error. Looking for a help in this issue. I am sure I am making a minor configuration mistake, but need to resolve that at the earliest to move ahead. Thanks in advance. Regards Soumik -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/need-help-in-starting-with-aero... Sent from the aerogear-dev mailing list archive at Nabble.com.

11 years, 11 months

4
12
0 / 0

iOS API cookbook examples

by Christos Vasilakis

Hi, for the needs of [1] we created a page that collectively has code examples for all the different subsystems available in iOS. Much of the content used to reside in API.md [2], but now that we have moved it inside the API documentation, we though it would be better instead of removing the file completely, to convert it to a web page that will be hosted on our web site. I have converted to asciidoc and added some more content for the basic concept of the available iOS subsystems. The result can be found here [3] Wdyt? Thanks Christos [1] https://issues.jboss.org/browse/AEROGEAR-1007 [2] https://github.com/aerogear/aerogear-ios/blob/master/API.md [3] http://tinyurl.com/cnvb6e6

11 years, 11 months

3
7
0 / 0

FYI - JIRA epics/grouping tickets for unified push

by Matthias Wessendorf

These are the epics for push: https://issues.jboss.org/browse/AEROGEAR-970 https://issues.jboss.org/browse/AEROGEAR-1034 https://issues.jboss.org/browse/AEROGEAR-1035 https://issues.jboss.org/browse/AEROGEAR-1036 https://issues.jboss.org/browse/AEROGEAR-1037 https://issues.jboss.org/browse/AEROGEAR-1038 TBD: add (concrete) sub tasks... -M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

11 years, 11 months

1
0
0 / 0

{AG Controller - User Guide} A few questions

by Matthias Wessendorf

Hi, I read the guide (http://staging.aerogear.org/docs/guides/aerogear-controller/) nice work!!!! However I have a few questions: ===== http://staging.aerogear.org/docs/guides/aerogear-controller/routes.html 1) public class Routes extends AbstractRoutingModule { @Override public void configuration() { route() .from("/cars/{id}") .on(RequestMethod.GET) .produces(JSON) .to(Cars.class).findById(param("id")); } ====> Could I access this only via a JSON request (e.g. "curl -v -H "Content-type: application/json" -X GET http........./cars/123") or also via browser (http://......../cars/123) ? 2) Parameters Route endpoints currently support the following types of parameters which are all configured by using the param method: Path Query Form Header Cookie ==> Can that be differentiated ? (e.g. path, query) Not sure I understand the above - perhaps an example helps? ==> What happens with header "foo" and param "foo" ? http://staging.aerogear.org/docs/guides/aerogear-controller/pagination.html 1) Should we add a link to http://aerogear.org/docs/specs/aerogear-controller/org/jboss/aerogear/con... 2) NOT needed (not now) - but perhaps a simple PaginationStrategy could be shown (or a link to a test case that tests a custom PaginationStrategy)? http://staging.aerogear.org/docs/guides/aerogear-controller/cors.html 1) where would I typically be implementing a CORS CDI Producer? Nice work! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

11 years, 11 months

2
1
0 / 0

[AG security] Handling mutliple login flows for the same user

by Sebastien Blanc

Hi Folks, I started this thread to figure out how to handle a particular situation. Currently when we log in into an application using ag-security-pl (and implicitly through picketlink) and the user was already logged in, we get a "UnexpectedCredentialException". The Aerogear Controller Demo, for example, handle this exception by displaying an error page telling : "user already logged in, maybe you should log out". But I was really thinking of where relies the responsibility of handling this very common use case (the same is applicable for the "register" flow) : I have user Bob who has his *Device A* and* B* using Application *SlackerApp * : - He logs into *SlackerApp* with *Device A*. - While still logged in with *Device A*, he logs into *SlackerApp* with *device B* (for a concrete example think of Bob using twitter on his laptop when working and his mobile when he is at the bathroom). In this situation, the log in flow for *Device B* will have to handle a * UnexpectedCredentialException*, I see 3 situations for handling this : - *SlackerApp *handle the exception : - by swallowing it and returns a successful log in status, - throwing a error page (which can be strange for Bob who wants to use his app on device B) -* AG security* handle the exception : - by swallowing it and returns a successful log in status, -throwing a http status - *PicketLink *handle the exception : - by swallowing it and returns a successful log in status, -throwing a http status I'm just wondering what is the best way to handle this Seb

11 years, 11 months

2
1
0 / 0

[ag-security-plink] Data sources

by Summers Pittman

Is it possible to use the picketlink dependency if I don't have a data source named "java:jboss/datasources/ExampleDS"? I havn't been able to find anyway of overriding it short of nuking the persistence.xml file in the dependency Google hasn't offered up any good suggestions.

11 years, 11 months

4
10
0 / 0

[RFC] Initial Versioning Policy

by Douglas Campos

Thoughts? -- cut here -- # AeroGear Versioning Policy For this 1.0.0 release and beyond we're planning some significant changes on how we do versioning for the project. ## TL;DR We're sticking to the de-facto standard of `major`.`minor`.`patchlevel`, mostly know as Semantic Versioning, or just [semver]. ## A bit of history During the early days of the project, we started following the [JBoss Project Versioning] - at that time our assets were mostly Java. Then we found out later that we were doing it wrong, because we forgot the timestamp part of the milestone releases. ## Getting it right So we're going to release 1.0.0 in a few days, and we'll drop the suffixes and work with versions like this: - **bugfixes**: - increment `patch` (1.0.0 -> 1.0.1) Bugfixes and minor changes: keeps API compatibility - **new features and small breaking changes**: - increment `minor` (1.0.1 -> 1.1.0) **Small breaking changes** means that some work **may** be needed for updating beetween minor versions. - **major releases**: - increment `major` (1.1.0 -> 2.0.0) Mostly backward incompatible changes and/or when a group of big features is ready. Any release can use the discriminators .alpha/.beta/.pre for testing, those are sorted right. [semver]:http://semver.org [JBoss Project Versioning]:https://community.jboss.org/wiki/JBossProjectVersioning -- qmx

11 years, 11 months

10
9
0 / 0

Next steps for Push (was: Re: AeroGear Unified Push - Abstraction layer for "push enabled apps" (was: Re: [AG Push] BASIC (and INITAL) use cases of the Unified Push Server))

by Matthias Wessendorf

hijacking threads - FTW So... that feedback was great... and I am still hoping for more input on the OTHER thread... So... here is my proposal: I wait for today/monday for more feedback and I will THAN move all the ideas into a OVERALL doc - which will endup on the homepage; Also, I'll start implementing that SERVER, using vert.x - where the service/server itself is accessible via HTTP/REST (only) Thoughts? On Fri, Mar 15, 2013 at 1:47 PM, Matthias Wessendorf <matzew(a)apache.org> wrote: > > > > On Fri, Mar 15, 2013 at 1:28 PM, tech4j(a)gmail.com <tech4j(a)gmail.com> wrote: >> >> >> >> >> On Fri, Mar 15, 2013 at 8:25 AM, Matthias Wessendorf <matzew(a)apache.org> wrote: >>> >>> >>> >>> On Fri, Mar 15, 2013 at 1:15 PM, tech4j(a)gmail.com <tech4j(a)gmail.com> wrote: >>>> >>>> A few small comments, because I think this is looking pretty good. >>>> >>>> * At first glance I like the idea of having it be a registry instead of a manager. In some ways that makes it more obvious this a logical construct. >>>> >>>> * Another use case: "Other services inside of JBoss could use the push manager/registry, for example the admin console, Errai, drools, etc..." >>>> ** I.e. not just for end user apps >>> >>> >>> >>> I think that's what I tried to address with this statement: "We want that any (JBoss/AeroGear powered) mobile application, that is backed by JBoss technology, is able to easily work with push messages. For a JBoss "backend application" it should be as simple as possible, to send messages to its different mobile clients" >>> >>> ==> should not be tied to a specific backend; For instance a JSF managed bean you use the "Sender" as well - to push out messages to 'its' configured mobile apps (on the registration) >> >> >> ok, then yes, same page >> >>> >>> >>>> >>>> >>>> * The non-native push (JS, "connected" apps, etc...) imo would/should be separate and part of AeroGear proper. I think having both functions in this one shared service would make it too complex, and hard to cover other groups use-cases. As I see it for AeroGear - we receive a msg/event/trigger that we want to send to clients. The API allows developers to say "send msg to x, y, z users/devices". AeroGear checks for any apps that are "connected" and sends a non-native push msg to those clients. AeroGear then determines who did not get a "connected" msg (that may be tricky), and uses the API your defining to send those users native push msg. >>> >>> >>> You mean breaking into two components? >>> - native push >>> - web based push >>> >>> and an overall API on top that 'aggregates'? >> >> >> Yes, and yes :-) > > > > Ah - great! > > I think that is a great idea, since the "non-native" web-push is really a different case, and there are lot's of different impls - having that piece separated, makes it easier to actually implement the native push thing > >> >> >>> >>> >>>> >>>> >>>> ** The API would have a way to set only "connected", only native, etc... as well. >>>> >>>> * In the future and maybe as a POC that this can work with non-aerogear clients we could see about getting push messages setup with Christos' JBoss admin app with this. Not a priority, but an idea :-) >>>> >>>> >>>> >>>> >>>> On Fri, Mar 15, 2013 at 6:56 AM, Matthias Wessendorf <matzew(a)apache.org> wrote: >>>>> >>>>> >>>>> >>>>> On Fri, Mar 15, 2013 at 11:27 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 15, 2013 at 10:58 AM, Matthias Wessendorf <matzew(a)apache.org> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 15, 2013 at 10:48 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote: >>>>>>>> >>>>>>>> Great Job, >>>>>>>> see my comments inline. >>>>>>>> >>>>>>>> On Fri, Mar 15, 2013 at 10:07 AM, Matthias Wessendorf <matzew(a)apache.org> wrote: >>>>>>>>> >>>>>>>>> As discussed on the earlier theard, we have some raw APIs... Below a little summary: >>>>>>>>> >>>>>>>>> We have a UnifiedPushManager(.java) defined, which is basically a registry for "push enabled" apps (PushApplication.java). Such a PushApplication is a logical construct on the backend which is allowed/enabled to send notifications to mobile clients. One example could be the "Twitter Backend" (e.g. for push notification on direct messages). >>>>>>>> >>>>>>>> As you said the manager is here more a registry than a manager in the current state, maybe we should have a PushApplicationRegistry interface which has as only responsibility to hold the register state, >>>>>>> >>>>>>> >>>>>>> Can you gist ? >>>>>> >>>>>> >>>>>> Take a look at my fork https://github.com/sebastienblanc/ag-unified-push-api/tree/registry ;) >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> the implementation of the registry will connect to the chosen persistence unit (JPA/Mongo/Oracle ...). >>>>>>> >>>>>>> >>>>>>> Not sure I really want to that - now :) I am (for first iteration) fine to have something running, instead of being that flexible and be able to go with any existing "data source" :-) >>>>>> >>>>>> >>>>>> Well, for sure, for the first iteration we will provide a default implementation. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> This way we could have a concrete implementation of the UnifiedPushManager than can be used by different backend/customers (think DRY) , they just have to inject the needed PushApplicationRegistry implementation. >>>>>>> >>>>>>> >>>>>>> Not sure what exactly you mean - perhaps a gist / pseudo code is helpful here too ? >>>>>> >>>>>> >>>>>> Again, my fork should help you understanding https://github.com/sebastienblanc/ag-unified-push-api/tree/registry but basically, it is the same as your code except I apply the delegate pattern. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Now each of the PushApplication can have a few mobile applications, that receive those push messages (e.g. the offical Twitter iOS client and the offical Twitter Android client). These "mobile apps" are represented - on the server - with the MobileApplication.java class. Usually there is only one iOS app and one Android... BUT imagine the case of a "paid/premium app" versus a free app (e.g. something like TwitterPro-iOS and Twitter-free-iOS... NOTE: there is NOTHING like that, I just made these two apps up, to explain the concept). >>>>>>>>> >>>>>>>>> Of course there are several installations of the iOS(and Android...) app. Each installation is represented with theMobileApplicationInstance.java class. Each installation is registered by a "device registration service": The actual app on the device submits its token/regId (and some other infos) to a HTTP endpoint.... >>>>>>>>> >>>>>>>>> Now the UnifiedPushManager(.java) is the central API to register PushApps and their mobile views, including (device)registration of installations (-> MobileApplication and MobileApplicationInstance). >>>>>>>>> >>>>>>>>> Any backend app, can now use the Sender API to actually send the message to these different devices/appications, from the UnifiedPushManager, assuming they have permission :-) >>>>>>>>> >>>>>>>>> A simple example is here (java code for registration AND sending); Note it's a Unit test.......: https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/o... >>>>>>>> >>>>>>>> >>>>>>>> Maybe the Sender interface should be an attribute of the PushManager, the customer can set his Sender impl (pushManager.setSender(...) ) and the UnifiedManager act as a facade for the "sending" actions. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hrm - you really think folks will write their own "Senders"? I think... if they want to add support for "Windows Mobile", they just have to extend the abstract MobileApplicationImpl and implement it's send() to talk to the Windows Push infrastrucuture >>>>>> >>>>>> >>>>>> Again, we will provide a default sender implementation. But I seee indedd issues, having a single senders for different platforms , hum, let me think about this ;) >>>>> >>>>> >>>>> >>>>> the Sender() is an aggregate of the different mobile Application's "send()" - it will enqueue the message for the different platforms >>>>> >>>>> >>>>> thanks for the feedback - will check ur fork >>>>> >>>>> >>>>> -M >>>>> >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> PERHAPS... just using interfaces was confusing - there will be concrete classes (first impl is in the TEST project (see other thread)), but the interfaces are a highlevel view of the "domain model" >>>>>>> >>>>>>>>> >>>>>>>>> So far, so good - but why this abstraction ???? >>>>>>>>> >>>>>>>>> Goal: We want that any (JBoss/AeroGear powered) mobile application, that is backed by JBoss technology, is able to easily work with push messages. For a JBoss "backend application" it should be as simple as possible, to send messages to its different mobile clients >>>>>>>>> >>>>>>>>> Some Scenarios >>>>>>>>> >>>>>>>>> MyWarehouseInc-backend can send messages to different "customer" groups (e.g. discounts for only iOS (or only Android) users). >>>>>>>>> MyInsuranceCorp-backend can send important "info messages" to diffenrent variants of its mobile Applications (e.g. to the MyInsuranceCustomer-APP (regardless of the OS) AND to the app for their own agents (MyInsuranceAgent-APP)) >>>>>>>>> MyPublishing-Company-backend sends updates to all of its apps (free and premium - regardless of the mobile OS). Advanced content is only push to the paying customers... >>>>>>>>> A company has different backends (small apps for different tasks) - and these different backends could be able to reach all of the company's mobile apps >>>>>>>>> >>>>>>>>> So... the Sender somewhat acts as a broker (for accessable apps on the 'registry' UnifiedPushManager)... >>>>>>>> >>>>>>>> >>>>>>>> Maybe we should define some kind of "Application" Collection, as smart/specific Java Collection implementation to be able to create easily groups of apps etc .. just a rough idea that needs to be cleaned up ;) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Something like that would be neat, for more advanced queries / selection etc >>>>>> >>>>>> >>>>>> We could have a (very) simple query language specific for Push Apps, like hibernate, we could query by example. In my fork you will see an extremely basic Query object ... >>>>>>> >>>>>>> >>>>>>> Thanks for the feedback! >>>>>>> -M >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> BTW... none!!!!!!! of the API names are final - happy to hear better names!!! >>>>>>>>> >>>>>>>>> Please provide feedback (here and on the other thread), for missing/wrong/good items.! >>>>>>>>> >>>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 14, 2013 at 6:58 PM, Matthias Wessendorf <matzew(a)apache.org> wrote: >>>>>>>>>> >>>>>>>>>> here is, including device registration: >>>>>>>>>> >>>>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/o... >>>>>>>>>> >>>>>>>>>> All hammered in java... since this is a test - most of the code will be executed, when interacting with HTTP endpoints of the thing; >>>>>>>>>> >>>>>>>>>> Yes, there is no JS application in the test - but we do have an abstraction interface for it: >>>>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o... >>>>>>>>>> >>>>>>>>>> Connected? Since only "online" JS clients are receiving message - there no real "push to device" for the JS world... >>>>>>>>>> >>>>>>>>>> -Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 14, 2013 at 3:41 PM, Matthias Wessendorf <matzew(a)apache.org> wrote: >>>>>>>>>>> >>>>>>>>>>> Pushed FIRST/TEST impl + actually test case..... >>>>>>>>>>> >>>>>>>>>>> https://github.com/matzew/ag-unified-push-api >>>>>>>>>>> >>>>>>>>>>> YEs.... I have 'xxx'd out the KEY and certs :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 14, 2013 at 11:04 AM, Matthias Wessendorf <matzew(a)apache.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>> My UNIT test looks (currently) like: >>>>>>>>>>>> >>>>>>>>>>>> https://gist.github.com/matzew/3d7f9915afd8f6705da5 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -M >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 13, 2013 at 11:03 PM, Matthias Wessendorf <matzew(a)apache.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 13, 2013 at 10:06 PM, tech4j(a)gmail.com <tech4j(a)gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think this is look really good! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here some thoughts, and/or possible additional use-cases >>>>>>>>>>>>>> >>>>>>>>>>>>>> * How do we want to handle multiple devices for one user? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Instance of 'MobileApplicationInstance'; each device has (per app) a different token; >>>>>>>>>>>>> What the apps do themselves, with multiple installs is something different. >>>>>>>>>>>>> >>>>>>>>>>>>> Twitter, for instance, sends the push-messages to EVERY device - but that's app specific sync >>>>>>>>>>>>> (yes, i wish there was something like IMAP, for twitter) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> * How do we want to handle the other side of unified push (non-native)? >>>>>>>>>>>>>> ** Might just not be there yet, but want to make sure we're still thinking the same thing :-) >>>>>>>>>>>>>> ** Would there be an additional abstraction above this for that? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> some sub type of 'MobileApplication' can/will cover that "mobile web" (JS client) side: >>>>>>>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o... >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> * I'm assuming there is no good way for apps to notify you when they are uninstalled? >>>>>>>>>>>>>> ** As a way of removing clutter in our tables. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> In apple land these are invalid tokens (see https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoo...) >>>>>>>>>>>>> So, on a scheduled base they can be remove; >>>>>>>>>>>>> >>>>>>>>>>>>> Google has similar API (on their MulticastResult (returned by the sender)) >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Push filtering - I would think IDM would be very good here. >>>>>>>>>>>>>> ** Sending to roles, groups, etc... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> have different users (==roles), but not spec'd out >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** When we store the device and app info what sub-system are you thinking? >>>>>>>>>>>>>> *** I know you were using mongo for some of the prototyping >>>>>>>>>>>>>> *** Would be possible to abstract to the IDM? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> yes, it should be possible (desirable) to use IDM - but does not really matter >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the feedback!!! >>>>>>>>>>>>> >>>>>>>>>>>>> -Matthias >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx(a)qmx.me> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 13/03/2013, at 10:28, Matthias Wessendorf <matzew(a)apache.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > ome more APIs, for some basic (initial) functionality: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > https://gist.github.com/matzew/c5fbc23bc97dfead46e1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I like the current form, but I'm sure we'll get asked about more OO(ish) APIs, like device.send(Message) - is this on the plans? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > User/Dev enrollment can be addressed by (hopefully) reusing the ag-security. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- qmx >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> blog: http://in.relation.to/Bloggers/Jay >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Matthias Wessendorf >>>>>>>>>>>>> >>>>>>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Matthias Wessendorf >>>>>>>>>>>> >>>>>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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(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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>>> >>>> >>>> >>>> -- >>>> blog: http://in.relation.to/Bloggers/Jay >>>> >>>> _______________________________________________ >>>> 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 >> >> >> >> >> -- >> blog: http://in.relation.to/Bloggers/Jay >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

11 years, 11 months

3
3
0 / 0

AeroGear Unified Push - Abstraction layer for "push enabled apps" (was: Re: [AG Push] BASIC (and INITAL) use cases of the Unified Push Server)

by Matthias Wessendorf

As discussed on the earlier theard, we have some raw APIs... Below a little summary: We have a UnifiedPushManager(.java) defined, which is basically a registry for "push enabled" apps (PushApplication.java). Such a PushApplication is a logical construct on the backend which is allowed/enabled to send notifications to mobile clients. One example could be the "Twitter Backend" (e.g. for push notification on direct messages). Now each of the PushApplication can have a few mobile applications, that receive those push messages (e.g. the offical Twitter iOS client and the offical Twitter Android client). These "mobile apps" are represented - on the server - with the MobileApplication.java class. Usually there is only one iOS app and one Android... *BUT* imagine the case of a "paid/premium app" versus a free app (e.g. something like TwitterPro-iOS and Twitter-free-iOS... *NOTE*: there is NOTHING like that, I just made these two apps up, to explain the concept). Of course there are several installations of the iOS(and Android...) app. Each installation is represented with theMobileApplicationInstance.java class. Each installation is registered by a "device registration service": The actual app on the device submits its token/regId (and some other infos) to a HTTP endpoint.... Now the UnifiedPushManager(.java) is the central API to *register* PushApps and their mobile views, including (device)registration of installations (-> MobileApplication and MobileApplicationInstance). Any backend app, can now use the *Sender API* to actually send the message to these different devices/appications, from the UnifiedPushManager, assuming they have permission :-) A simple example is here (java code for registration AND sending); Note it's a Unit test.......: https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/o... <https://gist.github.com/matzew/73d478a42c093e21a6b9#so-far-so-good---but-...>So far, so good - but why this abstraction ???? *Goal*: We want that any (JBoss/AeroGear powered) mobile application, that is backed by JBoss technology, is able to easily work with push messages. For a JBoss "backend application" it should be as simple as possible, to send messages to its different mobile clients <https://gist.github.com/matzew/73d478a42c093e21a6b9#some-scenarios>Some Scenarios - MyWarehouseInc-backend can send messages to different "customer" groups (e.g. discounts for only iOS (or only Android) users). - MyInsuranceCorp-backend can send important "info messages" to diffenrent variants of its mobile Applications (e.g. to the MyInsuranceCustomer-APP (regardless of the OS) AND to the app for their own agents (MyInsuranceAgent-APP)) - MyPublishing-Company-backend sends updates to all of its apps (free and premium - regardless of the mobile OS). Advanced content is only push to the paying customers... - A company has different backends (small apps for different tasks) - and these different backends could be able to reach all of the company's mobile apps So... the Sender somewhat acts as a broker (for accessable apps on the 'registry' UnifiedPushManager)... BTW... none!!!!!!! of the API names are final - happy to hear better names!!! Please provide feedback (here and on the other thread), for missing/wrong/good items.! Greetings, Matthias On Thu, Mar 14, 2013 at 6:58 PM, Matthias Wessendorf <matzew(a)apache.org>wrote: > here is, including device registration: > > > https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/o... > > All hammered in java... since this is a test - most of the code will be > executed, when interacting with HTTP endpoints of the thing; > > Yes, there is no JS application in the test - but we do have an > abstraction interface for it: > > https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o... > > Connected? Since only "online" JS clients are receiving message - there no > real "push to device" for the JS world... > > -Matthias > > > On Thu, Mar 14, 2013 at 3:41 PM, Matthias Wessendorf <matzew(a)apache.org>wrote: > >> Pushed FIRST/TEST impl + actually test case..... >> >> https://github.com/matzew/ag-unified-push-api >> >> YEs.... I have 'xxx'd out the KEY and certs :) >> >> >> On Thu, Mar 14, 2013 at 11:04 AM, Matthias Wessendorf <matzew(a)apache.org>wrote: >> >>> My UNIT test looks (currently) like: >>> >>> https://gist.github.com/matzew/3d7f9915afd8f6705da5 >>> >>> >>> >>> -M >>> >>> >>> >>> >>> On Wed, Mar 13, 2013 at 11:03 PM, Matthias Wessendorf <matzew(a)apache.org >>> > wrote: >>> >>>> >>>> >>>> On Wed, Mar 13, 2013 at 10:06 PM, tech4j(a)gmail.com <tech4j(a)gmail.com>wrote: >>>> >>>>> I think this is look really good! >>>>> >>>>> Here some thoughts, and/or possible additional use-cases >>>>> >>>>> * How do we want to handle multiple devices for one user? >>>>> >>>> >>>> Instance of 'MobileApplicationInstance'; each device has (per app) a >>>> different token; >>>> What the apps do themselves, with multiple installs is something >>>> different. >>>> >>>> Twitter, for instance, sends the push-messages to EVERY device - but >>>> that's app specific sync >>>> (yes, i wish there was something like IMAP, for twitter) >>>> >>>> >>>> >>>>> >>>>> * How do we want to handle the other side of unified push (non-native)? >>>>> ** Might just not be there yet, but want to make sure we're still >>>>> thinking the same thing :-) >>>>> ** Would there be an additional abstraction above this for that? >>>>> >>>> >>>> some sub type of 'MobileApplication' can/will cover that "mobile web" >>>> (JS client) side: >>>> >>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o... >>>> >>>> >>>>> >>>>> * I'm assuming there is no good way for apps to notify you when they >>>>> are uninstalled? >>>>> ** As a way of removing clutter in our tables. >>>>> >>>> >>>> In apple land these are invalid tokens (see >>>> https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoo... >>>> ) >>>> So, on a scheduled base they can be remove; >>>> >>>> Google has similar API (on their MulticastResult (returned by the >>>> sender)) >>>> >>>> >>>>> >>>>> * Push filtering - I would think IDM would be very good here. >>>>> ** Sending to roles, groups, etc... >>>>> >>>> >>>> have different users (==roles), but not spec'd out >>>> >>>> >>>>> ** When we store the device and app info what sub-system are you >>>>> thinking? >>>>> *** I know you were using mongo for some of the prototyping >>>>> *** Would be possible to abstract to the IDM? >>>>> >>>> >>>> yes, it should be possible (desirable) to use IDM - but does not really >>>> matter >>>> >>>> >>>> Thanks for the feedback!!! >>>> >>>> -Matthias >>>> >>>> >>>> >>>>> >>>>> On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx(a)qmx.me> wrote: >>>>> >>>>>> >>>>>> On 13/03/2013, at 10:28, Matthias Wessendorf <matzew(a)apache.org> >>>>>> wrote: >>>>>> >>>>>> > ome more APIs, for some basic (initial) functionality: >>>>>> > >>>>>> > https://gist.github.com/matzew/c5fbc23bc97dfead46e1 >>>>>> >>>>>> I like the current form, but I'm sure we'll get asked about more >>>>>> OO(ish) APIs, like device.send(Message) - is this on the plans? >>>>>> >>>>>> > User/Dev enrollment can be addressed by (hopefully) reusing the >>>>>> ag-security. >>>>>> >>>>>> +1 >>>>>> >>>>>> -- qmx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> blog: http://in.relation.to/Bloggers/Jay >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> 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

11 years, 11 months

5
13
0 / 0

iOS xCode Template

by Christos Vasilakis

Hi, I've created an quick-start example here[1] that will be used as an Xcode template [2] (think of it as maven archetype for iOS) for our users to easily get started with the framework. Prior to create the config required to produce the template, I would like to have your opinion on what else should be included in the base demo. Currently it connects to our TODO demo, retrieves the tasks and updates a table view component. I think it serves as a good basis for users to extend. Wdyt? Thanks Christos [1] https://github.com/cvasilak/AeroGearPrototype [2] http://tinyurl.com/bvhusuk

11 years, 11 months

4
13
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

aerogear-dev March 2013