Tuesday, December 20, 2011

What got you interested in programming?

When I was a kid, I would race home after school to watch M*A*S*H reruns on TV. One of my older brothers watched Star Trek reruns so I would sit through Star Trek waiting for M*A*S*H to start. It didn't take long before I became a Star Trek fan. Star Trek provided me with a view of the future. In that future all things were better. No one was poor, getting around was easy and just about any sickness seemed curable all in a 60 minute episode. Computers were an important element in Star Trek so for me, they became a way to touch the future.

I grew up near the University of California at Irvine. I would ride my bike there and hang out in the computer science lab. I bought punch cards, put them in a punch card machine and typed on them. I had no idea how to write programming code. I just mimicked what I saw others doing. I was probably 13 at the time and why no one chased me out of there still surprises me to this day.

My father spent his career as an electrical engineer mostly creating communications equipment for the military. One day he brought home a Texas Instruments portable terminal. It had no screen, just acoustic couplers that held the telephone handset for communication with the VAX mainframe at his work. A thermal printer was the only output device and of course when we would run out of the special thermal paper, that was a problem. My dad taught me to program in the original BASIC and we played the original text adventure game (called "Adventure") as well.

When the Apple II came along I wanted one but being in high school at the time, I certainly couldn't afford it. My dad was unwilling to pay extra for the Apple brand so instead purchased a Franklin ACE 1000, which was an Apple II Clone. The Franklin's motherboard failed several times, and I'll bet my dad ended up paying far more for it than he would have paid for an Apple II to begin with!  He bought me a book that taught Applesoft BASIC and 6502 assembler. One look at the pages about assembler and I knew right away that I was going to stick with BASIC.

Programming for me became a terrific outlet where I could create anything I could imagine. That's what got me interested in programming.

What got you interested in programming? Share your story.

Monday, December 12, 2011

How to create a Dylib on Mac OS X and create declares in Realbasic to use it.

This tutorial explains how to use Xcode to create a dylib, and then use Realbasic to declare into it. Dylib is short for Dynamic Library, which is a file that contains code that can be linked against at runtime. This means that it isn't built directly into your application, like a static library is, but you can still load it up and call methods in it.

This is mainly useful for C/C++ or Objective-C programmers to create a library that may do something not possible from Realbasic.

