LiveCode vs Xojo

I have been a Xojo developer for many years and I make a decent living at it.  That doesn’t mean, however, that I don’t look around at other development environments every now and then.  I do this because it makes good business sense to keep my options open.  This week I looked at LiveCode after a reader asked me to.

LiveCode (formerly called “Revolution”) is a unique development environment that has been around since 2001.  It was inspired by HyperCard and due to its lineage it uses a Card and Stack metaphor to represent windows, objects, and applications.  To put it more in Xojo terms you can think of a window as being a Card and the entire application as a Stack (of cards).  Dialogs and other objects can then be sub-stacks.  LiveCode can make Mac OS X, Windows, and Linux desktop applications, cgi-like web apps, and mobile apps for iOS and Android.

Its scripting is a natural English-like programming language that presumably makes it easy for casual programmers to get started.  Another interesting feature is that there is very little difference between ‘development mode’ and ‘debugging mode’ and switching between the two is literally just a button.  This means that you can run LiveCode commands practically at any time without the need to compile the application first.

The IDE has a variety of windows.  The Application Browser shows you all of the objects in the stack and lets you open each card into an editor.  The editors let you put controls on the Card (layout) and each card and UI object has a number of Messages that are similar to Xojo events.  LiveCode does not have an all-in-one window like most other IDE’s.  At first, I found the individual windows to be refreshing but after I while I found that I was fighting with background application windows.  I’m sure this is something that becomes more natural with usage but I had issues with it.  I’ve always wondered if Xojo’s all-in-one window IDE approach was really the ‘best’ approach to a development environment and now I see that I prefer it as it eliminates the distractions of other windows.  Also, Eclipse, Visual Studio, Xcode and Xojo all have all-in-one IDE’s so I this it safe to assume that most developers are comfortable with this style.  You may find LiveCode strange if coming from an all-in-one IDE.

The LiveCode scripting language definitely takes some time to get used to.  The natural English syntax seems inviting but after 30+ years of coding in various languages I found it frustrating.  It’s wordy and not exceptionally compact in its meaning.  If you don’t already have any programming experience this might be good for you.  If you’re coming from a different language you might be as frustrated as I was.

Xojo events are relatively easy to find and implement.  You simply right-click on an object either in the Navigator or in the Layout Editor and add Events to the object and it’s added into the code waiting for you to add your own code to it.  The object messages in LiveCode are not so easy to figure out, in my opinion.  To figure out the events I had to go into the documentation (which was decent, in my opinion), and had to look them up and then type them into the Script Editor.  I’m sure with a little time and practice I would pick up the messages that I use most often, but it is a hindrance to picking up the language.

LiveCode Dictionary

LiveCode API Dictionary

 

The Xojo Code Editor has a pretty good auto complete.  Auto complete means that when you start typing, say “SQLite”, and if there are either language keyword matches or variable matches the eclipses (…) is shown and if you hit the tab key a list of available properties and methods are shown to you in their proper context.  This makes discoverability much easier.  LiveCode has no auto complete in their Script Editor which means you have to look up the commands before you start typing and you won’t know if they’re correct until you run the project.

LiveCode has objects but they don’t have the same Object Oriented nature as Xojo.  In Xojo you create an instance of the object and then get/set a property or call a method using the dot notation.  Thus opening a database in Xojo means creating a new instance of the Database, setting a FolderItem property on that object.  Then calling the CreateDatabaseFile method on that same object and it returns a true or false to indicate success or failure.  All of that revolving around the same object (database).  The same thing in LiveCode requires less coding steps but there is no dot notation and it’s definitely more procedure driven.  Each method is its own call – not part of an object – and means that you’ll spend more time looking at documentation to discover them.  I feel that Xojo’s discoverability is superior to LiveCode.

