The Xojo Community is Awesome

Have I told you how much I love the Xojo community?  I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more.  I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product.  It’s a big deal.  Really!

If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey.  Programming is hard.  Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard.  Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.

Even Xojo pros, such as myself, have need of help.  Xojo covers Mac, Windows, Linux desktop, console, and web apps.  It does iOS apps for iPhone and iPad.  It now does Raspberry Pi for heavens sake!  It works with dozens of different databases.  There is simply no way any one person is going to know everything there is to know about Xojo.  It just can’t happen.  So yes, I go to the forums, all the time, and ask for help.

Just the other day I asked for some help with WooCommerce.  Not Xojo related, really, but certainly related to a project we’re working on for a client.  Within a few hours I had half a dozen developers private message me saying they might be able to help.  Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.

I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years.  I think I’d be hard pressed to find such a friendly community.  I call many on the forums my friends even though I’ve never physically met them.  The few that I’ve met in person have lived up to their forum reputations and are really friends for life.

So maybe this is my belated Thanksgiving post.  I am thankful that so many years ago I jumped both feet first into the tool.  I asked questions – many of the silly and redundant.  I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.

So if you are in need of a cross-platform development tool I highly recommend Xojo.  It ain’t perfect but no development tool is.  If you jump in I think you’ll love the community.  I know I do.

What say you fellow Xojo developers?

Shorts Report Designer Release 1.5.4

pens128We released version 1.5.4 of the Report Designer today.  One of the bigger changes is it ships with a web example of how to take a report definition and display it for a web app.  This affects a significant amount of methods and properties throughout the project to make them work on desktop and web but seems to work well.

BKeeney Shorts (with report designer) is 100% Xojo code (DynaPDF Starter kit required to export to PDF) and comes with a drop in Report Designer and Report Viewer component for both desktop and web apps.

For purchasing information please visit http://www.bkeeney.com/allproducts/bkeeney-shorts/

Version 1.5.4 change list:

  • Major code changes to allow most classes to work in web apps too.
    • Simply copy BKS_Shorts_ReportDesigner folder into your existing web project.
    • Delete PAF_PrintKit.DesignCanvas (desktop ScrollCanvas subclass)
    • Create a new PAF_PrintKit.DesignCanvas that is a WebCanvas subclass
  • Changing text values in the Properties List is now Case Sensitive
  • Added Portugese Localization
  • Added a commented out example of how to connect to MySQL without using the winDBConnection Window.
    • See winRPTViewer.Display
  • Fixed an issue that would cause the SQL statement to not be saved properly in the JSON string
  • Added a Default Style if none is in the local dictionary
  • How reports are saved so they can be viewed without first having to be in the designer
    • WARNING! YOU WILL NEED TO RESAVE ALL OF YOUR REPORTS
  • Cleaned up some localizations and made some more strings dynamic.
  • Made the Report Designer the default pushbutton in Demo Window
  • New Report opens a new Report Designer Window instead of copying the current connection. (this affected menu handlers in odd ways one wouldn’t expect)
  • Created a Web Example

The Good, the Bad, The Ugly of Deploying Xojo Web Apps

It’s been a very busy first half of the year at BKeeney Software.  We’ve just finished up three medium sized web apps.  One was deployed to Windows Server, one deployed to a Linux web server, and the last to Xojo Cloud.  We’ve done a couple of small web apps to a Xojo friendly host too.  I will describe our experiences below.

Windows Server

The first project was a CRM project where we converted a really old MS Access and ACT! system to Xojo.  The UI wasn’t all that complicated but the data conversion was a pain since it was so dirty.  We ended up using a MySQL database server.

Since we didn’t want to go through the hassle of getting an IIS server we made the decision to deploy as a standalone app.  The hardest part of the whole installation was figuring out how to create the service.  We ended up using NSSM – the Non-Sucking Service Manager http://www.nssm.cc to create the service.  After that, installation and updates were a breeze by simply stopping the service, changing the files, and restarting the service.  We are able to VPN into the server and copy the necessary files over.

The server was virtual and running on a VMWare server.  Despite our specifications the server was set up initially with a single core (virtual) processor.  Performance all the way around sucked.  We complained, the client complained, and as soon as they upped it to dual core processors (as we specified) everything went smoothly after that.

Xojo Cloud

The second project was another CRM-type project though a little smaller.  It was using an SQLite database.  We converted the data from a FileMaker database.  The data was much cleaner and more straightforward so it was a relatively easy transition.

The client decided to host on Xojo Cloud so deployment is done from with the Xojo IDE.  The only file we didn’t deploy via the IDE was the database itself which we transferred via SFTP to the appropriate shared document directory on the Xojo Cloud server.

