So I'm building a system in which there is a server object, and it generates Uploader objects. Both are defined as protocols/interfaces, whichever term you prefer. The Server object has a method which generates an Uploader and returns it, with the following signature:
- (id<Uploader>)generateUploader;
The Uploader needs to contain a reference back to the Server which created it, because it needs a reference to a Server to get the password from my keychain wrapper. So, it contains a method which returns its parent Server:
- (id<VayprServer>)parentServer;
Of course, this creates a circular dependency between the two protocols. Any ideas on how to fix this?
Thanks!
Billy
To break the dependency, like all circular dependencies, you gotta forward-declare stuff in the .hs. In particular:
// VapyrServer.h
#protocol Uploader;
#interface Blah : …
…
- (id <Uploader>) generateUploader;
…
and
// VapyrServer.m
#import "Uploader.h"
…
and
// Uploader.h
#protocol VapyrServer;
#interface MoreBlah : …
…
- (id <VapyrServer>) parentServer;
…
and
// Uploader.m
#import "VapyrServer.h"
…
This way, the two .ms will see things declared in the correct order.
This is not necessarily an anti-pattern.
In a tree structure such as the Explorer Tree in Windows Explorer, the Tree exposes a collection of Nodes, but each Node has a reference to the Tree.
Related
If I have a structure:
/app/views/tags/tag1.scala.html
/app/views/mystuff/tags/tag2.scala.html
Then, inside tag2.scala.html
#import tags._ // this refers to /app/views/mystuff/tags
#import _root_.tags._ // I want it refers to /app/views/tags
Then I have an error: object tags is not a member of package
Q: what is the best practice to handle imports if the view-structure is deeper than one level ?
REMARK:
I've already read that _root_ can not be imported. But how can I refer to the root then?
UPDATE:
If I try this (not to use root):
#import views.tags._
#import views.mystuff.tags._
Then I have error: object tags is not a member of package views
For now I follow different structure:
tags/tag1.scaa.html
tags/mystuff/tag2.scala.html
and this of course works (maybe this is even better).
Another idea is to create separate play module. Or even different (rest) application.. depending on what 'stuff' is in each concrete case.
So this is alternative solution, I don't know how to refer to root in that case:
The package "views" need to be the last in structure path, so you must change your structure from:
/app/views/mystuff/tags/tag2.scala.html
to:
/app/mystuff/tags/views/tag2.scala.html
I added the Facebook sdk code to my project then I got this error because I already had a json library, so I deleted the Facebook json library from my computer and from the project but I still get this error. I search the whole project for "#interface SBJsonBase" and I only get one result. How can it say it's a duplicate when I only have one interface? Is it including the file twice? Does the search not always find everything?
May be this helps? Delete your derived data and do a clean project, then try to build again
I had a simular problem. It was a small search, but I could solve it without creating a new project etc...
The thing was I had a Class B that was importing Class A.
Then I had a class that imported Class B and also Class A.
When I did this, these problems occured.
Eg. A SOAP webservice Class imports all the Entities that are passed over the web.
Class goToSchoolWebservice.
import "person.h"
import "school.h"
...
Then I had a Singleton class used for caching that had the Logged in Person and also a ref to the webservice class.
import "person.h"
import "goToSchoolWebservice.h"
--> this is where is went wrong!!
So watch out for these circular references. ITs not so easy to detect them!
if your using #include instead of import then use this technique to minimize duplicates: at the begining of your interface (actually right before it) do check for a definition and if not defined then define it and proceed to define your interface. here is an example:
#ifndef __NetworkOptionsViewController__H // check if this has every been imported before
#define __NetworkOptionsViewController__H
#import "blahblah.h"
#interface NetworkOptionsViewController : UITableViewController
{
NSMutableArray* somevariable1;
int somevariable2;
}
#end
#endif
-- for me personally, i got this error though because the file path to my class was wrong. I checked file inspector and my class file was not defined in Classes folder even though the IDE said it was. I deleted them and copied them over again.
For those that still get this error, despite following header import conventions: I got this error from importing a header that had been deleted from the project. The missing header was instead found in an old backup of my project in dropbox (That I made before doing some destructive stuff in Git), and that file caused the circular import.
I solved a similar problem by moving all the imports to the prefix header file.
I've got a couple of Core Data-generated class files that I'd like to add custom methods to. I don't need to add any instance variables. How can I do this?
I tried adding a category of methods:
// ContactMethods.h (my category on Core Data-generated "Contact" class)
#import "Contact.h"
#interface Contact (ContactMethods)
-(NSString*)displayName;
#end
...
// ContactMethods.m
#import "ContactMethods.h"
#implementation Contact (ContactMethods)
-(NSString*)displayName {
return #"Some Name"; // this is test code
}
#end
This doesn't work, though. I get a compiler message that "-NSManagedObject may not respond to 'displayName' " and sure enough, when I run the app, I don't get "Some Name" where I should be seeing it.
First go to your data model, select the entity you want to add methods to and change the class to something appropriate (I use the entity name with my initials at the beginning). Then select New File... from the File menu. From there select Managed Object Class (you have to do this while the data model is still the active document or you won't see this option). Step through the file wizard making sure to select the correct entity (Xcode will name the file correctly based on the class you entered earlier). Also make sure the Generate accessors and Generate Objective-C 2.0 properties options are selected. You should then be able to add any custom methods you want just like any other class. If you need any more help check out http://themikeswan.wordpress.com/2009/05/30/a-core-data-tutorial-part-2-polishing-the-basics/ I wrote this based on Mac OS X, but the concept is the same for iPhone.
For my iPhone app, I'm consuming a RESTful service and getting JSON. I've found libraries to deserialize this into an NSDictionary. However, I'm wondering if there are any libraries to deserialize the JSON/NSDictionary/Property List into my object (an arbitrary one on my side).
The java equivalent would be the object-relational mappers although the sort of object mapping I'm looking for is relatively straightforward (simple data types, no complex relationships, etc.).
I noticed that Objective-C does have introspection so it seems theoretically possible but I haven't found a library to do it.
Or is there a simple way to load an object from an NSDictionary/Property List object that doesn't require modification every time the object changes?
For example:
{ "id" : "user1",
"name" : "mister foobar"
"age" : 20 }
gets loaded into object
#interface User : NSObject {
NSString *id;
NSString *name;
int *age;
}
Take a look at the NSKeyValueCoding protocol. In particular, the methods setValuesForKeysWithDictionary: and dictionaryWithValuesForKeys:
I've made a framework to do this automatically. Check out.
https://github.com/dchohfi/KeyValueObjectMapping
Take a look at the Loid project on Sourceforge. My intent is to provide what you are talking about.
Right now the framework can reverse engineer a Meta description about an Object (such as your "User" object) and can serialize to and from a LoidTypeData object. My intent is to create a LoidTypeData instance from an incoming JSON block and then bind it to the Object. Of course, the reverse will also be there.
It is open source and GPL. You will need to access the code from SVN at the moment, don't quite know how to build distro for Mac.
-- Frank
I'd like to know if it is possible to hide library implementation from consumers of a static library.
This great thread spawned a few questions in regards to a licensing system for static libraries: Licensing system for static library. The scheme I'd like to use is:
Give consumer a license key they put into a plist
plist is deployed
strong key is generated off of bundle identifier and matched against key in plist
Here is why that system is flawed: I need to run an algorithm (for strong key generation on the fly) that then outputs some string. The problem is I must include header files for the library to be used. At this point, anyone using the library can step into implementations. If I have a method named checkLicense(), a consumer of the library can step into that method and see how the strong key is being generated.
Also, for static methods, am I to run the key generation every time since there isn't any state? I could probably use a singleton and call it in each static method call?
My main problem is that implementation can be seen within a static library if you have the header files. Is there some way of hiding implementation?
Assuming this static library you are creating is written in Objective-C, one method you could use is to create an anonymous category of your class in your implementation file (not your header). In that category, declare your sensitive methods and then just implement them in your class like normal. This makes it so you don't have to expose those methods in your public headers.
For example, in SomeClass.m:
#interface SomeClass (/*Secret stuff*/)
- (BOOL)validateRegistration:(NSData *)key;
#end
#implementation SomeClass
// Other methods....
- (BOOL)validateRegistration:(NSData *)key { /* ... */ }
#end
Notice that this is an anonymous category because I haven't given the category a name (that's just a comment inside the parentheses). This makes it so you don't have to declare a separate implementation block specifically for that category's implementation, which helps hide those methods a little further.