So I’m building a desktop app and my Listbox has a super of DesktopListbox.
But I’m looking down the road, and I see that there’s a super called MobileListbox, which I’m presuming has to be used for mobile apps.
But I infer then that if I want to deploy on different platforms, I need to have two apps and two sets of code to support. Or am I missing some technique like making multiple versions of the same window in the same app with different controls so that they can share code.
You’re on the right track. Ideally, you’d isolate the logic of your app into abstract classes that communicate with the UI in a way that is platform-agnostic.
Of course, that’s only if you need to transition between app paradigms - desktop vs. mobile vs web. A window built for any desktop app can use the same code for Mac, Windows, etc.
There is a way to have common code amongst Desktop, Web and Mobile by placing your code inside a separate External Class, but you will need to have three identical Desktop, Web and Mobile interfaces.
If I understand you guys, you’re saying to have Project 1 for the Desktop and Project 2 for Mobile and use external classes to make a common codebase that has the code for the window events and control events and for all of the database and program-specific functions. And you’re not going to have a single project with both sets of windows and controls in it and some type of conditional compiling for each platform. Did I understand you so far?
I’ve never heard of external classes before and I looked it up in the documentation, but it seems like it’s written to explain it only if you already know the answer and what you’re doing. Grok has helped me understand it a little better and given me a step-by-step approach to using interfaces to the desktop or mobile versions of the controls in separate projects and adding common code via external files. But it sounds like I won’t be able to put the classes or structures that I use in the external class.
So far, I’ve speed-watched Garry Pettet’s 2021 video on external classes, and I’ll have to watch it again tonight when I really have time to focus on it. But it didn’t demonstrate how to use interfaces to share code for common windows and controls on different platforms. Are there any videos you know of that you can recommend that show how to do this?
You are correct. I have enclosed a single app with two windows that shares External classes amongst Desktop, Web, iOS and Android applications ie four projects, but one code base.
https://www.holymackerelsoftware.com/Downloads/MethodPairsApp.zip
It is a totally different way of approaching Xojo, but it works.
Wow. I downloaded the app, and it’s amazing. I can almost get a sense of what’s going on. It’s also just beyond my reach to understand — which is why I’m looking for the video that explains step-by-step what’s going on so I understand how to build it.
Is this app demonstrating the external pair technique? I got through about the first 14 minutes of that video but then couldn’t follow once and don’t know what to do after you started telling us to compile it different ways.
Unfortunately, this is the way Documentation is written these days. Most of the time, I compare that to a dictionary: in a dictionary all of the words are listed, but can you learn a new language just reading a dictionary ?
I think the reason for this is the writer knows the subject very well, and that’s fine, but the writer needs to think about the reader that most of the time is a newcommer.
I have been in IT for a long time and dicovered that the best way to learn a new software is to write the material to teacch that software.
It depends on what part of the documentation you are reading. The Language Reference, which is usually at the top of search results, is not meant for beginners. There are other resources on the documentation site that are pretty good.
I never wrote documentation like anyone else did back then, but I’ve done extensive work in training, and especially communications.
I think my approach to really use this topic will have to be to get this running on the desktop first so I can get it to my testers. Then I’ll try making a super-simple app like I see in this video (or in another video) until I’m comfortable with the technique. Then I’ll convert my app using those techniques to have external elements. And then make an iOS version using the elements being shared.
One thing I’ve noticed is that the parts of the videos I’ve looked at haven’t had anything to say about interfaces. So perhaps interfaces weren’t the ideal recommendation on how to build this. But I sure appreciate when knowledgeable people devote their time to explain complicated topics for the rest of us. Even better is when there are multiple presentations targeting us at different skill levels so that as I figure out one part, I can graduate to the next level.
If anyone wants to pursue this path, I have written most Methods to work across all environments (Desktop, Web and iOS) plus work with GraffitiSuite Objects. For example, here are the Methods for just a ListBox/GraffitiGrid:
David,
I feel like I don’t know enough at this point to say yes or no that is the path I have to or want to follow. Is this an implementation of the external pairs’ technique that you describe in your video? And your post makes it sound like there are alternative options. What are the options?
Yes, the video and the app are the same. No, this is the only alternative I’ve pursued.
It is definitely not for the faint-of-heart. I suggest you get one app, with an External Module of Methods, going first before considering making it cross-environment.
If you’re happy to share, then I’m happy to learn.
I agree that at this point, I want to get an app working and cleaned up. Then I’ll move a bunch of routines to an external module. And then I’ll work on this method — or consider other methods — to make it cross-platform.
I’m certain than any advice & examples I can collect along the way will be helpful.