LiveCode is not a strictly typecast language meaning you can use a variable anywhere at any time.  This means that writing scripts can be very quick but it also means that introducing errors is easy and with larger projects it might be hard to find errors.  Xojo, on the other hand, is strictly typecast and the compiler will tell you if a variable is not defined or if you try to put the wrong type of data into a variable.  There are plenty of other languages out there that don’t require variable type declarations but I never have spent much time with them.  If you’re used to them it’s probably no big deal but I tend to like the compiler to warn me early and often of any potential issues.  Another little thing about the language is that to assign a value to a variable using the Put command rather than an equal (=) sign.  In LiveCode you would say:

put “ABC” into myStringVariable

In Xojo this same thing would be

dim myStringVariable as String = “ABC”

LiveCode Create DB

Creating an SQLite Database File using LiveCode

Xojo Create Db

Creating an SQLite Database File using Xojo

 

One of the major drawbacks that I discovered early on was that LiveCode does not make native looking applications.  The good news is that PushButtons look the same on each platform (no mean feat) but it also means that those Pushbuttons don’t look native on any platform.  There are commercial plugins available to make LiveCode applications look native on each platform.  I don’t believe that the plugins are using native controls either so this means that an OS update might ‘break’ the look of an application until those plugins are updated.

LiveCode Mac app

LiveCode App running in Mac OS X

LiveCode Ubuntu App

LiveCode App running in Ubuntu

LiveCode Win8

LiveCode App running Windows 8

 

Xojo is not perfect in this regard as not all of its controls are native on each platform either.  It does, however, use them whenever possible.  Another drawback to Xojo is that control features are often times the lowest common denominator between Mac, Windows, and Linux for desktop platforms.  This is more for feature parity than any malfeasance on their part.  Xojo web apps and iOS apps use native controls.

LiveCode, like Xojo, lets you create external libraries using C++.  LiveCode calls these Externals while Xojo calls them plugins.  It appears that there is an active community of developers and an active 3rd party development community for LiveCode.

Unlike Xojo, LiveCode comes in two different varieties:  Community Edition and Commercial.  The Community Edition is open sourced and free but limits you to open source and GPL applications.  If you are interested in LiveCode this is where I’d recommend that you start.

There are four different types of commercial LiveCode licenses.  The Indy Commercial license costs $299/year per seat and lets you do closed source and royalty free commercial apps with a $500k revenue limit (how this is enforced I have no idea).  The Business license costs $999/year/seat and eliminates the revenue limit.  The Pro license $1,999/year/seat and gives you more personalized service and a Premium license is $10,000/year for 3 seats and gives you priority support, use of their test suite, extensions, priority features (whatever that means) and a LiveCode conference ticket.

LiveCode also has a membership program that costs $99/year ($25/year for students) and gives you exclusive membership benefits and helps supports the continued development of the platform.  You also get access to over 100 training videos and access to the LiveCode Conference simulcast.

What I Liked About LiveCode

I found the LiveCode Start Center to be clean and uncluttered and useful.  It has four main areas, Projects that shows your recent projects, Getting Started that has handy links to the some beginners videos and guides, Resources that takes you to tutorials, sample stacks, the community forum and their API dictionary, and finally they have a Sample Projects list that has a sample projects in it.

The LiveCode website also does an excellent job of pointing out 3rd party commercial and non-commercial extensions and what they can do for the developer.  They also allow user reviews of the extensions so it makes it easier to make a purchase decision.  I have no idea what it takes to get listed on their website or if LiveCode takes a cut of the revenue but it’s something I wish Xojo would do a better job of helping their 3rd party developers market.

I also found it refreshing that their API documentation allowed user comments.  I really wish Xojo would do something similar because I feel that we, the user community, could add some really useful comments to the documentation.  While I like the Xojo documentation I feel it might be better served by opening it up a bit (with moderation).

LiveCode does deploy for Android which might be a huge bonus for some.  Assuming I could get a UI that looks native it might be the one thing that would make me look at LiveCode with any seriousness if a client asks for Android deployment.

