HBO Now Less Than Satisfying

It’s my day off.  This is a non-developer post so if you’re expecting Xojo related stuff come back later.

I admit that we’re not typical television viewers.  We just don’t watch live TV anymore.  What we’ve gotten in the habit of doing is watching TV series on Netflix through our Apple TV.  All the joys of TV without the annoying commercials and we can binge watch two or three episodes at time whenever we want.

We’ve gone through the entire Star Trek universe (some twice with our two boys being such disparate ages), Sherlock Holmes, FireFly, Babylon 5 (when it was available for streaming), Doctor Who, Torchwood, Orange is the New Black, House of Cards, Battlestar Galactica, and many other series that are forgettable.

The point is that we pick and choose what we want to watch.  Yes, we have cable but it’s the bare bones minimum package.  Our city is one of the lucky places to have Google Fiber and we plan on cutting the cord and getting rid of cable entirely (assuming they ever wire up our neighborhood).  We don’t watch live TV now so why should I keep paying for a service we don’t use?  That money adds up.

When Apple announced that HBO Now was coming to the Apple TV I was excited.  Having a free month was a great incentive so I signed up and so far I’ve managed to go through several seasons of Game of Thrones but I am not impressed with the app.  Let me rephrase it:  I HATE this app.

The HBO Now app crashes – a lot.  In the span of an hour episode today, in the middle of the afternoon, it crashed six times.  I don’t know if it’s HBO, AppleTV, my ISP, or a combination of all three but it sucks and I cannot recommend that you purchase the service.

Every time I start the HBO Now app I feel like I’m rolling a saving throw and must get a 20 or it crashes.  Apparently the die is weighted wrong because I can’t remember a time where I started it and it just played with no issues.

I find the UI to be awful.  I’m watching a series.  It doesn’t remember the series (even though I’ve added it to my watch list) and there’s no visual indicating if I’ve already watched an episode or not so you end up hunting through episodes.  GOT has kind of a long intro and if you try to fast forward, guess what happens?  You increase your risk of crashing.  Want to throw subtitles on (because accents can sometimes be hard to pick out), guess what?  That also increases the chance of a crash.

So tell me why I’m paying for a crappy UI and an app/service that crashes all the time?  I expect better and if they want my money HBO will have to get MUCH better and soon.  If Netflix and Apple can stream video consistently, without any issues, why can’t HBO?

[Updated to reflect that it was the HBO Now and NOT HBO Go app that was crashing]

Converting FileMaker to Xojo And ActiveRecord

We are currently converting a FileMaker app to a Xojo web app.  We are about  3/4 of the way through the project and it’s been a surprisingly easy conversion.  Our biggest challenge has been normalizing the database since the original FileMaker developer did some things that were less than ideal.

Hal Gumbert over at Camp Software is starting a series of blogposts on their own transition from FileMaker to Xojo.  It is a recommended read.

One of the big things that many developers want coming from FileMaker and MS Access and other tools where the database is tightly integrated into the development tool is data binding.  It makes for a quick way to load/save data to and from the user interface.  We don’t do data binding and I’ll get into that a bit later.

In Hal’s blog post he goes into the various Xojo options and ActiveRecord is one of them.  I thought I’d spend a little time talking about ActiveRecord to fill you in on what it does.

ActiveRecord eliminates many common mistakes that developers have when creating database applications using Xojo.  How many times have you mistyped a table or field name in an SQL query?  We used to do it a lot and ActiveRecord eliminates much of it.  It does this by creating a NameSpace module and creating a class for each table.  The properties in those classes then map to the field in each table.

A register function for ActiveRecord uses Introspection to ensure you have all of the tables and fields from the database mapped in your classes.  If not, an assertion takes place in debug mode which tells the developer if they’re missing a table, field, or if a field is mapped to the wrong datatype.  This is very handy on large projects where you might be adding a bunch of fields to meet changing conditions and this way you definitely will not forget to add them to the ActiveRecord classes.

Creating the classes can be tedious especially with very large databases.  Our ARGen utility will help generate the classes for your by scanning your database and creating the classes for you.  For some this might seem backwards but we tend to design the database first and then code to it and we find that ARGen does 75% of the repetitive work for us by creating the classes and adding some shared methods to each class that help in queries and finding a particular record.

Once created, using ARGen is fairly simple.  To get a list of records in normal Xojo code you would create a query.  ActiveRecord does something similar using a class shared method.  Here is an example of using the List shared method to load a ListBox:



