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

Tue May 6 09:07:24 EDT 2014

2 sounds reasonable, go for it

On 2014-05-06, Matthias Wessendorf wrote:
> yes, sounds like 2) is the way to go
>
>
> On Tue, May 6, 2014 at 9:10 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>
> > 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 at gmail.com>wrote:
> >
> >> Hi,
> >>
> >> answers inline
> >>
> >> On May 2, 2014, at 11:37 PM, Jay Balunas <jbalunas at redhat.com> 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 at redhat.com> 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 at gmail.com>
> >> 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 at redhat.com>
> >> 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 at redhat.com> 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 at gmail.com>
> >> 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 at redhat.com> 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 at gmail.com>
> >> 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 <edewit at redhat.com> 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
> >> >>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> aerogear-dev mailing list
> >> >>>> aerogear-dev at lists.jboss.org
> >> >>>> https://lists.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


--

abstractj