This blog series provides a clear, practical overview of how certificates work, with a focus on signing and distributing macOS applications. Some concepts apply to digital certificates in general, while others are specific to the macOS code signing process. By the end of the series, you’ll understand what certificates are, why they matter, and the role they play when building and distributing a macOS app.

The Developer ID field in the Build Settings > macOS > Sign Inspector Panel is our starting point:

By default, this field is empty. When you click Build, the app bundle (and its contents) is signed using a more relaxed security configuration. This does not require an explicit developer certificate and does not verify that the app comes from a known, trusted developer.

This type of signing is called Ad-Hoc signing. It is perfectly fine when debugging from the IDE or when building apps you intend to run locally.

In earlier versions of macOS, it was even possible to distribute and run Ad-Hoc–signed apps on other Macs, as long as the user explicitly chose to trust them. While this is still technically possible on recent versions of macOS, Apple has continued to tighten security, making it increasingly difficult for users to launch Ad-Hoc–signed applications.

In most cases, Gatekeeper will intervene and prevent the app from launching. Since the system cannot verify the identity of a trusted developer, it treats the app as unverified. With Ad-Hoc signing, macOS can only confirm that the app has not been modified since it was signed, it cannot validate who created it.

Under the hood: How “Ad-Hoc” signing works

Every time an app is signed (including all the contents inside its bundle) macOS uses Apple’s codesign tool. When Ad-Hoc signing is applied, the simplified process works roughly like this:

• A hash value (a unique digital fingerprint) is calculated for every file in the app bundle, whether it is executable or not, as well as for the bundle itself.
• These hash values are stored inside the app bundle, in the _CodeSignature folder.
• If the app contains multiple architectures (for example, x86 and ARM), the process is repeated for each supported architecture.

When a user double-clicks the app to launch it, macOS performs a similar verification process:

• It recalculates the hash value for every file in the bundle.
• It compares the newly calculated values with those stored in the _CodeSignature folder and if any hash differs from the stored value, macOS determines that the bundle has been modified since it was signed and it will refuse to launch the app.

Want to see this in action? Create a new Desktop project in the Xojo IDE, save it to your Documents folder, and build it for macOS.

Next, locate the built app in Finder. Control-click it and choose “Show Package Contents.” Then open the Contents > _CodeSignature folder and inspect the CodeResources file using your favorite text editor. You’ll see a list of hash values and digests corresponding to every file in the app bundle.

Apple Developer Certificates: Establishing Trust on macOS

What must you do so your apps are recognized as first-class citizens on macOS and can be distributed without Gatekeeper intervening? The answer is likely familiar: enroll in the Apple Developer Program (currently US $99 per year).

Among its many benefits, membership in the Apple Developer Program allows you to create your own Developer ID certificates. When you use these certificates to sign your apps, macOS can validate the signature and identify you as the verified developer distributing the software.

But how is this trust established and verified? To answer that, we need to start at the very root, literally!

Every computer, smartphone, tablet, and many other devices come with preinstalled Root Certificates. These certificates are issued by trusted organizations known as Root Certificate Authorities (CAs), including Apple. They serve as the foundation of a chain of trust, allowing other certificates issued by those authorities to be verified.

Technically speaking, a Root Certificate Authority (CA) is the top-level trusted entity in a public key infrastructure (PKI). It issues self-signed root certificates that act as the trust anchor for verifying other digital certificates. In other words, it is the foundation upon which the entire certificate trust model is built.

It is easy to take a look to these installed on your Mac:

1. Open Keychain Access.
2. Select Certificates at the top of the window.
3. In the sidebar, choose System Roots.
4. You will then see the complete list of root certificates trusted by macOS.

You’ll notice that there are three different Apple Root CA certificates. Why?

Each X.509 certificate contains detailed metadata defining its cryptographic properties and permitted usage. This includes the key type (such as RSA or ECDSA), the public key length, and the signature algorithm used.

• Apple Root CA: Is a RSA type, with a public key length of 2048 bits that uses the SHA-1 algorithm.
• Apple Root CA-G2: Is a RSA type, with a public key length of 4096 bits that uses the SHA-384 algorithm.
• Apple Root CA-G3: Is a ECDSA type, with a public key length of 384 bits that uses the SHA-384 algorithm.

Intermediate Certificates and the Chain of Trust

Root certificates are highly valuable and sensitive, so they are rarely used directly to sign end-user certificates (also called “Leaf” certificates). In the case of macOS app development, the developer’s certificate is the Leaf. This is where Intermediate Certificates come into play.

In simple terms, Intermediate Certificates are signed by Root Certificates and, in turn, are used to sign Leaf certificates. This protects the Root certificate from direct exposure. Together, the Root, Intermediate, and Leaf certificates form what is called the “Chain of Trust.”

The Chain of Trust verification starts with the Leaf certificate and works upward through the Intermediate to the Root. This same process occurs whenever you visit a secure website, make an online payment, or transmit sensitive data securely.

For example, the Leaf certificate is validated against its Intermediate certificate. If the Intermediate certificate is missing or expired, the Leaf certificate is considered invalid. Similarly, the Intermediate certificate itself must be validated against the Root certificate. If the Root certificate is missing or expired, the Intermediate is invalid, and all Leaf certificates signed by it are also invalid.

The same process happens when you sign your macOS apps: macOS validates the entire certificate chain before allowing the app to run.

Finally, certificates closer to the Root generally have longer validity periods. Leaf certificates must be renewed more frequently, while Root certificates are valid for many years.

Wrapping up

In this first article, we covered the fundamentals of digital certificates and their role in macOS app security. In the next article, we will focus specifically on Apple Developer certificates and how they enable trusted app distribution.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Code Signing on macOS: What Developers Need to Know

• Part 1, Get Started
• Part 2, Code Signing With Developer Certificates
• Part 3, Entitlements and Provisioning Profiles
• Part 4, How Xojo helps with Certificates, Signing and Distribution

Getting Started

Jade uses Anthropic Claude as its engine, so before using Jade, you first need to sign up for an Anthropic API key to access Claude. You can do this from the Anthropic Claude Console.

From there you can create your account. After you’ve done that, you will want to get an API key to use with Xojo. Click on the “API keys” tab to see existing keys and create new ones. Click the “Create Key” button to generate a new key. In the dialog, give it a name to indicate its purpose.

When you click Add, the actual key will be shown. Copy it to the clipboard.

Note that you cannot see the key again after closing that dialog, but you can always create a new key at any time.

Now go to Xojo Settings and in the General tab, paste it into the “Anthropic API Key” field.

Go back to the Claude Console and click on the Billing tab to buy credits. Interacting with Jade requires credits. The amount of credits used depends on the complexity of your interactions. Until you get used to Jade and credit usage, you’ll probably want to start with a small amount, like $5, and disable auto-reload.

Using Jade

To use Jade, select Help->Ask Jade or click the Ask Jade button in the toolbar. You’ll get some short introductory text. Note: Using Jade requires an internet connection.

You interact with Jade similarly to a chat app by typing prompts in the conversation area (bottom section) and pressing Send. Jade will think for a moment and then display its response.

If Jade’s response includes Xojo source code you can click one of the buttons above the code block to copy the code to the clipboard or to directly insert it into the active code editor.

When interacting with Jade, keep in mind that although it remembers the context from the current conversation, it has no knowledge of prior conversations. Click the “Start Over” button to clear things and start a new conversation. Starting a new conversation is useful when switching to a different topic as it prevents Jade from relying on information you previously discussed that is no longer relevant.

The Export button saves the current Jade conversation to a JSON file which is a great way to save information you want to retain and refer to later.

Other Tips

• Jade currently uses Claude Sonnet 4, but this may change as newer models become available.
• The only thing Jade knows about your project is what type it is (Desktop, Web, iOS, etc.). If you want Jade to offer suggestions based on your code, you will need to copy/paste the relevant code into the Jade conversation area.
• Your Jade conversation is restored when the IDE restarts. If you get errors, ensure that you have valid internet access, that the API key is valid and you have a positive credit amount.

Wrap

We hope you find Jade helpful with your Xojo development. Remember, Jade in Xojo 2025r3 is the first version of an AI assistant for Xojo and will improve over time. In subsequent releases we expect to add more capabilities and project integration. Read more about Jade in Xojo’s Documentation.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Added Support for WebStyle States

Working on Desktop projects is all fun and jokes. You can just change how the whole application looks every time your application users move their mouse one pixel to the left. Latency? Who cares!

In order to achieve the same results, WebStyle has been improved to support states. Hover, Pressed and Visited.

• WebStyle.Hover
  This is the style that will be applied when the mouse is over the element
• WebStyle.Pressed
  This is the style that will be applied when the user is pressing a mouse button in the element
• WebStyle.Visited
  This style can be used with WebLink instances. Used to let the user know the browser has visited that link in the past

Consider the following WebContainer:

In this case, it’s just a container with a WebLabel inside.

The Opening event contains the following code:

Please note I’m using named colors. You can read more about named colors in Introducing Named Color and CSS Classes in Xojo Web. If you try using another Bootstrap theme, the same code will use the new color palette without modifications.

Here is the result:

Combined with WebStyle.AddTransition, it opens the gates for more interesting GUIs. Let’s add some transitions to our code:

Let’s try the project again:

Neat! Let’s go crazy for a second with more complex effects:

The result:

You should definitely avoid going that crazy, this is just to show the possibilities. As Dr. Ian Malcolm said … “Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”

WebContainer.Pressed

Speaking about pressing on things, WebContainer.Pressed event is now available, so you don’t need to place a WebLabel or a WebContainer on top just to capture that event anymore. The event comes with some coordinates, just in case you need them.

The result:

Other changes

WebToolbar.Resized

Trying to tweak your design for different screen sizes? If WebToolbar’s automated behavior is not enough, you can implement the new WebToolbar.Resized event and adapt the contents. This is useful when you are reusing the same WebToolbar subclass in multiple WebPages. You will be able to place this code in just one place.

Exporting maps with WebMapViewer

Same as with MobileMapViewer. You can now use WebMapViewer.ToPicture method to export the current map. Like WebChart.ToPicture, due to the asynchronous nature of Web projects, the picture will be available in the new WebMapViewer.RequestedPicture event.

Updated DataTables

Last, but not least, DataTables has been upgraded from v1.13.4 to v2.2.2.

That’s (not) all!

As always, please make sure to check the release notes for a detailed list of new features and bug fixes. The Web framework is built on top of Xojo, new global features or bug fixes also applies to Web, including improvements to Console projects. Xojo Web is “just” a big Console project.

Thank you everyone for reporting, testing beta builds and giving us feedback.

Happy coding!

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

1. Define Your Idea

Start by summarizing your app’s purpose in a single, clear sentence. The more concise it is, the better defined your objective will be. This clarity will help guide your screen designs, navigation structure and code architecture.

This sentence can also double as your app’s short description in App Store Connect.

Focus on the essential features that form your app’s Minimum Viable Product (MVP). It’s easy to get sidetracked by new ideas during development. Resist the urge! Instead, keep a list of potential features for future updates and base priorities on user feedback.

2. Choose The Platform(s)

Xojo supports both iPhone and iPad, but your app doesn’t have to. Choose the device type that best fits your app’s use case.

• iPhone apps often support quick, task-based interactions.
• iPad apps are better suited to immersive, content-rich experiences.

To target a specific device only, set the unused layout (iPhone or iPad) to “None” in the App item’s Inspector Panel.

You’ll also need to decide the minimum iOS version to support. Xojo currently defaults to iOS 14.0, but as of writing, over 60% of users are on iOS 18 or later.

3. Prototyping

Xojo’s visual layout editor makes it easy to dive in designing your app. But take time to prototype your app first, especially if it has more than basic functionality.

Use tools like Figma or MockUp, or simply sketch your ideas with pencil and paper. Choose whatever helps you plan best and clearly.

Also, review Apple’s Human Interface Guidelines to align your app with native iOS expectations.

When designing in Xojo, you can fine-tune layout behavior using the iOSLayoutConstraint class to adapt to orientation and screen size changes at runtime.

4. Database Design

Most apps use a database. For local storage on iOS, use SQLiteDatabase, and save your database file in SpecialFolder.Documents.

Two key best practices:

• Add a Metadata table to track the database schema version.
• Create a custom SQLiteDatabase subclass to manage all read/write operations in one place.

This setup allows you to always know which version is installed on the user’s device and to react accordingly as your app evolves.

5. Graphic Resources

For icons, buttons and tab bar images, use Picture.SystemImage with symbols from Apple’s SF Symbols app. These scale beautifully across devices and adapt to light/dark mode. Just ensure compatibility with your minimum iOS version.

When using custom images, add them at multiple resolutions for optimal display across all screen sizes.

Typography also matters. Use system fonts thoughtfully, ideally no more than two font families. Vary sizes and weights to establish content hierarchy. Keep text readable with a minimum font size of 11pt.

Tip: When testing in the Simulator, set the window to physical size (Simulator > Window > Physical Size) to preview real-world readability.

6. Localization and Accessibility

Nothing prevents you from publishing an app in a single language, whether it’s your native language or English; but supporting multiple languages can increase downloads by over 100x.

