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