Finally, the fact that part of LiveCode is open sourced is interesting.  They successfully ran a KickStarter campaign to open source the product in 2013 and successfully did a campaign on their own website to fund HTML5 web deployment in 2014.  I don’t know about anyone else but I would help fund certain items for Xojo development even if wasn’t open sourced (perhaps a better grid control?).

What I Disliked About LiveCode

If you’re coming from C++, Java, or any object oriented language I think you’ll find the lack of ‘objects’ to be disheartening.  Add to it that there is no auto complete for the Script Editor and I think it’s a deal killer for me.  Those two features make discovering events, properties, and methods so much easier without having to constantly check the documentation and I think it’s a huge adverting for Xojo.

The lack of strong datatypes, while not a deal killer, scares me a little.  I want to be warned early, often, and loudly when things go wrong and strong datatypes are something that I really find attractive in a programming language.  If there’s a data conversion going on it’s because I want it to happen (don’t get me going on Xojo variants – they’re evil – get over it).  The natural English scripting language also puts me off simply because it’s unnecessarily wordy.  Again, if you’ve never programmed before this might be an advantage.

The lack of native looking controls is also huge drawback for me.  Xojo apps will try their best to look native (though Linux apps require more of a nudge than Mac/Win apps) and while not perfect, out of the box, Xojo apps are generally native.

Conclusions

Is LiveCode worth a look?  Sure.  Like any development environment, if it speaks to you and you can get your projects done in it then it’s the right one for you.  For me, Xojo is a better language, with a better IDE, and has more features that I want.  Xojo is only lacking Android support and I’d probably look more at Xamarin than LiveCode for a variety of reasons.

If LiveCode works for you that’s great.  This review isn’t meant to be overly critical of the tool but as an existing Xojo developer I don’t see enough reasons to switch from Xojo development to LiveCode.  Feel free to leave comments below on anything you feel I missed or got wrong.

Subclassing vs Extends vs Containers

Xojo is really powerful because it gives you multiple ways to create really powerful controls.  Today I’ll discuss subclassing, extends, and containers.

Subclassing

First, subclassing a control is really easy to do.  Create a new class and set the super to the control you are extending.  A great example of this is the Xojo ListBox.  In its raw form it’s powerful, but limited, in its functionality.  To have those awesome alternating row colors we subclass the ListBox and put our code in the CellBackgroundPaint event.

One of the things that people forget to do when subclassing the control is to repeat the events that that they are using.  Because I’ve used the CellBackgroundPaint event it’s not available to any instances of the class.  Sometimes this is desirable, but sometimes you want the control to still have those events.

The solution is simple.  Define a new event named CellBackgroundPaint and use the same properties and return value.  This means that you, the developer, can have the alternating colors in your listbox but also still have the opportunity to override those colors if you need them.

The other powerful thing about subclassing is that you can continue to subclass them all you want.  In one of our projects we have the following Listbox hierarchy:  ListBox -> AlternatingRowListbox -> CustomCellListbox -> RecordsetListbox.  Each one is still a Listbox, but each gets all of the events and properties of its supers so this means that the RecordsetListbox automatically gets the alternating rows even though it specializes in loading the listbox by using a Recordset.

Extends

Sometimes, though, you only want to add a single method to a class.  Creating a subclass to do this might be overkill, especially if you have to go back and and retrofit this change in a lot of places.  A good example of this the PopupMenu where you often have to set the text of the PopupMenu to some value.  The code is often like this:

for i as integer = 0 to pm.ListCount-1
   
   if pm.list(i) = sSomeValue then
      
      pm.ListIndex = i
      
      exit
      
   end
   
next

It’s not hard but after you’ve done this several dozen times you come to the realization that this should be automated somehow because it’s a lot copying and pasting and if you find a better way in the future you’ll hate yourself (trust me, I’ve done this).  You could easily subclass the PopupMenu and go through and change the Super of all existing popupmenu’s, but there is an even simpler way of doing this:  Extends

