| Page |
Section |
Section, class, method etc. |
Description |
| 3... |
1.8 |
Contributors |
Note the amount of contributors, and that the list contains device manufacturers, operators, Java implementation providers, application developers and others. This is a high value
specification, critical for the future use of Java ME and MIDP, and possibly also the adoption of CDC, as so far CDC has not been used much. |
| 5 |
1.11 |
Architecture |
MIDP 3.0 can be used for both CLDC and CDC, but I doubt the combination of MIDP and CDC will be used much by developers, because you will use CDC to get access to the more advanced UI of
Personal Profile for e.g.corporate applications, but not for much else. Yet, It depends on how it gets implemented in phones: If the norm will be MIDP 3.0 over CDC (which I doubt), then it's
not an issue, but there's still the issue of compatibility with pre-MIDP3 phones, that developers must handle for a long time still. |
| 6 |
1.13 |
Device Requirements |
The hardware requirements have been increased, e.g. 176*220, 16-bit color etc. From an actual device standpoint this is not an issue. The software requirements look the same as before. |
| 7... |
1.14 |
Specification Requirements |
Now requires JPEG and more media formats. |
| 10... |
2 |
MIDP 3.0 Packaging |
Adds the concept of LIBlets (~ DLLs), that can be shared among MIDlets. Resource files and record storage can also be shared. The JAD format has been extended to include information for
LIBlets and use of LIBlets. |
| 25... |
3 |
MIDP 3.0 Provisioning |
This section describes the addition of LIBlets and how that affects provisioning. |
| 26... |
3.3 |
MIDlet Suite Discovery |
LIBlets required by a certain MIDlet will be automatically downloaded, unless they already have been. This is similar to the approach taken by BREW for public and private extensions, and might even be
inspired by it. Whether we will run into "DLL hell" (as in Windows: several different versions of the same DLL taking up more and more space) with LIBlets is to be seen. |
| 27... |
3.4 |
MIDlet Suite Installation |
The MIDlet JAD will contain a hash of the LIBlet that the Application Manager can check against when downloading the LIBlet, to secure that the right LIBlet is used. |
| 30... |
3.5 |
RMS Provisioning |
Also RMS data can now be provisioned. This is neat to enable pre-configured applications. Of course earlier that could be part of the application code, but this enables one to change the
contents of the RMS data over time without affecting the application code. |
| 31... |
3.6 |
MIDlet Suite Update |
Indicates that a LIBlet upgrade is (possibly) triggered by a MIDlet upgrade. LIBlets are not upgraded independently. |
| 33... |
3.8 |
MIDlet Suite Removal |
If a certain LIBlet is no longer used by any MIDlet after a MIDlet has been removed, the LIBlet may (not will) also be deleted. I guess this is a matter of available memory. A LIBlet that
no MIDlet refers to could be deleted if memory is scarce, but that's up to the implementations. |
| 23... |
3.9 |
Installation/Deletion Status Reports |
Reports back to the server the result of the install/uninstall. |
| 38... |
4 |
MIDP 3.0 Platform |
Further describes the use of MIDP over CDC, and that an application developed for CLDC/MIDP should run as-is over CDC. As CDC is not a direct superset of CLDC, implementations need to
support also unique CLDC classes over CDC. |
| 40 |
4.7 |
Supporting CLDC Compatible Behavior on Top of a CDC Based System |
More about the above. |
| 42... |
5 |
MIDlet Concurrency |
Describes that it's now mandatory to support several running MIDlets. It was optional before, and few implemented such support (probably for system resource reasons, or maybe for lack of
preemptive scheduling; all phone application platforms provide preemptive concurrency, even though possibly not visible to higher-level applications). It further describes that MIDlets should
not know of other MIDlets running and not share data etc (unless they need to communicate with each other). Crashing applications should not affects other running MIDlets (nor of course the
phone's own applications). |
| 46... |
6 |
Security for MIDP Applications |
Adds a new class called Permission (from CDC and Java SE) for more granular and orderly permission control. This will also be added to a later revision of CLDC. Applications can also check
on given permissions. |
| 63... |
8 |
Security Policy |
Defines a new set of protection domains for signed applications: Identified Third Party, Operator, Manufacturer. For unsigned applications the Unidentified Third Party domain will be used.
This requires more analysis to understand the consequences thereof. |
| 70... |
8.7 |
Permissions for Downloaded MIDlet Suites |
Also here the granularity has increased to provide more fine-grained control over permissions.
You might argue that all this security measures still doesn't make the use of MIDlets really secure. E.g. the "Red Browser" trojan horse just asked the user to accept sending of SMS's when
warnings were shown. Not even this extended security scheme would stop that, unless unidentified applications are simply stopped from doing anything, rendering them useless, and forcing all
providers to sign their applications. |
| 99 |
11.7 |
Support for different IP versions |
Now also supports IPv6. |
| 99 |
11.8 |
Additional networking changes in MIDP 3.0 |
This is still in discussion state, but the possibility to select network interface is considered. |
| 99... |
11.9 |
Inter-MIDlet Communications (IMC) |
Used for communicating between MIDlets on the same device, and emulates somewhat the behavior of network socket communication. |
| 118... |
11 |
HttpConnection |
HTTP now supports DELETE and PUT. |
| 138 |
11 |
IMCConnection |
Provides the means to
communicate between different running MIDlets. |
| 141 |
11 |
IMCServerConnection |
See above. |
| 199 |
12 |
AnimatedImage |
The mandatory image formats
PNG and JPEG don’t support animation, so this adds that functionality. We are not talking a sequencing of PNG/JPEG images here, but raw bitmaps. I wonder why they didn’t require support for
GIF (that’s got native support for animation), now when there are no patent issues. |
| 218 |
12 |
Canvas: setPaintMode |
Controls whether pixels on a
Canvas are opaque or transparent |
| 228, 229 |
12 |
Choice: isEnabled, setEnabled |
Checks and controls whether a
choice item is enabled (“grayed out”) or not. |
| 237, 238 |
12 |
ChoiceGroup: isEnabled,
setEnabled |
See Choice above. |
| 241 |
12 |
Command |
Images can now be added to
commands, similar to images in lists. Of course the phone might not be able to show the image, e.g. if the command is chosen to be a soft key, but in a menu the image could be shown. |
| 264 |
12 |
CustomItem: setPaintMode |
See setPaintMode above. |
| 282 |
12 |
Display: HARDWARE_xxxx |
Tells the state of an
external display. Could this be for video outputs? Projector? |
| 282… |
12 |
Display: ORIENTATION_xxxx |
Used for setting the
orientation of the drawing on the display. |
| 283 |
12 |
Display: STATE_xxxx |
Tells the application whether
the display is in the background, the foreground, or visible. |
| 283… |
12 |
Display: SUPPORTS_xxxx |
Provides information about
what can be displayed: alerts, commands, forms, input events, lists, text boxes, ticker/title. Not sure why this is of any use, as all implementations should support these very basic UI
widgets. Not that e.g. ticker is very useful, at all. |
| 285 |
12 |
Display: addDisplayListener |
Used as a listener for e.g.
hardware change events (see e.g. HARDWARE_xxxx) |
| 288 |
12 |
Display: getCapabilities |
Returns information about
what UI widgets are supported, as a combination of the SUPPORTS_xxxx values mentioned above. |
| 289 |
12 |
Display: getDisplays |
Returns the complete list of
available displays. Clamshell phones have two and there could also be external connectors, so this is much needed. Now getCapabilities makes more sense. |
| 289 |
12 |
Display: getDisplayState |
Returns any of the STATE_xxxx
states. |
| 290 |
12 |
Display: getDotPitch |
Returns the size of pixels,
assuming they are always square (only one value; square pixels is a MIDP requirement). |
| 290 |
12 |
Display: getFullScreenHeight,
getFullScreenWidth |
Returns the dimensions of
full screen Canvas. |
| 290 |
12 |
Display: getHardwareState |
Returns one of the
HARDWARE_xxxx values. |
| 290 |
12 |
Display: getOrientation |
Returns one of the
ORIENTATION_xxxx values |
| 291 |
12 |
Display: isInternal |
Indicates internal or
external (and hence possibly detachable) display |
| 291 |
12 |
Display:
removeDisplayListener |
See addDisplayListener. |
| 294 |
12 |
Display: setOrientation |
See ORIENTATION_xxxx. |
| 298 |
12 |
Displayable |
Adds the concept of placeable
commands. This will be appreciated by many, but the risk is still there that you don’t get it exactly the way you want. |
| 300 |
12 |
Displayable: addCommand |
Now with placement. |
| 300… |
12 |
Displayable:
getCommandPlacements, getPreferredPlacement |
For controlling and checking
placement. |
| 305 |
12 |
DisplayCapabilityException |
Thrown when a non-supported
widget is used. |
| 307 |
12 |
DisplayListener |
Used for listening to display
state changes, e.g. disconnecting of an external display etc |
| 322 |
12 |
Font: createFont |
Introduces the possibility to
create your own fonts, and not just rely on arbitrary small, medium and large fonts. |
| 322 |
12 |
Font: deriveFont |
Sets an existing font to new
characteristics: size and style. |
| 323 |
12 |
Font: equals |
Compares font. For avoiding reselecting/allocating already selected fonts? |
| 323… |
12 |
Font: getAscent, getDescent,
getLeading, getMaxAscent, getMaxDescent |
Returns information about
distances in the selected font. |
| 324 |
12 |
Font: getAvailableFonts |
Returns what fonts are available |
| 326 |
12 |
Font: getFont |
Selects a font and returns
the instance of it. |
| 328 |
12 |
Font: getPixelSize |
Effectively returns the line
spacing. Valid for bitmap (pre-scaled) fonts only. |
| 329 |
12 |
Font: getStyle |
Returns the style of the
selected font. |
| 338… |
12 |
Form: getLayoutPolicy,
setLayoutPolicy |
See FormLayoutPolicy below. |
| 339 |
12 |
Form:
setItemTraversalListener |
See ItemTraversalListener. |
| 341 |
12 |
FormLayoutPolicy |
Enables you to control how UI
widgets are placed, if I understand the concept correctly. |
| 364 |
12 |
Graphics: SRC, SRC_OVER |
Blending modes. Replace vs
blend. |
| 366… |
12 |
Graphics: drawARGB16,
drawRGB16 |
Draws an image in 16-bit
color format. |
| 371 |
12 |
Graphics: drawRegion |
Draws a region of the image
into a region of the destination. |
| 376 |
12 |
Graphics: getAlpha,
getBlendingMode, setAlpha, setAlphaColor, setBlendingMode, hasAlpha |
Controls and checks different
color-related values. |
| 390 |
12 |
Graphics: createImage |
Several new types: image from
a source image region, with alpha etc |
| 399 |
12 |
Graphics: isAnimated |
See AnimatedImage. |
| 415… |
12 |
Item: getLayoutHint,
setLayoutHint |
See FormLayoutPolicy. |
| 424 |
12 |
ItemTraversalListener |
Receives events when the Form
item focus changes. |
| 433 |
12 |
List: isEnabled, setEnabled |
See Choice. |
| 438 |
12 |
MenuCommand |
Enables creating cascading
command menus. Many phones already support this for native applications. |
| 450 |
12 |
TabbedPane |
Provides the means to create
multi-layer forms that are navigated via tabs. If you’ve ever used Windows you know what I’m talking about. |
| 455 |
12 |
TableLayoutPolicy |
Puts form items in table
cells. |
| 458 |
12 |
TabListener |
See TabbedPane. |
| 459 |
12 |
Text |
A more advanced text
rendering solution than was available in earlier MIDP versions. You have much more control of how the text is placed and formatted now. |
| 473 |
12 |
TextBox |
Like Text, but within a given
region. |
| 539 |
14 |
Mobile Media API |
Full support for this API is
now required. What this means in terms of codecs is not mentioned here. |
| 565 |
15 |
MIDlet: getSplashScreenTime |
Just returns the time the
splash screen has been shown. Why? |
| 569 |
15 |
MIDletIdentity |
Used to communicate MIDlet
information between MIDlets. |
| 596 |
17 |
RecordEnumeration:
getRecordId |
Accesses a given record based
on index. |
| 607 |
17 |
RecordStore: addRecord |
Now with support for tags. |
| 609 |
17 |
RecordStore: enumerateRecords |
Now with support for tags. |
| 613 |
17 |
RecordStore: getTag |
See above. |
| 615 |
17 |
RecordStore: openRecordStore |
Now supports record stores
that can be shared between different MIDlet suites. |
| 616… |
17 |
RecordStore: readRecordStore,
writeRecordsStore |
Reads and writes via a
stream. |
| 619 |
17 |
RecordStore: setRecord |
Now with support for tags. |
| 629 |
18 |
EventData |
Provides the data used to inform an application about changes in system properties. |
| 637 |
18 |
EventDataListener |
The sink for EventData information. |
| 638 |
18 |
EventManager |
Enables posting and listening to events, including to launch applications if such are received. This way it sounds like partly overriding/complementing PushRegistry. Both system and
application-specific events can be issued. |
| 654 |
18 |
EventPermission |
Allows access to system events. |
| 657 |
18 |
EventSourceInfo |
Describes the source of an event. |
| 659 |
19 |
User Interface Customization |
This provides customization
similar (but not in any way identical) to J2ME Polish. A very important addition, and that hopefully makes it less required to make the UI using only Canvas. This is described in detail in the separate JSR 258. |
