Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have an app that showcases paintings, the number of paintings is about 600 ( so thats 600 png's ). The client wants me to include those images in the app build, so that they are always available to view even if the user if not online. Of course with every image comes some fields like description, painter, and price estimate, so this app will not stream anything and will have all of its data locally.
Anyway I am thinking of the best way to build this app, I thought of core data, and even encoding decoding, but since These images wil never change, I can put them in an images folder and on viewdidload just loop over contents of the folder and build my tableviewcells.
my question is :
1 : Is this a good architecture?
2 : I need to associate those images with the relevant description of them? whats the best way of doing this? If I jump into core data and create models I feel this would be an overkill.
Keep in mind that these images will never change, nor will the data be updated.
Thanks.
A couple of thoughts:
As discussed in your other question, I think that loading all of these images in the app has its disadvantages, given that you say that the app ends up being 300mb. If it is, indeed, going to be larger than 50mb, then I think you might want try to dissuade your customer from insisting that all of the images be included in the app, itself. I understand that you might not be able to convince them, but at least make sure they understand the implication of including all of these images (that it makes it harder to install the app and therefore, they may experience a lower adoption rate of their new app).
Storing the relevant description of the images in Core Data is a good approach. You could also use SQLite (e.g., via the FMDB wrapper), but I'd really encourage you to just use Core Data unless you have some other considerations you haven't shared with us. But a lot of other traditional solutions for simplified persistent data (plists, NSUserDefaults, etc.) might not be appropriate for this many records. Core Data is great and really isn't that complicated. Sure, the first time you use Core Data, it takes a little getting used to, but it seems well suited for this amount of data.
You talk about "encoding and decoding" of the images, and you haven't described anything that would lead us to suggest that sort of process. What encoding/decoding are you contemplating? It's probably easier to just store the images in the local file system (in the bundle if included in the app, elsewhere in the file system if you're downloading the images on the fly).
You mention that you might have "viewDidLoad just loop over contents of the folder and build my tableviewcells". Perhaps I'm reading too much into this (in conjunction with your other question's comments about receiving memory warnings), but given that you are talking about keeping the images descriptions in Core Data, you don't need to be iterating through anything in viewDidLoad. Your UITableViewDataSource methods will simply query the Core Data database and present the appropriate information. I don't see any need to be iterating through anything in viewDidLoad.
I did a similar kind of application some time ago. I used unique code names for the images and created a Core Data DB that would have one column associating the according line of data (description, author, ...) with the "code" name of the image (i.e., 2347.png).
My model was something simple like this:
NSNumber *imageCode // the number that you would use to associate to your images
NSString *name
NSString *author
NSString *description
I'm assuming that you know how to use Core Data.. if you don't, you can refer to this website: Core Data on iOS 5 Tutorial: Getting Started .. it is really helpful!
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am newish to Swift/SwiftUI and have been reading a ton of resources. Using what I am learning along with another example app similar to what I am trying to create, I am making an app that downloads a JSON file from an external API service. That JSON data contains the main part of my code (items from a video game), and my app displays that data in various views. My question though is this: I want a user to be able to track a few things about each object, such as whether they have collected it. I have spent 2-3 weeks researching and trying various options of how to do this, but I am wondering what the most efficient/most popular way of doing something like this is in real-world apps?
Here are some things I have been considering:
Download the API JSON initially and then create both it and my collection data as one object. From there, I would persist that data either be encoding back to a JSON file to be stored in the app's documents directory or in Core Data (or even Realm). The views would actually pull from my own personal data. My first concern with this method is that the API JSON may have changes at some point and I would like the app to always have the most up-to-date version of that info (and I don't know how to compare for updated info yet). My second concern is why keep all of that extra info locally in my app when someone else is already hosting it (or should I do that anyway so the app can be used offline)? If that is the case, is there a tutorial or something around that shows how to manage downloaded JSON data without completely overwriting current data?
Download the API JSON as I currently am (every time a view needs it), and store the collection info as its own data. This is the method I think makes more sense, but my question is how do I combine it with the API JSON? Is it easiest to use JSON or Core Data to combine these files? Do I use the Combine framework? Are there other frameworks/methods that would be better suited for that?
To sum up:
My app downloads JSON files from an API containing items from a game that can be collected. I want the user to be able to track whether they have collected said items from that game. I don't know the best way to do this or what framework/classes I should be researching to do this. Any help would be greatly appreciated.
Warning: Most tutorials for CoreData and SwiftUI, FYI, both ignore MVVM (e.g., using #FetchRequest so your view directly reads your model) and the benefits of abstracting your persistence choice with a DataManager object and protocol. Doing the latter lets you choose CoreData now and switch to Google Firebase later (i.e., launching a collaborative Android version), without changing any View code or really any ViewModel code. You can follow the same principles with JSON decoding as just a different DataManger for initializing data for your ViewModel to apportion to views. Ok, done with soap box.
If your dataset is really big and you plan to query it sideways, CoreData may be nice. Or just a skill to learn. It's not that bad.
But if the use case is something simple like
Character 1
-- isStarredAsAwesome
-- copiesCollected
-- maxLevelofCopyCollected
-- dateCollected
Then just save JSON to the Bundle.
The benefit of CoreData is you could query relationships, such as get a brag sheet of which of my video game characters are in my friends library, but at a higher level and played for fewer hours but collected far in the past. In a large dataset, CoreData will be faster than looping over arrays yourself. But for a smaller dataset like yours may be, again, it may not matter really at all.
I'm building a note-taking app with lots of cross-ways uses of entered text. In this case, CoreData was easier than managing all those relationships in JSON, which makes the extra function calls to manage CoreData CRUD calls worth it.
Also, you may want to ship the JSON with your app and then call an updater on launch. This way, in case the API changes, your app isn't immediately broken until you get around to updating it.
I've used archiving, user defaults, and some Core Data in my apps before, but I'm running into a wall re: the best method for my current scenario. I have an app that needs to instantiate some objects from a resource file each time before it's used. An example of one of the objects could be a "MathQuestion" object that has the properties:
questionID (Int) - 2341
questionText (String) — "What is the square root of _?"
questionVariable (Float) – "4"
correctAnswer (a block/closure that returns a Float) – "{return sqrt(value)}".
Ideally, I'd just have something like a spreadsheet with columns for each of these properties and rows for each of the different questions. That way, I would really be able to visualize all the data and make quick changes during development.
My app uses Parse, which is great for visualization and easy editing of values, but for this case, I'd rather the resources remained on the device and not the Parse server. I've been considering Core Data up till this point, but (this could be my inexperience with C.D.), I'm unaware of any way to manually edit the data—and it seems like it may be overkill for what I'm looking for anyways. (I basically just need a way to upload and parse a CSV!) Any advice would be welcome!
I would still recommend Core Data. It is simply the most efficient and scalable mechanism to store and retrieve data.
When I work in your kind of scenario, what I often do is work with a spreadsheet where I can conveniently edit the data. You could edit a CSV version of it that you have included in your target. (If this does not work for you, you could also copy paste into a separate CSV file right into Xcode.)
On every start, you just trash the data store (using NSFileManager when creating the NSPersistentStoreCoordinator). Then you call a method that reads in the CSV and stores it in Core Data.
Once you are done with development, you simply keep the sqlite file (you can include it in the bundle and copy it over, or re-generate it from your CSV the first time the app runs).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
First I should confess that I am completely new to iOS programming and would like to get an answer for a question which I was googling all the day.
I would be having an app which will contain nearly about 500 images of png format with less size. How to store these images by categories inside the app? From what I learnt,
I can create a plist and map the images with strings (but not recommended by many if the data becomes huge)
creating a manual folder and storing the images (not sure how to do this..)
I have seen lots of codes on how to download and save the image from web or even from camera, but not sure what is the best way to store the in-app images which I have in hand in the app itself. Any sugggestions with sample code would be greatly helpful.
Are you downloading the images? Will these images ever change? Do you have a lot of metadata for each image (you mentioned storing them by categories).
While this is not the only way to implement it, I've had luck implementing things like this using a CoreData model that has an Image entity with category and filename as properties. You can store the images in the NSBundle or anywhere you like as long as they are in the same directory to make it easier on you. Then make sure each filename is unique and maps correctly to the CoreData entity.
This allows you to also at any time, allow more images to be sent down or even replace them. Once you download new images, you add new entities to your CoreData without you needing to update any plist or mapping. You also gain access to NSPredicates with the CoreData fetchRequest, which will allow you to query the CoreData for images that fall under 1 category or even several categories.
The downside is that it requires additional set-up, namely learning CoreData and implementing it into your project.
Edit:
For doing something right now and very basic, the answer is easy to implement. Add the folders into your directory and make sure they have the target/are getting in the bundle. From there, add a pList that for each category lists the filenames of every image you're interested in.
Then when in the app they click on a category, you pull the plist and get the list of names as either a dictionary/array. Then you load all the images.
The downside to this is that you have to manually update the plist for any new changes and send it down to the phone from a server.
I am making a few apps that all require pre-set data to be loaded into the app. This data does not need to be changed or altered in any way as the app progresses - it is simply the data that the app runs on (to give more detail, it is questions for a quiz app). I have elected to use .txt files to store this data, but I wanted to know if this is the best way to do this? Text files allow me to easily change the data without coding. I can also copy and paste from normal documents. Is storing data in this way a good practice, or should I try to hard-code the data/ use a p-list?
The answer to this question depends a lot on how you want to implement your code.
.TXT files might work well, but what happens to the memory requirements when you pass a certain number of questions (e.g. more than 100, or even 10?). Also, what kind of structure are you using in memory to hold the question? If it's a NSDictionary or NSArray, perhaps a .plist file might work better for you.
Raw NSData, or some proprietary format, might work best if you have a lot of non-modifiable questions and you want to try to compress the data down as much as possible (which is a consideration on the low memory / low disk space iPhones).
CoreData might come in handy if you want to store a lot of questions and answers, especially those that users are manually entering in or managing.
For something like this, I will typically use JSON files, and then use Apple's JSON parsing framework.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
i would like to know or maybe if someone can guide me what to do. for now im putting my mind on creating an app that gets the featured products on my website, using storyboard. where i click on products on my list in the tables view the it'll send me to next view to choose the product and when i click on the product and it'll go to another view where its details are written. i would know that it'll be done with parsing, or am i wrong.
its like, products --> products name list from web --> details
the interface and the tableview are already set, coding is just missing i just need to know where to begin.
Just a heads up, this question is far too broad for StackOverflow. You need to break this up and ask several smaller questions.
User Loads app, and it makes a request to your webserver asking for product list
(NSURLConnection)
Webserver receives request and sends encoded data back down. XML? JSON? Up to you.
(What software is running on your webserver? PHP? MySQL? Gather data and encode)
App Receives product data. Parse the encoding wrapper to get your object data.
(JSON or XML to NSDictionary, some good libraries available)
Populate data source with this data
Display data
If you have hundreds of products you'll probably need to reproduce this over and over, but that's up to you. If you only have a dozen or so it's probably easier to just send the whole chunk over on app startup.
Ace, if understand you correctly, the products itself should be fetched from the server. Then you can pick one or display the details. So, I would use a framework to connect and get the results from the server. There are things to consider: XML/JSON data parsing and mapping, Storing and caching the products, so you would be able to display them when there is no connections and updating with the latest changes. I am currently using RestKit which handles pretty much all of these things but for JSON. If you consider CoreData (database storage in iOS) you may need some additional help with retrieving the objects - MagicalRecord framework (on top of RestKit). It will handle things like findAll, findByAttribute:name: so you can get the objects you need. These frameworks are somewhat advanced, but on the other hand, they provide a sound ground for the UI stuff.
When you set up the backend integration and get your objects/collection of objects into the client, you can start populating the TableViews and displaying details.
One more thing to consider for a new project - CocoaPods. It is a very nice way to manage third-party libraries and frameworks. You just specify the libs you need and their versions (the good practice is to always specify the version, so the libs stay in sync) and it will fetch them and create a XCode workspace with them, so you don't have to worry about integrating them into the project. Both of the frameworks are there, just use
pods search <your_framework>
Good luck