I have severals configuration settings that I need to be able to access throughout my application. These settings can't and won't be editable by the user. I'm coming from a web application background and I don't know what approach is recommended.
If my application was for the web, I would create a file config file config.py or config.php then set everything I need to set then load it where I need it. For iOS, I came across NSUserDefaults where it is use mainly for user preferences (at least that what I see people using it for). However the data I wish to store are not preferences at all.
Should I create a class and store my values in it or use NSUserDefaults ?
It is perfectly fine to use NSUserDefaults to store application configuration information that is not a user-visible configuration option. That said, my recommendation would be to create a class on top of NSUserDefault so that 1.) it is easier to change the underlying implementation if necessary and 2.) you have the strings representing the variable names only in one place (to avoid accidental spelling differences) and you can refer to individual variables by specific getter functions.
Related
Is it possible to change the application data from a extension?
I was creating a visual extension(table) in which if I change the value of a cell I should be able to change the value in the application level (not in database level),How can I achieve this?
Changing the value in Qhypercube.[].qDataPages.qDataPages... is only changing the value in Extension level.
I think the problem here is data persistence, since Qlik Sense itself is not a data warehouse or a true "data store" in the traditional sense. When you load data from a database into an app and it goes through the app's load script, it's then cached to the underlying QVF file for the app. Updating the data would need to happen at either the source level (the database in this case), an intermediary store like a QVD, or "on the fly" via variables and chart scripting. Those first two options are persistent and that third one is not.
That's why if you look at other similar Qlik extensions that enable users to input data, they are "writeback" solutions, as they update the underlying database that the app is pulling from. You can find a few examples of those here, here, and here.
A few existing ones also take the approach of outputting to QVDs, which could be your best bet if you want to avoid updating a database. See this one as an example, as well as their implementation docs here.
You could probably achieve all of this with a combination of:
Getting the hypercube of your (updated) table (more info)
Create a session app (more info)
Write to a new or existing QVD (more info)
(Partial) reload the current app (more info)
This would all depend on the Update rights of the users of the app, though.
This question already has an answer here:
Sharing data in between apps in IOS
(1 answer)
Closed 7 years ago.
I've been doing research on how to share data between applications securely. I'd like to get some info on the correct way to handle this before I do a deep dive on implementation using the wrong method. Just cause you can do something does not necessarily mean you should.
User Case: I am working on a suite of language learning apps that have a shared audio file base of several hundred audio files and json files containing important data corresponding to a language. I'd prefer to allow the user to not have to re-download the language bundle when they use another app in our suite.
1. App Extensions - Document Provider Non-UI Variant
According to the documentation:
The File Provider extension grants access to files outside the host app’s sandbox with the open and move actions. This extension (sometimes shortened here to file provider) also allows the host app to download files without presenting a document picker view controller. This feature lets the host app access previously opened documents using secure URL bookmarks, even if those files are no longer stored on the device.
On the surface this seems like a really solid solution. My main concern stems from the last couple lines where it state that the application can download the files no longer stored on the device. I want the files to be stored locally on the device to prevent constant downloading. If the Document Provider does store the files locally and allow the various applications in the group to access the files, then I think this could work.
2. Shared Keychain Access
Allows you to securely store data to a shared keychain that other applications that are part of a suite of applications can access. All applications that share keychain access must use the same app ID prefix. For an example of shared keychain access in action.
I've looked a little into the documentation of this one, and I think this might be the best fit. My major concern with this solution is whether or not there is a size limit to the data uploaded and if mp3/ogg/json file types are allowed. Most the examples/uses I have found with this solution point to sharing strings and small data, I am not sure if it will handle large data like json or audio files.
I also found this repo that apparently makes dealing with Keychain easier:
3. Custom Pasteboards
The custom pasteboard is best for the purpose of semi-privately sharing custom data between two applications. Custom pasteboards are identified using unique names. They can persist data beyond the application that creates them, allowing a pasteboard to hold onto data after the application is terminated or even after rebooting the device.
When writing or reading data to and from a pasteboard, you must specify a pasteboard type. Pasteboard types typically use a uniform type identifier (UTI) to identify the type of data going into and being retrieved from the pasteboard. See Apple’s UIPasteboard Class Reference documentation for additional information.
Above documentation pulled from this post
My main concern with this solution is that perhaps it is a bit of a hack. Logically a pasteboard seems like something that temporarily holds data and allows sharing between apps, whereas the solution I am looking for needs to be more of a permanent solution.
I'd appreciate any info on best practices towards sharing these types of files between apps. I assume there are plenty of other solutions I've omitted here, so if there is a better alternative I'd love some info on it. If it happens one of the listed solutions I have placed here is a good way to solve this problem I'd love to have some more info on your experience with working with them and if my concerns with them are valid, or nothing to worry about.
Thx in advance. As always, well written answers get up-votes ;)
I believe the best approach would be to enable data sharing by setting up an app group. This is Apple's recommended solution for sharing data between applications and extensions, and I believe for sharing data between apps in general.
See the section "Sharing Data with Your Containing App"
Also see "Adding an App to an App Group":
I currently have my app settings stored in an Entity called Settings. Each of my settings is an attribute. I have one Settings object which I load in my app delegate, and I access it through the delegate throughout the project. I am thinking of moving the settings to NSUser defaults. I would probably not need the Settings bundle since I have everything setup in the app. Besides the use of the settings bundle, I was wondering if anyone can tell me what are the benefits of using NSUserDefaults over my current method? Is there any way my choice can affect/improve app performance?
If there are a substantial number of items to be saved then archiving or a plist such as you currently have may well be best.
One advantage of NSUserDefaults is that specific items can be accessed and saved from any method individually. NSUserDefaults also supports several non object types.
Typically if I need to save essentially most of a classes state I will use archiving.
There is no reason not to use a combination, choose the method of persistence of each item individually.
Generally there will not be a large performance difference.
For substantial data choose Core Data.
I'm setting out to create an app where it will use 7-10 instances of a custom class, lets call them "books" each class will consist of a number of pages, a title, a int of how many pages a book contains and possibly some notes of the author associated with a specific page.
My question is what is the best way of creating these objects. it seems weak to just hard-code all the books together programatically, and if there are more added after the initial release I'd almost like to have the author be able to construct them with a simple desktop app.
So I guess what I'm looking for is a way to a create a small app to create instances of a custom class on a desktop, then bring those instances into the iphone app.
I only have an iphone dev license as far as I know. Obviously you don't have to be super specific but I'm looking for ways to accomplish this type of task. Maybe if there is a good way to go about hard coding them I would like to hear about that as well.
I guess an equivalent would be a game developer making like a level editor for his game so he doesn't have to create the boards programatically.
Provide your data in XML or JSON
format (or whatever flavour of file
format you prefer), this is to transfer data to/from application.
Parse your data file (xml/json) and store in permanent storage (file,sqlite,core data) on phone. This is the data that your application will regularly use from now on.
Offer user the option to get updates over network
If user selects to get updates, download updated xml/jason file over network, parse and update your permanent store
Use SQLite. You could easily create a sqlite database editor, or use some of the free ones out there. The iPhone can read a sqlite database natively, just include the library.
I'm doing an iPhone application. In this app, I just want to have a database to be used as a looked up table for values in my app. The only thing the database will do was to supply me the values I needed depending on the query of the program. It won't do any addition or deletion in the database. My question was how do I initialize a default data on the application using CoreData. So that when the program starts It already had all the values needed.
If you have other suggestions of what is better do or what are other alternatives, please tell me.
Thanks.
I would create a simple Mac application, starting from the template for a Core Data document-based application. Copy your existing .xcdatamodel over the default one in the project (or add the new data model and be sure to rename anywhere that refers to the default model). Open up the XIB file for the document window in Interface Builder and drag the Core Data Entity item into it from the Interface Builder library inspector. From the resulting dialog, choose an entity to display and select an interface to display it in.
What this will do is create a fully functional interface for adding, removing, or editing the properties of that entity type. Everything should be hooked up via Cocoa Bindings so that you don't need to write a line of code for this to work. You can add interfaces for each entity type in your model this way.
This will let you quickly enter and edit data within a Core Data document, which you can then save out to disk and add as a resource to your iPhone application. The SQLite database structures are fully compatible between the desktop and iPhone Core Data implementations, so I've found that this is a quick and easy way of testing your iPhone Core Data code.
Please refer to the Core Data Programming Guide, or see below (copy from the PG):
"
How do I initialize a store with default data?
There are two issues here: creating the data, and ensuring the data is imported only once.
There are several ways to create the data.
You can create a separate persistent store that contains the default
data and include the store as an application resource. When you want
to use it, you must either copy the whole store to a suitable
location, or copy the objects from the defaults store to an existing
store. For small datasets, you can create the managed objects
directly in code.
You can create a property list—or some other file-based
representation—of the data, and store it as an application resource.
When you want to use it, you must open the file and parse the
representation to create managed objects.
You should not use this technique on iOS, and only if absolutely necessary on Mac OS X. Parsing a file to create a store incurs unnecessary overhead. It is much better to create a Core Data store yourself offline and use it directly in your application.
There are also several ways to ensure that the defaults are imported only once:
If you are using iOS or creating a non-document-based application for
Mac OS X, you can add a check on application launch to determine
whether a file exists at the location you specify for the
application’s store. If it doesn't, you need to import the data. For
an iOS-based example, see CoreDataBooks .
If you are creating a document-based application using NSPersistentDocument, you initialize
the defaults in initWithType:error:.
If there is a possibility that the store (hence file) might be
created but the data not imported, then you can add a metadata flag
to the store. You can check the metadata (using
metadataForPersistentStoreWithURL:error:) more efficiently than
executing a fetch (and it does not require you to hard code any
default data values).
"
As mentioned above, generally we need to create a pre-populated default store with code, then use it as a
resource file, and copy it from resource bundle to document directory if the coredata file is missing. Please search the CoreDataBooks code example in your Xcode Organizer (or Apple Developer Center), and look at the - (NSPersistentStoreCoordinator *)persistentStoreCoordinator method.
I racked my brain for hours attempting to solve this. What I came up with was simply not to save the database. That way, it will be initialized each time the app is opened. If you save it, it will continue to duplicate.
I would write a tool that populates a database with the data you want in it, generate the db at build time and stuff it in your resources folder. If you are not going to write to it you can just leave it there and access it directly, if you ever did want to write to it you would need to copy it somewhere you are allowed to write (like the documents folder).