Have I told you how much I love the Xojo community? I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more. I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product. It’s a big deal. Really!
If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey. Programming is hard. Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard. Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.
Even Xojo pros, such as myself, have need of help. Xojo covers Mac, Windows, Linux desktop, console, and web apps. It does iOS apps for iPhone and iPad. It now does Raspberry Pi for heavens sake! It works with dozens of different databases. There is simply no way any one person is going to know everything there is to know about Xojo. It just can’t happen. So yes, I go to the forums, all the time, and ask for help.
Just the other day I asked for some help with WooCommerce. Not Xojo related, really, but certainly related to a project we’re working on for a client. Within a few hours I had half a dozen developers private message me saying they might be able to help. Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.
I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years. I think I’d be hard pressed to find such a friendly community. I call many on the forums my friends even though I’ve never physically met them. The few that I’ve met in person have lived up to their forum reputations and are really friends for life.
So maybe this is my belated Thanksgiving post. I am thankful that so many years ago I jumped both feet first into the tool. I asked questions – many of the silly and redundant. I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.
So if you are in need of a cross-platform development tool I highly recommend Xojo. It ain’t perfect but no development tool is. If you jump in I think you’ll love the community. I know I do.
What say you fellow Xojo developers?
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?
Will VB6 Apps Continue to Work in Windows 8? That single question has driven more traffic to this website in the past month than nearly any other question. I believe VB6 still has a very large user base so it’s very pertinent question for many organizations and developers. Perhaps Real Studio is an option for them, but we’ll get to that at the end of the post.
Visual Basic 6 is 20 years old. It’s stood the test of time and it while it’s showing its age it still functions and apps written on it still run in Vista and Windows 7. To its credit, Microsoft has made sure that this venerable product still runs on modern computers.
I don’t believe for a second that Microsoft is abandoning .NET, Win32 or COM simply because those are the foundation for nearly everything ever written at Microsoft. It simply doesn’t make sense for Microsoft to move to another set of API’s even if you believe that Microsoft moves to a new technology every now and then to make themselves a moving target. If anything, I believe that this might simply be a new way to develop apps but not replace anything.
While doing research for this post I ran across an unattributed quote supposedly from a person in Microsoft Support:
“We can’t make an official comment on our Windows 8 plans yet but it would be a likely outcome that VB6 applications will continue to work. “
I believe that statement but it’s not exactly a definitive statement. The real question, I think, is how bad will it suck? VB6 apps work in Windows 7 but without some work they look like they’re from the 90’s. Most app developers I know don’t want their apps to look that dated.
Microsoft has stated that the Visual Basic 6 runtimes will not ship after Window 7. This presumably means Windows 8 and beyond. I have heard that Windows 8 will be 64 bit only and that means that the VB6 runtimes will either not work at all or will have to be run in some sort of compatibility layer. So this means that existing apps MAY work, but only after jumping through hoops to install the runtime libraries and making sure the compatibility is set.
Let’s face it. VB6 is an old, old development environment. It was written in an age where computers didn’t have much memory and only one processor. Threading isn’t impossible, but the few times I tried to get it working in a VB6 app the result was instability and crashes. Threading is such an important thing in modern applications.
VB6 is object oriented – somewhat. For the time it was state of the art but since subclassing controls is impossible it makes for interesting workarounds and wrappers. Frankly it makes life more complicated than it needs to be.
Twenty years ago, VB6 was the cats-meow. The Macintosh was around but it was considered a toy (I disagree but that’s not the argument) and few cared about it. Microsoft was pretty much the only game in town. Linux hadn’t been invented yet and the internet was for a few hard core geeks.
This is where Real Studio starts to look more attractive. It works the same on Mac, Windows, and Linux. Web Edition brings some of the same ease of developing desktop apps to the web. In Real Studio I can subclass controls and objects (for the most part) all day long. It’s a modern object oriented programming language. Is it without foibles and inconsistencies? Certainly not, but it’s way more powerful than VB6 in many ways. Threading isn’t perfect, but it’s still light years ahead of VB6.
We’ve seen an uptick recently with people asking us to convert their VB6 application to Real Studio. Our VB6 Analyzer utility (found at http://www.bkeeney.com/consulting/vb2rbconversion) has been downloaded a lot recently. It allows users to scan their VB6 project and sends us a simple report detailing the number of forms, classes, libraries and OCX’s in use and lines of code and some other simple metrics. It’s no substitute for seeing the whole project but it gives us a nice way to guestimate the costs of rewriting the app in Real Studio.
Notice that I said rewrite the application. The only thing that Visual Basic and RealBasic have in common is that they have ‘basic’ in the name. It’s like comparing a computer from twenty years ago to a modern computer. Real Studio does things so much easier, better, and faster than Visual Basic that it’s really not worth trying to convert it line by line or even form by form. Believe me we’ve tried – the end result is that you end up spending as much time fixing VB6 code that has a better equivalent in RB than it would be to just rewrite it from scratch.
Is Real Studio a suitable replacement for every app? The answer is simple: no. Real Studio makes a really good cross-platform app, but that doesn’t always mean it will have all of the buzzers and bells available in development environments meant for each platform (grids in Windows come come to mind).
We are Real Studio consultants. That’s what we do and we’ve been doing it for ten years. Most of us spent a fair amount of time in Visual Basic before moving to Real Studio. If you decide to do the transition yourself you will hate it at first because Real Studio is different than VB. We all went through it and for a while you want Real Studio to be just like Visual Basic – trust me it’s not – and after you stop trying make Real Studio function like VB6 you’ll start to like it and get it. Transitions are never easy. For training videos, we have over 30 hours available at http://www.bkeeney.com/realbasic-training-section plus you could always hire us to come on site for training.
If you have VB6 project you want to transition please drop us a line and we can talk. If you want to get multiple Real Studio developers looking at your project, make a post at http://www.realsoftware.com/support/consultants.php which gets sent out to the Real Studio developers network.
Making a screencast video presentation is more difficult that you image. First you figure out the script, then you do the recording (perhaps more than once), then do any editing (cut the coughs and um’s, speed up long typing sequences, etc), add any callouts or special effects, then convert to the appropriate video format, upload the video and finally create an accompanying article to go along with it.
Whew! That’s a lot of work. I’ve done this for over nine hours worth of material so far!
We, BKeeney Software, are now offering streaming videos for REALbasic training with over an hours worth of free video (you do have to sign up for an account though). To say that this has been a labor of love is understating the scope of the project. With nine hours of video we’ve barely scratched the surface of all that REALbasic has to offer. We have many, many things still left on the plate. I look at this as a never ending stream of videos as REALbasic is always evolving (on a 90 day basis!) so the work will never be done.
With nine hours available now, what’s it mean for a month or year from now? I don’t honestly know, but as I’m writing this I’m encoding and updating another twenty-six minutes of video.
Since this is REALbasic I spend a lot of time working in one environment, Mac OS X, and doing debug runs in Windows 7 and Linux (Ubunutu) and show you the big, little and sometimes subtle differences between the platforms. You’re seeing how I approach a project from the ‘what I’m going to do’ to implementing it and doing final testing. And yes, you get to see me make some mistakes (hey, don’t we all?) and through the magic of post editing I’ll point those out when I do them so you’re not confused and then we show the correction process.
This is not a typical video training program. We have five hours of video just on the basic controls available for REALbasic. Not only do we describe what it does and some of the things to be aware of, we use the control in a project and examine what it does in Mac OS X, Windows, and Linux when there are differences.
My goal is to make you a better REALbasic programmer. I name EVERYTHING from RB objects to my variables in source code so that they mean something. At a glance you should be able to tell what your source code is doing because you’re not just writing code for right now, but you’re writing code for six months and six years from now.
Sign up for an account and automatically get a free Guest Pass. Poke around and take a look at the free videos. We’d love it if you’d sign up for a subscription. With our introductory pricing, a three month subscription costs $45. A year subscription is $150 which is a 20% savings.
What’s great about the video training? You can help direct what videos are done next. REALbasic has thousands of classes – some with poor documentation and examples. We can create the video training that helps you out sooner rather than later.
That’s it for now. Happy coding!
To view the Linux survey results, please see http://www.arbp.org/blog/topic/?t=7. Take a look at the survey results for Linux and feel free to respond below.
What did we fail to understand about Linux? Do you have a different opinion?