Extends lets you create your own method that acts like it’s part of the class.  If we were to take our code above for the PopupMenu and put it into a module (it won’t work in class objects like Windows) our code would look like this:

Sub SetText(extends pm as PopupMenu, assigns s as String)
   
   for i as integer = 0 to pm.ListCount-1
      
      if pm.list(i) = s then
         
         pm.ListIndex = i
         
         exit
         
      end
      
   next
   
End Sub

Same code, just using the extends.  What’s great about this is that using it super easy.  It becomes part of the AutoComplete list and is a ‘dot’ extension (just as if it was a subclassed item).  So calling it is like this:

pmFont.setText = sTheFont

I don’t remember when the Extends method was introduced but since it was introduced the number of Subclassed items in our projects has dropped dramatically.  Using Extends fails in one area and that’s Properties.  If you need a property for the additional functionality, you’ll still need to subclass the control and add the property to the subclass.

Containers

This final method may confuse some people.  Using a container control isn’t a subclass nor using the extends.  Containers are incredibly powerful controls in Xojo, though, because they allow you to create combinations of controls (and their subclasses) in unique and reusable ways.  A great example of this is a typical Save/Cancel pair of pushbuttons on a dialog or window.  On Macintosh OS X the Save button is on the right and the Cancel on the left.  On Windows it’s opposite.  In Linux, it’s the same order as Windows but the buttons have a different height.

There’s nothing stopping you from adding code to every window that has this Save/Cancel combination so that they’re in the proper location and height.  But why?  This is Xojo, a modern object oriented language!  Plus, I hope you’re as lazy of a programmer as I am because that’s a lot of work.  Use a container!

Create the container, add the pushbuttons.  I named my buttons Left and Right because their function is determined at runtime depending on the platform.  I add an Open event and in that event I add code like this:

#if TargetMacOS then
   
   btnRight.caption = kSave
   
   btnRight.Default = true
   
   btnRight.cancel = false
   
    
   
   btnLeft.caption = kCancel
   
   btnRight.Default = false
   
   btnLeft.Cancel = true
   
#else
   
   btnRight.caption = kCancel
   
   btnRight.Default = false
   
   btnRight.cancel = true
   
    
   
   btnLeft.caption = kSave
   
   btnRight.Default = true
   
   btnLeft.Cancel = false
   
#Endif

The kCancel and kSave are dynamic constants holding the proper strings.  In the ActionEvent of the buttons I have code like this to raise an event to tell the parent container (a window or another container) what happened:

Sub Action()
   
   //btnLeft
   
   #if TargetMacOS then
      
      //Cancel
      
      RaiseEvent Action false
      
   #else
      
      //Save
      
      RaiseEvent Action True
      
   #Endif
   
End Sub

Sub Action()
   
   //btnRight
   
   #if TargetMacOS then
      
      //Save
      
      RaiseEvent Action true
      
   #else
      
      //Cancel
      
      RaiseEvent Action False
      
   #Endif
   
End Sub

And finally the Action event which I’ve defined is:

Event Action(bSave as boolean)

It’s really as simple as that!  No matter which platform I’m on the Action event from this container tells me if the user pressed save or cancel.

Why did I include Containers in this article?  Good question!  It’s because you can think of Container Controls as a way to subclass Windows or WebPages without it being a window/page.  You can reuse Containers as many places as you want and when you change the original it changes the children (be aware though that there are some caveats with this statement – especially with WebContainers).  And even better is that you can dynamically add and remove containers at runtime.  Adding them is simple by using the EmbedWithin commands and to remove them use the Close method (I always set their visibility to false first).

We use a LOT of containers in our consulting work.  We find that it tends to simplify the code (remember being a lazy programmer isn’t a bad thing).  We’ve had windows/pages that have thousands of control and hundreds of controls visible at any given time but with a UI that complex we like to break them out into Containers.  So rather than having a Navigator with a listing of thousands of controls (and their labels!) we break it out logically into containers and the Navigator has maybe a dozen containers instead.

