Home
Blog Feed
Paxmodept Website
Mobile Portal
~mobile.paxmodept.com~
Blog Archive & Stats
| Month | Posts |
| June 2010 | (2) |
| May 2010 | (1) |
| April 2010 | (4) |
| February 2010 | (1) |
| January 2010 | (2) |
| December 2009 | (1) |
| November 2009 | (3) |
| October 2009 | (3) |
| September 2009 | (7) |
| August 2009 | (1) |
| July 2009 | (2) |
| June 2009 | (4) |
| May 2009 | (7) |
| April 2009 | (5) |
| March 2009 | (10) |
| February 2009 | (10) |
| January 2009 | (19) |
| December 2008 | (11) |
| November 2008 | (16) |
| October 2008 | (28) |
| September 2008 | (7) |
| August 2008 | (19) |
| July 2008 | (17) |
| June 2008 | (13) |
| May 2008 | (11) |
| April 2008 | (11) |
| March 2008 | (18) |
| February 2008 | (17) |
| January 2008 | (19) |
| December 2007 | (8) |
| November 2007 | (29) |
| October 2007 | (38) |
| September 2007 | (30) |
| August 2007 | (50) |
| July 2007 | (46) |
| June 2007 | (38) |
| May 2007 | (20) |
| April 2007 | (16) |
| March 2007 | (35) |
| February 2007 | (28) |
| January 2007 | (36) |
| December 2006 | (26) |
| November 2006 | (42) |
| October 2006 | (39) |
| September 2006 | (26) |
| August 2006 | (16) |
| July 2006 | (4) |
| Total | 796 |
© 2010 Jason Delport
The Secrets of Creating Great Connected Java ME Applications
Steve and I have been creating successful connected Java ME applications for over 4 years now (our first application went live in October 2003) and over that time two lessons have always asserted themselves.
(1) Mobile services are more than just the interface.
(2) Let the server do all the hard work.
Start every project with the premise that the Java ME application will be a thin client and utilize all the device resources for making the application look beautiful and function well. Make sure the user experience is the be all and end all of your Java ME developers life. Don't force them to worry about implementing complex sort algorithms in Java ME, let their sole focus be the interface.
This approach means you need to do your connectivity research, spend time finding the most optimal way to send data back and forward over the network. Analyze every function and feature of the application to see where you can consolidate information and reduce the number of connections. If you use a mark-up language remove all redundant data and optimize ruthlessly. Make sure you are always aware how much a typical session will cost the average user.
Make the server do most, if not all, of the hard graft and business logic. That may mean angry server side developers who don't understand the constraints of mobile and complain about "lazy" Java ME coders but this approach is worth fighting for upfront because its the correct long term choice.
If your clients are unwilling to write mobile specific API's then build a custom server-side proxy yourself. Typical web API's (both SOAP and REST) are not suited to creating connected mass market Java ME applications and trying to connect to them from Java ME will cause you untold headaches. If necessary go back to old school basics and transfer the data using simple comma separated mark-up, don't try to be too clever. Aim for the lowest common denominator. It's called micro edition for a reason.
I always use the iceberg metaphor in meetings with clients to describe this architectural approach. Mobile services are like icebergs. The part you actually see is only a small part of the whole.
"Never lose sight of the fact the mobile services are more than just the interface and always try to make the server do all the hard work."
(1) Mobile services are more than just the interface.
(2) Let the server do all the hard work.
Start every project with the premise that the Java ME application will be a thin client and utilize all the device resources for making the application look beautiful and function well. Make sure the user experience is the be all and end all of your Java ME developers life. Don't force them to worry about implementing complex sort algorithms in Java ME, let their sole focus be the interface.
This approach means you need to do your connectivity research, spend time finding the most optimal way to send data back and forward over the network. Analyze every function and feature of the application to see where you can consolidate information and reduce the number of connections. If you use a mark-up language remove all redundant data and optimize ruthlessly. Make sure you are always aware how much a typical session will cost the average user.
Make the server do most, if not all, of the hard graft and business logic. That may mean angry server side developers who don't understand the constraints of mobile and complain about "lazy" Java ME coders but this approach is worth fighting for upfront because its the correct long term choice.
If your clients are unwilling to write mobile specific API's then build a custom server-side proxy yourself. Typical web API's (both SOAP and REST) are not suited to creating connected mass market Java ME applications and trying to connect to them from Java ME will cause you untold headaches. If necessary go back to old school basics and transfer the data using simple comma separated mark-up, don't try to be too clever. Aim for the lowest common denominator. It's called micro edition for a reason.
I always use the iceberg metaphor in meetings with clients to describe this architectural approach. Mobile services are like icebergs. The part you actually see is only a small part of the whole.
"Never lose sight of the fact the mobile services are more than just the interface and always try to make the server do all the hard work."
~Comments~
~Add Comment~
Interesting input Jason. I have some questions for you on the comments as I'm working on such an application as we speak...and it will be my first mobile application. You make about using SOAP/REST interfaces on mobile...have you used these types of interfaces often on mobile devices? If so, what types of headaches have you seen? Have you used Fast Infoset or any other binary wire protocols that are now available for mobile web services? I come from a J2EE background so I'm interested to hear the issues. Thanks.
Hi Mike, one thing I am sure you are already aware of in regards to Java ME is that there is no consistency in the implementations. The promise of "write once, run everywhere" is a joke the Java ME universe, even more so than on desktop machines. There are many issues. (1) No default XML parser in MIDP. You will have to compromise between power and size when choosing the 3rd party parser you include. Complex XML is a PAIN to parse in Java ME. (2) No support for the PUT and DELETE HTTP verbs for REST web services. (3) No reasonably sized SOAP libraries (and that's not even considering the overall complexity of SOAP in the web world). (4) Web SOAP and REST API output tends to be very verbose and contain lots of redundant data. (5) Methods calls designed for the web are usually not appropriate for mobile. Small screens mean less data can be displayed at any one time and existing methods might be inappropriate for the mobile application work flow. (5) The temporary memory available in MIDP is limited and out of memory exceptions can't be caught and handled in a nice way. That means limited amounts of data can be sent from the server at any one time. (6) WAP gateways have a history of re-writing HTTP header data. My recommendations would be to use DataStreams or a very stripped down REST API with basic mark-up data in the response. There's nothing worse than building a great API and finding it breaks on a certain range of phones/network operators (carriers) and then having to start again from scratch. Hope that helps.
Interesting thoughts. Anyway, I think it worths to mention the main issue such an approach has to solve: comunication costs. The traffic is expensive at the moment.
Regarding fragmentation, MSA compliant devices will have a number of common capabilities that will reduce fragmentation.