Ever wonder how to conditionally implement newer features in your code while keeping the ability to use older versions of Xojo at the same time?…
Comments closedAuthor: Greg O'Lone
Did you know that Apple provides a command-line interface for the Application Loader? With a Post-Build IDE build script, you can automatically submit your iOS apps to the iTunesConnect for processing!
Comments closedDid you know that it’s possible to load and use 3rd Party Frameworks in your Xojo iOS projects? There’s quite a number of good projects out there, many of which are on sites like GitHub and freely available for use in your projects. If you’re familiar with Declares in iOS, loading a 3rd Party framework requires just a couple of extra lines of code and a CopyFilesStep.
Last year at XDC 2018, Jérémie Leroy talked about making sure your screenshots mimicked the Apple method so that the date was always Jun 9th, the time was always 9:41 AM, the battery always shows as full and the WiFi strength always shows full. It got me thinking that it might be handy to be able to make the simulator always show those values when you do a debug run so that you don’t need to think about it when you are ready to start taking screenshots and movies of your app. One way to do that is to build & run project like SimulatorStatusMagic on the simulator before running your project, but it would be more useful if it was automatic.
Comments closedWhile at the Xojo Developer Conference in Denver last spring*, we got a lot of great feedback about the features that people needed most from the iOS framework. We managed to sneak a few into recent releases of Xojo; here are three of my favorites!
Comments closedAbout three years ago, we added HiDPI/Retina support to our framework which was released to users as part of Xojo 2016r1 when we also shipped our first HiDPI IDE.
With Apple’s announcements at WWDC 2018 and the introduction of dark mode it was time to revisit our graphics and the overall appearance of the IDE again. Here are some things which contribute to the changes that have been made and ones that you will see in the coming months.
Comments closedA 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.)
Comments closedAbout two years ago, at XDC 2015 in Austin, Philippe Casgrain from LightSpeed did a bonus presentation on the benefits of Continuous Integration when building projects with Xojo. Coincidentally, we at Xojo had decided just days before that we needed to move away from manual builds and automate as much of our build process as possible to keep up with the increasing complexity and number of our frameworks (later that summer we would be going from 3 to 8). After the presentation, we heard from several developers asking when the limitations of automated builds would be addressed and because we were working on our own process, it gave us an excellent place to try out new things while ironing out the wrinkles.
Comments closedOne of the most frequent requests we get about the web framework is the ability to include raw HTML code when setting text. Starting in 2017, this is now possible… and perhaps ironically, it’s activated using an html-style tag.
Comments closedThere’s been a bit of discussion about how the new Xojo.Net.HTTPSocket is slow for some users on Windows, which we’ve been trying to isolate to…
Comments closedIDE Scripts to the rescue! With a simple script (less than 10 lines), whenever you have quoted text to paste into the IDE, just select your script from the File > IDE Scripts menu instead.
Comments closed