uber-archive / ohana-ios Goto Github PK

How do you access the email addresses field of a contact?

introduced d1f2a85.

What are you thoughts on adding

@Property (nonatomic) NSString *identifier;

to OHContact so we can easily persist a list of contact identifiers that can later be used to refetch the same contacts from CNContactStore? If not, how do you go about handling this case, if you do?

Current protocol:

@protocol OHContactsPostProcessorProtocol <NSObject>

/**
 *  Signal to be fired after the contacts post processor has finished its work (see signal definition)
 */
@property (nonatomic, readonly) OHContactsPostProcessorFinishedSignal *onContactsPostProcessorFinishedSignal;

/**
 *  The main method of any post processor, this method does the actual post processing on the contact data
 *
 *  @discussion The post processor may add, remove, or modify contacts passed into it.
 *
 *  @param preProcessedContacts The contacts to be run through the post processor
 *
 *  @return The contacts processed by the post processor
 */
- (NSOrderedSet<OHContact *> *_Nullable)processContacts:(NSOrderedSet<OHContact *> *)preProcessedContacts;

@end

The onContactsPostProcessorFinishedSignal here is never used in the Data Source. It also seems redundant to expect implementers to remember to fire this signal at the end of the synchronous call to processContacts (which already returns the same result).

After upgrading to Cocoapods 1.0.1, can no longer build when use_frameworks! is in the Podfile

How can I sort based on name and phone number only. Currently fuzzy search considers email and other fields also.

Hi guys!
Thank you for library, but I see couple of problems in it.
First of all, I want to draw your attention to problems that are connected with ownership qualifiers.
I will show you a few of them, but you will get the point.
For example, these properties in OHContact.h:

@property (nonatomic, nullable) NSString *fullName;
@property (nonatomic, nullable) NSOrderedSet<OHContactField *> *contactFields;

Default ownership qualifier for object types in ARC is strong
The problem here is that you can set NSMutableString or NSMutableOrderedSet instead and change them in another place; the values will change in this object too.
It will lead to some hard-to-debug problems.

Second problem is connected with copy method. There is an example from OHContact.m:

@interface OHContact ()

@property (nonatomic, readwrite) NSMutableSet<NSString *> *tags;
@property (nonatomic, readwrite) NSMutableDictionary<NSString *, id> *customProperties;

@end

Again, you defined both properties as strong.

- (id)copyWithZone:(NSZone *)zone
{
    OHContact *copy = [[OHContact alloc] init];
    ...
    copy.tags = [self.tags copy];
    copy.customProperties = [self.customProperties copy];
    return copy;
}

At this point, you copied both tags & customProperties to newly created object.
There will be no problem, if you don't change them, but it will be a problem, if you try to add some values to them, because copy of mutable object returns immutable copy and you will receive NSSet and NSDictionary accordingly. So, you will receive runtime error when try to add new objects.

I observed our travis setup flaking on #33

Let's track this here and prioritize fixing it if required.

The datasource.contacts returns the entire NSOrderedSet of contacts, but a few contacts are listed multiple times because of linked contacts. Is there a way to include post processors to remove these duplicates?

onContactsDataSourceReadySignal
2016-11-07 06:30:07.113 OhanaExample[71212:3367760] <NSThread: 0x7f83a6492460>{number = 2, name = (null)}

I think this was caused by the OHABAddressBookContactsDataProvider calling back on a background thread.

There's a generally larger task required here: Ohana's threading isn't very well defined.
We've generally assumed operation on Main. This is fine, but the contract with dataProviders and postProcessors should be better defined to dictate how they can offset work.

In all examples we are firing onContactsDataProviderErrorSignal on dataproviders, but there is no subscription to this event in the OHContactDataSource file , so currently it is very difficult to catch NSError from api calls in view controllers. So want to ask how to catch NSError events in viewcontroller using onContactsDataProviderErrorSignal , documentation lacks how to handle errors gracefully if we are loading contacts from remote datasource

the post processors are currently synchronous. they could have to do a substantial amount of work; we should make them async.

It's unclear what to do when dataProviderDidHitContactsAuthenticationChallenge is called on the provided system dataProviders' delegates.

Instead of relying on the consuming app to implement a way to request access, we should provide a callback in the to the authenticationChallenge method. When the consumer is ready to trigger the system authentication, they should simply call it.

The relevant part of the DataSource's current API looks like this:

/**
 *  Signal fired after the data source has finished loading all of its data providers
 */
@property (nonatomic, readonly) UBEmptySignal *onContactsDataSourceLoadedProvidersSignal;

/**
 *  Signal fired after the data source has finished running all of its post processors
 */
@property (nonatomic, readonly) UBEmptySignal *onContactsDataSourcePostProcessorsFinishedSignal;

/**
 *  Signal fired after the data source is ready to be used
 *
 *  @discussion When this signal is fired, the `contacts` property will have been set
 */
@property (nonatomic, readonly) UBEmptySignal *onContactsDataSourceReadySignal;

I propose removing the onContactsDataSourceLoadedProvidersSignal and onContactsDataSourcePostProcessorsFinishedSignal from the public API. They're unused externally in the example app and are really implementation details.

I also propose making the onContactsDataSourceReadySignal actually fire a list of of contacts.

Any questions or concerns?

For discussion:
The OHContact has mutable fields. Whilst customProperties and tags should perhaps stay mutable for the attachment of display metadata, the rest of the fields should probably be immutable when vended by the framework

We've landed a few breaking API changes. We'll need to major bump to 2.0.0 to publish.

If anyone else has thoughts for breaking changes, now's a particularly good time to speak up :)

Hey there,

Sorry if this is vague, more of a product manager than engineer, but truing to integrate Ohana with a project we're working on.

We use BuddyBuild as a CI/deployment tool, and it clones our project, does its own pod install, and compiles the app off-site, etc.

We aren't having any issues when we run the app locally using a simulator or when archiving for AdHoc, etc. But when BuddyBuild pulls our app and tries to compile, it's getting these errors:

    ▸ Compiling OHContactsDataProviderProtocol.m
    ▸ Compiling OHContactsDataSource.m
    ▸     ❌  /tmp/sandbox/workspace/Pods/Ohana/Ohana/Classes/Core/OHContactsDataSource.m:130:28: no visible @interface for 'NSOrderedSet<OHContact *>' declares the selector 'unionOrderedSet:'
            [_selectedContacts unionOrderedSet:contacts];
    ▸     ❌  /tmp/sandbox/workspace/Pods/Ohana/Ohana/Classes/Core/OHContactsDataSource.m:149:28: no visible @interface for 'NSOrderedSet<OHContact *>' declares the selector 'minusOrderedSet:'
    ▸  [_selectedContacts minusOrderedSet:contacts];
    ▸     ** BUILD FAILED **
    ▸ The following build commands failed:
    ▸ CompileC /tmp/sandbox/56ab9a3d6752ec01002bf2af/bbbuild/Build/Intermediates/Pods.build/Debug-iphoneos/Ohana.build/Objects-normal/armv7/OHContactsDataSource.o Ohana/Ohana/Classes/Core/OHContactsDataSource.m normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler

Tried 1.1.1 and 1.2.0, having issues with both. Any insight would be awesome. If there's anything else useful that I could get from my end, let me know.

This is not an issue but asking how to do the same. Assuming a phone with 5000 contacts(i.e. today this scenario is very common with gmail syncing all emails to your phone book too), it is not good to read them every time an application needs and instead can this be read and persisted in data store like SQLLite and then use listener to look for changes in address book and update the same in SQLLite.Is this possible using ohana?