Wednesday, June 29, 2011

The challenges of HTML5

Ed Silverstein of the HTML5 Report published an interesting article yesterday about the benefits of HTML5 to developers. He mentioned Real Studio's new HTML5 features as well. It's great to see people outside of the Real Studio community recognizing Real Studio as alternative to traditional tools for building web applications.

Monday, June 27, 2011

The Future of PowerPC and Carbon Support

Next month, Apple will ship OS X Lion (10.7). In order for our engineers to be able to develop and test on Lion, we must upgrade to the latest version of Apple's development tools. The new version does not support PowerPC. Therefore we will have to drop PowerPC support entirely for Real Studio 2011 Release 4 due this Fall. Less than 5% of Mac users are still using PowerPC-based Macs and by the time we ship R4 it will have been five years since Apple switched to the x86 Intel processor. I know for some of you this will cause some grief but you can still use 2011 Release 3 and earlier builds to support PowerPC.

As you know, we are moving our Mac framework from Carbon to Cocoa. Real Studio 2011 R2 includes greatly improved support for Cocoa. Many users are telling us they can ship their apps built with our current Cocoa-based framework. We believe that our Cocoa support will be complete enough to no longer be considered beta starting with Real Studio 2011 R4. At that time, Carbon will be deprecated. That means we will not be fixing any Carbon-specific bugs except for the most egregious. We will continue to support Carbon as a build option until we ship a release of Real Studio that includes a LLVM-based compiler as the default build option. In that release, Carbon will no longer be available as a build option.

Transitions are not always easy, but sometimes they are necessary in order for us to move forward. I know that for some of you these transitions will cause some grief but I think you can see that they are necessary if we are to keep making Real Studio better.

Friday, June 24, 2011

Key events of web browser KeyEvents

One area of Web Edition which has been confusing to our users has been the data that is returned from a user's browser with the two keyboard events — KeyDown and KeyUp. In Real Studio 2011r2, we've changed some things around to make the data more consistent from browser to browser and simpler to implement.

First of all, instead of two events, there is now only one, KeyPressed. This event fires after a key has been pressed and the Details parameter now includes several more pieces of information:
  • 4 Booleans that indicate the state of the different meta keys — AltKey, CtrlKey, MetaKey and ShiftKey.
  • Character contains the character that the user typed, assuming the key that was pressed has a glyph associated with it.
  • CharCode contains the ascii character code associated with the key.
  • KeyCode contains the keyboard code associated with the key (note: this may be different than CharCode, but not always). 28 KeyCode Constants to help you figure out which non-character key has been pressed.
Note: Some browsers even include the key names in the Character property. For instance, if you pressed the down arrow key, Character might be set to "Down". Don't rely on this functionality, it's not consistent from browser to browser.

Tuesday, June 21, 2011

Real Studio 2011 Release 2 has arrived!

Real Studio 2011 Release 2 is available for download today.  Here is a quick video demonstrating some of the key new features in this release.

With new HTML5 features like WebSockets, GeoLocation and WebMoviePlayer, as well as JSON support, Real Studio 2011r2 gives you the essential tools to communicate with online services like Google, Flickr and Twitter.  The new release contains 42 new features and 184 improvements, you can read the full release notes here.

Monday, June 20, 2011

JSON: A New Kid on the Block

