Home > Delphi, JavaScript, nodeJS, Object Pascal, OP4JS, Smart Mobile Studio > Smart Mobile Studio, updates ohoy

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!

smart

Some of the more advanced demos include a full bytecode compiler written in Smart Mobile Studio. It may seem like overkill, but its a perfect example of just what Smart can deliver!

New team

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

The initial RTL was built side by side with the compiler. In the beginning we didnt even have classical functions like Assigned(), so the codebase had a lot of esoteric twists and asm sections that – as the compiler grew in complexity, became redundant and caused hard to track-down bugs. The compiler is now en-par with Delphi in many ways, although without generics; It represents a whole new dialect of pascal. Where Delphi is the absolute top-dog when it comes to Windows desktop applications – tailored from scratch to fit the Windows API, Smart Pascal was made for Javascript and to interact with the javascript virtual machine environment.

But the old structure, while it served us well in knocking out Cordova Phonegap based apps quickly — just had to be refactored at some point. Javascript is Async by nature and trying to “mimic” blocking execution was starting to impact performance, order and even being able to read and understand the code (for users coming from Delphi or Freepascal).

book

Smart Mobile Studio Unleashed will be released before xmas 2016, it explains in great detail everything you need to write controls, work with memory, write services and basically use Smart Mobile Studio to its full potential.

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.

New tech

While re-factoring  whole RTL is more than enough work, we also want to get new tech into Smart Mobile Studio. A unified filesystem has been long coming, and while we have units to access pretty much every nook and crumble Javascript has to offer — a high level interface that is unified is really where my focus is now.

Storing files on mobile devices, in the browser, node or embedded really should be the same. You should write code once and it should work no matter what namespace you target. I want to shield users from some of the Javascript solutions still out there. But people should always have the option to dig into the underlying API.

Databases

Then there is databases. This has really baked my noodle. As mentioned JavaScript is not linear. Its Async by nature, which means writing a concrete API that fits all has been problematic to say the least. But I am happy to say that the code I have implemented is finally rich enough to capture all of them.

grid

The long awaited DB grid. This one handles thousands of records very fast and uses CSS GPU scrolling and effects. As always its skinnable through the stylesheet

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

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.

Tweening

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.

scrolling

Momentum scrolling for listboxes and displays is now standard. In fact, the actual scroll code is isolated in components, so you can mix and match the scroll type you like.

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” 🙂

Advertisements
  1. August 30, 2016 at 1:29 pm

    Aren’t widgets usually visual by definition? seems like you have the ancestry backwards there.

    • Jon Lennart Aasenden
      August 30, 2016 at 1:35 pm

      Problem is that we used TW3Component early, and changing that now will be a complete code-breaking feature for everyone using SMS.
      But on linux at least, under GTK# widgets can be both visual and non-visual. But i agree, it was a poorly chosen name.
      Thankfully nothing is finalized yet, still time to do changes. This one is on the debate list.

  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: