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.

Thoughts on Xojo Web Edition

When Web Edition for Xojo (then Real Studio) was released I can’t say I was overly impressed.  It was missing some features and was buggy (to put it mildly).  I was of the opinion that it just wouldn’t take off.

Since then the worst of the bugs were fixed and the worst of the framework problems were addressed and there’s been a steady improvement in the product in practically every release.  In my consulting business it’s went from being a ‘gee that’s a nice thing to have’ to being roughly half of our overall Xojo consulting business.

The fact that we had very little web development experience hasn’t stopped us from using Xojo for a lot of projects.  It’s great that a WebButton and a regular desktop Button and that a WebPage and Window act the same from a developer standpoint.  All the code experience that we learned over the course of a decade in desktop apps was, with a few notable exceptions (*cough* constructors *cough*), was immediately transferrable to web apps.  While there is a learning curve it’s not like we had to learn a completely new programming language to do some large and complex web apps.  In fact, we turned down work before Web Edition came out simply because we didn’t have the experience and in-house know how to do the work.

Our clients seem willing to forgo the numerous capabilities and power of a desktop app for the more limited capabilities of a browser based app.  I think the biggest reason being that web apps don’t have distribution issues.  There’s only one instance of the app sitting on a server somewhere.  Web apps also work in almost every desktop browser and even work with most mobile web browsers.  Heck, you can even configure the web app to look different based upon what device it’s being viewed on.

There are some disadvantages, of course, to Xojo web apps.  You can’t just put them up on any ol’ server.  You pretty much need a VPS or use the new Xojo Cloud (which is just a specially configured VPS).  Then you have to worry about 32-bit compatibility libraries but, honestly, once you get the first app running on a server the rest of them are pretty easy.  I’ve not had the pleasure of getting a Xojo web app working on IIS but I hear it’s not a pleasure, nor quick, experience.

Apps running in a web browser have a limited subset of capabilities. With Xojo web apps you can’t use drag and drop anywhere out of the box (I think you can do some of this with JQuery but I’ve not tried yet).  The controls, particularly the WebListBox, are lacking a lot of functionality, and there’s just not a wealth of 3rd party controls available for Web Edition yet.

Security-wise, Xojo web apps are compiled making it very hard to compromise an app even if a hacker gets into your server.  There’s still work to make your app secure from SQL injection attacks but that’s a relatively simple thing.  Much of the work is really securing your server so that it’s secure and that’s one thing that Xojo Cloud is doing well (perhaps too well based on my recent experience).

So the question, Dear Readers, is what are your biggest likes and dislikes about Xojo Web Edition?  What do you wish it did better or differently?

JavaScript Error (or Banging Your Head Up Against a Wall)

In one of our big Web Edition projects I recently added a new dynamic WebContainer option to the home screen.  It generated a JavaScript error on occasion but because it was under active development I wasn’t too worried about it.  Sometimes those errors fix themselves given some time.

I figured that I was doing something to a control before it was being shown.  I went round and round with the bug adding timers to add delays and changing the order of when things were shown.  It was really bugging me and I even contacted Xojo support because it was happening on the Xojo Cloud server during the alpha period but yet I was seeing different behavior on my VPS host.

Eventually, we really looked at the javascript error:

document.getElementById(‘EK7iZlsZ’).style.overflow = ‘hidden’;

If you go into the Web Inspector in Safari and in the console paste in document.getElementById(‘EK7iZlsZ’) it resolves to a Style.  It was confusing because that style is used everywhere and all styles are static meaning that I’m not replacing or changing that style on any control, anywhere in the project.  We all assumed it was an order issue with the web framework.

The bit that finally tipped us off to what the real problem was the ‘style.overflow’ part of the JavaScript error.  That is NOT visibility of a control, that’s the JavaScript for ScrollbarsVisible and it’s a property on all WebContainers.  This is the property that will let you change how scrollbars work on the WebContainer.

Of course, once we knew what the error was it was trivial to change it.  The line of code I had in an initialization routine of the WebContainer was self.ScrollbarsVisible = 2.  As soon as I moved this to the shown event the problem went away.

If you are a heavy user of WebContainers this might bite you at some point in the future.  Perhaps you’ll remember this blog post and remember how you thought Bob was a silly old programmer for missing something so obvious.  🙂

Gotta love hours and hours of work for moving one line of code.  Of course, along the way things got more efficient and I removed a bunch of time delay code that was no longer needed.  I love programming some days.  Now to repair the dent in wall from banging my head….

