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

Tue May 6 04:51:35 EDT 2014

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