Dopo qualche gg. di tempo prendiamo adesso in esame la classe che gestirà il comportamento del player nell’ambito del gioco.

Poichè il nostro gioco è uno shoot ‘em up le azioni che il giocatore può compiere possono essere schematizzate nel modo seguente:

1. Movimento nelle quatto direzioni (su, giù, destra, sinistra)
2. Fare fuoco
3. Acquisire rifornimenti o powerups.

Poichè ogni nostro livello ha un’ampiezza di 128 x 128 pixel, occorrerà gestire il fatto che lo sprite del giocatore non può oltrepassare il bordo inferiore [superiore] dello schermo.

Nel nostro gioco ciascun livello viene completato quando il giocatore riesce ad attraversare ciascun quadro per tutta la lua lunghezza.

Non appena lo sprite del giocatore oltrepassa il limite superiore dello schermo il nuovo livello verrà automaticamente mostrato a video andando a rimpiazzare il precedente.

Vediamo adesso di codificare le regole fissate in precedenza:

import java.io.DataInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.Vector;

import javax.microedition.lcdui.Image;
import javax.microedition.lcdui.game.LayerManager;
import javax.microedition.lcdui.game.Sprite;

public class PlayerSprite extends Sprite
{
 //final static byte DELTA_MOVE = 3;
 final static byte DELTA_MOVE = 1;
 final static byte MOVE_FORWARD = 1;
 final static byte MOVE_BACK = 2;
 final static byte MOVE_LEFT = 3;
 final static byte MOVE_RIGHT = 4;

 // Player properties
 private byte mLastMove = -1;
 private Bullet playerBullet;
 private int numOfBullets = 0;
 private int numOfLives = 0;
 private int playerStartx = 0;
 private int playerStarty = 0;
 private boolean havePowerUps = false;

Anzitutto dichiariamo la classe PlayerSprite come derivata dalla classe Sprite che il package J2ME ci mette a disposizione in modo da ridefinire (override) i metodi che ci interessano.

Definiamo poi una serie di variabili di classe il cui significato è abbastanza esplicativo e verrà immediato una volta illustrati i metodi in cui vengono impiegate.

Di particolare c’è solo la variabile playerBullet, che è un oggetto della classe Bullet, che vedremo in seguito.

Questi sono i metodi che gestiscono il movimento del giocatore:

public void moveForward()
 {
 setPosition(getX(), getY() - DELTA_MOVE);
 mLastMove = MOVE_FORWARD;
 }

 public void moveBack()
 {
 setPosition(getX(), getY() + DELTA_MOVE);
 mLastMove = MOVE_BACK;
 }

 public void moveLeft()
 {
 setPosition(getX() - DELTA_MOVE, getY());
 mLastMove = MOVE_LEFT;
 }

 public void moveRight()
 {
 setPosition(getX() + DELTA_MOVE, getY());
 mLastMove = MOVE_RIGHT;
 }

Ed esattamente, in base alla direzione scelta dal giocatore la sua posizione varia di DELTA_MOVE pixel per volta, ed al termine di ciascun passo viene memorizzata l’ultima scelta del giocatore (mLastMove).

Questi metodi invece sono dei test che verificano se il giocatore stia cercanddi oltrepassare il bordo inferiore dello schermo o quello superiore (termine del livello):

public boolean reachLowerLimit()
 {
 if (getY() <= 105)
 {
 return false;
 }
 return true;
 }