Xojo Developers Conference 2014

Geoff Perlman of Xojo gave the keynote address at the Xojo Developers Conference (XDC) today.  In his hour long talk Geoff talked a lot about Xojo Cloud and a little bit about the upcoming iOS version of Xojo.

This years XDC sold out and attendance was up over 16% over last year.  Attendees represented 14 different countries and over half were first time attendees.  Early on in the presentation Geoff acknowledged over 20 attendees that have been using Xojo since version 1.0.  He also presented Marc Zeedar (of Xojo Developer Magazine) with having attended every single conference.

Geoff then went on to acknowledge that the name change from Real Studio to Xojo has gone well.  There is one issue in that a sports drink made it to market about the same time with the same name.  The two separate companies are on friendly terms and on Friday all of the attendees will get a bottle of the sports drink.  This may or may not be a good thing on a Friday in Las Vegas.

Xojo Cloud

Xojo Cloud has now been released.  It has a number of benefits including zero configuration, one-click deployment, no maintenance, and better security.  The latter issue is incredibly huge since Xojo discovered that it takes about 15 minutes for a brand new server on the internet to get its first unauthorized access (attack).  With Xojo Cloud the servers are automatically configured with security in mind.

In the long run anyone creating web apps does not want to be a security expert.  However, those developers should be, so the security focus of Xojo Cloud is worth the additional cost.  Xojo admits that it is not the cheapest host, but it doesn’t take too much of your time doing configuration and maintenance on your (non-Xojo) server to make up the cost difference.

Xojo is paranoid about security and this is a good thing.  It was during XDC 2013 that their servers got hacked.  They feverishly moved all their backups into the Xojo Cloud servers.  Since then there have been no infiltrations (that they know of) in over 15 million scans.  When they reviewed their security with RackSpace (their server provider) who told them, “Only our most paranoid customers have this much security.”

Framework Changes

Parts of the Xojo framework have been been around for 15 years.  In that time Xojo has supported Mac OS 68k and PPC, Windows x86, Linux, Mac OS X, Cocoa, and Web (to name a few).  Obviously there are a few areas of cruft that have crept in and there are inconsistencies in the API.  Add in iOS, ARM, 64 bit, and LLVM and Xojo has some serious issues in the framework.  Thus a new framework is in the works.

The existing framework (classic) consists of the desktop and web.  Each of these sits on top of the console framework.  The console framework consists of non-ui items like FolderItem, TextInput/OutputStream and BinaryStream.

With the new frameworks there will be framework namespace for each platform (desktop, web, iOS) and will contain things that are specific for each.  For common elements (like buttons) these will live in the UI framework that lives underneath the platform frameworks.  The ultimate goal of this change will be copying common UI from a desktop app and pasting them into a web app the controls will just work with no problems.  This can’t be done now as the desktop and web controls have separate frameworks.

The new framework will arrive first in console, then web, iOS (initially it will have its own version of the new framework), and then finally desktop.  My advice is to not stress out about this until more information is known.

iOS

The big news of the day is that iOS is very close to being sent to alpha users.  The current schedule (always take schedule news with a grain of salt) has the alpha shipping in May with a beta in June and hopefully shipping to end users in the third quarter of 2014.

Pricing will be $400 for those users that want iOS only.  Pro licenses will go up $200.

Geoff did an initial demo with the iOS application running in the iOS Simulator.  This is similar to things we’ve seen before.  What was new, however, was that Geoff did a final build, used Apple’s Configuration Utility and ran the demo app on an iPhone and an iPad.

From this evidence it seems that work on the LLVM and ARM compiler is well advanced.  Built iOS apps are currently only 32 bit.

Another interesting tidbit from the demo was that Auto Layout is in full force in iOS.  Auto Layout is a super advanced way to handling automatic layout for windows, views, containers, etc. and is much more advanced than the simple locking properties.  This should really help in localization.  Other than the quick aside in the demo there was not much said about it.

All-in-all the keynote was fairly quiet.  Not a whole lot of new information was given out.  Ta ta for now and if I find out more information I’ll share it with you.

 

Container Control Love

We are big fans of Container Controls for a lot of reasons.  Containers, in my opinion, are one of the most powerful tools in Xojo and they are often misunderstood and under used, in my opinion.

Complex UI

Complex UI

