That’s what makes it so frustrating. Xojo is so close, but they don’t seem to be pursuing it. It’s like they are satisfied being just as partial a solution as everybody else. All they need to do - and I say this knowing just how much of a challenge it really is - is support multiple products in one project. No more desktop, web, console, mobile, and android projects. Just a Xojo universal project. That way I can keep my logic in modules, and my views are basically just thin containers around that functionality. I do this already!
The alternative is properly supporting shared code, but that’ll require a yet another saving format. Which isn’t necessarily a bad thing either. But Xojo has to do something.
My advice comes from direct experience. I started my Beacon app with the intention of bringing it to mobile. Nearly 10 years later, it’s still just as distant a fantasy as day 1. Xojo simply doesn’t give us the tools to do cross platform well, and doesn’t seem to want to. Knowing what I know today, this app would probably be browser-based. And not in Xojo.
Certainly one of the challenges is that in targeting multiple platforms, you are literally dealing with multiple moving targets. In another thread, we’re discussing how the upcoming macOS Tahoe will bring layout problems due to the changes in control sizes. Multiply that by every platform you are trying to hit and the problem gets exponentially more complex. And that’s just layout metrics; getting down into networking, etc. and the problems are even more divergent.
I think you also need to factor in the difficulties of dealing with OS vendors whose interests are not served by the easy creation of cross-platform apps. They would much prefer you only developed your applications for their platform(s) and are not exactly enthusiastic about coordinating their APIs, etc. with their competitors. In fact, it often seems like they intentionally change their development methodologies to maintain developer lock-in.
In the end: if this was an easy problem to solve, it would have been solved multiple times already, and well. While there is always room for improvement, Xojo does pretty well for what they are aiming for, even if we wish they would aim a little higher sometimes.
I can confirm that you can share code between projects using the xojo text format. We do it in all projects with our database module and standard modules we created to unify different platforms.
Just create git submodules and place your shared modules in it. Then add the code to the project in the same folders. It’s a bit manual setup but then it is working.
There’s just one caveat when you add a new class to the module you have to manually add it to the project file of other projects.
And yes you have to be careful when changing code in one project because it could harm other projects if you change parameters of methods for example. We address this by having different branches in the submodule as well.
An additional problem with git submodules is you cannot work on multiple projects at the same time. You need to commit the submodule, push, then pull in the other submodule. Plus, the normal push/pull in the project repo is not even good enough.
The submodule experience sucks. I’ll concede that technically, it works. So does copy and paste. They’re both pretty awful.
These kinds of issues are why I say multiple products in one project would be the better solution, rather than improving code sharing.
I typically work out code sharing by having the shared resources in their own repository(s) then modifying the project files to point to the shared resource after adding it to each project. So I’ll have a directory structure that’s something like:
Each platform-specific project file references the GraffitiSuite and VerificationKit directories, which are each their own repositories, and the project-specific (Project1, Project2, etc) directories are individual repositories. If I make changes to GraffitiSuite in one project, it shows up everywhere with a project reload. I can also fairly easily diverge source by changing the relative paths. Of course my method requires editing the project files by hand, but I feel that it’s worth it and never really bork the files. It’s a method that makes sense to my overworked brain, and allows me to quickly test multiple projects against a single set of changes. I can also easily use this method to have shared resources per project (for all its constituent platform-specific xojo_projects).
So my project folders will contain xojo_project files with relative paths:
I can set this up per-project by adding the objects to be shared, saving the project, closing the project, then editing the paths in the xojo_project file.
I’ve tried submodules and it annoyed me to no end. I’ve tried externals and they’ve always felt severely lacking and incomplete.
Yes, I’ve made the argument in the past that Xojo should consider moving to non-native controls. There’s pros and cons to such a move. Given Xojo’s limited resources, there’s some undeniable advantages. I’m not convinced they should or should not.
It’s the same with Delphi. In the project you choose the platform to compile for. But same, no native controls (which I hate). So for Mac I choose Xojo, for Windows either Xojo or Delphi.
I already do that in Xojo for Mac & Windows and I guess Linux would not be that hard to add too. But also creating apps for mobile from the same source code will be undoable I guess, reasons for that are mentioned above. Coding for multiple desktop systems isn’t a big problem, although code needs to be tested thouroughly for OS-specific problems with controls.
Xojo Binary Project and Xojo XML Project work perfectly well with version control. It’s a bit annoying to use Binary because you then need to use Arbed to compare the code. But I’ve been using XML now for some years and it’s fine, really. Using external items in a simple manner is way more important to me than using the Xojo Project format.
It’s called “Xojo Project” and produces a collection of text files that are not only easy for a version control system to handle, but is actually designed for it.
XML projects are text-based as well, but are a representation of the binary project, and not actually designed for version control. While it works, it definitely has some quirks.
Binary projects store everything in a single binary file that is trivial to share, but is only as compatible with version control as an image, for example. As Beatrix mentioned, there is Arbed that is intended to fill the gap, but in my opinion, demotes your version control to a glorified backup.
Truth is, none of the three formats is full-featured. There’s been talk for years about a new “one format to rule them all” kind of format, but I think it’s unlikely we’ll ever see that come to fruition.
I have started building a lot of my desktop UI elements in HTML because the native controls can end up feeling dated and restrictive at times. If you’re decent with Javascript you can write a whole app this way, but one could make the argument that you’re better off using a different solution than Xojo at that point.
GraffitiSuite has a cool product called GraffitiBundle that kinda does something similar, you write your app as a web project and GraffitiBundle wraps it up as a desktop app, similar to the way Electron works. You’re still limited to what you can create as a web project but you get a more customizable UI thanks to Bootstrap.
the same here, works on Desktop project, but don’t work on iOS project…
Var f As New FolderItem
If DebugBuild Then
f = GetFolderItem("").child("Contents").child("Resources").child("Levels").child("level"+Str(level)+".txt")
Else
f = SpecialFolder.Resources.child("Levels").child("level"+Str(level)+".txt")
End If
