Hi Prabath/Milan,
It is an improvement that we can do. But, it has some complications, users
are not allowed to choose the mode, it has to be set by the admin. In this
case how do we decide which user/device should use which mode. One option I
can think of is mode can be set per role by admin, since setting this per
user is not ideal. What you have mentioned, definitely has some good use
cases, for example a company may have a set of devices always connected to
power supply and some portable devices which are Android powered. In this
case, portable devices have a battery consumption concern which makes GCM
the ideal candidate, where the power connected devices can use polling.
Also, in a situation where the operation execution/device info retrieval
has to be done as quick as possible, polling is ideal(given that the
polling interval is reduced) in contrast to GCM where, the delivery of the
message may take time and unreliable.
On the other hand there is no any method which has been implemented to
persist these configurations in the device yet too.
This was there in the previous release, I will go though the code and get
back to you on this.
Regards,
inosh
On Tue, May 12, 2015 at 5:13 PM, Milan Perera <mi...@wso2.com> wrote:
> Hi Niranjan, Inosh,
>
> Actually the problem is at both ends. There is no any method that has been
> implemented to push these configurations (push method/ refresh time) from
> server to application yet. On the other hand there is no any method which
> has been implemented to persist these configurations in the device yet too.
>
> Adding to both Inosh and Prabath ideas, I think this 'push method' should
> be come with the device policies so that selected users will be able to use
> GCM or LOCAL at given time. WDYT?
>
> On Tue, May 12, 2015 at 4:57 PM, Niranjan Karunanandham <niran...@wso2.com
> > wrote:
>
>> Hi Inosh
>>
>> Notification Type gets cleared from the device when it is restarted and
>>> Kasun fix this (Please correct me if am wrong).
>>> Since It is fixed, I think the issue here is we have not yet passed
>>> these values from the server.
>>>
>> If so, then shouldn't this issue be there (after registering to the
>> server) even without restarting the device?
>>
>> Regards,
>> Nira
>>
>> On Tue, May 12, 2015 at 4:52 PM, Inosh Perera <ino...@wso2.com> wrote:
>>
>>> Hi Niranjan,
>>>
>>> Notification Type gets cleared from the device when it is restarted and
>>> Kasun fix this (Please correct me if am wrong).
>>> Since It is fixed, I think the issue here is we have not yet passed
>>> these values from the server.
>>>
>>> To add to this there was a limitation in the previous version is that
>>> after a device is registered and if we change the Notification Type in the
>>> server, it does not get reflected in the device.
>>> Yes, We will have to address this issue, @Milan - We can make this a
>>> profile operation. When the mode gets changed, all the android devices must
>>> get a profile WDYT?
>>>
>>> Regards,
>>> Inosh
>>>
>>>
>>>
>>>
>>> On Tue, May 12, 2015 at 4:32 PM, Niranjan Karunanandham <
>>> niran...@wso2.com> wrote:
>>>
>>>> Hi Inosh,
>>>>
>>>>
>>>>> According to EMM 1.1.0, When the device is successfully registered,
>>>>> with the response, we sent a set of initial configurations. This
>>>>> configuration, included things such as, whether the mode is LOCAL or GCM,
>>>>> if LOCAL(polling) then the frequency to poll. In EMM 1.1.0, these were
>>>>> stored in a config file and passed to the device. So in MDM we must pass
>>>>> this value and store at some point, so that the device can choose how to
>>>>> communicate with the server.
>>>>>
>>>> In EMM 1.1.0, these configurations (Type of notification, i.e., Local
>>>> or GCM) used to be stored in the registry. The default value is stored in
>>>> the config file which is then copied to the registry (tenant space) when
>>>> the tenant admin logs in for the first time. Therefore this setting can be
>>>> changed per tenant. When the device registers to the system, these values
>>>> are sent which is persisted in the device. AFAIR the same issue mentioned
>>>> by Milan was there in the previous version wherein the Notification Type
>>>> gets cleared from the device when it is restarted and Kasun fix this
>>>> (Please correct me if am wrong). To add to this there was a limitation in
>>>> the previous version is that after a device is registered and if we change
>>>> the Notification Type in the server, it does not get reflected in the
>>>> device.
>>>>
>>>> Regards,
>>>> Nira
>>>>
>>>>
>>>> On Tue, May 12, 2015 at 3:36 PM, Inosh Perera <ino...@wso2.com> wrote:
>>>>
>>>>> Hi Milan,
>>>>>
>>>>> According to EMM 1.1.0, When the device is successfully registered,
>>>>> with the response, we sent a set of initial configurations. This
>>>>> configuration, included things such as, whether the mode is LOCAL or GCM,
>>>>> if LOCAL(polling) then the frequency to poll. In EMM 1.1.0, these were
>>>>> stored in a config file and passed to the device. So in MDM we must pass
>>>>> this value and store at some point, so that the device can choose how to
>>>>> communicate with the server.
>>>>>
>>>>> Regards,
>>>>> Inosh
>>>>>
>>>>> On Tue, May 12, 2015 at 2:52 PM, Milan Perera <mi...@wso2.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm getting $subject whenever the device get restarted. Exception
>>>>>> details as follows:
>>>>>>
>>>>>> java.lang.RuntimeException: Unable to start receiver
>>>>>> org.wso2.mdm.agent.services.DeviceStartupIntentReceiver:
>>>>>> java.lang.NullPointerException: Attempt to invoke virtual method
>>>>>> 'java.lang.String java.lang.String.trim()' on a null object reference
>>>>>> at
>>>>>> android.app.ActivityThread.handleReceiver(ActivityThread.java:2586)
>>>>>> at
>>>>>> android.app.ActivityThread.access$1700(ActivityThread.java:144)
>>>>>> at
>>>>>> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1355)
>>>>>> at android.os.Handler.dispatchMessage(Handler.java:102)
>>>>>> at android.os.Looper.loop(Looper.java:135)
>>>>>> at
>>>>>> android.app.ActivityThread.main(ActivityThread.java:5221)
>>>>>> at java.lang.reflect.Method.invoke(Native Method)
>>>>>> at java.lang.reflect.Method.invoke(Method.java:372)
>>>>>> at
>>>>>> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
>>>>>> at
>>>>>> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
>>>>>> Caused by: java.lang.NullPointerException: Attempt to invoke
>>>>>> virtual method 'java.lang.String java.lang.String.trim()' on a null
>>>>>> object
>>>>>> reference
>>>>>> at
>>>>>> org.wso2.mdm.agent.services.DeviceStartupIntentReceiver.setRecurringAlarm(DeviceStartupIntentReceiver.java:61)
>>>>>> at
>>>>>> org.wso2.mdm.agent.services.DeviceStartupIntentReceiver.onReceive(DeviceStartupIntentReceiver.java:45)
>>>>>> at
>>>>>> android.app.ActivityThread.handleReceiver(ActivityThread.java:2579)
>>>>>> at
>>>>>> android.app.ActivityThread.access$1700(ActivityThread.java:144)
>>>>>> at
>>>>>> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1355)
>>>>>> at android.os.Handler.dispatchMessage(Handler.java:102)
>>>>>> at android.os.Looper.loop(Looper.java:135)
>>>>>> at
>>>>>> android.app.ActivityThread.main(ActivityThread.java:5221)
>>>>>> at java.lang.reflect.Method.invoke(Native Method)
>>>>>> at java.lang.reflect.Method.invoke(Method.java:372)
>>>>>> at
>>>>>> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
>>>>>> at
>>>>>> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
>>>>>>
>>>>>> This is occurred when device invoke *setRecurringAlarm()* method in
>>>>>> *DeviceStartupIntentReceiver
>>>>>> *class at the start-up. The reason for getting this exception
>>>>>> because it tries to get the '*mode*' string from *SharedPreference*
>>>>>> and trim it. However the '*mode*' is not stored there.
>>>>>>
>>>>>> Code Snippet
>>>>>> -------------------
>>>>>>
>>>>>> String mode = Preference.getString(context,
>>>>>> resources.getString(R.string.shared_pref_message_mode));
>>>>>>
>>>>>> if (NOTIFIER_MODE.equals(mode.trim().toUpperCase(Locale.ENGLISH))) { ...
>>>>>> }
>>>>>>
>>>>>>
>>>>>> According to what I have understood, it checks the
>>>>>> *NOTIFICATION_MODE* whether *LOCAL* or *GCM*.
>>>>>>
>>>>>> So my questions are, *where should I set this 'mode' preference and
>>>>>> how do we decide whether it should be LOCAL or GCM?*
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Milan Harindu Perera
>>>>>> Software Engineer
>>>>>> *WSO2, Inc*
>>>>>> (+94) 77 309 7088
>>>>>> lean . enterprise . middleware
>>>>>> <http://lk.linkedin.com/in/milanharinduperera>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Inosh Perera
>>>>> Software Engineer, WSO2 Inc.
>>>>> Tel: 0785293686
>>>>>
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>> Dev@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Niranjan Karunanandham*
>>>> Senior Software Engineer - WSO2 Inc.
>>>> WSO2 Inc.: http://www.wso2.com
>>>>
>>>
>>>
>>>
>>> --
>>> Inosh Perera
>>> Software Engineer, WSO2 Inc.
>>> Tel: 0785293686
>>>
>>
>>
>>
>> --
>>
>> *Niranjan Karunanandham*
>> Senior Software Engineer - WSO2 Inc.
>> WSO2 Inc.: http://www.wso2.com
>>
>
>
>
> --
> Milan Harindu Perera
> Software Engineer
> *WSO2, Inc*
> (+94) 77 309 7088
> lean . enterprise . middleware
> <http://lk.linkedin.com/in/milanharinduperera>
>
--
Inosh Perera
Software Engineer, WSO2 Inc.
Tel: 0785293686
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
