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

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?

On May 6, 2014, at 9:07 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; 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(a)gmail.com&gt; 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(a)gmail.com >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... 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 >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > _______________________________________________ > 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