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> 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> 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> 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>
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>
>>> 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>
>>> 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> 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>
>>> 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> 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>
>>> 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...
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(a)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(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