 public boolean reachEndOfLevel()
 {
 if (getY() > 1)
 {
 return false;
 }
 return true;
 }

Nel caso in cui il giocatore dovesse oltreppassare uno dei confini dello schermo, esso deve rimbalzato indietro alla posizione precedente, questo requisito viene soddisfatto dal metodo undo:

public void undo()
 {
 if (mLastMove == MOVE_LEFT)
 {
 setPosition(getX() + DELTA_MOVE, getY());
 }

 if (mLastMove == MOVE_RIGHT)
 {
 setPosition(getX() - DELTA_MOVE, getY());
 }

 if (mLastMove == MOVE_FORWARD)
 {
 setPosition(getX(), getY() + DELTA_MOVE);
 }

 if (mLastMove == MOVE_BACK)
 {
 setPosition(getX(), getY() - DELTA_MOVE);
 }
 }

Quando il giocatore attacca, facendo fuoco, accadono 2 cose fondamentali:

1. Un nuovo proiettile viene accodato
2. Un nemico che si trovasse lungo il percorso del proiettile verrà colpito e la sua reistenza verrò abbassata di un punto. Naturalemnte se la resistenza del nemico raggiunge zero, questa condizione decreterà la sua morte.

Stabiliamo anche le seguenti regole:

• Un giocatore non può attaccare nuovamente se il proiettile non ha completato il suo percorso colpendo il nemico, ovvero giungendo in prossimità del bordo superiore dello schermo. La frequenza di fuoco del giocatore cioè è pari a 1. Si può anche interpretare come un fucile che spari un colpo per volta
• Se il giocatore viene colpito muore e gli viene sottratta una vita dal numero di quelle disponibili

Questo metodo accoda un nuovo proiettile nel cannone del giocatore se la prima delle suddette regole viene rispettata:

public void encodeBullet(LayerManager layerManager)
 {
 if ( playerBullet == null )
 {    
 try {
 playerBullet = new Bullet(Image.createImage("/fire1.png"),layerManager);
 playerBullet.setPosition(getX() + 9, getY() - 10);
 } catch (IOException e) {
 // TODO Auto-generated catch block
 e.printStackTrace();
 }
 }
 }

Il metodo che segue invece gestisce l’attacco del giocatore in tutte le sue fasi: aggiorna la posizione del proiettile per ogni turno, accoda un nuovo proiettile nel caso in cui il giocatore possa attaccare, gestisce la collisione del proiettile con il nemico e ne diminuisce la resistenza nel caso in cui quest’ultimo venga colpito.

Se il nemico muore (vedi sopra) il suo sprite viene rimosso dallo schermo, analogamente se il proiettile termina la sua “vita utile”, anch’esso viene rimosso dallo schermo.

public boolean attack(Vector enemies, LayerManager layerManager)
 {
 byte bulletSpeed = 2;

 if ( playerBullet != null )
 {
 playerBullet.setPosition(playerBullet.getX(), playerBullet.getY() - bulletSpeed);

 for (int kk = 0; kk < enemies.size(); kk++)
 {
 if ( playerBullet.collidesWith((GameEnemy)enemies.elementAt(kk), true) )
 {
 layerManager.remove(playerBullet);
 playerBullet = null;
 int newStrength = ((GameEnemy)enemies.elementAt(kk)).getStrength() - 1;
 ((GameEnemy)enemies.elementAt(kk)).setStrength(String.valueOf(newStrength));

 if ( ((GameEnemy)enemies.elementAt(kk)).getStrength() <=0 )
 {
 layerManager.remove((GameEnemy)enemies.elementAt(kk));
 ((GameEnemy)enemies.elementAt(kk)).removeZombieBullet(layerManager);
 enemies.removeElementAt(kk);
 }
 return true;
 }
 }

 if ( playerBullet.getY() <= 3)
 {
 layerManager.remove(playerBullet);
 playerBullet = null;
 return false;
 }
 }

 return false;
 }

Seguono poi una serie di metodi di utilità per testare di volta in volta le proprirtà del giocatore o per inizializzare la sua posizione.

Ecco qui di seguito il codice della classe per intero, per qualsiasi dubbio o chiarimenti, chiedete pure

import java.io.DataInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.Vector;

import javax.microedition.lcdui.Image;
import javax.microedition.lcdui.game.LayerManager;
import javax.microedition.lcdui.game.Sprite;

public class PlayerSprite extends Sprite
{
	//final static byte DELTA_MOVE = 3;
	final static byte DELTA_MOVE = 1;
	final static byte MOVE_FORWARD = 1;
	final static byte MOVE_BACK = 2;
	final static byte MOVE_LEFT = 3;
	final static byte MOVE_RIGHT = 4;

	// Player properties
	private byte mLastMove = -1;
	private Bullet playerBullet;
	private int numOfBullets = 0;
	private int numOfLives = 0;
	private int playerStartx = 0;
	private int playerStarty = 0;
	private boolean havePowerUps = false;

	public PlayerSprite(Image image, int frameWidth, int frameHeight)
	{
		super(image, frameWidth, frameHeight);
		initializeSprite(1);

		/*
		try {
        	InputStream is =
        	     getClass().getResourceAsStream("/cannon.wav");
        	playerSound = Manager.createPlayer(is, "audio/x-wav");
        }
        catch (MediaException pe)
        { pe.printStackTrace();}
        catch (IOException ioe)
        { ioe.printStackTrace();}
        */
	}

	public void initializeSprite(int level)
	{
		setFrame(0);
		this.setPlayerProperties(level);
		setPosition(playerStartx, playerStarty);
		this.defineCollisionRectangle(10, 20, 10, 20);
	}

