The September/October 2010 edition of REALbasic Developer came out this week. Marc Zeedar has additional information about the REAL Studio Web Edition and includes some details that I didn’t cover in my Web Edition blog post.
JC has an article on Trapping For Errors which is a good read. Coincidentally, in my regular column I talk about how having a program fail can be instructive and how ‘failure is always an option’.
More information on REALbasic Developer Magazine can be found here.
In almost all of my applications I have an automated bug reporter class that allows the user to send me the Runtime Error type, the Error Stack and (hopefully) a brief description from the user on what they were doing. It lives only in the App.UnhandledException event and nowhere else. It’s far from perfect, but it’s better than nothing.
What do you have in your RB apps to get that crucial error information?
First, let me get this out of the way: I am not a web developer. My plate is more than full enough developing desktop applications and while I’d *like* to do some web apps, it’s just not in my realm of the probable at this point in my life. However, I am pretty good at developing REALbasic applications that work well on Mac OS X and Windows (and throw the occasional Linux app in there too).
REAL Software announced today a new version of REAL Studio, called Web Edition, that will be released some time this Fall. Internally, they called this product Barracuda. If you know any history about REAL Software, they had an internal product named Swordfish that they announced at their annual developers conference in 2005. It was never released because it was already obsolete soon after they announced it due to a variety of technologies like AJAX and JAVA and a number of other technologies. So call this completely rewritten version the “Son of Swordfish”.
I spent three hours playing with an alpha build this weekend and my first impression of the product is good. Since it’s an alpha build it has plenty of bugs but it is an interesting twist on REAL Studio and REALbasic. This has the potential of being the first Rapid Application Development environment for web apps that doesn’t require an expensive server as these apps will run on any Apache server or web server capable of FastCGI (not all commercial hosts enable FastCGI on shared servers).
Existing users of REAL Studio will be instantly familiar with the editors and know how to get around. Since web apps are unlike desktop apps in many ways, there are a number of new objects, classes, and controls that are for web apps only. There are also some things, like the MsgBox function, that did not work for me but will probably work when it’s released.
Instead of the regular Application object, every REAL Studio web app has a new WebApplication object that handles the open, close and unhanded exception events. New to the web app is the WebSession object which represents each user that is connected to your application. It has Open, Close and Reloaded events which, as you can imagine, are similar to what you might do in the Application object in the desktop version since a desktop app supports one user at a time.
Instead of creating windows, you create web pages and you edit them in the web page editor. It is much like the current window editor but has a new set of controls and new features to go along with it.
One of the first new features you’ll notice is the ability to do in-line editing. There is a little editor icon to the right of most controls that when selected, brings up an editor for that control and masks out the other controls. For some controls, like buttons, text fields and so on it simply changes the text you see on screen. For more complex controls like the listbox, for example, you can add column headings and add default data into the listbox.
In some respects some of these features remind me of how ActiveX controls in Visual Basic 6 used to have their own editor and UI and for the most complex of controls this will be welcome as editing them through the properties list can be tedious. For the simpler controls (like the button, label, etc) this new inline editor does the same thing as simply selecting the control and starting to type.
The page editor has tweaks on features that are better than the current Window editor such as visually aligning controls and showing spacing differently. There are also a number of new controls that are pretty common in web apps today: Link which is a label that when pressed opens the browser to a new page; Search Fields which is a rounded TextField that keeps track of last values held; Segmented Button which is a row of buttons that can act like either radio buttons or check boxes.
There are a number of controls that have changed as well. Pushbuttons are now WebButtons and Checkboxes are WebCheckboxes but act pretty much the same. The StaticText object has been renamed to the WebLabel (which makes more sense to many developers coming from other languages). Radio Buttons are no longer individual controls – they are now part of a group and you can specify their dimensions like a listbox (number of columns and rows). I’m actually on the fence on this one since I see the value in it but could also see it biting me depending upon the complexity of the user interface in the project.
The first release will not come with a proper tab control, unfortunately. This is disappointing, but you can easily overcome this limitation with a Segment button and using Container Controls. Just like with the desktop app, I think Container Controls are incredibly powerful, and is a useful way to make complex, reusable ‘window-like’ objects.
Perhaps one of the bigger changes is the removal of the Canvas object. This was done, I was told, because HTML5 has a canvas object and REAL Software did not want any confusion. Instead we have the ImageView object which can accomplish many of the same things using its Picture property (the graphics object is gone). The canvas object may return at some point, however.
One huge change is that in none of the controls or windows can you control the text characteristics or background colors you’re used to expecting in a desktop app. For that, we now have Styles. Adding a style is just like adding a new class or anything other object in REAL Studio and when you edit a style you have the ability to change the properties of Normal, Hover, Pressed, and Visited objects (this includes pages). There, you can control the text properties, border, shadows, padding, corner radii, and opacity.
As you can imagine, this leads to some very interesting interactions that take very little code. For example, you can create buttons that change color when you hover over them, or change opacity once you’ve clicked on them. I suspect that this will be a huge deal in the long run as it makes very complex interfaces very simple.
Since there are a ton of things you could do with a web app and no possible way for REAL Software to cover them all, they have a virtual control called PageSource that lets you add pure HTML code, JavaScript, and others, and can be placed in any web page. It has two properties, the code itself and the location. You can place it in the Header, Before Content, or After Content. I imagine that just like for plugins for desktop applications, there could be a market for HTML components for REAL Software web apps.
Placing and dealing with the code behind the objects is just like a desktop application. In fact, it’s the same code for the most part. Where things start to diverge is with dialogs. In desktop applications you create a window and change it’s super to modal dialog or similar, and call it via code. This was flexible and convenient but created a new window. Many users have popup windows turned off so this won’t work.
To compensate, REAL Software created a web dialog class that doesn’t create a new window, it just shows up on the current window using some nifty AJAX. Since the standard MsgBox method did not work in this alpha build I ended up creating my own web dialog and adding it to the page. After you add it, it is displayed in a new list at the bottom of the window and can be access there. Otherwise it acts similarly to how dialogs work now.
Debugging an app is easy as well. Simply hit Run in the IDE and it compiles and runs the web app on the local web server. It responds to break points and exceptions just like a desktop app and and allows you to interrogate application variables in the debugger.
I’m not sure if web apps will understand the concept of Reports in the first release or not. If you need to display a report to the user, you could probably accomplish the same thing with a listbox that covers the entire page.
Currently, REAL Studio supports two types of builds. The first is HTTP and the second is FastCGI. FastCGI should be more efficient, but might not be for everyone if you’re on a commercial hosting service since many do not support FastCGI.
REAL Studio Web Edition apps work with Safari, FireFox, Chrome and Internet Explorer. How far back this compatibility goes I’m not sure of at this point. If you find a limitation, you can use the functions in the Session object to get the browser type, operating system, platform, etc and give corresponding messages.
The Session object also keeps track of the page state so your active web pages won’t be forgotten during a session. This means that each page is ‘remembered’ which is a very nice feature. So if you have a Customer page and an Invoice page and the user reloads the page or closes it and returns before the session ends it will load exactly where the user left off. This is another one of the main features that I’ll like to see in action on a complex web app.
I spent less than a half hour converting a very small calculator application I had originally written as a desktop app. I spent more time logging the minor bugs (I did say it was an alpha build, right?) I found than I actually did writing the web app. I have no idea how long it would take to accomplish the same thing in php, Javascript, Ruby on Rails, or ASP.NET, but I suspect the answer is longer. I’ll be curious to get a true web developers impression.
The one big question that remains is how easy it will be to deploy and install REAL Studio web apps on your server. I looked up some documentation on my commercial host on how to install FastCGI apps and it did not appear to be for the feint of heart as it required going to the command line on the server. At this point I do not think there is an option for Single-Click-to-Install.
The Web Edition will become part of the Enterprise Edition of REAL Studio and also as a standalone version for those interested only in web apps. This addition to the Enterprise Edition really makes it worthy of the Enterprise moniker now. The web app addition is scheduled to be released sometime this Fall. With REAL Software’s rapid release plan that could mean either Release 4 or 5.
What do you think about this announcement? Is your curiosity piqued?
REAL Software announced yesterday that REAL Studio 2010 Release 4 will no longer be actively supporting the PowerPC (PPC) framework. This really means that only major bug fixes will be done to the PowerPC framework and nothing new will be added to it.
At the 2005 World Wide Developers conference Apple announced the move to Intel and many people were shocked that they would give up the PowerPC line of chips they spent a decade promoting as being better than their Intel counterparts. Intel was the future and blah, blah, blah. Many people said the Reality Distortion Field was on full blast.
In retrospect it seems so clear. One could certainly argue that Apple’s resurgence is, in part, because of their move to Intel. With a growth rates in the 30% range in year to year quarterly sales growths it’s not very hard to come to that conclusion either.
It’s been five years. Most consumers have an Intel based Mac and most businesses will probably be phasing them out in the next couple of years if they haven’t already. On BKeeney.com, only 10% of visitors are running a PPC Mac. BKeeney Briefs and the ARBP site are both less than 2%. When 90+% of total visitors to your websites are on Intel it’s safe to say the Intel transition is nearly complete.
The reaction to REAL Software’s announcement has been calm, I think, mainly because no one is shocked by the move. Most developers are most likely on Intel Macs and I think a vast majority of software buying consumers are on Intel now as well.
Since Cocoa is Intel only and the IDE will eventually be built using Cocoa this presumably means that the IDE will no longer run on PPC machines. This is probably not a big deal for most REAL Studio developers.
It might be a big deal for developers serving the education market, however. But since they’ve said they will not remove the PPC build option for several years that market should be relatively safe for the foreseeable future.
Transitions can sometimes be painful. The fact that Apple pulled off a major transition with very few problems is a testament to their engineering staff. For companies that feed off of Apple this transition wasn’t always easy and REALbasic had its growing pains. The transition to Cocoa has been painful but in the long run it will allow REAL Studio to grow with whatever is coming up next for Apple.
What do you think? Do you still work on a PPC machine to do development? Do you still serve PPC users?
I ran into a problem with REAL Studio this week that was annoying. The IDE hard crashed on me and it had tried to save the project (this is a good thing!). When this happens you get a dialog the next time start REAL Studio that says:
“REAL Studio has found unsaved changes from a previous session. Would you like to recover these changes?”
However, in this particular case I didn’t care about the changes so it was no big deal. I clicked No and worked on the project. Usually you never get the message again but I was every time I restarted REAL Studio. Again, not a big deal, but it was annoying.
The fix was relatively simple (thanks to RS staff on this one). On Mac OS X, REAL Studio puts files in the ~User/Library/Application Support/REAL Studio/RB2010 AutoSave Projects/ directory. Sure enough when I looked in that directory there were some files that shouldn’t have been there.
I simply deleted them, restarted REAL Studio and the problem went away. Voila! Hopefully someone else will find this useful.
The official press release will go out soon and will go through the official REAL Software distribution channel but I couldn’t contain my excitement any longer. It’s almost (but not quite) as exciting as announcing to your friends and family that you’re going to have a baby.
Mark your calendars and start making plans to attend the REAL Studio Summit 2011 in Atlanta, Georgia. The event takes place on March 19th and 20th, 2011 and is sponsored by the Association of REALbasic Professionals and REAL Software!
We are very pleased that REAL Software is participating. They will be sending a couple of people and will most likely present a couple of sessions.
Speaking of sessions, the call for speakers will go out soon as well and with the advanced notice I think we’ll get some really great speakers on a variety of topics. We will be targeting some people in the RB community based on their contributions on the RB Forums and NUG list and we hope to get some commitments soon.
I was always a big fan of the old REAL World events – not because of the sessions (though those were important) but because of the relationships you developed (no pun intended) with other REALbasic developers. Let’s face it, many of us don’t know another REALbasic developer that lives near us. I feel lucky that I found six in Kansas City and when I get together with them there’s a kinship that’s hard to explain. I’m energized about the platform and I get inspiration from them when they tell me what they do with REAL Studio. To me, that’s what the REAL Studio Summit is all about.
It’s not too soon to think about 2012. Pacific Northwest? MidWest? Europe? If you have a local group of RB users you might want to start thinking about it and contact me if you’re interested in being the contact team.
My review of REAL Studio 2010 Release 3 is up on the ARBP site.
Bottom line is that Cocoa isn’t ready for prime-time yet (obviously since it’s labeled as BETA), but it is nice to see what they’ve been working on. I urge you to try it out and report the bugs you find (which shouldn’t be hard to find). The more reports RS has on Cocoa bugs the better Cocoa will be eventually.
RBScript is still a mystery. I don’t use it any of my projects and I don’t know of many developers using it. With a new compiler (LVVM) behind it I expect it to break some projects. Again, finding and reporting the bugs will help all of us.
Console applications being able to access the graphics classes seems like a recipe for disaster in certain situations. If you use console apps a lot what is your opinion of this change?
What is your opinion of Cocoa, RBScript and Release 3 in general? Did I get anything wrong?
Official word from REAL Software about Cocoa. 2010 Release 3 will include the option to build for Cocoa. Officially this will be labeled as ‘beta’.
I think this will generate a LOT of Feedback reports for them. Sure, it’s ‘beta’, but will users really take that into account when they start bitching about it not doing something? I guess only time will tell.
The Serial communications saga continues…. Never say die when it comes to serial communications because, like so many things in programming, there are multiple areas where the problem might lie.
Here are the facts as I knew them this morning. Given a hardware configuration (serial port to fiber optic converter to fiber optic converter to Serial to USB converter), I could reliably talk to my device in Mac OS X and Windows XP. In Vista and Windows 7 it failed. The serial port monitor software that I running in Windows was able to see the messages with 100% accuracy while the RB serial control was not.
Sounds like an RB bug, right? I submitted it, with video proof, and had a reasonably happy weekend. The client was not happy, understandably, and after consulting with REAL Software (who, by the way, responded to my email promptly this morning) agreed that it might be a bug and they would be happy to try to reproduce (and ultimately fix it) if we sent them the hardware and a sample program and some money to do it for the R4 release. R4 will come out sometime this fall, by the way.
The client was not happy about the additional cost and the time delay as you can understandably imagine. So I said I’d do some research and figure out if other people are having serial issues too before issuing a recommendation to send all the materials to RS. I’m sure some of you are guessing where this is going.
It just so happens that the specific manufacturer of the Serial to USB Converter (Prolific) has some serious issues with their Windows 7 (and Vista) drivers. After a few more specific web searches I found an alternative (perhaps older) driver that works fine if you do the following in Windows 7: Right click on the properties of the installer, select Run as Administrator and select Vista SP2 under the compatibility popup.
Run the installer, restart Windows 7 and Voila! We now have a fully functioning driver – that works – in Windows 7.
Hindsight, as they say, is always 20/20 and I *should* have thought about this last week. I had “something in the middle” that I assumed worked. I had evidence that it did work (the serial port monitor) but my assumption was false (obviously).
Debugging serial communications (and network communications for that matter) is a royal pain in the behind. When something isn’t working, work the problem backwards. When there’s hardware involved, verify that the hardware works or try to eliminate the hardware. In my case, my Windows 7 doesn’t have a true serial port (it’s running on my Mac in VMWare).
So maybe you’ll learn something from my experience and pain. Maybe you’ll keep yourself from having a bruised forehead (from banging your head up against a brick wall).
I’ve had one of those weeks where I thought I was going crazy (crazier?). My cross-platform application that works fine on Mac OS X was behaving very strangely in Windows but only sometimes. This particular application talks to a hardware via a serial port. My standard test platform is Windows 7 with Windows XP as the secondary and both of these are run in VMWare on my Mac. So a bunch of things might be at fault but after trying this out on an old Windows XP laptop I quickly narrowed the problem down.
The data packet the hardware device sends is very small – 4 characters to be exact. What I was experiencing was that RB captured the first character on the first send – but not the whole packet. Then it would complete the first message on the 2nd message and only get part of the 2nd message. It would go something like this:
A
B | A
C | A
D | A
Where A is common to all messages so they should be AB, AC, AD and so on.
These messages in the real world are sporadic and with the exception of a regular hardware pass message it might be days or weeks in between messages so as you can imagine, this problem mucks up the logic quite a bit.
If you are not familiar with the Serial control, the DataAvailable event fires when there is data available (duh) and there you can check what’s in the serial buffer by using the LookAhead function. LookAhead in this case showed just the first character. The other property to check is BytesAvailable which should tell you how much is still in the buffer. It simply returned zero so I should have a complete message. Definitely something screwy going on there.
Invoking Serial.Poll via timer did not produce any different results. Neither did forcing a ReadAll.
One other thing that I discovered was the Serial Port Monitors are worth their weight in gold. Using one, you can at least verify that the data got to the computer. A free 14 day trial was good enough but if I do any other serial projects it will be worth it.
The good news is that I wasn’t crazy. The client is okay with Windows XP for now. The bad news is that it might take a release cycle (or more) to get it fixed. Oh well, battles for another day….
The July/August 2010 edition of REALbasic Developer Magazine is out. This months column title is “Having a Thick Skin: Take the Emotion out of Your Tech Support”.
I talk about the pitfalls of providing tech support when people asking for (or is it demanding!) for tech support aren’t nice. Email and forums posts are awful mediums for communicating to each other so you have to take the emotion out of the equation.
Do you have any horror stories, tips, or jokes about tech support you’d like to share?
