Always when you least need it
Yes, I know. This month was meant to be a very active time for OP4JS but sadly Norwegian weather brings with it complications like colds and the flu. So in short i have spent nearly 3 weeks off the grid with nothing but fevers, allergies and sneezing. So to those of you eagerly awaiting the Alpha release of OP4JS I am sad to inform you that we might have to push the date forward to make up for lost time.
Be that as it may my health is finally picking up after the onslaught of germs, viruses and weather up here – so for the past week I have been eagerly working on the object model, in this case: TApplication.
Much like under Objective C (which is the official language you use to create iOS applications, although you can now use alternatives) TApplication is the root controller object. It is in charge of creating a visible screen, kick-starting your application code, which in turn creates forms and register them, which is ultimately injected into the viewport. The viewport (or visible area) being a child object of TScreen – the place where forms do their thing.
Why go to so much trouble you ask? Well, it has to do with several aspects of HTML5 but first and foremost it deals with clipping and scrolling. You want your forms to slide in without problems under any webkit based browser (be it Safari Mobile or Chrome for Android). Secondly, we are trying to avoid having different TApplication models for each of our project types. We are currently aiming for 3 project types:
- Graphical application (“form” based”)
- Console application (for test purposes)
- Game application
The nested layout made visible
TApplication have to be dynamic enough to suit all 3 variations – and we also want to safeguard ourselves for the future where more project types come into play (libraries being on top of the list).
It also have to manage the forms you add to your application correctly, which means taking care of transitions, pre-positioning forms prior to movement and many more details. But thankfully we found a solution that is simple, elegant and robust. And no external dependency either. We might even drop jQuery soon because quite frankly: we dont need it.
On your right is view of how we organize things. The white color is from the actual HTML5 document, the red color is TScreen – which in turn has a child TCustomControl called viewport (green).
The benefits of this layout is that you can (if you want to) add a global header directly to the TScreen object. So instead of each form descending from TW3HeaderForm (which as the TW3Header control built into it) you can just create one header for the whole app. Of-course this means that your forms have to change the title and deal with the back and next buttons directly – but that’s just as easy as it would be in ordinary Delphi.
The second benefit is more or less the same, except for the footer. Many native apps have main view controller that introduces a fixed header and footer, typically containing a tab-bar at the bottom and a toolbar on top. We want to support this because it solves a lot of problems (and also makes you apps faster. The less objects the faster it runs, that’s how it works in Delphi as well).
Well — I better get back to work!