Xojo Cloud, for the most part, works flawlessly.  There have been occasions, however, where it fails to upload properly.  It’s a frustrating experience, to be sure, but Xojo customer service has always been able to fix it.  When it happens on a weekend you’re kind of out of luck.  Here are a couple of suggestions to try and get around the issue:  1)  Restart your server via the Xojo control panel.  2) Change the application ID of your application and try uploading again.

Linux VPS

Our third application has been around a while but we switched over from using SQLite to MySQL after our little db reached about three and half million rows in single table.  It still worked but some of the queries were taking *minutes* to complete.  The decision to move over to MySQL wasn’t a hard one.

You’d think that updating an existing app would be easy.  This one turned out to be anything but easy.  Since this one bites a lot of people deploying Xojo web apps to various Linux distorts it’s worth writing them all down.

  • Until Xojo web apps are 64 bit you’ll have to make sure the 32 bit compatibility libraries are installed.  Each is different so it’s ‘fun’ finding them.  Honestly, check on the Xojo forums to see what people have found.  Hopefully, this becomes a non-issue with Xojo 2015 R3 being scheduled to compile 64 bit apps.
  • Make sure permissions are 775 for all files and directories *including* the overall directory.  The latter one has bitten me more than once.
  • Make sure permissions for the config.cfg file is 664 or 666 (I’ve seen it both ways and I’ve never had a problem with either one).
  • Make sure the owner and group of the files matches that of the system.  If you’re FTP client shows owners/groups and it says something like “mixed” you’ve got a problem.  You’ll need to figure out how to change the owner/group on your own.  This may involved getting SSH access.  It may be easier to work through the CPanel File Manager to upload files because you’re guaranteed, then, to have the right owner/group.
  • Make sure the .htaccess file has been uploaded.  Since it’s a hidden file on Mac OS X it’s easy to miss this one.  If you zip the output directory and then upload the zip it will be there automatically.  If you’re zipping the contents of the directory don’t forget it!
  • Does the server have libicu installed?  Xojo 2015 R2 requires libicu and if you don’t have it your app will just crash with maybe an obscure error in the error log like “Can’t find missing file.”  I had this happen to me this week and when I reverted to 2014 R2 the app started up right away.  If you suspect you’re missing a library and have SSH access, try starting the app via the command line.  It will tell you what the missing library is.  You don’t always have SSH access so that’s kind of a drag.

Not really an issue with web app deployment, per se, but it’s an issue we deal with quite a bit.  MySQL on Mac OS X doesn’t care what the case is of a table or view.  tTable (mixed case) is the same as ttable (all lowercase).  On Linux and Windows this does not appear to be the case.  I know there’s a system variable that can turn this on or off but for this project the client had existing databases on the server and I really didn’t want to muck anything up on them.  Many queries that were running great on our local (Mac) system were not on the server.  Switching everything to lowercase isn’t a big deal (especially with ActiveRecord) but some db apps this will be a nightmare.  So don’t forget to test!

1701 Software Inc. http://www.1701software.com

We have deployed to 1701 Software several times in the past six months for ourselves and for various clients.  We’ve found their servers to be Xojo friendly from the get go (not so with most hosts) and their service is excellent.  They also offer a number of database options that Xojo Cloud does not like CubeSQL and Valentina in addition to MySQL and PostgreSQL.  Frankly, the fact that they are Xojo developers too makes them the top of my list of non Xojo hosting services.  Their prices are pretty good too for those that are price conscious.

That is our experience with deploying Xojo web apps in the past six months.  When everything works right it’s incredibly easy.  When it doesn’t – well, you tend to swear like a sailor.  Hopefully you’ll find this guide to be somewhat useful.  Anything I forgot?

Happy Coding!

[Edit:  Updated to not include an implied timeframe for the R3 release.]

Xojo iOS without Android

I will be honest and say that I did not think that Xojo for web apps was going to amount to much of anything.  Granted, I said this as I was struggling with a beta of the very first release to do some actual production work.  Since then it’s gotten considerably better and more stable and it’s become an increasingly large portion of our consulting work.

I was asked the other day what I thought about Xojo for iOS.  I replied that it’s stable and the community seems to be coming up solutions at a much faster pace than Xojo for web.  But until it starts bringing income into my consulting business I’m hesitant to say much more about it.

Let’s talk about that aspect of it for a bit.  When web came out I immediately landed a few consulting projects which was an awesome (and horrifying) way to learn the new framework.  Here it is roughly six months after release and I’ve only had a few nibbles but no actual projects on Xojo for iOS projects.  This despite the ten plus hours of training video I’ve created for Xojo for iOS.