for each oCompany as Data.T_Company in Data.T_Company.List(sCriteria, sSort, iOffset)
   
   lst.AddRow oCompany.sCompanyNameCurrent,  _
   
   oCompany.sStreet1, oCompany.sCity, _
   
   oCompany.sStateCode, _
   
   oCompany.sZipCode, _
   
   oCompany.sCompanyStatusName, _
   
   oCompany.sAgentName, _
   
   oCompany.sParentName
   
   dim iRow as integer = lst.LastIndex
   
   lst.RowTag(iRow) = oCompany
   
next


Data is the NameSpace and we are calling the T_Company List method and we pass in three parameters.  The first is our search criteria, the second is the sort criteria, and the last is the offset which allows us to ‘page’ our data.  It returns an array of Data.T_Company objects and we simply add what we need to the ListBox and stash the object in the RowTag event.  The best part about this is that AutoComplete in the Xojo code editor will show us the table and field names and we don’t have to remember any of it.

Screen Shot 2015-06-24 at 9.49.32 AM

When we wish to edit the record we grab it from the ListBox.RowTag property and pass it in to our editor.



dim oCompany as Data.T_Company =  lst.RowTag(lst.ListIndex)

dim pg as new pgCompanyDetails

pg.Display oCompany


ActiveRecord doesn’t do data binding.  We simply don’t find it useful for a variety of reasons.  First, to do data binding your need to have controls that can handle the data source.  We could create control subclasses but after working with custom data bindings in Xojo on a project or two I was not happy with the endless tweaking we had to do to get them to work properly.  Maybe someone with more patience that I do will be satisfied with it but I never was.  Plus, most developers I’ve met that have done data binding on large projects remain unsatisfied in some form or another or go to extraordinary lengths to make it ‘easy’ (like having every field be string even for things that should clearly be a numeric data type).

Instead we chose a much simpler route.  In our edit forms we have three methods:  Load, Save, Validate.  We feel this offers us some advantages over binding.  First, everything is local to the window.  We don’t have to go find the subclass that handles the data load, save, and validate.  This lets us customize everything for that particular form.  An example Load method:



Private Sub Load()
   
   if moCompany.IsNew then
      
      lblCompanyID.text = "New"
      
      pmStatus.Enabled = false
      
   else
      
      lblCompanyID.text = moCompany.iCompany_ID.ToString
      
      pmStatus.setid moCompany.iCompanyStatus_ID
      
      pmStatus.Enabled = true
      
   end
   
   //Other code here
   
   if moCompany.IsNew then
      
      ccDatePicker1.dtmSelected = new date
      
   else
      
      ccDatePicker1.dtmSelected = moCompany.dtClientSince
      
   end
   
   txtCompany.text  = moCompany.sCompanyNameCurrent
   
   ccLastModified1.SetRecord moCompany
   
End Sub


Right away we can see that what we load depends if the record is new or existing.  Data binding wouldn’t help us there.  Labels and TextFields are the easies to do data binding with but since you’ll need a TextField to do a numbers only field or a date field you now have to create multiple subclasses.  Probably not a big deal but we’ve found it to be a hassle.  Having everything local means we can handle the edge cases with ease rather than having to modify the control subclass that’s doing the binding.

Before we can call our save method we have a Validate method that simply returns true if everything is okay.  If not, it presents a message to the user:



Private Function Validate() As boolean
   
   SetError ""
   
   if txtCompany.text.trim = "" then
      
      seterror "Validation Error.  Company name cannot be blank."
      
      txtCompany.SetFocus
      
      return false
      
   end
   
   if Data.T_Company.IsDuplicate(txtCompany.text.trim, moCompany.ID) then
      
      seterror "Validation Error. That Company name is already in use."
      
      txtCompany.SetFocus
      
      return false
      
   end
   
   return true
   
End Function


Then finally in our Save method we load data from the controls into the object for saving:



Private Sub Save()
   
   moCompany.CompanyStatus pmStatus.RowTag(pmStatus.ListIndex)
   
   moCompany.dtClientSince = ccDatePicker1.dtmSelected
   
   moCompany.sCompanyNameCurrent = txtCompany.text
   
   moCompany.iCompanyEmployeeCount = txtNumberOfEmployees.text.val
   
   moCompany.SICCode ccSic1.SICcode
   
   moCompany.sURL = txtWebSite.text
   
   moCompany.sTaxIDNumber = txtTaxID.text
   
   moCompany.bInactive = chkInactive.Value
   
   moCompany.save
   
End Sub


Note that our save method doesn’t care if it’s a new or existing record.  Behind the scenes ActiveRecord does the appropriate Insert or Update prepared statements.

Every place where we are editing data we have these three Load, Save, Validate methods.  Everyone on our team knows to look for those so it’s very easy for our team to work on projects collaboratively and know pretty much what’s going on.

Could ActiveRecord do data binding?  Sure.  The classes are open source so feel free to modify them to your hearts content but I truly believe it’s more a matter of the controls being the real pain.

ActiveRecord has a number of events that are handy to use.  We track who created and who changed the records using 4 fields on each table CreatedDate, ModifiedDate, CreatedByID, and ModifiedByID.  We add the BeforeCreate and BeforeUpdate events.  For example, the BeforeCreate event looks like this:



Sub BeforeCreate()
   
   dtCreatedDate = new date
   
   if session.oUser <> nil then
      
      iCreatedBy = Session.ouser.iUser_ID
      
   end
   
End Sub


This gets called before we save anything so the class properties get modified before we attempt to save.  In many projects we have an audit trail to know who changed what data so we add the AfterCreate and AfterSave events of Data.T_Company and pass the entire object into the Audit table:



Sub AfterCreate()
   
   dim oAudit as Data.T_Audit = Data.T_Audit.AuditAdd(self)
   
   oAudit.iCompany_ID = self.id
   
   oAudit.Save
   
End Sub


Then it’s up to the Audit class to query the ActiveRecord class to find changed data and put that into its table.  Again, the code to do this is one one spot rather than all over the project.

I could spend hours talking about ActiveRecord as we tend to use on all of our new database projects.  It speeds up development of database applications.  It eliminates many of the common errors.  It tends to force most database code into the NameSpace classes.  And the compiler can warn you if you’re doing bad things with data.

ActiveRecord is not for EVERY project but we’ve found it incredibly useful in our consulting.  If you dread doing a database project because of the tediousness of database coding then perhaps ActiveRecord is for you.

We recently did a webinar with Xojo on ActiveRecord.  You can view it at http://developer.xojo.com/webinar-simplying-db-access-with-bkeeney-activerecord.  ActiveRecord itself is open source.  ARGen is $19.95.  We also use ActiveRecord in one of start to finish training projects at our training site called Link Share.

ActiveRecord home page 

ARGen home page 

Xojo Training Site

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?

Capturing Unicorn Tears

I ran across a post on the forums where the developer was asking how to call the Action event of a Pushbutton.  The simple answer is use the Push method.  It simulates the user actually pushing the button with the mouse thus causing its Action event to fire (and on Mac OS X the button actually animates the push – I don’t know about Windows or Linux).  The longer, more nuanced answer, is don’t do that!  It’s a bad idea.  Let me explain.

Let’s start off with a typical development experience.  You’ve created your wizbang new utility.  It starts of simple and you have a simple Pushbutton.  You add the Pushbutton to your window, you then add the Action event and you put your super duper code that captures unicorn tears.  You test and it works great to much acclaim.

Version one goes out the door and users ask for more features.  So you add a PagePanel to your Window and move the existing UI to one of the pages.  But, because capturing unicorn tears is THE feature of your app you add a Toolbar to the window and then add a Button to it.  In the Toolbar action event you need to make the same thing happen that the Pushbutton did before.

At this point you can either copy and paste the code from the Pushbutton Action event into the Toolbar Action event and be done with it.  This is bad because if you change something in your process it has to be fixed in two places.  But you’ve read the documentation and know that there is a Push method on the Pushbutton that allows you to simulate the push and fire the Action event.  This is slightly better because you only have one copy of the code.  But it’s still not great.

The better choice is to create a method that does whatever was in the Pushbutton Action event.  Maybe a method called “Handle_Capture_Unicorn_Tears” is a better idea.  Because then it can be called from either the Pushbutton or Toolbar action events.

I know, this seems like a lot of work, but now version two ships and someone asks, “Hey, wouldn’t it be great to have a keyboard shortcut for getting those Unicorn tears?”  And you say, “Yup,” and proceed to add it to the Menubar with its own MenuHandler.  If you had copied the code from action event to action event now you’d have a third place to maintain it.

Have I mentioned yet that this is a bad idea?  So don’t do it.  I’ve had to fix projects like this where code was copied and pasted each time it was used.  All of them slightly different.  Are there reasons for them to be different in this location versus the other location?  Only the unicorns know and they ain’t telling;  it’s very hard to debug apps like this.

But no, you’ve been trying to be a good developer and know that copy/pasting the exact same code in multiple places is a bad idea.  But you did use the Push method and you now try to call that from the MenuHandler.  Except the window that the Pushbutton resides on isn’t even open yet when you try to Free the Unicorns.  Except that in testing you always had that window open when calling the MenuHandler and now users are reporting a Nil Object Exception and are pretty angry.

I’m sure must be a valid reason to use the Push method.  I just haven’t found it yet in fifteen years of coding Xojo applications.  The Push seems to be the lazy way out when putting the code from the Action event into its own method would be just as easy (and preferable).

Push works for Pushbuttons, but there is no equivalent for it in other controls.  Nothing.  Learn how to call the same method from two places.  It’s not that hard.

I’ll mention a forward looking thing based on Xojo for iOS experience.  In the existing framework setting a controls value via code will always fire it’s action event.  For example, if you set the Value of a CheckBox it’s Action event fires.  In iOS, setting the equivalent Switch value via code does NOT fire its ValueChanged event.  This is on purpose and all iOS controls are like this.  I was told by a Xojo engineer that this will come to the desktop and web frameworks too.  Be warned.

Capturing unicorn tears is cool and I encourage to make such a utility.  Be smart about it and be lazy and not just lazy now but lazy for a year from now.  If you ever have a need to call a control event from another location, make a method and call the method from the spots it needs.

What say you my fellow Xojo maniacs?

Xojo Freemium Model Continues

Late last week Xojo announced that the Freemium model is NOT going to be cancelled and will continue indefinitely. According to a very brief forum post they discovered new information that showed there was no significant revenue difference between the Freemium and 30 Day Models and therefor the Freemium model will continue.

I don’t care which model they end up using. We’ll be buying a license anyway. Freemium has a LOT of advantages to the community. I’m also glad that the revenue difference isn’t significant – which is, by far, the most important part that some are forgetting.

What concerns me the most is the apparent lack of due diligence on Xojo’s part. In the original announcement (since removed – I’ll get to that in a minute) they said they didn’t make this change lightly. It took roughly a week of the community questioning the move for it to be reversed because of ‘new information’.

What the hell? If there is nothing that I’ve learned in my tenure as a Xojo developer is that the community HATES change. Every time there is an IDE change, name change, framework change, licensing change, or pricing change, it will upset more than a few people. Who needs or wants that level of aggravation if it can be helped?

Major policy changes need to be thoroughly vetted well in advance by everyone on staff. Once everyone is on board then, and only then, should it be made public. The change, and subsequent reversal, doesn’t pass the smell test. I believe the decision was made by a select few and not fully investigated internally before it went public.

So lets talk briefly about removing the blog and forum post. First, Xojo has every right to pull it, shred it, burn it, and otherwise recycle the bits. Should they have done that? Well, that’s open for debate. I believe they should have edited the original post with an update at the beginning and end of the article with a quick note and link to subsequent information. That way there’s no hiding the information but also immediately corrects it. But Xojo’s not my company and not my responsibility.

Removing the blog post and forum thread does remove the original blemish. After all, they reversed the decision and really there’s nothing that changes for any user – new or existing. It does leave a minor scar though. Xojo is a small company and the engineers and staff members are incredibly accessible which leads many of us to think “transparent”. Removing historical data leaves a bad taste for some.

Rightly, or wrongly, we expect Xojo to be accessible and transparent and removing those items exposes that as patently false even though it’s never been true. They have zero obligation to be transparent nor do they have any obligation for the engineers to be accessible. They mostly do all those things because they feel like it and it happens to be good for business.

It’s my belief that this will quickly be forgotten. After all, who has it harmed? Not a single person. Xojo may have a little egg on their face but at least it shows that they are flexible. A stubborn regime would have stuck to their original announcement and weather the storm it generated.

Instead they reversed their decision. Removing the blog post and forum thread is questionable but, again, I feel it harms no one except those that feel inclined to be angry at change.

Time to move on and do some coding!

Xojo Should Scream ‘Business’

With the recent news that the Freemium model failed to bring in the much hoped for additional revenue it’s worth taking a look at the short comings of the product and what can be done to attract not only more customers but, even more importantly, profitable customers.

Let’s be clear, this is not a hit piece against Xojo.  We have four full-time Xojo consultants that spend a vast majority of our time developing Xojo desktop and web applications for clients all over the world.  For all of its faults Xojo is a great tool that serves our customers well.  Can it be better?  Absolutely!  So please take this article as what we feel would help us make it an easier sell to prospective clients and what makes our lives easier.  I think these items might also attract those new, and profitable, customers.

The Xojo IDE itself has been the topic of more than a few of my blog posts.  Frankly, I hate the Navigator and how it switches Editors on you.  It steals the focus in odd ways and the back/forward history even after two years is still wonky.  The Navigator shows too much information when I don’t want it and not enough when I do.  Double clicking into objects makes sense but double clicking nearly anything else does not.

Many people complain about workflow issues and I can’t disagree.  I know I’m less efficient with Xojo than I was with Real Studio (the old version).  With Xojo I spend way more time mousing than I feel I should.  And many of the really nice features of Real Studio are gone from Xojo – especially in the Layout Editor.

