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

Tue May 6 09:31:21 EDT 2014

On Tue, May 6, 2014 at 3:26 PM, Burr Sutter <bsutter at redhat.com> wrote:

> Number 2
>
> Broadcast push for new contact/customer to all users/salespeople
> Cordova-ized for iOS and Android
> Native Objective-C & Android Java impls as well, is that about right?
>
yes

>
>
>
> On May 6, 2014, at 9:07 AM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > 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_securedAuthormuststay 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
> > _______________________________________________
> > 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/72c5c484/attachment-0001.html 