We have a very large application that consists of many interrelated segments that is currently running in Visual Foxpro using dbf files. Visual Foxpro was discontinued many moons ago, but this application was initially started in the 80’s and has been running for decades. And, of course, it has gone through many, many updates and modifications.
We are now considering a re-write, but one of the HUGE concerns is the code-test-debug-compile-deploy cycles that this would require, especially considering this application would be very, very large in order to handle all the various options.
Prior to Visual Foxpro, we built this application in FOXBASE (before it was purchased by Microsoft) and one of the neat things you could do with Foxbase was build a number of .FOX files and call them in your application. So one of those could handle order processing and one of them could handle the accounts receivables function. If you had a bug in the order processing process, you only had to regenerate the FOX file for order processing.
Has anyone come up with a way to break up a large app into separate EXE’s and call the one needed from a menu system so that you could reduce the build time for making changes to an application?
There is no way for Xojo to break up an app. You will need to create each app for it’s purpose. You can setup a main app that serves as a menu that will launch each sub-app using the shell class.
Smaller more focused apps can be a good strategy. Also, you can share code between them, which will have pros and cons. Without knowing anything about your app, I can’t tell you whether this is a good idea. Even if I could, my opinion would be subjective anyway. I agree with you that massive apps that take forever to compile can become hard to manage and improve.
If Xojo cold generate dynamically loadable libs (.dll / .so / .dylib), it would be great to solve exactly this kind of thing, modularization. One standard app could have a DLL with some capabilities, and the user could opt for an advanced module and you could just ship a new more powerful DLL (or new version of that module).
You’ve responded to my posts in the past, so thank you for that.
How big? Well, there’s been 2 or 3 developers working on enhancements to this app ever since I first wrote it back in the 80’s. In summary, this application is used by a $ 300 million dollar bakery and it pretty much handles everything from customer management, order processing, production scheduling, product costing, on and on.
In terms of KLOCS, I couldn’t begin to estimate but it’s in the hundreds of thousands.
I’ve had a good amount of success creating a set of “shared libraries” which are external Xojo items (.xml format) shared across multiple projects which include key functionality like database connection, mail delivery, shared class interfaces, etc.
Note, this takes some real work (as all large projects do?) using things like #pragmas and attributes along with polymorphism and overridden methods to handle Xojo’s framework and API changes but… it allows a big part of the business logic and “secret sauce” to be shared across many different Xojo applications of various type (web, desktop, mobile, console) and vintage. (from 2019 to 2023 versions of Xojo)
Additionally, I keep these shared libs are in their own git repo so as necessary, I can keep a legacy code branch of the shared libraries repo around to support older projects which need now-out-of-date functions. (This helps keep the shared libs from getting too bloated over time)
Having the “shared libraries” be in a git repo (and synced in my case with Github) means I can have them on multiple computers as well and they can be shared with multiple developers.
Is this as good as being able to make external dynamic libraries in Xojo? No. But it does allow “core”, broader-scoped features to exist externally and be worked on & improved working in multiple projects/multiple versions of Xojo.
I agree with Rick above, real external libraries (DLLs, dylibs) written in Xojo would be a best solution, but I’ve had real success with maintaining external shared libraries in a very large code base across multiple “services”(console apps for background processing, data migration, resource control) with multiple Web front ends and a Desktop application used for product configuration and more complex data management.
One possibility is writing the logic of the different “modules” in Xojoscript, which would be loaded either immediately prior to execution or scheduled to be reloaded from disk x number of times per day.
This way you could make small changes and fixes to your logic without re-deploying the executable. You could even store the xojoscript files on a shared drive, although I’d recommend keeping a local cached copy in case the shared drive ever becomes inaccessible.
This would have a performance penalty but it may be worth it, only you could decide that for sure.
We went with @Brandon_Warlick’s menu approach 20 years ago and it has worked quite well. Our “application” consists of 100+ Xojo projects, with a ton of shared code. There are a bunch of gyrations occuring behind the scenes in terms of updating code and shared libraries, but it has worked very well. I can update a single set of functionality (orders, inventory, check format, reporting, etc.) with impunity. Each user only sees the functions they have authorization for (on the menu) and only those .exe’s are ever installed on their computer. They have no physical access to any of the other functions. Sure, there’s a fair amount of copy/paste going on, but each xojo project is slightly different anyway, so having a universal do-all project would be very unweildy.
Here’s another issue, I’m concerned about. With multiple EXE’s, isn’t there a penalty in waiting for each EXE to start when they go from one option to another? Of course, you wouldn’t have this issue with one monolithic EXE, but is this one of the disadvantages of the smaller EXE’s?
The way we did it was to have a xojo project that acts as the “menu”. It presents the authorized options to the user and then launches the exe as needed. The 2 obvious benefits are 1) we can restrict the user from ever seeing and downloading the exe, and 2) we can update/modify a single set of functionality without affecting anything else. And I guess 3) we can create a speciallized exe for a single customer with slightly different and unique functionality.
No. The advantage of multiple exe’s is each one is small enough that it starts very quickly. As opposed to a single monolithic exe that takes some perceivable time to launch.
@John_Fatte - what I do is similar (though probably in smaller scope than what you and @Tim_Hare do).
The desktop app is able to launch various web applications (by going to the URL) as well as other Apps (Mac) or .Exes (Windows)
A lot of users always have a browser open, and opening one more page isn’t a big deal.
There are some complexities with managing authentication but if the use is all internal (i.e. only accessible if user is on company network locally or via VPN) and the sites simply aren’t available to the outside world (no public DNS) it’s manageable.
In general, opening a web page somewhere on the local network is very fast and doesn’t consume a lot of resources. (this is assuming you don’t need desktop-only features like direct access to hardware peripherals via a serial port, etc.)
(makes updating easier too if internal web apps is a viable option; only have to update the one web app)