You can call into Linux APIs to use methods and properties that are not built into the framework by using the Declare command. To create a Declare statement you first need to track down the API you want to use using Linux documentation.
Xojo Blog Posts
You can call into Cocoa Touch APIs to use methods and properties that are not built into the framework by using the Declare command. To create a Declare statement you first need to track down the API you want to use in Apple’s documentation: Apple Developer Documentation. Most of the time you will reference the Foundation and UIKit libraries, but there are many other libraries as well. Xojo Declares use the Objective-C names so be sure to refer to those in the documentation rather than the Swift naming.
A topic that comes up every once in a while on the forums is how to share code among several projects with more than one developer. Quite often what users try to do is to export classes and modules to a shared folder and have everyone include those in their projects. There can be issues with this technique, especially when using shared services like DropBox.
Because of the latency involved, external items shared in a shared folder on a server or a file sharing service are never truly in-sync with one another. While this technique works with a single developer across two or three projects, it gets more and more complicated as you add more projects and even more-so if you try to add more developers.
One of the largest issues with this type of system is that everything must be kept in sync all the time. Making one little change to a shared file or method which works fine in the current project could completely break a project that you haven’t worked on in a year. When you do get around to working on it again, there’s three possibilities:
- The project compiles and everything works just like it did before.
- The project doesn’t compile.
- The project compiles and doesn’t work like it did before.
With careful planning, you’ll probably hit #1 75% of the time, but the other two are wrought with problems. If the project compiles but doesn’t work correctly, you may not find out until you’ve given it to your users, with the worst case being unrecoverable data corruption. If it doesn’t compile, then what? The shared code is now required to be different in two different projects and you may have no history as to what was changed.
Thankfully the folks at who are maintaining Subversion at the Apache Software Foundation made it super easy to create shared code repositories using a feature called Externals. (For those of you that are using Git, I suggest looking into Submodules. Of the two techniques I’ve encountered, Submodules seem to require the least individual overhead.)
The linker is not technically part of the compiler, but it is needed to make a completed app. The purpose of the linker is to combine (link) all the various bits and pieces of machine code created by the compiler along with the necessary information to create a runnable app for the OS.
This is the ninth and final post in our Compiler series. Previous posts:
Code generation is one of the last steps of the compiler. This is where the compiler emits actual machine code for the IR that was previously created.
This is the eighth post in our Compiler series. Other posts:
Object Oriented Programming (OOP) puts in our hands the ability to create apps in a flexible and powerful way. Xojo embraces that philosophy in the Xojo language itself, allowing us to implement code in a flexible way for reuse, extension and maintainability that reduces the development cycles. One of these language tools is, in fact, common in other low level programming languages: Casting or type conversion. If you are interested in this (and you should be), continue reading and discover what it is, why you should be interested in it and how can you use it in your next Xojo app!
The last post covered optimization in general. In this post you’ll look at a specific optimization called “loop unrolling”.
This is the seventh post in our Compiler series. Other posts:
Like his father, my teenage son loves video games. The single player games where you take a character through some kind of adventure are the ones I like most. These usually have a fair number of AI-controlled enemies that must be defeated. My son, on the other hand, prefers to play against other human beings. When I asked him why, he said, “The AIs are so predictable.” To prove this to me, he took over when I was having trouble defeating a particularly difficult enemy and quickly dispatched him, narrating his strategy as he went and barely being scratched in the process. My son is an elite player compared to me partially because he puts a lot more time into it than I do but also because he loves video games far more than I do.
Just as people have varying levels of skill and interest in video games, the same is true of app development. There are those that are happy to devote enormous amounts of time to learning everything they possibly can. They don’t care how long it takes. They want to have control over everything and are willing to do whatever is necessary to make that happen. I’m so glad those people exist because there’s a lot of great software that might not otherwise have been created without them. I’m not one of those people. I really want to focus mostly on what makes my application unique, abstracted from the nitty-gritty of app development.
That’s why I have always been attracted to tools like Xojo. I am a citizen developer. Of all the job titles I have had over the years, all of them in tech, none have ever included words like programmer or engineer. I do some software development but it’s just a part of my job. It’s something I do to help me in my work or to help my co-workers.
In honor of Pi Day 2018, Xojo Pi licenses will be free! Xojo Pi licenses allow you to build console apps for Linux ARM for use with Raspberry Pi 2 and Raspberry Pi 3.