[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: <jsr361-experts.jsr361.java.net>
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 ?
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
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
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 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)
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
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
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
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
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.