In an iOS app, I'm writing a class that will be messaged, go do a background request (via performSelectorInBackground:withObject:), and then return the result through a delegate method (that will then be displayed on a map). Everything seems to work right when one request is happening at a time, but I'm trying to figure out how to handle multiple overlapping requests. For example, if a user enters something in a search box that starts a background thread, and then enters something else before the initial background thread completes, how should this be handled?
There are a few options (don't let the second request start while the first is in progress, stop the first as soon as the second is requested, let both run simultaneously and return independent results, etc.), but is there a common/recommended way to deal with this?
I don't think there's universal answer to this. My suggestion is to separate tasks (in form of NSOperations and/or blocks) by their function and relationships between them.
Example: you don't want add image resizing operation to the same queue with fetching some unrelated feed from web, especially if no relationship between them exists. Or maybe you do because both require great amount of memory and because of that can't run in parallel.
But you'd probably want to add web image search operations to same queue while canceling operations of the same type added to this queue before. Each of those image search operations might init image resize operation and place it into some other queue. Now you have an relationship and have to cancel resizing in addition to image search operation. What if image search operation takes longer than associated resize operation? How do you keep a reference to it or know when it's done?
Yeah, it gets complicated easily and sorry if I didn't give you any concrete answers because of uniqueness of each situation but making it run like a Swiss clock in the end is very satisfying :)
Related
I’m developing a small game where the player owns droids used to perform some automated actions. The easiest example is giving an order to a droid to send him at a specific position. Basically, the users gives it a position and the droid goes there. I’m already using a lot Azure app function and I’d like to use them to make the droid moves.
On the top of my head, I thought about making one function that would trigger every minute, fetch all the droid that need to move then make them move.
The issue with this approach is that if the game is popular, there could be hundreds of droids and I have to ensure that the function execution time stays below the minute.
I thought about just retrieving all droids that needs to move then for each of them calling a Azure app function via its URL to make it execute for this particular droid. In my head, it would parallelize the execution a bit but I’m not sure I’m correct.
I also have to think about using sql transaction or not in order to be sure not to create deadlocks.
The final question would be « how to handle recurring treatment of potentially large amount of data and ensure that it stays below the minute ? »
Thanks for your advice
Typically, you handle such scenarios with queues. Each order becomes a queue message, and then Azure Function is triggered by it and processes the order. It can and will scale based on the amount of messages in the queue.
If your logic still requires timer-based processing, the timer should be as lean as possible, e.g. send the queue messages to a queue which would do the real work.
I'm using GPUImageFilter in a chain, and most of the time it works OK. I've recently come across a few random crashes that match the symptoms in this github issue (albeit I'm using GPUImageFilter not live capture or video). I'm trying to find a suitable method that can ensure I've cleared the frame buffer and any other GPUImage-related activities in willResignActive.
Currently I have:
[[GPUImageContext sharedFramebufferCache] purgeAllUnassignedFramebuffers];
Is this sufficient? Should I use something else instead/in addition to?
As indicated there, seeing gpus_ReturnNotPermittedKillClient in a stack trace almost always is due to OpenGL ES operations being performed while your application is in the background or is just about to go to the background.
To deal with this, you need to guarantee that all GPUImage-related work is finished before your application heads to the background. You'll want to listen for delegate notifications that your application is heading to the background, and make sure all processing is complete before that delegate callback exits. The suggestion there by henryl is one way to ensure this. Add the following near the end of your delegate callback:
runSynchronouslyOnVideoProcessingQueue(^{
// Do some operation
});
What that will do is inject a synchronous block into the video processing pipeline (which runs on a background queue). Your delegate callback will block the main thread at that point until this block has a chance to execute, guaranteeing that all processing blocks before it have finished. That will make sure all pending operations are done (assuming you don't add new ones) before your application heads to the background.
There is a slight chance of this introducing a deadlock in your application, but I don't think any of my code in the processing pipeline calls back into the main queue. You might want to watch out for that, because if I do still have something in there that does that, this will lock your application. That internal code would need to be fixed if so.
Subject sounds mutually exclusive, and this is probably a terrible hack, but I'll ask anyway.
I have an single-threaded VB.NET application which is setting status bar label to "Loading..." and then synchronously loading data from database which in some cases can take up to 1-2 minutes. Is there any way to show user an AJAX-type animation while data is being loaded? Of course, the correct way is to use separate thread/BackgroundWorker for data access and manage UI separately, but I can't currently change data access model and have been asked for a "temporary fix".
Here are some of my ideas at the moment:
Update label (and only that single label) from another thread, force it's redraw, somehow circumventing windows forms message pump (probably not possible)
Keep another process in background and send "show" message to it from main application. It shows up in front of application, shows animation until "hide" message from main application is received. (problems with user switching away from main application but "animation" form still visible)
I'll probably get down voted for suggesting it (and quite frankly I don't blame people) but this sounds like a job for DoEvents.
I wouldn't normally suggest it, but you are looking for a hack.
I have created a web-service app and i want to populate my view controllers according to the response i fetch(via GET) in main thread. But i want to create a scheduled timer which will go and control my server, if there becomes any difference(let's say if the count of an array has changed) i will create a local notification. As far as i read from here and some google results, i cant run my app in background more then ten minutes expect from some special situations(Audio, Vo-IP, GPS).. But i need to control the server at least one per minute.. Can anyone offer some idea-or link please?
EDIT
I will not sell the app in store, just for a local area network. Let's say, from the server i will send some text messages to the users and if a new message comes, the count of messages array will increment, in this situation i will create a notification. I need to keep this 'controlling' routing alive forever, whether in foreground or background. Does GCD give such a solution do anyone have any idea?
Just simply play a mute audio file in loop in the background, OR, ping the user's location in the background. Yes, that will drain the battery a bit, but it's a simple hack for in-home applications. Just remember to enable the background types in your Info.plist!
Note: "[...] I fetch (via GET) in main thread." This is not a good approach. You should never fetch any network resources on the main thread. Why? Because your GUI, which is maintained by the main thread, will become unresponsive whenever a fetch isn't instantaneous. Any lag spike on the network results in a less than desirable user experience.
Answer: Aside from the listed special situations, you can't run background apps. The way I see it:
Don't put the app in the background. (crappy solution)
Try putting another "entity" between the app and the "server". I don't know why you "need to control the server at least one per minute" but perhaps you can delegate this "control" to another process outside the device?
.
iOS app -> some form of proxy server -> server which requires
"babysitting" every minute.
I've got a NSSearchField, whose action method does all the searching stuff, by analyzing the sender argument (string).
Now the searching stuff (feeding a large array) is kind of CPU intensive, which lets my search field freeze for some seconds.
In other cases i'd detach another NSThread to prevent my GUI from freezing. But in this case that is not possible, because I would detach another ("search") thread everytime the user enters another letter in the search field.
Is there another way of keeping my NSSearchField from freezing?
BTW: My guess is NO, because even the Developoer Documentation's seach field freezes all the time :)
I use GCD. I use an async queue, and the job periodically checks if the current search pattern has changed from what it was called with, and bails if it has. This seems to work quite well.
Can't you use setSendsWholeSearchString: to stop it searching as letters are typed?
Set an NSTimer every time the user types something.
If there's a timer already set, invalidate or reschedule it.
That way, you only get called upon to refresh the search every N seconds, however fast the user types.