Primoz Gabrijelcic have published a steady stream of examples since we released Smart Mobile Studio to the test group. This time he has coded a very nice app that demonstrates using the accelerometer and getting the orientation vectors of your iPhone or iPad.
You can find the acceleration demo here. Also make sure you checkout Primoz website for interesting articles, advanced code and knockout components
Spaceballs
In this little tutorial we are going to take a trip back in time, back to the golden age of personal computing. A time when the ultimate computer was the Commodore Amiga and the latest kid on the block was wire-frame 3d graphics and polygon art. I am of course talking about the 1990’s and the glowing polygon effect.
Continue reading
When interacting with ordinary javascript libraries or a remote webservice you natually have to go native with your datastructures. Under Smart this can be handled in a variety of ways but the two most common approaches are to either use a record or a variant.
Records in Smart work just like they do in other object pascal environments. And since Smart compiles to javascript rather than machine opcodes, a record will always compile to an ordinary javascript structure. I should note that javascript really doesnt distinguish between what we would call a record and objects. In javascript everything is an object.
So the following object pascal code:
[sourcecode language=”delphi”]
type TMyInfo = Record
miName: String;
miAge: Integer;
miGender: integer;
End;
[/sourcecode]
Results in the following predictable javascript code:
[sourcecode language=”javascript”]
{
miName: "",
miAge: 0,
miGender: 0
}
[/sourcecode]
This means that when you want to interact with native javascript libraries that expects a structure of values, you can use records to match it directly.
Using variants to achieve the same thing is perhaps easier, especially since you dont have to predefine the structure by hand. As of writing however it does require you to initialize the variant manually. We will probably add some RTL functions to simplify this very soon, but for now you can use this “one liner” ASM snippet:
[sourcecode language=”delphi”]
Procedure testvariant;
var
mData: variant;
Begin
asm @mData = {}; end; // Set variant to "empty JS object"
mData.miName:=’john doe’;
mData.miAge:=39;
mData.miGender:=1;
end;
[/sourcecode]
The resulting javascript structure will be exactly the same as that produced by the record. One difference to keep in mind though, is that the compiler will output the names “as is”. There is no way for Smart to map the content of a native object so make sure you get the names right.
Pascal Game Developer has a nice article about Smart Mobile Studio. Visit their website and have a look: http://www.pascalgamedevelopment.com/
I have to come up with some names for the different technologies soon. Smart now have two terms for compiler and also two levels of RTL: the low level RTL that is a part of Eric’s compiler, and a high level RTL which is our “VCL” clone. Im thinking of naming our component library the VJL (visual javascript library), and instead of refering to the compiler infrastructure as “the compiler”, it is more fitting to call it “the build tool”.
As the test group knows, the build-tool takes your source-code, invoked the compiler and finally glues everything together into a final, solid HTML5 document. Since our system was originally designed for iOS development only, and since Smart components (including forms, which is our version of pages in a way) are purely javascript based – a fully operational “app” really only needs one HTML file.
In Alpha 2 i removed the injection of code directly into the document.body section and introduced “Application.Display.View” to the VJL. The reason for this was make the application regard “the screen” abstractly. So by altering what “display.view” points to – you can make your apps live inside any DIV you wish.
A couple of testers have reported back that it could be handy to separate the RTL from the program code. There are a number of scenarios where you might, for example, want to run multiple Smart apps on the same document. If you run a website and want to get rid of Flash for instance, it would be nice to code the new banner in Smart and also host a game or a cool menu written in Smart as well.
Having talked it over with Eric it became clear that this should be reasonable to achieve, but it will come at a price: namely that it defeats the latest compiler switch named “smart linking”. When you smart link your apps, only the code you have used is included in the final binary (in our case “binary” is javascript). It’s the same technique Delphi and C++ uses to make programs as small as possible.
So if we include the feature then it will disable the smart linking option. I am experimenting with this now, by dumping the entire RTL into a separate file. If it doesn’t produce any negative side effects (except a small speed penalty and some bloat) then I’ll include it as an option. Eric might slap me over the head for playing around with this – but it would (in my view) complete the parallel of “Delphi” for javascript.
One of my long term goals is to add a new project type to Smart for writing libraries. Which would be the javascript incarnation of DLL’s. Since we have our own IDE we could generate a class-map for the library – which you could then import later so the Smart IDE can keep track of what the libraries export. A bit like a Windows TLB file when working with COM objects.
We should be able to poll this off by isolating the compiled code in it’s own name-space. It would then have it’s own RTL and library – but due to the nature of Javascript, it should actually work 🙂 It would mean a little tweak to the RTL but we are constantly tweaking anyhow.
Why are libraries important? Components, that’s why. By pre-compiling and obfuscating your code – you could write and sell your own components. The other benefits are self evident I think.
Before we started developing Smart Mobile Studio we did a survey of the alternatives for developing mobile apps. That’s actually where the initial idea and motivation came from. During this survey we must have tested at least 14 different “app” machines, languages and “rapid” development environments. We tested the serious players like C++, object pascal, C# and Java – to the outright scams which usually include the phrase “create your app in a day” (but the app you get is just a template with no real value what so ever).
The result of our survey was disappointing to say the least. At the time, using Free-pascal to work with iOS was a bit of a black art so while that was our initial choice – any substantial information regarding cross compilation was virtually non existent, so we decided to go for C# in developing our iOS apps. This involved learning a new language, a new platform and to some extent a whole new way of thinking.
But one thing we did notice was that Javascript had come a long way. While all the native systems were struggling to get aboard the iOS and Android bandwagon – javascript was all over the place. Doing things it’s not supposed to do in classical terms. Everything from silky smooth animations to action packed platform games.
Javascript can now do amazing things
To make a long story short we continued working in C# and object pascal, but as the idea behind cross compilation and using javascript as a medium began to grow, we found ourselves seeking out like-minded people, putting our ideas to the test. Unlike the “app machines” however, we did it properly from the ground up.
So the question is not if javascript works. The question is how to use that power properly.
When we took the time to look at javascript with new eyes, three things became apparent. First, browsers are not just page readers anymore but rather fully fledged multimedia environments. Secondly, Javascript has grown and can make use of the browser in a whole new way. And last but not least: javascript’s lack of structure is both it’s strength and it’s downfall.
Take something simple like a visual component. When you dig into the complexities of this simple task it turns out it’s not that simple after all. As of writing there exist no single standard between the different javascript frameworks on the marked. It is also highly unlikely that it ever will – because it’s not financially beneficial for these companies to work together. They would lose their uniqueness if they did, not to mention the technical difficulties getting two javascript frameworks talking to each other. When you use a framework you stick to it, mixing two different systems could in theory work – but in real life it quickly becomes a mess.
Classic remake of capcom streetfighter using gameQuery JS framework
Encapsulation and portability of source is also an issue, not in terms of browser compatibility – but in terms of programmers sharing solutions. There are several ways a javascript developer can create the same thing – and the lack of a common approach (which classical languages solve by syntax, classes and a common foundation like the VCL) makes it extremely time consuming.
After we created a small demo/game in Javascript, testing out ideas and playing around with the multimedia features, it became crystal clear that it simply takes to much time to hand-craft large projects in javascript. You can use one of the many ready-made frameworks out there, but the amount of source code you need to write for a large game or application is ridicules.
The alternative is not to ignore javascript, but rather to use javascript as a medium. What we did with Smart Mobile Studio was to transform a disadvantage into an asset. Javascript is the proverbial “wax that takes many forms”. We projected the rigid and time proven structure of object pascal onto the “everything goes” landscape of javascript. The end result is that you can now use the power of object pascal, it’s encapsulation, it’s class hierarchy, it’s true object inheritance and (thanks to our super clever compiler guru Eric Grange) even fancy concepts like interfaces, closures and var parameters. So not only do you get the power of javascript – you also gain the wisdom and experience of more than 18 years of pascal evolution (not to mention the object pascal community which is a living genius factory).
With a few hundred lines of pascal code you can achieve what it would require thousands – if not tens of thousands lines of javascript to match. But the central strength of pascal is that of scope and size. A large object pascal code-base can be maintained due to the architecture of the language. The same project in “native” javascript terms would be nearly impossible to keep track of. The time and cost involved in developing and maintaining a 200.000 lines long javascript project cannot be justified when you can achieve the same with 20.000 lines of pascal. Object pascal was designed to handle large projects. Javascript was not.
So. Are you tired of spending days hand-crafting javascript that could be delivered in hours?