Creating the dylib

  1. Launch Xcode
    This tutorial assumes that you are using Xcode 3.1.4 from Apple.
  2. Choose "File->New Project", or type Command-Shift-N.
  3. Select BSD Dynamic Library, and click "Choose".
  4. Choose a project name. For this example, we'll call it "SampleDylib".
  5. Choose "File->New File..."
  6. Choose "C File", from within the "Mac OS" section
  7. Name the file. For this example, we'll call it "SampleDylib.c". The default settings are generally correct, but if you have multiple projects open with multiple targets, make sure the proper project and target is selected. When done, click "Finish".
  8. Open the SampleDylib.c source file.
  9. Add the code below:
    #include <string.h>
    int addFunction( int a, int b ) {
     return a + b;
    int stringLength( char *str ) {
     return strlen(str);
  10. Save the file, then click the Build button, or press Command-B.
  11. If there were build errors, ensure that the code you entered looks exactly like it does above. Once the build is successful, continue to step 12.
  12. Find where the build was saved. If the builds folder location hasn't been changed, it will be located in a "build" folder, next to your project file. It will be named libSampleDylib.dylib. (This is bceuase we've not altered the default install name in the build target.)
    Another way to locate the file is to locate the target by going to the project window, expanding libSampleDylib, then expanding Products. Select libSampleDylib.dylib, and control-click (or right-click, for those with two-button mice), and choose Reveal in Finder
    You will need to access this location later.

Creating the Realbasic project

  1. Launch Real Studio. Create a new project, and choose "Desktop"
  2. Save the project to your Documents folder (so that it is next to the dylib file). For this example, we'll name it, "Test Dylib.rb"
  3. Double click on "App" in the project window.
  4. Expand the "Events" section, and select "Open"
  5. Add the code below:
    CONST dylibLocation = "@executable_path/../Frameworks/libSampleDylib.dylib"
    Declare Function addFunction lib dylibLocation (a as integer, b as Integer) as Integer
    Declare Function stringLength lib dylibLocation (s as CString) as Integer
    msgBox "5 + 2 = " + str(AddFunction(5,2))
    msgBox "The length of ""asdf"" is " + str(stringLength("asdf"))
  6. Run your application using the "Run Paused" feature of the IDE.
  7. Copy the dylib from the Xcode build into the application bundle. You can do this by right clicking on the debug app & selecting "Show Package Contents".
    Navigate to Contents > Mac OS & copy the dynamic library created by Xcode into the Frameworks directory in the bundle. (If the edition of Real Studio you use supports this you could use a Build Automation Step to do this for you on every compile)
  8. Now launch the debug application by double clicking it in the Finder. It should then connect to the debugger in the IDE.
  9. Notice that it correctly adds, and also correctly computes the length of the string.

What is it doing?

The loader (aka Dynamic Linker) doesn't search for a dynamic library very well. It relies on either having a full path to the library, or having it relative to the executable path. Since we want the dylib to be installed in the bundle, we use "@executable_path/../Frameworks/libSampleDylib.dylib" as the path for non-debug builds. This means that when you build your application you will need to copy the SampleDylib.dylib file into your Contents/Frameworks directory next to your actual executable file.
However, since the application is regenerated every time Realbasic builds it, the same path won't work for debug builds. (Suggestions about how to deal with this are included later)

What about the native types in Realbasic?

Using Realbasic, you can do almost anything through declares. Here are a few tips on how to handle different types in Realbasic:

  • Passing a float into your dylib, or returning a float: In Realbasic, use "Single" as the data type. Singles are the exact same as a float -- a single precision floating point, to be specific.
  • Passing a double into your dylib, or returning a double: Doubles are the exact same in both languages.
  • Passing a c-string (null-terminated string) into your dylib: In Realbasic, declare the type for the parameter as CString.
  • Passing a pascal-string (one byte length specifier) into your dylib: In Realbasic declare the type for the parameter as PString.
  • Passing a void* (arbitrary data) into your dylib, or returning it: In Realbasic, declare the type for the parameter as Ptr, and pass in a MemoryBlock. Also declare the return type as Ptr, and it will automatically be converted to a MemoryBlock on return.
  • Passing a pointer to a struct into your dylib: The same as above. Set up the memoryblock to contain the different fields, and pass it in as a Ptr.
  • Limitation: It isn't currently possible to pass in a struct inline.

Known issues

  • By default all symbols (functions & subroutines in C) are exported. This is usually what you want.
    If you happen to preface one with the C keyword "static" then it won't be exported & so it will not be usable directly in Real Studio code like we've shown.
  • If you name your file with a ".cpp" extension then Xcode assumes that it is a C++ file & names will get mangled by the Xcode compiler. This means they would not be directly usable in Real Studio.
    You will need to preface them with an "extern "C"" declaration to make sure the names get exported unmangled.
Because Real Studio recompiles your application every time you run it under the debugger you can't use the same path for the dylib while debugging as you can in the final build. You can deal with this by using an absolute path to the dylib when debugging. In my case this would be:

CONST dylibLocation = "/Users/npalardy/Documents/libSampleDylib.dylib"

Another way to deal with this is to put the dylib next to the application bundle where Real Studio builds the application (right next to the project file on OS X). Then you can use a relative path like:

CONST dylibLocation = "@executable_path/../../../libSampleDylib.dylib"

And you could make the code in your Real Studio project look like:

#if debugBuild
   CONST dylibLocation = "@executable_path/../../../libSampleDylib.dylib" // next to the app bundle
   CONST dylibLocation = "@executable_path/../Frameworks/libSampleDylib.dylib" // inside the app frameworks in the bundle

Declare Function addFunction lib dylibLocation (a as integer, b as Integer) as Integer
Declare Function stringLength lib dylibLocation (s as CString) as Integer

Document Updated by:
Norman Palardy norman@realsoftware.com
Real Software, Inc.
based on a previous article by Jonathan Johnson
Real Software, Inc.

Friday, December 9, 2011

Search Engine Indexing of Web Edition Apps

We've been getting some questions about how the search engines treat Web Edition apps and what, if anything, you can do about it.

First of all, it's worth noting that most search engine "bots" do not support Javascript. This means that neither the Web Edition framework nor the initial WebPage of your app will ever be delivered. You can't even use a Javascript command to redirect to another page.

In fact, there are some good arguments for why you wouldn't want a search engine to index your application content. Think of a membership list, or a company calendar or an email client. Having that content indexed by a search engine could be catastrophic, and probably part of the reason that most search engines don't index dynamic content like that, unless specifically told to do so.

We're investigating ways to make this a little easier to do, but there is something you can do about this now... META Tags. There are two HTML header tags that you can add that help a search engine to figure out what your site/app is all about. They are:
  • Description: A brief description of that your page or product is about. It is not uncommon for search engines to display this text as is when showing a listing for your page.
  • Keywords: A list of key words and phrases under which a search engine should index your page.
To use these tags, add code that looks like this to the app.HTMLHeader property in the IDE:

<meta name="description" content="My software is the greatest piece of software ever made" />

<meta name="keywords" content="best software, greatest software, awesome software, most-likeable software" />

Wednesday, December 7, 2011

How much is too much?

This week, Microsoft provided more information about the app marketplace being built into Windows 8. They are doing some things differently than Apple which is a good because healthy competition is always a good thing for consumers.

In one of the videos, Microsoft Web Services VP Antoine Leblond says that prices for apps can be between $1.49 and $999.99. He went on to say that "a thousand bucks is too much for an app." Who exactly is he to say how much is too much for an app? Microsoft's store currently sells two editions of Visual Studio for over $1000 each. Will these not be offered in the app marketplace? 

The price a developer charges for their product should not be dictated by any online store. That's a decision the developer should make.

Static Variables in Web Edition

Static variables can be a valuable thing, but there is a downside that you should be aware of when using them in Web Edition.

The Real Studio documentation for Static says:

"A variable declared with the Static statement and assigned a value retains its value from one invocation of the method to the next." (Click Here)

Static variables persist across subclasses as well, so if you have a method in a class that uses a Static variable, all of the subclasses will share that variable's value.

So what's so special about Real Studio Web Edition? Well, each end-user session is technically a subclass of the individual Webpages and other items you created in the IDE. Using Static variables may have unintended results.

For example: If you use a variable as Static in the WebPage1.Resized() event like this:

Event Resized()
  //Initialize the Static Variables
  Static LastWidth as Integer = Self.Width
  Static LastHeight as Integer = Self.Height
  //Show a message if the window got smaller
  If Self.Width < LastWidth and Self.Height < LastHeight then
    MsgBox "The browser window just got smaller!"
  End If
  //Update the Static Variables
  LastWidth = Self.Width
  LastHeight = Self.Height
End Event

This will work fine as long as there's only one Session (like if you're testing in debug mode). Once there's more than one, they will all share the LastWidth and LastHeight properties and every time a one user's browser window is resized, LastWidth and LastHeight will be updated for all connected users.

Here's what happens: If User1 makes their browser smaller and gets the MsgBox and then User2 makes their browser window smaller they will only get the MsgBox if the window is smaller than that of User1. Whichever user resized last, the dimensions of their browser is what is left in LastWidth and LastHeight.

