What is the prefered solution for parameter / setting storage in cross-platform applications. I use the registry (and occasionally inifiles) in Windows, but branching out it strikes me that this is a fairly win-centric approach.
What is the prefered solution for parameter / setting storage in cross-platform applications. I use the registry (and occasionally inifiles) in Windows, but branching out it strikes me that this is a fairly win-centric approach.
Just curious if anyone has any recommendations...
Just curious if anyone has any recommendations...
XML files are common, though personally I'd use JSON these days...
ReplyDeleteUse of Ini-Files or (the heavier approach) SQLite/(Mem)Dataset files should be an option.
ReplyDeleteXML config, .NET/Mono style might be useful perhaps.
ReplyDeleteKind of depends really. Do you want humans to edit the files or not? What sort of structure do you need to be able to support? I wouldn't recommend anything without having more detailed information about the problem space.
ReplyDeletethere's no excuse to use anything other than SQLite, because:
ReplyDelete- highly flexible, can modify table structures, query existing table names
- high performance, in stead of N ini/xml/json files, you can have just 1 file
- can store virtually any type of data
I worked on a project in the past that was using a custom file format for storing TREES and their data, each TREE had it's own file, I rewrote everything within one day to use just one SQLite database, load/save was many times faster, complex ways of querying data was finally an option, you can easily see how this goes.
bottom line, you will always rename/add/remove data from your configuration files, so why not use SQLite?
Dorin Duminica And if I want my user to be able to edit the configuration file? In a text editor?
ReplyDeleteDavid Heffernan SQLLite does have a lot of editors available, so it's not as opaque as some other databases.
ReplyDeleteI agree it's still not as friendly and easy to edit as a text format config file.
David Heffernan I think that the 20-80 rule applies, how many of your user base actually use a text editor for editing configuration? especially complex ones?
ReplyDelete+Dorin It totally depends on the app and the target user base and the perspective of the developer. For instance, using a db makes life easier for the dev and harder for the user. Which may be fine for you if you don't care much for your users ;-) or if they don't ever want to edit config as text.
ReplyDelete"No excuse" is a tad strong though.
David Heffernan totally agree, buuut, users should usually configure parameters via the interface available in order to avoid mistakes...
ReplyDeleteDorin Duminica That depends. If you want to deploy config to 1000 machines in a corporate setting, then maybe it makes sense to edit text. You simply don't know. You might not need it for your app. Doesn't mean we don't need it for ours.
ReplyDeleteDavid Heffernan there are always exceptions, I agree, however, when we're talking about more than a handful of parameters and 2 or more configuration files, I think a text editor is very unproductive, a single SQLite file can contain multiple "versions" of configurations, can be easily e-mailed, backed-up, copied, etc. there's too much win on the SQLite vs. alternatives.
ReplyDeleteI have used XML for configurations in the past and some of the current projects, works great with OmniXML, buuut, the reality is that almost always someone forgets to do something, and, if everything is done properly great, if there are multiple files, again, too much room for error.
My 2 cents is: use must use a configuration screen/form in order for data to be properly validated, otherwise, if some value is invalid, what do you do? ask the user to "properly fix the configuration file/s" OR default some values which leads to many questions as to why value X and X+1 have the same outcome?
SQL-Lite sounds good until you get into the question of where the file is stored. At that point, it's no different than any other kind of file. Do you know for sure that you can always store them on the device? Or will there be a requirement to have them on a centralized server somewhere (enterprises love that kind of thing)? What about cloud storage?
ReplyDeleteThere are also an increasing number of cloud-based solutions for this, including one from Dropbox that looks like an "INI-file in the cloud". However, I haven't seen any Delphi-specific components or libraries yet that make it easy to use.
David Heffernan definitely no requirement for the user to edit config directly, this would be handled in the ui. It's just the parameter storage itself I'm curious about. Just wondering if I'm better off implementing a getsetting() function for each platform, or to use some mechanism that is platform independent. The former could use the register in windows, and whatever makes sense on each other platform...
ReplyDeleteChris Rolliston has a SharedPreferences (Android) and a CFPreferences (IOS) wrapper to handle the native storage on all FMX platforms. That being said; just use INI files and SQLite where appropriate for the multi platform support. SQLite supports encryption on all platforms (but not supported in the Delphi Android implementation). https://delphihaven.wordpress.com/2013/09/12/a-few-xe5-related-bits/
ReplyDelete