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@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@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@gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> answers inline
>>>>
>>>> On May 2, 2014, at 11:37 PM, Jay Balunas <jbalunas@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@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@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@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@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@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@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@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@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@lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev@lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev