Geoff just wrapped up the Keynote at this year’s XDC here in beautiful Denver, Colorado. The stately ballroom at the Magnolia Hotel was packed. After…
Xojo Blog Posts
During his Keynote, Geoff announced the winners of the 2018 Xojo Design Awards, honoring excellence in software design in the following categories: Best Developer Tool, Best Specialty App, Best Consumer App, Best Mobile App, Best Utility App and Best Cross-Platform App.
These apps represent the creativity, flexibility and diversity in the Xojo Community – support this year’s winners and the whole Xojo community by sharing and reviewing their apps on social media and app stores!
This year’s winners are:
The Cloud is everywhere these days. And lots of companies offer Cloud products or services. Why should you use them?
Starting with Xojo 2018r1, your Xojo apps require the libunwind8 library to be installed on your Raspberry Pi. Here’s how to update your Pi.
Xojo 2018 Release 1 has a new feature for Xojo Cloud users: Xojo Cloud Server Stats.
Here are some tips that will help ensure your Windows apps look and feel their best, with Xojo 2018 Release 1 now that Windows apps now have a more stable and flicker-free UI than ever before.
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.
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: