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

Tue May 6 09:26:04 EDT 2014

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 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_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
> 
>> _______________________________________________
>> 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