Tag: GUI

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="java.io.FileInputStream"%> <%@page import="java.io.RandomAccessFile"%> <%@page import="java.io.File"%> <%@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

GUI Performance Enhancement Strategies

Graphical User Interfaces (GUIs) tend to be event driven. A user performs an action and the GUI sends that event to any interested components through a Model-View-Controller mechanism. When the events being sent represent fine grained actions (for example a single field on a form changed, as opposed to coarse grained events like the form being submitted), the performance of the GUI can become an issue. Other examples of when performance of the GUI might become an issue are: when the model in the GUI is large, when the GUI needs to process the data a lot in preparation for displaying it (either client or server side), when the GUI is poorly implemented and duplicate listeners exist meaning that components are refreshed multiple times, unnecessarily. The following strategy has been used to help improve GUI performance. This list is ordered with the easiest / most important tasks (least effort, best improvement) at the top: ensure a clean MVC implementation, without duplicate listeners, add data caches, optimise caches (e.g. they hold more than one object graph), optimise refreshing of non-active elements. 1) Clean MVC Implementation First of all, read the MVC article on this blog. Then, using a profiler or debugger follow your controller as it fires model change events. Are any model listeners fired more than once for any reason? If they are, it is less than optimal and you need to first look for mistakes in the programming logic. If there really is a good reason that the event…

Read more

Object Orientation (OO) in GUIs

I was taught (hopefully rightly) that a class contains data relevant to it and methods which act on that data. For example, a class representing a Monkey might have attributes like date of birth, male/female, number of children, and a reference to the zoo where it lives. Methods might be getYearsOld() to work out how many days old it is, haveSex(List<Monkey> partners) , addChild(Monkey kid), setZoo(Zoo newHome). Equally a complex graphical user interface component like a tree or a table might contain a matrix or hierarchy of cells and methods for setting the cells attributes (data, size, borders, rendering information, etc). It would typically have renderers for painting the cells as well as perhaps editors for editing the data in the cells. In fact, Swing has a rather nice implementation of Tables, Trees and even Tree-Tables. Eclipse JFace is fast catching up. So if you do find yourself building something like this, say in Java Script, look at the nearest thing you can find that already exists, analyse how object oriented it is, then implement something similar (even sub-class it). What you want to avoid is creating a load of helper methods which just build the GUI in a totally pre-object-oriented manner - Builder Classes as I call them. I have seen this done several times by programmers that learned to program in the object oriented age. It might be expected from an older programmer who learned to program pre-object orientation, or one that has never used an object oriented…

Read more

SAP, SOA and a GUI

When I first learned about SAP, I was led to believe it was insular. Sharing its data or uploading data to it was possible, but expensive and discouraged. If you have SAP, stick with it. Then came XI, the SAP eXchange Infrastructure which is the SAP offering for Enterprise Application Integration (EAI), or now rather Enterprise Service Bus (ESB). With it, you can build marvellous Service Oriented Architectures (SOA). So what? Well, my experience of XI is that its used as a replacement for IDOCs, BAPI, EDI and the like. Instead of those hard to use protocols, simply subscribe to a published web service. But hang on... If SOA is in use, couldn't we go a step further? SAP isn't very good at really rich clients (GUIs), and chances are, to develop one would cost a huge amount. So what about the idea of building your business logic on top of existing SAP functionality, so that you extend it to suit your business processes, and then build that rich client on top of the SOA that SAP can offer from your business logic? An example would be the project I'm working on at the moment. We need to build a planning tool for use in Service Stations for trains. Service stations consist of a large number of platforms where trains can be serviced. Some types of service can only be done on some platforms (axle change for example). As well as planning which trains go where and when and for…

Read more