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.

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:


-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQCgdz6vtxQcENpusUzL+aReKYRQv9lYoxYT4l7yK4ylLw
PE/qOVx3puQDYZb80WzvDq2Z4t5KyYEEru3f+s4OfMhdUnDEkkOMLrBE1
…Edited for content...
-----END RSA PRIVATE KEY-----


-----BEGIN CERTIFICATE-----
MIICUTCCAboCCQCaEmvwajGn1DANBgkqhkiG9w0BAQUFADBtMQswCQYDV
UzETMBEGA1UECBMKU29tZS1TdGF0ZTESMBAGA1UEBxMJU29tZS1DaXR5
…Edited for content...
-----END CERTIFICATE-----

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!

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.

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.

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.

When a WebLink is not a web link

Every once in a while, a situation comes along where you want the appearance of one control, but the behavior of another. A user recently asked me if they could use a WebLink control just to execute some Realbasic code in the MouseUp event, and you can, but there's a trick!

If you add a WebLink to a page and then add a Msgbox command to the MouseUp event like this:

Sub MouseUp()

MsgBox "Hello World!"

End Sub

The problem is that the WebLink is expecting to have a URL associated with it. Leaving it blank and clicking anywhere on the text of the link causes the page to refresh, clicking outside of the text (but still on the control) will execute the code in the MouseUp event.

So how do you get the whole control to behave? In the URL field, type this:

javascript:;

This tells the browser that instead of going to a page, you want it to execute a command (in Javascript). Immediately following with a semicolon sends an empty command, so it does nothing, and the MouseUp event fires the way you want it to.

Presto!

The Cost of Using a Slow Computer

This is an interesting article about the cost to a company of having developers using less than optimal computers for their work. At Real Software, I learned this a long time ago. Replacing developer computers every two years or less is better for the developer and doesn't cost as much as you'd think. You can get more for the computer if you sell it sooner or pass it on to another person in the company.