I'm using the following code to set a property that holds information about twitter rate limits in a core data record:
- (Limits *)limits
{
if (!_limits) {
[[[TwitterManager sharedManager] API] getRateLimitsForResources:nil successBlock:^(NSDictionary *rateLimits) {
_limits = [Limits createWithInfo:rateLimits user:_user];
} errorBlock:^(NSError *error) {
NSLog(#"Error %s: %#", __PRETTY_FUNCTION__, error);
}];
}
return _limits;
}
When it gets to the last line, it doesn't reflect the new value because the block hasn't finished yet. How can I best go about this?
Mixing synchronous and asynchronous code like this is quite hard. The best way to go ahead with this would be to make your limits method asynchronous and have it take an completion block:
- (void)getLimits: (void (^)( Limits *limits ))block
{
if (_limits) {
block( _limits );
} else {
[[[TwitterManager sharedManager] API] getRateLimitsForResources:nil successBlock:^(NSDictionary *rateLimits) {
_limits = [Limits createWithInfo:rateLimits user:_user];
block( _limits );
} errorBlock:^(NSError *error) {
NSLog(#"Error %s: %#", __PRETTY_FUNCTION__, error);
block( nil );
}];
}
}
If you want to call your limits method on the main thread you really should go with this option. Blocking the main thread for network access will not lead to great user experience and might get your app killed by the watchdog if the request takes too long.
If this is not an option you basically have to wait for the request to finish. The easiest way to do this would be to use a synchronous method if your TwitterManager supports that. If not there are different ways to handle this, depending on how the TwitterManager class is implemented.
If everything runs on a different thread you could just use a dispatch group to block your current thread until the response arrived (dispatch_group_wait). This will lead to a deadlock if your twitter class tries to dispatch any work on the same queue/thread you send your limits message on.
Related
I'm using PromiseKit to simply my API requests.
In this scenario, I'm fetching a list of objects IDs from the server. I need to then fetch details for each ID, and return an array of details. Fairly common scenario.
Effectively, I need to add promises to the promise chain from within a FOR loop which is contained in the FIRST promise.
I've created code that begins to drift right, but the chain completes before the second chain of promises (fill shallow model requests) can be executed.
[PMKPromise promiseWithResolver:^(PMKResolver resolve) {
// Fetch an array of object IDs (shallow objects)
[APIManager fetchObjectListWithCompletion:^(NSArray *resultObjects, NSError *error) {
resolve(error ?: resultObjects[0]);
}];
}].then(^(NSArray *objects){
// Fill each shallow object (query details)
PMKPromise *fetches = [PMKPromise promiseWithValue:nil];
for(id model in objects) {
fetches.then(^{
[APIManager fillShallowObject:model withCompletion:^(NSArray *resultObjects, NSError *error) {
// resolve?
}];
});
}
// Return promise that contains all fill requests
return fetches;
})].then(^{
// This should be executed after all fill requests complete
// Instead it's executed after the initial ID array request
});
Is there a better way to do what I'm trying to accomplish? Perhaps a way to append a promise (.then) with a resolver?
I think you want when:
[AnyPromise promiseWithAdapterBlock:^(id adapter) {
[APIManager fetchObjectListWithCompletion:adapter];
}].then(^(id objects){
NSMutableArray *promises = [NSMutableArray new];
for (id model in objects) {
id promise = [AnyPromise promiseWithAdapterBlock:^(id adapter){
[APIManager fillShallowObject:model withCompletion:adapter];
}];
[promises addObject:promise];
}
return PMKWhen(promises);
}).then(^(NSArray *results){
// when waits on all promises
});
Code is PromiseKit 3.
I have a number of network requests and one or more of them will return valid data and is possible that some will return an error. How can I combine this request to stop once the first valid returned the data but not to stop in case of error.
I have try like this:
[[RACSignal merge:#[sigOne, sigTwo, sigThree]]
subscribeNext:^(RACTuple *myData){
NSLog(#"Data received");
} error:^(NSError *error) {
NSLog(#"E %#", error);
}
completed:^{
NSLog(#"They're all done!");
}
];
My problems:
if one of the signals returns first with error then no next will be send. Not desired because one of the other signals will return valid data.
if all three return valid data then the subscribeNext will be called three times but I would like to stop as soon I got some valid data (to reduce network traffic)
Try this:
[[[[RACSignal merge:#[[sigOne catchTo:[RACSignal empty]],
[sigTwo catchTo:[RACSignal empty]],
[sigThree catchTo:[RACSignal empty]]]]
repeat] take:1]
subscribeNext:^(RACTuple *myData){
NSLog(#"Data received");
} error:^(NSError *error) {
NSLog(#"E %#", error);
}
completed:^{
NSLog(#"They're all done!");
}
];
By using catchTo:, the signals are being replaced with an empty signal when they error, which just causes the signal to send complete, and doesn't end the subscription for every other signal.
By adding repeat, we're getting the signal to run again if no next events occurred (because all of the signals errored).
By adding take:1, the signal will complete once a single next event is received.
The client I'm building is using Reactive Cocoa with Octokit and so far it has been going very well. However now I'm at a point where I want to fetch a collection of repositories and am having trouble wrapping my head around doing this the "RAC way"
// fire this when an authenticated client is set
[[RACAbleWithStart([GHDataStore sharedStore], client)
filter:^BOOL (OCTClient *client) {
return client != nil && client.authenticated;
}]
subscribeNext:^(OCTClient *client) {
[[[client fetchUserRepositories] deliverOn:RACScheduler.mainThreadScheduler]
subscribeNext:^(OCTRepository *fetchedRepo) {
NSLog(#" Received new repo: %#",fetchedRepo.name);
}
error:^(NSError *error) {
NSLog(#"Error fetching repos: %#",error.localizedDescription);
}];
} completed:^{
NSLog(#"Completed fetching repos");
}];
I originally assumed that -subscribeNext: would pass an NSArray, but now understand that it sends the message every "next" object returned, which in this case is an OCTRepository.
Now I could do something like this:
NSMutableArray *repos = [NSMutableArray array];
// most of that code above
subscribeNext:^(OCTRepository *fetchedRepo) {
[repos addObject:fetchedRepo];
}
// the rest of the code above
Sure, this works, but it doesn't seem to follow the functional principles that RAC enables. I'm really trying to stick to conventions here. Any light on capabilities of RAC/Octokit are greatly appreciated!
It largely depends on what you want to do with the repositories afterward. It seems like you want to do something once you have all the repositories, so I'll set up an example that does that.
// Watch for the client to change
RAC(self.repositories) = [[[[[RACAbleWithStart([GHDataStore sharedStore], client)
// Ignore clients that aren't authenticated
filter:^ BOOL (OCTClient *client) {
return client != nil && client.authenticated;
}]
// For each client, execute the block. Returns a signal that sends a signal
// to fetch the user repositories whenever a new client comes in. A signal of
// of signals is often used to do some work in response to some other work.
// Often times, you'd want to use `-flattenMap:`, but we're using `-map:` with
// `-switchToLatest` so the resultant signal will only send repositories for
// the most recent client.
map:^(OCTClient *client) {
// -collect will send a single value--an NSArray with all of the values
// that were send on the original signal.
return [[client fetchUserRepositories] collect];
}]
// Switch to the latest signal that was returned from the map block.
switchToLatest]
// Execute a block when an error occurs, but don't alter the values sent on
// the original signal.
doError:^(NSError *error) {
NSLog(#"Error fetching repos: %#",error.localizedDescription);
}]
deliverOn:RACScheduler.mainThreadScheduler];
Now self.repositories will change (and fire a KVO notification) whenever the repositories are updated from the client.
A couple things to note about this:
It's best to avoid subscribeNext: whenever possible. Using it steps outside of the functional paradigm (as do doNext: and doError:, but they're also helpful tools at times). In general, you want to think about how you can transform the signal into something that does what you want.
If you want to chain one or more pieces of work together, you often want to use flattenMap:. More generally, you want to start thinking about signals of signals--signals that send other signals that represent the other work.
You often want to wait as long as possible to move work back to the main thread.
When thinking through a problem, it's sometimes valuable to start by writing out each individual signal to think about a) what you have, b) what you want, and c) how to get from one to the other.
EDIT: Updated to address #JustinSpahrSummers' comment below.
There is a -collect operator that should do exactly what you're looking for.
// Collect all receiver's `next`s into a NSArray. nil values will be converted
// to NSNull.
//
// This corresponds to the `ToArray` method in Rx.
//
// Returns a signal which sends a single NSArray when the receiver completes
// successfully.
- (RACSignal *)collect;
I need to dispatch a block on the main queue, synchronously. I don’t know if I’m currently running on the main thread or no. The naive solution looks like this:
dispatch_sync(dispatch_get_main_queue(), block);
But if I’m currently inside of a block running on the main queue, this call creates a deadlock. (The synchronous dispatch waits for the block to finish, but the block does not even start running, since we are waiting for the current one to finish.)
The obvious next step is to check for the current queue:
if (dispatch_get_current_queue() == dispatch_get_main_queue()) {
block();
} else {
dispatch_sync(dispatch_get_main_queue(), block);
}
This works, but it’s ugly. Before I at least hide it behind some custom function, isn’t there a better solution for this problem? I stress that I can’t afford to dispatch the block asynchronously – the app is in a situation where the asynchronously dispatched block would get executed “too late”.
I need to use something like this fairly regularly within my Mac and iOS applications, so I use the following helper function (originally described in this answer):
void runOnMainQueueWithoutDeadlocking(void (^block)(void))
{
if ([NSThread isMainThread])
{
block();
}
else
{
dispatch_sync(dispatch_get_main_queue(), block);
}
}
which you call via
runOnMainQueueWithoutDeadlocking(^{
//Do stuff
});
This is pretty much the process you describe above, and I've talked to several other developers who have independently crafted something like this for themselves.
I used [NSThread isMainThread] instead of checking dispatch_get_current_queue(), because the caveats section for that function once warned against using this for identity testing and the call was deprecated in iOS 6.
For syncing on the main queue or on the main thread (that is not the same) I use:
import Foundation
private let mainQueueKey = UnsafeMutablePointer<Void>.alloc(1)
private let mainQueueValue = UnsafeMutablePointer<Void>.alloc(1)
public func dispatch_sync_on_main_queue(block: () -> Void)
{
struct dispatchonce { static var token : dispatch_once_t = 0 }
dispatch_once(&dispatchonce.token,
{
dispatch_queue_set_specific(dispatch_get_main_queue(), mainQueueKey, mainQueueValue, nil)
})
if dispatch_get_specific(mainQueueKey) == mainQueueValue
{
block()
}
else
{
dispatch_sync(dispatch_get_main_queue(),block)
}
}
extension NSThread
{
public class func runBlockOnMainThread(block: () -> Void )
{
if NSThread.isMainThread()
{
block()
}
else
{
dispatch_sync(dispatch_get_main_queue(),block)
}
}
public class func runBlockOnMainQueue(block: () -> Void)
{
dispatch_sync_on_main_queue(block)
}
}
I recently began experiencing a deadlock during UI updates. That lead me this Stack Overflow question, which lead to me implementing a runOnMainQueueWithoutDeadlocking-type helper function based on the accepted answer.
The real issue, though, is that when updating the UI from a block I had mistakenly used dispatch_sync rather than dispatch_async to get the Main queue for UI updates. Easy to do with code completion, and perhaps hard to notice after the fact.
So, for others reading this question: if synchronous execution is not required, simply using dispatch_**a**sync will avoid the deadlock you may be intermittently hitting.
everybody.
I want to understand, how i shoud procceed situations when an asynchronous method has "didFinish:#selector(SEL)" parameter.
My code example is:
//
// Authentication check
- ( void )authenticationSuccess: ( GDataServiceTicket* ) ticket
authenticatedWithError: ( NSError* ) error {
if ( error == nil )
{
NSLog( #"authentication success" );
}
else
{
NSLog( #"authentication error" );
}
}
//
- ( void ) fetchFeedOfSpreadsheets {
//create and authenticate to a google spreadsheet service
if ( !(mService) )
{
GDataServiceGoogleSpreadsheet *service = [self spreadsheetService];
[mService autorelease];
mService = [service retain];
}
// check autentication success ( invoke "authenticationSuccess" method for debug success & error )
[mService authenticateWithDelegate: self
didAuthenticateSelector:#selector(authenticationSuccess:
authenticatedWithError:) ];
// HERE I WANT TO MAKE A PAUSE AND WHAIT THE RESULT, EITHER I AUTHENTICATED OR NOT
// AND MAKE AN "IF" STATEMENT TO CONTINTUE WORKING ON SERVER, OR RETURN ERROR
//fetch retrieves the feed of spreadsheets entries
NSURL *feedURL = [ NSURL URLWithString: kGDataGoogleSpreadsheetsPrivateFullFeed ];
GDataServiceTicket *ticket;
ticket = [mService fetchFeedWithURL: feedURL
delegate: self
didFinishSelector: #selector(spreadsheetsTicket:finishedWithFeed:
error: ) ];
// HERE I WANT TO WAIT SECOND TIME. I WANT "spreadsheetsTicket:
// finishedWithFeed:error:" TO PROCCEED ERROR AND PUT A FEED IN SOME NSARRAY OBJECT
// AND AFTER THAT I WANT TO WORK WITH THAT NSARRAY RIGHT HERE
}
I's clear, that i can push the code i want into the end of "authenticationSuccess" method section, but it's also clear, that it's a wrong a way to solve the proble. There a number of situations like this, where i call an asynchronous method with a selector parameter, and i want to find a solution providing me a flexible code writing.
Thanks in advance.
It's a standard practice in Objective-C to put the code to be executed after the authentication in the authenticationSucess: method. You might not like it, but that is life.
Many people had the same complaint as you, so
on iOS 4 and later, there's something called blocks which allow you to write the code to be executed after the authentication in the method which initiates the authentication, as in
[mService authenticateAndExecute:^{
code to be executed when successfully authenticated ;
} whenError:^{
code to be executed when authentication failed;
} ];
But in this case you need to modify the API, which is possible by using categories. See this blog post by Mike Ash. He has many other posts on blocks on the same blog, which are also very instructive.
If you're going to use a library that works asynchronously (and therefore doesn't block your UI), you should have a good reason for trying to force it to work synchronously.
You should be checking for an authentication error at the end of your authenticationSuccess:authenticatedWithError: method, and calling the next request from there if there's a success. Similarly, in your spreadsheetsTicket:finishedWithFeed:error: check for an error, and continuing processing if there isn't one. It might be a better design to do that continued work in a separate method, but that's up to you.
Is there a specific reason you want to use the GData API in a synchronous fashion?