	private void setPlayerProperties(int level)
	{
		int search = 0;
		String playerProps = null;
		try {
			playerProps = readPlayerProperties(level);
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		Vector playerProperties = new Vector();
		int yy = 0;

		do
		{
			yy = playerProps.indexOf(";", search);

			if (yy != -1)
			{
				playerProperties.addElement(playerProps.substring(search,yy));
				search = yy+1;
			}
		}	

		while (yy != -1);

		this.playerStartx = Integer.parseInt((String)playerProperties.elementAt(0));
		this.playerStarty = Integer.parseInt((String)playerProperties.elementAt(1));

		if (  ((String)playerProperties.elementAt(2)).equals("T")  )
		{
			this.havePowerUps = true;
		}
		else
		{
			this.havePowerUps = false;
		}
	}

		private String readPlayerProperties(int level) throws IOException
		{
			String filler = "0";
			if ( level < 10 ) filler = "00";
		    InputStream file = getClass().getResourceAsStream("/player/level." + filler + level);
		    DataInputStream in = new DataInputStream(file);
		    String theBuf = "";
		    int y = 0;

		    try
		    {
		    	do
		    	{
		    		y = in.read();
		    		if ( y != -1 )
		    		{
		    			theBuf += (char) y;
		    		}
		    	} while ( y != -1);

		    } finally {
		        in.close();
		    }
		    return theBuf;
		}

	public void setLives (int lives)
	{
		this.numOfLives = lives;
	}

	public int getLives ()
	{
		return this.numOfLives;
	}

	public void moveForward()
	{
		setPosition(getX(), getY() - DELTA_MOVE);
		mLastMove = MOVE_FORWARD;
	}

	public void moveBack()
	{
		setPosition(getX(), getY() + DELTA_MOVE);
		mLastMove = MOVE_BACK;
	}

	public void moveLeft()
	{
		setPosition(getX() - DELTA_MOVE, getY());
		mLastMove = MOVE_LEFT;
	}

	public void moveRight()
	{
		setPosition(getX() + DELTA_MOVE, getY());
		mLastMove = MOVE_RIGHT;
	}

	public void undo()
	{
		if (mLastMove == MOVE_LEFT)
		{
			setPosition(getX() + DELTA_MOVE, getY());
		}

		if (mLastMove == MOVE_RIGHT)
		{
			setPosition(getX() - DELTA_MOVE, getY());
		}

		if (mLastMove == MOVE_FORWARD)
		{
			setPosition(getX(), getY() + DELTA_MOVE);
		}

		if (mLastMove == MOVE_BACK)
		{
			setPosition(getX(), getY() - DELTA_MOVE);
		}
	}

	public boolean reachLowerLimit()
	{
		if (getY() <= 105)
		{
			return false;
		}
		return true;
	}

	public boolean reachEndOfLevel()
	{
		if (getY() > 1)
		{
			return false;
		}
		return true;
	}

	public boolean bulletEncoded()
	{
		if ( playerBullet == null )
			return false;
		else
			return true;
	}

	public void encodeBullet(LayerManager layerManager)
	{
		if ( playerBullet == null )
		{
			try {
				playerBullet = new Bullet(Image.createImage("/fire1.png"),layerManager);
				playerBullet.setPosition(getX() + 9, getY() - 10);
			} catch (IOException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}
	}

	public void setAvailableBullets(int num)
	{
		this.numOfBullets = num;
	}

	public int getAvailableBullets()
	{
		return this.numOfBullets;
	}

	public boolean havePowerUps()
	{
		return this.havePowerUps;
	}

	public boolean attack(Vector enemies, LayerManager layerManager)
	{
		byte bulletSpeed = 2;

		if ( playerBullet != null )
		{
			playerBullet.setPosition(playerBullet.getX(), playerBullet.getY() - bulletSpeed);

			for (int kk = 0; kk < enemies.size(); kk++)
			{
				if ( playerBullet.collidesWith((GameEnemy)enemies.elementAt(kk), true) )
				{
					layerManager.remove(playerBullet);
					playerBullet = null;
					int newStrength = ((GameEnemy)enemies.elementAt(kk)).getStrength() - 1;
					((GameEnemy)enemies.elementAt(kk)).setStrength(String.valueOf(newStrength));

					if ( ((GameEnemy)enemies.elementAt(kk)).getStrength() <=0 )
					{
						layerManager.remove((GameEnemy)enemies.elementAt(kk));
						((GameEnemy)enemies.elementAt(kk)).removeZombieBullet(layerManager);
						enemies.removeElementAt(kk);
					}
					return true;
				}
			}

			if ( playerBullet.getY() <= 3)
			{
				layerManager.remove(playerBullet);
				playerBullet = null;
				return false;
			}
		}

		return false;
	}

	public void implementPower(Powerup elementAt, GameLogic gameLogic)
	{
		if (elementAt.getType().equals("AMMO"))
		{
			this.setAvailableBullets(this.numOfBullets + elementAt.getAmount());
		}

		if (elementAt.getType().equals("TARGET"))
		{
			gameLogic.stageCompleted();
		}
	}

	/*
	private void stopBulletSound()
	{
		try {
			playerSound.stop();
		} catch (MediaException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}*/
}

8. Kuix:

Kuix(Kalmeo User Interface eXtensions) cung cấp hầu hết các phần tử đồ họa như button, textfield, menu, tab… để tạo ra giao diện đồ họa và sử dụng XML/CSS để mô tả screen và các hoạt động người dùng trong ứng dụng.

Địa chỉ: http://www.kalmeo.org/projects/kuix

9. LWUIT(Lightweight UI Toolkit for Java ME) :

LWUIT cung cấp các component  để tạo ra giao diện, với mô hình lập trình tương tự Swing. Các thành phần chính của nó bao gồm: layout, PLAF & themes, Font, touch screen, animation, widgets, 3D, painter, modal dialog, external tool và I18N/L10N.

Địa chỉ: https://lwuit.dev.java.net/

10. MWT(Micro Window Toolkit):

Lấy cảm hứng từ các framework AWT, Swing và SMT, MWT cung cấp một framework UI được thiết kế và tùy chỉnh cho các thiết bị nhỏ.

Địa chỉ: http://j2me-mwt.sourceforge.net/

11. Nextel:

Nextel là công cụ mã nguồn mở chứa các thư viện để phát triển UI và RMS trên J2ME handset.

Các công cụ cửa sổ, OWT(Open Windowing Toolkit), sử dụng một mô hình container/component, và cung cấp giao diện cho phép các developer tạo ra các giao diện người dùng. Công cụ này được thiết ký dành riêng cho MIDP handsets. Và nó được xây dựng dựa trên Canvas.

Địa chỉ: http://nextel.sourceforge.net/

12. OpenBaseMovil:

Ngoài cơ sở dữ liệu và scripting engine, OpenBaseMovil chứa một view khai báo định nghĩa ngôn ngữ. Với file XML bạn có thể thiết kế các view theo ý mình, và chúng hướng tới các script và data: bạn có thể duyệt một tập hợp các kết quả có ít hơn 10 dòng mã.

Địa chỉ: http://www.openbasemovil.org/about/

13. Synclast:

Synclast UI API là một công cụ mở rộng cho việc tạo ra giao diện người dùng tùy chỉnh màu sắc trên MIDP một cách trực quan.

Đia chỉ: http://www.synclast.com/ui_api.jsp

14. Thinlet:

Thinlet là một công cụ GUI, một lớp Java đơn giãn, phân tích  hierarchy và các property của GUI, xử lý các tương tác ngườ diùng và gọi ở mức logic business. Nó tách biệt giữa phần trình bày đồ họa với các phương code java.

Địa chỉ: http://thinlet.sourceforge.net/home.html

15. TWUIK:

TWUIK Rich Media Engine là một công nghệ UI kết hợp cả graphic, animation, rich media và các tương tác triển khai trên một phạm vi rộng lớn hỗ trợ các thiết bị J2ME.

Địa chỉ: http://www.tricastmedia.com/twuik/

With many thanks to Graham over at the Nokia Discussion forums I came across an interesting Wiki article (Platform independent key events processing) which provides a class that tries to determine common non-standard keycodes for a variety of handsets. The second handset that I tested was an LG KS360, unfortunately this detection class was unable to detect the soft key buttons.

I have combined my welcome screen based soft-key detection into that class as a fail-safe, and this seems to be working great. So, where possible the correct keycodes are detected by working out the device vendor, and then where all else fails, accept the first non-standard keycode that is returned from the welcome screen for the left soft-key.

I have also added a SOFTKEY_GUESSED field which indicates if the left soft-key value was guessed. If it was, then you can decide whether or not to allow other non-standard keys to represent the right soft-key. You might decide against guessing the right soft-key in more critical scenarios where data could potentially be lost by pressing another unrelated button on the keypad.

The combination of these two techniques seems to provide a much better solution.

Sau đây tôi xin giới thiệu một số framework J2ME dựa trên Canvas(low-level UI). Bạn có thể dùng chúng để tạo ra các giao diễn đẹp thay vì phải sử dụng các lớp trong high-level UI của MIDP như: Form, List, TextBox…

1 .Apime:

Apime là một framework cung cấp nhiều chức năng cho J2ME/MIDP. Nhân(core) của nó là UI, với các components cơ bản được tạo ra theo cấu trúc swing. Ngoài ra nó còn có các lớp dùng để quản lý file và tùy chỉnh skins, internationalization, keyboard cho nhiều loại ngôn ngữ khác nhau…

Địa chỉ: http://www.java4ever.com/index.php?section=j2me&project=apime&menu=main&lang=_en.

2. Fire(Flexible Interface Rendering Engine):

Tập hợp các thành phần cơ bản của Fire cung cấp tất cả các chức năng của các thành phần Java ME GUI có sẵn trong MIDP 2.0 như Form, Items… cộng với một số thành phần giao diện, theme, animation, popup menu và các thành phần layout đẹp mắt.

Địa chỉ: http://sourceforge.net/projects/fire-j2me/

3. J2ME GUI:

Một thư viện GUI lightweight cung cấp tất cả các thành phần giao diện tương tự như MIDP. Ngoài ra nó còn có thể được mở  rộng tùy theo nhu cầu phát triển. Hiệu suất cao trên cả những thiết bị có cấu hình thấp, với các style tùy chỉnh, và tương thích với nhiều loại thiết bị.

Địa chỉ: http://www.garcer.com/

4. J2ME Lightweight Visual Component Library(LwVCL):

LwVCL hỗ trợ cả java(J2SE/J2ME Profile) và .NET platform.

Địa chỉ: http://www.lwvcl.com/j2me.php

5. J2ME Polish:

J2ME Polish chứa bộ công cụ LUSH để tùy biến giao diện mà không thay đổi mã nguồn ứng dụng. Việc thiết kế các hiệu ứng và chuyển động được đặt trong file CSS bên ngoài, tương tự như Web. Ngoài ra, còn có một designer WYSIMYG cho thiết kế giao diện.

Địa chỉ: http://www.j2mepolish.org/

6. J4ME:

J4ME là một thư viện mã nguồn mỡ dùng để build các ứng dụng J2ME. Nó giải quyết nhiều hạn chế của J2ME: UI, Logging, GPS và các phương thức nằm bên ngoài J2ME.

Địa chỉ: http://code.google.com/p/j4me/

7. jMobileCore:

Thư viện jMobileCore là một tool mạnh để tạo các ứng dụng trên J2ME. Nó hỗ trợ phát triển các thành phần giao diện, truy cập dữ liệu nhanh và truyền thông tin cậy và đơn giãn hóa việc tạo ra các ứng dụng đa luồng.

Địa chỉ: http://jmobilecore.sourceforge.net/

II. GameCanvas:

Lớp Canvas được thiết kế cho các ứng dụng hướng sự kiện(event-driven), đó là màn hình được cập nhật khi người dùng nhấn một phím hay một soft-key. Tuy nhiên, các ứng dụng game có xu hướng hướng thời gian(time-driven) và tiếp tục update screen cho dù người dùng có nhấn phím hay không, và lớp GameCanvas cung cấp cơ sở giao diện cho người dùng game, ngoài các đặc điểm kế thừa từ lớp Canvas, nó còn có các đặc điểm nổi bật hơn lớp Canvas. Đầu tiên, ứng dụn game được điều khiển một cách chính xác khi display được update, thay vì phải đợi system sofware gọi phương thức paint(). Thứ hai, nó điều khiển được vùng màn hình  được update. Thứ 3, nó cung cấp các khả năng đặc biệt: đó là bộ đệm graphics off-screen và khả năng query trạng thái phím.

2.1. Key Polling:

Lớp GameCanvas cung cấp khả năng thu nhận trạng thái phím thay thế cho implement các phương thức callback để xử lý cho mỗi sự kiện phím. Key polling tạo ra sự logic trong việc xử lý phím và thực thi tại thời điểm thích hợp trong vòng lặp game. Đồng thời, nó cho phép detect việc nhấn nhiều phím tại 1 thời điểm trên thiết bị hỗ trợ chúng.

Phương thức getKeyStates() trả về trạng thái phím với một giá trị integer, mà mỗi bit của nó tương ứng với một specific key được nhấn hay đã được nhấn ở lần trước đó của phương thức getKeyStates(). Ví dụ:

int keyStates = getKeyStates();

if ((keyStates & UP_PRESSED) != 0) yPosition–;

if ((keyStates & DOWN_PRESSED) != 0) yPosition++;

if ((keyStates & FIRE_PRESSED) != 0) fireRocket();

2.2. Screen Buffer:

Không giống như lớp Canvas(chia sẻ tài nguyên screen với các ứng dụng khác), mỗi đối tượng GameCanvas sẽ có một screen-buffer riêng, để developer có thể vẽ lên nó tại bất kỳ thời điểm nào sử dụng đối tượng Graphics. Mỗi đối tượng Graphics được tạo ra bằng cách gọi phương thức getGraphics().

Nó tối thiểu được việc sử dụng bộ nhớ heap và tránh được lỗi bị flicker khi vẽ lại màng hình. Bạn chỉ cần gọi phương thức flushGraphics() để hiển thị đối tượng Graphics này ra màn hình. Kỹ thuật này thức chất là nó vẽ một image tạm thời từ đối tượng display thực tế, khi gọi phương thức flushGraphics() thì nó hiển thị đối tượng image tạm thời này lên màn hình. Nó có thể flush toàn bộ hay một vùng buffer. Các phương thức này sẽ không làm gì nếu GameCanvas không biểu diễn currently.

Ngày nay, với sự phổ biến của J2ME và sự bùng nổ của các loại game trên điện thoại di động  đã thôi thúc các nhà sản xuất tùy chỉnh lại các lớp để hổ trợ cho việc phát triển game. Và vấn đề chính ở đây chính là tính linh động(portability). Ví dụ, sử dụng lớp Sprite trong Siemens thì sẽ gặp rắc rối trong việc cài đặt cho các loại điện thoại Nokia, để khắc phục vấn đề này, bạn phải re-implement lớp Sprite.

Với MIDP 2.0, các vấn đề về tính linh động của game được giải quyết với 5 lớp sau:

• GameCanvas
• Sprite
• Layer
• LayerManager
• TiledLayer

Trong đó, lớp Layer là lớp trừu tượng, làm superclass cho các lớp: Sprite, LayerManager, và TiledLayer. Cả 5 lớp này nằm trong gói java.microedition.lcdui.game.

Không chỉ giải quyết được vấn đề về portability, mà nó còn làm cho code tối ưu hơn, nhỏ gọn hơn vì bạn không cần phải implement các lớp custom như  Sprite, bởi các lớp này giờ là một phần underlying Java Enviroment trên mobile handset.

I have this javame library I have been compiling for a while. It has a lot of small small code snippets and classes I use often, there is a database part where I have tried as much as possible to encapsulate parts of the saving/retrieving parts of RMS, there is also the UI part, which is what I want to talk about today.

This part contains a TickerForm, which is a form that can show scrollable contents pulled from database or URL at intervals(I am yet to finish it) and the second thing is the Controllable form. This form has a Controller that you can use to service the form(just like posting a form through POST). You call the submit() method of the form and the service method of the controller is called. The service method stores the values of items of the form in a Properties object(which is basically a key-value pair). A code is worth more than a thousand words they say, so here we are

/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package com.trinisoft.atpay.forms;

public void commandAction(Command c, Displayable d) {
if (c.equals(ok)) {
submit();
if(getResponseCode() == 200) {
display.setCurrent(loginForm);
} else {
Alert l = new Alert("Error Occurred",getResponseText(),null,AlertType.ERROR);
display.setCurrent(l,d);
}
} else if (c.equals(cancel)) {
mainForm.notifyDestroyed();
}
}
});
}
}

