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, forbidden
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 HSDPA, UTRAN with HSDPA and HSUPA
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”)
From: Volker Bauche [mailto:
Sent: Freitag, 24. Mai 2013 02:50
Subject: [jsr361-experts] Re: some remarks
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
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 just
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?
Roger> For the question about the relationship between CLDC AccessPoint and
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
Most applications can operate effectively with only the AccessPoint information
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.
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
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.