Just record some ways of data interchange in J2ME.
Size: 30 kb
XML Pull Parser, tested, low memory needed
Size: 23 kb
XML Pull Parser, not tested yet, commented by someone "blazingly fast, and low memory".
2.1 JSON ME
Download or Download JSON ME (Zip file) at JSON.org
Size: 32.1 kb
JSON has -30% data to download, this project is part of project Mobile Ajax for Java ME.
This parser can work with the expression language which works a lot like a very small subset of XPath -
the expression syntax uses the dot character for sub-elements and
square brackets for arrays. Some sample expressions are, for example -
"photos.photo.title", ".location", ".status.text", etc. This feature is very usefull, not necessary to explore the tree yourself, just give XPath and retrieve the node.
1. But like XML DOM Parser, this parser will load the entire tree in memory from one json string, if the json object is relative large(>100kb), it is more efficiant than XML Pull Parser? need test........
2. This package is not CLDC1.0 compatible, it was written based on CLDC1.1 and uses Float and equalsIgnoreCase, Boolean object. I dont understand why Float is necessary for the parser, KXML doesnot use Float but works very well. It is a pitty.
3. Binary custom protocol
Not a common solution, need develop protocols for each request, but could be lightweight and low memory cost.
J2ME Polish RMI source in included in project "J2ME Polish"
1, It is easy to implement on client and server, structure
is simple and process fast.
2, It can be used in many mobile devices, as known till now, some Benq Siemens devices do not support it.
3, The client codes which is used to access web services (named
as Stub, it is the local Java object that acts as a proxy for the Web service
instance), has been enveloped in Polish, no need to care about it.
4, It is not difficult to write the server side code. Server
side has no other configuration, simple as Servlet interface.
5, Security level is high; it seems that not many applications are
using this protocol.
1, The server source code combined with client source code,
so that it is not a simple task to maintain the project, if the web service is
becoming more and more complex. It is better to separate the two sides’ code so
that it is good for the code management.
2, All the POJOs must be written manually, if the transferring
data has many types, they should be turned to POJOs one by one. I have looked
through the code of banking client, there are many POJOs there.
3, Data types only support normal types, such as String,
double, int, array… It can not handle complex data such as tree structure.
5.1. JSR 172
J2ME Native protocol for Web Service.
1, Once all the needed toolkits have been installed, it is
easy for the client side to develop J2ME code. Because all the Stubs and POJOs J2me
code could be produced by the WTK toolkit from the WSDL(Web Service Definition
Language), which will be produced from Web Service.
2. It is easy to get the Java object and data from Web
Service in formats of SOAP and XML in J2ME client. The data type is flexible to
3, High security, Web Service has perfect system to protect
the data transferring.
4, Efficiently to parse SOAP and XML data as native function.
No need to care about the parsing process, the underground API will do that.
5, if the mobile devices support JSR 172, the size of the
application will be smaller.
1, It is complex to implement Web Service. Need Axis, or other Web Service toolkits.
2, SOAP does support only normal data types, such as Boolean,
int, String, array……. If the data contain much information in tree structure,
it is better to use XML instead of SOAP.
3, The POJOs and Stubs J2ME codes could be produced by WTK
automatically, but I have not found any way to execute this function when using
server side, besides that the server should be compiled, the server side J2ME
code should be also recompiled for the changing. If this function could be run
in ANT, that could reduce the work.
4, The server side development seems to be not easy, in my
Web Service code is more difficult than normal servlet code.
5, Does not support for all mobile phones, only for those
which has embedded JSR172 inside.
6, Data transferring efficiency, because it use XML format, but that will increase the data transfer size within the internet connection.
7, Low extending capability
Introduction to J2ME Web Services
This method is very similar with the JSR172 and Axis(2) Web
Service, the difference is by the client, KSOAP will be imported as library for
the application. Here only list the difference with the upper method.
1, Could support all MIDP2 mobile devices, works with KXML,
it can parse SOAP and XML data from Web Service.
1, Increase the size of application, the KSOAP and KXML
package has about 80kb size(after zipping).
6 Hessian Protocol
Hessian J2ME and Hessian Web Service have their own binary protocol, and it support J2ME API to parse the binary data, the data could be any thing. Hessian has XML serialization and deserialization functions.