I've written several J2ME midlets communicating with various web applications (e.g. ofbiz and Zope). Here are a few points from my experience:
1. The J2ME platform has a very limited set of Java APIs. You will not be able to get a framework like ofbiz working on it. 2. The best option is to create a simple client that can communicate with ofbiz services. You could use SOAP but from my experience even XML parsing on the phone is difficult due to memory constraints and performance. I found it easier to create simple serialization method for objects that was shared on the mobile phone and the server. 3. J2ME is getting better but you will still find it difficult to get the same application to run the same on every phone. For simple data displays on the phone, WAP is still the easiest and most pervasive. 4. The best Java platform that I have found is the Blackberry. Their emulators are very accurate and they have an extended API set that lets you create more robust applications. Brett On 8/25/06, Chris Howe <[EMAIL PROTECTED]> wrote:
I'm brainstorming a couple of options for integration of ofbiz with mobile terminals (smartphones). What could be stripped off of Ofbiz and still provide the framework' basic database functionality with hsql or derby as well as the services and minilang. Also looking at what could be done to pair down the java requirement to JRE instead of the JDK. The most frequent use of this would be through a thin client. However, I'm needing to anticipate loss of connectivity so it needs to store information locally and then sync. Would a paired down OFBiz work for this or would it be better to look at another option for use on the smartphone and then have it sync through SOAP when connectivity is available?