So it makes me wonder if Xojo for iOS is really going to take off.  Part of me wonders if Xojo misunderstood the market for mobile apps.  Sure, iOS is where the money seems to be, but Android has the marketshare and Windows mobile (whatever they call it these days) just keeps hanging around.  Xojo simply doesn’t address Android or Windows mobile.

I think one could reasonably argue that part of Xojo’s strength on desktop is that it makes decent apps that are cross platform and it doesn’t matter which platform you develop on.  You do have to spend extra time for a Xojo app to be 100% compliant on Mac OS X and Windows (I’ll leave Linux out of the mix since I don’t cater to that crowd) and I don’t think many people would argue that if you were going to make a Mac-only application you might want to stick with xCode and Swift or Visual Studio for making a Windows only application.

Apple and Microsoft will always have the best gadgets and goodies for those platforms.  That’s just a fact.  Xojo is often a compromise of the lowest common denominator between the platforms.  It’s RAD capabilities are important but I’m not sure that I’d give it THAT big of an advantage once you get past the learning curve of all the respective platforms and languages.

Xojo for iOS is nice and works well but I feel that without Android it’s not going to get much traction.  Xojo is known for cross-platform apps yet it only supports one mobile platform.  If you were going to go the trouble of developing for more than one mobile platform wouldn’t you go with a tool that supported more than just iOS?

I mean no disrespect to Xojo.  They’ve accomplished a pretty amazing thing.  They have an IDE that allows you to create iPhone and iPad apps without learning Swift or CocoaTouch.  However, you are limited to developing on Apple hardware (that’s Apple’s not Xojo’s fault) and to do any remote debugging you have to use the iOS Simulator that’s part of xCode.  Just that part eliminates a good chunk of Xojo’s potential market (the Windows and Linux users).

Xojo for iOS works well.  It has good developer community support.  I see no reason why developers wanting an easier mobile development environment wouldn’t choose Xojo except for one thing:  It’s iOS only.

So what do you think my fellow Xojo users?  What do you think of iOS for Xojo?  Is it anything without Android and Windows Phone or is it missing something else?

Xojo Cloud Database Support

Last week Xojo announced new features for Xojo Cloud.  They now support MySQL and PostgreSQL database servers in addition to SQLite that they have supported since day one.  One of the interesting features with the database support is that db admin tools that support SSL tunnels can connect to the database as if it was running locally.  In my testing it was surprisingly easy to setup and use.

The first thing to do is log into your Xojo Cloud account control panel.  Then simply enable either the MySQL or PostgreSQL database and enable the SSL Tunnel.  In each case you will receive a username and password that you’ll need to copy before moving on to the next step.

Screen Shot 2015-02-26 at 10.28.25 AM

Our MySQL admin tool of choice is NaviCat.  Setting it up was pretty easy to do.  Create a new connection and then navigate to the SSH tab.  Enter your server IP address, the username and password.

Screen Shot 2015-02-26 at 10.32.30 AM

Then navigate to the General tab and enter a Name for this connection (I used Xojo Cloud).  Because you’re using the SSL Tunnel you need to enter ‘localhost’ into the Host field.  Enter your Xojo supplied username and password and then test your connection.

Screen Shot 2015-02-26 at 10.38.00 AM

After that, everything acts just as if the server were local to you.  In this example I created a sample database named ‘bkeeney’ and a table called ’t_temp’.

Screen Shot 2015-02-26 at 10.34.09 AM

Your Xojo web application, then, will connect to it via the localhost parameter along with username and password suppled to you from Xojo.  Because it’s inside the firewall your web app needs to do nothing more.

Setting up a database server in Xojo Cloud really is that simple.  It just works.  From start to finish it only takes a few minutes to get up and running.  It’s a great addition to Xojo Cloud.

Xojo Trainer Feb 2015 Update

We released an update to Xojo Trainer today.  We’ve added over 8 additional hours of Xojo Training video to our package.  This brings the total up to over 60 hours!  Here’s the complete list of new video topics:

iOS

  • iOS Walkthrough
  • 1.0 iOS App Object
  • 2.0 iOS App Icon and Launch Images
  • 3.0 iOSScreens and iOSViews
  • 4.0 iOSTextField and iOSTextArea
  • 5.0 iOSButton and iOSMessageDialog
  • 6.0 iOSCanvas
  • 7.0 iOSHTMLViewer
  • 8.0 iOSImageViewer
  • 9.0 iOS Primitive objects
  • 10.0 iOSLabel
  • 11.0 iOSSlider
  • 12.0 iOSSwitch
  • 13.0 Xojo.Core.Tiemr
  • 14.0 iOSSegmentedControl
  • 15.0 iOSTable
  • 16.0 Xojo.Net.TCPSocket

New Framework

  • 1.0 Xojo.Core.Date
  • 2.0 Xojo.Core.Dictionary

