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".
Related
I have two apps with very similar code bases, but full of different data, labels, images, etc.
I'd like to make a new app with two buttons on launch, one for each app.
I can't just combine them, because the apps share a lot of same class names.
What is the best way to do this?
Thanks!
is there a way to refactor every file at once?
No, there's no tool in Xcode to rename all the identifiers in an app at the same time. However, if you use the Rename tool, you can change all uses of a given identifier at once, which is a huge time saver. You could easily rename several dozen classes in an hour or less.
You can use "Refactor" functionality of Xcode.
First create your one project. Make everything you want. Then, just refactor the project and give second project name.
So that, you will have 2 copy of the project with different name and you can achieve your goal.
Happy Coding.
Cheers!
You need to rename all classes !
As a project don't contain same name class.
Simple add some extension for differentiate you class,
like
LoginViewController_firstapp.h
and
LoginViewController_secondapp.h e.t.c.
using Refactor tool! Its works like a charm!
Enjoy coding
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.
In general I know how to do the Localization of iOS apps, the only thing is to choose between available ways and do it the right way. So I'd like to ask you about your l10n approach for your projects.
Here are my inputs:
I have 15 XIB files (packed with
lots of IB outlets that are not
synthesized as properties, but will
have to be localized).
It is most likely that that my
app will have 3-5 language versions,
but it is possible that I will even
go for 10 languages in the future.
In near future I plan to add new
targets that may change UI design
(paid/free versions).
I see two ways I could go:
Option A: localize each nib file by making XIBs localizable and adding language versions:
I fear that with 15 XIBs and 3-5 languages it will be maintenance horror that will go out of my control when I'll extend localization to ~10 languages and introduce new targets (maintenance horror is not about SCM, I'm using git btw).
I'd need to keep in sync all versions of XIBs which would effect in painful change-request process.
I also fear that my app bundle will grow big (currently XIBs use ~1.1 MB and translate to ~120 kB of NIB files).
when I'll decide to do iPad version, the number of XIBs will grow again.
Option B: do the localization in the code by wiring up all needed outlets synthesizing them to properties and setting their labels/titles correctly:
I fear that my app memory footprint will be really big. Or, considering proper mem mgmt, should I not consider this an issue?
I'd go for 2nd option as I see less cons to it and it can allow having everything in one place under control in each view controller, but I'd like to know what would be your choice? Which way works better for you?
EDIT: I know that that ibtool could simplify the process in Plan A, but I'm still not convinced for it.
I am using Option B in all of my projects, since this also makes it easy for me to distribute the string files to the localizers. Testing is of course needed after that to make sure the strings fit into place. Also some projects do not use XIB files, so the process is always the same, no matter if XIB files are used or not.
There is no memory issue with that option at all in my experience.
Well, I was expecting a little more feedback from SO users, but that's fine as after some research I've made my own decision to abandon option B and go for a modified version of option A.
I've heavily used ideas from a Compile-time approach by Philippe Casgrain. In general it uses ibtool to automatically localize nibs when building. Philippe's approach keeps maintenance reasonably sane for now. All other strings that I use in the code are handled using NSLocalizedString approach which was quite easy to implement in my case (just used genstrings tool). The only issue that can potentially hit me in the future is adding new targets with different/modified UI layouts.
It's hard to say whether it was the best choice. Time will tell, so some day I'll update the question and share with you how the decision worked out for me. Maybe someone will benefit from it in the feature ;)
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
I have some utility functions like:
void myVibratePhone()
{
AudioServicesPlaySystemSound (kSystemSoundID_Vibrate) ;
}
that I'd like to use across all my projects.
In C, I'd give each project the header file, and link in the .OBJ file (or perhaps create a library).
What is the Apple-approved recommended way to share code (cocoa and C primarily) among my apps? Would I need a framework for this? How would I go about creating one?
Also, since I'm using subversion for version control, if I use a framework, do I place the version of the framework that the app is using in the subversion repository for the project so that anyone who checks it out can build it straight away or make it a requirement that people check out a project + check out the utility functions also for a successful build of any project?
I don't plan on putting anything on the App Store at this time, but I don't want to do anything that will cause apple to not accept an app in any case.
I found this writeup about xcode 3.0 (I'm using Xcode 3.2.1):
How do I create a bundle of reusable code in Xcode?
I followed it, but am having one issue:
1) trouble finding my library .h file in the main project: I've tried both hardcoding it in the main projects .h file
#import "file://localhost/Users/piesia/Documents/My Utilities/MyUtilities.h"
as well as:
#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"
and
#import "~/Documents/My Utilities/MyUtilities.h"
I've also tried updating Header search paths in the Project Build settings:
"/Users/piesia/Documents/My Utilities/**"
when using #import
After a lot of trying (and replacing %20 with space), I was only able to get the variants
#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"
and
#import "../../My Utilities/MyUtilities.h"
but I'd prefer not to hard code the path if I can figure out a better way.
So, in closing, 1) is the writeup that I'm following the recommended way to do shared code in Xcode 2) is it recommended that I keep the shared files in a separate subversion repository from the main program and link and include it in as I'm doing now and 3) do you know what I'm doing wrong in my attempts at loading the shared header file? Would anything that I'm doing or not doing with shared code hurt my chances of getting approval if I ever decided to submit it to the App Store?
I agree with creating a static library to share the code.
To add the headers to the project you need to set the "User Header Search Paths" to the location of the .h files.
You then import the headers using something similar to:
#import "YourHeader.h"
You shouldn't need any additional path information in the import if the header search path is set correctly.
Oh this one is a bugger! - I think unfortunately the easiest way is to hardcode.
My team has dozens of reusable components in our products, many of them shared between Mac and iPhone. My experience in this is that most of the time it's much easier to just include the source code rather than to create a separate static library. The separate project for the library adds a lot of complexity and seldom provides much value. Here is how I usually approach it:
In subversion we have a directory tree like this:
/common
/Component1
/Component2
/Project1
/Project2
...
In Project1.xcodeproj, we just drag in "Existing files" from common into the tree (don't copy). Doing it this way avoids lots of overhead in managing another project. This does mean that changes to the common tree can break any of the projects. That means you need to recompile everything before committing (we use a top-level build script to check that you didn't break anything). The advantage of the static library is that you can stage this by upgrading the library for each project when it's ready. On the other hand, it means that you have to rev the library often and manage syncing it around. We've found that just sharing the code directly typically is much more effective.