3

I'm training the new iOS developer who will replace me. However, the majority of views in the project is created with code (using a library to make Autolayout more concise). There is no storyboard in the project and the process of starting the app is also in code (AppDelegate).

This makes the handover more troublesome as I know that the new developer will have a hard time tracing which classes I used for which UI elements, especially the one who is not familiar with it.

1) How should I make a document for the project which views are built programmatically? Currently I just took bunch of page screenshots in the app, ordered it in a flow, and put a class/file name on it.

2) Also, are there any suggested way or patterns to arrange the code so that the project built without using interface builder is easier to reason about?

Improve this question
2
  • 1
    How do you keep track of which classes you use for which UI elements? Is there a naming convention, or some other mechanism? Describe that in your document.
    – Robert Harvey
    Commented May 12, 2017 at 4:09
  • 1
    Sounds like you created a storyboard after all! But your storyboard is all documentation and not executable...
    – Daniel T.
    Commented May 13, 2017 at 1:59

2 Answers 2

Reset to default
2

It sounds like you've documented which view goes with which class and which source file. Pictures with a flow is a pretty good way to do that. It would also be important to document why you've done it this way, and if there are commonalities between the views what those are and the thinking behind why they are that way. Knowing your thought process may be more helpful than knowing the specifics of any given class. I often find that I understand a source base much better after I've figured out how the previous owner of it thought. It makes finding things in the future easier, too.

For arranging the project, I'd probably use Xcode's Project Navigator pane to arrange the source into related folders. For example you might have a view that has several options that lead to different sub-views depending on what the user presses:

Foo -> Bar 1 -> Baz 1
   \-> Bar 2 -> Baz 2

I'd arrange the files into folders something like this:

Foo
 +- Bar 1
 |  +- Bar1.mm
 |  +- Bar1.h
 |  +- Baz1.mm
 |  +- Baz1.h
 +- Bar 2
 |  +- Bar2.mm
 |  +- Bar2.h
 |  +- Baz2.mm
 |  +- Baz2.h
etc.
Improve this answer
1
  • "I often find that I understand a source base much better after I've figured out how the previous owner of it thought." +100 the most useful documentation will mention what/how, but focus on why.
    – RubberDuck
    Commented May 12, 2017 at 16:44
0

It's a good idea to have a comment at the top of each source file explaining what the code in each source file is good for, and what you would have to do as a user of the application to execute this code. You'd think that is common sense, but surprisingly often it isn't there.

And then what you did: Have a screen shot for each user interface class, with the name of the class, and a document telling other developers how you go from one screen to the next, that's not bad at all.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.