In the first picture you see a very complex layout.  The client only wanted a single window for everything.  Each item in the family list is its own container.  Each of those containers has a tab control and you can see a fairly typical layout.  In almost every case each of the tabs has its own container as well.  The project takes it to the extreme but adding these dynamically is really fast.

Screen Shot 2014-02-15 at 2.06.15 PMThis project was a conversion from VB6 and everything really was in one window.  It was a nightmare to debug and in the process of converting it and breaking it apart into containers we found numerous errors they had never been able to find due to the shear amount of code in this one window.  To load the container we simply create a new instance of one (if it doesn’t already exist), give it the database file and the container literally does everything else.  The Xojo window has about 200 lines of code for everything.  The old VB6 window had over 10,000 lines of code.

Containers let you create really complex UI layouts and treat it as a single entity.  I see this a lot with projects with tab controls where each tab has 30 controls on it and you have 10 tabs.  That’s a LOT of controls and logic to load and save the data to them.  What we do is create a container for each tab and the container has the load, validate and save logic.  Then we place the container on the tab control or page panel.

Doing things like this does a couple of things for us.  First, it makes the coding of the Window very simple.  Instead of having 300 controls you have 10.  When the Window is opened or when the user presses the tab to expose it to the user we tell it to load the data (this is where using ActiveRecord comes handy).  The window itself doesn’t know or care about the individual controls.  So all the code for the container is where it makes the most sense – in the container.

The second thing this does is simplify what the IDE has to display.  I’ve made no bones about it that I do not like the Xojo Navigator.  The more objects you have in it the worse it gets.  Finding stuff is hard and I find it to be a royal pain.  Using containers reduces this issue.

The only real drawback to using containers at this point is that they draw really slow in the Layout Editor.  This appears to be addressed in the latest 2014 R1 beta but until it’s actually shipped you never know if it will get pulled for some as yet undiscovered show stopper bug.

Containers are also the only reasonable way to make repeating rows of controls.  Many people bag on Xojo for not having a powerful grid component but I think by using Containers you can do a lot of the same things.  To make a very sharp repeating rows control you need to have at least 4 different containers.  The overall container, an inner bounds container, the overall list of rows, and finally the row itself.  This is for desktop apps only since you can do the same thing in Web with only two containers.

Doing this type of repeating row control is not possible in carbon apps since the controls do not respect the container bounds but it works in Cocoa apps.  In Windows there is no issues but in Linux you need to use the new transparent property on all of the containers so the controls will respect the bounds of the container.  Xojo just did a blog post on this.

The drawback to the repeating row strategy is that you don’t want to have hundreds or thousands of rows.  Each container consumes memory and they can quickly make your UI slow and unresponsive.  At that point it’s much better to page your data so that your user can only see x number of rows at a time.  We usually settle on 50 as a nice starting point.

As I said earlier, Web Edition repeating row lists are even easier.  You simply add the container row to the container list and it knows to add a scrollbar.  It also knows how to scroll when the user uses the mouse scroll wheel.

One caveat about this is WebDialogs.  There is a super nasty bug in the framework where WebDialogs don’t get events like they should.  If your web dialog, and subsequent container, happens to be over a WebListbox and you try to scroll, the underlying listbox will receive the scroll events.  If you find this happening to you, you can try disabling the listbox.  Still, this bug sucks.

There is huge overhead using the EmbedWithin method in web apps.  Every time you use it the app has to serve up a new page and send it down the pipe.  I saw an example project the other day that had 50 rows and each row had 10 container cells on it.  With very little data and no style information it took almost have a second to display the repeating list in the browser on the same machine.  Add some additional time going over a slower connection and your app looks slow and unresponsive.

The answer for now, is to not do that.  The performance of the embed within command is simply too big to use it a lot.  We had one largish web project where we used containers for each of our tabs and were adding them at runtime.  It was not good.  The lag time was simply too big so we ended up embedding the containers into the page at design time.  Now we take a little bit of a hit when the page is first displayed but the user doesn’t notice anything when they switch tabs.

If you are not using containers you really might want to look at them again.  They really are powerful tools.  With a little time and practice you can make your coding life easier while developing some incredibly complex layouts.

XDC Conference and Training Day News

Xojo sent out a notice to speakers this morning about due dates for session presentations for the Xojo Developer Conference.  You don’t need to care about the presentation deadline but that’s just a reminder that I need to get my act together because not only do I have two presentations to prepare for BKeeney Software is doing an entire day of training before the conference (note to self, start talking to myself all day long to get voice in shape).