Each container has Save, Load, Validate set of methods (sometimes this is using an Interface) and whatever other methods are required but the point is that the overall window/page doesn’t need to know, or care, what the individual controls are and how to load, save, and validate their data – it only has to know enough to call the Load, Save and validate methods in each container.

With Xojo for Web, containers are even more important because you can create ‘repeating rows of controls’ that are very complex.  We wrote an entire accounting application for a client in using Xojo for Web and as you can imagine creating an Invoice Line Item row that needs Qty, Price, Amount, Sales tax and the necessary UI to add and delete the row, void a row, make it non-taxable can be complex.  Sure, we could have come up with a UI that doesn’t have that in a list, but frankly, it’s not that hard using WebContainers.

Containers are very powerful things and a great way to combine controls into one unit.  It’s also a way to create a dynamic control that can easily be added a runtime.  Rather than using a ControlSet (i.e. control array) and cloning an existing control (and having to keep track of the index) you can dynamically place your container that holds your one control.  We don’t use this technique very often but it does come up every now and then.

Conclusions

Subclassing a control in Xojo is pretty easy but sometimes overkill.  Using the extends method works great if you’re adding methods to a class/control and don’t need to add any properties.  Containers are powerful constructs that let you combine controls into a reusable object that have their own events and that can be added dynamically.  As a Xojo programmer you should be familiar with all three methods.

Did I forget anything?

Xojo vs Xamarin

AndroidLast week when I was the guest speaker on Xojo’s webinar on consulting, I fielded a question regarding Xamarin.  The basic gist of the question was if I felt that Xamarin was a threat to Xojo.  At the time I had heard of Xamarin and read a few articles on it but that was about it.  In the week since I’ve been doing more research on the topic.

Xamarin is an interesting development tool.  To sum up what it is in a sentence or two probably does it some injustice but here’s my take.  Xamarin takes the C# language and .NET framework and has ported it to Mac OS X, iOS, and Android.  This allows developers to use the Visual Studio IDE on Windows, and Xamarin Studio users on Mac OS X and Linux to create native Mac OS X, iOS, Android apps, in addition to Windows desktop and Windows Phone apps.

I threw Mac OS X in there since it’s listed on their website but it appears to more of an afterthought since the focus seems to be on mobile applications.  Indeed, their mantra is that they want to make the best development experience for mobile applications.

I am not a C# developer but like most modern languages it’s not the language that’s difficult to learn it’s the framework and .NET is arguably one of the biggest and most advanced frameworks around.  Having the .NET framework available for iOS, Android, and Mac OS X is a huge advantage for anyone already familiar with it.  Theoretically it should make the transition from Windows developer to cross-platform developer very easy.

Xamarin uses native platform user interfaces and compiles to native applications for each supported platform.  This is good in that you get the best of each platform.  The not so good is that it appears that you’ll end up coding each user interface separately (see Xamarin.Forms later on).  I can see the arguments going both ways on this whether this is good or bad.

Unlike Xojo, Xamarin does not have a built-in forms editor.  They give the option of building Cocoa and Cocoa-touch applications strictly via code or by using Apples Interface Builder.  You either stay in Xamarin to build everything via code or you exit to Interface Builder to design your UI.  I can’t imagine that’s very efficient but Interface Builder wasn’t always integrated in Xcode either.  As a developer you have to roll with the punches.

The Xamarin framework has some cross-platform calls to make life easier, but when it comes to iOS and Mac OS coding it appears that most of it is similar to Xojo’s ability to make declares into the native OS.  Again, you might call this a strength as you get the Apple methods but it also means that you’ll need to know each target OS in detail which can be a rather large learning curve.

Xojo abstracts as much of the platform as possible which means that a TextField on Mac OS has mostly the same capabilities as a TextField in Windows and Linux.  The strength in Xojo means that you don’t need to know the details of each platform but it also means that you generally get a compromise in functionality.  This is where system declares can really aid the Xojo developer.