Start localizing early to avoid design issues later. Add a module to your Xojo project with localized String constants for all app text, and enable the “Localized” option for each one.

Suggested languages (in order of impact):

Core: English

High-impact additions: Chinese, Spanish, German, French, Japanese, Italian, Portuguese, Russian, Korean

Also, localize accessibility labels and App Store listings, including screenshots and descriptions, for each supported language.

7. Testing the App

Xojo provides multiple ways to test your app, both from a design and user experience perspective, as well as from a functionality perspective:

• Simulators: Ideal for design, layout and localization testing. You can also use them to take App Store screenshots.
• On-device Debugging: Offers realistic input experience and access to hardware-only features.
• Build to Device: Lets you run the app outside the debugger, simulating real-world use.

Once you’ve finished fixing bugs in your code and app design, move on to testing in the real world by compiling your app and using Xcode to copy that bundle to a physical device. Testing like this, you’ll likely find some optimizations, especially around design and usability.

TestFlight is your gateway to external beta testers. After uploading a build to App Store Connect, create a public link to invite testers. Remember to increment the version number with each new build.

Tip: Add ITSAppUsesNonExemptEncryption = False in your Property List to streamline build approvals.

8. Publish it!

Publishing with Xojo is straightforward. The most time-consuming step is preparing your App Store Connect listing including text, artwork, screenshots, keywords and possibly localized pages. Read more about this in my earlier post How to Publish macOS and iOS Apps to the App Store Directly from Xojo.

Make sure you select the correct build when submitting your app for review.

9. Marketing

Something you should be doing simultaneously is preparing the related materials to introduce your app to the world. Start your marketing efforts early. A simple website can significantly boost discoverability. Use it to:

• Provide tutorials and FAQs
• Link to App Store and social media
• Highlight features and updates

Consider creating a YouTube channel for app demos and support videos, and maintain active social media profiles to stay visible.

Don’t forget to take advantage of the Marketing tools provided by Apple to help you create badges, assets, links and even QR codes to promote your app.

10. The Next Steps …

After launch, gather user feedback and track any bugs that slipped through. At this stage, it’s common to manage:

• A public release (on the App Store)
• A development version (next major update)

Save your Xojo iOS project in text format and use a version control system. This helps you manage multiple branches and collaborate efficiently.

To Summarize

Even the simplest iOS apps require a fair amount of time and effort, but thanks to Xojo, both aspects are significantly reduced.

What iOS apps have you created with Xojo? What’s your methodology or any tips you’d like to share? Feel free to comment on the Xojo forum!

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Apparently, vibe coding is the latest and greatest thing in software development, or so I hear from the younger generation. It seems like it’s all about using AI tools to generate code based on natural language prompts. You tell the AI what you want to build, and it spits out the code. No more late nights wrestling with syntax errors, no more meticulously planning out every class and function. You just… vibe it into existence.

The Origin Story

The term gained traction thanks to Andrej Karpathy, a prominent figure in AI (OpenAI, Tesla). He described ‘vibe coding’ as fully embracing AI generation, iterating based on natural language, and potentially minimizing direct code interaction or even deep review. This idea – letting the ‘vibe’ of the requirement guide the AI, potentially bypassing meticulous human coding – is where the conversation gets really interesting, and perhaps, a little unsettling for seasoned developers.

How It Works (Supposedly)

From what I gather, the process involves describing your desired outcome in plain English (even voice commands are suggested), letting AI generate the code. You then refine through further prompts. The most discussed and debated aspect? The suggestion by proponents that deep, line-by-line understanding of the generated code might become less critical than iterating on the high-level ‘vibe’.

My (Slightly Jaded) Take

Look, progress is essential, and making development more accessible is a worthy goal. We see this with low-code/no-code platforms and the genuine utility of AI assistants. However, as someone who values robust, understandable, and maintainable code, principles that are core to Xojo’s design philosophy, the notion of accepting code without fully grasping its mechanics raises serious questions.

We’ve spent years learning that the devil is in the details: edge cases, security vulnerabilities, performance bottlenecks. Can a ‘vibe’ truly account for all that?

As one Reddit user aptly put it, ‘Coding is easy, testing and maintaining is hard.’ That deep understanding is crucial for the hard parts.

The Potential Upsides (Maybe)

Okay, I’ll admit, there might be some potential benefits to this “vibe coding” thing.

• Rapid Prototyping: It could be useful for quickly creating prototypes and experimenting with new ideas.
• Lower Barrier to Entry: It might allow non-developers to build simple applications and bring their ideas to life.
• Increased Productivity: It could free up developers to focus on higher-level tasks like architecture and problem-solving.

The Concerns (Definitely)

But here are the things that keep me up at night:

• Lack of Understanding: If you don’t understand the code, how can you possibly debug it or fix it when things go wrong?
• Hidden Risks (Security & Quality): Could relying heavily on AI without rigorous review introduce subtle bugs or security flaws that aren’t immediately apparent?
• The Maintainability Maze: What happens to long-term maintainability when the original ‘author’ (the AI) has no memory, and the human overseer lacks deep understanding of the implementation?
• Erosion of Craftsmanship?: Does over-reliance risk deskilling developers or devaluing the rigorous problem-solving at the heart of good engineering?

My Verdict

So, is ‘vibe coding’ poised to take over software development? For complex, critical applications, it seems unlikely in its purest form. The risks associated with a lack of deep understanding are simply too high. However, dismissing the power of AI in coding would be equally misguided.

These tools are becoming powerful assistants. The key isn’t choosing between ‘vibes’ and traditional coding; it’s about intelligent integration. Use AI to accelerate development, handle boilerplate, and explore ideas. But never relinquish the crucial step of understanding, testing, and refining the output.

Fundamentals matter. Clarity, solid architecture, and maintainability, the very things Xojo is built to facilitate, become more important, not less, in an AI-assisted world. We need to leverage these tools wisely, as co-pilots, not as autopilots flying blind.

But, what do you think? Am I simply being a traditionalist coder, or do you share some of my concerns regarding “vibe coding”? Let’s discuss it in the Xojo forums. Share your experiences and perspectives. Navigating this evolution is something we should do together as a community.

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The End Result

The latest drag and drop example has a functional GUI that looks professional and feels intuitive. All without writing a single line of JavaScript (we will enhance it a bit with some CSS, though).

Please note this is a sample project created to explore drag and drop, not a full featured Kanban board. I’ll omit on purpose things like persistence. The complete project can be found in the Examples section of the IDE, under Platforms > Web.

Let’s walk through how to make it happen.

Creating the Required Components

First, we need to define the building blocks of our Kanban board. In Xojo, WebContainers are perfect for modularizing reusable UI elements. Here’s what we’ll create:

• KanbanCard
  A WebContainer to represent each task card. It’ll have a simple label for the task name (e.g., “Write blog post”) and maybe a colored border or handle to indicate it’s draggable. Add a WebLabel for the text and set its properties in the Inspector to make it visually distinct.
• KanbanCardContainer
  Another WebContainer to act as a column. It’ll hold multiple KanbanCard Containers and serve as both a drag source (where cards come from) and a drop target (where cards land). Include a WebLabel at the top for the column title (e.g., “To Do”) and a rectangular area below it to house the cards.
• Main Page
  A WebPage to host everything. This is where we’ll arrange our columns side by side.

In the Xojo IDE, drag a WebContainer onto your project for the Card, another for the Column, and set up three instances of the Column Container on the main WebPage (“To Do,” “In Progress,” “Done”).

KanbanCard

This component will be pretty easy to build. It is basically a WebRectangle with a WebLabel that we will use for the Title. To make it easier to update, I’ve added a Title Computed Property that will update the TitleLabel if needed.

For the background WebRectangle, we will use the following ColorGroup. Please notice Xojo added support for Named colors, that will rely on the current Bootstrap theme, supporting Dark Mode:

As you can see, BackgroundRectangle and TitleLabel controls are implementing the Opening event. This is just to set the mouse cursor that will be shown when we hover:

Me.Style.Cursor = WebStyle.Cursors.Move

The container itself is also implementing the Opening event. This is to make this control draggable, using the following line of code:

AllowTextDrag(WebDragItem.DragActionTypes.Move)

Any descendant of the WebUIControl class is draggable. And yes, that includes custom controls created with the Web SDK.

For the WebDragItem.DragActionTypes Enumeration, you can choose one these options:

In this case we will only be allowed to “Move” a card from one place to another.

There are cases where it makes sense to support multiple drag action types. In your operating system’s file browser, when you drag and drop files and folders, you can change between Move, Link or Copy by using Keyboard shortcut combinations. Depending on the drag action type, the element will be moved, a symbolic link will be created, or it will be copied, respectively.

Normally you will implement just Move or Copy, but keep in mind it’s possible to have more (at the cost of increasing the learning curve of your application for your users)

Allowing something to be dragged is the first of two steps. You also need a place to drop these items into.

KanbanCardContainer

This container will be more elaborate, but should be easy to follow. Let’s see how it works at runtime, with some annotations:

The WebLabel we used for the Title and the WebButton used for adding new cards are positioned manually in the IDE designer. Same as the invisible WebRectangle holding the KanbanCard items and the KanbanAddCard custom button.

But instead of placing our cards manually, we’ll take advantage of the browser’s capacity for doing this job for us. We just want to add them dynamically at runtime and let the browser stack them vertically, automatically. We also want the browser to display a scrollbar if the columns have several cards.

Here is the code we will add to the WebRectangle:

// Let the framework know we want to let the
// browser place the items automatically
Me.LayoutType = LayoutTypes.Flex

// This style will ensure cards won't be
// placed horizontally by the browser
Me.Style.Value("flex-direction") = "wrap"

// If there are more cards than available
// space, this style will allow the user
// to scroll
Me.Style.Value("overflow") = "auto"

Let’s add some methods to add and remove cards at runtime.

• AddCardWithTitle(title As String)
• AddCardWithTitleAt(title As String, index As Integer)
• RemoveCardAt

Moving Cards Between Columns

Here’s where Xojo’s drag and drop shines. Each Card Container needs to be draggable and each Column Container needs to accept dropped cards. In Xojo:

1. Make Cards Draggable: Open the KanbanListCard in the IDE and implement the Opening event. Enter this code:
   AllowTextDrag(WebDragItem.DragActionTypes.Move)
2. Accept Card Drops: Open the KanbanCardContainer and implement the Opening event. This is the code we need in order to accept drops:
   AcceptTextDrop(WebDragItem.DragActionTypes.Move)
3. Remove from Source: To move (not copy) the card, in the source Column’s DragEnd event, remove the dragged card from its original parent after a successful drop.

With this, you can drag a card from “To Do” to “In Progress,” and it’ll visually jump columns. Xojo handles the heavy lifting. No JavaScript or DOM manipulation needed!

The Hard Part: Reordering Cards

Reordering cards within a column, or dropping a card into another column in a specific position is trickier. You need to detect where the card lands among its siblings and adjust their positions. Xojo’s drag and drop doesn’t natively sort UI elements, so we’ll simulate it.

There are several ways to achieve this, let’s explore some options.

One would be to deal with X/Y coordinates. Once you drop a card, you could take a look to see where the card landed, compare the coordinates with the other cards and reorder them accordingly. In desktop and mobile projects this could be a valid solution. In web projects, dealing with specific coordinates might work, but there are more accurate and easier solutions.

The second way could be good enough in most cases. Cards could also accept drops so, if you drop one card on another, we just have to put the card being dropped in the position where it’s being dropped, and push down the rest of the stack. This way you won’t need to scratch your head and deal with screen coordinates or control dimensions. The end result will be based on this idea.

But what should we do to generate the gap between Cards? Maybe you can create a transparent Container that also accept Card drops, to simulate the gap between cards.

This would work for you, and I honestly recommend you to give it a try, it’s super easy to implement and it will just work. If you don’t want to explore the CSS rabbit hole, that’s fine, this can be your bus stop.

Two downsides:

• You won’t have animations
• You will double the amount of controls on screen (performance may suffer)

I went in another direction though. Using some CSS, you can add and modify margins on the fly, with neat transitions. In my sample project, the margin between cards is managed by the `margin-top` CSS style.

And here is where the Xojo Framework helps. To make styling easier, it adds a CSS class to the element being dragged and also to the element where the mouse is over, when it’s accepting a drop.

dragging – The HTML element being dragged will have this property
dragover – The HTML element under the other element being dragged

In this case, the “Bar” card will receive the dragging CSS class, while “Test #2” will receive the dragover CSS class, while the “Bar” car is above.

I’ve added some transparency to elements with the dragging class. As you can see in the screenshot, the “Bar” Card opacity is set to 30%.

For dragover class, I’ve added some margin and transitions. If you drag something into a card, the top margin will grow, simulating it’s making room for the card you are about to drop.

Here is how the HTML Header section of the sample project looks like. It isn’t too much code, but it does uses some somewhat advanced CSS tricks:

This approach keeps cards neatly stacked and sortable. It’s the “hard part” not because you will have to write a lot of code, but because you’ll actually have to think a solution that won’t require roundtrips between the browser and the server. Xojo’s event system makes it manageable without JavaScript, and with some CSS, the result will be great.

Some CSS Enhancements

In some cases I’m using shadows and border radius using the Bootstrap’s CSS classes.

As you can see, I’m using rounded-2 for the border radius, and shadow-sm to easily add a shadow to the cards.

You can read more about this in the following blog post:
Introducing Named Color and CSS Classes in Xojo Web

There is a related sample project you might want to check:

Closing Thoughts

This has been a fun experiment to explore the Xojo Web drag and drop feature. Give the sample project a try and explore each control to see how it’s been created. I can’t recommend enough that you try to build it from scratch (and ask in the forum if you get stuck!)

We can’t wait to hear about how you plan to introduce drag and drop into your projects. Don’t be shy and create a forum thread to show what you have built, or what you are working on.

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

• The Dockerfile below should be placed in the same directory as your Xojo project
• Remember to modify the WEBAPP_NAME variable on line 33 to match the name of your project
• Feel free to customize this Dockerfile to suit your specific needs. We encourage you to share your modifications and experiences in the Xojo forum

# Step-by-Step Instructions for Building, Saving, and Running the Image:
# 1. Build the Docker image:
#    "docker build -t hellodocker-image ."
#    This creates a Docker image named "hellodocker-image" based on this Dockerfile.
#
# 2. Save the Docker image to a tar file:
#    "docker save -o hellodocker-image.tar hellodocker-image"
#    This saves the "hellodocker-image" to a file named "hellodocker-image.tar".
#    You can use this file to transfer the image to another server.
#
# 3. Upload the .tar file to the remote server.
#    After transferring the tar file, follow these steps on the remote server:
#
#    3.1 Load the Docker image:
#        "docker load -i hellodocker-image.tar"
#        This imports the image into the Docker environment on the server.
#
#    3.2 Run a container from the image:
#        "docker run -d --name hellodocker-container --restart always -p 7000:80 hellodocker-image"
#        This creates and starts a container named "hellodocker-container" that:
#        - Restarts automatically if it stops (via `--restart always`).
#        - Maps port 80 inside the container to port 7000 on the host machine.
#
#    3.3 Verify the web app is running:
#        Open a web browser and navigate to http://server-ip:7000
#        Replace "server-ip" with the IP address of your remote server.
#
# Complete video guide at: https://youtu.be/ARr7d6Z6CRY

# Use Ubuntu 22.04 as the base image for the container.
FROM ubuntu:22.04

# Define the name of the Xojo web app executable.
# This should match the exact name of your compiled Xojo web app (case-sensitive).
ENV WEBAPP_NAME=HelloDocker

# Prevent interactive prompts during the installation of dependencies.
ENV DEBIAN_FRONTEND=noninteractive

# Install required system libraries for the Xojo web app to run, and purge unnecessary software (PHP, Python, Apache)
RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
    ca-certificates \
    libunwind8 \
    libsoup2.4 \
    libpango-1.0 \
    libicu70 \
    libglib2.0 \
    libgtk-3-0 \
    && apt-get purge -y php* python3* apache2* libapache2-mod-php* \
    && apt-get autoremove -y \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

RUN useradd --create-home ${WEBAPP_NAME}

# Set the working directory inside the container.
# This is where the web app files will be located.
WORKDIR /${WEBAPP_NAME}

# Copy the built Xojo web app from the build context into the container.
# Remember, this Dockerfile must be placed in the same folder as the Xojo project.
COPY ["Builds - ${WEBAPP_NAME}/Linux 64 bit/${WEBAPP_NAME}", "."]

# Change ownership of the application files to the non-root user
RUN chown -R ${WEBAPP_NAME}:${WEBAPP_NAME} /${WEBAPP_NAME}

# Ensure the main web app executable has permission to run
RUN chmod +x ${WEBAPP_NAME}

# Create a directory for persistent data storage.
# Ensure the data directory is owned by the non-root user.
RUN mkdir -p /home/${WEBAPP_NAME}/data && chown -R ${WEBAPP_NAME}:${WEBAPP_NAME} /home/${WEBAPP_NAME}/data

# Define the volume for the container to store data.
# The contents of "/home/${WEBAPP_NAME}/data" will persist outside the container.
VOLUME /home/${WEBAPP_NAME}/data

# Switch to the non-root user for security purposes.
# All subsequent instructions (including CMD) will run as this user.
USER ${WEBAPP_NAME}

# Expose port 80 inside the container.
# This allows the web app to listen on port 80, which will be mapped to port 7000
# on the host machine when the container is run.
EXPOSE 80

# Start the Xojo web app when the container runs.
# The app will listen on port 80 inside the container.
CMD ["sh", "-c", "./${WEBAPP_NAME} --port=80"]

I also recommend reading this article for additional details on Xojo and Docker: https://blog.xojo.com/2021/05/17/running-xojo-web-applications-in-docker/

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

But when you do need that extra boost, it’s an option to consider, and I recently came across a scenario where it made a huge difference.

The (One Billion Row) Challenge

This came about from a discussion of the “One Billion Row Challenge” on the Xojo Forum, where a programmer is tasked with reading a billion rows of temperature data and consolidating it into statistics for each given city. Our friend Mike D started a project to demonstrate different techniques, and I eventually started my own project. Using MemoryBlock, Ptr, and preemptive threading, I was able to process a billion rows in roughly 8 seconds.

But that’s not the point of this post.

See, in order to process the data, you must first create it, which isn’t as straightforward as it seems.

Creating The Data

Each row of the data file takes the form “City;temp”, where “temp” is single-place decimal between -99.9 and 99.9. For purpose of limits, I used, arbitrarily, 413 random cities out of a list of all cities. The original code looked something like this where “bs” represents a BinaryStream:

Var r As New Random

For i As Integer = 1 To rowCount
  Var city As String = cities(r.InRange(0, cities.LastIndex))
  Var temp As Double = r.InRange(-999, 999) / 10.0

  bs.Write city + ";" + temp.ToString("#0.0") + EndOfLine
Next

This was simple, easy, and slow. To generate the full billion rows took about 2.5 hours.

Memory-Unblocking

Upon investigation, I rediscovered what I already knew. Dealing with strings, both in conversion and concatenation, can be a bottleneck. I won’t go through all the iterations here, but nothing I tried made a significant difference. The only solution was to ditch strings entirely.

I started with creating a MemoryBlock “buffer” (“outMB”) of 1 MB with an associated Ptr (“outPtr”). (You can access the contents of a MemoryBlock through its methods, but those are function calls, which have an overhead. Ptr methods are operators that work with the bytes directly so they are faster.) The plan was to fill the buffer as much as I could, write it to the file, then start again at the top of the buffer.

Keeping a position index, I started with writing the city using outMB.StringValue since there is no equivalent Ptr method for this. Next, I plugged in the value of a semicolon with outPtr.Byte(outMBIndex) = 59.

Working with integers is faster than doubles, so I used a little math to plug in the temperature values directly using If statements and outPtr.Byte.

Finally, I used outPtr.Byte(outMBIndex) = 10 to plug in the linefeed (ASCII 10).

The final code looked something like this:

Const kEOL As Integer = 10
Const kHyphen As Integer = 45
Const kDot As Integer = 46
Const kZero As Integer = 48
Const kSemicolon As Integer = 59

Var r As New Random

Var outMB As New MemoryBlock(1000000)
Var outPtr As Ptr = outMB

Var outMBIndex As Integer = 0

For row As Integer = 1 To rows
  Var cityIndex As Integer = r.InRange(0, cities.LastIndex)
  Var city As string = cities(cityIndex)
  Var cityBytes As Integer = city.Bytes

  If (outMBIndex + cityBytes + 10) >= outMB.Size Then
    bs.Write outMB.StringValue(0, outMBIndex)
    outMBIndex = 0
  End If

  outMB.StringValue(outMBIndex, cityBytes) = city
  outMBIndex = outMBIndex + cityBytes

  outPtr.Byte(outMBIndex) = kSemicolon
  outMBIndex = outMBIndex + 1

  If r.InRange(0, 4) = 0 Then
    outPtr.Byte(outMBIndex) = kHyphen
    outMBIndex = outMBIndex + 1
  End If

  Var temp As Integer = r.InRange(0, 999)
  Var t1 As Integer = temp \ 100
  Var t2 As Integer = (temp \ 10) Mod 10
  Var t3 As Integer = temp Mod 10

  If t1 <> 0 Then
    outPtr.Byte(outMBIndex) = t1 + kZero
    outMBIndex = outMBIndex + 1
  End If

  outPtr.Byte(outMBIndex) = t2 + kZero
  outMBIndex = outMBIndex + 1

  outPtr.Byte(outMBIndex) = kDot
  outMBIndex = outMBIndex + 1

  outPtr.Byte(outMBIndex) = t3 + kZero
  outMBIndex = outMBIndex + 1

  outPtr.Byte(outMBIndex) = kEOL
  outMBIndex = outMBIndex + 1
next

If outMBIndex <> 0 Then
  bs.Write outMB.StringValue(0, outMBIndex)
End If

This code is far longer, harder to follow, and difficult to maintain, which goes back to my original point of why MemoryBlock should be avoided.

It also generates one billion rows of data in about a minute (as opposed to 2.5 hours).

It’s nice to have the option.

Kem Tekinay is a Mac consultant and programmer who has been using Xojo since its first release to create custom solutions for clients. He is the author of the popular utilities TFTP Client and RegExRX (both written with Xojo) and lives in Connecticut with his wife Lisa, and their cat.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Like 4D, Xojo has a drag and drop user interface builder, a Code Editor, a Debugger and a Compiler as well as a cross-platform framework. While 4D now has an object-oriented language as an option, Xojo has always been object-oriented. The language is a dot syntax not unlike Javascript. You do not have to become an experienced object-oriented programmer to use Xojo. One of its strengths is that you can learn incrementally.

Xojo supports database application development but there are differences between how it and 4D handles that. 4D has its own database engine and query syntax. Xojo supports SQLite, PostgreSQL, MySQL and ODBC for accessing databases. Unsurprisingly it uses SQL as its query syntax. Because 4D is solely designed for database application development, it ties the user interface you create to tables in the database. Xojo does not. 4D’s model prevents you from having to write code to get data from database records in and out of your user interface. While by default Xojo does not provide this, it provides an add-on called DBKit which assists you in connecting to and interacting with databases.

Xojo supports desktop development for Linux, macOS, Windows and Raspberry Pi (Linux on ARM). It supports web development as well and mobile development for iOS and Android. You can also build console apps which can be handy when you need an app with no user interface to run on a server. Xojo uses native controls and compiles to native machine code for x86 and ARM. Whether you come to Xojo to build desktop, web or mobile apps, you’ll find that 95% of what you learn and the code you write will be applicable to all targets. With the exception of iOS (which because of Apple’s requirements must be built from a Mac) you can build your apps from any platform to any platform. Xojo also includes a Remote Debugger which allows you to build from one operating system and run on another. For example, you might do your development on macOS but want to debug on Windows to track down a Windows-specific issue. With the Remote Debugger, this is quite easy.

Xojo is free to use for development. You only purchase a license when you need to deploy. This is a developer license, not a deployment license. That means that you can deploy as many applications as you like to as many users as you like, without any additional cost. Each developer purchases their own license. A Xojo license comes with 12 months of updates. The new Xojo releases available during your license period continue to be available to you even after your license expires. Renewing your license gets you another 12 months of updates. If you only need to deploy cross-platform desktop applications, the Xojo Desktop license is $399USD. Yearly updates are also $399USD. If you wish to build for any platform we support, the Pro license is $799USD. Yearly updates are also $799USD. Compare licenses and find more pricing details at our webstore.

If you’d like to give Xojo a spin, I recommend starting with the QuickStart and then the full tutorial. After that, check out DBKit, the video and its tutorial which will make it easier to build database-oriented applications. These are the desktop tutorials but there are also tutorials for mobile and web application development. Because Xojo is a general, cross-platform development tool rather than one specifically for database applications, what you build with it is truly limited only by your imagination. If you have any further questions, please reach out to us. Our user forum is also filled with experienced and enthusiastic Xojo users that answer and have answered hundreds of questions. And the Xojo Blog has many posts on database development with Xojo.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

On November 12th Thomas Kurtz, the co-inventor (along with John Kemeny who passed in 1992) of the BASIC programming language died at the age of 96. It would be difficult to overstate the impact he had on computing. BASIC made it possible for so many people (myself included) to begin their journey into programming.

In the late 1970s I became interested in learning to code. My father, who was an electrical engineer and coded in Fortran at work, brought home a book that taught the basics of programming. Written and published by Apple, it appeared to only cover 6502 Assembler, the chip that was in the Apple II. Just a few pages in my eyes began to glaze over and I started to wonder if programming was really for me. Fortunately, I flipped the book over to find it was actually two books in one. From the other side it was a book about AppleSoft BASIC. As I looked at the language, it made immediate sense to me. Assembler was too low level and not a great first language but BASIC was ideal for this purpose. I learned enough to get going and my life was forever changed.

Programming has evolved a lot since then but we still design Xojo with the same principle that Thomas and John espoused with their original version of BASIC: that programming should be accessible to anyone with an interest. We have many users whose first experience with programming was with Xojo just as mine was with BASIC. In our own way, Xojo is continuing what Thomas and John began. Today more people have the ability to learn programming than ever before. Thomas and John both were true pioneers that contributed significantly to making that happen.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In The Beginning

