The last week we once again run into an issue with the Linux shared library loader. In a Xojo app you may end up having several libraries several times in different versions. For example the system provides the zlib library in some version, e.g. 1.2.3 on an older Linux installation. The MBS Compression Plugin uses zlib in version 1.2.8 while DynaPDF uses a custom patched 1.2.7 for the PDF compression. Also the Xojo runtime may come with its own version.
Now it seems like there can be a problem. All those versions of the library may or may not export publicly their functions and you may have several deflateInit functions around. Now when resolving the functions references in a shared library (e.g. plugin), the loader will pick one by name to solve it. And for us this was catastrophic a few times. Because you end up getting a different version of the library than expected. DynaPDF brings 1.2.7, but may end up getting tied up to 1.2.3 or 1.2.8. For PNG, JPEG, zlib and other libraries, there are checks in place to make sure the header files and the library matches in version. If versions won’t match data structures may have different sizes or parameters to functions have different meanings.
In DynaPDF the resulting error from a different zlib version is:
This is solved for MBS Plugin 17.3pr4 by setting all non-exported symbols to local symbols. This should make all functions to resolve within the library take precedence over functions from other libraries.
For DynaPDF we added GetPNGVersion, GetJPEGVersion, GetTIFFVersion and GetZlibVersion functions. They allow you to query the jpeg, png, tiff and zlib versions used in the DynaPDF library.
PS: For FileMaker Cloud we do the same fix next prerelease.
Open Terminal, cd to the folder of the app sdk. For me this command line:
Run the makeprojdir command giving a folder name, the app name and the identifier:
./makeprojdir test test de.monkeybreadsoftware.test
Of course you use your own names and bundle id.
Open test project in Xcode
In the target popup menu you can select a simulated device and when you run the app. The section for installed plugins will be empty.
Congratulations, now the app should run in simulator!
If you have trouble till here, maybe you review the iOS App SDK 16 Guide.
Now you can drag & drop the plugin into the plugins section in the Xcode project right in the Custom Application Resources folder.
Run the app again and it should show the plugin listed with version.
Now you can use the plugin in your scripts for the solution and test in the simulator.
If the plugin is not visible, please check logs and see if some error occurred. Please use MBS("Trace") command to write all plugin calls to the log in Xcode, so you spot errors easier.
Next you can change target to be your iPhone and run the app on the iPhone. This may need some code signing things and an Apple ID registered for developing.
Go to build settings and assign a Team for the code signing. Xcode can do the rest, at least for me.
Once this is set the app can build and run on your iPhone.
Now screen shut look like the screenshot on the right side.
Next step is to build for archive.
This gives you the build app with symbol file (for debugging) and an "Upload to App Store" button, if that is your destination.
Well, the creation of the ipa file to distribute will succeed.
Anyway, when you distribute your app via Mobile Device Management, you just need the app file or the ipa archive.
You may want to split our plugin into an arm only version for distribution to save some space.
Enjoy FileMaker on iOS with MBS Plugin!
Which nicely proofs that we used to use FileMaker a long time ago. So somewhere 1996/1997 we bought Claris FileMaker Pro 3 and used it with a little database to track some inventory.
I do remember seeing the typical record navigation controls in several apps over the years and those may have been FileMaker runtimes.
When we started making FileMaker plugins in 2006, we got FileMaker Pro Advanced in version 8.5.
So how long ago are your roots to using FileMaker?
At FileMaker conferences I met people who started with FileMaker Pro 1.0 or even before with Nutshell.
And even if you needed to convert your database a few times, there could be solutions which run the last 30 years with FileMaker. That's a long time in computer history!
Another function set for iOS is done: ImagePicker. It allows you to pick photos from the saved camera roll, the photo library and take a new picture via camera. You can control a lot of settings, e.g. whether to allow editing or which camera (front or rear) to use.
In all cases we call a script trigger later when the user selected an image. There you can take the picture and add it to a container field in your database.
Here is the same script to show the picker. Source Type is for example "Camera":
Set Variable [ $SourceType ; Value: Get(ScriptParameter) ]
In gerade mal vier Monaten startet die FileMaker Konferenz in Salzburg.
So langsam füllt sich die Konferenz und noch ein paar Tage gibt es den Frühbucherrabatt. (bis 17.6.)
Vom 12. bis 14. Oktober 2017 treffen sich wieder ca. 200 Teilnehmer im Pitter in Salzburg. Die deutschsprachige FileMaker Entwickler treffen sich um Neuigkeiten zu FileMaker zu erfahren, mit den Mitarbeitern von FileMaker in Kontakt zu kommen und um alte Freundschaften zu pflegen.
Bitte bald anmelden um ein Ticket zu bekommen. Die Konferenztickets und die Zimmer im Hotel Crowne Plaza Salzburg waren in den vorherigen Jahren schon vor der Konferenz ausverkauft.
Für die MBS Plugin Schulung am 11. Oktober sind noch Plätze frei. Nehmen sie sich einen Tag Zeit zu erfahren, was alles im MBS Plugin steckt, was dieses Jahr neu ist und probieren wir direkt einige Funktionen aus. Je nach den Wünschen der Teilnehmer bauen wir gerne neue Beispiele, die dann bestimmte Funktionen zeigen.
Screenshots are in German, but whatever localization you use, the dialog will look correct in your language.
For both you can check if service is configured for the user and show the panel with your message to send. You can define message text, add URLs and images from both container fields and image files on the device. The user can change text and press send. You get a script triggered when the user is finished.
We also have SocialRequest functions to post without showing a dialog and those do work on iOS now.
Will be soon available in next plugin version. Or email if you like to try today.
Now the are a lot of new APIs, but I'd like to know from you what you'd like to see in our plugins for Xojo and FileMaker.
Usually we provide lower level wrapper for Xojo to Apple's APIs for macOS with hiding all the threading issues from you and translating values from native Xojo types to the matching Foundation types. As there is currently no iOS plugin SDK for Xojo, we can't make all features available via declares.
For FileMaker we usually provide a much more higher level API to do selected things and provide plugin functions for both macOS and iOS.
If you have ideas and wishes, please email me. I'll keep a list and if we have a lot of wishes for a given API, I may give it some priority.
Screenshots are in German, but whatever localization you use, the dialog will look correct in any language.
For both you can check if sending is possible, show the panel with your message to send. You can define subject, body text and add several attachments. For emails we can use HTML text of course.
The user can change text and add more attachments of course.
Will be soon available in next plugin version. Or email if you like to try today.
On my next visit to Nuremberg, I'd love to make another developer meeting:
Wer hat Interesse an einem FileMaker & Xojo Entwicklertreffen im Juni in Nürnberg?
Einfach gemütlich zusammen sitzen und über Xojo und FileMaker Neuigkeiten, Konferenzen und die täglichen Probleme bei der Softwareentwicklung unterhalten.
Gerne zeige ich auch neue Pluginfunktionen oder helfe bei Problemen mit Projekten. Einfach Computer mitbringen und was zeigen.
Wir treffen uns am 16. Juni 2018 in einem Biergarten in Nürnberg.
Bei Interesse bitte bei mir melden.
First we are happy to report that this can work. Your FileMaker iOS SDK application can register for notifications and report you the device token. This device token is needed to send push notifications to the device. Push notifications can show a message to user, set the app badge or transfer data to the app.
First please review our documentation for the UNNotification functions. When you add the MBS Plugin to the project, please also add our MBSInit framework. You may need to split both to only include the arm versions in the final app to run on a device.
After your app launched on a device, you may be asked to allow notifications. This happens only if MBSInit framework is loaded and triggers the early initialization of our plugin. The function UNNotification.RemoteNotificationsDeviceToken returns you the device token as a long text with hex encoding. If something goes wrong, you get an empty text there and the function UNNotification.RemoteNotificationsError will give an error message, e.g. that this is not available in simulator.
Let me know if you like to try this and need assistant. You should be able to get notifications to show messages to the user, launch the app and trigger scripts. Even the sending of notifications to devices should work via MBS Plugin by using CURL functions to talk to Apple's web service.
We got a new video for you about our latest functions for FileMaker 16. While talking to other developers at dotfmp conference in Berlin, a few developers told me about the new card window feature in FileMaker 16 lacking a few details in functionality.
A quick check showed that a plugin could of course monitor mouse clicks and trigger a script if a click is done outside a given area. The new EventMonitor.SetCardWindow function allows you to define where the card is and which script to trigger in case of a click. This script can than clear the trigger with EventMonitor.ClearCardWindow and close the card.
Please try next week the new plugin and this feature and let me know how it works for you.