At the 2015 Xojo Developer Conference they acknowledged that the IDE is not as good as it could be.  That’s an understatement for those of us spending all day long in the product but it’s a start.  The sad thing is that the IDE is so tightly coupled with the language that they can only fix en mass rather than incrementally.  This means we might have to wait a bit for these changes.  We can only hope that whatever the new design is it’s a signifiant improvement.

I would also argue that Xojo’s insistence of having a UI to create method definitions, properties, events, and so on, are a detriment to adoption.  I know of no other language that forces a developer to jump through the same hoops for declaring methods, properties, constants, etc.  The Code Editor only allows a single method to be displayed at a time so at best it’s clunky and I see no advantage to this design.  At that point many feel it’s more like a toy than a true development environment.  Does it help newbies?  I’m not convinced since plenty of newbies pick up other languages.

The people that can afford to spend a good chunk of money on upgrades and 3rd party tools are businesses.  Xojo should scream business at every step of the process but yet it doesn’t.  The Xojo website talks fast and easy but not ‘business’ and business is where the real money is.

The Xojo IDE has a built-in reporting tool.  It’s weak and I know only a handful of developers that regularly use it.  Most people abandon it and hit the 3rd party market (we sell a set of reporting classes for this very reason).  The fact that Xojo itself doesn’t use their own reporting tool for any report (that I’m aware of) is a shame.

Many businesses need to create PDF documents.  The main solution is a 3rd party plugin to simply create a PDF document.  An even more expensive solution (same developer) exists to view them.  Neither solution works with the built-in reporting tool.

Most businesses require some basic user input controls such as Word Processing, Date, Time, and Calendar.  Xojo has none of those so any business owner will immediately have to hit the 3rd party market.

One item that has come up for years is the lack of a good grid control.  I’m not talking about a listbox replacement but a true grid control that can show native controls in any cell.  Now I understand that making it truly cross-platform is hard but you’d think a company that makes a cross platform development tool would be up to the task.

These are just for Desktop apps.  Web apps have similar issues with an even bigger lack of standard controls out of the box.  The Xojo WebListbox in particular is very weak.  The WebSDK helps alleviate some of these issues but the 3rd party market hasn’t exploded with solutions.  But again I would argue that Xojo should be providing basic no-frills controls without a customer having to hit the 3rd party market.

I’ve had several discussions in the past couple of weeks with developers migrating away from FoxPro and FileMaker.  Xojo would be an excellent choice for them if not for some of the above reasons.  Data binding seems to be an issue for some and Xojo deprecated it a number of years ago.  I have no idea if it’s coming back.  I can argue that I’ve never used a binding system that’s been great but for many business applications it’s a way to quickly get up and running.  I personally think binding gives many developers a false sense of security but I also see how it can be used to quickly develop a complex UI.

Xojo database applications are also pretty dumb.  There is nothing that Xojo does to help you when it comes to table and field names.  At some point you have type in an SQL statement and you won’t know if you have an error until runtime.  By that point it’s way too late and it’s frankly one of the reasons why we developed ActiveRecord to eliminate many of the silly and stupid mistakes that are common to programming database applications in Xojo.

The Database Editor that’s built-in to Xojo isn’t very useful.  Yes, it can help create SQLite databases and attached to all of the supported database servers, but it’s features are very weak.  To the best of my knowledge you still cannot create an integer primary key field that’s auto incrementing.  No wonder why new people to Xojo are confused.  In some ways I feel it would be better if Xojo removed the database editor entirely.

Why would any business owner choose Xojo over any other development platform with the issues I’ve just described?  The fact is some choose don’t.  After 64 bit applications and fixing the IDE workflow issues I strongly suggest a heavy focus on attracting business users.  They are the ones that can afford the more expensive licenses and right now Xojo isn’t necessarily a tool that attracts them.

It sounds like I’m really pissed off at Xojo.  No.  I simply make my living with the product.  If even just a few of these issues are addressed it makes my life, as a consultant, easier.  Make Xojo a great tool for businesses and the non-professional developers will follow.

What makes Xojo a great development choice?  It’s a RAD environment that is easy to learn.  The language is easy for beginners to pick up and yet powerful enough for advanced developers to extend it.  It creates very good cross platform desktop applications for Mac OS X, Windows, and Linux, web applications that be run on nearly any computer, console applications that run on any computer (soon including Raspberry Pi), and it even lets you create iPhone and iPad applications.  Add in some better business features and what’s not to love? At that point Xojo screams business.

So what say you my fellow Xojo developers?  Are these worthwhile goals or stupid ones?  Did I miss anything?

Xojo Ends Freemium Model

This week the Xojo blog announced that they were ending the Freemium model and going to back to the standard 30 day trial period model. As you would expect this has led to an outcry of folks on the forums and there are lots of opinions as to why Xojo is wrong to end the Freemium model. They’re wrong and here’s why.

Xojo said that the Freemium model increased downloads but didn’t change buying habits. The original thinking was that more downloads would get more eyeballs and thus more revenue in the long run. The IDE was free to try and use until you wanted to do a final executable.  It didn’t.  Period.  Their two year experiment with the Freemium model failed.

I don’t mean to belittle the hobbyist developers out there, but there is ample evidence that many of them simply just ran their apps in the IDE rather than compile them as standalone executables, thus not even purchasing an inexpensive desktop license. Obviously this was not the intent of the Freemium model and certainly violates the spirit of the model if not legally as well.

We can argue all day long as to why the freemium model didn’t attract more paying customers. I’m sure there is not just ONE reason but combinations of many smaller issues and here are some wild guesses. Perhaps desktop programming is experiencing a decline and perhaps web apps aren’t growing as much as once thought. Perhaps iOS isn’t an attractive target without Android. Perhaps the lack of business-only features hurts them. Perhaps the IDE design pushes some people away. Heck, I’ve asserted for a long time that the insistence of dumbing down the IDE in favor of newbie programmers is a detriment to the health of the platform. <Insert your favorite theory here>

One argument I might buy is that they didn’t give it a long enough try.  Some times it takes a while for things to take hold.  Add in that two years ago they changed the name of the company/product and lost whatever internet search rankings they may have had and it’s quite possible that it’s only now that people are finding Xojo.  It doesn’t matter now.

Regardless, the bottom line is that the Freemium model didn’t increase revenue for Xojo. At best, it means that revenue stayed the same and, at worst, they lost revenue. No company can stay in business by having static or negative revenue.  Expenses only go down through layoffs and no one wants that.  It’s the right business decision or otherwise we might not have our favorite development tool around in another year or two.

So while it’s sad it didn’t help them I can’t complain. They know the financial numbers better than we ever will. They told us the reasons so it’s time to move on.

What do you think?

XDC Notes:  Compiler Notes AND Exception Line Numbers

So far I’ve written a couple of posts about information gleaned from the XDC keynote address last week.  One session that revealed some additional information was Joe Ranieri’s Compiler session.

Joe started off by talking about what’s happened to the compiler in the past year.  The list is pretty impressive since that includes iOS (32 bit AND 64 bit), 64 bit for Mac, Windows, and Linux, as well as adding the new framework, and adding better compiler error messages.

He spent some time explaining why the Using and Global keywords came about and how they are used.  It’s interesting that you can mix and match the two frameworks and how that might be desirable.

Iterators were next up in the presentation.  Iterators allow our classes to be used with For Each loops and Joe said that iterators are generally more efficient than alternate approaches.  Two interfaces are available Xojo.Core.Iterator and Xojo.Core.Iterable.  A good example of the new interfaces are in the Xojo.Core.Dictionary class.

The new Text datatype is the attempt to solve the String datatype deficiencies.  Strings could be text or a bucket of bytes which led to issues with encoding.  Text is always a valid textual representation and is a series of Unicode code points (a way to think of this is an array of characters that might be ASCII or a valid Unicode character- either way you, the developer, don’t need to care).  When converting to Text you always give it the Encoding you want so it’s never in question.  One nice feature of Text is that you can convert to and from a String with no penalty.

The New Auto datatype is the replacement for Variant.  Auto’s perform NO conversion of data which led to sometimes subtle issues with Variant as it would gladly convert from datatype to datatype regardless if it made sense or not.  Auto will only do conversions that the compiler would (such as doubles and integers) but raise exceptions when it comes across something it can’t do (like strings to integer and visa versa).  Auto preserves type information exactly so you can use Introspection to determine the type.

New for 2015 R3 is more 64 bit targets.  This includes GUI projects on Windows and Mac OS X, console and web projects on Linux, Windows, and Mac OS X.  Porting, for most of us, should be straightforward.  However, there are a number of problems we’ll face.  Among them are Declares, Integer size assumptions, and Plugins.

A new 64 bit aware plugin SDK is due out soon and Christian Schmitz from Monkeybread was showing off his plugins running in 64 bit apps with no issues (it’s my understanding it was NOT using the new SDK so I’m sure he’s got some work to).  The new SDK is entirely C based and the overloaded C++ functions are going away.  Most of the long deprecated functions are doing away too.

Declares will be a problem, though.  Of particular note is the Windows Functionality Suite.  It won’t work in 64 bit and you’ll have to find replacements for those things you use.  Mac OS Lib is in better shape but needs some updating too.

Structures need to be updated for 64 bit apps to.  The default structure alignment of 1 means it puts each field right after each other and this is wrong for 64 bit apps.  If you use the structure alignment of 0 it will align the structure ‘naturally’ which matches was C does.  I’ll be honest, this was interesting news but way above my pay grade in understanding.  Talk to Joe if you have questions on the implications of this change.

Also new in R3 is customizable array sorting.  Currently we can do this using SortWith but now we’ll be able to pass in a delegate.  Joe really seemed pleased about this addition but I think the implications won’t be immediately noticed by the community.  I for one don’t remember the last time I had to sort an array since we generally load arrays sorted in the order we want later.  You might find this useful.

Joe wrapped up his talk with some roadmap items.  For R3 the IDE debugger is still 32 bit.  Obviously it needs to be 64 bit and that will happen.  The better compiler error messages initiative will continue as well as Xojo-specific compiler optimizations.

Perhaps the biggest bombshell that came out of the roadmap portion was exception line number information!  This means that we should be able to get information on which line of code caused the exception.  I believe at this point several people clapped as determining which line of cause caused an exception can be difficult to determine.

I followed up with Joe after the session and while it’s not finalized, here are the plans.  The compiler will spit out two files on the build.  The first is the application and the second debug information.  When an exception is called there will be a binary blob that can be saved and sent to the developer.  There will be a tool included with the IDE that takes that blob and can show you the original line of code that caused the issue.  AND it will show you the stack like the debugger does now.  It will not have any variable or argument information.

Regardless, this is a feature that people have been requesting for years.  This should lead to better error reporting and hopefully better programs!

The compiler session was the only Xojo led session, that I attended, that had any sort of roadmap information presented (with the exception of the Keynote).  It was informative and was a wealth of information.  This session gets a five start review (except for the purple code against the black background – sorry Joe).

See anything that gives you hope?  Anything makes you want to mope?

XDC 2015 Recap

The Xojo Developers Conference is my favorite week of the year.  It’s where I go to renew friendships, make new ones, talk to potential clients, learn from other Xojo developers, and learn what Xojo is up to.  Along the way there’s usually a surprise or two and this year was no exception.

The first surprise from XDC was that all sessions were recorded.  All attendees will get access to the sessions.  Currently it’s unknown if they will be available to the general public for free, or for a fee.  During the wrap-up session several people gave an impassioned plea to make these available to everyone at no cost.  The argument is that their experience with other conferences showed attendance actually goes up after releasing session recordings.

Not really much of a surprise since they’ve been telling us this for over a year now, but 64 bit builds are coming in 2015 R3.  This is indeed welcome news in a  software world that’s quickly becoming 64 bit.  From what I gather from people way smarter than me (insert joke here) is that 64 bit won’t really change anything in our apps and won’t give us much, if any, enhancements, and will make some things slower.  As Geoff joked at the conference, let’s hope that 128 bit computing doesn’t come any time soon.

Drag and Drop for web applications is coming for R3 as well and I expect this to be a big deal.  There are just some times of applications that do well with a drag and drop environment.  Think graphical editors where you have an object that you select and move by dragging it.  The current web framework has drag events but they should absolutely not be used – ever – since they don’t really work like we expect.  Drag and Drop might very well be my favorite news from XDC.

Raspberry Pi apps built using Xojo.  I think this is a wonderful addition to the product.  Raspberry Pi is a hugely popular processor because of its price and it’s used in a lot of places.  Hobbyists and the DIY crowd really like it and I’ve seen more and more ‘professional’ level projects with them too.  Heck, my sons 3D printer is run by a Raspberry Pi.  The XDC crowd didn’t react much to it when they announced it but as the week went on it came up in conversation more and more.  What a great way to introduce Xojo to new developers!  Really, the only question that’s come up is how much will it cost?  We already know it will be part of the Pro license but what about those that don’t need all the other stuff?

One unexpected surprise was the mention of the long deprecated and removed SpriteSurface and SuperSpriteSurface.  It seems that more than a few people got their start in Xojo/REALbasic developing games using it.  SpriteSurface wasn’t a great class, in my opinion, but it was enough to get started and getting people exposed to the language.  Perhaps we’ll see a Son of SpriteSurface in the future?

One thing that I expected to hear more about but didn’t was Auto Layout.  Norman had a session on it but other than there wasn’t a mention of it anywhere.

This isn’t a surprise because I’ve been many XDC’s now, but the official evening events are usually a lot of fun.  This year there was a mystery dinner theater that most found entertaining but the river cruise to watch the bats come out at dusk was awesome.  What goes on after the official events is even better as clumps of developers go exploring and Austin is a great place for exploring.