Threads have been a part of of the Xojo language for a long time, and by now experienced users know the basics: subclass a Thread, fill in the Run event, then call Start. The code in Run will execute independently from the rest of your code leaving your app responsive while it does work in the background.

Mostly.

See, until now, a Thread was only “cooperative”, meaning it ran alongside your main code with the framework deciding when to switch between them and how long each should execute. While the main code was running, the Thread code was paused, and while the Thread was running, the main code was paused.

Think of it like standing before two devices that perform different functions when cranked, but only having one crank available. You run the first machine for a bit, then the other, then back to the first, until they are done. And you do it really, really fast.

This worked pretty well when your goal was, say, to keep your user interface responsive. You could spin long-running code into a Thread, then present the results once it finished.

But it was inadequate if your objective was to speed up some intense process, or the code in your Thread did not present logical places to yield time back to your main code. In the former scenario, you were better off not using a Thread, or perhaps using Worker (a severely limited earlier attempt at allowing simultaneous processing), while in the latter you would have to manually yield back processing time, leading to even slower operation.

In The Now

Cooperative threads are fine for many tasks, but when you need something that truly runs independently within your app, a “preemptive” thread is required.

A preemptive thread spins off onto another core in your machine, which probably has at least four, and runs there entirely isolated from other threads. It’s like launching a separate, mini-app that you can share information with.

The limitations that apply to cooperative threads drop away. Since it runs on a different core, it cannot slow down or interfere with your main code, and will run as fast as its core will allow.

Challenging Times

This sounds almost too good to be true, but it’s not without its challenges. While cooperative threads were rather easy to work with, preemptive threads require an extra layer of thought and awareness for Xojo users.

When a cooperative thread’s code is running, you know nothing else is, so you don’t have to worry about, say, updating a Dictionary or removing an element from an array. But with preemptive threads, code runs simultaneously with other code so you cannot just update that Dictionary if there is a chance that the main code, or another preemptive thread, might be doing it too.

Consider this example.

// In our thread
If MyArray.Count = 0 And FinishUp Then
  Exit
Else
  Process MyArray.Pop
End If

//////////////////////////////

// In the main code
FinishUp = True
MyArray.Add 1

You might think the thread is going to process the last element and then exit its loop because FinishUp was set to True, but with preemptive threads we have to be aware of race conditions where the order of actions is unpredictable. Here, the main code could set FinishUp to True, and the thread could see that MyArray was empty and exit before the main code could add the last element. Conditions can change at literally any instant, even in the middle of a single line of code.

Fortunately, there are ways to protect against this and you must use them to ensure orderly operation and avoid surprises.

Know Your Type

The first step is creating a preemptive thread, and Xojo’s implementation is pretty straightforward. Rather than introducing a unique class, you can continue to work with the existing Thread by setting its new Type property to Thread.Types.Preemptive. The Type can be set when instantiating the Thread or from within its running code. You can even switch types at will, although once running, the Type can only be changed from within the Thread.

Example:

// A subclass of Thread called PThread

MyThread = New PThread
PThread.Type = Thread.Types.Preemptive
PThread.Start

Or within the Run event, you could do this:

Me.Type = Thread.Types.Preemptive

You can also set Type through the Inspector after dragging a Thread to a window.

Protect Yourself

Now that you have a preemptive thread ready to go, you have to think about how to protect common resources. Xojo has done a good job of making a lot of the framework safe, but that just means your app shouldn’t crash if, say, the Thread tries to manipulate a variable at the same time as other code. It’s up to you to make sure one area of your app doesn’t clobber the changes made by another.

Consider this code that maintains a Dictionary of Integer arrays.

// Thread code
Var arr() As Integer

If MyDictionary.HasKey(x) Then
  arr = MyDictionary.Value(x)
Else
  MyDictionary.Value(x) = arr
End If

arr.Add 1

//////////////////////////////

// Main code
If Not MyDictionary.HasKey(x) Then
  Var arr() As Integer
  MyDictionary.Value(x) = arr
End If

Run this long enough and you’re going to wonder why some data got lost. Why? Because both the Thread and main code might be checking for the key at the exact same instant and filling it in when it’s not found. If the Thread does it first, the main code will almost instantly replace it with an empty array.

Instead, you should use a Semaphore or CriticalSection to make sure code is protected.

You’d first instantiate one of these in a common property like a Window or Module. (I’m using Semaphore here, but it works the same for CriticalSection.)

MySemaphore = New Semaphore
MySemaphore.Type = Thread.Types.Preemptive

Notice the new Type property? It must match the one in Thread and can be used between the main code and a Thread or between same-typed threads. (This is one of the limitations of Xojo’s implementation: you cannot share a Semaphore or CriticalSection between preemptive and cooperative threads.)

The example can be updated like this:

// Thread code
Var arr() As Integer

MySemaphore.Signal

If MyDictionary.HasKey(x) Then
  arr = MyDictionary.Value(x)
Else
  MyDictionary.Value(x) = arr
End If

MySemaphore.Release

arr.Add 1

//////////////////////////////

// Main code
MySemaphore.Signal

If Not MyDictionary.HasKey(x) Then
  Var arr() As Integer
  MyDictionary.Value(x) = arr
End If

MySemaphore.Release

This will force either the main code or Thread to wait for the other to complete before continuing, ensuring proper order and avoiding the race condition.

Limitations

Using preemptive threads comes with certain restrictions. The biggest one is the aforementioned inability to share a Semaphore or CriticalSection with a cooperative thread. The other is the same as in a cooperative thread: you cannot update a user interface component directly instead relying on the UserInterfaceUpdate mechanism (more on that below).

If you are setting up multiple threads to work on different parts of some object, that may crash hard depending on the type of object. For example, writing to the same file or different parts of a MemoryBlock is fine, but updating a Picture may not be. In those cases, you will have to get creative.

What’s It Good For?

Choosing preemptive threads over cooperative means that you either have some code that needs to truly run in the background that would otherwise interfere with you user interface, or you have some large task that can be logically processed in parts.

Window Service

In the former case, the easiest technique might be to drag a Thread to your window, set its Type, and implement the Run event. It can be started from within the window either through a manual process like a pressing a button, or automatically when the window opens.

Just like with a cooperative thread, you can send data back to your window using the AddUserInterfaceUpdate method and implementing the UserInterfaceUpdate event.

Splitting It Up

If your task involves something that can be split up into logical chunks, I encourage you to look at my ThreadPool module, accessible through the Xojo Examples or my GitHub page. (The latter has a README with more details.)

The ideal usage for ThreadPool is when you have some data that can be processed in sections. For example, suppose you wanted to count the vowels in a large file. You could subclass ThreadPool and implement its Process event to count one block. You would then send the file into your subclass in chunks of, say, 256k each and gather the results.

The benefit of ThreadPool, among other things, is that it will handle the coordination for you so the dangers of using preemptive threads are minimized. You still have to consider how to send your results back to your main code safely, perhaps using Semaphore/CriticalSection or the AddUserInterfaceUpdate method, but each block can be considered independently of the others.

(A big thanks to MVP Anthony Cyphers for writing the example included with Xojo.)

Juggling Chainsaws

The power of preemptive threads is clear, but the potential pitfalls can be serious. Unless you’re very careful, you can easily create bugs that may not be readily apparent, and may take hours or even days to track down. (I say this from unfortunate experience.) Unless you have a compelling reason to take on that challenge, don’t bother.

What I’m trying to say is, if a cooperate thread does the job adequately, there is no need to introduce the headache that preemptive threads can bring.

But if you do have a legitimate need, like a long-running process that needs to run quickly without blocking your UI, go for it, just be careful.

In any case, it’s great that we finally have that option.

Kem Tekinay is a Mac consultant and programmer who has been using Xojo since its first release to create custom solutions for clients. He is the author of the popular utilities TFTP Client and RegExRX (both written with Xojo) and lives in Connecticut with his wife Lisa, and their cat.

Need More Information? Read more about preemptive threads in the Xojo Documentation and Blog. Or read about Semaphore and CriticalSection, also on the Xojo Blog.

1. One-Time Purchase

Implement a one-time purchase model where users pay a single fee to download and use your desktop application. This approach provides instant revenue and offers several advantages:

• Simple, straightforward pricing
• Immediate revenue generation
• No ongoing costs or commitments for users

However, this model has potential drawbacks:

• Limited ongoing revenue, as users only pay once
• Requires continuous updates and improvements to maintain user satisfaction
• Relies heavily on new customer acquisition for sustained growth

Example: A one-time purchase model is ideal for specialized tools or applications with a specific, well-defined purpose. For example, a desktop application that converts file formats or performs complex calculations for a niche industry would be well-suited for this model. Users typically expect such tools to work reliably without the need for frequent updates or ongoing subscription costs.

2. Subscription Model

Implement a subscription model where users pay a recurring fee to access and use your desktop application. This approach generates ongoing revenue and encourages customer retention.

Benefits:

• Predictable, recurring revenue streams
• Increased customer retention and loyalty
• Ability to continually update and improve the application

Potential drawbacks:

• Users may be deterred by ongoing costs, especially for one-time tasks
• Requires ongoing development and support, which can be resource-intensive

Example: Successful subscription-based desktop applications offer regular updates, new features, and premium support to justify the recurring fees. Productivity software suites and antivirus programs commonly use subscription models to provide ongoing value to customers.

3. Freemium Model

Implement a freemium model where a basic version of your desktop application is offered for free, with the possibility to upgrade to a premium version with added features or support. This approach attracts users with a free version and encourages upgrades to a paid version.

Benefits:

• Attracts a large user base with the free version
• Provides opportunities to upsell premium features or support
• Allows users to try before buying, reducing purchase risk

Successful implementation:

• Clearly define features and limitations of the free version
• Offer significant value in the premium version to encourage upgrades
• Make the upgrade process easy and seamless for users

Example: A photo editing software might offer a free version with basic editing tools, and a premium version with advanced features like HDR support or batch editing.

4. In-App Purchases

Implement in-app purchases to allow users to buy additional features, content, or services within your desktop application. This approach enhances the user experience and increases revenue.

Types of in-app purchases:

• More features or functionality
• Premium content (exclusive data or expert advice)
• Virtual goods or currency
• Ad-free experience or premium support

Successful implementation:

• Clearly communicate the value of in-app purchases to users
• Make the purchasing process easy and seamless
• Ensure in-app purchases are relevant and useful
• Avoid aggressive or deceptive monetization tactics

Examples: Productivity applications can use in-app purchases to offer advanced features. For instance, a project management tool might provide basic task tracking for free, but offer in-app purchases for advanced reporting, time tracking, or integration with other popular business tools. This allows users to customize their experience based on their specific needs and budget.

Games often use in-app purchases to enhance player engagement and monetization. A strategy game might offer a base game for free, but include in-app purchases for special units, resource packs, or cosmetic items. This model allows players to enjoy the game without spending money, while providing options for those who want to progress faster or customize their experience.

5. Advertising

Integrate advertising into your desktop application to generate revenue. This approach can be effective but requires careful consideration to keep a positive user experience.

Types of advertising:

• Display ads (banner ads or pop-up ads)
• Sponsored content (sponsored articles or product placements)
• Affiliate marketing (promote other partner products or services)

Successful implementation:

• Choose relevant and non-intrusive ad formats
• Clearly mark ads to avoid confusing users
• Use targeting options to deliver relevant ads based on users’ interests
• Monitor user feedback and adjust ad strategy accordingly

Balance revenue generation with user experience when integrating advertising. Overly aggressive or intrusive advertising can drive users away, while insufficient advertising may not generate adequate revenue. Carefully check user engagement and satisfaction to find the right balance for your application.

Conclusion

Monetizing a desktop application requires careful consideration of target audience, application type, and revenue goals. Understanding different monetization strategies allows developers to choose the best approach and maximize revenue.

Each strategy, discussed in this article, offers unique advantages and disadvantages. The right choice depends on the specific application and target audience.

To succeed in monetizing a desktop application:

• Understand target audience needs
• Choose a monetization strategy aligned with application type and revenue goals
• Continuously check and adjust strategy to improve revenue and user experience

By following these guidelines and selecting the right monetization strategy, developers can create successful, profitable desktop applications that meet user needs.

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Some of you might not have noticed because, until recently, most people didn’t think much about Windows ARM. After all, nearly everyone still runs Windows on x86-64 CPUs. But lately, Windows on ARM is starting to get more traction, both in the press and in the market.

Back in May, Qualcomm announced the Snapdragon Dev Kit for Windows. This is supposed to be a $900 mini PC (about the size of a Mac mini) for developing Windows ARM apps for the Snapdragon X Elite SoC (system on a chip). I say “supposed to be” because although the press release says it was intended to go on sale on June 18, I can only find pre-order pages for it, so it seems to not be available just yet or out-of-stock.

There have been other ARM PCs for Windows in the past, but their performance has always been less than desirable. The new Snapdragon X Elite is supposed to be roughly equivalent to Apple M3 SoCs.

