How do I read iPhone Exchange Account Name from Xcode? - ios

I want to be able to read the names of the exchange accounts.
ABSource objects only have 2 properties from what i could tell.One of them is an integer specifying the type of source(ex: 0 for local addressbook, 1 for exchange addressbook) and the other is a string specifying the name of the source.Unfortunetely the name of the source will not be the name of your exchange account,it will always be called "Contacts".The problem is that if you would save all the sources in an array and when writing a contact to a specific source you would acces it from there it will work...it will add it to the right source,my problem is i want to be able to select which account to add to from a table view and so far have found no way of differentiating the accounts.

Yes, for some Exchange accounts (and other types of accounts) it seems like there is no way to get any other name except "Contacts".
What you should do is:
Create a separate object that holds the ID and name of the source and has a boolean which tracks whether this account has been selected. Hold these objects within the array that is responsible for populating the UITableView. When the user selects a source, modify the boolean and at the end, when you want to know what the user selected, go through the array and select only the IDs from the objects that have been selected.

Related

ASP.NET Model Id in ViewModel - is it safe?

Scenario:
(with an ASP.NET web app - Core or MVC)
I have a database with Users and Items for each user.
That means the UserId is a foreign key in the Items table.
From the browser I login as a User. I get my Items as a list of ItemViewModels, which are mapped (AutoMapper) to ItemViewModels via a simple api GET request.
I want to update one of the items (which should belong to me - the logged in user) via a simple API call. So I send the modified item back to the server via a PUT request as an ItemViewModel.
First approach:
The simplest approach would be to include the Item's database ID, ItemId, in the ItemViewModel - so when I receive the item to be updated as an ItemViewModel, I can map it back to the existing item in the database.
This however sounds pretty unsafe to me, as anyone could modify the PUT request with any ItemId and affect items which don't belong to the user who executed the request. Is there anything I'm missing about this approach?
Second approach:
Don't pass the database PK ItemId in the ItemViewModel.
Instead use an additional form of identification: let's say that user X has 10 items. And they are numbered from 1 to 10 using a property named UserItemId(which also exists in the database).
I can then pass this UserItemId in the ItemViewModel and when I get it back I can map it to an existing Item in the database (if all was ok with the request) or discard it and reject the request if the UserItemId didn't match anything from the logged in user's items.
Is anyone using this approach?
Pros:
The user only has access to it's own items and can't affect anyone else's since it doesn't know the actual Item ID (primary key), and any modifications are restricted to it's items.
Cons:
A great deal of extra management must be implemented on the server side for this approach to work.
Any other approaches ?
Please consider that the case mentioned above applies to all entities in the database which a client side implementation can CRUD, so it's not just the simple case described above.
The proposed solution should work for the entire app data.
I know this question has been asked here and here but the first one doesn't have a satisfying answer and I don't think the second one really applies to my situation, since it just deals with the UserId.
Thanks.
EDIT
Please consider the Item above as an aggregate root which contains multiple complex subItems each with a table in the db. And the question applies for them as much as for the main Item. That means that each subItem is passed as a ViewModel to the client.
I should mention that regarding further securing the update request:
For the first approach I can easily check if the user is allowed to change the item. But I should do this for all subItems too.
For the second approach I can check if the user can update the Item as follows: I get the userItemId of the incoming ViewModel -> I get all the logged in user's items from the database and try to find a match with the same userItemId, if I get a hit then I proceed with the update.
I think your application is not secure, if you only hide the Id.
You must check, before changing the database entity, if the user is allowed to change the entity.
In your case you should check, if your Id from the authenticated user is the UserId in your item.
If your ViewModel ist similar or identical for your API you could use a FilterAttribute in your controller.

iOS: Modeling Friends List with Syncano DB