You should draw your attention to two places, the contructor and the commandAction in the init() method. In the super constructor, you pass in a Controller, the controller have a service method, which handles the forms submit() and stores response-code and reponse-text keys and values in the Properties passed to it. These keys are used in the commandAction to get the response code and value. Any other value(or object for that matter) that you want to send back as response can be stored in the Properties object.

I think this suite of classes would be useful for anyone interested in Java ME development. Try it out and let me know your feedbacks.

Code hosted at www.gitorious.org/~trinisoftinc

ciao

Apa Itu J2ME?

J2ME merupakan sebuah kombinasi yang terbentuk antara sekumpulan interface Java yang sering disebut dengan Java API (Application Programming Interface) dengan JVM (Java Virtual Machine) yang di desain khusus untuk alat, yaitu JVM dengan ruang terbatas. Kombinasi tersebut kemudian digunakan untuk melakukan pembuatan aplikasi-aplikasi yang dapat berjalan diatas alat (dalam hal ini mobile device).

Mungkin anda bertanya, apakah kita, sebagai pengembang aplikasi (developer/programmer), harus melakukan instalasi JVM dan Java API ke dalam alat yang akan kita gunakan? Jawabannya: “TIDAK”. Masing-masing dari perusahaan alat telah menyediakan JVM (dan sekumpulan Java API yang diperlukan) di dalam alat bersangkutan. Hal ini, membuat kita sebagai developer, hanya perlu berkonsentrasi dalam pengembangan aplikasinya dan memasukkannya ke dalam alat tersebut.

J2ME memiliki beberapa keterbatasan terutama jika diaplikasikan pada ponsel. J2ME sangat tergantung pada perangkat yang digunakan bisa dari segi merk ponsel, kemampuan ponsel, keterbatan memori pada ponsel, masalah pengijinan hak akses pada file-file tertentu pada ponsel dan dukungan terhadap teknologi J2ME.

J2ME sendiri pada dasarnya terdiri dari tiga buah bagian, yaitu: konfigurasi, profile, dan paket-paket opsional, seperti yang di tunjukkan pada gambar 1.

Gambar 1. Bagian-bagian di dalam platform J2ME

(Sumber http://developers.sun.com/mobility/configurations/articles/cdc/)

Berikut ini penjelasan dari masing-masing bagian tersebut.

1. Profile

Profile merupakan bagian perluasan dari konfigurasi. Artinya, selain sekumpulan kelas yang terdapat pada konfigurasi, terdapat juga kelas-kelas spesifik yang didefinisikan lagi di dalam profile. Dengan kata lain, profile akan membantu secara fungsional yaitu dengan menyediakan kelas-kelas yang tidak terdapat dilevel konfigurasi.

Adapun profile yang sangat populer penggunaanya adalah profile yang disediakan oleh Sun Microsystems, yaitu yang dinamakan dengan MIDP (Mobile Information Device Profile). Gambar 2 menunjukkan perbandingan antara MIDP 1.0 dengan MIDP 2.0. Sebagai tambahan pengetahuan bagi Anda, berikut ini beberapa profile yang tersedia untuk kebutuhan-kebutuhan spesifik lainnya:

• PDAP (Personal Digital Assistant Profile), yaitu profile untuk PDA yang memperluas fungsi-fungsi pada konfigurasi CLDC dan digunakan khusus untuk menambahkan kemampuan-kemampuan lebih apabila dibandingkan dengan penggunaan profile MIDP.
• Foundation Profile, yaitu profil yang digunakan untuk konfigurasi CDC. Profile ini menambahkan beberapa kelas dari J2SE ke dalam konfigurasi CDC, dan berperan juga sebagai pondasi untuk membentuk profile baru lainnya.
• Personal Profile, yaitu profile yang mendefinisikan ulang Personal Java sebagai profil yang dapat digunakan sebagai profil dalam J2ME. Profil ini merupakan hasil perluasan dari Foundation Profile.
• RMI Profile, yaitu profil yang menambahkan dukungan RMI (Remote Method Invocation) ke dalam konfigurasi CDC.

Gambar 2. Perbandingan antara MIDP 1.0 dan MIDP 2.0

(Sumber http://arie8011.blogspot.com/2009/04/sekilas-java-dan-j2me-java-2-micro.html)

2.  Konfigurasi

Konfigurasi merupakan bagian yang berisi JVM dan beberapa library kelas lainnya. Perlu diperhatikan bahwa JVM yang dimaksud di sini bukanlah JVM tradisional seperti yang terdapat pada J2SE, melainkan JVM yang sudah didesain secara khusus untuk alat.

Terdapat dua buah konfigurasi yang disediakan oleh Sun Microsystems, yaitu CLDC (Connected Limited Device Configuration) dan CDC (Connected Device Configuration). Target alat dari konfigurasi CLDC adalah alat-alat kecil, seperti telepon selular, PDA, dan pager. Pada sisi yang lain, CDC, merupakan superset dari CLDC sehingga semua kelas yang didefinisikan di dalam CLDC akan ada juga dalam CDC. Gambar 3 menunjukkan perbandingan antara CLDC dengan CDC.

Gambar 3. Perbandingan antara CLDC dengan CDC

(Sumber http://arie8011.blogspot.com/2009/04/sekilas-java-dan-j2me-java-2-micro.html)

3.  Paket-Paket Opsional

Paket-paket opsional merupakan paket-paket tambahan yang dibutuhkan oleh aplikasi sehingga pada saat proses deployment paket-paket tersebut perlu didistribusikan juga sebagai bagian dari aplikasi bersangkutan. Sebagai catatan bahwa paket-paket opsional  ini bukan merupakan paket yang dibuat oleh perusahaan alat yang digunakan]

Referensi:

1. Tuntunan pemrograman Java untuk Handphone, karya mas Budi Raharjo dkk.
2. http://arie8011.blogspot.com/2009/04/sekilas-java-dan-j2me-java-2-micro.html
3. http://developers.sun.com/mobility/configurations/articles/cdc/

I have this problem with my iPhone, Whenever I run the battery down to less than 20%, the phone won’t charge again when I plug it in my MAC. But if I plug it in windows it will charge, if and only of the windows box is not been used. If the windows PC is in use, then no charging for iPhone. Of recent, the iPhone started behaving very funny too. Sometimes, the MAC will charge it sometimes it won’t. So I decided to look for reasons why.

First I note that when the battery is below 20%, before you plug it in, shut it down first, then plug it in and everything will be fine. Next, The iPhone will charge if iTunes is not running before you plug it in. If iTunes is running, then you have to close iTunes and open it again, and iPhone is charging. Next I also noticed that most of the electric chargers that ship with the iPhone will not work for you once you jailbreak the iPhone.

The iPhone is a great product, but when people complain about the battery, I think it goes beyond the mere fact that it runs down quickly, the battery of the iPhone is generally shitty, You will be surprised at the vast amount of people who have posted online about this(google is your friend) and yet, apple seems to not want to do anything about it! Although this problem of not charging seems to be experienced by mostly people who jailbroke their iPhones.

Anyway, after about 4hours, today I now know exactly the voodoos I have to invoke to make the iPhone charge anytime anyday anywhere…..I pity the less tech savvy people who use jail broken iPhones.

Olá a todos, e com muita satisfação que liberamos o 1º demo do nosso jogo, para que todos ja possam ver como está ficando. Para jogar basta baixar os arquivos e mandar para o celular pelo cabo ou pelo cartão de memória. Bom é isso, estão aí os links:

Memoria Matemática:

http://rapidshare.com/files/309439901/Memoria2.jar.html

Jogo das Contas:

http://rapidshare.com/files/309442573/MidContas.jar.html

As many of you are aware, the soft key buttons on a mobile phone are general purpose buttons that are reused over and over again. On most handsets there are two of these directly beneath the screen (one on the left, and one on the right).

In a recent project I needed to be able to detect when the left and right soft keys were being pressed, but unfortunately, J2ME does not define a standard key code. Instead it is up to the developer to specify different codes for all of the different phones in their target audience.

Two solutions came to mind:

1. Compile the application for each target handset (perhaps overkill given that this be the only difference).
2. Get the user to specify which button is which (even if they do not realize this!).

I decided to go with option #2 so that my application would work for the majority of handsets. Instead of asking the user to configure the keys directly, I created a welcome screen.

The welcome screen contains a nice greeting, but more importantly the text “Continue” in the bottom left corner. The user will instinctively press the soft key button that is nearest that text, and so the key code is known for the rest of the application. I decided to filter out all known keys so that the user does not press the “FIRE” button, etc.

Welcome Screen for J2ME

Once the key code of the left soft key is known, we can assume that any other non-standard button that is pressed is the second soft-key.

Please note that this does mean that other unknown buttons will also behave as the second soft key.

Here is a simplified version of the welcome screen that I used:

public class WelcomeCanvas extends Canvas {
   public WelcomeCanvas() {
      setFullScreenMode(true);
   }

   protected void paint(Graphics g) {
      g.setColor(0x336699);
      g.fillRect(0, 0, getWidth(), getHeight());
      g.setColor(0xFFFFFF);
      g.setFont(Font.getFont(
         Font.FACE_SYSTEM, Font.STYLE_PLAIN, Font.SIZE_LARGE));
      g.drawString("Welcome!", getWidth() / 2, getHeight() / 2,
         Graphics.HCENTER|Graphics.TOP);

      // The all important continue text!
      g.setFont(Font.getDefaultFont());
      g.drawString("Continue", 2, getHeight() - 2,
         Graphics.BOTTOM|Graphics.LEFT);
   }
   protected void keyPressed(int keyCode) {
      if (!SoftCommandCanvas.isKnownKey(this, keyCode)) {
         SoftCommandCanvas.KEY_SOFT_LEFT = keyCode;
         continuePressed();
      }
   }

   protected void continuePressed() {
      // Do something!
   }
}

Here is an example of how you can detect which soft key is being pressed in another canvas:

public class SoftCommandCanvas extends Canvas {
   // The default value here works for Nokia handsets.
   public static int KEY_SOFT_LEFT = -6;

   public SoftCommandCanvas() {
      setFullScreenMode(true);
   }

   public static boolean isKnownKey(Canvas canvas, int keyCode) {
      return (keyCode >= KEY_NUM0 && keyCode <= KEY_NUM9) ||
         keyCode == KEY_POUND || keyCode == KEY_STAR ||
         canvas.getGameAction(keyCode) != 0;
   }

   protected void keyPressed(int keyCode) {
      if (!isKnownKey(this, keyCode)) {
         if (keyCode == KEY_SOFT_LEFT)
            fireLeftSoftCommand();
         else
            fireRightSoftCommand();
      }
      else
         super.keyPressed(keyCode);
   }

   protected void fireLeftSoftCommand() {
      // Do something!
   }

   protected void fireRightSoftCommand() {
      // Do something!
   }
}

This is my experience with the JavaME EA for MAC OS. I am using 10.5.8(Leopard).

At first it was a God sent that we now have a tool from sun. Using Netbeans and mpp-sdk kinda sucks, but it was all I have got. After the download, which went without incidents, I ran the EA for the first time and it blew all the whistles and knock all the bells. I immediately opened a sample app and run it, It ran well without incidents. Then out of the blue, I got the first error.

When trying to run ANY application, it will return with an exception/error message that it can not connect to device 0, or any of the devices I used at that. I googled and all the responses were not helping me at all. At last I did the unthinkable, guess what that is? I restarted my MAC. I have not done that in a looooooong while so it took some time before the system actually finished the restarting process and voila, my EA was back online. But not for long!

Next, EA takes it upon itself to just DIE for no reason. I run an app, and the next thing is the EA has stopped working un-expectedly. I also tried googling, but no result. So I started fooling around. I went to tools and refresh the SDK under platforms and voila again, EA stops dying. But again, that was not all.

Next I noticed that after running an app for about 6 to 10 times, EA will stop working saying it has run of memory. I tried to close all applications while running EA but, duh! after about 6 to 10, sometimes 15 runs, it will stop working with the same out of memory error. The annoying thing is, it won’t even quit. I will have to use force quit(windows version of CTRL + ALT + DEL).

I am yet to solve this problem, and I don’t think I will ever solve it until the next version comes out. Looking back however to the days of mpp-sdk and Netbeans, I think I still prefer the EA, At least I can do Bluetooth without having to buy some licence from some people.

All in all, I give Sun +1 on this. It is really something all MAC developers have been asking for since time immemorial. All that remains is perfection. And if I remember correctly, in software, attaining perfection is an eternal process. No software is perfect until it is dead.

One thing I will give kudos to the EA guys for again is that, all projects created on Netbeans also works perfectly on EA, be it from windows or linux. +1 to you guys again on that.

Finally, EA is a good product. If you are a MAC J2ME developer, you will enjoy this IDE.

So i’ve decided it’s time to tell the world what I am doing because surely they are all intensely interested and can’t survive another day without knowing what Dave is up to next.

Primarily I will be blogging about my new initiative to upgrade my mobile application development skills to keep up with the Joneses. You see, back in 2001 I began developing stuff in J2ME and have done so ever since, but the world spins at a bloody fast pace and this year I have felt like I have fallen off.

I was one of those VERY early adopters of Java for mobile phones, having started with tools such as Whiteboard SDK, MIDP 1.01 and the like. I even got my hands on a Motorola iDen i85s from a mate at Motorola Labs in Sydney (this phone is now a museum piece) so that I could run Java apps on an actual device as opposed to an extremely buggy emulator.

In 2002 I predicted that Java for mobile phones was going to be the future. Not all would have agreed (deluded Qualcomm BREW people for example). When I attempted to buy Nokia’s first Java handset (the 6230i) from a Sydney Telstra store, the pimply kid – ahem – salesman told me “Java, that’s just a gimmick. Now you really want THIS phone <points me to other device that I don’t want>”. Still, a billion Java phones later I reckon I was right.

Recently I have felt that despite their best efforts, Sun has failed to move to the next level with J2Me. It’s reaching the end of it’s road. Perhaps the mobile apps and games market has simply grown up and there are sweeping winds of change. So it’s time for me to grow up too.

First decision: which platform to move to. There appears to be 3 main contenders here:

1. Apple iPhone SDK
2. Google Android
3. Symbian

The winner for me was surprisingly obvious: Android. Here’s why:

1. Symbian? No, forget it. Not cool enough by half.
2. iPhone? hmmm, C based. I haven’t written a line of code in C since Data Org class at UNSW in 1998.
3. Android is Java-based. So am I.
4. iPhone is limited in distribution. Yes yes, I know, 2 billion apps downloaded…I don’t care. iPhone’s OS and platform will always be limited by the fact it only runs on one set of devices: Apple’s. It is the same thing that limits Mac OS from ever being as widely used as Windows. Those who use iPhone’s love them and download heaps of content, but they will soon be swamped in number by more open platforms that are just as good if not better.
5. Android will be that platform swamps iPhone. Mark my words, it will happen. Not in 2010, maybe not in 2011, but by 2012 it will be dominant. It will also run into many of the same fragmentation problems that plagued J2ME, but with the benefit of hindsight Google can be prepared for that.

So Android it is, and my adventures in learning Android will be told for young and old.

Hey guys,

a lot of things are going on at the moment. I am working on a few different gaming projects with some really interesting people.

A first version of my Super Koopa War, where the player fights Goombas, Shyguys and Monty Moles and tries to defeat Super Mario, will be released for J2ME phones in the near future. A few things regarding usability, balancing and game fun are still to do, before the Demo will be released on the bolg. This little game shall serve as tutorial on how to implement a mobile game with a nice architecture (entity system, event system, collision detection, physics and a nice animation concept) in J2ME.

Additionally, we are working on a second (top secret) project, either for the iPhone or for the PSP, since we have the PSP DevKit now at University.

To provide you guys with new stuff, I posted a new tutorial at the publications section. It is a simple Solar System in 3D. Also a first person camera has been implemented to show how things work in the source code. This example does not use OpenGL functions. Matrices, vectors and calculations are done manually. This should give an impression on what OpenGL does when someone calls gluLookAt() or glRotate(). So camera, transformations and rotations are calculated and applied by hand. Feel free to download the example and play around with it.

Am fost surprins să citesc de faptul că Ericsson Labs oferă suport pentru hărțile OSM în propria librărie Mobile Maps. Spre deosebire de Google Maps librăriile de la EL oferă suport pentru randarea dinamică a datelor vectoriale, personalizarea hărților și suport pentru majoritatea telefoanelor de pe piață, datorită faptului că sunt dezvoltate pentru Java ME și Android.

Sunt oferite cu titlu de două aplicații (Guidu și Photocaching) care folosesc această librărie dar din păcate documentație este unul din punctele slabe deocamdată (pentru un astfel de produs e nevoie de un tutorial bine pus la punct). Am găsit în cele din urmă și două tutoriale (câte unul pentru fiecare platformă suportată) care pot fi încercate la adresa https://labs.ericsson.com/apis/mobile-maps/android-getting-started sau https://labs.ericsson.com/apis/mobile-maps/documentation/getting-started-tutorial.

Exemplu Mobile Maps pe emulatorul Android

Mobile Maps + J2ME

Sursa: https://labs.ericsson.com/apis/mobile-maps/blog/openstreetmap-android.

Projekt mobilny powoli nabiera rozpędu. Powstają elementy API mobilnego jak również poszczególne funkcjonalności i projekty interface’u. W ostatnich dniach udało się nawet uruchomić testowo niektóre funkcjonalności. Choć do zakończenia projektu i testów zewnętrznych jeszcze daleko to widać już znaczące postępy. Niewątpliwie listopad bedzie bardzo pracowity

Śledzik mobilny: ekran logowania

Śledzik mobilny: loading

Śledzik mobilny: followers

W końcu zabrałem się za czytanie książek o JSP. Póki co ustawiłem Tomcat’ a i bazę danych MySQL. Mam zamiar stworzyć galerię zdjęć dodawanych za pomocą komórki tzn. jeszcze będę musiał napisać aplikacje J2ME by móc cokolwiek wysyłać z komórki ale mam nadzieje że się uda dość szybko to zrobić. Przede mną jeszcze rozwikłanie zagadki jak to ze sobą połączyć i jak wykorzystuje się połączenie z internetem w komórkach do przesyłania danych. A potem jak aplikacja ma odbierać te dane i gdzie je składować. Tak więc troszkę jest :] Ale przynajmniej ciekawi mnie to.

Heya there… this is the first tutorial on my J2ME developing series. Have fun…

So, to start up, beginning to experimenting with mobile along with java development, j2me pulled my eyes. j2me is the sun’s implementation on java for the mobile industry. Nowadays, almost every cellphone, smartphone, PDA, etc… manufacturer provides java support, the all known .jar files which you can find everywhere in the web.

So, to start up, beginning to experimenting with mobile along with java development, j2me pulled my eyes. j2me is the sun’s implementation on java for the mobile industry. Nowadays, almost every cellphone, smartphone, PDA, etc… manufacturer provides java support, the all known .jar files which you can find everywhere in the web.