I am building app, that there will be a "Admin Panel" Where features can be turned on and off. I have come to realize that i am not sure how that is gonna work. Would I create a Db and make that editable or would i need to make a plist and have the options work from there? Some of the options that will be able to be turned on and off will range from pages, to certain parts of the page. Anyone have any suggestion or somewhere to point me in a direction to get this answer?
How you decide to persist the data is up to you. You might try NSUSerDefaults.
Regardless of how you store the data, you can use an editable UITableView with a cell style of UITableViewCellStyleValue1. This is similar to how many of the settings are handled in the Settings app.
UITableViewCellStyleValue1
A style for a cell with a label on the left side of the cell with
left-aligned and black text; on the right side is a label that has
smaller blue text and is right-aligned. The Settings application uses
cells in this style.
This question is very broad and the answer might be "it depends". A typical approach would be to leverage NSUserDefaults and store the preferences there.
Read the documentation on NSUserDefaults and consult the Preferences and Settings Programming Guide for a bigger picture.
I did this recently and decided against using the database for storage of these options as it seemed unnecessarily complex for just storing a few settings. OTOH, I opted not to use the plist. In the end, I decided to use the NSKeyedArchiver to save those settings out to a file in the filesystem. My decision against the plist was based on the fact that I had a couple of complex data structures I wanted to save.
It may be that it could have been done in a plist or using NSDefaults, but the save and load methods took only a few lines of code, then I created a class containing all of the items I needed to save.
Were I doing it again I think I would do it the same way.
Related
I am designing an idle clicker style app, as I am quite new to programming and thought it would be a good personal project. However I am trying to design the upgrades on a second ViewController menu, however every time that the user leaves the first ViewController, all the settings on that page are lost e.g. stats. I know that there are already similar questions, but they don't relate to my issue and I am having difficulties trying to understand them.
I was just wondering if someone had any way to save this progress both when the user moves to a new viewController and when the app is closed and reopened. Also this might be pushing it, but if you could describe what each part of the code does it would be very helpful.
Thanks
Best is to use UserDefaults to store page contents. You can define key/value pairs and save and load values as needed. Look for it in the IOS documentation. It is very easy to implement it.
In my iOS app, I need to keep track of which sequence numbers have already been received from the server and which sequence numbers need to be retrieved. I want to be able to store this in case the app terminates or crashes.
I am trying to decide which storage method I should use: core data, plist etc.
The list of sequence numbers is dynamic and can change a lot. Any pointers on how to decide on storage will be greatly appreciated.
Without more exact details in your question it is hard to give you an accurate answer. However, what can be provided is some insights on the benefits / downfalls of using the storage systems listed above.
I would stay away from using a plist since your data is dynamic and can change a lot. Every time you save to a plist you will need to overwrite the entire file. This means to change a single value you must retrieve all values, make a single change, and save all values back to the plist. This isn't a modular way of doing such saves and can become problematic if you have a lot of information that is changing and needs to be saved all the time. On the up side - setting up a plist save / read write structure is very easy and fast.
NSUserDefaults should be used for just that. Saving user settings and preferences. It is really easy to use NSUserDefaults, but may become very problematic in the long run if you data is very large. Values returned from NSUserDefaults are immutable too. This may or may not be a problem for your needs.
CoreData may be overkill for what you're doing, unless your sequence numbers are very large. Personally, I would go with CoreData knowing how it can handle dynamic values and how fast it is to save objects compared to the plist and NSUserDefaults. The down side is CoreData is a bit of a learning curve. Unless you have used it before, it is easy to go down the wrong path using it.
As far as pointers on which storage option to use, do some research. Make a list of pros and cons of each storage option. Ask yourself how big your data may get, and what is the best solution. You already know the data is dynamic and may change a lot. Look at the performance of each storage solution.
Here are some helpful reading material links straight from Apple:
Plist
NSUserDefaults
CoreData
Alrighty,
I am new to Xcode so I apologise if I am missing any key points here.
But, I want to have a large list in a UITableView type display. The list will be an array of strings with maybe 500 ish entries and a search bar to search for what ever entry you like. Once found you can tap the entry and it will load a detailed view of what ever it is. I would prefer to not have to have all of the data entry in Xcode and am wondering what would be the neatest way to store/read/write this?
I am leaning towards some sort of data file... but couldnt quite work out how to implement this into Xcode. I have searched around a bit but couldnt find anything which made sense (probably because i am quite new to Xcode).
This will be an App for iOS.
Any ideas?
I understand that you want to create a UITableView displaying static data and your problem is that you don't want to store the data in your code. Depending on how complicated the structure of your data is you could save it in a sql database, store it with coredata, keep it in a xml file or keep it in a file in a custom encoding. I don't quite now where your Problem lies. You can just load the file/database, parse it in an object structure and display it in the tableview. There are a couple of advantages of using a database to a file:
You can create connections easily and handle them without a lot of effort
You only need to load in the memory what is really needed at the moment.
Core data will be fine for you. However if you don't need all of its extra functions and the list will be static (eg, non changing and will be read into the code at runtime in its entirerty) then you can probably use a plist. Plist data can be read directly into arrays.
I am new to iOS app development. I have been reading the documentation on the Apple Developer website as well as reading references on the Internet and I still can't seem to find anything that explains how to separate content from the app such that the content itself is easy to update. The open source iOS examples I have seen all hardcode content into implementation files. Although I have read up on Core Data, I'm not sure if that is the most approriate framework to use for my use case. I want to make a basic app that simply contains lots of views with each view containing various types of UI elements as those seen in HTML for example H1, H2, H3, P, UL and IMG. With Core Data, I'm assuming I would have to somehow save my data(content) into a SQLite database file and then get the app to read it, would this not be tedious? How would I then update the SQLite database in addition to populating it in the first place?
To reiterate I simply want to know, what's the best way to achieve this and still be able to update content relatively easy without having to go to a file that has the content hardcoded.
Many Thanks
easier way is to fit them inside plist files, then read them as NSDictionaries
please read Plist Array to NSDictionary
and Parse Plist (NSString) into NSDictionary for more information
Is it possible to specify validation rules for a particular entry in a Settings.bundle? For instance, would it be possible to restrict a text field to a particular set of characters? Or do I have to alert the user if there is "garbage" in the configuration?
I believe you'll have to alert the user that they entered bad data. There isn't any way to add your own code to the settings bundle beyond the plist values.
Boy, this is an old question, and...boy, things haven't improved.
The settings metaphor -where Apple recommends that you stick ALL your app settings, BTW- is a usability train wreck.
For example, I needed to add a discrete set of integers as a range of values (1 - 7). The default is an Int.
Looks like the only UI element available is a slider.
With continuous range, and no markings.
Oh, well. There's no way in hell that I'd ever use this as a place to put general-purpose app settings; only rather obscure ones that hardly ever need to be tweaked.