Skip to main content

[jsr361-observers] [jsr361-experts] Re: some remarks

  • From: Lampart Thomas < >
  • To: " " < >
  • Subject: [jsr361-observers] [jsr361-experts] Re: some remarks
  • Date: Thu, 11 Jul 2013 18:02:16 +0200
  • Accept-language: de-DE, en-US
  • Acceptlanguage: de-DE, en-US
  • List-id: <>

Dear specleads and experts,

As discussed in our call today I check my input below against the latest 
version of the spec  and I found most of it in it. Thanks.
Just a few additional remarks:

1.)    You didn't want to add "isLimited" ? why?

2.)    Oh and you added some network types to "getNetworkType". I believe 
this was also part of our discussion today. I didn't suggest to add 802.11. 
Don't know where this came from ;-) I also believe that you can remove CSD.  
Don't know what this would be.

3.)    Regarding my suggestions for the Power API. I didn't find of these in 
the spec. What are your current thoughts on these issues ?

Kind regards

From: Lampart Thomas
Sent: Freitag, 24. Mai 2013 16:43
' '
Subject: [jsr361-experts] Re: some remarks

Hi Volker, all,

@Volker: thanks for the spec update.

As promised here is some input regarding extending the cellular package. I 
really tried to focus on basic functionality, as managing a cellular device 
can sometimes really involve a lot of things. I am writing this from the 
perspective of a 3GPP cellular, so someone who is familiar with CDMA might 
want to recheck this and make a suggestion how these functionalities can be 
more generalized to cover both technologies.

1.)   Subscriber class:

a.    Authentication code handling (e.g. sim pin): Suggestion:

                                          i.    Add method: 
"setAuthenticationCode (String code)"

                                         ii.    Add method: "AuthState 
getAuthenticationState ()"; states are : READY, PIN, PIN2, blocked

2.)   CellularNetwork class:

a.    Add method: "static CellularNetwork[] getAvailableCellularNetworks()", 
returns all cellular networks the device can see

b.    Add method: "static selectNetwork (CellularNetwork network)", selects a 
network; and "static selectNetwork ()" for automatic network selection

c.    Add method: "deRegister()"; deregisters from cellular network, the 
device will not automatically register again even in automatic mode.

d.     Add the following method: "int getAvailability()", gets network 
availability, possible values are: unknown, current operator, available, 

e.    Add the following method: "boolean isLimited()", indicates limited 
service, i.e. device is camping on a network but cant register

f.     The network type should not only distinguish between 3GPP and CDMA but 
should also support subtypes like GSM, UTRAN, GSM with EGPRS, UTRAN with 

Also one additional remark regarding the Power API. I suggest to add the 
following functionality into the PowerManager:

*         Switch off device

*         Reboot the device

*         Disable/Enable all RF ("Airplane mode")

Kind regards

From: Volker Bauche 
[mailto: ]
Sent: Freitag, 24. Mai 2013 02:50
<mailto: >
Subject: [jsr361-experts] Re: some remarks

Dear experts,

in order to accelerate the discussion a bit, I had a phone call with Thomas 
today about the
issues we have discussed in this thread and that had not been solved during 
this discussion
so far.
This email documents our findings (see red inline below).
I have also uploaded a new spec version (v.0.5) to the JCP site (EG area) 
that reflects
the findings explained below (with the exception of the additional methods 
for the Cellular
package, where I have to wait for Thomas' list (see below).

Although not all of you have sent me a vote about preparation of EDR, I assume
that those of you that did not do not have serious concerns against this, so 
I will
prepare this step now. The EDR version will be very close to the v0.5 I have 
uploaded, but I will let you know of course as soon as I have applied for EDR.

Best regards -

4.) Overview: handling of input (e.g. keypad) should not depend on the 
presence of a display. Many applications have keys but no display.
How should the input from the keys be handled then? (I mean based on which 
API? Does it mean we need an API for processing key inputs independent on a 
graphical API?)
Well, the KeyListener doesn't look too bad to me. The problem with it is that 
it is in the same package as Display, right ? Or are there other dependencies 
Yes, the key listener is part of the lui package. The package is not bug, the 
largest part is of course the Display class. If you find it acceptable to 
implement the lui package (with a then even smaller dummy Display class) for 
having an API to handle key events. we can keep it this way. If not, we will 
have to find a way to extract the key functionality from this package.
Alternatives would be to put it into the event package (but my guess is that 
you would not like this - see below :-) ) or have an extra package for it.
I do not have a problem to implement a dummy Display class in order to use 
keys only. I am only a bit unsure how this would work for a TCK. As 
optionality is on package level only a TCK would probably expect a full 
implementation of the lui package or nothing at all, right ?
Right, while the question is, what means a "full implementation". You can do 
a dummy implementation that does nothing useful e.g. in the DIsplay class if 
you do not have a display, and hence pass the TCK if this implementation 
behaves as expected. The question is whether you want to do this, or if you 
would rather like to spare the memory. In this case we would have to extract 
the key handling from the lui package.
As it makes sense to have device with keys, but without a display, while it 
does not appear useful to have to implement
the whole lui package for that (which would be a dummy implementation anyway 
if there is no display), we have decided
to split the lui package: the KeyListener gets its own package 
javax.microedition.key, everything else remains in lui.

