iOS Apprentice Sixth Edition Exceeds All Expectations

This particular RW ebook has always been my favorite for years because Matthijs, mystically, seems to always have the information that I need at the moment. This version of iOS Apprentice is no exception.

This is not to say that the other RW ebooks and tutorials are not invaluable because each are essential to those of us who want to improve our dev skills. I have the highest regard for all of you who work so hard to provide the knowledge that is within this website. Bravo!

I have this question based on the following:

In Checklists, Matthijs notes - “Don’t type anything into the button’s Title field. … If your app runs on an iPhone where the language is set to something other than English, these predefined buttons are automatically translated into the user’s language.” I was not aware of this, thus my question.

I have an app that uses two scenes: Scene One is embedded in a Navigation Controller and allows the user to enter numerical data required by Scene Two.

When the user’s makes her final data entry and taps the view, Scene Two slides into view displaying all of the calculations based on the data she entered in Scene One. Scene Two has a single navigation button that I added entitled “Back”.

To clarify, this is not the “Back” button that is automatically added to Scene Two when Scene One has a Bar Button Item dragged onto its navigation bar. Scene One has no bar button items at this stage.

What I would like to know is this: Is it possible to code up a “<Back” button that would be translated into other languages such as the drag on Bar Button Items are able to do?

I am familiar with creating nav bar buttons, but I think these buttons will not be translated into the user’s language. At least, that is what I think.

Further clarification: As noted above, the user causes Scene Two to slide in only after she enters the final required data and taps the view. By design, there are no bar button items to choose from in Scene One. Because of this, as best I know, without the addition of an added Bar Button Item to Scene One’s navigation bar, the “< Back” button will never appear in Scene Two.

I hope I’ve explained this sufficiently clear to warrant a response.


1 Like

I should add that Apple’s UIBarButtonItem documentation has no mention of language conversion if one of their methods for programmatically creating a bar button item is implemented. If that is correct, the that is unfortunate.

There are two possible solutions that I can think of (and there may be more …):

  1. You can embed Scene One in a navigation controller but disable the navigation bar for that view. Then, since you are in a navigation stack, you can have Scene Two display the navigation bar and make use of the default Back button which would be translated to the device language automatically. This is the option that I’d go with if possible/viable.

  2. You can add your own navigation Back navigation button but then do the translating yourself by adding all the localizations. This is more effort-intensive and is probably not the solution you were looking for since I get the impression that you wanted to make use of the automatic translations rather than do your own translations? :slight_smile:

Thank you for your very prompt response.

I understand all that you noted, but unless I’m missing something there is no Back button in the object library, at least not when I placed the “+” (Add) button in my test app. I was hoping that there was, which would have solved my problem.

Please correct me if I’m mistaken.

Thanks again.

There is no Back button in the object library, that is true. But if you have a navigation stack and navigate from one view to the other, the second view automatically gets a back button. This button will show the first view controller’s title if a title is set, but if the title is empty, I believe it simply says “< Back”. So that should (and I do stress the should since I have not tested this to make sure it all works as I said it would …) do what you want.

Thanks again for your help.

I wholeheartedly agree with what you noted:

“If you have a navigation stack and navigate from one view to the other, the second view automatically gets a back button.”

To navigate from view-one to view-two view-one must have a bar button item in its navigation bar. When this button is tapped it slides in view-two and this view will in fact display a “<Back” button in its nav bar as you so accurately noted.

However, I do not have any bar buttons in my view-one and that’s the crux of my problem. I do not want a bar button in my view-one, but I do want a back button in the nav bar of my second view. A back button such as this, could be translated into locale dialects.

If I had some evidence that a programmatically created button could be translated into local languages that would be all that would need to know.

A thought just popped into my head: I may be able to determine this if I put an app on my iPhone that had a coded bar button and changed the language. Crazy idea, but it may prove this one way or the other.

Your help is sincerely appreciated.

For whatever it’s worth …

I just loaded the app in question which had a back button that was automatically created by adding a bar button item in the first view and creating the segue to the second view.

I also programmatically created a second bar button in the second view entitled “Add”.