I'm trying to get a handle on how to use custom Swift classes to model my Syncano backend. I have classes MPUser and MPUserProfile exactly as described in this guide. However, instead of adding an avatar field, I'd like to add a friends list. Should this property be:
An array of MPUsers
An array of MPUserProfiles
An array of integers corresponding to the other users' IDs
Something else?
Edit: their page on classes makes it sounds like I would want an array of type Reference (referring to users' IDs) but their arrays can only have string/int/boolean/float. I'm now wondering if an array of (non-Reference) integers will work fine.
Thank you for your help.
Currently Syncano doesn't support holding arrays of references. It's something we are working on (adding many-to-many relationships), but in the meantime you should could safely just use array type and store ID of referenced objects in there.
When you store array of IDs, you can use either ID of a user, or ID of a user profile.
The connection between them is as follows:
User is a physical user that logs into your app.
His profile is an object that belongs to him.
User A cannot be accessed by user B, but profile of user A can be accessed by user B.
You can get a profile of user A either by using profile ID (object id from user_profile class), or by using user A id (owner field in object inside user_profile class).
Depending on which route you take, you can then ask Syncano for list of all friends doing either:
give me all user profiles, where ID is in [array of user profile IDs]
or, give me all user profile, where owner is in [array of user IDs]
An array of MPUser's definitely. I haven't used Syncano so I may be utterly wrong on this, but having using Couch, Firebase and played with Realm...
The whole idea of key/value/object/document stores like these is that details of the storage are abstracted away in the back end. So you put an MPUser in an array, and when you access that array sometime later you get it back. Totally magic. That the DB itself might physically store that as an Int64 or inline the entire string is of no interest to you - data in, data out.
I suspect you have worked in the SQL world, which is why you put that last option there? Generally that's not how you work in object stores - thank gawd.

Is it possible to limit fields in address book that can be edited?

In writing an app for iPhone/iPad, I like to restrict the fields within the Address Book that can be edited.
As an example, each contact has a name, phone number(s), email(s), and an address. I'd like to allow editing of just the phone number(s) and email(s) fields and to simply display the name and address without the option of changing them since the name and address fields have been created elsewhere in the app.
Is it possible to be this selective when invoking the Address Book feature that allows editing of a contact record? It doesn't seem so since the choices for editing seem to be just YES or NO.
You have a few options:
Implement your own editor instead of using ABPersonViewController. This is the best way to go since you can display whatever you want and restrict editing to whichever properties you want. But it will take the most effort to complete.
Create a separate instance of ABRecordRef with only the properties that may be edited, and copy the edited values back to the original ABRecordRef after editing. This is a poor option because only those properties which are editable are going to be visible.
Create an exact copy of the ABPersonRef and assign that to the ABPersonViewController. When editing is done, only copy the desired properties back to the original ABPersonRef. This is better than the second option because all properties are displayed, but it will confuse the user if they are allowed to perform an edit that is not saved.

Name on Check in QuickBooks SDK

I have a customer requirement to export the checks written in QuickBooks into a specific format because their bank allows fraud prevention by uploading a file and they verify the name on the check against what you give them before clearing it.
I looked at the QuickBooks SDK (we use the XML to communicate in general) and It references a field on the check called PayeeEntityRef with a FullName property, but typically in QuickBooks that data structure would indicate what the entity is called, not what appears on the check (Vendors have a NameOnCheck property, for example, which can be something other than their name).
Without coding up multiple test cases to demonstrate QuickBooks behavior here, does anyone have experience with getting the name as it was printed on the check? What is the best way to do it?
It's somewhat possible to get what you are wanting, but there are going to be some hiccups that you'll need to let you client know about. The main problem being that there's no way to retrieve the actual name printed on the check.
You would first need to query for the Checks/Bill Payment - Checks for the bank account. Then, using the PayeeEntityRef (I would use the ListID component) figure out which "List" the entity is on; Customer, Vendor, Employee, or Other. I don't know of any way to tell which list the PayeeEntityRef is from other than doing a query for each of the lists.
If the PayeeEntityRef is a Vendor or Employee, then you can retrieve the NameOnCheck value. The only thing you would need to keep in mind is that if the NameOnCheck has been modified AFTER the check was printed, the names will not match.
If the PayeeEntityRef is a Customer or Other name, then you have to do a little bit more. The value that QuickBooks uses for the printed name is based on what fields are filled out for the customer record. It first will use the CompanyName field if it is not null. Next, it will try to use the First/Middle/LastName fields, if they are not null. Finally, it will use the Name field as a last resort. Keep in mind that this is not the FullName field, just the Name field.
I haven't tested this with an "Other" name, as I have my clients try not to use that list, but I would imagine it's similar to how Customers work.

Create a New big Object Wizard: ASp.net MVC

Here's my question:
I need to write a wizard, for customers to "create a new" very big objetc, with some other asociated with it: for example, Some images stored in another table (with relationships), some Lat's and Lang's for google earth, etc.
Each of them are stored in diferent tables in the Database, and that's why, i have to first insert to get the first object's Database generated ID to make the relationships with the another Objects. That's the reason I think puttin' Everything on just one View and hide selective DIVs with Jquery is not one of my option.
Session isn't an option because of the bigger object.
And because of the type of website, the wizard MUST be as follows:
Basic details of objetct 1
Images of object 1 (I will need here the ID of the first object)
Geolocations (with google maps, as before)
More details of object 1.
Preview
Publish
The point is, in step 4, user fill some fields that are required by the DB, and I cannot make them nullable as is it part of the customers reqs.
If somebody can a least give Ideas, will be nice...
Thanks in advance
You state that storing your object in Session is not desirable because of the size of the object. An alternative is to serialize that object and store it in the database. As the user progresses through the wizard, that object gets retrieved, updated and stored back in as a blob. Once they publish it, you can insert the appropriate records and remove the serialized object from whatever table you're storing them in.

Resources