While this could lead to a hard to track down bug, imagine what would happen if you used a Static variable for a Password!

To avoid this problem, you should use properties of the class you are using (in this case WebPage1.LastWidth) or as a property of the Session itself.

When writing code for Web Edition, always remember that all of the Sessions are technically running the same exact program. Properties on Modules and the App class, Shared Class Properties and Static Variables will all be available to all Sessions.

Tuesday, December 6, 2011

Linux & Cairo

In Real Studio 2011 Release 4 we upgraded our Graphics drawing on Linux to use Cairo instead of the antiquated GDK drawing system. For those unfamiliar with Linux, Cairo is akin to GDI+ on Windows, or CoreGraphics on OS X.

The main benefits to switching to Cairo include: smoother drawing because of anti-aliasing, translucency support and hardware accelerated drawing. See figure below for a comparison of Cairo drawing (top) and GDK drawing (bottom)

Another important reason for switching to Cairo is because 2011 Release 4 introduces alpha channel support for Pictures. This would have been excruciatingly painful to do in GDK (and GDI on Windows for that matter), so the upgrade to Cairo was a necessity.

An additional gain from this upgrade is improved printing support on Linux. Although we resolved the issue with only being able to print at 72 DPI in a previous release, the fact that we created an offscreen picture and scaled the text was a show stopper for many. Now that our printing API uses Cairo and our Graphics drawing is also using Cairo, this transitory picture we had to keep around before is essentially out of the picture now, pardon the pun.

Friday, December 2, 2011

The demise of HyperCard

John Gruber, the blogger behind Daring Fireball, has a podcast called The Talk Show. Right at the end of this week's episode, he and his co-host Dan Benjamin discussed the demise of HyperCard.

If you're not a Mac user or are too young to remember it, let me give you a little background. HyperCard was a simple development tool provided with the Mac prior to Mac OS X. It had a drag and drop interface builder and a simple programming language similar to AppleScript. I saw the appeal of an English-like programming language but also quickly discovered the concept's Achilles' heal. In English, you can say the same thing many different ways. In HyperTalk (the programming language of HyperCard) there was usually just one way to write the code for a particular function. AppleScript suffers from this same problem which can make it quite frustrating at times. One of our engineers once called AppleScript "a read-only language" which is a great description. It's easy to read AppleScript code, but very frustrating to write. HyperCard also suffered in that it did not support color and could not be used to build standalone applications. If you sent a HyperCard file (called a "stack") to another person, they needed to have HyperCard installed to run it.

Despite these limitations, there was an attractive simplicity to HyperCard.

So, despite its simplicity and popularity why did HyperCard die? On the show, the hosts suggested that Steve Jobs killed it. One of the things that Jobs did when he returned to Apple was simplify. He very correctly and intuitively understood that Apple needed to focus on a smaller number of projects if they were going to produce great stuff. Also, one of the features of NeXT that Jobs was most proud of was its advanced (at the time) visual development tools and object-oriented language. He believed (correctly as it turned out) that object-oriented programming was the future. So if you consider how important Jobs felt it was to focus and how he felt about the development tools brought to Apple with the acquisition of NeXT, it's easy to see how Jobs would feel that two development tools was one too many.

But I think the real reason is far simpler. Bill Atkinson was the main developer behind HyperCard. He left Apple in 1990. Without Atkinson pushing HyperCard, it was quickly abandoned inside of Apple. There were probably few who knew the code or who had anything like the passion that Atkinson had for it. As a result, updates were released with decreasing frequency and in 2004 Apple finally killed it.

In their podcast, John Gruber and Dan Benjamin discussed what development tools exist today that fill HyperCard's void. I was quite happy to hear John mention Realbasic. It won't shock you to hear that I think Realbasic/Real Studio fills this gap nicely. One of the big problems John felt HyperCard had was that it couldn't build stand alone apps. Even if it could, Hypercard didn't use native controls so the apps would not have felt like true, native applications. Real Studio of course builds native apps and uses over 40 native interface controls.

It has always been my vision for Real Studio to be an easy-to-learn and easy-to-use development tool that is powerful enough to build almost any kind of app while supporting all the important platforms. The only platform Real Studio is missing at this point is mobile and that's something we are working towards. It's just never made sense to me that a developer should have to learn lots of different languages and development tools to build different types of applications. 

HyperCard was one of the first visual, integrated development tools. That was a significant innovation. While HyperCard and Real Studio are very different in many ways, they have the same goal: to make programming accessible. I think that Real Studio has done a good job of taking over where HyperCard left off. 

Wednesday, November 30, 2011

Embossing Effects On-The-Fly

Embossing is an effect used to give an object the appearance of being sunk into or raised above a background. They are very easy to create in Photoshop, but today I'm going to show you how you can start with nothing but a shape and build the effect in code. This has the advantage of allowing you to adjust the effect on-they-fly based on parameters you choose.

We've done exactly this in our new IDE. In fact, I've been given permission to show a very small glimpse of the tray area of our new layout editor. The same object in our current IDE is on the left, the new version is on the right.

That version on the right is produced in code, starting only with an 8-bit mask to describe the shape:

The embossing effect is created using 3 layers. The bottom layer is the drop shadow, the middle layer is the fill, and the top layer is the inner shadow. I created this simple animation to demonstrate how the individual layers build together to create the effect:

Now, let's get to some actual code. First, you need an image to use as the shape. This image should have no color, only shades of grey. The background can be either white or translucent. We first need to create a method used to draw this shape at any color. For simplicity's sake, we'll call this method IconAtColor:

Private Function IconAtColor(Icon As Picture, Fill As Color) As Picture
  Dim P As New Picture(Icon.Width,Icon.Height,32)
  P.Graphics.ForeColor = Fill
  Return P
