I read some articles and info in developer.apple.com about Core Data. Now I want to create ManagedObjectModel for my app. So I need to help - because it's first my planning about database. So my app will have next options
User must login with his Login and Password. So if he forget password, there is chance to create new pass by entering correct answer on secret question.
App will store contacts. Every contact have name, surname, photo, phones, and coollection of map annotations.
User can create some groups (like Family, Friends...)
So this app I create for understanding basics of objective-c and maybe there are no logic in my app.
Please check my entities, maybe I allowed blunder.
First entity Contact
id - number of contact.
image - I will store array there. So if image <200 Kb I insert it in database, if more I will save the path to this image
map - the dictionary of map annotations
name
phones - array of phone numbers
surname
Second entity Group
contacts - array that contain id of contacts, that belong to this group
id - number of group
title - it is the name of group (like Family, Friends...)
Third entity Login
groups - array that contain id of groups, that belong to this group
login
password
secret answer - answer to the secret question
secret question
Relationships
So each Login can have some groups, but each group will belong only to one Login. So I create "to-many relationship" for group relationship. So each group contain some contacts and contacts can be in some different gruops - I create many-to-many relationship.
About property "optional". I understand that if it's not check - this attribute or relationship have to be. So I remove this property for
"id" in Contact
"id" in Group
"login", "password" in Login
in relationship "toGroups" in Contact
in relationship "toLogin" in Group
About "Delete Rule". I want if I delete some Login all groups and contacts belong to this login must be delete. I can choose "Cascade" for relationship "group" in Login but it will delete only groups but not contacts. I cann't do such for relationship "toContact" because if I delete some Group it will delete contacts, but other Groups still can have this contacts. So maybe I must create attribute "contact" in Login that will be array of contacts, and create relationship to Contacts and if I delete Login all groups and contacts that belong to it, will be delete.
PS Sorry I am stil newbie and my question maybe funny for you, but I need help
A few things I noticed -
You have no need to use 'id' properties. Most databases plan on these for primary/foreign key management, but core data will manage this all for you provided you have the relationships set up. Also by this logic, you don't need properties to manually create that relationship (i.e. 'Contacts' in group and 'groups' in login
Are you sure you wants to be storing dictionaries and/or arrays in an entity? These sound like another standalone entity such as one for map annotations. Then you would build a one-to-many relationship from the original object to the new one.
Images stored as binary data are not the most efficient way to go about this. Its better to use the filesystem the app sandbox provides. Just saw a similar question the other day Storing images locally on an iOS device
Related
I'm developing an app using the low code platform SLINGR. I need to set permissions by the company an user belongs to.
What would be the best approach to implement this?
Any help would be greatly appreciated.
The best way to achieve this is by using permissions with a filter of type By user field. For example, you can create an entity called people with the following structure:
- user
- company
Then, in Application > Settings in the app builder, you have to configure this entity as the one used for extended fields (https://slingr-stack.github.io/platform/app_development_app_settings.html#user-extended-fields). Once you do that, you will be able to filter by the company of the current user. For example, let's suppose you have an entity called tasks with the following structure:
- number
- title
- company
- description
Then, in the permissions for this entity, you will add a filter by user field where the field tasks.company is equals to people.company. This way, users will only see tasks that belong to the company they also belong to.
I am working on system that will manage orders. Orders can be created via admin or via customer. Employee can take orders and change it's status.
My system should have three global types of users:
Admin - this type of users mostly uses WEB interface. Admins have different access levels, so some of them can only create orders, and others - edit core info about pricing and so on.
Customer - this type of users uses customer's mobile app. Main action is to add and cancel orders.
Employee - this type of users uses employee's mobile app. Employees can see open orders, assign themselves to orders and change order statuses.
Also, Customer and Employee can be authorised with phone number, that can be changed at some time (independently of each other). Admins can be authorised with uname + pword.
Current solution has one table for Admins, one for Customers and one for Employees.
So first part of question is how to structure database properly?
The second part is about authorising in REST api. In current solution I have three endpoints, that are authireses usertype independently.
admins/auth
customers/auth
employees/auth
And my thoughts is to keep three tables as is, because each usertype is slightly different concept and really independent. And keep authorisation as is, but add something like roles and privileges to auth token to restrict access for some resources.
I'm creating a social media app. I'm able to allow the current user to search for a PFUser and add the user to a friendship relation. I'm struggling on accessing the friendship relation and getting all the friends to create a table view right now. Could someone help me with this?
A Relation type in Parse represents just like what it literal meaning is. It's just a relation that contains no data. If you want to access the data inside the relation. You will need to perform query on it like so:
let query = relation.query() // I assume relation is an instance of PFRelation you want
Actually, Parse tutorial provides us a very comprehensive guide and you should check that first: https://parse.com/docs/ios/guide#relations
NOTE: This answer provides alternatives to using Relations to make a Friend System
I have created a friend system in two ways using Parse and both a function of your specific needs.
The first time I implemented a friend system. I had a table of Users and a table of Relationships. The Relationships table stored the usernames (or ObjectIds) of the two users in a relationship and the state of that relationship (friends, request sent, etc). The problem with this is that the queries can be kinda complicated, and if you have a lot of users, this may end up being too slow.
The second option is storing friend information in the User table itself. For each user, you add the columns with they type Array: Friends, RequestSent, and RequestReceived. Anytime a user sends a request they update their own user row and send a message to CloudCode to update the other affected user. Take a look at this example:
User A sends a request to User B:
User A adds user B's name to RequestSent
User A sends a message to cloud code that he/she wants to add user B
CloudCode adds User A's name to User B's RequestReceived
User B wants to accept User A's request
User B adds user A's name to Friends
User B removes user A's name from RequestSent
User B sends a message to CloudCode that he/she wants to accept User A's friend Request
CloudCode adds user A's name to Friends
CloudCode removes user A's name from RequestReceived
With this option, you never perform any server side queries. You only ever perform get operations. The downside to this option is if the logged-in user has thousands of friends/requests, it will take a while to download that information.
Note: The reason you have to use CloudCode is that a User can only change information about him/herself. The other option is to have CloudCode manage all the adding/removing so better checks can be made.
I found with this method that you can sometimes have one user who is listed a a friend in another users row but not their own. Controlling everything from CloudCode could eliminate this kind of error.
What's the best way to programmatically convert an NSManagedObject-subclass (User) instance into an instance of its subclass (AccountUser)?
Setup
AccountUser inherits from User : NSManagedObject
When I sign up or log into the app for the first time, I become an AccountUser. Then, I download all of my friends and store them as User objects.
Both User & AccountUser have attributes firstName, lastName, etc. AccountUser has some extra things, like accessToken.
Problem
My friend John logs in on my device. Since he's my friend, he's already stored as a User. But now, I want to convert him into an AccountUser. What's the best way to do this programmatically? I have lots of attributes and relationships to preserve, so creating a new AccountUser object from a User object and then deleting the original User object is a lot to do. If I just create an AccountUser without deleting the User, things get messy. E.g. when I fetch User by ID, I get two objects back: one is the AccountUser, the other is the User.
One way to do it is to simply create a new AccountUser object and copy the relevant fields from the existing User object into it. Then deal with the old User object appropriately -- delete it, save it, whatever makes sense. It'd make sense to give AccountUser an initializer that takes an instance of User, like -initWithUser:.
Another (probably better) option would involve using a single class (User) for all users. If there's additional information to be stored for some users (currently AccountUsers), create a new Account class and associate an instance of Account with the users that require it. So the User objects that represent you and your friend John would each have associated Account objects, and all the other users wouldn't. When one of your other friends logs into your phone, you can create a new Account object for that person and associate it with their existing User object.
Maybe you can do it this way
Add the User entity a boolean property called "is_account_user".
Set a relationship between User and account user.
if a user has an account user, create the AcountUser entity and relate it to the User.
If the user has no account info then the "is_account_user" will be NO;
When you fetch for a user you can check if is_account_user is YES, and if so you can get his AcountUser with the relationship.
Hope it helps
I am trying to run a workflow on the creation of a 1:n relationship.
I have a Contact entity, and PortalRole entity. When I associate the PortalRole with the contact I would like to trigger a workflow which sends out welcome emails to the users.
The PortalRoles are assigned to the contacts from a ribbon button which launches a HTML web resource and uses JSON / JQuery and the REST services to create the associations.
How can I call the workflow? I need to grab the Contacts email address and send them 1 of 2 emails depending on how many associations they have (new portal user or portal user gaining extra roles)
You should build your workflow for the PortalRole entity and trigger it from Create. You'll still be able to access Contact fields in the workflow.
The trick is in your last requirement - send "Email A" for the first role association and then "Email B" for the each additional association.
You could add a Yes/No field to Contact called "First Role Assigned." Your workflow would look something like this:
If Contact:FirstRoleAssigned = Yes
Send "Email B"
Else
Send "Email A"
Set Contact:FirstRoleAssigned = Yes
This blog post provides a very good explanation of dealing with relationships.
(So Many) Many-to-Many Options: Which to Use?
So…of these three approaches, which is best? As always, it depends on
what you need to do, but here are some rules of thumb you can use as
guidance:
Native N:N
Probably the easiest to configure but the most limiting. Use when you
only need to know that two records are connected to each other but you
don’t need additional information about the connection itself.
Examples:
Custom entity Industry with an N:N to Account Add a custom N:N
relationship between the Competitor and Territory entities to track
which competitors are active in which territories Custom entity Color
with an N:N to Contact (you don’t track your contacts’ favorite
colors???)
Manual N:N
A little more work to configure, but generally worth the effort. Use
when in addition to knowing two records are connected, you also need
information about the connection, such as its status, when it was
created and so forth.
Examples:
Associations and Members Events and Registrations (1:N from Contact
to Registration, 1:N from Event to Registration) Subscribers and
Subscriptions (1:N from Contact to custom entity “Subscription”, 1:N
from custom entity “Subscription Product” to Subscription)
Connections and Connection Roles
As I mentioned above, these are actually a specific implementation of
the Manual approach. And if you delve into this a little, you’ll find
that the Connection entity is a bona-fide customizable entity. You can
even customize it, adding custom fields to the connection form and so
forth. But…be careful about overdoing it: there’s only one Connection
entity, and customizations made for one Connection Role generally will
not be applicable to another one.
One specific advantage of these is that a single connection role can
connect records of different types (e.g., contacts can refer other
contacts, accounts and opportunities)
This is a judgment call, but I’d say to use these when you need to
track some information about the actual connections (such as when
they’re created and how many there are…), but not that much. Examples:
Referrals (Contact to Contact, Contact to Account, Contact to
Opportunity) Former Employee (Contact to Account, Lead to Account)
Board of Directors (Contact to custom entity “Board”, Lead to Board)
http://community.dynamics.com/product/crm/crmtechnical/b/richardknudson/archive/2011/05/08/many-to-many-relationships-in-dynamics-crm-2011.aspx