I’m really hoping that Xojo also implements a way to share code between text based projects as text so I can still look at the diffs and check in those changes with appropriate notes.
This is what unit tests are for
5 Likes
You have to compile one for each posible architecture you want to deploy, maybe kind of annoying to recompile all of them when you wan a change, the ide needs to be closed?
In targets like Android, you have to bundle ALL the libraries for each posible architectures making the file a HUGE waste of space I do look at file size when choosing beetween mobile apps.
That’s exactly how plugins work now. What do you expect differently from libraries? The advantage is you don’t have to build them in C++.
To be what it was promoted: Portions of protected XOJO CODE that are easily shared between projects and developers.
No need to reload the IDE
No need for compilation
No more dependencies or bloated executables
…
2 Likes
I’m sorry, I thought libraries were the mechanism to build a plugin in Xojo code. I may have missed the memo. I can’t find anything on the Xojo website or blog that refers to what they are.
1 Like
It used to be listed on the roadmap as “Plugins made with Xojo” but was changed to “Xojo Libraries”. I don’t expect that they’ll be full-fledged plugins. At a minimum I hope they’re adequately protected but would love to see them compiled.
1 Like
That’s the major thing here, nowhere to read what xojo actually plans to present us. We requested something like dynamic (precompiled) libraries to extend xojo. Perhaps we get newer types of modules? Who knows.
For sure I’m interested in getting some xojo responses to this so that we know a little more what to expect.
Xojo gave up on “plugins made in Xojo”, to something more like a “protected shareable module safer than an encrypted module” … we will still know.
precisely, if you program in xojo, someone else has to write the plugins. If, however, you can write your own libraries of functions that you often use in all software (as is normally done in the .NET framework world) you are helped. Personally I tried a few times with “make external” and I only messed up
2 Likes
I only work that way. I find the text projects too annoying.
1 Like
I’m not following you. What do “text projects” have to do with using make external?
by text project do you mean the difference in saving the text/binary project?
I’m quite unclear as to what we are dealing with. Is a library a collection of Xojo source methods? If so, are they text or binary? Is a library a collection of compiled binary methods? Either way, if I reference one method out of the (say) ten that the library contains, do I just get the one or are all ten included in my app? And so on.
I’m using XML. There have been procedures suggested for using common code in text format. But I found those overly complicated.
I believed that the use of “make external” was independent of the type of project format
Nope.
Let’s say we plan how this feature could look like.
First this would be a new project type called Library. You add stuff there, Xojo compiles it and writes the intermediate LLVM representation to a new file. That is what I would assume and this would not work for Android since LLVM is not used there!
This intermediate representation would usually be after the #if are processed, which may cause problems. So either they compile it for each platform to evaluate things like “#if targetWindows” correctly and make a Mac and windows version of the library. Or they change the way it works to keep #if somehow in the intermediate code and evaluate them later.
As you refer to framework classes, you may need to decide upfront on which framework variant to use (console, desktop, iOS, web). it would be great if we could have all frameworks available at same time, so a library could have iOS screen, web page and window at same time.
Another thing needed would be the Xojo IDE strip the items to their public interface and include that with the library, so the IDE could on the receiving side display the items with their properties, methods, events for developers to see what is available. At least for auto complete this would be needed.
For distribution to other developers you may need to pre-build the library to intermediate code individually for all combinations of framework, OS and CPU type. Just like we build plugins 13 times to cover all combinations. And then you may need to do this for each Xojo version individually since compatibility may be limited up and down the versions.
Good for building would be that we could just add these libraries to projects without pre-compilation since all is packaged already. But a few of the problems could be avoided by cheating and just doing encrypted source code again.
7 Likes
That’s a great explanation / proposed structure Christina - thanks.
a better way to share code between projects and between people.
a project group could also help to reuse source code. vb6/delphi/ms vs have it…
the benefit is, it is cleanly separated.
Example:
project group
core library source project
business library source project
desktop app project
android app project
iOs app project
I use externals successfully for large collections of universally-applicable utility methods, like the legendary StringUtils and ArrayUtils, my own collection of Utils, and the pList class from MacCrafters. I also have a few simple shared controls and an updater system module. Problems have arisen when I’ve tried to share more specialized classes with complex functionality across multiple apps.
2 Likes
One thing I discovered today and that is only fleetingly covered in the docs is that I can use my own constants in conditional compilation. Such as:
#if app.myConst=27 then
// May be compiled depending on the value of myConst in this particular project
#endif
I had hoped this existed, but most of the places where conditional compilation is discussed, only the target constants are mentioned, so I nearly missed this.
I am starting to look at a second project, which will use chunks of code from the first, but with some variations that I can handle with conditional compilation. That won’t really scale but will be useful in this instance.
1 Like