I am new to developing iPhone apps, and wanted to be sure that I am laying the correct foundation as I go about the coding process. The app that I am developing will permit users to login, upload photos from their iPhones, write a short description for the picture, as well as view other users photos. Where should I be storing the following data, and how should this be architect-ed? I have heard core data, sqlite, MySQL, PostgreSQL, etc... The data I need to capture and store is:
-Username
-Password
-Photos they upload
-Descriptions of the photos
Ideally, the architecture will support hundreds of thousands of user uploaded images (hypothetically).
I understand that this question is probably incredibly basic on some levels, but again, this is my first time navigating the data storage aspect of an iPhone app.
For Username and Password, look up KeyChain.
For everything else Core Data is good. SQLite is a possibility.
Related
I want to build a flutter app which focuses on learning plant names with the help of a lot of pictures. In total there will be 600-800 pictures.
question: Do I store these pictures all in the app or in a database?
From what I read so far I guess the app would be too big if I store all these pictures in the app.
question: Which database should I use for storing such an amount of pictures?
I want to give the possibility to store a lection/course (containing 30-40 pictures) locally on the phone to be able to learn without internet connection.
question: Which database should I use for that?
Question #1: Do I store these pictures all in the app or in a
database?
You should not store all the images in your app. Use the Cloud Storage for Firebase service to store your pictures and download them to your app as desired.
Question #2: Which database should I use for storing such an amount of pictures?
You should use Cloud Storage for Firebase to store your pictures: "Cloud Storage for Firebase is built for app developers who need to store and serve user-generated content, such as photos or videos."
Question #3: I want to give the possibility to store a section/course (containing 30-40 pictures) locally on the phone to be
able to learn without internet connection. Which database should I use
for that?
You can save these pictures locally as explained here in the Firebase doc: "The writeToFile() method downloads a file directly to a local device. Use this if your users want to have access to the file while offline."
If in a database, get pic to many times, and much more than the free limit of database , we will prefer pic in app than in database.
But in app will never consider the cost, just keep the develop account. Maybe, a pic could compress down to 50kb each, and the app will not too big to download.
mongodb google-could amazon ... all database on the market can serve you.
above dbs are good. the more resourses on net, the better envirnment we like.
Basically what I want to do I be able to enter in data on a website, and have it appear on an iPhone app, so I want it to send the data to my iPhone, and store it so that every time i open the app, it will re load the data and put it on the screen. How can I go about this?
You will need a backend-side to your app. If you don't have any experience with backend-developing, I would recommend taking a look at Parse.com or other similar backend providers. They give you a server-solution without having to develop it yourself.
Good luck, and welcome to SO!
My app is going to save a flag in the database (core data) saying whether the user is authenticated or not. How easy or difficult is to someone to access the "core data" database and change the information there without going through the App?
I am going to save a flag there saying "this user is authenticated" so he never has to authenticate again. This is a fun app, not a bank app, so I wonder if that's ok.
Putting in other words: Should I assume that a regular iPhone user (not jailbroken of course) will not be able to mess with the "core data" database and this database can only be accessed through its intended iphone app?
This isn't the kind of thing you should use Core Data for anyway. You should instead use NSUserDefaults or the keychain (depending on if you're just storing that flag, or associated user/password information).
The user defaults are there for storing settings, the keychain for private data. Use the right screwdriver for the right screw.
The iOS app sandbox is quite tight on-device. As such other apps won't be able to access your database, nor will the user on-device.
Application data in the app's Documents directory is backed up through iTunes, however. Though I've never tried such a thing, I can imagine a scenario where the user installs and runs your app but is not authenticated. He syncs and the user data is written to his computer. He opens the backed-up resource on his PC (iTunes does encrypt or obfuscate it) and figures out how to change the sqlite database or plist to show himself as authenticated. He then uninstalls the app on his device, then reinstalls it through iTunes, authenticating himself.
If the scenario is possible, you could potentially store the database in the cache directory instead, a directory that's not backed up when the device is synced with iTunes. It means the database would vanish if the user had to restore his device, but that might be an acceptable loss in your scenario, I don't know.
Edit
I agree with jer that the database isn't the best place to store such info, and if you're targeting iOS 3.2 and above, keychain is definitely the better place.
I don't believe a user on a non jailbroken phone would be able to mess with the data.
I'm currently in the middle of developing an iPhone app with a big reference database (using Core Data backed with a pre-populated sqlite database). Once the app is live and deployed to a client's iPhone, I need the facility to update/insert a small amount of data. What are best practices / methods for doing this?
There may be occassions when the frequency of updates will be daily for a month or so. Other occassions when a data update happens once every few months.
What is the recommended way of doing this? Note, I don't anticipate any data model changes for these updates -- this is purely an insert/update of data.
At the moment I'm starting to research the use of push data notifications (q:payload size restrictions?), app store updates (q:code/data model only, not data updates?) and the use of my own ad hoc data server (which the app connects to routinely to check for updates).
Can anyone please provide me any pointers on the above?
Thanks in advance
IIRC Push Notifications have a maximum payload of 256 bytes. Enough for notification purposes, but not more. Your app would still have to download the actual data from your own server after receiving the notification.
Note that the app bundle is not writable on the device. So if your app needs to update the data store, you should copy the pre-populated database file from the app bundle to the app's documents directory on first launch.
App Store updates would certainly be feasible (especially now that Apple seems to have gotten its review process down to a few days at most) but note that an App Store update will always replace the entire app bundle (code and data), so if your pre-populated reference database is big, the customer would have to download it in full every time.
I'm currently creating an iPhone app where in one part of my app you can view your twitter stream. I'm unsure if I need to ever save the twitter information to a sqlite database or not.
So here is the flow of this part of the app:
press button to see twitter stream
go get twitter stream
display twitter stream in table view
I'm wondering if I should ever save the twitter stream into a database. Any advice?
I would say you should save the twitter stream. You should almost always try to save some application state in an iPhone app. This way, if the user is interrupted (a phone call) they can jump back into your app without missing a beat.
There are a few different ways to persist data in an iPhone app. Instead of bothering with using a SQLite database you will almost certainly want to use Core Data, which is new in iPhone OS 3.0
If you won't ask the user to provide his/her twitter credentials and it will be an anonymous stream, you don't need to store anything.
But the minute you want to store some preferences, actual state (to show the user what he/she was seeing when a phone call came or after application restart) you will need to store persistent data.
I think it's important to cache web data. With a cache, you can present data immediately on app startup - this is important on the iPhone OS because users are constantly opening and closing apps. Having your data immediately available is a big win for the user.
You can make the caching very simple, just have a single table with the URL as one column and the HTTP response as a second. Then you don't have to change any of your code to make the caching happen.
Alternatively, you will need to define a data model and manage that through CoreData or sqlite.