6.) javax.microedition.cellular: I do have the feeling that this package 
somehow overlaps with the AccessPoint in CLDC8/GCF. Please clarify how these 
two function complexes interact and why they are separated in this way.
It does not overlap. The interactiopn between those two is well-defined.
But we have Roger as one of the CLDC Specleads in our EG.
@Roger: Could you explain the interaction between AcceddPoint and Cellular to 
the EG a bit, pls?
Yes, please.
Roger> For the question about the relationship between CLDC AccessPoint and
MEEP CellularNetwork.

The AccessPoint abstration is focused onTCP/IP network interfaces.
Its origin was based on the operating system or device managing
the underlying networking stack.  The application can pick an interface
and may want/need to be aware of its characteristics but cannot control it.
Recent suggestions/improvements have expanded that somewhat but it
is still primarily an abstraction for a networking stack.

The MEEP CellularNetwork and Subscriber encapsulate information about
wide area networking and the operator managed subscriber information
found on SIM cards.  These abstractions provide access to cellular networking
properties and controls.  As above, the application needs only an abstraction
for the network and (mostly) leaves the management of the cellular network to
the implementation.

Most applications can operate effectively with only the AccessPoint 
and do not need control over cellular functions in most cases and the
separation makes the API easier to understand and use.
OK, thanks for clarification.
Then one remark about the cellular package (in fact it's a similar remark as 
I had about the AccessPoint):
This is an API which does only allow to query information which is in the 
device. It does not allow the midlet to configure or control anything. I 
think this is a big drawback!
In a typical (M2M) device the Java application (midlet) is the master. There 
is nothing outside which could do this job. So e.g. who enters the sim pin 
code ? Who selects the network ? I think that this API should be able to do 
So would you mind providing a list of methods you miss?
Thomas volunteered to send a list with setter methods he would like to see in 
this package.

8.) javax.microedition.event: A general question about this package: why such 
a generic event package ?

In the past several classes had some listener functionality and they received 
"their" events through this listener.

To me it seems a bit confusing to have such a generic event mechanism which 
then again contains events of all sorts.

In order to make the API more comprehensive, we try the following: while 
several packages continue to use the event package in order to handle
certain events (means the Event and EventListener class that have been 
defined there), we move the package specific event names and values
into the respective packages: backlight stuff into lui.Display class, power 
and battery related events into the power package, data network related 
events into the cellular package.

9.) javax.microedition.event.power: the previous question leads directly to 
this question: wouldn't it be nicer to have

PowerManager class with a Listener instead of PowerManager being a part of an 
event package ?

For me this just seems to be the wrong way around ?

The solution described above includes also one for this issue.

10.) PowerManager: good idea to have such a class, but at least for the use 
cases I know there are some issues here.

E.g. a device can never signal a sleep state to a midlet, because the moment 
it would do so the device can not be in

sleep state.

I'll clarify with our TCK guys how tests for certain power states will be 
performed in order to handle two concerns:
- WIll an implementation that initiates the SLEEP mode on a very low level - 
causing to fall into sleep immeditely and don't having the chance to send 
this event notification - have the chance to pass the TCK?
- How will the TCK handle the fact that an implementation may not handle all 
power states as they are not supported on a hardware level (like regulated 
low power state etc.)

Also: the passage in the spec reading that dependency attributes MUST be part 
of the JAD/Manifest if an application needs certain optional packages of MEEP 
in order to be able to run, was wrong and has been corrected.
As in MIDP and IMP(-NG), those Dependency attributes remain optional (also 
for optioanl packages), it is just recommended to use them in order to avoid 
that an application using a not implemented package will be installed and 
later crash during runtime.
But in cases where the manufacturer is the author of both, MEEP 
implementation and applications (a typical situation in the embedded world), 
this is of course not necessary.

[jsr361-observers] [jsr361-experts] Re: some remarks

Lampart Thomas 07/11/2013

[jsr361-observers] [jsr361-experts] Re: some remarks

Volker Bauche 07/11/2013
Please Confirm