Jumping into a new language can be daunting, but according to Guilherme Silveira, once you understand the basics of what you’re building, how, and why, the rest will all fall into place. In this interview, we find out how he’s applied this simple rule to his inaugural Parleys Course: Swift and iOS from scratch: Coding like a Pro. For first time iOS developers, this course will guide you through several parts of the language and the API.

Can you tell us a little about your background? Are you primarily a mobile coder?

I started as programmer in Brazil and moved to Germany when I was 18 to work for a software development company. I helped co-found Brazil’s largest online user group and Q&A site, GUJ.com.br. When I came back, I could either go to a consulting company and work for one project at a time, or change the software development industry in Brazil by starting a teaching business- so that’s what we did.

Since then, I have developed a lot in Java, a little in Ruby, Scala, and less often for specific platforms and languages such as Android, iOS, Octave, R, etc. This way I keep developing, researching, and – most of the time – discussing and understanding how things work and why.

My daily life is both at Caelum and Alura, our two main companies, both focused on software development education, and some of my time is spent at Casa do Código, a Brazilian publisher.

You work as Head Instructor at Caelum – what has this taught you about educating developers?

First, a teacher is there for all students. It is easy for a teacher to work with the average student: they stick to the content in the expected rhythm. It is hard for a teacher to cope both with a student that started somehow behind others, or a student that started ahead. It requires energy and will. So our courses and teachers must be adapted to deal with any conceivable situation. That’s a huge challenge.

Then we have to fight “silver bullet courses”. It is pretty easy to find tutorials or trainings that teach something good and forget to say when not to use that. A developer who does not understand why his tool is bad, is damned to suffer from its usage. Teach why something is good and why it is bad, show why that feature should or should not exist. Then you have a developer thinking for himself, otherwise you just have a follower.

So we try to teach what they will have to use in their daily lives: learn to learn by themselves. It is a tricky thing. We teach developers to be independent of us, and if they like it, they come back. Teachers should focus on teaching thinking about trade offs, quality, don’t believe everything they say, question your own code, and your own beliefs.

In the end, an average developer is, well, average. Improving average is my work. If we improve the software development market in 1%, then it’s 1% more productivity for the entire industry. Good teaching is key for the average quality to increase, and that’s the challenge – good teaching.

Brian Goetz talks about a similar topic when he mentions that improving Java means improving an average of 9 million developers. If he is capable of adding a new concept to the language that improves the life of all (and not just some) of the 9 million devs, he changed the industry. That’s what keeps him motivated to develop Java as a language.

Can you tell us what people should be able to do at the end of your course?

They will be able to understand the language, why some of its features are good or bad, how, why and when (not) to use them. It is not about syntax. Syntax is really nothing compared to feature composition, to pattern creation and code maintenance in the long term.

You will also understand basic components, the interface builder, and the storyboard. As Apple tries to sells us the drag and drop visual basic 1996 programming style (which is actually even better for newcomers than VB was – nobody can deny it), we need to understand those concepts well. But its implications are also important; why does the drag and drop generate code that seems so bad compared to the language design specifications? We will understand those issues and know how to tackle those, including learning how to do things programatically, not only drag and drop them around.

Swift Visual Basic-alike drag and drop solutions are amazing, and reach out for new developers. Segues are amazing. On the other hand, more advanced developers might want to use their custom XIBs, and connect everything neatly with unit and system wide testable code.

Summing up, you will learn the base of the language, API, components, drag and drop, and understand why it works like that, as well as good design practices (from immutable state to good citizens, separation of concerns, refactoring, DAOs, etc) and code smells (lots of comments, big methods, and high complexity) will be part of our discussion.

Of course, everything is done by creating a real life project, going through real life issues.

Is it aimed at any particular level of developer?

Beginners in mobile development, newcomers to software development who already learned logic, former Objective C or android developers willing to understand how to apply some Swift good and bad practices. Teaching as much API as possible is not the goal of these three courses. We intend to provide the basis for the students to look up APIs and know how to use them well.

What will the biggest challenges be?

As with any mobile environment, I understand the issue is runtime errors.

In a web environment, if your client tries your web application, and your server throws an exception and your end user gets a 500, or you provide an invalid button click that gives a 404, what does the user do? Refresh. Or back and try another link. No problem.

In a mobile environment, if you try an app that throws an exception, your application crashes. What does the user do? Typically they uninstall and try another one. There are dozens of applications that do variations of what our apps do.

So what does Swift do?

```
class Product {
  var name:String
  init(name:String) {
    self.name = name
  }
}

var age = 15
```

No, that code does not compile. Every variable must have a value. There is no null value (by default). Your code only compiles – and goes to production – if all values were set. No more accessing invalid memory references and crashing (or worse) your app. Never. Not because of nulls. Never. Ever.

