Month: March 2010

Auto-update of Midlets

Any professional application should be capable of updating itself over the internet. Even Midlets! The idea is fairly easy in that the Midlet needs to make a call to the server to check what version the latest software has, and compare that to the installed version. If there is a newer version available, then it needs to start the (mobile) device's browser and point it at the URL of the new JAD file. The device will take care of the download and installation after that. So, the following article shows you exactly how this can be implemented. First off, refer to the previous article, which described a framework for making server calls. The sequence diagram looks like this: Based on the framework, the following JSP can be installed serverside, which reads the version number out of the JAD file: <%@page import=""%> <%@page import=""%> <%@page import=""%> <%@page import="java.util.List"%> <html> <body> <% RandomAccessFile raf = null; try{ String version = null; String path = request.getSession().getServletContext().getRealPath("index.jsp"); File f = new File(path); f = f.getParentFile(); f = new File(f, "jads/nameOfJad.jad"); raf = new RandomAccessFile(f, "r"); String curr = null; while((curr = raf.readLine()) != null){ if(curr.startsWith("MIDlet-Version:")){ version = curr.substring(16); break; } } %>OK <%=version%>| add other master data like the users details, their roles, etc. here... <% }catch(Exception e){ log.warn("failed to read master data", e); %>ERROR <%=e.getMessage() %> <% }finally{ if(raf != null) raf.close(); } %> </body> </html> This JSP is called when the Midlet starts, and effectively delivers "master data" to the device, such…

Read more

Choosing a Model/Event Pattern

The following diagrams show different implementation patterns of models and corresponding events, as typically used in the UI. Depending upon your needs, you can use the following tables to decide which pattern to implement. The patterns are split into model patterns and event patterns. Not all combinations of the patterns make sense, but patterns can be combined to fulfill your unique requirements. At the end I make some recommendations. Model Pattern 1 - Automatic Event Firing With the above pattern every change to the model results in an event being fired. Typically if the focus of a text field is lost, the model gets set (in Eclipse RCP perhaps using databinding). Any views that show this model attribute get notified and update themselves. Works well for cases where multiple views of the same model need to be continuously up to date. A big disadvantage is the number of events which get fired. You also need to watch out for cyclic dependencies whereby an event updates a second view, and that update fires another event which updates the first. UI performance can suffer with this pattern, because its granularity is simply too fine.   Model Pattern 2 - Manual Event Firing This pattern lets the caller (typically the controller) fire an event after it has finished updating all parts of the model. Typically the controller performs any validation of multiple fields, may call the server and when everything is good, updates the UI's model. An example might be when an input…

Read more