You don’t have to wait for Qualcomm as Copilot+ PCs and laptops with Snapdragon SoCs are starting to appear elsewhere. Lenovo has the ThinkPad T14s Gen 6, which at about $1700 is not exactly a bargain, but is in the ballpark of many Mac laptops. The Yoga Slim 7x is even cheaper starting at just $1200.

But I’m not here to sell Lenovo products. I’m just pointing out that Windows on ARM is becoming a reality, if slowly. That might be starting to change given Intel’s recent troubles with its Raptor Lake CPUs and most recent earnings report, however. Take it with a grain of salt, but Qualcomm is predicting that Windows ARM could reach 50% of Windows PC market within five years.

That sounds astonishing, but change often happens slowly then all at once.

Building for Windows ARM with Xojo

The good news is that with Xojo you are already prepared for this. To build your existing Xojo desktop project for Windows ARM, you just need to change one property in the Windows Build Settings and click Build. There is no step 3.

Xojo can also build Windows apps for x86-64 and x86-32, which pretty much covers all your bases. Not to mention that it can build macOS apps, Linux apps, web apps, iOS apps and Android apps.

And if you already have an Apple Silicon Mac then you don’t even need to purchase a Windows ARM computer. You can run Windows ARM as a virtual machine on a Mac using Parallels or VMware Fusion. You’ll still need to get your own license for Windows 11, however.

Although you can make your own Windows ARM apps with Xojo today, there are a couple temporary limitations to keep in mind. The first one is that XojoScript is not yet available. The other is that Xojo itself is not yet a native Windows ARM app. Both of these are because the Xojo compiler itself is not yet native on Windows ARM. That will change, but for now Xojo itself runs perfectly fine using the Prism x86-64 emulation layer in Windows. In addition you can use the Remote Debugger to test your apps on Windows ARM from another computer.

Will Windows ARM replace Intel like it did for Macs? It seems hard to believe, but the wind seems to be blowing in that direction. To make sure you’re prepared, download Xojo for free today and start creating your own ARM apps!

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

Presented with choosing what development tool is best for your main, full-stack development needs, let’s discuss the benefits of Xojo development platform for your next web project. With its simplicity, flexibility, and powerful features, Xojo will help you create high-quality web applications quickly and efficiently, with the added bonus of covering backend and frontend development in the same IDE—no more language switching—while also lowering your overall costs.

Overview of Full-Stack Development

Full-stack development covers the entire spectrum of technologies and skills required to create a fully functional web application. This approach involves both the frontend, which users interact with directly, and the backend, which powers the application.

At its core, full-stack development refers to the ability to work on both the client-side and server-side of an application. This means that full-stack developers should be proficient in frontend technologies such as HTML, CSS, JavaScript, as well as backend technologies like Node.js, Python, and frameworks such as React and Django. Full-stack developers possess a broad skill set that includes designing user interfaces, managing databases, and server logic, enabling them to oversee the entire development process.

Usually, a full-stack developer handles:

• Frontend Technologies: These consist of HTML for structure, CSS for styling, and JavaScript for interactivity, crucial for crafting engaging user interfaces. Frameworks such as React, Angular, and Vue.js are also typical choices for building dynamic web applications.
• Backend Technologies: This segment covers server-side programming languages like Node.js, Python, Ruby, and PHP, coupled with frameworks such as Express, Django, and Ruby on Rails, essential for robust backend development. Databases, both relational (e.g., MySQL, PostgreSQL) and NoSQL (e.g., MongoDB), are also crucial for data management.
• APIs (Application Programming Interfaces): APIs enable simple communication between frontend clients and backend applications/servers, facilitating the exchange of data. RESTful APIs and GraphQL are common approaches used in modern web applications.

Advantages in adopting a full-stack approach in software development:

• Faster Development Cycles: With a single developer or a small team capable of handling both frontend and backend tasks, projects can progress more quickly, reducing the time to market.
• Easy Integration: Full-stack developers have a comprehensive understanding of how the different components of an application interact, leading to better integration and fewer compatibility issues.
• Enhanced Problem-Solving: By possessing a complete view of the application, full-stack developers can identify and resolve issues more efficiently, improving overall project quality.

Why choose Xojo as a full-stack development solution?

When it comes to full-stack development, selecting the right programming language(s) or frameworks can significantly impact the efficiency and effectiveness of your projects. Xojo is a powerful choice for anyone seeking a robust, user-friendly and versatile development environment that provides everything needed to transform their ideas into fully fledged, working software products, no matter the platform or environment.

Xojo features ideal for full-stack development:

• Built-in Web Server: Xojo has its own built-in web server that allows developers to easily test and deploy web applications (on Linux or Windows servers) without the need for additional software. There is no need to set up complicated web server technologies or deal with compatibility issues and security. Xojo handles all of that for you. In production, you can run a web app built with Xojo as stand-alone or behind Apache or Nginx. You decide what works best for your project.
• Visual Development Environment: Xojo offers a visual development environment that allows developers to design user interfaces using drag-and-drop elements. This approach simplifies the process of creating appealing applications, accessible to both novice and experienced developers.
• Object-Oriented Programming: Xojo is object-oriented programming (OOP), enabling developers to create modular and reusable code. OOP encourages better organization and maintainability of applications, making it easier to scale projects over time.
• Compiled Code: Xojo compiles code into machine code, which results in fast and efficient web applications. In the event that some bad actors gain access to your server, rest assured that Xojo built web apps are more secure than those built with other tools.

In addition to these features, while many programming languages cater to full-stack development by combining and utilizing multiple external solutions, Xojo distinguishes itself as an ideal, singular solution. Compared to languages like JavaScript, Ruby, PHP or Python, Xojo has a gentle learning curve, making it an attractive option for beginners. Its syntax is straightforward and resembles natural language, which helps new developers learn concepts quickly. Xojo’s visual tools and drag-and-drop features enable developers to prototype applications rapidly. This is particularly advantageous for startups and businesses looking to iterate and launch products quickly.

Xojo for Frontend Development

Creating an engaging and user-friendly frontend is crucial for any web application. With Xojo, developers can quickly prototype and design visually appealing interfaces without the need for 3rd party tools or additional frameworks.

Xojo’s visual development environment makes building user interfaces an easy and enjoyable thing. With its drag-and-drop interface, developers can easily design and layout their GUI components- buttons, labels, and text fields- without needing any code at all. This intuitive approach allows developers to focus on the logic of the application rather than getting bogged down by low-level details.

So, what makes Xojo’s frontend capabilities so effective? For starters, it allows frontend developers to quickly:

• Prototype and test ideas without writing code;
• Easily create complex layouts and designs;
• Focus on the logic of the application rather than the UI;
• Collaborate more effectively with designers and other team members.

Example: A simple web app frontend built with Xojo

To illustrate the power of Xojo’s visual development environment, let’s take a look at a simple web app frontend built using Xojo. In this example, we’ll create a basic to-do list application with a user-friendly interface without writing any HTML, CSS or JavaScript code.

Coding Backend Functionality and Connecting it to the Frontend

While users interact with the frontend of apps, it’s the backend that does the heavy lifting, handling data and core functionality. Xojo makes building these backend systems easier for developers with useful features that create efficient server-side applications without unnecessary complexity. Xojo is a practical choice for developers who want to build solid, functional backends for web (and even desktop or mobile) apps without getting bogged down in overly complicated processes. Here are some notable aspects:

• Database Integration: Xojo supports out-of-the box connections to a variety of databases, including MySQL/MariaDB, PostgreSQL, SQLite, and ODBC. Besides the built-in database classes, now there’s also the DBKit project and the new DatabaseConnection project item.
• RESTful API Creation: Xojo makes it easy to create RESTful APIs, which are essential for enabling communication between the frontend and backend of a web application. By defining endpoints and handling HTTP requests and responses, developers can facilitate data exchange and enhance the interactivity of their varied applications and clients (web, desktop or mobile).
• Session Management: Managing user sessions is crucial for web applications, especially those that require user authentication. Xojo provides built-in support for easy session handling, allowing developers to track user activity and maintain state across different pages, improving the overall user experience.

Integrating the Frontend and Backend

Full-stack development works best when the frontend and backend of an app work well together. Xojo makes this easier by offering a single app development software solution for both parts. Developers can use the same programming language throughout the whole project, which saves time and reduces complications. This approach helps programmers focus on creating a smooth user experience without switching between different tools or languages.

Here are some key points worth taking into account when you want to start building your next successful application:

• Unified Language for Development: One of the standout features of Xojo is that it allows developers to work in one programming language, eliminating the need to switch between multiple languages like HTML, CSS, or JavaScript. This means that both the frontend and backend logic can be implemented using Xojo’s straightforward syntax, streamlining the development process, no matter the OS platform they’re building for.
• Single Integrated Development Environment (IDE): Xojo’s IDE serves as a centralized hub for managing both frontend design and backend coding. Developers can design user interfaces visually, drag and drop elements, and simultaneously write the corresponding backend code without needing to leave the IDE. This integration enables a more intuitive workflow, reducing the chances of errors and inconsistencies.

As the demand for agile and efficient software development continues to rise, the choice of programming language solutions and frameworks can have a significant impact on both project timelines and budgets. Xojo stands out as a compelling alternative for developers and teams accustomed to traditional stacks like LAMP (Linux, Apache, MySQL, and PHP) or MEAN (MongoDB, Express.js, Angular, and Node.js) or any other.

For organizations and startups already familiar with other development stacks, transitioning to Xojo can lead to significant savings in training costs. Xojo’s intuitive interface and single programming language approach mean that team members can quickly adapt without needing extensive retraining. This is especially beneficial for companies looking to onboard new developers or expand their teams. And as an extra plus, using Xojo, you can expand your application supported platforms to include building native desktop clients (Mac, Windows, Linux) or mobile clients (iOS, Android) , all with just one codebase.

And let’s not forget that managing a full-stack application typically involves maintaining multiple technologies, which can result in higher operational costs. Xojo minimizes the need for additional languages and frameworks, resulting in lower maintenance overhead costs and increased efficiency in full-stack development. Updates, debugging, and scaling become more straightforward, allowing teams to allocate resources more effectively.

Is it fair to call Xojo not just a great full-stack development suite but a full-stack development suite that truly optimizes the entire development process and maximizes productivity?

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

Why Clean Coding Matters

Before diving into the specific practices, it’s important to understand why clean coding matters:

1. Readability: Clean code is easier to read and understand, which is crucial when multiple developers are involved or when you revisit your code after some time. This reduces the cognitive load on developers, making it easier to grasp the code’s functionality quickly.

2. Maintainability: Code that follows clean coding principles is easier to maintain and update, reducing the risk of introducing bugs. Maintainable code allows for efficient troubleshooting and quick implementation of changes or new features.

3. Scalability: Clean code can be more easily extended with new features, facilitating the growth of your application. Well-structured code makes it easier to see where and how new functionality can be added without disrupting existing features.

Key Practices for Clean Coding in Xojo

1. Use Meaningful Names

Using meaningful and descriptive names for variables, methods, and classes is one of the simplest yet most powerful practices in clean coding. Avoid abbreviations and opt for clear, self-explanatory names. This practice helps other developers understand your code without needing extensive documentation.

Example:

// Bad
Var n As Integer

// Good
Var userCount As Integer

In the good example, userCount clearly indicates the purpose of the variable, making the code easier to understand at a glance.

2. Follow Consistent Coding and Naming Conventions

Consistent naming conventions make your codebase uniform and easier to navigate. Establish and follow conventions for variables, methods, properties, and classes.

Read more detailed about Coding and Naming Conventions in the Xojo Documentation

3. Keep Methods Short and Focused

Each method should perform a single, well-defined task. If a method is too long or performs multiple tasks, consider refactoring it into smaller, more focused methods. This makes the code more modular and easier to test and maintain.

Example:

// Bad
Sub ProcessUserData()
  ' Code to validate user input
  ' Code to save user data to the database
  ' Code to send a confirmation email
End Sub

// Good
Sub ProcessUserData()
  ValidateUserInput
  SaveUserData
  SendConfirmationEmail
End Sub

Sub ValidateUserInput()
  ' Validation logic
End Sub

Sub SaveUserData()
  ' Database saving logic
End Sub

Sub SendConfirmationEmail()
  ' Email sending logic
End Sub

By breaking down ProcessUserData into smaller methods, each method has a single responsibility, which makes the code easier to understand and maintain.

4. Comment Wisely

Comments should explain why something is done, not what is done. The code itself should be self-explanatory whenever possible. Over-commenting can clutter the code, while under-commenting can make it difficult to understand the rationale behind certain decisions.

Example:

// Bad
// Increment the user count by 1
userCount = userCount + 1

// Good
// Increment the user count to keep track of active users
userCount = userCount + 1

In the good example, the comment provides context for why the increment is necessary, which might not be immediately obvious from the code alone.

5. Use Constants and Enumerations

Avoid using magic numbers and strings. Instead, define constants and enumerations for values that have specific meanings. This makes your code more readable and easier to update.

Example:

// Bad
If statusCode = 200 Then
  ' Success logic
End If

// Good
Const kHTTP_SUCCESS As Integer = 200
If statusCode = kHTTP_SUCCESS Then
  ' Success logic
End If

Using kHTTP_SUCCESS instead of 200 makes the code more readable and the purpose of the value clearer.

Enumerations

Enumerations (enums) are a powerful way to represent a set of related constants. They make your code more readable and maintainable by grouping related values under a single type. This can be particularly useful for handling states, options, or categories in your application.

Example:

// Define an enumeration for user roles
Enum UserRole
  Admin
  Editor
  Viewer
End Enum

// Use the enumeration
Var currentUserRole As UserRole = UserRole.Admin

Select Case currentUserRole
Case UserRole.Admin
  ' Admin-specific logic
Case UserRole.Editor
  ' Editor-specific logic
Case UserRole.Viewer
  ' Viewer-specific logic
End Select

In this example, the UserRole enum defines three possible roles: Admin, Editor, and Viewer. Using an enum makes the code more readable and ensures that only valid roles are assigned to currentUserRole.

6. Handle Errors Gracefully

Implement proper error handling to ensure your application can gracefully recover from unexpected conditions. Use Try…Catch blocks and meaningful error messages. This practice improves the robustness and user experience of your application.

Example:

Try
  ' Code that might throw an exception
Catch e As OutOfBoundsException
  // Log the error and inform the user
  System.DebugLog("Error: " + e.Message)
  MessageBox("An unexpected error occurred.")
End Try

By catching exceptions and providing informative error messages, you help users understand what went wrong and how to proceed, while also aiding in debugging and logging.

7. Refactor Regularly

Refactoring is the process of improving the structure of your code without changing its functionality. Regular refactoring helps keep your code clean and manageable. It involves restructuring your code to improve its internal structure while maintaining its external behavior.

Example:

Before refactoring:

Sub DoEverything()
  ' Lots of code here
End Sub

After refactoring:

Sub DoEverything()
  PerformTaskA
  PerformTaskB
  PerformTaskC
End Sub

Sub PerformTaskA()
  ' Task A code
End Sub

Sub PerformTaskB()
  ' Task B code
End Sub

Sub PerformTaskC()
  ' Task C code
End Sub

By breaking down DoEverything into smaller tasks, the code becomes more modular and easier to maintain.

Advantages and Disadvantages of Clean Coding

Advantages

1. Improved Readability: Clean code is easier for other developers and yourself to read and understand, which is crucial for effective collaboration and maintenance.
2. Easier Maintenance: Maintenance tasks are simplified with well- structured and well-documented code, reducing the time and effort required to update and debug the code.
3. Fewer Bugs: Following clean coding principles reduces the risk of bugs by promoting clarity and simplicity in the code.
4. Better Collaboration: Teams can work more efficiently together when the code is understandable and consistent, reducing misunderstandings and errors.
5. Scalability: It’s easier to integrate new features when the code is well- structured, as the modular design allows for more straightforward extensions.

Disadvantages

1. Time Investment: Clean coding requires more time and effort, especially in naming, documentation, and refactoring. This can slow down initial development but pays off in the long run.
2. Initial Learning Curve: Developers unfamiliar with clean coding principles need time to learn and apply them, which can temporarily decrease productivity.
3. Over-Perfection: There’s a risk of spending too much time perfecting the code, which can impact overall productivity and delay project timelines.

Clean coding is not just a set of guidelines but a mindset that can significantly improve the quality of your software. By adopting clean coding practices in Xojo, you ensure that your codebase remains readable, maintainable, and scalable. Whether you are working on a small project or a large application, these principles will help you write better code and build more robust software.

Incorporating clean coding practices into your development workflow might require an initial investment of time and effort, but the benefits far outweigh the costs. Clean code leads to fewer bugs, easier maintenance, and a codebase that can grow and evolve with your project’s needs.

Happy coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In this article, we will explore the concepts of type casting and iteration within Xojo applications. We will break down a practical example to demonstrate how these techniques can be used to optimize form handling and enhance user interactions.

Understanding Type Casting

Type casting is a concept where a generic control is converted—or “cast”—to a specific type to access its unique properties and methods. This technique is particularly useful when you need to manipulate various controls dynamically within a loop.

For instance, imagine you have multiple text fields on a Window and you want to apply specific actions only to some controls. By using type casting you can loop through all controls, identify those that you’re looking for, and then apply the desired actions.

Type casting is advantageous because it allows you to:

• Access Specific Properties: Gain access to properties and methods specific to the control type
• Enhance Code Maintainability: Write cleaner, more readable and reusable code
• Improve Performance: Perform operations more efficiently by targeting specific control types directly

In essence, type casting allows developers to create more interactive and user-friendly applications by leveraging the full capabilities of each control type (you will see later in our example).

Iterating Through UI Controls

Iteration is a fundamental programming technique used to repeat a block of code multiple times. In Xojo, iterating through controls allows developers to dynamically interact with each instanced control, making it possible to apply specific actions based on the control type.

To iterate through controls in Xojo, you can use a simple For Each loop, which simplifies the process of accessing each control individually. Here’s a basic example:

For Each control As DesktopUIControl In Self.Controls
// Perform actions on each control
Next

Now, let’s utilize type casting to identify and manipulate all DesktopUIControl type controls. For example, if you want to find all DesktopTextField controls and perform certain actions, like disabling them, you can do so as follows:

// Loop through all controls in the current window or container
For Each control As DesktopUIControl In Self.Controls
  // Check if the current control is a DesktopTextField
  If control IsA DesktopTextField Then
    // Cast the control to a DesktopTextField for specific operations
    Var dtfield As DesktopTextField = DesktopTextField(control)
    // Disable the DesktopTextField type controls
    dtfield.Enabled = False
  End If
Next

Tip: Make sure to read more about the operator IsA at https://documentation.xojo.com/api/language/isa.html

Practical Example

Let’s get into a practical example to see type casting and iteration in action.

1. Place different type controls on a Window (buttons, text fields, text areas, popup menus, etc.).
2. Make sure to also place two DesktopTextField controls and name them “PasswordField” and “EmailField”.
3. In a Button control, add the Pressed event and write the following code:

// Loop through all controls in the current Window or Container
For Each control As DesktopUIControl In Self.Controls
  // Test if the current control is a DesktopTextField
  If control IsA DesktopTextField Then
    // Cast the control to a DesktopTextField for specific operations
    Var dtfield As DesktopTextField = DesktopTextField(control)
    
    // Get the name of the current text field
    Var ctrlName As String = dtfield.Name
    
    // Check if the text field is either the password field or email field
    If (ctrlName = "PasswordField") Or (ctrlName = "EmailField") Then
      // Check if the text field is empty
      If dtfield.Text.IsEmpty = True Then
        // If empty, set focus to this field
        dtfield.SetFocus
        // Exit the loop and the current method/function
        Return
      End If
    End If
  End If
Next

The above Xojo code snippet is used to perform a simple form validation. It checks if the password and email fields are filled out, and if either is empty, it sets the focus to the empty field and stops further processing. This is useful for ensuring that users don’t submit a form with these crucial fields left blank.

Conclusion

Mastering software development type casting and iteration not only makes your code more maintainable but it’s also a good strategy for dynamically managing instanced objects.

We encourage you to experiment with these techniques in your own Xojo projects. By applying the principles discussed in this blog post, you’ll be well on your way to creating more efficient and interactive applications.

Make sure to also check the following resources:
1. https://documentation.xojo.com/getting_started/object-oriented_programming/advanced_oop_features.html#casting
2. https://documentation.xojo.com/api/language/isa.html#isa
3. https://blog.xojo.com/2017/12/13/make-your-own-classes-iterables/
4. https://blog.xojo.com/2018/03/21/casting-get-ready-and-keep-the-type/

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Why Read and Write in Chunks?

Loading or writing a large file in one go can overwhelm your application’s memory and degrade performance. Processing files in smaller, manageable chunks allows for better memory management and more responsive applications.

Reading Files in Chunks

To read a large file in chunks, you can repeatedly read smaller portions of the file until you reach the end. Here’s an example:

Var file As FolderItem = FolderItem.ShowOpenFileDialog("text/plain")
If file <> Nil Then
  Const kChunkSize As Integer = 1024  ' 1 KB chunks

  Var inputStream As TextInputStream = TextInputStream.Open(file)
  Var buffer As String

  While Not inputStream.EndOfFile
    buffer = inputStream.Read(kChunkSize)
    // Process the buffer (for demonstration, we'll just print it)
    System.DebugLog(buffer)
 Wend

  inputStream.Close
Else
  MessageBox("No file selected.")
End If

In this example:

• A TextInputStream is created to read the file.
• The kChunkSize defines how much data is read at a time.
• The file is read in a loop until the end is reached, processing each chunk.

Writing Files in Chunks

Writing large files in chunks involves writing smaller portions incrementally. Here’s an example using String.Bytes and String.MiddleBytes for better performance:

Var file As FolderItem = FolderItem.ShowSaveFileDialog("text/plain", "example.txt")
If file <> Nil Then
  Const kChunkSize As Integer = 1024  ' 1 KB chunks

  Var outputStream As TextOutputStream = TextOutputStream.Create(file)
  Var data As String = "Large data string here..." // Your data source
  Var totalBytes As Integer = data.Bytes

  For i As Integer = 0 To totalBytes Step kChunkSize
    Var chunk As String = data.MiddleBytes(i, kChunkSize)
    outputStream.Write(chunk)
  Next

  // Write any remaining data
  If totalBytes Mod kChunkSize <> 0 Then
    Var remainingBytes As Integer = totalBytes Mod kChunkSize
    Var chunk As String = data.MiddleBytes(totalBytes - remainingBytes, remainingBytes)
    outputStream.Write(chunk)
  End If

  outputStream.Close
  MessageBox("File written successfully.")
Else
  MessageBox("No file specified.")
End If

In this example:

• A TextOutputStream is created to write to a file.
• The total bytes of the string are calculated for iteration.
• Data is written in chunks defined by kChunkSize using String.MiddleBytes for improved performance.
• After the loop, any remaining data that didn’t fit into a full chunk is written.

Practical Example: Processing Large Log Files

Processing large log files line by line in chunks can be done as follows:

Var file As FolderItem = FolderItem.ShowOpenFileDialog("text/plain")
If file <> Nil Then
  Const kChunkSize As Integer = 4096 ' 4 KB chunks
  Var inputStream As TextInputStream = TextInputStream.Open(file)
  Var buffer, remaining As String
  While Not inputStream.EndOfFile
    buffer = inputStream.Read(kChunkSize)
    buffer = remaining + buffer
    Var lines() As String = buffer.ToArray(EndOfLine)
    // Process all but the last line
    For i As Integer = lines.FirstIndex To lines.LastIndex - 1
      System.DebugLog(lines(i))
    Next
    // Save the last line for the next chunk
    remaining = lines(lines.LastIndex)
  Wend
  // Process any remaining content
  If Not remaining.IsEmpty Then
    System.DebugLog(remaining)
  End If
  inputStream.Close
Else
  MessageBox("No file selected.")
End If

In this example:

• The file is read in larger chunks (4 KB).
• The buffer is split into lines, and all but the last line are processed.
• The last line is saved and appended to the next chunk to ensure no data is lost.

Advanced Techniques: Handling Binary Files

Reading and writing binary files also benefits from chunk processing. Here’s a basic example of reading binary files in chunks:

Var file As FolderItem = FolderItem.ShowOpenFileDialog("")
If file <> Nil Then
  Const kChunkSize As Integer = 1024 ' 1 KB chunks
  Var binaryStream As BinaryStream = BinaryStream.Open(file, False)
  Var buffer As MemoryBlock
  While Not binaryStream.EndOfFile
    buffer = binaryStream.Read(kChunkSize)
    // Process the buffer (for demonstration, we'll just print its size)
    System.DebugLog(buffer.Size.ToString)
  Wend
  binaryStream.Close
Else
  MessageBox("No file selected.")
End If

In this example:

• A BinaryStream is created to read the file.
• Data is read in chunks and processed accordingly.

Writing Binary Files in Chunks

You can also write binary files in chunks. Here’s a basic example:

Var file As FolderItem = FolderItem.ShowSaveFileDialog("text/plain", "example.txt")
If file <> Nil Then
  Var binaryStream As BinaryStream = BinaryStream.Create(file, True)
  Const kChunkSize As Integer = 1024 ' 1 KB chunks
  Var data As MemoryBlock = ...  ' Your binary data source
  Var totalBytes As Integer = data.Size
  For i As Integer = 0 To totalBytes Step kChunkSize
    Var chunk As MemoryBlock = data.MidB(i, kChunkSize)
    binaryStream.Write(chunk)
  Next
  // Write any remaining data
  If totalBytes Mod kChunkSize <> 0 Then
    Var remainingBytes As Integer = totalBytes Mod kChunkSize
    Var chunk As MemoryBlock = data.MidB(totalBytes - remainingBytes, remainingBytes)
    binaryStream.Write(chunk)
  End If
  binaryStream.Close
  MessageBox("Binary file written successfully.")
Else
  MessageBox("No file specified.")
End If

In this example:

• A BinaryStream is created to write to a file.
• Data is written in chunks using MemoryBlock.MidB to handle binary data.
• After the loop, any remaining data that didn’t fit into a full chunk is written.

Using Threads for Large File Operations

When working with large files, consider using a Thread to perform read and write operations. This keeps the user interface responsive while the file operations are running in the background.

Example of reading a large file in a thread:

Class FileReadThread Inherits Thread
  Private mFile As FolderItem
  Sub Constructor(file As FolderItem)
    mFile = file
  End Sub
  Sub Run()
    Const kChunkSize As Integer = 1024 ' 1 KB chunks
    Var inputStream As TextInputStream = TextInputStream.Open(mFile)
    Var buffer As String
    While Not inputStream.EndOfFile
      buffer = inputStream.Read(kChunkSize)
      // Process the buffer (for demonstration, we'll just print it)
      System.DebugLog(buffer)
    Wend
    inputStream.Close
  End Sub
End Class

// Usage
Var file As FolderItem = FolderItem.ShowOpenFileDialog("text/plain")
If file <> Nil Then
  Var fileThread As New FileReadThread(file)
  fileThread.Run
Else
  MessageBox("No file selected.")
End If

In this example:

• A Thread subclass is created to handle file reading.
• The main UI remains responsive while the thread processes the file in the background.

Conclusion

Handling large files efficiently is crucial for developing robust Xojo applications. By reading and writing files in chunks, you can manage memory usage better and ensure your application remains responsive even when dealing with large datasets. Experiment with these techniques in your projects to experience the benefits.

Happy coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

Throughout that time, software development has generally become more difficult with developers having to learn a wide variety of tools and programming languages, many of which are the hot thing for a short while and then disappear afterwards for the next hot new thing as the cycle repeats.

Up until recently this was not as big a deal for tech companies because they could just hire their way out of the problem. Teams got big and bloated, often because the tools being used were large, complex, rapidly changing and difficult to learn. So the solution, in opposition of the Mythical Man Month, was to throw more people at it. This was feasible because of 0% interest rates and the relative ease of raising capital.

But that era is over. Interest rates are no longer historically low and raising capital for companies is now much harder and less desirable than it once was. This means technology companies are reducing staff and hiring more judiciously. Fewer people now have to do more with less.

The idea of a “one person framework” is that there should be a way for a single developer to create software using just one development framework. This is not a new idea, but it is being talked about again because of these recent changes with how technology companies work. In many ways, Xojo is the original one person framework. From its inception, with inspiration from Visual Basic, Xojo let you make complete apps more efficiently without having to also learn other tools, languages or frameworks.

So what can Xojo, as a one person framework, do for you? Xojo lets you build most of the apps your company is likely to need, using only Xojo itself and its easy-to learn object-oriented programming language (which is similar to Visual Basic and Python, languages that many people already are familiar with). Xojo is a cross-platform, integrated development environment (IDE) that combines an object-oriented programming language, visual designer, code editor, debugger and more into one tool and one framework.

With Xojo you can make apps for most of the commonly used platforms that your business is likely to need.

Desktop Apps

Xojo has been a great way to make desktop apps since its inception in 1998. Unlike Java, Electron or other frameworks you’ve seen throughout the years, Xojo makes native apps and can do so for the major desktop platforms: Windows, macOS and Linux. Yes, that includes native ARM and x86 apps as well.

With a single project, you can click one button to have Xojo build separate native apps for each of those platforms. To further drive that point home, the Xojo IDE itself is a desktop app made with Xojo that runs on Windows, macOS and Linux.

With Xojo you have access to many commonly-used controls and the Xojo framework with support for databases, JSON, XML, RegEx, Zip/Unzip, networking and so much more.

Web Apps

Since 2010, Xojo has been able to make web apps. Xojo uses a somewhat unique approach to web apps by running compiled code on the web server. This code communicates to the app running on the web browser using an internal JavaScript framework and Bootstrap for the UI, which you don’t really need to worry about. It’s all handled automatically.

This approach is great for business purposes as it lets you make web apps using a development pattern that is very similar to what is used to make desktop apps.

If you don’t want to deal with the hassle of managing your own web app server, Xojo even offers Xojo Cloud as a fully managed web hosting service with 1-click deployment of your Xojo web apps.

Mobile Apps

Mobile support first appeared for iOS in 2013 and Android support was recently added in 2023. Using Xojo to make native mobile apps that can be deployed in their respective app stores is yet another way Xojo can help one person make more apps.

A developer that already knows how to use Xojo can jump right into mobile development without having to learn yet another IDE and programming language.

Console Apps

Console apps are text apps that run from the command line. These app are great for automating internal processes or other command-line tools. You can even build Console apps that communicate with other console apps to build a chain of tools for processing or converting data, for example.

Xojo Framework

A single person can create all of the above types of apps because Xojo uses the same programming language for all of them. And as mentioned above, the Xojo framework has many built-in features and is broadly compatible across all the different project types. There are differences, of course, but we strive for consistency and compatibility.

For just a few of its many capabilities, all platforms have the same framework classes and methods for things such as Dictionary, Set, URLConnection, files, SQLite, and most graphics. And speaking of examples, Xojo includes over 400 example projects from which to learn.

Could Xojo Work For You?

As you should now realize, a single developer using Xojo could reasonably create a desktop app (for Windows, macOS and Linux), a web app, and mobile apps for iOS and Android. If you previously had multiple teams of multiple people creating that many apps, then Xojo could really save you a lot of money and time.

Will you use Xojo to make the next Photoshop, FaceBook, Excel or Google Docs clone? Perhaps not, but most companies don’t create those types of apps. Xojo does a lot, but it does not and cannot do everything. There is a limit to what any single framework can do, otherwise it becomes too large for its own good, collapsing under its own weight.

Instead, most businesses have much different needs and often require specially created software. For business apps, especially bespoke small-business apps, Xojo can often be an ideal solution by allowing apps to be created faster, more easily and at less cost than can be done with other tools. This saves you money and time, both of which are in short supply these days.

Xojo is free for learning, development and testing! Give it a spin to see what it can do for you.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What are Git and GitHub?

Git is an open-source version control system, also known as a source control system. Created by Linus Torvalds in 2005, it is now the most popular version control system, supplanting Subversion a while ago.

GitHub is an online Git hosting service, now owned by Microsoft. GitHub provides additional features beyond just Git hosting, but for this post we will focus on its Git hosting. GitHub is free to use for both public and private repositories.

A repository is essentially a place to store a project. Public repositories are great ways to share open-source projects. Others can view and download the source code. Private repositories are only visible to you and are great for your own internal projects.

Git is a distributed version control system, which just means that the source code can be versioned locally and on the server, only synchronizing when necessary. For simplicity it is common to keep both in sync, however. Older version control systems such as Subversion were server-based and versions were only ever kept on the server. A distributed version control system is slightly more complex, but it does have the advantage of making it easier to work offline.

A version control system tracks changes made to text files, something that is incredibly useful when it comes to source code. Tracking changes is a very common task that is needed while programming. You may have seen people save their projects as MyProject1, MyProject2, MyProjectNewVersion, etc. That is a rudimentary way of trying to ensure you don’t lose changes as you update your code. With version control and the Xojo version control project file format you get a much more flexible technique.

When you save your project using the Xojo version control project file format (called Xojo Project) in the file selector, each project item is saved as its own file on the drive. And each of these files is plain text — you could view them using a text editor if you wanted.

You might be thinking: “I’m just a single developer, I don’t need this extra complexity.” But version control systems are not just for multi-person teams. Sure, version control is a great way to make sure that different team members don’t make different changes to the same code. But version tracking is useful to everyone. Even as a single developer, being able to review previous changes, and revert changes if they don’t work out can be a lifesaver. It removes any “fear of breaking things” from your workflow. Plus, having your source code on a remote server (GitHub) can also function as one of your source code backups.

A Quick Example

To give you an example of how this works, consider a single text file that exists in Git: ReadMe.txt

Initially it contains just this text:

Hello!

You pull down the file to your computer (I’ll define Git terms like these below) to work on it. Opening the file in a text editor, you change its text to this and save:

Hello, Xojo!

Now the file on your computer contains that text. This is called the working copy. The file in the repository still has the text “Hello!”. Now you can do a couple useful things.

You can ask to see the differences between the file in the repository and the one in the working copy. When doing so, most tools will highlight the line that changed, showing the repository contents on the left and the working copy contents on the right. This is a wonderful way to review changes made to code.

The other thing you can do is commit the change to the repository. This adds this file to the repository and makes it the latest version. In Git you’ll then be able to see that this file has two versions and you’ll be able to see what the file looked like for each version.

These two things mean that you will never again lose any work. Anytime you make a change to your code that you want to save as a version in the repository, you commit it. You don’t want to commit after every change as that is too granular and will be hard to manage, but it means you can safely make a bunch of big changes to something and still be able to go back and review what the code looked like previously.

The other useful thing you can do is revert changes. If, after saving the file with “Hello, Xojo!” you realize that was a mistake, you can go back to the previous version by choosing to revert the file. This discards the local working copy and pulls down the most recent revision from the repository.

I realize that this might all seem rather different and confusing, but once you do this on a couple small projects you’ll get the hang of it and you will never want to go back to using MyProject1, MyProject2 again!

Terminology

Repository: This is essentially a place to store a group of files, which for our purposes will be a Xojo project saved in the version control file format (Xojo Project).

Clone: Copies the repository to your computer so you can work on it

Fetch: Updates the local repository with any changes that are stored on the server

Pull: Similar to fetch, except that it also copies the changes into the working copy

Commit: Add the changed file to the repository as a new version

Push: Pushes the committed file to the server (GitHub). Often this is done as a single step: Commit and Push.

Working Copy: Your local copy of the repository and the file

General GitHub Usage

With Xojo, the general workflow you will use is:

1. Create repository on GitHub for the project.
2. Pull it down to a folder on your computer.
3. Create a Xojo project.
4. Save it in Xojo Project (text) format into the above folder.
5. Commit and Push it to GitHub.
6. Make additional changes to the Xojo project.
7. Commit and Push to GitHub as necessary.

Create a GitHub Account

If you don’t already have a GitHub account, you’ll need to create one. Head on over to the sign up page to start the process:

Create a Repository

Now that you have a GitHub account, you’ll want to go to your GitHub home page and click the “New Repository” button.

As mentioned above, a repository is essentially where your project is stored. You’ll typically want a separate repository for each project. This is what the new repository form looks like:

For open-source projects you’ll want to make sure “Public” is selected as it’s not really open-source if it is not public. For a public repository, be sure to come up with a catchy “repository name” and always include a description. Choose “Private” for internal projects.

I always check “Add a README file”, which adds an empty README file to the repository. You can update it later, but it is where you’ll briefly describe the project and how to use it (using Markdown). The README is shown by default when you go to the repository in a web browser.

You should also select “Xojo” for the gitignore template (click the dropdown and type “xojo”). This identifies the project as using the Xojo programming language, which helps with searches and also marks the “uistate” file (which contains user-specific UI settings, such as window sizes and positions) so that it is not included in the project.

Last is the license. For most public open-source projects, I recommend the MIT License, which essentially allows anyone to use your code however they want. For private projects, you can leave it at “None”.

Click the Create Repository button to create the repository.

Clone the Repository to your Computer

With the repository created, you can view it on the GitHub website for you account:

From here you’ll be able to see the files in the repository, along with other information.

You are now ready to “clone” the repository to your computer. This copies the repository files to a folder on your computer so you can modify its files. Of course, the only files in the repository will be LICENSE and the empty README.md, but it is still necessary to do the clone so that you can create the folder where you will then add your Xojo code.

In order to clone, you’ll want to use a Git client application. There are many to choose from, but two free ones are the official GitHub Desktop and Atlassian SourceTree. GitHub Desktop is simpler so that is the one I’ll show here.

Download GitHub Desktop: https://desktop.github.com

Start GitHub Desktop and click “Sign into GitHub.com”.

On the Configure Git page, enter the name and email you want to use to identify your commits.

Click Finish on the next page to show the main screen where you have the option of creating new repositories or cloning a repository. Since we already created a repository online in the previous section, you want to select “Clone a Repository” (you can also choose this from the File menu). In the list, choose the repository you created above, choose your local folder location (Choose…) and click Clone.

You now have a folder on your disk where you can add your Xojo project. This is what the repository looks like in GitHub Desktop:

Note: If you are using another Git client, you will choose its “clone a repository from URL” feature and then provide the URL shown in the “Clone or Download” button on the repository page.

Add Your Xojo Project Code

Start Xojo and open the project you want for the repository you cloned (or you can just create a new project). Click “Save As”, make sure the Format is “Xojo Project” and choose the folder you created when you cloned the repository.

Go back to GitHub Desktop and you’ll now see all the Xojo files appearing in the list as “changed files”. (For this test I used a Xojo SQLiteExample.)

You now need to “Commit” these changes. By default they are all selected/checked in GitHub Desktop so you can enter a brief summary and description (for the first commit, often “Initial commit.” is used, but I used “Initial Xojo commit.”) and then click the “Commit to main” button.

Each time you commit you want to be sure to type a clear summary and description of the changes. This will be helpful later when you are reviewing prior commits.

This marked the files as committed in your local repository, which is needed before you can push the changes up to the online repository. Generally speaking you want to commit things after you have made changes that you want to track. You don’t need to immediately push the changes up to the server (online repository) each time, however, people often do as it is simpler. Some Git clients even offer a single button or command to commit and push in one step.

