I started writing a simple app the other day that will parse an entire pocket query file from geocaching.com… eventually it will bloom out and be a full-featured geocaching application.
Coming from the realm of java web development, I am used to having good tools that automate all the mundane parts of the process. In many cases, most of the data persistence layer of an app is fairly routine… Once you know what the fields in your data objects look like, the rest of the layer is basically spelled out for you… If you have a bean that stores a bunch of strings, you will have a table that stores a bunch of strings… etc.
If you wanted to write out your data structure in shorthand to give to another programmer who would work on that layer for you, you could easily write it out like this:
Entity Person {
String FirstName
String LastName
Date birthdate
@VitalStats vitalStats
Service PersonService {
set getPersonByFirstName(String firstName) throws PersonNotFoundException
set findPerson (firstName, lastName)
}
}
ValueObject VitalStats {
Float weight
int heightInInches
int waistSize
...
}
From that basic description of the data layer, another programmer could easily create for you code that would handle your model and give you an easy iterface to work with it. What is even nicer, however, is that the other programmer doesn’t have to be a human – a properly written tool can take that simple description and also write all the code for you.
One project I have worked with before is Fornax Sculptor – (the domain-specific language in my example is strongly based on sculptor’s DSL) – they in turn build on top of Open ArchitectureWare and integrate their generation solution within the popular java build-tool Maven.
To build a code generation tool to simplify the model layer of an android app would not be too tough. Here is what I was thinking it could provide relatively easily:
- Generate the db adapter, along with the necessary create statements
- Generate simple
beans to transfer data - Generate a basic service layer that the rest of the application talks to to get / save data
If anyone has any other thoughts on what kind of things are basically just braindead work once the data model is defined, let me know.
