+1 that's the correct behavior.

On Wed, Jun 18, 2014 at 8:48 AM, Niranjan Karunanandham <[email protected]>
wrote:

> @Sameera: I just used a use case to example why we will have to kill the
> camera. As per the offline discussion we had, I agree with you that if the
> camera is in the foreground and a "disable camera" operation is sent, then
> the camera is killed and an appropriate message needs to be displayed to
> the user (depending on the policy). If it is in the background, then the
> camera is killed.
>
> Regards,
> Nira
>
>
> On Wed, Jun 18, 2014 at 8:06 AM, Sameera Perera <[email protected]> wrote:
>
>> Chan, Niranjan,
>> We are discussing specifically the context in which the agent receives a
>> "disable camera" policy while the the camera is in use: It is not on the
>> general use case of disabling the camera.
>>
>>
>> On Wed, Jun 18, 2014 at 2:25 AM, Chan <[email protected]> wrote:
>>
>>> ​How about making this configurable? For use cases like schools -
>>> students don't need to get warnings. It should just work!
>>>
>>> Cheers~​
>>>
>>>
>>> On Tue, Jun 17, 2014 at 7:00 PM, Niranjan Karunanandham <
>>> [email protected]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> IMO in EMM, it is the administrator of the organization who should have
>>>> the control. When the user (in the case of BYOD) agrees to the Policy
>>>> agreement before he enrolls to the EMM system to get access to organization
>>>> data. In such a case the administrator should ensure that the device
>>>> satisfies to the organization's policy. If it should be a warning message
>>>> only then it should be done by the Admin by setting the policy type to
>>>> Warning (Policy types are Acknowledge, Warning and Enforce), where in a
>>>> warning message is only displayed to the user. The enforce policy type
>>>> should enforce the policy if it gets violated. This is very important when
>>>> it comes to dynamic policy like policies vary with time for example: say
>>>> from 8am to 6pm, the camera is disabled during the weekend. Another one
>>>> will be geo-location based policies.
>>>>
>>>> Regards,
>>>> Nira
>>>>
>>>>
>>>> On Tue, Jun 17, 2014 at 4:24 PM, Harshan Liyanage <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Sameera,
>>>>>
>>>>> Yeah its due to UX issues. I think your suggestion is a better
>>>>> solution than merely killing the camera app.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Lakshitha Harshan
>>>>> Software Engineer
>>>>> Mobile: *+94724423048*
>>>>> Email: [email protected]
>>>>> Blog : http://harshanliyanage.blogspot.com/
>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>>>> lean.enterprise.middleware.
>>>>>
>>>>>
>>>>> On Tue, Jun 17, 2014 at 3:50 PM, Sameera Perera <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Harshan,
>>>>>> Why do you oppose killing the camera app?
>>>>>> I'm going to assume this is because of the intrusive UX; to have the
>>>>>> camera app close suddenly. But, if you post a warning prompt, this still
>>>>>> interrupts the user while he's on the camera.
>>>>>>
>>>>>>  once he has closed the camera app, we could disable the camera
>>>>>>
>>>>>>
>>>>>> I think the JIRA is saying that this is already working.
>>>>>>
>>>>>> if the user doesn't close it we will record it as a policy violation.
>>>>>>
>>>>>>
>>>>>> This maybe over-engineering it and perhaps not even the ideal
>>>>>> solution from the admin's perspective.
>>>>>>
>>>>>> If we kill the camera app and notify the user that the camera was
>>>>>> disabled by policy, wouldn't that work? (This is of course assuming the
>>>>>> answer to the first question is UX).
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 17, 2014 at 3:36 PM, Harshan Liyanage <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Kasun,
>>>>>>>
>>>>>>> What if we let the user know that he is violating a policy (as a
>>>>>>> Warning type policy) & once he has closed the camera app, we could 
>>>>>>> disable
>>>>>>> the camera or if the user doesn't close it we will record it as a policy
>>>>>>> violation.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Lakshitha Harshan
>>>>>>> Software Engineer
>>>>>>> Mobile: *+94724423048*
>>>>>>> Email: [email protected]
>>>>>>> Blog : http://harshanliyanage.blogspot.com/
>>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>>>>>> lean.enterprise.middleware.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 17, 2014 at 3:19 PM, Kasun Dananjaya Delgolla <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi Niranan/Harshan,
>>>>>>>>
>>>>>>>> Only way we can implement it without killing the process would be
>>>>>>>> implementing a listener on camera which is a bit difficult to achieve. 
>>>>>>>> If
>>>>>>>> we could do so, we can listen to the camera event and do the locking 
>>>>>>>> once
>>>>>>>> the camera is not in use. I will be researching more on this aspect and
>>>>>>>> will update you on this as soon as I get a workout.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 17, 2014 at 3:15 PM, Niranjan Karunanandham <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi Harshan,
>>>>>>>>>
>>>>>>>>> Please find my comments inline.
>>>>>>>>>
>>>>>>>>>     To handle this, we need to kill the camera process if it's
>>>>>>>>> running, before executing camera lock via the device administrator. 
>>>>>>>>> The
>>>>>>>>> reason is, android OS does not allow locking while user's using the 
>>>>>>>>> camera
>>>>>>>>> since it distracts the user experience. So before executing it, we 
>>>>>>>>> need to
>>>>>>>>> kill the camera process.
>>>>>>>>>   IMO killing a process is not a good way to do this. May be we
>>>>>>>>> could find alternative solution to achieve this.
>>>>>>>>> The reason that we need to kill the process is because if the user
>>>>>>>>> has it in the backend. When he registers to the EMM then if there is a
>>>>>>>>> policy to disable the camera then it won't work. In such a case the 
>>>>>>>>> user is
>>>>>>>>> able to register to the organization network but he is violating the
>>>>>>>>> policy. Also if the policy type is enforce and the user goes to the 
>>>>>>>>> device
>>>>>>>>> management screen and enable the camera, then it should automatically 
>>>>>>>>> get
>>>>>>>>> disable (if a camera disable policy is present for the device). 
>>>>>>>>> Either we
>>>>>>>>> need to kill the camera process or close it so that we can disable the
>>>>>>>>> camera.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Nira
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 17, 2014 at 3:05 PM, Harshan Liyanage <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please find my comments inline.
>>>>>>>>>>
>>>>>>>>>> 1. Camera disable during policy apply- jira-
>>>>>>>>>> https://wso2.org/jira/browse/EMM-648
>>>>>>>>>>
>>>>>>>>>>     To handle this, we need to kill the camera process if it's
>>>>>>>>>> running, before executing camera lock via the device administrator. 
>>>>>>>>>> The
>>>>>>>>>> reason is, android OS does not allow locking while user's using the 
>>>>>>>>>> camera
>>>>>>>>>> since it distracts the user experience. So before executing it, we 
>>>>>>>>>> need to
>>>>>>>>>> kill the camera process.
>>>>>>>>>>
>>>>>>>>>>   IMO killing a process is not a good way to do this. May be we
>>>>>>>>>> could find alternative solution to achieve this.
>>>>>>>>>>
>>>>>>>>>> 2. After Login, pending notification must be called- currently
>>>>>>>>>> takes time for first one to start
>>>>>>>>>>
>>>>>>>>>>    Currently our EMM Agent waits for a server push
>>>>>>>>>> notification/local push to be triggered to get the pending operation 
>>>>>>>>>> list
>>>>>>>>>> from the server for the first time after registration. So to make it 
>>>>>>>>>> a bit
>>>>>>>>>> faster, we are going to execute a pending operation call on register
>>>>>>>>>> success event.
>>>>>>>>>>
>>>>>>>>>>  I think this might improve first-user experience as well. So I'm +1
>>>>>>>>>> for calling pending operation call on the register success event.
>>>>>>>>>>
>>>>>>>>>> 3. Handle notifications so that it doesn't send unnecessary
>>>>>>>>>> network calls
>>>>>>>>>>
>>>>>>>>>>     (Ex: If the user sets 2 second notification interval, we do
>>>>>>>>>> not need to send continuous network calls if the first call has not 
>>>>>>>>>> given
>>>>>>>>>> the response)
>>>>>>>>>>
>>>>>>>>>> +1 for reducing unnecessary network overhead.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Lakshitha Harshan
>>>>>>>>>> Software Engineer
>>>>>>>>>> Mobile: *+94724423048*
>>>>>>>>>> Email: [email protected]
>>>>>>>>>> Blog : http://harshanliyanage.blogspot.com/
>>>>>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>>>>>>>>> lean.enterprise.middleware.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Jun 17, 2014 at 2:36 PM, Kasun Dananjaya Delgolla <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> I'm in the process of improving the EMM Android Agent and
>>>>>>>>>>> following are the improvement that I'm currently focusing on,
>>>>>>>>>>>
>>>>>>>>>>> 1. Camera disable during policy apply- jira-
>>>>>>>>>>> https://wso2.org/jira/browse/EMM-648
>>>>>>>>>>>
>>>>>>>>>>>     To handle this, we need to kill the camera process if it's
>>>>>>>>>>> running, before executing camera lock via the device administrator. 
>>>>>>>>>>> The
>>>>>>>>>>> reason is, android OS does not allow locking while user's using the 
>>>>>>>>>>> camera
>>>>>>>>>>> since it distracts the user experience. So before executing it, we 
>>>>>>>>>>> need to
>>>>>>>>>>> kill the camera process.
>>>>>>>>>>>
>>>>>>>>>>> 2. After Login, pending notification must be called- currently
>>>>>>>>>>> takes time for first one to start
>>>>>>>>>>>
>>>>>>>>>>>    Currently our EMM Agent waits for a server push
>>>>>>>>>>> notification/local push to be triggered to get the pending 
>>>>>>>>>>> operation list
>>>>>>>>>>> from the server for the first time after registration. So to make 
>>>>>>>>>>> it a bit
>>>>>>>>>>> faster, we are going to execute a pending operation call on register
>>>>>>>>>>> success event.
>>>>>>>>>>>
>>>>>>>>>>> 3. Handle notifications so that it doesn't send unnecessary
>>>>>>>>>>> network calls
>>>>>>>>>>>
>>>>>>>>>>>    (Ex: If the user sets 2 second notification interval, we do
>>>>>>>>>>> not need to send continuous network calls if the first call has not 
>>>>>>>>>>> given
>>>>>>>>>>> the response)
>>>>>>>>>>>
>>>>>>>>>>> Please share your ideas on this.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> --
>>>>>>>>>>> Kasun Dananjaya Delgolla
>>>>>>>>>>>
>>>>>>>>>>> Software Engineer
>>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>> Tel:  +94 11 214 5345
>>>>>>>>>>> Fax: +94 11 2145300
>>>>>>>>>>> Mob: + 94 777 997 850
>>>>>>>>>>> Blog: http://kddcodingparadise.blogspot.com
>>>>>>>>>>> Linkedin: *http://lk.linkedin.com/in/kasundananjaya
>>>>>>>>>>> <http://lk.linkedin.com/in/kasundananjaya>*
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> *Niranjan Karunanandham*
>>>>>>>>> Senior Software Engineer - WSO2 Inc.
>>>>>>>>> WSO2 Inc.: http://www.wso2.com
>>>>>>>>> M: +94 777 749 661 <http:///>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Kasun Dananjaya Delgolla
>>>>>>>>
>>>>>>>> Software Engineer
>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>> lean.enterprise.middleware
>>>>>>>> Tel:  +94 11 214 5345
>>>>>>>> Fax: +94 11 2145300
>>>>>>>> Mob: + 94 777 997 850
>>>>>>>> Blog: http://kddcodingparadise.blogspot.com
>>>>>>>> Linkedin: *http://lk.linkedin.com/in/kasundananjaya
>>>>>>>> <http://lk.linkedin.com/in/kasundananjaya>*
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> *Sameera Perera*
>>>>>> Director of Engineering
>>>>>> gtalk: [email protected]
>>>>>> Tel : 94 11 214 5345
>>>>>> Fax :94 11 2145300
>>>>>> *WSO2, Inc.* <http://wso2.com/>
>>>>>> lean.enterprise.middleware
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Niranjan Karunanandham*
>>>> Senior Software Engineer - WSO2 Inc.
>>>> WSO2 Inc.: http://www.wso2.com
>>>> M: +94 777 749 661 <http:///>
>>>>
>>>
>>>
>>>
>>> --
>>> Chan (Dulitha Wijewantha)
>>> Software Engineer - Mobile Development
>>> WSO2Mobile
>>> Lean.Enterprise.Mobileware
>>>  * ~Email       [email protected] <[email protected]>*
>>> *  ~Mobile     +94712112165 <%2B94712112165>*
>>> *  ~Website   dulitha.me <http://dulitha.me>*
>>> *  ~Twitter     @dulitharw <https://twitter.com/dulitharw>*
>>>   *~Github     @dulichan <https://github.com/dulichan>*
>>>   *~SO     @chan <http://stackoverflow.com/users/813471/chan>*
>>>
>>
>>
>>
>> --
>>
>> ------------------------------
>>
>> *Sameera Perera*
>> Director of Engineering
>> gtalk: [email protected]
>> Tel : 94 11 214 5345
>> Fax :94 11 2145300
>> *WSO2, Inc.* <http://wso2.com/>
>> lean.enterprise.middleware
>>
>>
>>
>
>
> --
>
> *Niranjan Karunanandham*
> Senior Software Engineer - WSO2 Inc.
> WSO2 Inc.: http://www.wso2.com
> M: +94 777 749 661 <http:///>
>



-- 

------------------------------

*Sameera Perera*
Director of Engineering
gtalk: [email protected]
Tel : 94 11 214 5345
Fax :94 11 2145300
*WSO2, Inc.* <http://wso2.com/>
lean.enterprise.middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to