Web Presentation

Xamarin’s website is gorgeous.  Nearly everywhere you go there are very helpful tutorials and videos explaining how to do things.  It’s also laid out in such a way that you can quickly find things.  The Xojo website is okay and relatively easy to find things but Xamarin goes out of their way to convince you to use their development tool.

The tagline on the Xamarin home page is “Create native iOS, Android, Mac and Windows apps in C#.  Join our community of 687,765 developers.”  Practically everything about the website screams, “Use me and you’ll make a great applications!”  It’s very professional looking and it’s all business.

The tagline on the Xojo website reads, “Create powerful multi-platform desktop, web & web-mobile apps.  Fast development.  Easy deployment.”  It’s not that Xojo doesn’t attract professional developers but their emphasis is on different things.

One thing that surprised me quite a bit was under the Support/Consulting Partners menu of the Xamarin website.  It’s a listing of Xamarin consultants and they are listed by tier (authorized or premier), by geographical region, and by expertise.  The Xojo website has the Find a Developer page.  The first says that it’s a serious language with a lot of software development partners and the other says that it’s a smaller community.

IDE Comparison

The Xamarin IDE is fairly simple and seems to be a hybrid between Xojo and Xcode.  Their Solutions pane is not nearly as complex as the Navigator and is far simpler and easier to use, in my opinion.  The Solutions list only shows objects unlike the Xojo Navigator that shows everything (methods, properties, constants, enums, etc) as you drill down into the object.  As you select an object in the Solutions list the source code editor loads all your source code.

If I had a major beef with Xojo is that they try too hard to dumb down the IDE.  You can’t just start typing away like you can in practically every other language/development environment I’ve ever seen.  Instead, you are forced to add methods through the Xojo UI.  You’re forced to do the same thing with properties, events, constants, enums and so on.  While this is great for people just starting out in Xojo it’s a limiting factor for more experienced users and forces you to use the mouse – a lot.  This means you can only see one method at a time unless you open up multiple windows whereas the Xamarin source code editor shows you everything in the source code.  Method definitions are defined via text in the code editor and not by a specific user interface.

Xamarin has the prerequisite autocomplete in the source code editor and appears to be work roughly the same as Xojo’s.  One thing that I REALLY liked about Xamarin was a tool tip showing you what the current parameter was.  As the user types the code editor recognizes where it is and provides a tool tip with a hint on what it’s currently expecting for the parameter.  This was one of my favorite features from VB6 and sadly, Xojo’s source code tip is an antique by comparison.

Xojo has a built-in forms editor.  Not only that but it has a reports editor, menu editor, database editor, as well as specific editors for a bunch of one-off items.  Xamarin shows objects and source code – that’s it.  So this forces you to either build all the UI via code or via an external editor.  While the Xojo editors aren’t perfect they are there and easy to use.

If you purchase the Xamarin Indie subscription (or better) you can use the Xamarin.Forms module which allows you to build iOS, Android, and Windows Phone screens from a single code base and it should speed up development.  However, I think Xamarin faces similar hurdles to Xojo in that a bug in their framework requires a new release so it’s no panacea.  And, you still build the UI via code not through a GUI editor.

Pricing

Xamarin comes with four different subscription options.  The Starter Subscription is free and is good for individual developers and allows you to deploy Android, Windows Phone, and iOS apps to a device and to their respective app stores.  Apps are limited in size and you are forced to use the native UI builders.

The Indie Subscription costs $299 per year, per developer, per platform.  If you were interested in iOS, Android, as well as Mac OS X this would cost $807.30.  Apps are unlimited in size and can use Xamarin.Forms.

The Business subscription costs $999 per year, per platform, and per developer.  This gives you Visual Studio support, “business features”, and email support.  The same Android, iOS, and Mac bundle jumps to $2,697.30.

