It has been interesting to see how the curriculum has unfolded during the 100 Days of Swift Challenge. The first 12 days consisted of short videos that introduced foundational elements of the language followed by quizzes that tested comprehension of the material and also providing a good learning experience of paying close attention to detail to catch typos or small trivial errors that always seem to catch us when we are writing code.
The second learning method introduced was around consolidation days where concepts were reviewed but we were given additional information or detail that now make sense after we have greater context of when things could or should be used. This reinforced the foundational knowledge that we have gained and built confidence before going into more complex areas.
Now we are nearing the completion of the third learning technique – building projects. In the project phase Paul Hudson again provided three different types of projects to reinforce what we are learning – app, game, and technique.
The “app” is normally creating some type of app that can be run on the device. This means working with view controllers, classes, structures, methods and the other foundational pieces in our ever-expanding arsenal. This is where the student can gain confidence in how the pieces fit together to make something that actually runs either in the simulator or on your phone or tablet. In this case the first project was creating an app that would allow the user to view images of storms on their device.
The “game” project took what we learned in the first project but then changes the boundaries to make you think in terms of user experience and within the construct of helping the user achieve some goal. In our case this second project was a quiz game where a user tried to guess a national flag correctly from three choices. The underlying code between Project 1 and Project 2 was not that different but how we manipulated it and what design criteria we used to develop the app flow was different reinforcing how skills could be used in either endeavor.
Now we move to the third project type, “technique”. In this case we are diving deeper into a specific area to enhance the usability of the application. For this particular project we revisited the Storm Viewer application we created in Project 1 and added the functionality to share the image.
This particular project was fascinating. Apple when they build the ecosystem for their phones has provided hooks to share data between applications or between users. That in and of itself is valuable and provides developers with a consistent hook to provide a more seamless user experience regardless of the app you are using.
The consistency alone is a time saver to developers but as the telemarketers like to say, “that’s not all!” Using the UIActivityViewController built into Swift gives us a mechanism for sharing data from the application. In other languages it was normally left to the developer to account for how to share data depending on what kind of data it was you were trying to share. For example, you may share text much differently than an image which in turn could be different than how you would share a video or some other binary data.
iOS developers have some help here. The operating system and the language constructs have pre-defined ways of dealing with data types freeing us up from having to worry less about what the data is and give us more time to worry about how we present the data to be shared within our application parameters.
In the case of our Storm Viewer application, we are dealing with images. When we tell iOS that is the data type we are sharing we automatically get the appropriate sharing mechanisms such as saving to Photos, sending in an email, or displaying the image via AirPlay to an external device such as an AppleTV. It took roughly six lines of code to include in our Project 1 application and we added the functionality to share storm images. That is pretty impressive.
0 Comments