Home > Amibian.js, CSS, Delphi, JavaScript, Object Pascal, OP4JS, Smart Mobile Studio > Smart Mobile Studio: Q&A about v3.0 and beyond

Smart Mobile Studio: Q&A about v3.0 and beyond

A couple of days back I posted a sneak-peek of our upcoming Smart Mobile Studio 3.0 web desktop framework; as a consequence my Facebook messenger app has practically exploded with questions.

smart_desktop

The desktop client / server framework is an example of what you can do in Smart

As you can imagine, the questions people ask are often very similar; so similar in fact that I will answer the hottest topics here. Hopefully that will make it easier for everyone.

If you have further questions then either ask them on our product forums or the Delphi Developer group on Facebook.

 

Generics

Yes indeed we have generics running in the labs. We havent set a date on when we will merge the new compiler-core, but it’s not going to happen until (at the earliest) v3.4. So it’s very much a part of Smart’s future but we have a couple of steps left on our time-line for v3.0 through v3.4.

RTTI access

RTTI is actually in the current version, but sadly there is a bug there that causes the code generator to throw a fit. The fix for this depends on a lot of the sub-strata in the new compiler-core, so it will be available when generics is available.

Associative arrays

This is ready and waiting in the new core, so it will appear together with generics and RTTI.

Databases

We have supported databases since day 1, but the challenge with JavaScript is that there are no “standards” like we are used to from established systems like Delphi or Lazarus.

Under the browser we support WebSQL and our own TW3Dataset. We also compiled SQLite from native C to JavaScript so we can provide a fast, lightweight SQL engine for the browser regardless of what the W3C might do (WebSQL has been deprecated but will be around for many years still).

Server side it’s a whole different ballgame. There you have drivers (or modules) for every possible database you can think of, even Firebird. But each module is implemented as the authors see fit. This is where our Database framework comes in, sets a standard, and we then inherit out classes and implement the engines we want.

This framework and standard is being written now, but it wont be introduced until v3.1 and v3.2. In the meantime you have sqlite both server-side and client-side, WebSQL and TW3Dataset.

Attributes

This question is often asked separately from RTTI, but it’s ultimately an essential part of what RTTI delivers.

So same answer: it will arrive with the new compiler-core / infrastructure.

Server-side scripting

22555292_1630289757034374_6911478701417326545_n

The new theme system in action

While we do see how this could be useful, it requires a substantial body of work to make a reality. Not only would we have to implement the whole “system” namespace from scratch since JavaScript would not be present, but we would also have to introduce a a secondary namespace; one that would be incompatible with the whole RTL at a fundamental level. Instead of going down this route we opted for Node.js where creating the server itself is the norm.

 

If we ever add server-side scripting it would be JavaScript support under node.js by compiling the V8 engine from C to asm.js. But right now our focus is not on server-side-scripting, but on cloud building-blocks.

Bytecode compilation

I implemented the assembler and runtime for our bytecode system (LDef) this winter / early spring; So we actually have the means to create a pure bytecode compiler and runtime.

But this is not a priority for us at this time. Smart Mobile Studio was made for JavaScript and while it would be cool to compile Delphi sourcecode to portable bytecodes, such a project would require not just a couple of namespaces – but a complete rewrite of the RTL. The assembler source-code and parser can be found in the “Next Generation Demos” folder (Smart Mobile Studio 3.0 demos). Feel free to build on the codebase if you fancy creating your own language;Get creative and enjoy! **Note: Using the assembler in your own projects requires a valid Smart Mobile license.

Native Apps

It’s interesting that people still ask this, since its one of our central advantages. We already generate native apps via the Phonegap post-processor.

phonegap

Phonegap turns your JS apps into native apps

Phonegap takes your compiled Smart (visual projects only) compiled code, processes it, and spits out native apps for every mobile OS on the market (and more). So you don’t have to compile especially for iOS, Android, Tizen or FireOS — Phonegap generates one for each system you need, ready for AppStore.

So we have native covered by proxy. And with millions of users Phonegap is not going anywhere.

Release date

We are going over the last beta as I type this, and Smart Mobile Studio 3.0 should be available next week. Which day is not easy to say, but at least before next weekend if all goes accoring to plan.

Make sure you visit www.smartmobilestudio.com and buy your license!

  1. July 1, 2018 at 11:55 pm

    About the RTTI bug.
    I remember in the past, SMS1.2 everything “RTTI” was working as expected, but something has changed at 2.0 codebase, and there was a minor issue when you execute/run the RTTI project you’ve got that terrible ghost black screen. I have posted a solution, however, I’ve got no feedback from smart team. Please consider to read this post:
    https://forums.smartmobilestudio.com/topic/4506-rtti-metadata-only-for-some-classes/?tab=comments#comment-22364

    https://github.com/smartpascal/smartms/blob/master/games/RTTI/uRTTI.pas

    example:
    https://raw.githack.com/smartpascal/smartms/master/games/RTTI/www/index.html

    regards,
    warleyalex

    • July 17, 2018 at 3:59 pm

      Yes there was a bug introduced when our compiler guy changed the way values were handled inside the codegen. When the time comes to update the back-end this will go away. We havent focused on it because we have been busy building up the infrastructure — but we are coming close to the point where rtti is very much needed, especially attributes and property walkers for easy protocol generation

  2. sglienke
    July 2, 2018 at 5:49 pm

    Is that new compiler still based on DWS and will these new features end up in DWS or is this a change to a proprietary compiler?

    • July 17, 2018 at 3:54 pm

      We have our own fork of DWS that was developed by eric and the team a while back. We have a toolbox around the AST that is not in the official DWScript repository. I do hope that we ar some point can converge because eric is doing a lot of cool stuff, and i know dwscript users could benefit greatly from our special libraries — but this is a long and sensitive issue that involves both investors and owners and contributors so it’s really not up to me. Being able to transform pascal to js is only a small part of the equation. I used to think that was the bomb, but having spent years on the infrastructure needed around that I realize that every part of the system has an important role. Smart is ultimately the RTL, IDE, importer mechanisms and hundreds of layers of code that makes up the infrastructure. We only use dwscript to generate the AST and then we have a specially licensed codegen on top of that.
      But I do hope we can converge at some point yes.

  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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: