The First Law of Demos

It’s the last full week before the Xojo Developer Conference in Austin.  I’ve gone through my presentation on Reporting Tools in Xojo at least once already.  I have the Keynote presentation done (added a few things), have the sample projects done and ready to upload to the website.  You’d think I’d be done, right?  Wrong!

The First Law of Demo’s says that unless you’ve done the demo multiple times on the hardware you’ll actually use it’s as if you’ve never done it in the first place.  I should know, I’ve been standing in front of a group of people to do a demo only to have the first element fail and then flounder away for the next twenty minutes with plenty of, “well, if this worked I’d be able to show you this feature.”

I have learned from my mistakes, the hard way.  Several times.  Here are Bob’s rules of effective demo’s.

Rule #1:  Disconnect from your normal network/regular computer

There are things floating around on your drive that you tend to use all the time.  So when you take your development project off your home network, or move to a separate machine, you’ll quickly find the things that you forgot include in your demo packages.

In my case, I discovered that a Xojo project had references to graphic files that weren’t included in the folder I moved to the presentation machine.  The graphics weren’t necessary and it was easy to fix but how embarrassing to be in front of your peers to have a simple error like that occur.  It shows a lack of preparation.

Rule #2:  Run all of your Demo’s in the latest version of the software

This sounds silly, I know, but I found that one of the reporting tools I’m talking about in my session doesn’t work with Xojo 2015 R1 and R2.  For whatever reason I was using 2014 when I first created the project and didn’t run into the problem until I started working with it on the laptop which had the latest version of Xojo.

Another reporting tool I’m talking about in my session had to have a number of libraries installed to work properly.  And then it needed a newer version of its plugin.  These issues were not very hard to fix when I have reliable internet access and access to all my files, but once you’re away from home that’s not always the case.  Again, if this happens in a presentation it looks like you have not prepared.

Rule #3:  Practice saying your presentation out loud  

Speaking your presentation is important in a number of ways.  First, it will show you where you have not prepared enough.  If you find yourself um’ing and ah’ing in a particular session that’s an area to do again (and again).  Since you can think faster than you’re speaking you’ll often find yourself saying “I need to mention this.”  Having this happen during your actual presentation is a bad time.  Practicing beforehand will show you these problems.  Practice multiple times to catch even more of them.

I’m a good writer (I’m sure that’s open for debate) and I have my ‘inner voice’ that talks to me when I’m reading something.  That’s not good enough when practicing for a presentation because your inner voice lacks depth.  It lacks the pauses and breaths that you need when speaking.  Practice your presentation as if there are people in the room.  Pause for effect.  Pause for eye contact.  And in technical presentations pause for people to wrap their head around the idea.  Silence is good in a technical presentation and that pause is never as long as you think it is.

A lot of people have a fear of public speaking.  I can’t say was overly enthused about the subject a few years ago either.  I decided to tackle that fear and enrolled in a local chapter of Toastmasters (TM).  At this point I have achieved the Competent Communicator award and feel more comfortable speaking in a crowd.  Frankly, after two years of TM it’s hard not to evaluate all speakers and count their use of um’s and ah’s.  Toastmasters is a safe and friendly environment to learn how to speak in public.

Rule #4:  Practice, Practice, Practice

This seems intuitive but I’ve seen it happen to myself and others way too often.  The more you can practice your presentation, out loud, the better off you’ll be.  I can’t remember which Toastmaster’s speech I was giving but I didn’t have the same preparation as I normally did and it showed.  My use of fillers words was awful, I fidgeted a lot more, and I was uncomfortable with the topic, and I had to use my notes more often than I wanted.  I did okay but it was not my best speech.

Steve Jobs was known for his awesome keynote speeches where he introduced new, sometimes buggy, products to the world.  He practiced, on stage, with the actual product hundreds of times until everything seemed magical and when something didn’t go as planned he could make joke of it and move on (and use the backup device).  That last bit is very hard, but if you’ve practiced your presentation to the point where you’re dreaming of it you should do okay if things go awry.

Rule #5:  Relax

I can’t say I’ve ever been to a technical presentation where the audience was hostile to the speaker.  We usually have a choice on what sessions to attend and we are there to learn something new and hopefully be entertained.  The audience is pulling for you!  When you make a mistake during your presentation know that we’ve been there and had the same thing happen to us.

Toastmasters has another fine tradition of telling a joke to start off their meetings.  It makes everyone relax a bit and if the joke, even an awful joke, can get a chuckle or two it’s a great way to start a presentation.  If you can do a joke somehow related to the topic you’re even better!  One word of caution on jokes, though, unless you’ve practiced the heck out of telling this joke don’t bother!  The timing of joke is everything and unless you’re are comfortable with it don’t screw it up (unless you’re comfortable enough to botch the joke and recover from it and make everyone laugh anyway).

So that’s it.  I have a lot of work to do before the conference next week.  I have to practice some more and when I get tired of talking about it I’ll do it again once or twice.

Hope to see you at the conference.  Please stop me and introduce yourself.  I really enjoy meeting my fellow Xojo developers.

Xojo 2015 Release 2

Xojo Release 2 went public this week.  This release is a typical mishmash of new features and bug fixes.  So let’s dig into it!

iOS

The DatePicker was added to iOS.  This is a most welcome addition and let’s you switch between Time, Date, Date and Time, and Countdown Timer.  There’s still no generic data picker which is a shame.

The Launch Images and App Icons folders for iOS has now been replaced with an editor that allows you to drag and drop images into it.  If the image isn’t the appropriate size for the selected image a message appears saying what the dimensions of the image is and that it will be scaled to fit.

[Edit]   One thing I forgot (because I didn’t see them in the release notes) was that build times are much better in R2.  From comments I’ve seen it may be an order of magnitude faster.

Web Apps

If you are using the HandleSpecialURL or HandleURL the RequestHeaders now has a Secure property telling you if the request came in over a secure channel.  If you are using SSL Certificates they can be specified on the command line.  Another new web feature is the ability to set the HTTPOnly property attribute in the Session.Cookie.Set method.  This should work as a preventative measure against cross site scripting attacks against Xojo web apps.

New Framework

The new framework is making its way to more and more of the overall package.  The Xojo.Data, Xojo.Crypto, and Xojo.IO.Folderitem are now available for all targets and platforms.  The Xojo.Data namespace includes the ability to read/write JSON (no work on XML yet).  The Xojo.Crypto framework gives you access to MD5, RSAEncrypt/Decrypt, RSASign, RSASignVerify, SHA1, SHA256 and SHA512 hash methods.  Xojo.IO.Folderitem gives  you file handling.

Xojo.Net.HTTPSocket now works for all platforms (except Xojo Cloud).  It should be noted that HTTPSocket is now ONLY asynchronous.  No longer can you wait for the response but now you have to use the events from the socket.  This is really a better way of using the HTTPSocket but if you’ve been using it in the old framework synchronously you’ll need to adjust your code accordingly.

[Edit] The new HTTPSocket supports HTTP 1.1, automatically supports proxies on all platforms, and performs proper certificate validation.  It also no longer performs polling on the socket so it should be have significantly lower CPU usage.

The Xojo.Core.Timer now works properly on Mac OS X 10.7 and 10.8.  Apparently it didn’t work properly in older versions of Mac OS X.

Miscellaneous

For many, the recent addition of the Windows ICU DLL was a major setback as they were quite large.  You’ll be happy to know that they’re now statically linking them and removed the unused portion of the libraries so the built package is now considerably smaller.

The IDE receive a large number of bug fixes including a couple of memory leaks.  They also fixed how deleting items works and how the focus works when switching between tabs with the Code Editor displaying.

According to the release notes there are 147 total items that were changed in Release 2.  This number seems a little low in comparison to some previous releases.  Given the short period between the R1 release and XDC I think this makes sense and the engineers have a lot of work to do in getting ready for XDC.

I did not get as much of a chance to run the beta as I usually do but there hasn’t been a lot of chatter on the forums about issues either.  What little I did with the beta was solid and this looks to be a decent release.

Have any comments about this release?

Xojo Desktop vs Xojo Web App Development

The question comes up every now and then on what’s the best target to develop for:  desktop or web.  The answer is sometimes pretty straightforward but, in reality, the answer should be “it depends.”  You see, each target has some very good strengths and also some bad weaknesses that you need to evaluate before you start coding.  Let’s go over some of those issues.  Let’s start with desktop apps.

Xojo has been making desktop apps for it’s entire history.  Thus it is very stable and mature and there are a lot more 3rd party libraries and plugins available.  You get most, if not all, of the goodies that come along with the desktop environment and this can mean your desktop apps can have most of the buzzers and bells that modern users demand.

With desktop apps, if you need 10 more copies, it’s as simple as installing them on new machines.  These days there’s not a lot of issues deploying to Mac OS X and Windows and most versions of Linux, but still, you need to test on all supported platforms.

The major downside to desktop apps is deployment.  Each user has a copy of the software and depending on your needs/requirements you might need to ensure that everyone be on the same version.  Example:  You’ve created a desktop app for a veterinary clinic that handles everything from pet checkin to billing.  All of them connect to the same database so when you introduce a schema change in the database you need all the clients to use the newest version.    For a small organization this might not be so bad but scale that up to a corporation with several hundred copies of your software.  A good organization might have a good IT department and can deploy your software to everyone at once, but my experience says that most organizations don’t handle this well.  So your software has to be programmed to be cognizant of database versions and check at startup and complain if it’s not what it’s expecting.  From experience it’s a pain to deal with.

Desktop apps that are part of an n-tier system also need to be programmed differently.  You can program each client with all the logic it needs, but then you have to worry about record locking issues (i.e. who wins if two users are editing the same record at the same time).  You also have deployment issues, again, since you’re back to the issue of updating every client every time there’s a little change in logic.  The better solution is to have a middleware application that handles the business logic and is the go-between between the client apps and the server.  The middleware app does all of the business logic and handles the transactions between the database and the client apps.  It’s a fair bit of work and is not what I would consider a simple undertaking.  But at least you generally only have to update the middleware app most of the time and the clients can stay the same.

Web apps, on the other hand, have several advantages over desktop apps.  First, they are n-tier by design.  Each client has its own set of logic via Xojo WebSessions even though there is only one application running.  The user runs in a browser and everything is processed on the server.    So when you need to update your web app you shutdown the old one, replace the executable and the next time someone hits the URL the newer version is there and running.  Having only one instance to update is really nice (and quick).  Web apps eliminate many deployment challenges.

Web apps aren’t perfect though.  Since they are generally exposed to more random user interaction via the web you spend way more time dealing with security and making sure nefarious users don’t get into your system or abuse it.  All of your database operations should use PreparedStatements to make sure SQL injection attacks cannot happen.

Web apps run in a browser.  That’s both good and bad.  Users can access your app as long as they have internet access.  In some areas this is no big deal and for others it’s a huge deal.  Browsers also have a lot of built-in security to keep bad things from happening on your computer.  This security also limits what your browser can do in terms of file handling local.  Xojo does not currently support drag and drop operations with the browser.

Xojo web apps are also not as stable and mature as the desktop side simply because it’s younger.  That’s not the same as unsafe but it does mean there are not as many 3rd party options for Xojo web apps.  Some controls, in particular the listbox, are vastly inferior to their desktop counterparts in terms of capabilities and may not be good enough for your needs.  Web Containers go a long way towards solving this issue but it’s not ideal.

Not all web browsers are created equal.  Some perform better than others and all of them have gone through tremendous growth in the past ten years as the internet has become ubiquitous.  This means there are a lot of different browsers, and versions of those browsers, being used by the general public.  Testing the various browser type and version combinations is critical and despite all the efforts of Xojo to get it all right, the speed of new browser releases does mean issues pop up now and then.  Mobile browsers have their own set of issues that you might need to take into account as well.

Desktop apps have a huge advantage in that they don’t have to convert text to UI like web apps do.  For example loading 1,000 rows in a desktop listbox, while slow is blazingly fast compared to doing the same thing in a web app.  1,000 row list boxes in web apps are SLOW simply because the server has to create all that html data, send it through the internet to the browser, and then the browser has to reassemble it for the user to see.  To get around this most websites do data paging where they only show you 25 to 50 records at time.  Again, not hard to do but one more thing to develop.  Also keep in mind that mobile browsers try really hard to minimize data connections over cell connections so what seems fast on your desktop might be incredibly slow on a mobile phone.

Perhaps the biggest issue with web apps (not just those made with Xojo) is scaling.  Your app will react differently when accessed by 1000 simultaneous users than when it has 10.  The way around this is to do load sharing and balancing using NgInx and works well on Apache web servers.  Finding a good web server to host your web app can be challenging too.  Until Xojo releases their 64 bit support for web apps it will be increasingly difficult to find and install 32 bit compatibility libraries that work with Xojo web apps.

As you can see, there’s is no right answer.  Both desktop apps and web apps have their place in the world since they each have strengths and weaknesses.  Before you start development work you need to think through the implications of doing each.

Happy coding!  Was there anything I forgot to mention in the debate of desktop vs web apps?

BKS Shorts Webinar

JpicAppIcon256oin me from 1 to 2 PM (ET) on Tuesday, March 31 as I do a webinar with Paul Lefebvre of Xojo.  In this webinar I’m going to talk about BKeeney Shorts, our reporting classes for Xojo.

Many Xojo developers are familiar with banded-style reporting tools.  They are generally easy to understand and use and are great for simple reports.  However, if you’ve struggled with complex reports that don’t easily fit in the banded reporting tool paradigm then BKS Shorts is worth looking at.

BKS Shorts is 100% native Xojo code and its strength is that you have 100% control over all of your report objects.  Its drawback is that you have to code everything!  BKS Shorts has multiple rendering options including to the Graphics object (Canvas and printer), to HTML, and to PDF  (using the MBS DynaPDF plugin).  BKS Shorts works on desktop, web and console apps on Mac, Windows, and Linux.

In this webinar I’ll go through an example or two explaining the code and answering any questions that come up.  To register for the webinar, please go to https://www.zoom.us/webinar/register/9a94b333833729fbcde7dc3c8da9331e

 

See you online!

 

BKS Spell Checker 1.0.2

picBKS_SpellCheckerWe released a new version of our Mac/Windows spell checker plugin today.  Version 1.0.2 works better with foreign language Hunspell dictionaries that are in different encodings.

The Spell Checker plugin has two different spell checking modes.  In the first mode it  works with the native spelling dictionaries on each platform.  On all versions of Mac OS X (that Xojo supports) and Windows 8 and above it uses the built-in spell checker dictionaries.  If you can’t, or don’t want to, use the native dictionaries you can use the Hunspell dictionaries.  There are hundreds of Hunspell dictionaries available for use in a variety of languages and speciality industries.

There is no Linux version at this point due to lack of interest.

More information, including downloadable demo, pricing, and usage is available at http://www.bkeeney.com/allproducts/bks-spell-checker-plugin-for-xojo/

LiveCode vs Xojo

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

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

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

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

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

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

LiveCode Dictionary

LiveCode API Dictionary

 

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

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

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

put “ABC” into myStringVariable

In Xojo this same thing would be

dim myStringVariable as String = “ABC”

LiveCode Create DB

Creating an SQLite Database File using LiveCode

Xojo Create Db

Creating an SQLite Database File using Xojo

 

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

LiveCode Mac app

LiveCode App running in Mac OS X

LiveCode Ubuntu App

LiveCode App running in Ubuntu

LiveCode Win8

LiveCode App running Windows 8

 

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

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

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

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

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