Web Edition

  • PictureShare project

These are the same videos that we’ve been streaming to thousands of Xojo developers for years at http://xojo.bkeeney.com/XojoTraining/.  Now you can view these videos and get the source code that comes with them offline at any time on your Mac or Windows computer.

We recently hit a milestone on our online Xojo Training – we’ve now streamed over 9,000 hours of video to users all over the world.  All of this via a Xojo web app!

For more information on Xojo Trainer, please visit http://www.bkeeney.com/allproducts/xojo-trainer/

WebSession.Quit

For years we’ve been doing some basic checking in the WebSession.Open event of our Xojo web apps. First, we check to see how many open sessions we have and if it’s over a preset number.  The second check we do is to see how many open sessions we have for the current IP address. We set it to something low like 10 because when some joker decided a few years ago to prove that Xojo web apps suck. He opened up our training app, and then hit refresh 150 times and then complained about how unresponsive the app was (thus proving his point that Xojo web apps suck, I guess).

In our apps, if either of those conditions is met we use a ShowURL to redirect to one of the webpages on our regular website to show the user that the app is either too busy or something bad happened. It’s worked decent enough that I’ve never revisited it until this past weekend when several users alerted me to the redirect never clearing. Since I couldn’t login to my own app I restarted the server and everything was fine again.

I tend to use a log file on my web apps to track certain conditions and this morning I added more information so I could track this more. I just happened to be monitoring the app (in my browser) when my session count spiked to around 50 in just a few seconds. Looking at the new information in the log file the IP addresses were all over the place.  An attack?  I dunno but it sure seemed like it.

Unfortunately, the session count didn’t go down immediately like I expected it too and, in fact, it didn’t go down even up to an hour later. I had over a hundred open sessions before it stopped (did Xojo Cloud security close the port?).

When that happened I started looking at code. Some of this code I hadn’t looked at in a year or more. Basically the code did the two checks in the WebSession.Open even and if the function returned true I immediately tried to call WebSession.Quit.

Guess what happens when you do that? If you guessed nothing you’d be wrong. It generates a Nil Object Exception first with the following stack trace:

Function WebSession._WaitingForSync() as boolean
Sub

WebPushHandler.CheckForChanges()

Sub _SessionShutdownThread.Event_Run()

And after that then it does nothing. The WebSession never quits – ever – until something kills the app.

My solution was to put a timer property into the Session and if I meets my quit conditions start the timer and in the action event (using AddHandler) quit the Session. Seems to work as expected now.

This is filed in Feedback <feedback://showreport?report_id=35794> and it appears that it’s been verified. There are some additional details on their response. They know why it’s happening at least. Let’s hope this one gets fixed sooner rather than later.

I’ve seen various people have issues with WebSession.Quit over the years. This might be the root cause of some of those.

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 2014 Release 2.1

Xojo 2014 Release 2.1 was released this week. This maintenance release is huge in several important ways.

This is the last version of Xojo that will build Mac Carbon apps. The upcoming changes to the framework for iOS and 64bit (and who knows what else) have made it impossible (or at least unfeasible) for the engineering team to keep supporting the Carbon framework. So long Carbon, we have to split up. It’s you, really, not me.

Since this will be the last version to support Carbon some nagging bugs were fixed in the Carbon framework. The hard crash that occurred when creating a new instance of the XMLDocument has been fixed. In addition a bunch of plugin issues for Carbon were fixed.

Cocoa apps that use RegEx will now pass submission to the Mac App Store.

For web app developers a big change was made to HandleSpecialURL that breaks everything that depended upon how the old, incorrect way, WebRequests were handled. I know this affects Web Custom Controls and it may also affect Studio Stable Web Essentials (unconfirmed). More info in a Xojo blog post at http://www.xojo.com/blog/en/2014/08/handlespecialurl-changes-in-2014r21.php

A few other web bugs were fixed. WebSession.Quit now properly clean and close the Session. A bug with WebContainer.EmbedWithin used in a open event (never a recommended way, if you ask me) that would cause WebLabels and WebLinks to offset was fixed.

There were several of database class changes too. SQLite now uses FTS4 with unicode61 tokenizer on Mac OS X. MySQLCommunityServer SQLExecute and Prepared statements no longer assume the statement is UTF8 encoded. The ODBCDatabase DatabaseRecord.Insert no longer inserts the wrong value.

As always, read the release notes for additional information and Feedback ID’s.

This dot release is critical for those developers still building for Carbon. iOS will (presumably) be out in Release 3 in at least beta form and the new framework is causing changes in a big way. I’m sure some of those changes will be subtle but some will be a smack to our collective faces.

To paraphrase Game of Thrones, “iOS is coming.” Sorry, couldn’t resist. 🙂

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.