I then changed the language of my iPhone to Spanish and launched the app. ( I also restarted the iPhone just as a precaution.) When my iPhone came back to life all of the titles were indeed in spanish. However, when I ran the app the back button was still “Back” and the second button was still “Add”.

If changing languages was supposed to change the app button titles of these automatically added buttons it failed to do so. Back should have become “Volver”. I could be way off the mark with this, but those are my findings.


P.S. This have been a good learing experience for me.

You do not need a button on view-one in order to achieve what you are trying to do :slight_smile: I don’t know your level of programming experience and so perhaps I’m assuming you know a few things that you might not …

Basically, you can initiate a segue between two views (or rather view controllers) without having an explicit button action. You can simply create a segue from one view controller to another by dragging from the yellow circle at the top of the view controller (in the storyboard) to another view controller. Then you have to give this segue a unique identifier.

After that, from anywhere in your code where you want that segue to run, you can invoke the performSegue(withIdentifier:sender:) method to execute this segue - no button action needed. That was what I was suggesting for your case.

I believe this is explained in “iOS Apprentice” I forget whether this has been touched upon at the point where you are now in the book but I am fairly certain that this is explained somehwere … If not, please let me know and I’ll add this to be included in the next release.

Thanks again for your indepth response.

I am aware of the performSegue(withIdentifier:sender:), but was not aware that this automatically created a Back button. It makes perfect sense that it could do that, but I could have easily forgotten this (now) important bit of information.

I will code up an app and get back to you.

You have been extremely helpful.

The performSegue(withIdentifier:sender:) method is indeed discussed on page 387. The author’s code triggers the segue when a table view row is tapped.

I believe I will have to use the touchesBegan(touches: withEvent event:) method to trigger the segue via a view tap.

Thanks again for your help.

I believe it might be page 347 (just mentioning in case somebody else finds this thread useful …) but yes, it would be the same technique since you can trigger a segue via code at any time using this method. So, as you said, in your case it would be based on view tap or when the user meets some other criteria. But it should work as you wanted, provided that your first view controller does not have a title.

Good luck and do let me know if you run into any issues.

You have been extremely helpful to me and I sincerely appreciate it.

While trying to implement the method you suggested for creating a segue and then calling performSegue(withIdentifier:sender:, I came across the following by accident.

The method you suggested requires code to work as noted above. I discovered that if you drag a Tap Gesture Recognizer onto the first VC this object will appear in the document outline as usual.

If you control-drag from the TGR object in the document outline to the second VC and select Show, this works perfectly without having to add any code whatsoever. By “works perfectly”, I mean that tapping the first view will make the second view slide right in and it also has a “<Back” button as well.

Using “customButtonGestureRecognizer.isEnabled = false” is also very handy to disable the tap function if necessary.

Can you tell me which, in your opinion, is the preferred method?

Thanks again.

I’m not trying to answer my own question, but could it be that your method allows more control in triggering the segue than using the Tap Gesture Recognizer method that I used?

Just a thought.


There are many different ways in which you can activate a segue. Some would require code and others, as you discovered (and also saw in the book via the table view cells), do not require code. Personally, I don’t have a preferred method :slight_smile: I use the one which makes the best sense to me depending on what I require.

I certainly do prefer not to write any code if I can help it. But that doesn’t mean that the codeless way is the best always. For example, if an accidental tap on the screen can bring up the second view, then I’d probably go with code.

On the other hand, as you said, you can disable/enable the gesture recognizer as you require. So, if you show some sort of a message at the appropriate time indicating that the user can tap on the view now to move forward and it works fine for you, then feel free to go that way.

In essence, use what works best for you :slight_smile:

Thank you for your response.

I did not think I was doing anthing incorrectly, but was surprised at how simple the segue was to implement using the TGR. Being able to control its behavior code wise was important as well.

I’m sure that you will not be surprised to know that I have learned a LOT with just this singular exercise. This latter revelation accidently solved a serious flaw in one aspect of my updated app. It is one of those “Why in the world would a user do that?” things, that if we are fortunate, we would discover (and fix) before the user does.

Becuase I have lost my one trusted beta tester, this discovery has been very, very useful to me.

Thanks again for your help.

This topic was automatically closed after 166 days. New replies are no longer allowed.