So you must initialize it, as a good citizen:

```
class Product {
  var name:String
  init(name:String) {
    self.name = name
  }
}

var age = 15
```

A good citizen is one that, if you can ask him something, is going to behave properly. There is no “illegal state” question that can be posed to a good citizen. Note that this is not a matter of immutability. Our previous good citizen will *never* have a null value, since the compiler does not allow it. But if you want it immutable, you can:

```
class Product {
  let name:String
  init(name:String) {
    self.name = name
  }
}

let age = 15
```

Great, Swift by default makes our code safer – and we can live with safer mobile apps. But you probably heard they have optionals, and have seen a lot of !? around, right? If I define a variable as optional!, I don’t need to set it’s value, so the following code compiles again:

```
class Product {
  var name:String!
}

var age:Int!
```

But then, what happens if I try to access their members? Members of *null* values? Crash! Note: the optional? variant provides a different variation of positive and horrible situations.

While Swift by default makes everything mandatory and safer, you will notice that most tutorials, the drag and drop engine, and parts of the API (mostly due to backward compatibility) were built using a lot of optionals !?. Why? While the API was built like this for backward compatibility, some other decisions seem to be based on field injection, a popular topic on dependency injection engines.

As you can see, I am not a fan of field injection, of running away from safe environments, or of skipping compile time safety for our apps. And we will try to show both sides throughout the course so the students are not led to belive “only one side exists”. Know and understand your language.

There is a fight between the language and the API. There are several solutions to create values and make sure they are valid. The good citizen pattern, builders, singletons etc. Singletons? Oh no. Still, there are so many solutions that we have created, and Swift (if avoiding optionals with !?) has one of the best I have seen in a language that is really trying to be mainstream.

There are several amazing things about it. The interface builder and navigation system is also amazing, but in all these points you will notice the fight between the language – programatically creating your app – and building a fast prototype with segues, and messy methods with several switch cases. While the drag and drop rapid solution makes us do it this way, the language tells us the opposite. 

That is painful, and developers must understand it well before continuing.

Oh, before I forget, there are also “weak” references. We know them. But most of us don’t. It is not difficult to understand them, but they are a barrier for a first time developer to do it right. 

Do you see Swift as the next step from Objective C, or do you think it has a different role? 

We hear that Swift might replace Objective C in the long run, but it also might be that low level developers still develop in Objective C, while newcomers develop in Swift. Swift would be the answer to easier programming and allowing new developers to use it. The entry point for android is knowing Java and understanding basic mobile concepts, although it is not rocket science, it’s not like “my first PHP script”.

PHP is so easy at first for new developers that it allows a huge horde of newcomer developers to learn web programming. That is a great thing.

Swift might allow us to have that horde of mobile developers. The question that I always consider is…how do we want those new developers to learn? Bad code? Good code? They are our legacy.

Swift might not substitute Objective C when writing low level code, as PHP did not substitute C, but if it allows us to double the number of our fellow developers. And that’s good for us as a software development industry, and also the wider world.

With the predicted price hikes from Google this year, do you think we’ll see more developers turning to iOS from Android?

I am not an expert on apps market, so this is a tricky question for me. It is said that iOS users are more willing to spend money in apps than Android users. But market share is 86% Android, 12.3% Apple. Since Android has 7 times reach than iOS, unless Apple users buy 7 times more than Android, **if you have to pick just one**, **considering this simplistic** scenario, it seems wise to currently develop first for Android, then for Swift. 

But wait. There are so many other variables in place. We have to worry about people finding our app. Is our application a first timer and people will only find it if they search for it? Not an easy start. Is your app is a version of a current web application? If so, won’t your users be disappointed not to have it available on iPhone? Are your current users iPhone users? Did you look at your analytics?

 There is so much that we need to take into account that is seems impossible to answer this question. We typically tell our students to first analyze who your target clients are. If you have this information from analytics, good, use it, and build it first for iOS or Android. Then for the other one.

Anyway, you (our student) will develop the app for both platforms, since he does not want to lose part of the money and market share that both iOS and Android provides. It is wise to benefit from all big players. 86% of the market share makes it a must for Android development. 12% of the market plus higher sales on their platform makes developing for iOS a must.

It seems “unwise” for a developer to turn to just one or another platform.

Guilherme Silveira Talks Swift and iOS – From Scratch to Coding Like a Pro

| Mobile & IOT| 478 views | 0 Comments
About The Author
- Editor of Voxxed.com, focusing on all things Java, JVM, cloud-y, methodical, future-fantastic, and everything in between. Got a piece of news, article or tutorial you'd like to share with your fellow Voxxians? Drop us a line at info@voxxed.com

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>