How do you write code once, and use it in multiple projects?
For example, let’s say I have an AddressBook class and I use it in my Desktop app. I want to also use that class in an iOS version of the app, which is in a different project.
I could just drag a copy of that class from one project to the other, which I have been doing.
Is there a better way? The problem is that if I change the class in one project, I have to remember to do it in the other.
Is there a “best practice” for this?
Best ? I do not know, but I would highlight (select) the entry in the Navigator and Copy, change to the target project and Paste (and if this does not works, I wil use a simple Copy / Paste of the code).
Hi, thanks for the reply. I’m not having problems moving the code around - which I think it what you’re suggesting here. What I’m asking is how do I contain the code somewhere, say I exported my AddressBook class to the file system, and then drag it into any project I want to use it in.
I can do that too, but it creates a copy because when you drag AddressBook.binary_code into the project, it makes a copy in the project, so a change to it in the project isn’t reflected at the source on the file system.
It feels a little messy to do this.
svn externals
git has something similar
Typically the way to do this is to make the project item external in each project with a shared path. To do this, you can right-click the project item in the navigator and select “Make External…”
there are a bunch of caveats with this mechanism you should mention
this makes the item binary or xml which is not optimal with version control - diffs basically dont work well
you can’t export modules with sub modules this way
svn externals work with plain text projects and you can share modules etc that contain modules & classes
Thanks @Norman Palardy & @Anthony Cyphers -
I quickly checked - externals is sort of ok. It makes a copy. A change in project 2 is not reflected in the file system where the ‘external’ class is located. Still… it’s not bad.
I see where Norman is going with svn externals - I use git. I’ll look into the workflow for this.
at least svn externals keep 1 copy and other projects / repositories just references that other repo
and you can tie the external set up to a specific version or track all changes if you want
and diffs still work nicely
Thanks Norman
At first I thought external re-usable building blocks were a great idea, but they come with their own headache - if you make a change some time later, it may break older apps that use the same code. For this system to work you have to be very rigorous about encapsulation so that interfaces never change. For me it’s too much risk and I’ve gone to internals only now. I copy from one project to another so each is self-contained.
@Julia Truchsess
Thats also what I’ve been doing. It has not been a problem yet - I just see it being problematic. The obvious issue is say, fixing a bug or changing features in your object (like we’ve been talking about).
In PHP there’s composer which mitigates this really well. Likewise, .Net has Nuget. Failing those, in .Net you can have shared references between projects or use compiled DLLs… XoJo doesn’t have these right now.
I’ve only been using Xojo for about a year almost… and not on a daily basis so I’m in no way an expert. I often wonder if there are easier/better ways to do things.
you can tie an external to a specific version so one project can always use a specific version and be unaffected by changes from other projects
or you can make it NOT tied to a specific version and keep them up to date
entirely up to you when you do / dont update other projects with new version from the originals
and the external is part of the project your pulling the code into so it is project specific
and really fairly easy to set up
I extensively use external items in all my projects.
yes you have to be very strict with the method parameters, but the way I use it is that if I add another parameter
I always set a default value : , aNewParam as string=""
that way, the default behavior is maintained and the other apps still work.
if really this is not possible, then when you recompile the other app, you usually get a compile error because of
the missing parameter and it is usually easyly corrected.
I dont use binary or xml external items at all since you cant do decent diffs or get a useful history
The other limitations are also not worth it for us
We have a common set of code that uses nested module & classes which Xojo’s external items cant handle
The diffs aren’t really a problem when using external items in xml. I use Arbed for the rare occasion I need a diff. But windows and classes that are external make me bonkers because they dance like drunk when editing properties.
modules that contain modules and other classes dont work
we have far too many to do any other way than svn externals (500+ classes and modules nested down in some cases 3 levels)
for a single developer you can make externals work
too fragile for a team of more than 1
[quote=483807:@Norman Palardy]there are a bunch of caveats with this mechanism you should mention
this makes the item binary or xml which is not optimal with version control - diffs basically dont work well
you can’t export modules with sub modules this way
svn externals work with plain text projects and you can share modules etc that contain modules & classes[/quote]
As has already been noted, there are caveats to every method. Which to choose is user- and project-dependent. For instance, do they have access to text projects?
[quote=483809:@Rob Hallock]Thanks @Norman Palardy & @Anthony Cyphers -
I quickly checked - externals is sort of ok. It makes a copy. A change in project 2 is not reflected in the file system where the ‘external’ class is located. Still… it’s not bad.
I see where Norman is going with svn externals - I use git. I’ll look into the workflow for this.[/quote]
I haven’t tested in a long time, but if you use Externals in Xojo, I think the best way is/was:
1.) Make external in Project 1
2.) Save Project 1
2.) Copy it in the navigator of Project 1
3.) Paste in to the navigator of Project 2
4.) Make external in Project 2 at the same path
5.) Save Project 2
And I made no assumption that they’re not using that version.
