Hi. This is an open discussion I would like to start.
With TM Studio you have a set of nice adapters you can use to access web services, databases, etc. The problem is that, if you use them from the controller, that controller probably will not be able to run in offline. E.g. if you use a SQL adapter, your controller will not work in a Pocket PC or MIDP environment.
So the adapters are indeed very well suited for single-platform controllers (e.g. online apps), but if you plan to create a multiplatform app better you not use them from the controller.
This means you have to program all that in the model Java classes. It is a real pity Studio not only does not help on that, but even misguides you into using adapters that will prevent the application from being multiplatform.
I would like to discuss the best way of doing that kind of multiplatform models. I am currently creating one, and what I am doing is:
- There is a set of Java classes, created from inside the Studio, that implement the “business logic” and are independent of the storage method. In fact, these classes do not have any real storage; they just made up fake data. They are useful for creating the application logic and interfaces, but you cannot handle or synchronize real data.
So the controller relies exclusively in that single set of “business logic” classes, that (as the controller) should work for every platform.
- Created outside Studio, there is another set of classes that extend the business logic ones, so that they inherit the business logic but provide the storage logic. I plan to do a set of classes for Tamino XML Server (online), another for Tamino Mobile DB (Pocket PC, laptop) and yet another one for MIDP (Palm, Symbian).
Using Ant for building these outside classes, they are easily integrable with the TMStudio build process.
Interesting points are:
- The business logic classes must be MIDP-compliant; e.g. they must be restricted to use the MIDP classes. Of course, the storage-specific classes have not to do so.
- Each set of storage-specific classes will be totally independent; they are not in the global project classpath, so that they do not interfere and, most important, they do not get deployed in every platform. I deploy them by setting target-specific properties and prebuild.xml files.
- For selecting which storage-specific set of classes must be used, I do not rely on property files and so, but I have a master-factory class (environment) that is instantiated from target-specific model states (e.g. a state for online, in an online-exclusive layer, and so on). Once the master factory is instantiated, all classes used are the storage-specific ones. Each storage-specific model can use its own property files if it wants, but they are different ones in each platform.
I still have not looked into synchronization issues (I’ve still not even finished the storage ones).
A slightly different approach is the one I think has been followed in the Tamino Mobile Building Blocks API, the foundation of the Tamino Mobile Applications:
- The classes are nicely layered in “business logic” ones and in “data storage” ones, but there are no classes created inside the Studio, all of them are created in a external JAR file that is defined in the global project classpath.
I guess having the business logic classes created outside the Studio has no drawbacks and has the advantage of using a better IDE for them; however, by now I personally prefer to create them from inside.
However, I think the global JAR should contain only the business-logic classes, and not every other class, because a) you ensure you controller is multiplatform, and b) the global JAR gets fully deployed to every target.
- Synchronization is based, AFAIK, on XML streams. I do not think this is the best idea, since I think they are transporting XML character data on top of a binary stream of Java objects… if you have binary Java objects, I do not see the point on putting character data on top of it, that has to be parsed again into binary objects. Also this makes the thing to rely on the Xercer parser, which is yet another thing to install and run in the PDA; and also makes it more difficult (though possible) to synchronize with MIDP environments.
Other relevant points:
- The business logic depends on Java classes not available in MIDP (from java.lang.Serializable to org.w3c.dom), which AFAIK means that the business logic classes will not run on MIDP and that for having the Tamino Mobile Building Blocks API available on MIDP most of it will have to be rewritten.
- The selection of storage-specific classes is globally based on property files. I do not think that is good, because they are not specially well handled by Studio (you need to have several property sets), and because they are not available on MIDP.
Does anybody ave an opinion on all that? I’d like to talk about it. Thanks