12 Weeks as a iOS Developer Intern — Week Three
I took a deep dive into “Advanced Swift” by Chris Eidhof, “RxSwift” by the Ray Wenderlich team and got to work on my first big app screen.
Advanced Swift gave me a better idea of how the Swift language worked.
For example, the reason you can iterate through arrays and dictionaries is not because they are arrays and dictionaries. Arrays and dictionaries can be iterated through because arrays and dictionaries conform to the Sequence protocol.
Sequence — a series of values of the same type that lets you iterate over the values
- most common way to traverse a sequence is a for loop
- to conform to sequence protocol, provide a makeIterator() method that returns an iterator
In order to conform to the sequence protocol, a makeIterator method that returns an iterator must be implemented.
Iterator — produces values of the sequence one at a time and keeps track of its iteration state as it traverses through the sequence (for loop)
Of course an iterator must conform to the iterator protocol.
RxSwift
While reading RxSwift, I realized some of the definitions of Observables were written out in the README.MD of the project I’m working on. Moral of the story, always read the README file!
Reading the documentation and README.MD is especially important when being on-boarded to a large project because it really helped me get a sense of where everything was, and what was in the project. The keyboard shortcut cmd + click for jump to definition was invaluable. If you haven’t set up Xcode with that shortcut yet, here’s a link on how to do it :
I have more notes on RxSwift that I’ll probably make a separate post about but here are a few things for now that I noted about RxSwift:
Observables — just a sequence that is async
- referred interchangeably to as “observable”, “observable sequence”, “sequence”, occasionally “stream”( They all mean the same thing!)
- Observable<T> class produces a sequence that “carries” a snapshot of data T
- ObservableType protocol can emit/receive only 3 types of events, does not assume anything about Observable or Observer
*(Event sequences is why delegates/closures are not needed for classes to talk to each other)
Three types of events:
- A next event (latest value, this is how observers receive values)
- A completed event (when the Observable has completed it’s life cycle successfully, no more events are emitted)
- An error event (Observable terminates with error and will not emit other events)
My First Big App Screen
This week I got to work on an app screen that was much more complicated than the screens I had previously worked on. There were quite a few interesting things that I learned.
Let’s set the stage, a bunch of UIViews inside of a content view, inside of a scrollView :D
- Tap gesture recognizers in a UIView inside of a content view, inside of a scrollView never fire because the scrollView does not communicate to the UIView when a user taps the UIView.
- In order to do something when a user tapped the UIView, I created a UIButton the same size as the UIView and set the color to .clear so it would not be apparent.
- I then set the UIButton action to push to another screen.
- Please share below if you know of a more elegant way to do this~
***edit, this is how you make the tap gesture recognizer work
2. In order for a scrollView to scroll properly, the contentView that holds all the UIViews must be bigger than the scrollView.
- All the UIViews inside of the contentView must have a top, leading, trailing and inherent height constraints
- The bottom UIView inside of the contentView must have a bottom constraint.
- Make sure the topmost UIView in the contentView is pinned to the contentView’s top safeAreaLayoutConstraint and NOT the outermost View’s top safeAreaLayoutConstraint. If the topmost UIView is pinned to the outermost View’s top safeAreaLayoutConstraint, the scrollView will not scroll at all. This had me confounded for quite a bit until a senior iOS engineer helped me in the process of debugging this issue. Thanks Eric!
I also received very helpful, actionable feedback from my manager this week about the areas I’m doing well on, as well as areas in that could be improved on, along with how I could improve.
The how part is especially important because thats what made the feedback actionable. One of the parts that I worked on this week was the reading documentation part. I realized the second week that I had not read through the documentation very thoroughly which made building some screens quite challenging because I wasn’t sure of all the kinds of data in the app.
Quote of the week:
There is always a solution. — Daniel D.
This quote is what I remembered every time I encountered a bug. Before Daniel (iOS Engineer) had said this to me, I would just feel blocked.
He’s right though, there’s always a solution. Usually more than one.
There’s always a light at the end of the tunnel.
Looking forward to what week four brings!
Read about week two as an iOS developer intern here
Show your support with 👏 claps below, follow me on my iOS developer journey 😊 on Twitter
