Skip to content

Month: April 2018

2018 Xojo Design Award Winners

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:

Comments closed

Set Focus to a Field Using an iOS Declare

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.

Comments closed

Using Subversion Externals
with Xojo Text Projects

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:

  1. The project compiles and everything works just like it did before.
  2. The project doesn’t compile.
  3. 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.)

Comments closed