Development notes

The setup of a Joty Workstation application Eclipse project

It is advisable to start working with the desktop / client-server running mode as target asset (to have this chance is the plus of the technology); anyway for sake of conciseness let's name this asset with the literal D/C-S mode as opposed to web mode.

The following are the steps to be carried on:

Desktop dbms based application : the conversion in the Joty technology - Considerations

This kind of application is the best candidate to the transformation.

Ideally no change is to be done on the database and all the efforts are forwarded to the analysis of the original code.

Assumed that no hard obstacle is encountered in discovering the management of the connection to the dbms, scenario that is encapsulated in the corresponding implementation of the basic class shown above, every visual object of the application that makes access to the database is the target of the analysis.

For each of such objects an inspecting in the class hierarchy of the Joty framework is advised, starting from the org.joty.workstation.gui.DataAccessDialog root class and going down along its descendants until the best fit is reached either about the layout or about the data management, obviously the perfect match is not searched but only a template that lets see pour effort for further development.

The same process advised for the internal data panels that compose the data dialog, here starting from the org.joty.workstation.gui.DataAccessPanel root class.

When the best templates are found respective classes must be derived: these extension will be the the implementation classes of the target visual object and they will be instantiated with the org.joty.workstation.gui.Factory methods.

Then in the original source code must be identified for each visual object that makes data access and for its internal components that do so,

In the target code, these two elements find there location in the following statements (for a simple scenario):

Then the development has to continue obviously with further analysis, from the identification of the keys for the DataAccessPanel implementations and for the org.joty.workstation.gui.Table instances (inner data grids), to the update-ability of the various database fields, from identification of the contexts of data look-up to the cross-referenced links needed among data dialogs and so on: this is only an introduction about the matter.

It is worthwhile here to note that the framework provides the context parameters infrastructure that allows to store values when easy to be caught and to retrieve them when they must be used in various expressions by letting the developer to reduce the traversing of the code for the procurement of the quantity of interest.

It is also to note that any visual data object (data panel or data grid) that wishes to publish its modifications have just to invoke the setAsPublisher method and any visual data object that wishes to be informed of a dialog publishing event, have just to invoke the subscribe method.

The conversion of a Joty application into Accessor mode

The Accessor mode is scoped either to the application object or to each data dialog object.

The Accessor mode at application object scope:

Because of these reasons, for the application scope the reader is redirected to the source code and related documentation. Here only the transformation of a Joty data dialog into one running in Accessor mode is described, as element constituting the entire conversion process.

Steps for preparing the Accessor class (the precondition)

Steps for setting an org.joty.workstation.gui.DataAccessDialog derived class to the Accessor mode

Steps for converting a data access made at application scope in one running in Accessor mode

Finally, not regarding the conversion process, it is to be noted that in order to get concrete advantage of the accessor mode, the binary of the MyAppAccessor class must be deployed to the server, in the same location where the jar of the Joty server is located. Then the framework must be informed about this location and this is done by setting the remoteAccessor configuration attribute.

As a conclusion it is evident that the conversion process is incremental and can be partial, indeed: only the data access of interest can be converted to the Accessor mode.

The setup of a Joty Mobile application project

Android studio 2.3.3 and later is recommended for the development of a Joty Mobile app.

Create a new Android Application project and in the build.gradle file of the application module add the following lines in the 'dependencies' clause:

compile 'org.joty:joty-mobile:2.0.4@aar' compile 'org.joty:joty-core-app:2.0.1' compile 'org.joty:joty-core-common:2.0.2' compile 'org.jsoup:jsoup:1.10.3'

Only if Jcenter doesn't exhibit availability of the above artifacts, add the row 'mavenCentral()' (or 'mavenLocal()' - see download page) to the repositories clauses of the build.gradle file of the project.

See OdontiorMobile1App sample for an example of Joty mobile app

The Joty Mobile app as stand alone project or as integration of a Joty Workstation application project

In Joty 2.0 it is typical that the mobile app is just an integration of something reacher that can be the workstation application, since Joty 2.0 Mobile has been developed with the handset devices in mind more than the tablet devices, but this does not deny the chance to developed a completely autonomous mobile project relying on Joty Server.

Either autonomous or integrator of a workstation application, the Joty Mobile app must be developed either basing on the remote accessor mode or not. In the positive case it requires, if not already existing for the workstation application, the existence of an implementation instance of the Accessor class, living/deployed on the Joty Server.

The Joty Mobile app development notes

The development process requires to implement a main activity as subclass of and to implement at least the following methods:

Then for each data entity to be managed the following gui elements must be developed:

The setup of a Dynamic Java project for an Application Joty Server instance

See the content of the project tree for the Odontior 2.0 sample application.