New to Parse backend and coding all together...
Developing my first iOS app and I'm contemplating how I should store the data in Parse.
So I want to get advice from you lovely, experienced developers. What's the best way to structure my Parse class(es) if I want to store comments, follow requests, favorites, etc. That would make it simple when querying in an Alert tab within my app.
You probably don't want to store all the alerts on parse but rather send one alert via a notification and it's payload and store it locally.
Related
When the app has access to the devices contacts, and you need those contacts to populate a PickerView, does it pull the contacts to a Firebase DB and fetch those contacts to populate the PickerView? Or does it do it within the phone(maybe Core Data)?
Any advice or guidance would be greatly appreciated.
If does and I can use Core Data, can I use it hand in hand with Firebase, or does it even store it somewhere? I'd like my users to be able to select which contacts they want to add to the app.
Thank you in advance.
I think it would be best to pull from the device's Contacts, using the Contacts Framework - in Xcode this is the Contacts.framework package. The Apple site offers some sample code that you might be able to take advantage of in your application. For that you'd need permission from the user by enabling a NSContactsUsageDescription in your info.plist. That describes to the user why you'd need access to their contacts.
As far as storing the data in a Database, I'm not sure that would be a wise decision nor one that makes sense. Consider the reasoning behind that, does this information need to be on some remote database? if your answer is no, then chances are that you don't need to do that extra work. You might however register new users that use your application with something like Google's Firebase if you want to manage any messages between users (for a chat app for example).
Hopefully that answers your question and helps you out in some way.
I want to store only 20 Notifications which include
"Title,Detail and Received Time" fields inside Notifications Table.But,I only found solution for working CoreData with CRUD some example.But,I am still seeking for working with limitation when user fetch new results from api inside device database.That is where I am stuck.I don't know how to do it using CoreData because I was beginner at that.
Requirement :
1.Application can only store 20 Records maximum.So,when it reach max length,it will do First-In-Last-Out to Notifications table base on Notifications Received Time.(First Problem)
2.Every time the user do pull to refresh,my app fetch new notification from Web-Backend and replace or overwrite on user device database when it successfully download new notifications like "Push Notification Service App" on App Store.(Second Problem)
I really need a hand to pick up with core data flow which I am stucking at things I am not familiar with.
Any help or guide please?(Posting Sample with .json is appreciated)
use NSUserDefaults for that if your data size is small
Consider using a service, like RestKit or similar, to support your web service interaction. Each record should have a unique identifier supplied by the server so you can find an existing copy and update it instead of needing to delete everything and recreated it.
To trim your data use a fetch request with a fetchOffset and a sortDescriptors by date. This allows you to skip the newest 20 items and gives you a list of everything that needs to be deleted. If you're using RestKit you can supply this fetch request in a fetch request block and the deletion will be done for you.
we are about to finish our first app with parse.com. This first app is for the enduser. PushNotifications and everything are working fine.
Now we want to create an app for our admins to manage everything. We want it to be a separate app. Therefore I was wondering: will this be possible? Two apps connecting to one data collection on parse.
Especially regarding the PushNotifications. Admins should also receive a push notification on the new admin app (e.g. new member joins and needs to be activated).
Has anyone ever done something like this?
Or do we need to build the admin part into the main app?
The thing is we will need a third app, which is for business owners to manage their listing on our main app. So the same problem/question will apply then.
Looking forward to your feedback.
Txs!
Yes same Parse app ID can be used by different platforms/apps, that is basic concept of Parse. You can even use it in web, iOS, Android, etc with same parse app. This should not be a problem.
You might need to modify you parse data structure tough to suit your admin app requirement.
Check https://parse.com/docs/ios/guide#roles
I am creating iOS app where user authenticates through facebook and allows my app to store some data like (name,email,gender,location) . I want to use this data later in my app for specific purpose.
What are the best practices of storing/retrieving this kind of data?
I have read about CoreData and NSCoding. Are those the best
alternatives if there will be huge data in future?
Should i retrieve this data from facebook everytime user accesses
the app instead of storing in my app?
I think CoreData is the best way to go.
developer.apple.com/CoreData
I have a parse.com backend and a swift ios8 app.
What is the best way for the apps that use the backend to be notified of changes to a certain table so that a collection view can reload its data?
Data is added to the db from one of the apps not via the website.
Would I need to setup push notifications? Or would I do regular checks from the app To see if data has changed? Or is there another way?
Use push notifications is the better way to achieve your goal.
Here's the steps:
1.Data added from another app to the db in your backend
2.Your backend shoud post a push notification to all your app
3.when your app received the notification, it must pull the newest data from backend and refresh the view in app
Regular checking from app will has a bad influence on you app's performance, so do not use this way if possible.