The Enterprise subscription costs $1899 per year, per platform, and per developer.  This adds Prime Components (pre-built UI assemblies), guaranteed response time of a day, hot fixes, an individual manager, a bunch of support and code troubleshooting options.

Xojo pricing is much simpler by comparison.  $99 for an individual platform license with a $99 1 year renewal.  $299 for all desktop apps (Mac, Windows, Linux) with a $150 1 year renewal.  $399 for web apps (running on Mac, Windows, or Linux computers) with a $200 1 year renewal.  $999 gets the Pro license which gives you all desktop, web, database server, and console/service apps, consulting leads, and beta program access and the 1 year renewal is $500.  The Enterprise license at $1,999 is everything as Pro with an additional day of custom training and the 1 year renewal is $1,999.  All of the licenses are for a single developer.

Xojo is considerably less expensive but the Xamarin pricing is inline with what professional developer organizations are used to paying for their tools.

Conclusions

If I were a C# developer I would be all over this product – especially if I wanted to my apps running on non-Microsoft computers and devices.  I believe this is where many of the nearly three quarters of a million developers are coming from.  I’m sure there are plenty of other developers that were tired of developing their mobile apps on one or possibly even three separate development tools too.  Xamarin makes the development process easier  by using a single tool.

Xamarin is really pushing mobile app development.  Based on the forum activity I suspect that Mac OS X isn’t in the limelight but because iOS is so similar I can see why it was added.  It’s another notch in the capabilities checklist for a growing tool and user base.  If you can do all of your development with one tool why wouldn’t you?

Xojo really isn’t competing in the same space as it’s for only desktop and web applications (an iOS version is currently in alpha testing and should be released this year).  Xojo has been doing cross platform desktop and console applications for nearly two decades and has transitioned through 68k, PPC, and Carbon to Cocoa on the Apple side as well as all the Windows and Linux variants and versions.  Web apps are relatively new but the framework is very much the same as the desktop side.

From what little we’ve seen of the iOS version (remember that it’s in alpha testing right now) it has a built-in forms editor and uses pretty much the same framework as the desktop and web (with specific differences, of course).  It promises to make developing for iOS extremely easy.  However, Xojo has no current plans to support Android or Windows phone.  This might be the one key difference that might make Xarmarin an attractive development environment for many.

Will this consulting company be switching from Xojo to Xamarin anytime soon?  No.  The cost of migrating to a new tool, retraining, and getting involved with consulting in a new environment is considerable.  If Xojo went away tomorrow I know which tool I’d look at first.

Lessons Learned The Hard Way #1

This seems like a no brainer, but we’ve been bitten by it and we’ve picked up the pieces of multiple projects from others who haven’t lived by this rule:  If you’re creating a cross platform application, test early and test often on the platform you’re NOT developing on.

Real Studio is a cross-platform development tool.  It runs on Mac OS X, Windows and Linux.  In the Professional/Enterprise versions you can build for other platforms and debug on the other platforms as well while staying your native environment (using remote debugging).  It’s really an awesome experience running Real Studio on the Mac and running the executable via VMare (or even on another machine in the office) running Linux or Windows.

We see it time and time again (and we’ve been guilty of it ourselves a time or two) where someone does all their development on Mac OS X and tests on Mac OS X but their app looks awful once they get it into Windows.  Text backgrounds looks like crap and the flickering is atrocious whenever they resize the window or move controls around at runtime.

The reason?  Mac OS X and Linux have double buffered windows while Microsoft Windows does not.  Mac OS X and Linux always draw to a buffer first and then draw to the screen.  Windows does not which is the cause of much flickering.  Real Studio has some easy workarounds for a bulk of the flickering and some simple rules of thumb to reduce, if not eliminate, Windows flickering issues.  Among them:

  • Canvas objects should have Double Buffering turned on
  • Do not erase the background of Canvas and Container Controls
  • Be wary of using Refresh – perhaps Invalidate is a better choice
  • Layering of controls will almost always get you into trouble.  Putting anything over a Canvas control (that draws anything) is almost a sure way of getting into trouble

