Smart Mobile Studio, updates ohoy
Its been a while since I’ve written much about Smart Mobile Studio. There are many reasons for this, but I figured I could write a bit now so people dont think we are standing still 🙂 So.. whats going on? Lets go through the highlights!
When you have a small team you can pivot on a dime. There are no board meetings, no finding dates that suits everyone, “vacation” is a foreign word – and you can pretty much jump on ideas and just implement them straight away.
But as software grows in size and complexity, that way of working can cause more challenges than solutions. You have to establish a proper company structure, plan ahead with care, delegate tasks and do chores you may not like.
Also, teams are people. And people change, take on new jobs and move. Without much drama that is the case for us as well — and while the core of the old team is still working on Smart, we had to establish a new team with more members (and board meetings and .. well, you know how it goes).
New RTL structure
Just think about it: We want to support mobile devices, nodejs client/server, embedded technology, Windows Universal apps and all the exciting gadgets that are coming out with pure JS interfaces. To pull that off you really need all your ducks in order and a clear separation between visual. non visual and hybrid systems must be in place.
We have solved this quite elegantly in my opinion, by the use of namespaces.
You have the system namespace which implements platform independent code (and abstract classes). Then you have the SmartCL visual framework that contains code that targets the DOM and browser. And finally you have the SmartNJ namespace that contains code adapted for NodeJS and headless frameworks. For embedded devices each will have their own namespace (like Arduino), all of them rooted in the platform independent system namespace.
This is an elegant way of solving how you approach the different platforms out there, it has less overhead than the “all in one” VCL type RTL we have fostered so far.
The downside is naturally, like C# coders live with every day, more units. But I have made sure that correlations match 1:1 as much as possible.
So where you find, for example, “system.filesystem.pas”, you will also find a corresponding “smartcl.filesystem.pas” and a “smartnj.filesystem.pas”. So once you know the units in the system namespace, its just a matter of replacing the prefix for the platform you target.
But a DB API is just the foundation. NodeJS has drivers for almost all native databases out there, like MSSQL, MariaDB, Oracle and even good old access for that matter. Implementing these under a unified framework takes time — which is also why we needed more people to join the group.
I have covered the most essential, the built in databases supported by the browser, sqlite and also TW3Dataset — this is more than enough for mobile and browser applications. But NodeJS is a whole other ballgame, and that has really been a challenge. Allthough a very rewarding one intellectually. But NodeJS is so massive that we have to build up over time, its impossible for such a small team to deliver high-level classes for all of them in such short time.
Actions is another factor I have really wanted for a long time. In Delphi and Lazarus this makes programming so much easier, faster and elegant. And writing a Smart version of this was not hard at all. So this is in place — we only need to adjust the property inspector and automatic codegen to take height for action objects.
The effect system in Smart is pretty cool. In fact its one of the most powerful CSS GPU based systems out there. No other system makes writing GPU powered effects so easy, yet its one of the least known aspects of Smart Mobile Studio.
The downside of effects that uses hardware, is that they have to run their course. Once started you cant really stop them, or abort the sequence mid-way. This is actually down to the browser, and even though its all defined in the WC3 standards – no browser really implements the stop feature.
To give users an alternative we have implemented a CPU only tweening system. This can be used to tween (morph is also a word used for this) anything from colors to moving elements. But as mentioned, CPU will always be slower than GPU. But with the tweening library in place, used for example in combination with Sprite3d — you have everything you need to write high-speed, silky smooth multimedia and control effects.
Components, not just controls
And yes, finally we have a pure separation between visual and non-visual components. Once established in the IDE you will be able to drag & drop non-visual controls, and we have debated the use of datamodules as well.
Since the VCL/LCL TComponent type inheritance chain is quite fat, we have avoided that. Non visual controls are called widgets, withe TW3Component now inheriting from TW3CustomWidget. This makes the inheritance chain linear – but allows you to safely write non visual components that are universal and dont collide with the namespaces scheme.
This is really cool! For instance listboxes now have a scrollmethod property where you can hook up a non-visual scroll mechanism. Momentum scroll? Row-by-Row scroll? Flat scroll? It makes it so much easier to hook things up.
Where to next?
There are a few company formalities left, but once those are in place we’ll get cracking! I personally cant wait to get going on the new IDE features. And with nodeJS becoming more and more relevant, both for embedded work and Smart devices – I think everyone will agree that it was worth the wait!
And as always — a long, long nose to those that said “it cant be done” 🙂