Intro to MIDP Development

Intro to MIDP Development

• 1.
  MIDP  Development   Jussi  Pohjolainen   Tampere  University  of  Applied  Sciences  
• 2.
  Class  Diagram  of  MIDP  app   abstract  class  MIDlet   +  int  checkPermission(String)   #  abstract  void  destroyApp(boolean)   +  String  getAppProperty(String)   +  void  noFfyDestroyed()   #  abstract  pauseApp()   +  boolean  plaGormRequest(String)   +  void  resumeRequest()   #  abstract  void  startApp();   class  MyMIDlet  
• 3.
  Code   import javax.microedition.midlet.MIDlet; importjavax.microedition.lcdui.*; public class MyMIDlet extends MIDlet { public MyMIDlet() {} public void startApp() {} public void destroyApp(boolean unconditional) {} public void pauseApp() {} }
• 4.
  MIDlet’s  Life  Cycle   Constructor   destroyApp()   Paused   Destroyed   startApp()   pauseApp()   AcFve  
• 5.
  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()
• 6.
  Intro  to  MIDP  GUI  
• 7.
  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  
• 8.
  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  
• 9.
  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  
• 10.
  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(…); } }
• 11.
  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)
• 12.
  Display’s  methods   •  boolean flashBacklight(int d) •  boolean isColor() •  int numColors() •  boolean vibrate(int duration)
• 13.
  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  
• 14.
  Class  Hierarchy  
• 15.
  Examples  of  Displayable  objects  
• 16.
  DelegaFon  Event  Handling  
• 17.
  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  
• 18.
  SeparaFon  of  GUI  and  BL   RegistraFon   Source   Listener  
• 19.
  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!
• 20.
  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);
• 21.
  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 } }
• 22.
  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);