So the lesson is that you really should be testing your app in all of the environments you plan on supporting early in your development process.  If you wait until you’re about ready to ship it’s too late.  You might have some fundamental assumptions in the project that’s hard to fix now that you’re almost done.

Cross platform development is easy using Real Studio, but that doesn’t mean there aren’t differences.  You need to test for those differences early and on a regular basis.

Since I spend most of my time on the Mac side I’m assuming Windows and Linux RB developers have the same issues going to the other platforms.  What are some of the issues you see?  Did I miss any reasons for Windows flickering?

Visual Studio For the Mac?

Interesting little blurb at http://blogs.barrons.com/techtraderdaily/2010/05/26/apple-will-steve-ballmer-show-up-at-the-wwdc-keynote/ about Microsoft presenting at Apple’s World Wide Developer Conference (otherwise known as WWDC) to show off Visual Studio for iPad/iPhone and general Mac OS X development.

Geeze.  How many levels of wrong is this rumor?  You think Apple is going to trust Microsoft with the keys to their iPhone/iPad kingdom?  I don’t think so.  Apple has worked too hard building xCode and Cocoa Touch to let a 3rd party develop for iPhone/iPad.  If this does happen, then Apple might as well give Adobe a call and let them know they can restart their iPhone/iPad programs too.  And we all know where that feud isn’t over yet.

Where this might make sense is desktop applications.  Microsoft, while doing all that work to write Microsoft Office for the Mac in Cocoa, wrote their own Cocoa libraries and other Mac GUI editors and put it into Visual Studio.  Seems like an awful lot of work with minimal gain for Microsoft unless they’ve decided to make a push in REAL Software’s corner.  They certainly have the knowledge and resources to do such a product.

While I don’t think this rumor has legs it does make you think.  No doubt Microsoft is feeling the pinch of developers learning Cocoa which does nothing for Microsoft.  If they developed a cross-platform Visual Studio it stems the bleeding because now developers don’t have an either/or decision to make.  Learning a new development tool and frameworks suck and letting all those Windows developers develop for Mac and Windows using their tool keeps Microsoft in the game.  It doesn’t help them with iPhone/iPad development (now) but in five years who knows.  If it does happen it will generate some serious buzz which is something Microsoft wants (needs?).

What does this do, if true, to our favorite development tools company located in Austin?  I don’t think it would be good news.

Cocotron

More info on Cocotron can be found at http://www.cocotron.org/.  Their stated goal is:

The purpose of the project is to provide an easy to use cross-platform solution for Objective-C development.


There’s a blog post at Mac Daddy World at http://macdaddyworld.com/2008/10/27/adventures-in-cocotron/

Now I can say with some certainty that xCode and Objective C isn’t as easy to learn and use as REALbasic but a programming language is a programming language and we can all learn “one more” language and IDE.  Certainly one of the truths about REALbasic is that all of it’s controls are a compromise and not as feature rich as their .NET and Cocoa brethren.  Cocoatron has the potential of changing some minds of people who might be looking at REALbasic and go with Cocoa if controls on both platforms are nearly identical.


It seems that Cocotron isn’t an officially supported Apple product but that might not matter in the long run if enough developers start using it.  Stranger things have happened in other platforms where something becomes a de-facto standard.  It wouldn’t surprise me either that Apple has a skunkworks project that does this as well so it’s possible that at any point Apple could go, “Because of demand, here’s the official Cocoa for Windows frameworks.”


One major issue I see with Cocotron is that you can only do code development on the Mac.  That is certainly one of RB’s strengths where you can run on Windows, Linux or Macintosh OS X and compile and debug for the other platforms (Pro editions only).


One thing that is similar to RB is that it looks like you can debug your Windows app while running in the xCode IDE.  I wonder how fast or slow that is?  I might just fire up xCode this weekend.

Your thoughts?