For this initial commit you definitely want to push the commit to the server, so click the button in the toolbar that says “Push origin”. This pushes the commit to the origin, which is the GitHub repository in this case.

If you now go back to the GitHub repository online and refresh the page you’ll now see the files have been committed:

Sharing Your Public Project

If you created a public repository then it is now available on GitHub for anyone to use. People can find it by searching or you can share the URL (perhaps in the Xojo Forum).

Since I published a public project, anyone can use it. This means that they can clone it and push changes to your project as “pull requests”. A pull request is a change that a user has made that they would also like you to apply to your project. Since this is your project, others cannot directly change it without you adding them as contributors. However, you can review these pull requests and choose to pull and merge the change into your project if you want. Or you can reject the pull request — it’s all up to you since it’s your project.

Changing and Updating Your Project

You’ll likely be continuing to change your project to fix bugs and add features. Each change you make shows up in GitHub Desktop where you can commit it and then push it to the server.

As an example, go back to Xojo and make a change to the project. I added some comments to the AddTeamRow method. After saving, the changes are now visible in GitHub Desktop:

You can see the one file that was changed, SQLiteWindow, and the changes (or diff) is shown in the viewer. Here you can see the changes by the blue highlighted lines in the gutter. The first change indicates that line 386 was removed and replaced, with the change noting that “Please” was added.

The next two changes indicate that new lines were added to the code.

It’s always good to review code like this before you commit it to make sure the changes are what you expect.

You can now Commit this change (always add Summary and Description text so you know the reason for the change!) and then Push it to the server (Push origin).

Discarding Changes

Say you’ve made changes to your Xojo project, but realize you’ve really messed things up and want to go back to the way the code was. For example, say I’ve accidentally deleted a bunch of code in the ShowData method and saved the project. In GitHub Desktop, it would look like this:

You can see the big red area indicating the code that was removed.

To discard this change, I can right-click on SQLiteWindow in GitHub Desktop and select Discard Changes. This pops up a confirmation dialog and clicking Discard Changes will restore the file to its previous version, which is the version of the file that was last committed to the repository.

After doing this, you will need to close the project in Xojo and then re-open it so that it can refresh its internal project structures to reflect the discarded changes. After doing that, you can go back to the ShowData method to see that the code is restored.

This capability is a big reason why version control is also incredibly useful for solo developers.

Using or Cloning Other Repositories

Don’t forget that you can also use other people’s public repositories. To do so you’ll want to click the “Clone or Download” button on the repository page.

For simple usage, where you just want to grab the current version of the repository because you don’t intend to change anything, you can then click the Download ZIP button. Once downloaded, unzip the file and then open the project in Xojo where you can use it or copy/paste it into your own projects (review the license agreement before you use projects, of course).

You’ll want to clone a project when you want to manage it using GitHub Desktop (or your GitHub client of choice). This allows you to fetch/pull updates from the online repository and also allows you to make your own changes and push them up to the server where the repository owner will get them as pull requests, as described above.

Change Your Default Project Format

You might find it worthwhile to change your default project format to be the version control format. This way it will always be selected by default when you save. You can change this in Xojo’s General Settings:

Pro Tip: When saving a project for the first time in version control format, it is always a good idea to save into a newly created folder. This ensures that all your files will be neatly contained in one place and won’t accidentally override something else that may have been in the folder.

Git Going

If you’ve created Xojo projects in public repositories on GitHub, be sure to share them in the forum!

This post just scratches the surface of what GitHub does and also only touches lightly on Git and the concept of source control in general. If you’d like to use Git for source control, but would prefer an alternative to GitHub you might also want to check out Atlassian BitBucket which also offers free Git hosting for both private and public repositories.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

Monkeybread Software and Christian Schmitz have organized an exceptional event in Germany taking place in just 2 months – April 22nd to 27th. Take this opportunity to meet and network with members of the global Xojo Community. Meet Geoff Perlman, Xojo’s Founder & CEO and Xojo Engineers, Javier Menendez and Ricardo Cruz.

This event includes:

• Keynotes from Geoff Perlman and Christian Schmitz
• Educational, Feedback and Q&A Sessions
• Web Lab with Xojo’s Ricardo Cruz
• Performance Lab with MBS’s Christian Schmitz
• Dinners, Networking and Sightseeing

Training, Sessions & Events

6 Day Schedule

Monday          22nd April        Welcome Event
Tuesday         23rd April         Sight Seeing Tour & Dinner
Wednesday    24th April         Training Day & Reception in Hotel
Thursday        25th April         Conference & Dinner at Baggerado
Friday             26th April         Conference & Farewell Dinner
Saturday         27th April         Geyser Tour

Einstein Hotel Am Römerpark

The event will be hosted at the Einstein Hotel Am Römerpark, a modern business and conference hotel with unique ambiance and modern facilities. Located in Andernach across from the river Rhine, the hotel features a garden, lounge, terrace and the Sky Bar & Restaurant.

Visit, Attend & Network

Location: Andernach

Networking is not limited to the event hotel! Enjoy the evenings with other Xojo users at casual get-togethers. Arrive a day or two before the conference or stay over the weekend and schedule time to enjoy the area. Join the group for sightseeing and a Geyser Tour. Andernach has much to offer visitors including the “Runde Turm” (round tower), Mariendom (Cathedral of Mary), the old crane on the Rhine River front, the Mikveh or the well preserved town wall.

Learn everything else you need to know and Register Today at Monkeybread Software.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Downloading the Xojo Project

The Xojo project that I demonstrated can be downloaded here. In the zip file, you’ll find the Xojo project file and a “Readme” file. The Readme file includes step-by-step instructions on setting up SuiteTalk REST, a custom NetSuite role, an integration record, and more.

The SuiteQL Query

During the webinar, I spent some time discussing the SuiteQL query that’s used to lookup items based on the keywords that a user enters. I mentioned that there’s a lot of variation between NetSuite instances, both in terms of how they’re configured and customized. That makes NetSuite development both challenging and interesting.

As a result of the variation between NetSuite instances, you may need to modify the SuiteQL query based on how your NetSuite instance is configured. In the Xojo project, you’ll find that the query is stored as a constant named “SuiteQLQuery,” and it’s an attribute of the ListView screen.

The query uses the REGEXP_LIKE condition, which I discussed recently in this blog post. If you’re not already familiar with REGEXP_LIKE, then you might want to read up on it. Also, in the query I’m using the TO_CHAR function to format the “first column Base Price” as currency. Specifically, in the query, you’ll see this: TO_CHAR ( COALESCE( MAX( Price ), 0 ), ‘fmL99G999D00’ ). If you’d like to learn more about the TO_CHAR function and the format model modifiers that it supports, visit: https://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements004.htm#SQLRF00216

Our Next Webinar

Our next Xojo / NetSuite webinar will be held on Thursday, February 22nd at 1PM CT (US). I’ll demonstrate how you can use Xojo to develop a Web app that integrates with NetSuite. To signup, please visit Xojo’s Webinar page. And finally, I want to thank everyone that attended the webinar, as well as Geoff and the entire Xojo team for the opportunity to present.

Tim Dietrich develops custom software for businesses that are running on NetSuite. He makes extensive use of Xojo to develop mobile, desktop, Web apps, and more – all of which integrate seamlessly with NetSuite. To learn more, visit: https://timdietrich.me

Students looking to begin their journey into programming choose Xojo for its ease of use and dedication to cross-platform development. Plus, Xojo is true rapid app development and is ideal for building prototypes and mockups really fast. All of these features benefit from Xojo’s OOP-focus. Xojo also has an active and helpful community and years worth of free, on-line resources.

Ease of Use from App Design to Build

Xojo is known for its user-friendly and visual development environment. It employs a drag-and-drop interface, which can be helpful for students who are new to programming and those who want to rapidly prototype software without delving into complex coding. Xojo is efficient, featuring a streamlined development process and extensive feature set, you can create applications fast without sacrificing quality or functionality. Xojo is based on object-oriented programming principles. Learning OOP through Xojo can provide students with a solid foundation in programming concepts that are widely applicable in the software development industry.

Multiplatform Development for Windows, macOS, Linux, mobile, & web

Xojo is incredibly versatile. Whether you’re interested in desktop, mobile, or web application development, you can built it with Xojo. With its cross-platform capabilities, you can even build applications that run on multiple platforms from a single code-base. This can be particularly valuable for students working on a MacBook but needing app for a Windows machine or vice-versa. Write your app once and compile it for macOS, Windows and Linux.

Rapid Application Development for Prototypes and Mockups

Xojo is designed for rapid application development (RAD), making it an ideal choice for students who need to create functional applications quickly. Students can use Xojo to build practical, real-world applications. This hands-on experience can be valuable for learning and demonstrating software development skills, especially for those working on the design and usability aspects of software development.

Community and Resources

Xojo has an active community and offers resources, including documentation, tutorials, and forums. Students can benefit from this support when learning and troubleshooting. With an active and friendly community of developers, top-notch support team and extensive documentation and tutorials, you’ll always have the help and resources you need to succeed. Learn at your own pace, and have access to the support you need to overcome challenges along the way.

No matter why you choose Xojo, whether for its simplicity, cross-platform capabilities, rapid development or community and resources, Xojo is a valuable tool for learning programming and software development concepts. Xojo is a great place to start when building or looking to expand your development toolkit.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Remote Debugger

With Xojo, you can. Let’s talk about Xojo’s aptly named Remote Debugger. In the instance above, that particular user can install Xojo’s Remote Debugger app on their computer. You and your users can find the app included in the Extras folder of the Xojo download. After your user installs, launches and sets the Options in the Remote Debugger app, you can connect to that user’s computer by adding a connection to it in the Debugging pane of the Settings dialog box in the Xojo IDE on your computer.

Press the Add button, choose a name, add the user’s IP address and the password they created for the Remote Debugger app. If the user is just barely remote (on your local network for example), the Add dialog that appears will show local Remote Debuggers, making the process even easier. If this is the case, you can click on the user’s machine from the list without having to ask them for the their IP address.

It gets a bit complicated if you and the user are not on the same network. That’s because their router has to be configured to allow the connection to get through to their computer. That can be complex and potentially not allowed by their network administrator. The easiest solution in these cases is to use a service such as ZeroTier or Tailscale that creates a secure, private network which effectively puts you both on the same network making it a breeze to connect. (Both of ZeroTier and Tailscale have a service tier that is free.)

Once you’ve added the remote debug host, you can choose Project > Run Remotely and then choose that host to begin the connection. When you do this, your computer will compile a debug version for the computer and OS running on that remote user’s computer. It will then send that build to their computer and launch it. The app will then connect back to your Xojo IDE’s Debugger! You can then debug just as you normally would. Have the user try various functions as you watch what they are doing using screen sharing of some kind. When it drops in to the Debugger, you can step through the code, look at the values of variables and properties, etc., just as you do when debugging on your local computer. In cases like this, it can take a frustrating, painful debugging experience and make it nearly stress-free. In minutes you’ll be staring at the line of code that just wasn’t expecting the user to do what they did.

Also, the remote computer doesn’t have to actually be remote. For example, the Remote Debugger is handy for debugging on local virtual machines or other computers on your desk. It lets you keep your project where it belongs (where you keep it on your computer) while debugging in an OS running somewhere else.

So the next time you wish you could just debug on another computer or virtual machine, remember Xojo’s Remote Debugger! Watch a 13 minute video on Xojo’s Remote Debugger to learn more.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Overflowing with Gratitude

Our stacks are overflowing with appreciation. Appreciation for not being overworked that is. That’s what they have been doing, being overworked in Xojo 2023r3 and slowing things down. In 2023r4, we have optimized our stack overflow checks to reduce the unnecessary effort expended on this task. This optimization will be especially valued by macOS users, as our stack overflow checks consumed the most time on that platform. Take for example, how many more functions calls can be made in 2023r4 over 2023r3 in just one second:

Var start As Integer = System.Ticks
Var count As Integer
While System.Ticks - start < 60
  Reflect("Thanks")
  count = count + 1
Wend

MessageBox count.ToString + " functions calls in one second"

Appreciation for our Users

It would be unjust not to recognize the assistance we’ve received from our users, particularly those who consistently report issues for us to address. A special acknowledgment goes out to those who go the extra mile in helping us pinpoint problems and offer valuable tips and solutions. You know who you are, and we sincerely appreciate your contributions!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

A set is a group of items, not unlike a Dictionary. You can add or remove items from the set, as you might expect, but some of its more unique capabilities let you do a difference, intersection and union of two sets.

• Difference returns a new Set with members that are unique to each Set. This is essentially the items in the first set that are not in the second set.

• Intersection returns a new Set with members that are common to both Sets.

• Union returns a new Set that contain the members of both Sets.

There are also methods to populate a set from an array or a Dictionary. Learn more about using the Set class in the Xojo Programming Documentation.

Set is based on code written by Xojo MVP Kem Tekinay and works on all platforms.

Kem Tekinay is a consultant and developer based in Connecticut. A Xojo MVP, Kem has been an avid Xojo user since the early days and is a world-renowned thinker and philosopher, at least in his own mind. You can find him and his work at MacTechnologies Consulting.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.