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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
