Wednesday, September 29, 2010

Upgrades and Renewals and Updates and Bears, Oh my!

With the recent introduction of the upcoming REAL Studio Web Edition I've received a lot of questions about how to upgrade/update/renew existing license keys. I want to clarify how REAL uses the terms Renewal, Upgrade and Update.

Renewal - A 12 month Renewal gives you access to the current REAL Studio release and all releases for the following 12 months. You can Renew any "Modern" REALbasic/REAL Studio license key anytime, before or after its expiration date. Pre-2005 license keys must be Upgraded to the "Modern" edition before they can be Renewed.

Upgrade - You can Upgrade any existing REAL Studio license key to any edition up the line. For example, you can Upgrade your Personal license key to Professional or Upgrade your Professional license key to Enterprise. You can even Upgrade your Personal license key to an Enterprise license key, it will always save you money to Upgrade an existing license key. Upgrading a license key adds 6 months to the existing expiration date.

Update - You can "update" your license key by purchasing a Renewal. This will give you access to the current REAL Studio Release and all releases for the following 12 months.

Bears - We don't sell bears.

Your REAL Studio license key belongs to you and you are never required to Renew or Upgrade. I hope this answered your questions about REAL Studio license keys and subscription plans. We try and keep it simple here. Have you seen the REAL Studio License Terms? You can read the whole thing in under 5 minutes!

Remember, if you are developing professional applications it will always benefit you to keep your license key current. REAL Studio code maintenance should be an ongoing process not a quantum leap!

As always, if you have any questions about Upgrades, Renewals or REAL Studio please email Customer Service.

Tuesday, September 28, 2010

Where on the web does your app run?

There has been a lot of discussion about our upcoming Web Edition on our beta list which is really great. One thing that some people seem to not be clear about is exactly where your code executes. Allow me to explain.

For those of you that haven't look into our Web Edition, you build web applications in a way that is pretty much identical to how you build a desktop application. You drag and drop, you double-click and create your application logic using the same language you use for the desktop. The difference is where code executes. In a desktop application, all code is executing on your computer as an application. For web applications, your application is on a server so it executes there and sends all the necessary stuff behind the scenes to the user's browser to provide them with your UI so they can use your application.

So from your perspective as the developer, you will develop basically the way you always have using REAL Studio. From the end user's perspective, the app will act very similar to how a desktop app works. Think of a page as a window and it's all the same. We handle the rest of the magic to make it work like that. If that's all you needed to know, stop reading here. If you want more nitty-gritty details, read on.

Let's take a simple app with a single page, a textfield and a button. The button is coded to set the Text property of the Textfield to "Hello World!". You created the app by dragging a Textfield and a Button onto a page. You added TextField1.text="Hello World!" to the Action event of the Button. You built the app and installed it on a server. That's everything you had to do. Now what happens when a user comes along?

When the user enters the appropriate URL to get to your app, our framework (inside your app) goes to work. It turns your page into HTML, CSS and JavaScript on the fly and sends it to the user's browser. The user can type all they want in the TextField, resize the window, etc., but that will not matter because the only thing your app cares about is the Button's Action event. Any other event that occurs will not create any communication with your app on the server because you didn't implement any other event. When the user clicks the button, the JavaScript that was generated to react to that event fires and sends a message to the your app on the server. Your app executes the Action event. And since this updates the TextField, the HTML and CSS needed to update the page are generated by the web framework and sent to the browser where the browser shows the updated page. This all happens really fast. And for each page a user has open, there is an equivalent object in memory on the server that represents that page. This allows us to save the state of that page as the user moves from one page to the next (even though the browser is only showing one page at at time to the user).

The thing that does not happen is any kind of translation of your code into JavaScript. Your code executes on the server and it's fast because unlike most web technologies, your code is compiled to machine code rather than interpreted at runtime.

Over time, we will add more ways to automatically generate JavaScript that takes care of more things in the browser to make communication between the browser and your app more and more efficient. And you will be abstracted from these details so you can focus on what makes your application unique.

If you still have questions, fire away.

Update on Cocoa

There has been a lot of excitement around our announcement regarding the new Web Edition and it's made some people wonder what is going on with Cocoa. So let me give you an update on that.

First of all, Cocoa progress is not in any way affected by our Web Edition. Different engineers have different sets of skills so we can't productively put engineers working on the Web Edition to work on the Cocoa framework. It would be great to have that kind of flexibility but it's not realistic.

