Search Results

Search found 3 results on 1 pages for 'frenetisch applaudierend'.

Page 1/1 | 1 

• May a NSManagedObjectContext re-fault objects automatically?

  - by frenetisch applaudierend

  I am trying to create an application which allows background threads to update core data objects while the user might be reading the same data. My approach to this would be to use multiple NSManagedObjectContexts and then before a background thread does a -save: operation, I fetch the object the user is currently working on and fire the fault for all its properties and relationships recursively. This way I have all objects the user could act with in my NSManagedObjectContext without seeing the already updated values. But this can only work if the NSManagedObjectContext cannot decide himself that e.g. memory usage is too high, and starts faulting objects which I do not explicitly reference (other than through the NSManagedObject relationship). So the question is, can the NSManagedObjectContext decide that an object needs to be re-faulted, without intervention from my side? Thanks for your effort, Markus

  Read the article

• Assigning a default value to a final variable in case of an exception in Java

  - by frenetisch applaudierend

  Why won't Java let me assign a value to a final variable in a catch block after setting the value in the try block, even if it is not possible for the final value to be written in case of an exception. Here is an example that demonstrates the problem: public class FooBar { private final int foo; private FooBar() { try { int x = bla(); foo = x; // In case of an exception this line is never reached } catch (Exception ex) { foo = 0; // But the compiler complains // that foo might have been initialized } } private int bla() { // You can use any of the lines below, neither works // throw new RuntimeException(); return 0; } } The problem is not hard to work around, but I would like to understand why the compiler does not accept this. Thanks in advance for any inputs!

  Read the article

• Is there a difference between NSString compare: and isEqual(ToString): ?

  - by frenetisch applaudierend

  Occasionally I find code which tests if two NSStrings are the same like this: if ([str1 compare:str2] == NSOrderedSame) { // Do something } Now, I believe this is less readable than using isEqualToString: and it also has some nasty side effects, like if str1 == nil the if(..) evaluates to true, or when str2 == nil havoc might break upon us according to the Apple docs. But before I crusade against those statements in my companys code, I wanted to make sure I didn't miss some important point. So my question basically boils down to: Is there any difference between a compare: to NSOrderedSame and isEqual:?

  Read the article

1