I encourage you to go to an XDC.  It’s a very nice event where you’ll learn a lot not only from the sessions but from those attending as well.  No word on where next year’s XDC will be. The cities under consideration:  Seattle, San Antonio, Miami, New Orleans, and I believe San Diego.  If you have a preference, be sure to let Xojo know.

So that’s my recap of XDC 2015.  Did any of the news surprise you?  Anything you expected to hear more about but didn’t?

Xojo Developers Conference 2015 Keynote Notes

Geoff Perlman from Xojo spent an hour this morning talking to the attendees about what Xojo is working on and there was some interesting news.  So let’s dig into the highlights!

In a major change of XDC policy all sessions at this years conference are recorded!  All attendees will get access to all of the videos in June.  According to an announcement in the Xojo forums, these recordings will be for sale at some point in the future.

If you look on the App Store, you can find an XDC iOS application that contains the list of sessions, give feedback, as well as maps.  This app required a bunch of technologies currently not built into Xojo for iOS:  Notifications, iBeacon, and camera access to scan QR codes.  Furthermore, this app and administration application will be open sourced.

Xojo Cloud servers will pretty much double in most of their specifications while keeping the price the same.  The small server will now support DB servers (Postgres and MySQL), have 1 GB of RAM, 20 GB SSD drive, and 200 GB outgoing bandwidth.  The medium and large servers have similar upgrades and all of this will be available in June.  Xojo will contact customers to help them migrate their servers.

Web apps are getting drag and drop capabilities.  Starting in R3 developers can specify if controls can allow a drag or accept a drop.  This includes controls.  The API is similar to the way desktop apps work with drag and drop.  In fact, it’s a little easier than desktop, and while Geoff didn’t promise anything he said it’s possible that this API may make it to desktop at some point.  No word if there is drag and drop being added from client file system to the browser.  I will try to follow up on this.

Xojo gave a little history on how the Xojo IDE came about.  When they redid the Real Studio IDE they wanted a modern looking IDE, that was more approachable, had better search results, and had less tab management.  However, they acknowledged this morning that it has some shortcomings.  The panes take up too much screen real estate, too much time spent hiding/showing panes, to much dependency on the mouse, poor Layout Editor workflow, and poor project Navigation.

Xojo is in the process of designing changes to address these issues.  The changes will reduce pane management, be more keyboard friendly, improve the Layout Editor workflow, and greatly improve project navigation.  No idea on when this will occur as it’s a big change.  And there’s no real way to incrementally change the IDE so it’s an all or nothing change.  Let’s hope that it doesn’t take the two years it took to go from Real Studio to Xojo.

Starting in R3, Raspberry Pi (Linux on ARM processors) is supported.  This turns out to be an interesting addition since these tiny little processors are inexpensive and used in many embedded and hobbyist applications.  This is an interesting new target and might bring some new developers to Xojo.  This new target is included in the Pro license.

Also in R3 we will get the first opportunity to build applications in 64 bit for Mac OS X, Windows, and Linux.  Geoff showed off the Feedback app built as a 64 bit application.  He also said that if you are using plugins it’s likely that your app won’t work until plugin developers can get them 64 bit capable.  Attendees will get Alpha one (emphases on the one) where 64 bit compiling only works on Mac OS X.  Later R3 alphas will work on all platforms.  However, for R3 the debugger is still 32 bit.

Sometime between now and next years XDC we will be able to create plugins using Xojo.  These are available for iOS and 64 bit Mac OS X, Linux, and Windows applications.  32 bit desktop apps will not be supported.  What’s interesting about the new plugin format is that it can contain resources (images, sounds, etc) that current plugins can’t do.  These new plugins can also interact with the IDE meaning that you can have dialogs and editors.  This is very exciting news and should lead to some interesting developer solutions.

EDIT:  Geoff worded this poorly. What he meant is that you can have plugins that use the GUI framework. There’s nothing in the announced roadmap for extending the IDE itself.

Retina support is currently being worked on.  In R2 for iOS we now have image sets and your application will pick the right image resolution at runtime.  This will get moved into desktop targets and into the IDE in 4th quarter 2015.

Updates for Windows.  Geoff showed us a currently usage chart for Windows.  Windows 7 and 8 are now accounting for over 80% of the installed base.  Therefore, starting with R3, Xojo will not support builds in Windows XP.  While Retina support for Mac OS X will come soon, he did mention that Windows HiDPI support is coming.

EDIT:  This was poorly worded as well.  Support for Windows HiDPI is not in the announced roadmap, just that it’s something Xojo would like to tackle at some point.

Those are the highlights.  If you have questions, let me know below and I’ll see if I can get them answered.  Anything particularly excite you?  Anything you dread?