They passed along another nugget of information that I thought was interesting.  They only have 10 spots left!  If you’re thinking about attending the biggest Xojo developer conference of the year, NOW is a good time to register.  February 14th is the deadline for early registration.

Speaking of deadlines, our pre-XDC Training Day early registration ends on February 14th as well.  This years training day is more hands on then last year and we are getting attendee feedback ,when they sign up, about the topics they want covered.

The morning session is all about desktop applications and so far we have some great suggestions that include Containers are Your Friends, Reducing Windows Flicker, Preferences, Updating UI from Threads, Window Menus, Remote Debugging, Power PostBuild Scripting, and more.

The afternoon session is all about web applications.  Great topics here, so far, too.  Suggestions so far:  Basic Web Application Concepts, Web Security, Dynamic Web Dialogs, Sending Emails, Special URL Handling, Reporting, Containers are Your Friends, Communicating with Desktop Apps, and more.

I think we have way more material than we have time but hopefully we can help some developers with their particular questions.  Our entire team will be there so we should be able to show some love to everyone.  Each attendee also gets a complimentary 3 month subscription to our Real Studio/Xojo Training Videos.

I LOVE the Xojo developer conferences.  If I have not met you yet, please make sure you introduce yourself.  Maybe I can answer a question for you, or perhaps direct you to another developer that knows a topic better than I do.  You will find no bigger density of Xojo developers at any single gathering than this conference!  You can talk about Xojo all day long and well into the night.  Cheers!

2014 Training Day Early Registration Price Ends Next Week

Bob KeeneyThe early bird pricing for our 2014 Xojo Training Day ends on December 31st.  Save $200 off full price for our full day of training.

Join us in Las Vegas, Nevada on Tuesday March 25th (the day before the Xojo Developer Conference), at the Monte Carlo Hotel and Resort, as the BKeeney Software staff walk you through creating desktop and web applications using Xojo.  This is a great opportunity to ask questions about your own projects and project needs.  Join the BKeeney Software staff as we share our experience using Xojo (and Real Studio) for the past thirteen years.

More information can be found at https://www.bkeeney.com/xojo-training-2014/.  More information on the Xojo Developer Conference can be found at http://www.xojo.com/xdc/

Place a sure bet with BKeeney Software.  See you in Vegas!

Xojo 2013 Release 4(.1)

Xojo 2013 Release 4 hit the internets this week.  And they promptly pulled it after they discovered a crashing issue when it tried to verify licensing on their servers.  Release 4.1 was released today which fixes the issue.  As far as I know, it’s the only fix in 4.1.

I would characterize Release 4 as a maintenance release as it has several hundred bug fixes and just a few new items. I’m okay with this and if I had any say in the matter I would alternate releases with new features and bug fixes. One thing this release does NOT include is the Xojo Cloud that has been in development for over a year.  I expect Xojo Cloud will be released for the 2014 Release 1 (so it will probably go into beta soon).

The big change in this release is that the IDE and applications built for Cocoa require Mac OS X 10.7 (Lion) or later.  I think this is a pretty good move though it will make life harder for some.  Apple updates their OS regularly and many update their OS when they can because the upgrades have been safe.  I can’t find the statistics but it appears that a vast majority (in the neighborhood of 80%) of Mac users are on 10.7 and above now.  Obviously, if you have clients and customers that require 10.6 (Snow Leopard) you’ll need to stick with Xojo 2013 Release 3 (or continue building in Carbon).

New in Release 4 is new cryptography functions using the Crypto class.  The new class adds RSA encryption to the Xojo framework.  It has functions that allow you to generate public and private keys, verify the keys, encrypt and decrypt data, sign data blocks, verify signatures, and generate a random block of data.

For desktop users, the Canvas and ContainerControls now have a transparent property.  The default is true to maintain current functionality.  This change is particularly important in Linux as child controls on an opaque (not transparent) canvas or container control can be clipped.

The IDE can now use constants for the application identifier which can be useful if your application has multiple names or versions.

Release 4 has a ton of bug fixes and tweaks to the IDE.  This includes many fixes and changes to the Navigator and some of the copy and paste bugs that have afflicted the IDE since its first release.  It’s still not perfect, but it’s getting better.