For REAL Studio 2010 R4, there are over 30 bug fixes related to Cocoa specifically and a few new features as well. But we are not just fixing bugs. We are also refactoring code to make it more efficient and easier for us to maintain so that there will be fewer bugs in the future.

At this point, all Cocoa work now has shifted to R5 which will likely ship in early December. By that time, we believe the Cocoa framework will be in good enough shape that you should be able to run your apps under Cocoa with some bugs but your apps may not be shippable. For 2011 R1, most applications should run with few if any bugs and be shippable to your end users. The IDE itself will be in a similar shape. For R5 we will have it running but buggy and for R1 it should be shippable.

The journey from Carbon to Cocoa has been a long one but we are seeing the light at the end of the tunnel.

Thursday, September 23, 2010

Porting a desktop app to the web

With the ability to build web applications coming to REAL Studio soon, I'm sure many of you are thinking about creating a web version of some of your desktop projects. Whether you are going to continue to have both a desktop and a web version and wish to share code between them, or you plan to move your project entirely to the web, there are some changes you may have to make to do so.

Primarily, these changes are in three areas: communication with user interface controls, reporting and graphics.

Communicating with User Interface Controls
Although the user interface controls in our web framework are for the most part very close to their desktop equivalents, they don't share any code with those desktop equivalents. As a result, they are not the same classes under the hood so you can't have code that directly talks to both a desktop pushbutton and a web button. So the first thing you have to do (if you haven't done this already) is separate this code from the UI.

I have started porting a desktop project to the web recently. The project is a very fancy calculator of sorts. The user fills in 10 or so fields, chooses some options and the app calculates the advantages of doing one thing instead of another. The window is filled with methods, each of which is essentially a formula. Anytime the user changes a value in a field, a bunch of these methods run and update StaticText controls that show the results. Since these methods can be directly accessing controls (even via parameters unless I only pass in values), I have to change the way the methods get their data.

To port this to the web, I created a class (which I called "scenario" since one set of data and results is a scenario in this case). I moved all the methods to that class and then created properties for each of the fields on the window. I added a property to the window that holds a reference to a Scenario object and I create that object in the open event of the window. The fields now just update the properties and the methods use those properties rather than the fields themselves. Once I was sure that worked and produced the same results as before, I made the class an external file so I could share it with the web project.

Once I had made this change, I imported the Scenario class into my web project and added code to the controls on the page to update the same properties. So if you have your code and UI closely tied together (as I did), you will need to separate them first. You can do that today in preparation for building your web version. Incidentally, this kind of separation is just good design as well. And by using the class as an external item in both the desktop and web projects, I can fix or enhance the code in this class from either project.

If your desktop project prints, then you'll need to take a different approach for the web. Printing for a desktop project means drawing into a graphics object or using the Report Editor. Using a graphics object isn't a great solution for the web because you can't send it right to the printer. You would have to display it on a page. Sending page-sized graphics over the internet is not a great idea regardless of what tool you use to build your web app. And the Report Editor is not supported for web applications right now. The best solution is to create a page which you lay out for printing. Then you just fill in values, most likely into labels (the statictext control of the web framework) and present the page to the user. They can then print the page directly from their browser.

There's not much in the way of overhead when it comes to using graphics in a desktop application. In a web app however, the varying speeds of the Internet between your app and the user's browser, will impact the responsiveness of your app so you need to be thinking about how to optimize when it comes to sending large amounts of data from the app to the browser. Large pictures will be time-consuming. You can make them smaller by using JPEGs. But if possible try to avoid using pictures. There are other ways, in some (certainly not all) cases, to use controls such as rectangles combined with styles to create graphics that are smaller and can be cached automatically by the browser. For example, to create a monthly calendar, use rectangles and labels rather than drawing the whole thing in a big picture.

In summary, there are some things you can do now to start preparing your desktop project to become a web project. There are also things you can start thinking about in terms of how you will approach printing and graphics in your web application. It's going to take some trial and error to find the techniques that make the most sense for you.

Saturday, September 11, 2010

The stigma of BASIC

Back in 1998, we chose the name "REALbasic" for two reasons. First, it would suggest that this might be similar to Visual Basic and second, it suggested that the language would be easy to learn and use. But over the years we discovered that some people would make a lot of assumptions about the language because it included the word "basic" in it. The biggest assumption has been that it must be BASIC as in the language invented at Dartmouth College in the 1960's. Nothing could be further from the truth.

The original BASIC was procedural, under-powered and interpreted. BASIC is an acronym that means Beginners All-Purpose Symbolic Instruction Code. It was designed primarily to teach people programming and not to write large applications.

The language of REAL Studio, REALbasic, is as object-oriented as Java, very powerful and compiled. If you doubt this, consider that REALbasic is strongly-typed and supports inheritance, interfaces, polymorphism, operator overloading, introspection, delegates, RTTI (runtime type information), exceptions and the list goes on. And if you're new to programming, you can ignore almost all of this until you are ready. That's what makes REALbasic approachable. There are only a few keywords (such as Dim, Left, Right and Mid) that REALbasic and the original BASIC share in common. But they they do share one important thing in common. The goal of both languages is to make it easier to learn and write code. In BASIC as in REALbasic, there's one line of code per line. No need to remember to end each line with a semi-colon and no creating crazy lines of code that can't be read. Such as this in C:

v(c,j ,K){ char*P=E[c][j];
The point is to focus your attention on solving the problem and to avoid getting distracted by the semantics of the language itself. REALbasic, as a language, is every bit as powerful and object-oriented as C#, Objective-C, Java or C++. But it was designed to be much more approachable than these languages especially when combined with the REAL Studio IDE. I've had many users tell me that they tried for a long time to get a friend or co-worker to look at REALbasic but they wouldn't because of the word "basic" in the name. But in all cases, when they finally agreed to look at it, they found they really, really liked it. They were converted.
Now you could say that I'm just making an argument for changing the name or perhaps ust dropping the word "basic". Perhaps we just called the language "RB". PHP for example, is an acronym but it no longer means that anymore. It's just PHP. This is a discussion for another blog post.
So the next time you meet someone that looks down on REALbasic because of the word "basic", tell them that it's a misnomer and that REALbasic is a very powerful, object-oriented language that compiles to machine code and shares only the few good parts of the original BASIC. Convince them that they really should look deeper. You'll be doing them a favor. And you'll be doing the community a favor by growing it by yet another member.

Thursday, September 9, 2010

iOS Development in REAL Studio

Today Apple announced that they have loosened the restrictions on the iOS Developer Program License Agreement. I think "loosened" is an understatement. They have removed all restrictions that would prohibit us from bringing iOS support to REAL Studio. Apple said that they have been listening to developers and as a result, have made changes that allow for third party tools but at the same time, allow Apple to keep the level of security they need.

Apple really does listen to developers. We have been having discussions about iOS support with Apple for some time now. Based on today's announcement, it's clear they really have been listening to us and others.

iOS support is the number one feature request in Feedback, our bug and feature request tracking system. But it's not just number one. It's way number one. We calculate a score for each case and the score for iOS support is almost 3 times (300%) higher than that of the case in the number two spot. Whereas the case in the number two spot is only 10% higher than number 3. So we hear you loud and clear regarding iOS.

iOS devices (as well as most other mobile devices) use an ARM processor. Before we can support iOS, we need to have an ARM backend for our compiler. And as many of you already know, we are in the process of moving the backend of our compiler to LLVM (the same compiler that Apple is moving to) and LLVM has ARM support. In fact, the ability for us to support mobile devices was a significant factor in the decision to move to LLVM. RBScript now compiles using LLVM. The next step is to get applications compiling with it. That is no small step but it's also not as big as it might first seem. Getting RBScript working was the biggest step and that's done. We still have a lot of work to do but we are certainly over the hump.

What does all this mean? Well, I'm not here today to announce iOS support. But I can say that the path has now been cleared of any obstacles that might stand in our way.

Thank you Apple, for listening to us and other developers and finding a solution that provides the security you need while giving us the option to support iOS in REAL Studio.

Friday, September 3, 2010

REAL Studio Web Edition App on iOS

Check out the latest sneak peek of REAL Studio Web Edition to see an unaltered Web Edition application running on the iPhone and iPad.

Wednesday, September 1, 2010

REAL Studio Web Edition Beta Program

A lot of people have been asking me about getting into the REAL Studio Beta Program. It's easy to join - just log into your account on the website and go to Beta Program, or visit You must have a current REAL Studio key to join the program, and you can join with any edition of REAL Studio.

Additionally, we have set up a forum for REAL Studio Web Edition. Bring your questions, share your excitement (we are!) or just talk about what kind of web apps you want to start on!

Don't forget to tell your friends about REAL Studio Web Edition. Tweet it! Facebook it! Digg it! Help get the word out there! If any of you are writing articles or blog posts about REAL Studio Web Edition please let me know so I can link to you and help you with promotion.