End Function

Next, the actual embossing. We'll start with the bottom layer, the drop shadow. In our effect, the drop shadow will be used to create a bottom-edge highlight. So we're going to create a picture and fill its contents with white. Purists will argue that a new picture starts white, and they'd be right, but I like to be explicit. By filling it with white, there is no doubt you have a white picture. Next, we're going to clear the mask. A mask defaults to filled black, but we want the opposite, so a simple ClearRect call will handle that. Into the mask, we're going to draw the icon twice. First, we're going to draw the icon using some shade of grey between black (opaque) and white (transparent). This creates the opacity of the shadow. In the example code, we're going to use 75% white (25% opaque, &cBFBFBF). The shadow must be drawn 1 pixel from the top. Then we draw the icon a second time at 100% white (&cFFFFFF) at 0 pixels from the top. This "cuts" the shadow away from where we will actually fill. We do this because the fill may be translucent, and we don't want the shadow to show through. Here's the code to what we just did:

Dim DropShadow As New Picture(Icon.Width,Icon.Height,32)
DropShadow.Graphics.ForeColor = &cFFFFFF

Now we're going to create the fill layer. Because we want the fill to darken the background, we're going to fill a new picture with black, and once again, clear the mask. Then all we have to do is draw the icon into the mask, again at some color between black and white to describe the opacity. In our example, the fill will be 50% opaque (&c7F7F7F):

Dim Fill As New Picture(Icon.Width,Icon.Height,32)
Fill.Graphics.ForeColor = &c000000

And of course, the final layer is the inner shadow. Like the fill, we want this layer to darken, so we fill a new picture with black, and like the other two layers, we clear the mask. Like the drop shadow, we need to draw the icon twice. Once for the opacity, and once to "cut" the shape away. In this example, the shadow is 75% opaque (&c7F7F7F). This time, the first drawing should be 0 pixels from the top, and the second drawing should be 1 pixel from the top.

Dim InnerShadow As New Picture(Icon.Width,Icon.Height,32)
InnerShadow.Graphics.ForeColor = &c000000

And there we have it, the three layers needed to create the effect. Draw them all directly on top of each other, starting with the drop shadow, then the fill, and finishing with the inner shadow. You can adjust some of the numbers, such as the distances from the top to draw the icon on the drop shadow and inner shadow layers, and choose different colors to create different opacities. Your fill color does not need to be black. You can reverse the inner and drop shadows to create a raised effect. Experiment with this code to achieve new effects.

A sample project can be downloaded here which includes the artwork and code ready to run.

Tuesday, November 15, 2011

More than an Introduction to Programming

Last week Peter Wayner wrote a nice piece in the New York Times titled "Programming for Children, Minus the Cryptic Syntax". Anything that gets kids interested in programming is a good thing and the article discusses a few software products designed specifically to teach kids programing logic in a fun and intuitive way. 

Real Studio would have a made a great addition to this list. Though most of the software tools Wayner mentions are great for introducing programming to kids, they can't realistically be used for much more than that. On the other hand, Real Studio can be used to introduce programming to kids without limiting what they can do to simplistic programming. Real Studio is really accessible to children and is already used in many schools around the world to teach programming. 

Many people feel that you have to choose between something being easy and intuitive or difficult and powerful. I think that choice is a copout- you can have it both ways, though it may require more design and thought to achieve. We add features that make Real Studio easier and we add features that make it more powerful. We work to make it intuitive for those learning programming for the first time and at the same time, make it powerful for experienced developers.

You can have it both ways if you take the time to design your products with this in mind and the result can be a far superior product, one that students would be lucky to get their hands on early.

Thursday, November 10, 2011

The Winner: HTML5

Developers have tried for years to deliver applications with desktop-like features and quality through a web browser. In the early days HTML was simply not up to the task. The original solution was to use Java to run an app inside the browser but that, unsurprisingly, resulted in a horrible user experience. Later Flash appeared. Flash provided a much higher quality experience because the Flash browser plugin could do just about anything in terms of the user interface while still providing the benefit of deploying the app through a browser. Java and Flash are similar in concept but one was developed by a company that primarily made servers while the other was developed by a company that exclusively made desktop software. It's not a shock that Flash has a better user experience.

But Flash is not without downsides. First, the user has to have the Flash plugin installed. Second, the plugin has to load some or all of the application from the server to the user's browser. This often results in the user waiting through an annoying loading progress thermometer. Flash also crashes too often. Over the years, some people have told me that they don't install Flash because their entire system becomes unstable if they do. In addition, Flash and similar technologies like Microsoft's Silverlight are not efficient on mobile devices which are sensitive to battery life. Apple famously chose to not support Flash on iOS because it was felt that Flash was just not efficient enough.

Here at Real Software, long before there was an iPhone, we considered giving Real Studio users the ability to build applications that could be deployed in a browser via a special plugin we would develop. After much consideration, we decided not to pursue this for many reasons- one of which being we believe that depending on an installed plugin greatly reduces the value of the technology.

Later, AJAX and HTML5 came along making it more possible to build desktop-like applications for the web. This made Adobe Flash and Microsoft Sliverlight less necessary and provided an excellent solution for power-sipping mobile devices. At Real Software, when we decided to investigate building web applications again, the native web technology had caught up with what we wanted to accomplish allowing us to develop our web framework for Real Studio. Real Studio Web Edition has never relied on plugins and instead creates native HTML/HTML5, CSS, JavaScript, etc., on the fly and sends it to the browser.

