Is there a quick-reference guide to the iPhone SDK that's as fast and easy to use as one of those little O'Reilly books, or JavaDoc?
I'm new to iPhone SDK programming. I need reference material. Let's say I want to know if the string class has a "reverse" function. For Java I go to http://java.sun.com/javase/6/docs/api/ and browse down to find "String". Then I can see everything about String, with hyperlinks to Serializable and Character. I don't see a "reverse" method, but look, there's a hyperlink to StringBuilder -- aha, there's StringBuilder.reverse(). Total elapsed time 30 seconds.
For the iPhone I go to http://developer.apple.com/iphone and log in. Everything seems to be slower here. There are fewer cross-links than in the Java documentation, and each link seems to pull in a big page that takes a long time to load. Just the page for NSString takes 30 seconds to load fully. Maybe I just don't know my way around the documentation yet, but it seems to be much harder to browse for what you want. There's no equivalent of flipping through a book, or if there is it takes 30 seconds to turn the page.
The iPhone platform is immense -- for almost anything you'd want to do, there's got to be a class somewhere that does it. The built-in help in XCode is good but I'm still lost with it.
How do YOU go about finding that class you need? Is there a better way?
I just use XCode's built-in help system. Right-click a class or symbol name, and choose "Find Selected Text in API Reference". You can also do "Jump to Definition", which will open the header file where that symbol is defined.
More info on this stuff here.
When I started with iPhone dev I used the iPhone Developers Cookbook, it has examples of how to do specific things. It's easy to pick out one piece of functionality to try out.
I'd highly recommend checking it out.
Use the XCode hot keys to jump to documentation on anything - in XCode for Leopard, you can double-click on something like "NSString" while holding down "Option" and it will take you to the documentation for that class. You can do the same thing for method names.
In Snow Leopard that key combo opens up a little help box with a summary of what you clicked on, "Cmd-Option double-click" brings up the docs as with Leopard.
The built in docs are very good and even provide links to sample code (if any exists for the subject in question).
There's also a way to generate your own XCode compatible documentation with Doxygen, just like you could with Javadoc:
http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
If the speed of browsing documentation is the issue, I recommend downloading the related doc sets and browse them locally in Xcode. In Xcode's preferences, select the last "tab" (Documentation) and click the "GET" button next to the documentation test you want. (I'm on Snow Leopard and Xcode 3.2, but it should be similar on Xcode 3.1.x as well.)
If finding what you need is the issue, I second #paulsnotes's answer — the "cookbook" approach is very helpful form a task-based exploration standpoint. Also, when you find something you were looking for, and it took much longer than usual, provide feedback on Apple's documentation. Each page has links at the bottom. You can suggest what classes, sample code, etc. would be useful to cross-link to make it easier to find what you need.
If we are recommeding books, this is excellent for a beginner, it gets you up to speed very quickly while leading you through creating highly functional apps you can use as a jumping point for your own:
Beginning Iphone Development
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I read all over the Internet (various sites and blogs) about version control. How great it is and how all developers NEED to use it because it is very useful.
Here is the question: do I really need this? I'm a front-end developer (usually just HTML/CSS/JavaScript) and I NEVER had a problem like "Wow, my files from yesterday!".
I've tried to use it, installed Subversion and TortoiseSVN, I understand the concept behind version control but... I can't use it (weird for me).
OK, so... Is that bad? I usually work alone (freelancer) and I had no client that asked me to use Subversion (but it never is too late for this, right?). So, should I start and struggle to learn to use Subversion (or something similar?) Or it's just a waste of time?
Related question: Good excuses NOT to use version control.
Here's a scenario that may illustrate the usefulness of source control even if you work alone.
Your client asks you to implement an ambitious modification to the website. It'll take you a couple of weeks, and involve edits to many pages. You get to work.
You're 50% done with this task when the client calls and tells you to drop what you're doing to make an urgent but more minor change to the site. You're not done with the larger task, so it's not ready to go live, and the client can't wait for the smaller change. But he also wants the minor change to be merged into your work for the larger change.
Maybe you are working on the large task in a separate folder containing a copy of the website. Now you have to figure out how to do the minor change in a way that can be deployed quickly. You work furiously and get it done. The client calls back with further refinement requests. You do this too and deploy it. All is well.
Now you have to merge it into the work in progress for the major change. What did you change for the urgent work? You were working too fast to keep notes. And you can't just diff the two directories easily now that both have changes relative to the baseline you started from.
The above scenario shows that source control can be a great tool, even if you work solo.
You can use branches to work on longer-term tasks and then merge the branch back into the main line when it's done.
You can compare whole sets of files to other branches or to past revisions to see what's different.
You can track work over time (which is great for reporting and invoicing by the way).
You can recover any revision of any file based on date or on a milestone that you defined.
For solo work, Subversion or Git is recommended. Anyone is free to prefer one or the other, but either is clearly better than not using any version control. Good books are "Pragmatic Version Control using Subversion, 2nd Edition" by Mike Mason or "Pragmatic Version Control Using Git" by Travis Swicegood.
There are lots of benefits, yes you need it.
What tools/techniques can benefit a solo developer?
Best Version control for lone developer
You don't need version control any more than a trapese artist needs a safety net. It's like backing up your hard drive—most of the time it seems redundant as nothing happens but it will be needed eventually. There's no maybes here. It will happen. And you can never predict when and the past is a poor indicator as to when it will happen. It may happen only once ever in the future but even if you know it'll happen once you won't know how bad it will be.
Yes!
Do it. It won't hurt you..
I usually switch from Laptop to PC and back and it's absolutely great to have your code somewhere in a central repository.
Sometimes it's great to go just revert to the latest revision because you screwed up something that would be too difficult to fix..
The biggest advantage that is missing is being able to re-produce the source code that generated an old build.
At build time, you tag the source control with 'Build 4.26'. The next day you start coding Build 4.27. Three months later, when a client says, "I'm using Build 4.26, and there's a bug in the Frickershaw feature. I can't upgrade to any other build because of some changes to file formats you made in build 4.27. Is there anything you can do for me? I'm willing to pay."
Then, you can checkout a branch of the 4.26 source code... fix the Frickershaw feature, and then re-build the package for the user in about an hour or two. Then you can switch back to version 4.39, and keep working.
In the same vein, you can track down the exact point at which a bug was added. Test versions 4.25 for the bug, then 4.20, then 4.10 and eventually find the bug was introduced in version 4.12. Then you look for all changes made between 'Build 4.11' and 'Build 4.12', and then focus on the Frickershaw feature. You can quickly find the source code for the bug without ever debugging it.
Branching doesn't seem useful to you? Have you never wanted to just try something out to see if it would work? I do a lot of plain old html/css stuff too, and I find that invaluable. There is literally no danger in branching to test something, seeing if it works, and deciding "meh" and then just rolling back.
I've never needed to get to a backup (knock on wood), but I find just the rolling back functionality invaluable.
A few perks as a freelancer:
Know definitively what you changed in every single file and when (as long as you check in often)
Rollback to any version in your past. Surprising how often this is valuable.
Track a set of changes as a 'release'. This way you know what each client is currently using and what's in development.
Backup
The ability to easily share a project if you suddenly aren't solo
Try a DVCS like Git or Bazaar. They are incredibly easy to set up, easy to use, and offer all the important features of Subversion, CVS, etc.
The key is that you can revert back to a working version when you break something, which is often much faster than undoing the change manually.
I wouldn't hire a contractor without them integrating into our processes. They would have to access code via our SVN, and would be unlikely to get paid without meeting unit testing and code review requirements.
If contracting I'd make sure to have solid experience of both VSS (check-in/out) and CVS (merge & conflict) models.
Working on your own you have a great opportunity to play and learn with the latest - I'd be trying out Git.
As a lone developer you can think of source control as an unlimited undo - one that works across sessions and reboots.
A minor advantage of source control for me is that I work on multiple development computers. It is easy to move my work around between machines.
The greatest advantage in my opinion has already been listed. It allows me to sleep at night knowing that if we have to roll-back a change it will be fairly easy.
I think the main advantage in moving from a "keep-all-versions file system" to a source code control system lies in the fact that the sccs adds structure to all those versions you kept of all those files, and provides you with records of "what was the consistent state of the whole file system at point X".
In other words, "Which version of file A goes with which versions of B, C, D, ...".
And an afterthought (¡!): the special act of committing or checking in makes you think about "what is this?", and the resulting log message can, hopefully, serve as memory...
The literal answer to this question is, No, you do not NEED version control.
You do, however, WANT version control, even if you don't know it.
That said, many SCM tools can be mysterious or downright unpleasant to use until you break through the Grok Barrier, so let's revise that a bit:
"You do, however, want EASY-TO-USE version control." And it's out there...download a bunch of recommended visual clients and give them a whirl, then try whichever maps best to the way you think.
Which leads to the question you meant to ask:
Why do I want to use version control?"
Answer: Version control allows you to be FEARLESS!
Yes you need it.
At the very least, for a single developer shop, you need to move code into a ProjectName-Date-Time directory several times a day.
That is, write a script that will automatically back up your working directory at lunch and at quitting time, without overwriting other back ups.
This can grow pretty fast, so eventually you'll want to save only the differences between files, which is what a VC application does.
Since you usually work alone, I would say that it is a good idea to use version control. One of the main benefits I have found in using version control (Subversion in my case), is that when working alone it gives me more confidence in trying a new approach to the problem. You can always branch to a new method or framework of solving the problem and see if you like it better. If it turns out that this branch doesn't work, you can just abandon it and go back to the old method. This also makes it easier to try out the different solutions side by side.
So, if you have ever seen a different approach to solving a problem and you wanted to try it out, I would definitely use version control as a tool to make this easier.
If you are working on your own, and are performing backups on a regular basis, VC may not be needed (unless you count your backups as version history). As soon as you start working with another developer, you should get version control in place so that you don't start over-writing each other's work.
Even if you don't need it right now, it is something you will need whenever you work in a team.
Having a history of changes to your html/css/javascript can be a godsend. Being able to compare your front-end to the code a month, or several months ago can really go a long way in figuring out why suddenly the template is all askew.
Plus if you ever want/need to get help on your project(s), you'll have an easy system to distribute, track, and deploy updated content.
Definitely do it, you'll thank yourself once you get used to it.
Checkout (one time)
Update (beginning of day)
Commit (end of task/change after testing)
That's all there is to it. Don't commit EVERY single modification that you're refreshing in the browser, just the one's you want to go live.
Think if it like a backup. It is a little irritating until the day you need it. Then the amount of work you lose is directly proportional to the frequency of your backups.
Another benifit is being able to look at old ways you did things that may have become obsolete in a certain spot but could be usefull in another. Just cut and paste the old code that you got when doing a compare.
That is unless you like reinventing the wheel you already reinvented...
When things can go wrong they will.
It is very nice to have the ability to reference code you may have deleted a month ago, or to recover the entire project after a hardware failure or upgrade.
There may also be a point in the future when the project is worked on by more than you. The ability to prevent (or control) branching and versioning is a must in an environment like that.
Must must must must must must. You must use version control.
This is of the deepest importance.
If you don't understand why now, you will one day.
When your client phones up in a panic because something is broken on the live site and it's a regression, you'll be glad you can just open TortoiseSVN and see what it was you did last Tuesday that caused the breakage.
It's really odd. Ever since I started using version control, I've very occasionally had the need to look up old copies of my code and use them. I never needed to do this before...probably because the idea of doing didn't really stick. It's easy not to notice those times when you could have found version control helpful.
Search within an entire codebase. It's a killer feature, mainly because the search gets actioned on another machine so you can get on with your work undisturbed.
Which incidentally, is the reason why we didn't change to SourceGear Vault. It can't do this. We're still looking for a SourceSafe-compatible replacement for... well, SourceSafe. Despite what everyone says, it hasn't let us down yet*
* this may just be a matter of time.
I think you've made the right decision to use some kind of version control. For simplicity, I'd go with SVN (ignore CVS as SVN is basically a "better" CVS)
SVN can work with "local" repositories right on the filesystem and on lots of platform so you don't have to bite off too much in infrastructure (servers, networks, etc)
Great resource for SVN: http://svnbook.red-bean.com
I don't know much about GIT, but it being open source and gain lots of mindshare probably has alot of similar advantages!
Borrowing a quote from somewhere: You might not need it now, but when you do, you'll be glad you did.
Happy versioning!
Although old and crude, we have found Microsoft Visual SourceSafe to work. It works great for keeping version history. If you are not to worried about branching, which being the solo developer you may not, it might just fit the bill.
As far as checking in, finding a good checkpoint can be a challenge, but checking in on every save will only make versioning hard to track.
"Do I really need version control?"
Yes. Unless you write perfect code that never needs to get changed.
An example:
I had a requirement. I built up a webpage, spent a day or so on the page, it's Section 508 compatibility (this was about 6-7 years ago), and uploaded to the website. Next the requirement was changed drastically. I spend another day working on the page (and Hayuge Excel files didn't convert into accessible HTML easily). About a week later, client switches asks that we go back to Version A. Source control would have done this in about 10 minutes. As it was, I had to blow another %$#^^&$# day on the task.
Yes, you need version control either for development purposes or simply for storing your documents. This way, you can go back in time if you're required to do so in order to revert changes or mistake made on a code or documents.
Once you start working on a team that references ever upgrading "components" from multiple callers/applications, version control will be an absolute must. In that environment, there is no way that you can keep up with all the permutations of possible change.
You need version control just like you need insurance in life.
You need version control to manage different file versions. With it, you can get and work on the files from different places and it facilitates team members to collaborate on the same project.
At work we use confluence.
On occasion it crashes, resulting in an error 500 page being generated.
This page includes some interesting reference information, including:
System Information:
favouriteColour: Myrtle
javaRuntime: Java(TM) SE Runtime Environment
jvmVersion: 1.0
operatingSystem: Linux 2.6.18-92.1.13.el5
...
Myrtle?
Many thoughts raged through my head. What's Myrtle? Why is it my favourite colour? Is it my favourite colour? Why does that particular tidbit of information require its own system property?
At first I assumed it was just something that someone at work had done. A remnant of a project long forgotten, an old April Fools joke perhaps?
It seems I was mistaken. In fact, even Atlassian acknowledges the colour, though they give no reason for its existence.
Now, I know what you're thinking? Who cares?
I do, gentle reader, I do. And you should too. It's little mysteries like this that make life worth living.
So, is there one among you who knows the secret of The Mysterious Myrtle uh.. Mystery? At least one inquiring mind wants to know..
Your Confluence System Favourite Colour (Australian spelling FTW) is also available from Admin -> System Info.
And if I told you any more, I'd have to kill you.
This looks like an obfuscation of their version or the error number.
You're not supposed to give your exact version away when selling corporate enterprise systems - it supposedly makes it easier for hackers to know what vulnerabilities to hit.
However they still want to be able to know what version you're on or what error id you got when you call for technical assistance, so they have a code word for each release.
I suppose the colours run out pretty quickly.
Maybe it's something incredibly fundamental to programming - like pi for math, 42 for the universe, or the L-unit for space travel (as we all know, without it, space travel is but the fevered dream of a madman).
We can only guess.
FWIW, I've frequently put "interesting" information in error dumps -- I've found it's easier to get people to report it in bug reports, and they're more likely to accurately report something like "myrtle" as opposed to "error #47" or whatever...