What I Liked About LiveCode

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

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

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

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

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

What I Disliked About LiveCode

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

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

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

Conclusions

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

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

XojoTalk

One of the things that I love about the Xojo community is that it’s pretty friendly group.  You ask a question on the forums and you’ll usually get a decent answer or two.  This means that we’ve often ‘talked’ with Xojo experts but have never met them.  One of the things that stinks about the Xojo community is that we are a small enough group that it’s likely there are not a lot of Xojo developers near you.  That’s a shame because the Xojo developers I’ve met in person are as nice, if not nicer, than they were online.

If you can possibly attend the Xojo Developers Conference (this year it’s April 29 – May 1 in Austin, Texas) I highly recommend it.  Whether you are a newbie to Xojo or been around the block, as they say, a few times, I’ve always found it to be a good experience.  To be able to talk Xojo for 3 or 4 days is invaluable!  Nowhere on the planet will you find a higher concentration of Xojo developers per square foot.

Recently Paul Lefebvre, the Xojo Evangelist from Xojo, has been hosting a podcast called XojoTalk.  I love these podcasts because we get to hear from Xojo developers that we’ve ‘known’ for years through the forums and we get to learn a bit about them.  How they came to use Xojo and what they’re doing with Xojo.

Often the conversations veer off into some strange topic that you wouldn’t expect.  When I was a guest back in October the Royals were starting their playoff runs and while I’m not much a baseball fan it was a BIG deal for those of us in the Kansas City region (29 years since our last playoff appearance).  We also talked a bit about the, then, recently announced Windows 10 and what it meant for Xojo developers.  These organic conversations are entertaining and well worth a listen.  Paul does a great job so check it out!

You can subscribe to the podcast via your favorite RSS reader via http://feeds.feedburner.com/xojotalk or via iTunes at https://itunes.apple.com/us/podcast/xojotalk-podcast/id920411434

My entire team will be at XDC.  We are doing only two sessions this year.  Carol is doing a database design session and I’m doing a reporting tools session.  Hope to see you there!

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/

Xojo 2015 Release 1

This week saw the release of Xojo 2015 Release 1.  This release has only a couple of new features (and one really big change) but many smaller changes and bug fixes.

The biggest new feature for Xojo is that you can now build 64 bit iOS applications.  This is a big deal because Apple is making 64 bit iOS apps mandatory for those apps submitted to the App Store.  As of February 1st submissions to the App Store must be universal 32 bit / 64 bit app bundles.

In December 2014 Xojo gave us a tentative roadmap and met it as 2015 R1 was in a usable beta on February 1st.  This is an accomplishment in and of itself since Xojo rarely, if ever, gives us their schedule.  Not only gave a schedule but met it!  I’d say lets give them some kudos for being a bit more open and accomplishing their task!

So far in testing it appears that 64 bit iOS applications are solid.  This also means that the 64 bit compiler is working and works in a 32 bit application and debugger.  According to their December 2014 blog post the next up for the 64 bit treatment is Linux web/console and this will be much anticipated by anyone that’s tried to install a Linux web app on a 64 bit Linux OS and struggled to find 32 bit compatibility libraries.

Besides 64 bit for iOS, there are a plethora of bug fixes to the IDE, the new framework, and the compiler.  To say that the IDE received some love would be an understatement.  These changes should make for a more stable development environment.  The number of bug fixes is too many to list here and I highly recommend reading the release notes.

The IDE Icon Editor received another makeover (how many is this in the past 15 years?) that allows it to handle 1024 by 1024 icons.  Some unused sizes were removed and the output format is now PNG rather than JPEG2000.  In my own testing it seemed that images moved forward from older projects didn’t look quite right so you should definitely make sure your icon images are updated before doing a release.

The Web framework received a few important updates.  WebLabels now work properly on dynamically created WebContainers.  WebCheckboxes respond properly on touch devices.  WebContainer mouse event handlers no longer interfere with scrolling.  WebListbox no longer offsets the selection if placed inside a WebContainer and accessed from a touch device.  Internet Explorer now supports gradient fills.

The new framework received new Parse functions for Integer, Double, Single and will act like the existing framework Val and CDbl functions.  What this means, in reality, is that Parse is more lenient and doesn’t throw exceptions when it can’t figure out the value of the passed in Text.  I think it’s obvious that Xojo is mindful of how we are using the new framework and reacting to our (valid) criticisms and wants and needs.

Windows and Linux users didn’t receive much love in this release, however.  The release notes only have a few for each and those seem pretty minor.  One bug fix that affects everyone, but appears to affect Windows more, was the Serial control.  It appears that it was possible to receive incorrect data.

I think many will be happy with this release.  64 bit iOS applications were a necessity and everything else was bug fixes and expansions of functionality.  I wish more releases were like this (i.e. a few new features and mostly bug fixes).

As with any new release you’ll need to test it against your own projects to find out if you have any issues.

What are your comments about Xojo 2015 Release 1?

Xojo Open Source Projects

In my last post I talked about the state of the 3rd party market for Xojo.  It was a somewhat depressing talk for those already selling and a cautionary tale for those contemplating entering the market.  All is not bad news, however.  In some ways, the amount of open source source code available for Xojo is at an all-time high.

For many Xojo developers the must-have libraries are the Windows Functionality Suite  and MacOSLib .  These two libraries are great places to start to enhance your Windows and Macintosh applications respectively.  There are both free and wrap system API calls into Xojo classes and methods.  I would start with these two classes.

The folks at IntelligentVisibility have done some interesting things.  Their CalendarTimeChooser project is 100% Xojo code calendar and time chooser that is pretty slick, in my opinion.  Besides that they have a DropBoxAPI project, a Telnet class for Xojo, a Logging class, an AutoCompleteTextField, and a Loading Wheel control.

Long time Xojo user Kem Tekinay has released Kaju.  Kaju is a set of classes that can perform self-updates for your Mac, Windows, and Linux apps.  This solves some real world problems we all face and while Monkeybread Software has the Updater Toolkit it uses different technique for each platform and (from experience) troubleshooting can be difficult in getting the Sparkle framework working on the Mac.

Another long time user, Scott Boss, of Nocturnal Coding Monkeys, has released the Xojo Colors Module that aims to simplify the use of colors in your Xojo project.  Another project is XoDrill which is Xojo class that uses the Mandril APIs from MailChimp allowing you to send mass mailing through the MailChimp service.

iOS has only been out for one release, but it has received a lot of love from the community.  Some criticize Xojo for not being complete and not providing some basic functionality.  I disagree because Xojo should not have to provide everything – just the basics for us to do everything else.  I think it’s working because the work coming out of the community has been extraordinary.  If your Xojo iOS app needs gestures then xojoGestures is a great place to start.

If you are working with iOS then I hope you are spending a lot of time in the Xojo iOS forum.  The users there are turning out iOS declares at a prodigious rate and there are way too many to list here.  The forum should be your first place to search for a solution.

Xojo for iOS has introduced the new framework which, in come cases, is considerably different than the existing one.  XojoiOSWrapper  tries to bring those legacy framework methods to the new framework and specifically for iOS.  If you’re working with iOS AND desktop apps and trying to use a set of shared business logic between them you’re finding it hard to accomplish.  GlueKit for Xojo is a set of classes and methods from long time Xojo developer Phillip Zedalis of 1701 Software, that allows you to interact with a single class that bridges the new and old frameworks.

Perhaps this trend is part of a larger trend with software that tends to make things open source.  I’m still not convinced that this is the best thing, long term, but it does provide some stability with developers entering and leaving the community and having source disappear forever.  Regardless of the long term implications it shows that the Xojo community is alive and thriving.

If I didn’t catch your Xojo open source project I apologize profusely!  Any oversights are purely my error.  Please leave a comment with the link to your repository and a brief description of what it does.  And for those of you wiling to share your work with the community a big hearty THANK YOU!