probably me be stupid, but i cannot figure out how to use namespaces in the iphone sdk. Please could somebody help me. basically I need to know where to define a namespace in the files, i assume in the header, but where? I keep getting errors.
Objective-C does not have namespaces.
As Daniel A. says, no namespaces in Objective-C.
It is common practice - and recommended by Apple - that you prefix your frameworks / packages with 3 letter codes. Apple uses things like UIKit, NSString etc.
So you could use DTHCoolClass etc.
Objective-C has no namespaces. What people do is prefix their code with some capital letters. Like initials or product name abbreviation. Personally I hate it and I use normal names like SignUpViewController instead of SMASignUpViewController.
In my opinion the world would be a better place if app developers dropped the prefixes. I'm ok with libraries using this.
As others have mentioned, Objective-C doesn't have namespaces. Apple recommends that you prefix your class names with 2 or 3 letters indicating the project, framework or developer.
In practice, whether or not you should prefix depends on what sort of class you are talking about, and how it is likely to be used.
I prefix all model and utility classes, since the names could clash with Apple's (or 3rd party) libraries (e.g. use NFResourceManager instead of ResourceManager, and NFRecord instead of Record). These sort of classes may be pulled out into another project framework at some stage in the future, so prefixing them allows you to keep the names unambiguous.
I almost never prefix view controllers, unless I think there's a good chance I'll use it elsewhere, or want to share it. The majority of VCs won't get used elsewhere, so there's little benefit of prefixing (and you're unlikely to have imported code from a 3rd party library that contains VCs).
For most view classes, I prefix them, unless it's highly specific to a particular project/app, in which case there's little point.
If you're trying to use namespaced C++ code within your obj-C files then you'll need to rename your source files to tell Xcode to use the C++ compiler. Rename the relevant .m files to .mm and you should be able to use C++ namespaces.
Me being a little stupid, i was trying to create the namespace in the wrong place
Related
I have a few extensions that I'd like to use throughout my project but I'm unsure if I should keep them in their own file, or if I should just make specific extensions in each viewController file.
Which would be more efficient or better?
I think this is largely a matter of style rather than efficiency. That said, yes you should put them in their own file. That way if you want to reuse them between projects, you can simply drag and drop them into a new project.
In general, it is best to keep your files as small and modular as possible in order to keep things simple. If a piece of functionality doesn't specifically pertain to that file or viewcontroller then I think you should break it into its own file.
I usually make files following the naming convention of Objective-C categories which are similar.
So, I put my String extensions in "String+Extensions.swift" and my UIViewController extensions in "UIViewController+Extensions.swift"
If I want to sub-categorize even further, then I make more files with different words after the +. In file names, to iOS devs that have done a lot of Objective-C, a + means "has categories" and for Swift files, means "has extensions".
In C, C++ and Objective-C you can compile part of an executable into its own "object file" and use it (and/or a library containing multiple object files) from any other code by including a "header file". Highly-templatized C++ code notwithstanding, a "header" typically contains just the declarations needed to validate the correctness of calling code (and assist the IDE with autocomplete, etc.).
But Swift does not have header files.
Now, apparently it is not currently possible to make a Swift static library, but in the future how would a situation like the above work, wanting to use some existing precompiled code from "new" source code, given that Swift does not have headers?
Would it work something like how [I infer] Java must work, where the compiled form can be introspected enough for the compiler to verify it is being used properly? Does Bitcode in addition to its intermediate representation also provide the necessary "protocol" for retaining such metadata?
If Apple were to port Cocoa to Swift (and keep it closed source), how would it then be "imported" into Swift apps?
Although, really, this question is not anything to do with "closed source" per se but rather trying to understand the boundaries around compilation units in Swift. Based on a similar question for the Go language, mine here could be re-phrased as: can you link to a pre-compiled Swift library without the source?
Well, just consider Apple's Swift libraries. They are closed-source, and you can use them fine and you can see pseudo-"headers" for the stuff in the library in the compiler. The exact mechanism of how this works is not currently publicly documented, but it must exist.
In addition to #user102008, the good new is, Swift will be open sourced by the end of this year, and even ported to Linux by Apple. While we can't guarantee it will always work that way (as Apple has poor records on those kind of issues), people will found suitable solutions within this even if Apple has no interests in doing so.
Even more, afaik, Swift objects were actually Objective-C objects. There'll not be that different to make Swift things work than Objective-C. (More details: http://www.eswick.com/2014/06/inside-swift/) After they were compiled, just do a class dump (or load it into a debugger such as IDA) and you can easily create a .h to make it work like normal static library or a framework.
I m going through framework files that comes with iOS, like Twitter.framework. What i can see is that it all contains the .h files, where as i want to see the implementation files, is there any way to view them?
You can't, and in the vast majority of cases you should have no need to beyond your own curiosity.
The .h files are provided so that your code can link to the Apple provided API's. You don't have a technical need to see the implementation and Apple doesn't provide them presumably because they don't want you to see their implementation. There are valid reasons for this such as protecting their intellectual property and maintaining a certain level of security by obscurity within the OS components.
No, Apple does not supply any implementation files for their frameworks.
we cant see the m file of any frameworks.
all we can get is only .h files.
if the implementation's source files are not provided and a binary is provided for you to link to, then that is by intent. some libraries provide their implementations, and some do not.
When I'm using big frameworks like the Three20 Framework,
I always have the choice whether to #import the whole framework or to #import only the single file of it i'd need.
I guess there's a difference in compilation-overhead since it has to open all files of the framework, but is there also a run-time difference? like bigger memory-usage? Or does the compiler-optimization already remove everything that's not needed?
And if I use the same framework pretty much in every class I use, is it recommended to include the framework in the prefix file instead of every single class?
Greetings
Infinite :)
There will be a compilation difference, yes: including everything will take longer to compile. But there shouldn't be a run-time difference.
Your idea of including the framework in the prefix is a good one for frameworks you're going to be using throughout. However, there is a catch, which is that if you change something in that framework your entire codebase will have to be recompiled.
There is no performance hit in runtime. No matter how many frameworks or files you import, if you don't use whichever classes they won't affect the resultant bytecode when you compile. The compiler doesn't even optimize anything; unused classes just "aren't there" at all.
Include the framework in the precompiled header file if you're sure it's going to be necessary.
You footprint won't be any different unless you actually use the classes however I prefer to be more frugal with my headers, only including the ones I need. If I need a lot from the same library (like Three20) then you can add the whole reference.
Only include headers in the prefix that don't change much, but it will speed up compilation greatly.
Are there any tools out there for Objective-C / Xcode? Something that can do one or more of the following:
Detect unused imports
Auto-synthesize properties
Autogenerate dealloc method from retained properties
Provide method stubs for interface
-Detect unused imports
Not sure of anything that checks for dead imports.
-Auto-synthesize properties
-Autogenerate dealloc method from retained properties
User Scripts work quite well to do this inside Xcode, you can also use a program like Acessorizer as mentioned but it pastes something onto the clipboard for you to paste.
-Provide method stubs for interface
type "init" just after #implementation, and type Control-. (period).
These are user macros (not scripts), and you can easily define your own. Note they have placeholders that you can use tab to jump to the bits to fill in.
You want to look at Kevin Callahan's Accessorizer, which can do several of the things you request and more. The Google Toolbox for Mac also includes an Xcode plugin that can remove whitespace and a few other things.
You could probably do something with AppleScript or another scripting language, called via AppleScript, to operate on method or header files.
If you want static analysis, Clang is built in to all recent releases. None of what you've described has anything to do with static analysis, however.