This post originated from an RSS feed registered with Java Buzz
by Fred Grott.
Original Post: JavaSkills Conquering Mobile World
Feed Title: ShareMe Technologies-The Mobile Future
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: A Weblog about Java programming and digital convergence on mobile devices in such areas as P2P and collaborative technology. Old Archive .
I wanted to take some time and give an analysis of where Java skills on
Mobile devices is headed and maybe how you can prepare for this new
future. According to this
SD Times article there are 3 areas of java in Mobile devices, RTSJ, J2ME,
J2SE special parts or all of J2SE(ie personaljava).
So what are the
java skills in common between RTSJ, J2ME and areas of personalJava/J2SE
being ported to J2ME? For one you are modifying your OOP approach to
bundle like minded methods in one class. One example all methods workign
with RecordStores can be put in one class even though you may be working
with more thna one record store.
Than you are avoiding those java
constructs that increase number of objects and heap sizes. One example of
this is the choice of suing StringBuffer instead of String in conversion
code such as used in RecordStore class to work with RMS which stores data
in string form. Avoid nested statemtns in the form of if statements.
Group your utility methods and global variables in a Cache class. Most menus
need a back and exit commands choices displayed to user. In handsets
prepare for your appliction to recover from being paused not only due to
incoming calls and SMS but it may be paused by user as well in most cases.
In passing objects from mobile client to server realize that there is an
object impendence missmatch and you need to use the appriporiate protocol
technology that deals with this issue. For example J2ME only has one hash
object type whereas J2SE and J2EE have several has object types.
Be
aware that depending upon end customer requirements you are either writing
to a 3 year old spec as it exists in the average mobile device or writing
to the new spec for thsoe new mobile devices coming out this fall. Also be
prepared to review Vendor bug databses. Why?
In the mobile world
although you may be developing for say MIDP1.0, Vendor A may have
MIDP1.03, Vendor B may have MIDP1.02, and Vendor C may have MIDP1.04.
This is due to absence of easy firmware upgrades on the devices, an issue
that vendors are now addressng and making head way in eliminating this
headache. Basically you modifiy your code according to the work arounds
found in the bug databases and do not forget to check the SUN J2ME one as
well in this process.
Previous Topic