Now Adobe has announced that it's discontinuing the Flash plugin for mobile devices. It also appears that Microsoft may be putting Silverlight out to pasture as well. Adobe is going to refocus on HTML5. If Microsoft is going to end development of Sliverlight, perhaps they plan to do the same. This will likely be the beginning of the end for Flash as a plugin for desktop browsers as well. If Flash is going to support HTML5 for mobile, where all relevant browsers support HTML5, it's only a matter of time before the majority of desktop users are using an HTML5-compatible browser. At that point, it would not make sense for Adobe to continue to support a Flash browser plugin at all.

HTML5 has won this fight but it's not a total win for users. Flash is a complete end-to-end solution developed by one company. That allowed Adobe to provide a very consistent user experience. HTML5 (along with CSS, JavaScript, etc.,) is a standard that is then interpreted by the developers of Internet Explorer, Firefox, Chrome and Safari. That's a lot of different people and the result is that these native technologies don't work exactly the same on all browsers, creating extra work for web application developers that have to test and tweak their web apps for each browser. Adobe will have to deal with these inconsistencies.

The Real Studio web framework already abstracts the developer from these browser differences and from the assembly language of the web (HTML, CSS, JavaScript, AJAX and PHP/Java) as well. This is what web development technologies need to do to make web application development efficient for and accessible to everyone.

What we are seeing today with this announcement from Adobe and the rumors about Silverlight is technological equivalent of survival of the fittest and this time the winner is HTML5.

Thursday, October 27, 2011

Safely connecting to a MySQL Database

You can connect to a MySQL database in a Real Studio web or desktop application using the MySQLCommunityServer class. If you have built a web application you need to consider SQL injection which is a way for someone to get data out of your database that you didn't want them to have or change data that you didn't want changed. The goal is to make sure that user input (such as SQL commands or delimiters) doesn't contain anything to manipulate a database in an unwanted way.

So, before you upload your web app, take a look at using prepared statements to protect your data. Although it uses the Real SQL Database there is example code for this in the Order example project. You can download that project from the about box in the Orders example.

Here's some example code from the Real Studio Language Reference:

// We'll assume "db" is the MySQL Database object added to your project
Dim stmt As MySQLPreparedStatement
stmt = MySQLPreparedStatement(db.Prepare("SELECT * FROM Persons WHERE Name = ? AND Age >= ?"))
stmt.Bind(0, "John")
stmt.BindType(0, MySQLPreparedStatement.MYSQL_TYPE_STRING)
stmt.Bind(1, 20)
stmt.BindType(1, MySQLPreparedStatement.MYSQL_TYPE_SHORT)

Dim rs As RecordSet = stmt.SQLSelect

Monday, October 17, 2011

Siri: The killer app for the iPhone 4S

I freely admit that I'm a gadget guy. I often buy new technology when it's first available and I'll admit that has not always worked out. I remember having several "Newton moments" waiting for the Apple Newton to attempt to turn my chicken-scratch handwriting into text. It routinely misunderstood- often to the delight of whomever was watching my demonstration.
Whenever I want to buy a new gadget, the first step is rationalization. How can I rationalize spending the money on this thing? Well, I don't have any other expensive habits. I don't play golf or gamble. But the real rationalization for buying the new iPhone 4S was my kids. The 8 megapixel camera can shoot 1080p HD video with image stabilization. After all, I can't go back in time and reshoot today’s pictures with a higher quality camera tomorrow. Basically 100% of the photos and video I take of my kids (heck, of anything) are taken with my iPhone; after all they say the best camera in the world is the one you have with you! So I convinced myself (and my wife since we make purchasing decision above $100 together) that the better camera alone was worth it. And it really is.
But there's another new feature of the iPhone 4S called Siri that I was interested in. For those of you that have somehow managed to still not have heard about Siri, it's a built-in personal assistant that recognizes your voice and can take actions for you. But as much as I attempted to rationalize Siri as a reason to buy the new iPhone 4S, somewhere in the deep recesses of my mind, I couldn't help but think it was going to be more cool than practical. That was, until I tried it.
Siri can be activated simply by holding your iPhone 4S up to your ear as if you are about to make a call. The very first thing I asked Siri to do was "Tell my wife I'm thinking about her." That is word for word what I said. Siri then sent my wife a text message that read “I’m thinking about her”. Apparently, I should have said, "Tell my wife I'm thinking about you" so that the text message would have been "I'm thinking about you", but that's close enough for me. Next, I asked Siri to call my mom. Siri asked, "What is your mother's name?" and I replied, "JoAnn". "Is your mother JoAnn Perlman?", asked Siri. "Yes", I replied. Siri then asked, "Do you want me to remember that JoAnn Perlman is your mother?" and again I replied, "Yes". Siri then told me it was calling my mom and the call went through. Pretty cool.
Testing Siri further I asked, "What is the capital of Texas?" Siri responded with a document that had several details about Texas including the fact that the capital is Austin, Texas. On my way home from lunch, I heard a text message come in. I put my iPhone to my ear and asked Siri to read my last message. It read it and asked me if I'd like to reply. I told it what I wanted my reply to say and Siri sent it. Next, I asked it what time my marketing meeting was today. It looked at my calendar and responded correctly. I asked it what I had on my calendar for tomorrow. It read my tasks. I even composed an email message and sent it while driving, though I'm not sure how you tell it which email account to use.
This is pretty amazing and useful technology and I'm sure Apple will take this much, much further. Siri seems to be the killer feature of the new iPhone 4S. Someone pointed out to me that technology like this has existed for Android for sometime. Well, in fact Siri has existed for iPhone for some time as well. What Apple did in iOS5 is buy it and deeply integrate it. But it’s interesting that I had never heard of it until now for either platform. Everyone is talking about Siri now but I don’t remember anyone ever mentioning it before for either platform.
For an app or feature to be considered “killer” to me, it must be very useful but I also have to know about it. It does no good for a great product or feature to exist if no one ever hears about it.

Wednesday, October 5, 2011

So long, Steve.

