In our ongoing effort to improve the building of 4D applications, we’ve added a few functionalities to 4D v19R5 that you’ll certainly find useful.
The first one is the ability to remove some of the biggest 4D modules from your applications: CEF, Mecab, PHP, Spell Checker, and 4D Updater. If you don’t need some of these modules, you’ll be able to significantly reduce the size of your applications.
We also changed the final directory when you build a compiled structure, in order to accommodate those using multiple compiled versions of the same structure.
As for our Japanese customers, we have merged the Japanese version of 4D and the international one on MacOS.
Let’s delve into the details.
Projects introduced the new directory.json file containing users, groups and permissions. It allows authentication, restrictions, permissions on several parts of the application, through settings or code. Let’s see the new improvements about this file usage in merged server projects.
You may want to restrict administrators from accessing the Data Explorer and the Runtime Explorer in your deployed merged servers. 4D v19 R5 enables to do so.
Here is everything you need to know.
As a publisher, you sometimes want to duplicate a merged client application to connect each of them to their dedicated 4D Server. Let’s see how to do this.
The release of Silicon Macs had a great impact on the way 4D compiles applications. Before v19, 4D was compiling only for Intel architecture, using the same code on Mac and Windows. But Silicon Macs use a new architecture, and as such 4D needs to compile specifically for Silicon. It affects cross-platform client/server application building.
As long as you build your server on Mac, it’s not much of an issue, as you can compile for both Intel and Silicon platforms. But on Windows, it’s not possible to compile for Silicon Macs. Our current recommendation is to compile the project on Mac for both architectures, and then copy it on a Windows machine before building the server. Unfortunately, for big projects with a lot of data, the copy can take some time.
To prevent session loss, 4D monitors the sleeping state of remote 4D applications.
When a user is connected from a remote 4D application to a 4D Server and their computer goes into sleep mode, the information is sent to 4D Server. At the moment the user’s computer wakes up, the remote 4D application then recovers its execution context.
When generating .4dz files, 4D uses a standard zip format by default. If you are a software publisher, you’ll be happy to know that 4D v19 R2 added a feature that allows preventing users of your application from seeing the content of the 4DZ, and therefore from being able to modify it.
On Mac, application signature has become a standard, and since Big Sur, you can’t even run unsigned applications. In the past, we published a workaround to build client-server applications running on a Windows server and accepting connections from Mac clients. With the release of 4D v19, we have updated the application building in 4D to handle this case. Here is how you can build a single platform or a cross-platform application in v19.
There may be times when you might need users to connect to many instances of the same merged server application. When this happens, the merged client application downloads as many local resources as the server connections. But if your server’s Resources folder is huge, this can be quite a drain on time, volume, and network! Fortunately, 4D v18 R5 has a solution for this scenario!
Hosting several 4D Server applications on the same machine is not unusual, especially for production and pre-production environments. But if your machine hosts merged server applications built with different 4D versions, which is the case if you use your pre-production server with the latest 4D version, you may encounter problems due to the shared 4D structure folder.
Let’s see how to resolve this issue.