Have someone, during CKAssets synchronization between the device and iCloud, had a serious slowdown in the seemingly unrelated to iCloud application elements? For example, is it possible that, in UINavigationViewController, pushViewController works slower than before? The only difference that I've been able to notice is in appealation to objects in iCloud. If yes, how to fix it?
You do have to be aware that CloudKit callback code blocks are executed on a background thread. If you don't call the main thread it would look like your application is not responsive. If you have a callback and within that callback you want to access UI components, then make sure it's in a code block like:
NSOperationQueue.mainQueue().addOperationWithBlock {
... your code ...
}
Related
We are building a React-Native iOS app that needs to access our realms natively as well as via RN.
We have writing working correctly from our UI and can load the data in our background Swift service, but after the write, The changes_available method in js_realm.cpp is firing which contains assert(0) which is causing the app to crash/hang in debug. What do we need to be doing to prevent that method from firing?
Update: A release was just made (0.11.1) which should prevent this crash from occurring. Note that notifications across bindings have not yet been tested and may not work.
This method gets called when changes are made externally to a Realm from another process or thread. In your case it sounds like writes made from the swift apis are causing this method to get called. The ReactNative binding was written with the assumption that everything would be done from a single thread without considering the use of other language bindings being used simultaneously.
As is the only thing you can to do prevent this is to not make a write in Swift while a Realm is open in JS. One way to do this would be to call Realm.close after every use, although this may perform poorly.
In the near term we can also do a point release to remove the assert(0) - this will prevent the crash/hang, but notifications for changes made in Swift wont work without additional changes. Can't give an estimate of when we can get cross language notifications working properly.
First of all, I am a a very new Objective C/Cocoa iOS Developer but I've written C/C++ applications before.
So I managed to run the Rabbitmq-c (http://hg.rabbitmq.com/rabbitmq-c/) client inside my iPhone App, and I can connect to Rabbitmq directly from my app and even consume a queue item. So all's good.
Now my problem is, my iPhone app needs to use the rabbitmq-c library to poll for incoming messages in from the server. Probably there will be, an almost infinite while loop.
Do I have to take this to a new thread? Ideally, I want to wrap the rabbitmq-c class as an Async objective C class and use NSNotification (or something similar) to notify my UI. I'm a bit leery of creating a new thread, as I read about stuffs like Runloop etc can solve a lot of problems without using an extra thread.
What is the best way for me to go about this? Any examples of code or directions would be helpful. Please remember, I am not dealing with an Objective C code/Coca rabbitmq library here, I'm using C code inside my iPhone app.
Thanks
Subrat
don't block the main thread with your server polling.
since the operation never ends, create your own thread and run loop for this server polling. you can potentially use the run loop (each thread has one) instead of the infinite while. the alternatives involve regularly spawning threads. it's easiest to just use one thread for this.
once you have an update, post the notification (if you choose NSNotification) from the main thread -- UIKit is meant to operate from the main thread only.
for samples, i'd begin with samples related to NSRunLoop and CFRunLoop.
good luck
You can also create custom delegates for updating the UI, or the stuff related to UIKit.
Notifications might be a little easier to code and offer the advantage that multiple objects can observe one notification. With delegates, such a thing cannot be done without modifying the delegating object (and is unusual).
Some advantages of delegating:
The connection between delegating object and delegate is made clearer, especially if implementing the delegate is mandatory.
If more than one type of message has to be passed from delegatee to delegate, delegating can make this clearer by specifying one delegate method per message.
Or other way is to write method to receive messages. This method can have infinite loop.
Later you can put this method in background thread like this.
[self performSelectorInBackground:#selector(receiveMessages) withObject:nil];
So I've read some stuff about multithreading and NSOperation and wondering how I can use that to improve my app. Using Instruments I have isolated a few places where my app could definitely use a speed improvement. My question is, are these kinds of things suitable for another thread using NSOperation?
Drawing a view: I have a rather complex view that is taking a little time to draw. When it's drawn I experience some lag.
Allocating and playing audio: I'm using AVAudioPlayer to play some background music. When I allocate it, again some lag.
Calculations: I'm also performing some calculations and doing some comparisons with lots of integers.
I strive for the best possible performance for my app, so what would you do?
UI updates are not suitable on the Background thread. All UI updates always need to be done on the main thread. If your view is taking too much time to render, consider refactoring, pre-redering and caching or some other means of optimization.
Audio code can be background based, but shouldn't be that expensive
Calculations can definitely be backgrounded without worry.
I concur that background threads are not the thing to do for UI updates. Since the user is "blocked" on waiting for the UI to show them what is going on - it doesn't make sense from a logical point-of-view - and it can cause other coding issues.
The biggest thing I have found good for background threads often has to do with asynchronous operations. (Think of an AJAX web page). If you want your user to be able to interact with the UI while something is going on. A good example would be retreiving, updating, fetching any kind of data from the web.
Even if you are doing any kind of web operations which you would think should be synchronous - (like loading a message from a web site) - you would probibly want to handle it asynchronously because you don't know what kind of network conditions would cause it to take a long time - and perhaps eventually timeout or fail. (Something like recording audio would work like this too).
Even if you were to want to block your application when reading such a synchronous piece of data from the web, you may still want to do this asynchronously - so you could load the data in a background thread - while you give a progress bar, spinner (progress) control, or allowed the user to hit a "Cancel" button in the foreground UI thread.
Think of "asynchronous" requests as ones that will take a longer period of time - or in which you can't determine how much time it will take.
Some UI drawing methods were made thread safe with iOS 4.0:
source: Apple dev: What's new in iOS: iOS 4.0
Drawing to a graphics context in UIKit is now thread-safe. Specifically:
The routines used to access and manipulate the graphics context can now correctly handle contexts residing on different threads.
String and image drawing is now thread-safe.
Using color and font objects in multiple threads is now safe to do.
I've found that my apps generally benefit the most from background threading:
Downloading things from the web
Expensive queries (reading/writing) to the database
Long running algorithms
If you do decide to background some tasks, I would recommend using NSOperation and NSOperationQueue, as they simplify things a lot. A bit of a learning curve, but definitely worth it!
Best of luck!
I am sold on KVO but if used in the obvious way it is synchronous. I would like to use it in a situation where I am firing off many KVO messages in rapid succession and it is causing my app to grind to a halt as the KVO messages are handled. Can someone suggest an approach - perhaps using NSOperation or NSThread - that will work here?
My goal is to retain the decoupled, flexibility of KVO if possible.
KVO is inherently single threaded in that the KVO notifications will be delivered on the same thread as the change.
Of course, UIKit and Cocoa both really only want you to be diddling UI elements on the main thread.
Thus, if you are doing asynchronous operations, you are most likely using threads and, if so, already have a synchronization issue in that you need to get the notifs from some thread to the main thread.
And therein lies the key. Instead of blindly forwarding each change notification as it comes in, you can coalesce the change notifications before passing them on to the main thread.
There are a variety of means via which you can do this. The specific solution is going to be quite unique to your application, most likely.
Personally, I try to avoid coalesce-and-forward of fine grained operations. I find it far simpler to tell the main thread that a particular sub-graph of objects have changed. More likely than not, the drawing code that will then make the changes visible to the user is going to need to redraw related state and, thus, related changes will be automatically reflected.
The key, as you have surmised, is to throttle the notifications so you don't bog down app responsiveness (or destroy the devices battery life).
Use the Receptionist Pattern as recommended by Apple https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/ReceptionistPattern/ReceptionistPattern.html
Check out NSNotification. It's not quite the same thing, but you can fire off notifications on background threads (with a little bit of research and work). You can maintain the nice decoupling and fire-and-forget behavior.
I have some slow internet task to save and load file, I'd like to do those slow tasks in some background thread. I am wondering whether that's doable, and if it is, any sample code?
Then after it is finished, I'd like it to notice back to the main thread, so that I could update the UI.
Take a look at NSURLConnection. It will load an NSURL (using NSURLRequest) in the background, and send delegate methods regarding its status.
Ultimately the device you are running your code on has a single processor and cannot possibly load large quantities (gigabytes) of data. The best route, by is likely that suggested by Ben (NSURLConnection asynchronously) which gives you the added advantage of being able to cleanly cancel and handle error messages. While it isn't technically threaded in the way you probably think you want it to be, it is well integrated with the event loop and is non-blocking. If that is still not enough, I would suggest looking at NSOperation and NSOperationQueue. You can fire off an NSOperation sub-class object and perform the download there (I would still advise doing it asynchronously there so as to enable canceling, pausing, etc).
Log in to the iPhone Developer Center and search for Introduction to Threading Programming. Or, maybe you can log in and use this link:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/Multithreading/Introduction/chapter_1_section_1.html#//apple_ref/doc/uid/10000057i-CH1-SW1
If you do decide you need a background thread even after using asynchronous HTTP calls to gather the data, don't forget to wrap the background thread code in a new NSAutoReelasePool and then release it at the end.