I’ve only been around the FileMaker world since FileMaker 9, where I stumbled into it at the school where I was a teacher. So I’m relatively new, though have got a respectable number of versions under my belt. In that time, I’ve seen native FileMaker grow. It has evolved from a database tool to a platform upon which we can develop and access highly-complex custom apps.
Each release of FileMaker brings more features, more tools we have inside the application to develop our own custom apps. And we are grateful for it. We can now use JSON natively. We’ve been able to connect to SQL systems for many versions, and we have cool layout transitions for iOS. We have been able to create custom web pages with CWP technology. With native FileMaker, we can reach out to a web service and retrieve data. The list of native FileMaker possibilities has grown.
But there have been questions about what constitutes native FileMaker. I am guessing because the platform is much different than in FileMaker .fp3, .fp5, of .fp7 days, people worry that they have to work with stuff that’s not native FileMaker.
So let’s discuss what constitutes native FileMaker.
What is Native FileMaker?
Native FileMaker is simply what you can do with FileMaker that requires no additional install of other apps or tools. Additionally, native FileMaker is anything we can do inside of the platform using the tools, objects, functions, script steps, and schema to solve a use case from our client.
- Using the JSON syntax to collect data into an object
- Connecting to a weather api to get the latest weather forecast
- Using a virtual list of data from many different tables into one table
- Creating a web page using Custom Web Publishing that shows data from a FileMaker custom app.
- Creating a SQL query using ExecuteSQL which collects data from an unrelated table in our app.
And much, much more . . .
I have presented these to folks and have gotten back the challenge that these are not native FileMaker. I respect the thoughts of those folks and so I spent some time thinking about how their thoughts differ than mine. And I think it is because there’s a concept of “Idiomatic FileMaker”.
Idiomatic FileMaker includes, it seems, that which we think of first when we think of FileMaker: Scripts, fields, schema, layouts, rectangles, text boxes, etc. That’s what we first learned about as we began our journey. This definition of FileMaker is all well and good but it severely limits our ability to do much with the application. Idiomatic FileMaker hasn’t changed a whole lot since FileMaker 7, and if we stay thinking of FileMaker in these terms, we risk being left behind in the custom-app development world.
Expanding Native FileMaker
But “native FileMaker” has changed. The engineers at the Wedge (the nickname given to FileMaker’s headquarters–a wedge-shaped building) have added so much more to the platform. There is almost no limit to what can be done. (I once pointed out we can’t do 3D drawings in FileMaker. I was corrected. ) And we are glad they have done so. We are glad we can now natively parse JSON with no plugin. It is awesome we can connect to web services and get back data and easily work with it. It is amazing that we can create a list of records using data from all over our custom app without having to build lots of relationships or calculated fields while de-normalizing data. Instead, we can create a virtual list which is native FileMaker, but may not be idiomatic.
Keep Moving Forward
We should take advantage of native FileMaker for our clients. We should leverage everything the platform has as our clients require it. Let’s say our client wants a list view that has columns that sort and a filtering mechanism and even expandable rows, we should seriously consider using a web viewer integration of a DataGrid. If our client wants to be able to send items up to box.com, we have to explore data APIs and Insert from URL. If the client wants to see the weather forecast in their app, we should turn to parsing JSON from a web service that FileMaker has reached out to for the latest information. With open arms, we should embrace the virtually-limitless capability rather than shunting much of it to the side.
The rest of the software development world has already embraced technologies that expand their app. We, as FileMaker developers, designing the best possible custom app for our clients or ourselves, should do the same. FileMaker is not a small-time system anymore (not sure it ever has been small-time). Let’s use native FileMaker to its fullest.