Just An Application

March 18, 2010

MIDP 3.0 On Maemo 5: A TabbedPane And Some Lists … Again

Filed under: Java, JME, LCDUI, Maemo, MIDlets, MIDP, MIDP3, MIDP3LCDUI, Mobile Java, Qt — Tags: , , , , , , , — Simon Lewis @ 1:43 pm

It’s that MIDlet again. This time running on the Maemo5 emulator. The implementation code is identical to the Symbian version with vanilla Qt being used as the LCDUI back-end.





Copyright (c) 2010 By Simon Lewis. All Rights Reserved.

Advertisements

March 17, 2010

MIDP 3.0 On Symbian: A TabbedPane And Some Lists

Filed under: Java, JME, LCDUI, MIDP, MIDP3, MIDP3LCDUI, Nokia, Qt, Symbian — Tags: , , , , , , , — Simon Lewis @ 9:02 am

Here’s the SimpleTabbedPaneMIDlet again, this time running on the N97 emulator. The only difference between this and the Android version is that the LCDUI backend is implemented using vanilla Qt rather than Android widgets.




Copyright (c) 2010 By Simon Lewis. All Rights Reserved.

March 5, 2010

MIDP 3.0 On Android: Notifications

Filed under: Android, Java, JME, LCDUI, MIDP, MIDP3, MIDP3LCDUI — Tags: , , , , , , — Simon Lewis @ 12:04 pm

Notifications are another new feature in MIDP 3 for which there is some usefully equivalent functionality in Android, namely Notifications ! or more specifically

    android.app.Notification

and

    android.app.NotificationManager

Below is a very simplistic MIDlet which demonstrates the basic use of Notifications. Of course, in reality a MIDlet would actually be doing something which would cause it emit Notifications. In the case of the Missed Call Notification type that I am using in the example, it might be doing some actual telephony, although that is a bit unlikely since as far as I am aware neither JSR 253 nor 304 have ever been shipped. Anyway, here’s the MIDlet



import javax.microedition.lcdui.Alert;
import javax.microedition.lcdui.AlertType;
import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.Notification;
import javax.microedition.lcdui.NotificationListener;
import javax.microedition.lcdui.NotificationType;

import javax.microedition.midlet.MIDlet;