When I heard this evening about the death of Steve Jobs, I immediately thought about the huge influence he has had on my life over the last 30 years.

I started learning programming on an Apple II. Actually it was a clone because my dad wouldn't "pay extra for a brand." He paid dearly when we replaced the motherboard three times.

I earned my first computer, a Macintosh 512K, doing custom programming for my brother's company.

I made my living working at an Apple dealer and later writing custom Mac software until I went to work for a Mac development tools company in Silicon Valley. In 1994 I left for Austin, Texas where I founded Real Software because there were no good rapid application development tools for the Mac. 

My kids have been growing up watching Pixar movies. And when I saw the trailer for Finding Nemo, I knew Pixar was something special so I bought Pixar stock and held it until they were bought by Disney.

I watched Steve Jobs bring Apple back from the brink to amazing success. Apple is certainly the greatest corporate turn around in history. From the iMac to the iPod, to the iPhone and the iPad, he has left his mark on the world of technology.

Steve Jobs truly was a visionary. He was often way ahead of his time and never allowed the limits of what others thought possible to stop him. He was a relentless taskmaster (based on what the people I know that worked for him) but that was just what came with the package.

What I learned from Steve Jobs was to not be afraid to dream big, to be passionate about what you do for a living and to never accept "just good enough."

I had never really realized until tonight that my entire adult life has been so impacted by the vision of Steve Jobs. This might make me sound like an Apple fanboy, but really, I'm just a fan of great products that enable people to do things they couldn't have done without them. Steve Jobs was always great at making great things.

Whether you liked him or hated him, he was a genius. Only a fool would deny that.

But now he's gone, far too early and the world is diminished.

So long, Steve. We'll miss you.

Real Studio, Cocoa and LLVM

Our new Cocoa-based framework for Mac OS X made some big leaps forward in Real Studio 2011 Release 3. And we continue to hear good results from our beta testers that their projects are running fine under Cocoa. We have set up a way for beta testers to alert us to any showstoppers that may prevent them from shipping their apps. Needless to say, we are prioritizing these to maximize the number of Real Studio developers that will be able to ship Cocoa-based Mac apps using our next release. This is important because starting in November Apple is placing additional restrictions that will require apps submitted to the Mac App Store to be built with Cocoa. To be clear, it's not that they are requiring Cocoa; it's that Carbon apps don't seem to be stable when built with the new restrictions Apple is requiring. To further our efforts to get Cocoa into the best shape we can for our next release, we are adding additional engineering resources.

Real Studio 2011 Release 4 will ship in November. Our Cocoa support will still be considered beta for that release. Our criteria for it to no longer be beta is that we are comfortable making Cocoa the default option for building for Mac OS X. However, although it's beta, there's a very good chance that your projects will work perfectly using the Cocoa build option so give it a try and give us feedback.

There will be more Cocoa bugs to fix for 2012 Release 1 and there are two additional features that need to be implemented for that release as well: the movie player and drawers. However, we are quite confident that 2012 Release 1, scheduled to ship in February, will bring our Cocoa support to the point where we can remove the beta label. That will be a real milestone for us (no pun intended) as the transition to Cocoa has been a long one.

Once Cocoa is no longer beta, we will return to working on our transition to LLVM for our compiler backend. While we have been focused on Cocoa, the LLVM team has been improving LLVM - and this is great news for us and you! Hooking up the Real Studio debugger was estimated to take us at least a month, due to a significant amount of work required to parse the LLVM metadata. Fortunately, the LLVM team has done this work for us which means LLVM for Real Studio that much closer.

Finally, I'd like to thank all the beta testers who take their time to help us improve Real Studio. Thank you! We really appreciate your efforts and we look forward to putting out the new releases you need.

Friday, September 30, 2011

What is "App"?

The question what is "App" comes about from a recent Feedback case. This case does report a bug - which we've fixed - but it also points out a limitation in peoples' understanding of the Real Studio runtimes.

So what does App actually refer to? If you change your app class name why does App. still refer to the right method that you wrote on your class called "TestApp"?

This is a long standing area of confusion. When the runtime starts your program, it creates 1 instance of your app class. But, at runtime how do you access that instance? You can't use TestApp as that's the name of the class and not a reference to the one instance. So how do you, the end user, get access to this one instance?

When the IDE compiles your program it actually inserts a function called App that, if you wrote it, would look something like:

Function App() As TestApp
return mAppSingleton

When the runtime starts, it creates an instance of your app class and saves that reference so it can return it later when needed.

So the App function always returns an instance of your app class - regardless of what it's called.

And you can always use App.whatever to refer to methods, properties, constants etc. that you put on your app class.

Thursday, September 29, 2011

Using SSL with the ServerSocket Class

Using ServerSockets to serve SSLSockets has been problematic at best for anyone wanting to create an application that serves secure TCP sockets. It was recently brought to my attention that even though a critical framework bug was fixed this spring, we still lacked instructions on how to set it up properly.

The instructions here are for Linux and Mac OS X, and we are actively trying to figure out the right configuration for Windows. As soon as we have that information, it will be added to the SSLSocket page in the Documentation Wiki.

The Secure Part of Secure Sockets Layer (SSL)
The first thing you'll need is to get an SSL Certificate. If you'll be testing internally or only connecting to your own apps, a self-signed certificate will do the trick. For simplicity and ease of understanding, open a Terminal window and follow steps 1-4 on this site.

The second thing you'll need to do is to combine the private and public keys (server.key and server.csr) into a single file. Use your favorite text editor to copy the contents of server.key into server.csr and save. The resulting file should look something like this:

…Edited for content...

…Edited for content...

The Hookup
Now that you've got the certificate, you will need to create an app that can listen securely. If you've done any work using ServerSockets with TCPSockets, you know that ServerSocket has an AddSocket event that fires every time the ServerSocket thinks it needs to make more connections available.

Traditionally, you would create a subclass of ServerSocket and then do something like this:

Function AddSocket() As TCPSocket
  Dim ssl As New SSLSocket
  ssl.ConnectionType = ssl.TLSv1
  //If your certificate has a password you'd enter it here
  ssl.CertificatePassword = "" 
  ssl.CertificateFile = getfolderitem("certificatefile.crt")
  ssl.Secure = True
  Return ssl
End Function

Let's say your ServerSocket subclass is called "MyServer". When you call MyServer.Listen (assuming everything else is set up), you're all ready to go!

Tuesday, September 27, 2011

Two Steps Backward, One Step Forward

In August, Mozilla introduced WebAPI, a standard API for web applications to communicate with various parts of smartphones such as contacts, dialing, the clock, etc. This would of course be with the user's permission or some other form of security. They want this API to be the same across all browsers, operating systems and devices. I think this is a great idea and it's really needed to make web-based apps "first class citizens" on mobile devices. Of course most apps may not need this level of access but if yours does, then greatly improving access to a mobile device's hardware, especially in a cross-browser way, would be great. We could certainly use it in Real Studio Web Edition.

But why stop there? Web apps running on browsers on desktop/laptop computers need similar levels of access. These types of devices may not be as sexy as mobile devices but I'd guess that more web apps are accessed from desktop/laptop computers than mobile devices. These apps could benefit from many of the same capabilities that are being suggested by Mozilla for WebAPI.

Web Apps are great because they are easy to access, require no installation and are easy to maintain for the end user. But while this is a step forward in application development, it's also two steps backward because of the limitations browsers impose in the name of security. I'm all for security but the browser can, as mobile browsers do for things like GeoLocation, ask the user's permission so insure security and enable more powerful web applications.

OS X & Fonts

One thing that surprises people in OS X is that unlike Classic Mac OS, text drawing OS X can't always draw text in italic or bold.

There's been some discussion on this in the lists & the forums and the reasons seem to all boil down to OS X drawing routines work differently than Classic Mac OS and require the specific variation of a font be installed so it can be used. There may be more technical underpinnings but the upshot is if you want italic or bold, the font has to have that variant or it won't work.

You can see this effect for yourself in a tool like TextEdit.

* Create a document and make it rich text.
* Type a bunch of text then select it all and open the Font panel.
* Select a font like Lucida Grande and try making the text italic.

In 10.5.8 this font has no italic variant and so you cannot select the Italic style for the text. It's not even enabled.

As you might guess, this affects Real Studio as well since we use system level text rendering routines. But there are options. You can always use the "standard fonts" installed with OS X that have the variants you need. Or, if you need a custom font or need to guarantee that the font you use has the variants, you can set up an Application specific font quite easily. 

The following is from this great tutorial posted by by paulg on the forums: 

1. Download a custom font file from one of the many font sites on the internet. Many are available for free with no restrictions. For example here is a freebie I will use in this tutorial: http://spacefonts.8m.com/fonts/stargate.zip

2. In a new RS Desktop Application drag a StaticText Field to the window.

3. Change the TextFont property to "Stargate" or the exact Full Name of the font, not the filename. You can get the Full Name of the font by using the finder to Get Info on the font File and you will see the Full Name. It is Case Sensitive. Note that you will not see the custom font in the IDE as it will only be visible at runtime, instead the default system font will be used. You can get around this by installing the font on your system. But this defeats the test we are trying to run.

4. Change the text to something other then Untitled. I also increased the size to 16 in my example and used all Caps for this particular font.

5. Build the application.

6. Open the built app's contents folder by right-clicking and choosing "Show Package Contents".

7. Navigate to the "Resources" folder and create a new folder to hold your font(s). In my example, I created a folder called "AppFonts".

8. Copy your font file(s) to this new directory.

9. In the Contents folder of the package, open the info.plist file in your favorite editor. If you are using the Plist editor add a new Child and add the key ATSApplicationFontsPath. Plist editor will display it as "Application fonts resource path" and set the value to the name of the folder you created in step 7. In my example I called it "AppFonts" so that is what I put as the Value.

Run the app and you will see the StaticText in the font you specified. In 10.6 you may get a warning that your app wants to use a font that is not installed on the system and asks if you wish to continue.

Of course this could use some automation and there may be a security concern if people get a message that your app wants to use a font that is not installed. I have a few other Non-RB apps that use fonts in this manner and I do not get that warning so not sure what that is about, maybe code signing?

You can use more then one font in your app, just include them all in the folder you created in step 7 and refer to them by name.

Tuesday, September 20, 2011

Saying Goodbye to Mac OS X 10.4 Tiger

We generally support a particular version of an OS for about 5 years. Mac OS X 10.4 is more than 6 years old now. Apple no longer updates 10.4 even for security issues and most of the sites that report version statistics indicate that usage of 10.4 is at about 5% to 10%. The longer we support older versions of any operating system, the fewer resources we have to support the newer, more modern releases.

With that in mind, Real Studio 2011 R4, due in November, will be the last release to officially support Mac OS X 10.4. We wanted to make sure you knew this ahead of time so you could plan accordingly. 

Windows 8, Metro and Real Studio

Last week Microsoft released the first developer preview of Windows 8. At Real Software, we have done some preliminary testing of Real Studio on it and so far, so good.

There are a dozen or more reviews of the Windows 8 developer preview along with the new Metro user interface so I'm not going to write another one. But I will give you my overall view of it and where Microsoft stands at this point.

Metro shows that Microsoft understands the problem of taking the current Windows UI and putting it on tablet. Though Metro is a step in the right direction, Microsoft continues to display a no longer deserved arrogance. When it comes to smartphones and tablets, Microsoft is in a distant 3rd place yet they act as if they are the clear frontrunner. When they shipped Windows Phone 7, the team at Microsoft had a mock funeral for the iPhone. We all know how that turned out. I watched one of the Metro presentations. The presenter talked as if iOS, arguably the premier smartphone OS, had not already done most everything he was showing. And he talked about iOS and Android without mentioning them by name as if they were not worthy competitors. Professionally, that sounds silly. 

Like I said, Metro is a good start and there are minor improvements here and there over iOS as it is today. For example, they have made moving an app from one page to another much simpler by allowing you to hold the app and flip though screens with a second finger. The thing is, Metro is not competing with iOS 4 or even the soon to be released iOS 5. It will be competing with iOS 6 which will be shipping when Windows 8 and Metro, which Microsoft has spent the last two years developing, start shipping. There aren't even rumors about iOS 6 yet. And there are large areas of Metro where it's clear that Microsoft just doesn't get it. The simplicity and clean lines are great. But the animation on the Start screen, while it might make for a good demo, is REALLY distracting. The screen has a dozen visible tiles, each representing an app, some of which are changing their content every few seconds. I was instantly reminded of the scene in the movie Idiocracy where this guy in the future is sitting in his living room watching nine TV screens all at the same time. Don't get me wrong. I LOVE animation. But it should be used sparingly in a user interface or it can become counterproductive.

Microsoft is really behind the eight-ball. They probably felt they needed to show Windows 8, what is likely to be more than a year before its release, to keep Windows developers focused on Windows development. I get that. But what Microsoft needs more than anything is a change of attitude. They continue to act with arrogance when they have been humbled by Apple and Google in the smartphone and tablet market. Microsoft's stock price hasn't really changed in almost ten years!

Microsoft is still the dominate player on the desktop. But even there, PC sales are flat or in decline (while Mac sales are on the rise) because a portion of the market is shifting to smartphones and tablets. Microsoft is not at all positioned to keep customers, let alone gain new ones in this market shift. Of course, they are keeping customers to some degree because the cost of switching is high but if Microsoft is going to have any chance of beating the competition, they need to feel hungry and they need to act humble. Shouting "We're number one!" should be reserved for those that actually are number one.

Wednesday, September 14, 2011

The Rough Edges of HTML5

In his post last month, "The 11 hard truths about HTML5", Peter Wayner points out that HTML5 has some rough edges that prevent it from unseating native apps. I think he's right.

Wayner begins with the inherent security issues of JavaScript, that if you know what you are doing, you can change variables since they are exposed to you. The solution is to code defensively. The example he cites is a user changing their longitude and latitude to make it appear they are somewhere they are not. Developers should request this data any time they need it rather than store it in variables that could be manipulated by the user. However, this does place the burden on the developer. 

Further, there are security issues with web apps built with traditional tools like JavaScript that Wayner doesn't mention. In the vast majority of cases, web apps are a bunch of text files on a server somewhere. Larry Nedry, a friend of mine and an internet security expert, says, "The only way to make a server totally secure is to unplug it." He's right. If a hacker really wants to get on your server, they will. Since the source code is all exposed, it can be manipulated in ways that can easily go undetected by many developers. We solve this problem in Real Studio by compiling web apps to native machine code. While it's still possible to hack, it's significantly more difficult and most hackers are likely to move on to an easier target.

Wayner also mentions how local data storage is not as useful as many had hoped because the user can switch browsers or computers. And since it's just a SQLite database, it can be easily changed, which means it's no good for storing sensitive data. He points out that local storage is used for creating applications that work off-line but syncing to a server-side database is problematic as well. Heck, if the user can change the data, syncing could get really screwed up.

He's right that one of the huge benefits of web apps--that the user doesn't have to install and upgrade them--can also be a detriment. Users aren't always ready to upgrade when the developer is. This is another area where the developer has to be extra careful because he or she is upgrading everybody at the same time. Native apps don't suffer from this problem but this is just one of those things developers have to accept about web applications.

Finally, Wayner discusses the fact that there are incompatibilities between browsers with tag formats, varying levels of feature implementation and hardware idiosyncrasies. He says, "...why have I wasted two weeks trying to get basic audio files to play in all of the major browsers?" Good point. In the end, he summarizes it all when he says that many JavaScript developers have left it up to libraries like JQuery to abstract the developer from these differences.

As developers, heck as humans, we long for a silver bullet solution. Those rarely occur and when they do, they are narrow in focus rather than something as broad as HTML. HTML5 is a great step forward in making web applications more desktop-like. But it's just one of many steps toward this end and as a result, native applications will be with us for a long, long time.

Having said that, one of the ways in which we as developers can make use of the increasingly faster processors available today is by having more abstraction from platform details. The details I'm talking about are not just the ones that Wayner mentions but also from HTML, JavaScript, CSS, PHP, and AJAX or what I call the assembly language of the web.

Developers should be able to build their UI via drag and drop like they do on the desktop. And they should be able to use the same language and frameworks they use for the desktop as well. The browser should be nothing more than the delivery system for the app. Why should a developer have to start over from scratch just to build an app for a new platform? Why should they have to abandon so many of the skills they have mastered?

Our goal for Real Studio as always been to abstract developers from all of this. Real Studio provides developers with a single IDE, language and framework with which to build applications for Mac OS X, Windows, Linux and the web. Yes, there are some differences between these platforms and we can't abstract 100% of them but we abstract enough to let the developer focus on what makes their application unique. This level of abstraction does require developers to give up some control. However, most developers don't need 100% control and will gladly give some of it up for far greater productivity and security.

The long term solution is for development tools to shield developers from platform differences. Computers and mobile devices have the processing power to allow for this. It is the development tool that can provide the layer of abstraction that smooths out the rough edges of both native and web application development.