MIDP  Development  

Jussi  Pohjolainen  

Tampere  University  of  Applied  Sciences  

Class  Diagram  of  MIDP  app  

+  int  checkPermission(String)  #  abstract  void  destroyApp(boolean)  +  String  getAppProperty(String)  +  void  noFfyDestroyed()  #  abstract  pauseApp()  +  boolean  plaGormRequest(String)  +  void  resumeRequest()  #  abstract  void  startApp();  

abstract  class  MIDlet  

class  MyMIDlet  

Code  

import javax.microedition.midlet.MIDlet;

import javax.microedition.lcdui.*;

public class MyMIDlet extends MIDlet {

public MyMIDlet() {}

public void startApp() {}

public void destroyApp(boolean unconditional) {}

public void pauseApp() {}

}

MIDlet’s  Life  Cycle  

Paused  

AcFve  

Destroyed  

Constructor  

startApp()   pauseApp()  

destroyApp()  

ApplicaFon  Manager  

•  Applica'on  Manager  controls  all  the  methods  in  the  previous  slide  

•  You  can  try  to  change  the  state  by  using  methods  like:  – void notifyDestroyed() – notifyPaused() – resumeRequest()

Intro  to  MIDP  GUI  

Intro  to  GUI  

•  Problem:  Mobile  Devices  are  totally  different  from  each  other  –  Screen  size,  ResoluFon?  –  Color  Depth?  –  Input  Devices?  

•  Two  soluFons  – Abstrac'on:  Let  MIDP  take  care  of  the  pracFcal  implementaFon  

– Discover:  Sniff  the  features  of  the  current  phone  and  act  according  to  them  

AbstracFon  vs.  Discover  

•  AbstracFon:  Use  high-­‐level  API  – Portability  key  issue  – Very  easy  to  use  – LiXle  control  over  look  and  feel  

•  Discover:  Use  low-­‐level  API  – Full  control  over  graphics  – Classes  like  Canvas,  Graphics,  Image,  Font  – Time  consuming,  but  you  can  control  the  look  and  feel  

Display  

•  MIDP  GUI  could  be  seen  as  a  deck  of  cards  •  No  mulFple  windows  

•  Display is  a  class  that  represents  the  screen  display  

•  Display has  a  single  GUI-­‐element  whose  content  is  controlled  by  one  app  at  any  Fme  

•  The  main  task  of  the  Display-­‐class  is  to  take  care  of  what  is  visible  at  the  screen  

Using  Display  –  class  in  Code  import javax.microedition.midlet.*; import javax.microedition.lcdui.*;

public class MyMIDlet extends MIDlet { public MyMIDlet() {} public void pauseApp() {} public void destroyApp(boolean ignore) {} public void startApp() { Display d = Display.getDisplay(this); d.setCurrent(…); } }

Using  Display  

•  You  ask  reference  to  the  client  device's  display:  public void startApp(){ Display d = Display.getDisplay(this)

}

•  SpecificaFon  says  that  this  is  done  in  startApp-­‐method  

•  A^er  ge_ng  the  reference,  you  can  use  Display-­‐classes  methods:  –  public void setCurrent(Displayable next) –  public void setCurrent(Alert alert, Displayable

nestDisplayable)

Display’s  methods  

•  boolean flashBacklight(int d) •  boolean isColor() •  int numColors() •  boolean vibrate(int duration)

Displayable  

•  Display  is  responsible  for  changing  GUI  –  elements  on  the  screen  

•  These  GUI-­‐elements  are  Displayable –  objects.  

•  Displayable is  a  abstract  class  that  has  couple  concrete  classes  

Class  Hierarchy  

Examples  of  Displayable  objects  

DelegaFon  Event  Handling  

DelegaFon  Event  Handling  

•  MIDlet's  event  handling  system  is  the  same  as  in  Java  SE  •  DelegaFon  Event    Model:  

–  Simple  and  easy  to  learn  –  Support  a  clean  separa'on  between  applica'on  and  GUI  code  –  Facilitate  the  creaFon  of  robust  event  handling  code  which  is  

less  error-­‐prone  (strong  compile-­‐Fme  checking)  –  Flexible  enough  to  enable  varied  applicaFon  models  for  event  

flow  and  propagaFon  –  For  visual  tool  builders,  enable  run-­‐Fme  discovery  of  both  

events  that  a  component  generates  as  well  as  the  events  it  may  observe  

–  Support  backward  binary  compaFbility  with  the  old  model  

SeparaFon  of  GUI  and  BL  

Source   Listener  RegistraFon  

DelegaFon  Event  Model  and  MIDlets  

•  In  MIDP,  event  source  is  usually  Displayable-­‐object  

•  RegistraFon  is  done  with  –  setCommandListener(CommandListener l)

•  Listener  can  be  any  object,  which  class  has  implemented  the  CommandListener  interface!

Example  

•  Event  source  –  TextBox textbox = new TextBox(....);

•  Event  Listener  –  Cat listener = new Cat();

•  RegistraFon  –  textbox.setCommandListener(listener);

•  The  Cat-­‐class  must  implement  the  CommandListener-­‐class.    

•  It  is  wise  to  add  some  commands  to  the  Textbox-­‐screen:  –  Command exitcommand = new Command(..); –  textbox.addCommand(exitcommand);

Listener  

•  Listener  can  be  any  class  that  implements  the  given  interface.    

•  In  this  case,  Listener  is  a  class  called  “Cat”  class Cat implements CommandListener{

public void commandAction(Command c,

Displayable d){

// This will be called

}

}

BL  and  GUI  in  the  same  class  

•  In  small  programs  it  is  usual  that  the  GUI  -­‐  and  the  applicaFon  code  is  implemented  in  the  same  class.  

•  Now  the  listener  is  the  same  class:  –  class OmaMIDlet extends MIDlet implements CommandListener

•  And  registraFon:  –  textbox.setCommandListener(this);