public final class SimpleNotificationMIDlet
                   extends
                       MIDlet
                   implements
                       NotificationListener,
                       Runnable
{
    public void destroyApp(boolean ignore)
    {
    }
	
    public void startApp()
    {
        primaryDisplay = Display.getDisplays(0)[0];
        new Thread(this).start();
    }
	
    //
	
    public void notificationDismissed(Notification theNotification)
    {
        primaryDisplay.setCurrent(new Alert("Notification Dismissed", null, null, AlertType.INFO));
    }
	
    public void notificationSelected(Notification theNotification)
    {
        primaryDisplay.setCurrent(new Alert("Notification Selected", null, null, AlertType.INFO));
    }
	
    public void notificationTimeout(Notification theNotification)
    {
        primaryDisplay.setCurrent(new Alert("Notification Timeout", null, null, AlertType.INFO));
    }
	
    public void run()
    {
        try
        {
            missedCall("+44 1234567890");
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }
	
    private void missedCall(String theCaller)
    {
        Notification n = new Notification(NotificationType.CALL);
		
        n.setListener(this);
        n.setLabel("Missed call from " + theCaller);
        n.post(true, 60000);
    }
	
    //
	
    private Display	primaryDisplay;
}


Here’s the Notification immediately after it has been posted. For a couple of seconds it takes over the entire status bar.

Here’s the Notification once the status bar re-appears. For the misleadingly named Call NotificationType, which is actually the Missed Call NotificationType, I am using the generic Missed Call icon as shipped with Android.

Here’s the expanded view which is shown when the status bar is pulled down

And that’s it really. At this point the user can either click on the Notification or ignore it, and a MIDlet can either update the Notification or remove it.

In the example MIDlet, if you select the Notification in the expanded view, this happens

If you hit the clear button in the expanded view, this happens

If you just sit and wait then eventually this happens.

There is one feature of Android Notifications which is not demonstrated above, and that is the ability to associate a number with a Notification, in which case you get this

There is no API for doing this in MIDP 3, but the specification does explicitly permit an implementation to group together Notifications of the same type. so in theory a single Android Notification could be used to represent a number of MIDP 3 Notifications, with the number of Notifications being displayed in the icon, as above.

In practice there is no way for the implementation to know the intended semantics of any single MIDP 3 Notification and consequently whether it would be appropriate to group it with other Notifications of ostensibly the same type, or whether doing so is simply going to end-up badly confusing the user. There is also an issue with how to handle the display of a group of MIDP 3 Notifications in the expanded view of a single Android Notification. Although the view is customizable this is done using something RemoteViews which have fairly circumscribed functionality.


Copyright (c) 2010 By Simon Lewis. All Rights Reserved.

December 16, 2009

What’s New In MIDP 3.0: Redux – LCDUI – Notification

Filed under: Java, JME, MIDP, MIDP3, MIDP3Issues, MIDP3LCDUI, Mobile Java — Tags: , , , , , , — Simon Lewis @ 10:28 pm

Original Post

Changes Since Proposed Final Draft

Removing the NotificationListener via the Notification.setListener(NotificationListener) method no longer removes the Notification as well.

This eliminates the inconsistency between its behaviour and the documentation describing the Notification life-cycle which I noted in the original post.

Issues

The other minor issues noted in my original post still exist.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

What’s New In MIDP 3.0: Redux – LCDUI – Fonts

Filed under: Java, JME, MIDP, MIDP3, MIDP3Issues, MIDP3LCDUI — Tags: , , , , , , — Simon Lewis @ 5:07 pm

Original Post

Changes Since Proposed Final Draft

Font.FONT_IDLE_TEXT and Font.FONT_IDLE_HIGHLIGHTED_TEXT

Links fixed to point at the right versions of the static getFont method, i.e.,

    Font.getFont(int)

Font.createFont(InputStream)

Scope of the Font created is now limited to the MIDlet that created it.

Implementations MUST insure that the availability and use of fonts created using createFont method is limited to the execution environment of a [sic] MIDlet that instantiated the font.

Changed from MIDlet Suite.

Font.getFont(String,int,int), Font.getFont(int,int,int) AndFont.deriveFont(int,int)

Documentation for all three methods has been updated to explicitly specify that the constant STYLE_UNDERLINED is supported in their respective style arguments.

The specification of the static method Font.getStyle(String) however, has not been updated to match. Possibly it does not need to be. Who knows ?

Font.hashCode()

Font now has a hashCode, which of course it should since it over-rides the equals method.

Unfortunately how the hash code should be computed is apparently a secret, since all the specification says is

the hashcode is computed from the font face name, style, pixelSize, ascent and descent

Issues

None apart from the secret hash code algorithm and that only affects implementors.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

What’s New In MIDP 3.0: Redux – LCDUI – Command Layout

Filed under: Java, JME, LCDUI, MIDP, MIDP3, MIDP3Issues, MIDP3LCDUI — Tags: , , , , , , — Simon Lewis @ 10:49 am

Original Post

Changes Since Proposed Final Draft

javax.microedition.lcdui.Display

The following has been added to the end of the Exact Placement of Commands section
of the Display class documentation.

On each callback of CommandLayoutPolicy.onCommandLayout(Displayable), implementation MUST first disassociate Command and Menu
with their respective previous placements. At the beginning of each callback of CommandLayoutPolicy.onCommandLayout(Displayable) method,
Displayable.getCommand(int) or Displayable.getMenu(int) will return null for every placement.

As I said in my original post

  1. The specification does not contain an explicit definition of the state of a Display’s placements when the onLayout(Displayable)[sic] method is called, that is, whether Commands and/or Menus previously placed on the current Display by the Displayable are still present or whether all Commands and/or Menus must be explicitly placed each time the method is called. This makes implementing the method perhaps more interesting than it ought to be.

Well now it does. Every time you layout a Displayable’s Commands you start with a clean slate.

javax.microedition.lcdui.Displayable

The setCommand(Command,int) method no longer throws an IllegalArgumentException when the placement

is associated with a placement that does not support commands

possibly because it is actually not possible for a placement not to support Commands.

It is hard to be sure because the Item.setCommand(Command,int) method will apparently still throw an IllegalArgumentException when the placement

is associated with a placement that does not support commands

The CommandLayoutPolicy Example

The CommandLayoutPolicy now looks like this. Actually it doesn’t because I have re-formatted it. In Chrome, Firefox and Safari the formatting is all over the place, as it is in the PDF version.


class MyCanvas extends Canvas implements CommandLayoutPolicy {
    MyCanvas() {
        setCommandLayoutPolicy(this);
    }

    void sort(Command[] commands, int[] positions) {
        // sort the commands in the correct order depending on the positions available.
        // Implementation can use Display's getCommandPreferredPlacements to get the recommended 
        // placement for each Command.
    }
 
    public void onCommandLayout(Displayable displayable) {
        Display display = displayable.getCurrentDisplay();
      
        final int border = Display.SOFTKEY_BOTTOM;
     
        int[] positions = display.getExactPlacementPositions(border);
     
        int numOfPositions = positions.length;
           
        Command[] cmd = displayable.getCommands();
     
        sort(cmd, positions);
     
        if (cmd.length <= numOfPositions) {
            for (int i = 0; i < cmd.length; ++i) {
                displayable.setCommand(cmd[i], positions[i]);
            }
        } else {
            for (int i = 0; i < numOfPositions ; ++i) {
                displayable.setCommand(cmd[i], positions[i]);
            }
       
            int[] menuSupportedPlmts = display.getMenuSupportedPlacements();
            if( menuSupportedPlmts != null ) {
                Menu options = new Menu("More", null, null);
                // first add the remaining commands in the Menu
                for (int i = numOfPositions; i < cmd.length; ++i) {
                    options.append(cmd[i]);
                }
                // Get the first preferred placement of Menu
                int menuPlmt = menuSupportedPlmts[0];
                // check if this placement already occupied by Command
                if( displayable.getCommand(menuPlmt) != null ) {
                    //add the existing Command in Menu, otherwise the existing
                    // Command will be removed from the Displayable according to
                    //setMenu() method
                    //
                    options.append(displayable.getCommand(menuPlmt));
                }
                displayable.setMenu(options, menuPlmt);                    
            }
        }    
    }
 }

This is an improvement on the previous version which was flat-out broken. Note that it still doesn’t check the return value of the call to Display.getExactPlacementPositions(int).

Issues

The changes above are the only ones that I have found. Of the original issues I raised they address two if you are being charitable.

  1. What is the state of the Displayable with respect to Command layout when the CommandLayoutPolicy.onCommandLayout(Displayable) method is invoked ? It is a clean slate

  2. Can there be placements which do not support Commands ? Probably not.

Everything else is still up for grabs. Developers, assuming there are going to be any, are going to have to try it and see what happens, and then hope it happens the same way everywhere, which is the past has not been a guaranteed recipe for success.

Possibly if somebody had attempted to write a real-world example for the specification the Command layout feature itself would have been better specified. The example provided effectively does no more than provide the existing default behaviour.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

December 15, 2009

What’s New In MIDP 3.0: Redux – LCDUI – Menus

Filed under: Java, JME, MIDP, MIDP3, MIDP3Issues, MIDP3LCDUI, Mobile Java — Tags: , , , , , — Simon Lewis @ 9:30 pm

Original Post

Changes Since Proposed Final Draft

The semantics of the depth returned by the method Menu.getMenuDepth() have been changed.

The method now

Returns this menu’s depth within its menu tree. The top menu is of depth 0, the menus attached to it are of depth 1, 2, etc. The top menu is the menu in the menu tree that has no parent menu . If a menu is attached to both a Displayable and another menu, its depth is calculated based on the menu to which it is attached. For instance, a menu A is a sub-menu of menu B and is also attached to a Displayable. If menu B is of depth 3, then menu A will return a depth of 4.

Previously, as I observed in my original post, the specification was both contradictory, and seemed to imply, amongst other things, that a Menu could effectively have two depths.

Issues

Although it is not a particularly serious issue, despite the changes, it is not exactly clear what having the ability to obtain the depth of a given Menu is actually for.

The depth of a Menu is only significant in the context of the maximum limit on Menu depth.

If you know that a Menu is at the maximum permitted depth then it is true that you know that you definitely cannot add a sub-Menu to it.

If you know that a Menu is not at the maximum permitted depth however, you do not know that you can add a given Menu as a sub-Menu with out knowing whether the Menu you wish to attach itself has any sub-Menus, and if so what the maximum depth of the sub-Menu tree, and you are going to have to compute that.

As I say it is not serious but some use-cases might have helped.

This is also true of the eternally enigmatic Menu.onParentEnabled(true). What is it for ?


Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

July 23, 2009

What’s New In MIDP 3.0 ? Part 33: LCDUI – KeyListener

Filed under: Java, JME, LCDUI, MIDP, MIDP3, MIDP3LCDUI — Tags: , , , , , , — Simon Lewis @ 7:19 am

The KeyListener interface enables an object to listen for key events associated with a Canvas, CustomItem, or IdleItem

When a key is pressed, released or repeated the listening object is notified with the key code and modifiers.

The KeyListener of a Canvas or Custom Item can be set using their respective

	public void setKeyListener(KeyListener listener)

methods.

In each case passing null as the listener argument will result in the current KeyListener, if any, being removed.

For both a Canvas and a CustemItem having a KeyListener does not affect the


    protected void keyPressed(int keyCode)
	
    protected void keyReleased(int keyCode)
	
    protected void keyRepeated(int keyCode)

and they will continue to be called.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved

What’s New In MIDP 3.0 ? Part 32: LCDUI – TextEditor

Filed under: Java, JME, LCDUI, MIDP, MIDP3, MIDP3LCDUI — Tags: , , , , , , — Simon Lewis @ 7:14 am

1. TextEditor

A TextEditor is a UI element which can be used in conjunction with a Canvas, CustomItem, or IdleItem to display and obtain text input from the user.

A TextEditor is the Canvas/CustomItem equivalent of a TextField and supports the same input constraints and modes as a TextField.

A TextEditor can only be associated with a single Canvas or CustomItem, but a Canvas or CustomItem may have multiple TextEditors associated with it.

The implementation is only responsible for the visual representation of the cursor and text. All other visual aspects of a TextEditor, for example, scroll bars if required, are the responsibility of the MIDlet.

2. TextEditorChangeListener

The TextEditorChangeListener enables an object to listen for the TextEditor events.

The listening object is notified when

  • the caret moves

  • the text changes

  • the current input language changes

  • the current input method changes

  • the direction of the writing language changes

  • the user traverses away from the TextEditor


Copyright (c) 2009 By Simon Lewis. All Rights Reserved

July 22, 2009

What’s New In MIDP 3.0 ? Part 31: LCDUI – Text

Filed under: Java, JME, LCDUI, MIDP, MIDP3, MIDP3LCDUI — Tags: , , , , , , — Simon Lewis @ 8:59 pm

A Text object is a mutable text container with the ability to layout it’s contents.

In addition to the text it contains, it has the following attributes, all of which can be set by a MIDlet as required.

  • the width and height of the rectangle within which to layout it’s contents

  • the initial text layout direction

  • the text alignment

  • the paragraph start indentation level

  • the space in pixels above each line of text

  • the space in pixels below each line of text

  • the background colour

  • the default foreground colour

  • the default Font

  • the position and length of the currently highlighted text, if any

  • the current position, if any, of the caret</p

The colour and Font used to render text can also be set on a section by section basis if required.

The contents of a Text object can be rendered to a Graphics object which means that it can be used in conjunction with a Canvas, CustomItem, IdleItem or mutable Image.


Copyright (c) 2009 By Simon Lewis. All Rights Reserved

Older Posts »

Blog at WordPress.com.

%d bloggers like this: