I read some threads about this six months ago and didn’t form any conclusions. But I didn’t need it at the time and I deferred the topic.
But now that I have a Mac version of an app that’s close to ready to release, I have a question about the iOS version. Since lots of the containers for the Mac version are desktop controls, I know that I’ll have to make a different file to compile for iOS. What’s the best practice to minimize having to make code changes in two places? I’ve never done anything with iOS before.
Since the macOS version and the iOS version are two different project types, you will need to maintain two repositories for them. However, it should be possible to share code between the two projects here and there using submodules (Git & Co.) and externally deployed methods, etc.
While Xojo aims to be cross-platform compatible, in the Xojo universe this unfortunately only means that you can create apps for various platforms with Xojo, not that this is possible with just one project…
sure it works, but how about version control, the files are usually in other project folder.
or if you change the methods in one project it could break the other project you will recognise at next compile.
When using Git for shared code you don’t end up using the External Items feature.
There are some options for using Git repositories instead, but I haven’t read through them all because there’s a lot to read up on. Check out submodules, Jürg talks about something called MonoRepos, and if you Google around you might be able to find what Norman has to say.
This is why I don’t use shared code. Sometimes a project will need project-specific tweaks to classes I’ve designed to be generic. I could spend the time engineering a generic solution that would work for all projects, but I choose not to for a number of reasons.
I don’t find updates as hard as people make them out to be, my diffs are usually pretty simple. Maybe y’all need to commit more frequently?
I use shared external objects in many of my projects, which work OK.
For example, if Project A and Project B both use the same external, both projects are open in the IDE, and I make edit changes in Project A, Project B’s version will be updated immediately. That’s nice.
However, a longstanding issue is that the text format for externals is an XML format which is very hard to read and to diff and use in version control software.
For example, here is a comparison of the same method in the two formats:
Xojo Text Format
#tag Method, Flags = &h0
Function MacOSUniversialBuildType() As String
var f as FolderItem = app.ExecutableFile
var bs as BinaryStream = BinaryStream.Open(f)
var tag as integer = bs.ReadUInt64
var tagHex as string = tag.ToHex
select case tagHex
case "CAFEBABE00000002"
return "Universal"
case "CFFAEDFE07000001"
return "Intel"
case "CFFAEDFE0C000001"
return "ARM"
else
return "Unknown"
end select
End Function
#tag EndMethod
Xojo XML Format
<Method>
<ItemName>MacOSUniversialBuildType</ItemName>
<Compatibility></Compatibility>
<Visible>1</Visible>
<PartID>1733146623</PartID>
<ItemSource>
<TextEncoding>134217984</TextEncoding>
<SourceLine>Function MacOSUniversialBuildType() As String</SourceLine>
<SourceLine>var f as FolderItem = app.ExecutableFile</SourceLine>
<SourceLine>var bs as BinaryStream = BinaryStream.Open(f)</SourceLine>
<SourceLine>var tag as integer = bs.ReadUInt64</SourceLine>
<SourceLine>var tagHex as string = tag.ToHex</SourceLine>
<SourceLine>select case tagHex</SourceLine>
<SourceLine>case "CAFEBABE00000002"</SourceLine>
<SourceLine>return "Universal"</SourceLine>
<SourceLine>case "CFFAEDFE07000001"</SourceLine>
<SourceLine>return "Intel"</SourceLine>
<SourceLine>case "CFFAEDFE0C000001"</SourceLine>
<SourceLine>return "ARM"</SourceLine>
<SourceLine>else</SourceLine>
<SourceLine>return "Unknown"</SourceLine>
<SourceLine>end select</SourceLine>
<SourceLine></SourceLine>
<SourceLine></SourceLine>
<SourceLine>End Function</SourceLine>
</ItemSource>
<TextEncoding>134217984</TextEncoding>
<AliasName></AliasName>
<ItemFlags>0</ItemFlags>
<IsShared>0</IsShared>
<ItemParams></ItemParams>
<ItemResult>String</ItemResult>
</Method>
I’m glad I asked and I feel this is still a hot topic. I have to re-read the section in the docs about libraries. Is that what you’re talking about when you reference “shared external objects?”
If I have a routine where the code is the same but maybe the screen coordinates change based on the platform. Or maybe there are minor differences because of properties. Does it make sense to have a single code base but include conditional compiling instructions? I’ve had success with that technique in a different language where I had to program different database calls for Mac & Windows.
No. As far as when I’m speaking, I’m referring to “Shared code” as the idea of having code maintained in a separate project, being used in another. Think along the lines of using a Preferences Module in a larger project like MyGreatApp. The Preferences Module is the “shared code”.
External Items is the IDE feature that allows you to use code from another project. It does not work with Plain Text projects, but there are better solutions for plain text projects when you use source control.
I can speak specifically to Git, so my posts mention Git by name; though I’m sure there are solutions for the other source control systems out there. With Git, we don’t use External Items and trick the IDE basically. Xojo loads the items as if they were regular project items.
I am avidly anti-Library because the way Xojo implemented them tosses the source code out, and I’ve had far too many problems with that bullshit in the past.
I tend to lean toward “no” if it requires compiler conditions. Circle back to the Preferences Module example. It’s a great use case because multiple projects would need the same centralized preferences reading and writing code, but it doesn’t need you to specify “this was compiled by Project A” to do something specific.
I saw a video or maybe it was a blog post last May about sharing external items and also libraries. I thought I bookmarked it but can’t find it now. I’ll follow your link and see what it says about external items. I haven’t used Git because my projects have all been solo.
I had the impression that Libraries were the way to go some I’m very interested to hear more about their liabilities. And I remember that thread from last Spring mentioned plain text projects but all I know about the technique is the name.
Is it a safe assumption that I should give the Desktop Canvases and the iOS Canvases the same name so that the code stays the same between the two projects?
You won’t be able to share a DesktopCanvas and MobileCanvas between projects, only non-UI logic.
You can abstract the drawing into a class that accepts a Graphics object instance and share that code, but not the [Platform]Canvas itself. Code written in this way wouldn’t need to know the name of or type of Canvas it is working with since you pass it an instance of Graphics (directly from a Paint event).
You should definitely check out source control, even as solo developer. It makes building your project so much easier. You can test ideas safely and easily because you can roll back reliably. AND SO MUCH MORE!
I have 84 numbered versions of my project on my machine going back to May. What I like in the video about Git is that it can identify the differences between versions, which would’ve helped me a couple of times. Sounds like it doesn’t support the Lite version, but when I have to upgrade to the Pro license then I’ll get it.
What I was asking about the code sharing, let’s say I have a canvas. I know it’s a desktop canvas in my project and it’s called txtOverlay. I’m thinking that in iOS, it will be an iOS canvas but if I call it txtOverlay, then all of the routines that use it won’t have to change, will they – as long as they’re changing properties that both the iOS and Desktop versions support.
I could have sworn Lite was allowed to save as plain text in more recent IDEs, but they edited the blog post about it and there’s no archive.org copy prior to the edit, so I don’t know for sure what you can do. I know they no longer offer Lite licenses, but historically they did exist (and some are still active), so it would be nice to know what the terms were.
You can check, the Save As dialog will either have a Format popup menu or it won’t. Select “Xojo Project” if you can, otherwise it means they changed their mind about the “Lite gets source control” announcement.
This isn’t a thing. You can’t share UI / controls between Desktop and iOS/Mobile projects, that’s what I was saying above.
You can abstract the drawing into a class that you could share, but when done correctly, that class wouldn’t need to know whether it’s an iOS/MobileCanvas or DesktopCanvas that’s drawing because the Graphics object is cross platform abstract.