Better is subjective, of course, but one of the bigger annoyances to many users (including me) is that changing text values in the Inspector (such as a control name) didn’t actually stick unless you tabbed out of the field.  This has been fixed and just this one change alone is worth getting and using Release 4.

There are a few debugger changes that are worth mentioning.  First, the debugger now catches exceptions raised in computed properties.  Before it wouldn’t, which could cause navigating in the debugger to actually change the control flow of the program.  Second there are some specific fixes to the debugger for Windows and Linux users, and finally a new DebugIdentifier property was added to the Thread class to make it easier to debug code that’s running in a thread.

One item of note that came through late in the beta cycle.  Several developers had issues with rejections from the Mac App Store (MAS) due to using QuickTime API calls (or the framework linking to them).  It appears that Apple, while only deprecating QuickTime in Mavericks, is actively rejecting apps that use it.  Release 4 no longer links to QuickTime but according to the Beta list testers this is still an issue.  In my opinion, this is more an issue with Apple, suddenly and with little warning, rejecting MAS submissions than it is Xojo doing anything wrong.

While I like Apple, sometimes getting apps into their store is like hitting a moving target.  Apple giveth and Apple taketh away.  <insert favorite negative Apple cliche here>  If you know more on this, please add comments below.

What are your thoughts about Release 4?  Are you happier with the IDE after 4 releases than you were initially?  Are you looking forward to Xojo Cloud?  What about the eventual iOS support?

[Edit:  Changed wording on the debugger changes for computed properties so it was more accurate.]

Network Link Conditioner

If you’ve been using Xojo Web Edition for any length of time you’ve probably run into this problem:  You code your app and debug it on your local machine and you’re very happy with it but when you put it on your web server it’s slow, unresponsive, or generates some random javascript errors.

Welcome to web app programming.  What’s happening is that on your local machine there is, for all practical purposes, zero latency between the browser and the application.  You can do amazing things wish no latency issues.  I once had a working D&D Mapping helper for Dungeon Masters that used drag and drop on a web page.  That is until I put it on the web server and then it practically ground to a halt.  The end result is that it was a very hard lesson to learn (thankfully it was a ‘for fun’ project).  Drag and Drop in a Web Edition application really doesn’t work due to this latency (not even sure why the events are even there).

Latency is an issue all web apps have to deal with and since Xojo apps do nearly all of their processing on the server this can be of particular concern.  Short of putting the apps on my web server there wasn’t a lot I could do to test this until I found out about The Network Link Conditioner for Mac OS X.

Screen Shot 2013-12-14 at 5.32.53 PMThe Network Link Conditioner is available through Xcode and allows you to simulate network conditions on your Mac as if you didn’t have the super speedy connection you really have.  It’s quite instructional to do this.  You can simulate speeds from Edge, DSL, 3G, Wifi, and Cable Modem with varying degrees of lossy conditions in the wireless options.

To get The Network Link Condition open up Xcode and select the Xcode -> Open Developer Tool -> More Developer Tools and log into your Apple Developer Account and in the Downloads area search for Hardware IO Tools for Xcode.  This package includes a number of things, including the Network Link Conditioner preferences pane.  Download the disk image and mount it.  Simply double click on the Network Link Conditioner prefPane file and the Finder will install it in your System Preferences panel.

Then it’s simply a matter of starting it and selecting the network type you want to test against.  This tool is very cool and I highly recommend it if you are developing for Xojo web applications.  What it will show you is how slow your app is over these types of network connections and will most likely show you where you need to do some optimizations.  Perhaps you need to preload some things on your first page so they’re slower later on.

In one of our current projects we were loading a number of WebContainers dynamically.  This made sense since we felt we didn’t want to load everything when the user logged in and only load the container when they selected it.  This was great but this made the initial selection of the user slow as the server had to create the objects and then push them down to the browser.  The perception was that the app was very slow.

Of course, during development on our local machine we never saw that issue.  Everything was fast and speedy.  But when we started using the Network Link Conditioner we could see it rather well.  We also were able to replicate a few sporadic javascript errors that only occurred on the server (doing things in the WebContainer open events is bad too).

The solution was to load the pre-load containers when the user first logs in.  It takes longer at first, but when the user makes a selection the app has to only issue visible commands to the browser which is very fast.

A word of warning is in order.  Remember to turn Network Link Conditioner off!  It’s easy to forget that it’s on.  If you forget, though, your entire machine will seem slow if you’re doing anything over the network or internet!

What other tools and tips have you found for helping you debug your web applications?