Re: [aerogear-dev] contacts-mobile-basic quick start

Anyone else ? If we all agree I can adapt the temporary backend I deployed including this new behaviour. Sebi On Mon, May 5, 2014 at 9:34 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt;wrote: > Hi, > > answers inline > > On May 2, 2014, at 11:37 PM, Jay Balunas <jbalunas(a)redhat.com&gt; wrote: > > > I wanted to chime in here on additional/related items around the > contacts use-case and specifically around how to integrate push. Some of > these have already been discussed so just getting in one place for my own > sanity :-) > > > > 1) I agree that users and "contacts" are separate things. I think it > is best to think about them as was mentioned below - users (employees) and > contacts (customers, leads, etc...). This is easier to grok imo and could > be helped by some simple wording in the UI. > > +1 > > > > Cons: > > ** We then need a way to add "users" - otherwise we won't be sending > many push messages. Maybe users could be automatically created when an app > first accesses the backend? > > already the backend provides endpoints for creation of “users”, as well > as a list of default users initialised once the app is first loaded. By > default when a new user is created the security role assigned to it doesn’t > allow the creation of new contacts, you get back an “Unauthorised” error. > It doesn’t effect push per se, since an “admin” user can create a contact > and the notification can be send to all other users that are logged in, but > we should document this behaviour. > > > > > 2) Simplifying the push use-case: If we change the use-case from > saying hi to specific contacts to notifying all users when a new contact > was created it could simplify not only the UI, but the server side > processing for the push. We could reserve the more specific push usage to > the console, and/or AeroDoc. > > > > If we go with 2) we might be able to avoid the issues with 1) > altogether because a broadcast would send to every app that has registered. > > > > Wdyt? > > I am +1 on this behaviour. IMHO its more clear for the end-user and the > actual notification is used to “alert” for a change on the server part that > the app can decided to respond (e.g. fetch the new contact list). > > Thanks, > Christos > > > > > > > > On May 1, 2014, at 10:46 AM, Burr Sutter <bsutter(a)redhat.com&gt; wrote: > > > >> Joshua owns the backend, let's see if he has a thought on this item. > >> > >> On May 1, 2014, at 7:25 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; > wrote: > >> > >>> Hi everyone, > >>> > >>> have started working on the iOS native client of the contacts quick > start app. Based on edewit branch[1] (which creates a contact on signup of > a user) have created an initial version of the iOS client and you can find > it here [2], together with a screencast showcasing the app in action [3]. > >>> > >>> Some comments observed during writing of the application which would > like your feedback: > >>> > >>> a) for PUT, DELETE operations noticed that the jax-rs backend > expects the id of the Contact to be present in the body of the request. Not > sure why this was chosen instead of @Path(“id”) resulting against > /contacts/{id} ? > >>> > >>> b) currently roles are used to distinguish between who is able to > create/update/delete contact. When a user signs up (and contact is > created), by default the user is _not_ able to apply any CRUD operations > apart from viewing (any operation results in unauthorised error). If we > agree on this behaviour, would like to know how can I determine the role of > the user (in order to update the UI accordingly, eg. disabling add,edit UI > elements). Looking at the json response upon login of the user, couldn’t > determine a “key” that specifies the role (apart from an “admin” key which > stayed the same regardless of the type of the user). > >>> > >>> > >>> Thanks, > >>> Christos > >>> > >>> [1] > https://github.com/edewit/jboss-wfk-quickstarts/tree/push_and_secured > >>> [2] https://github.com/cvasilak/aerogear-push-quickstarts/tree/ios > >>> [3] https://vimeo.com/93471554 > >>> > >>> > >>> > >>> On Apr 23, 2014, at 5:43 PM, Erik Jan de Wit <edewit(a)redhat.com&gt; > wrote: > >>> > >>>> 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 <bsutter(a)redhat.com&gt; 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 <scm.blanc(a)gmail.com&gt; > 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 <edewit(a)redhat.com&gt; 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 <scm.blanc(a)gmail.com&gt; > 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_sec... stay because the receiver must know who sends the message. > >>>>>>>> > >>>>>>>> Envoyé de mon iPhone > >>>>>>>> > >>>>>>>>> Le 23 avr. 2014 à 13:35, Erik Jan de Wit <edewit(a)redhat.com&gt; 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(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 > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > > > > > > _______________________________________________ > > 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