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

Tue May 6 03:10:29 EDT 2014

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140506/900537ac/attachment.html 