With Web Edition coming along and more and more feature requests coming in, one of the essentials to making external services work was to add JSON support (http://www.json.org). This nifty protocol written by Douglas Crockford is a way to represent objects as a string so they can be transmitted across the internet. As it turned out, interfacing with Google's Geocoding engine was the perfect opportunity to add JSON to the upcoming Real Studio 2011 Release 2.

Building on an open-source library from Charcoal Design, we created a new class named JSONItem. For those of you that don't already know, JSON objects can either contain named items (like a dictionary) or indexed items (like an array). To make these objects a little easier to create, we've added methods so you can manipulate them either way. Values can be Strings, Numbers, Booleans, Nil or another JSONItem.

For instance:

//Like a Dictionary
Dim Person as new JSONItem
Person.Value("Name") = "John Doe"
Person.Value("Married") = True
Person.Value("Age") = 35
Person.Value("Spouse") = "Jane Doe"

//Like an array
Dim Kids as new JSONItem
Kids.Append "James"
Kids.Append "Julie"
Kids.Append "Joe"
Kids.Append "Jessica"

//Add the Kids JSONItem to the parent JSONItem
Person.Value("Kids") = Kids

//Create a JSON string from the defined object
Dim JSONString as String = Person.ToString()

JSONString = {"Name":"John Doe","Married":true,"Age":35,"Spouse":"Jane Doe","Kids":["James","Julie","Joe","Jessica"]}

In addition to creating JSON Strings, JSONItem can parse them. Once loaded, you can walk through the object as if you were traversing a folderitem tree. Using the example above:

Person = new JSONItem(JSONString) //From the example above
Dim MyKids as JSONItem = Person.Child("Kids")
For i As Integer = 0 to MyKids.Count-1
MsgBox MyKids.Value(i)
Next i

Services that you can communicate with using JSON include Google, WordPress, Twitter, YouTube and Flickr.

Thursday, June 16, 2011

Avoid the "default" language

Avoid the "default" language, at least as far as the language a project is built in.
Why should you avoid "default"?

When you compile a project "default" means "whatever language the current user is running in". On some OSes this is not a problem as you only have one available language. But on something like OS X where it's dead easy to switch between English, French, or any other installed language, it can be horribly confusing.

You might work in English and your partner might work in French, for example.

Now when you compile the "default" language for dynamic constants it's considered to be English, and when your partner compiles it's considered to be French. What this means is that depending on who builds the project, you or your French partner may be surprised by the results.

Ideally, if a user has their preferences set to list German, French or English, then that user would see the application in French. And if someone else has them set to German, English, French they'd see it in English.

So far so good.

But now when you edit the "default" value for a constant what language do you write them in?
If you write in English and your partner writes in French, you'll have problems. Our first German example above will see some default values in French and some in English and so will the second. Why?

It works this way because "default" is ambiguous for each developer. For the English developer it's English and for the French developer it's French. So which is it for the entire project? The answer is that "it depends".

When "default" is the selected language the created plist for the application requires an entry for the "development region" - what the OS should consider the "default language". And since the project is set to "default" the value used has to be derived from somewhere - and that is the language that the OS is currently using.

You can avoid this in one of two ways.
  1. always explicitly set the language that a project is built in (see Build Settings > Language)
  2. always put in values for each localization in the listing for each localized constant
Ideally you should do both.

Thursday, June 9, 2011

No more Mac?

Since 1984, the operating system for the Mac has always begun with the "Mac" prefix. First it was Mac OS and later, Mac OS X. Apple has been very consistent about that. They never called is "OS 9" or "OS X". Apple always used the "Mac" prefix. But if you look at Apple's page for the next version of the Mac operating system, for the first time, that's no longer the case. Lion is called "OS X Lion" all over their website.

Why? I think Apple is trying to transition to a single brand for their mobile and desktop operating systems. Certainly, many of the features in Lion were inspired by features in iOS. And it would make sense for Apple to want their users have a common user experience between their iPhone, iPad and iMac or MacBook. Steve Jobs said that the Mac and PC have been "demoted" by iCloud to being "just another device." Apple is not content for the desktop to be the digital hub because the desktop digital hub is not always available. The cloud is, so by keeping all of your devices in sync via iCloud, they make it easier for you to own more devices. At least, they make it easier to own more Apple devices. And that only makes sense because Apple is a hardware company.

So the rebranding of Mac OS X to simply OS X is Apple's first step towards a single name for their two operating systems. One day you will see all the devices they sell as being so similar in user experience that there will be few barriers to stop you from buying more of them. And that's the point, removing the barriers that prevent prospects from becoming customers.

What do you think? Why would Apple remove the "Mac" prefix from Mac OS X?

On a related note, in this blog post, Bob Cringely stated that the iCloud's real purpose is to kill Windows. iCloud might indeed be the final missing ingredient that makes the iPad a realistic option for Windows users looking to replace their current PC. After all, when considering a new Windows PC versus an iPad, price is no longer an issue. However, I don't think Apple spends time thinking about killing Windows. I think Apple spends its time thinking about creating great products. Anything else that happens is nothing more than a byproduct of that thinking.

This all may make me sound like an Apple fanboy. I'm certainly a fan of theirs. However, I'm a fan because they have consistently made great products. There are plenty of companies for which I'm a fan for the same reason.

Monday, June 6, 2011

Pushing Pixels

At some point, many of us end up writing routines that will make changes to a picture. You might need to rotate the image, change the color scheme, etc. You can use the Graphics.Pixel property but Real Studio offers another, faster way: the RGBSurface class. This class has a Pixel method that works just like Graphics.Pixel, but RGBSurface is significantly faster than using Graphics.Pixel! In my test, RGBSurface averaged 14 times faster on the Mac and about 70 times faster on Windows. That means of course that Graphics.Pixel is pretty slow on Windows since RGBSurface on the Mac and on Windows are roughly the same.

You can change pixels using the RGBSurface class using almost identical code to what you'd write when using Graphics.Pixel. For example, my test code simply copies an entire picture pixel by pixel.

Here's the code using Graphics.Pixel:

dim copy as new Picture(beach.width, beach.height, 32)
dim beachGraphics as Graphics = beach.Graphics
dim copyGraphics as Graphics = copy.Graphics
dim lastX as Integer = g.Width - 1
dim lastY as Integer = g.Height - 1
for x as Integer = 0 to lastX
for y = 0 to lastY
copyGraphics.Pixel(x, y) = beachGraphics.pixel(x, y)
next
next

And here's the same code using the RGBSurface class:

dim copy as new Picture(beach.width, beach.height, 32)
dim sr as RGBSurface = beach.RGBSurface
dim cr as RGBSurface = copy.RGBSurface
dim lastX as Integer = beach.Width - 1
dim lastY as Integer = beach.Height - 1
for x as Integer = 0 to lastX
for y as Integer = 0 to lastY
cr.Pixel(x, y) = sr.pixel(x, y)
next
next

The only big difference is that you just need to get an RGBSurface object for the source and the destination and then copy pixels between them.

So when you need to do pixel-level changes, make sure you are using RGBSurface!

EDIT: Charles Yeomans found an optimization for both examples. It didn't speed up the first example but it made a big difference for the RGBSurface example making it even faster.

Wednesday, June 1, 2011

Hello World: An update on LLVM

When learning programming, the most common first program one writes is "Hello World" which basically just displays that message. It's a small but significant milestone to be able to produce this simple message. When we were working on adding support for Windows to Real Studio, it was exciting to see "Hello World" on Windows 98! We experienced the same excitement during the development of support for Mac OS X, Linux and the web.

We reached a similar milestone today with our work to replace the backend of our compiler with LLVM. First, a quick summary of how our compiler works and how LLVM will be an important part of the future of our compiler:


When your choose Run or Build in Real Studio, all of the code you wrote is passed to the Real Studio compiler which is represented by the items in grey in this diagram. The front end is the part of the compiler that understands the Realbasic syntax. It converts your code to a sort of meta-assembly language. That meta-code is then passed to the compiler backend which turns it into x86 assembler which your computer can understand. All this compiled code is then passed to the linker which puts it all together and produces the actual application you can distribute. Of course all of this is hidden behind the scenes but it's helpful (or at least mildly interesting) to understand how it works.

We have written two different backends for the compiler: one that produces x86 assembler and the other that produces PowerPC assembler. The latter is no longer supported since Apple has stopped making Macs using PowerPC processors.

LLVM is an open-source compiler backend that has a lot of advantages over the ones we have written:
  1. It's an optimizing compiler which means it can make your code run faster.
  2. It does dead-code stripping which means it can leave out the parts of the Realbasic framework that your project isn't using resulting in a smaller application.
  3. It may enable us to return to a single-file executable on Windows.
  4. It supports the ARM processor used in mobile devices such as iPhone/iPad.
Last year we took the first step of making RBScript compile with LLVM. The next step is to replace it for building entire applications. We have spent a bit of time on this next step recently. Today we were able to compile and run a "Hello World" console app and a desktop app as well. This is a significant milestone but it's only the first of many.

There is still a lot of work to do before you will be building your projects with LLVM but reaching this important "Hello World" milestone is an important one.

EDIT: For the sake of clarity, it's possible that some issue might prevent us from achieving single-file executables for Windows. So I have changed "will" to "may" in item #3 above. Also, I have removed mention of Android from item #4 because LLVM doesn't help (or hinder) us when it comes to supporting Android.