Day 66-70

Project Week + Graduation

This is the first stack where I had a full week to work on stack's project. My project's function is to be able to have a workout log, where you can customize each workout from a list of exercises where you can add/delete/edit each exercise. These workouts would then go to a log where, for every workout, a time would be displayed to show when you did these workouts.

This blog entry is going to be my entire project week wrapped up in one. I decided to do this project alone since I feel that I would learn more if I just did it by myself. 

My idea going into this was to use core data. However, there were a lot of hiccups when it came to using it since I've never used it before. I went through the learning platform's chapter on it. Core data is a database within each iPhone. It's structure is liteSQL. I haven't worked with a SQL database since my first stack so it took some adjustment. The first problem I ran into was the one to many relationships: I realized my entity structures weren't correct. I wanted to link my list of exercises to each individual workout. But what I needed to do was to create an exercise table that contains all the exercises but IS NOT connected to any other tables. 

After using MongoDB, I was blessed to have the ability to write arrays as a data type in my rows. Now, back to core data, I have to create another entity to just hold these many exercises. Cool, got that figured out. But the next problem was how to correctly link each exercise to a workout. My UI design is now at fault, since I haven't created a workout first before trying to add my exercises to said workout. What happened was a bunch of unwrapping nil errors. 

This issue took me a day to overcome because I was too stubborn with how I was approaching it, thinking up and failing with 5 different solutions. Eventually I had to go about it in a different way and I realized that I had to first add the workout and the workout exercises has to come later.

By the end of the week, I had the ability to customize prototype table views, add/delete/edit exercises, add/edit/delete workouts and ability to add exercises to each of their own workouts and almost had the ability to add these workouts to the log. Unfortunately, I couldn't fetch properly the data. So all my workout log had was just the title. This is a project that I'm going to keep working on because I'm passionate about fitness but it's also a good way to keep my Swift knowledge intact.

Annnnd....THAT'S IT! I graduated! I graduated as a double black belt student and it feels weird to be done but so exciting. For some people, it's a big weight of their back but honestly I feel like the pressure is still on until you find a job. Cause one, as a dev, you're never done learning, and two, you have to do all the linkedin and resume stuff to start applying for jobs on top of learning more CS.

My next blog will be a review of the bootcamp and my future plans.

Day 65

iOS Black Belt

Today is finally here! Time to get my last black belt. The test wasn't that bad as the materials on it are all things that we've done before. Now, my app didn't work completely the way it should have, instead I did some front-end manipulation to create a similar effect. Now I won't say too much about the test but after working with sockets, core motion, core location and kind of AV foundations, the black belt wasn't as bad as I thought. Although a big hamstring that happened was when you delete a reference to an outlet on your view controller but not in your story board..which led to an hour wasted on googling the answer and only realizing this is the error they warned you in the very beginning. 

The grading was instant and I boom, I got my last black belt!

Day 64

AVFoundations

Last day of Hackathons. honestly, I'm pretty burnt out learning so quickly the new technologies we have the past week. AV Foundations is the library for all video audio and camera capabilities that an iPhone has. Unfortunately there are no solid tutorial online as a lot of them are written in objective-C. Mental note to myself: learn how to read obj-C so I can learn more Swift related projects. I found a tutorial that has me import 2 different libraries and the only thing I got done was having an app that accesses my phone's camera. After that, saving photos/videos don't work because I didn't write in the code where I want to save. This was annoying since you'd think there would be a default storage location but there isn't.

I decided to prepare for my black belt instead. So this blog entry isn't as exciting as it should be. Although if I do think of a cool app to make with this library, I will do so in the future.

Day 63

Core Motion and SpriteKits

Onto the third straight day of Hackathons, we are using Core Motion (using iPhone's gyroscopes and accelerometer). Naturally I thought of making games that requires tilting. To build an app like this, Xcode actually has a game development framework. We first import the Core Motion library as well as the SpriteKit framework. Core Motion allows us to use the accelerometers and gyroscope capabilities of the iPhone. So the first thing David and I did was to write a basic app that tells us the x/y/z coordinate tilt of the phone to make sure we understand how it works.

The next part was utilizing Sprite Kit. Instead of a storyboard for our UI design, we have a .sks file that's a scene for the game. We just added a picture of an asteroid and a built in object of a spaceship. The project design is whatever data we get from the Core Motion, we want to affect our game scene. Core motion is utilized by instantiating a motion manager class. We first got to move the spaceship around in the directions that we wanted via accelerometers. Now the second part is messing around with the velocity of our spaceship. 

Once we go the physics and movement of our spaceship down, we created asteroids. At this point, we don't know what the objective of our game is, we just wanted to see how to make stuff. Now, we would populate asteroids and give them a random direction and velocity. Now, we need a collision detector function that would detect collisions and alter the velocity and direction of both the spaceship and asteroid. The cool thing about this is that there are already methods to do this for you via contactTestBitMask. That function tests for if two bodies enter a shared space and run the logics of what angles and speed the two objects will have.

Day 62

Core Location

I think one of benefits of learning the different core libraries of the iPhone is really cool, but also super frustrating. The learning platform has no chapters on core location so we do what every software engineers do...we google. Core location actually isn't that bad; there are a lot of tutorials online for using it. Import MapKit to the view controllers to be able to use all the different methods and attributes. I partnered up with Maric and we wanted to do something like FireChat. FireChat is a group messaging app that is uses bluetooth rather than cell data. Our idea was to create a map app that can ping other individual coordinates so if you're at a large concert or venue that has limited connectivity, there would be a way to find each other.

The first day we spent just messing around with how to use MapKit and figured how to zoom upon our phone's location. Maric found a beacon library that uses cell data to see how close a phone is with another phone but we scratched the idea cause we wanted something that didn't use cell data. Eventually we conceded that cell data is required and our project became just a map that can ping locations of other phones who are connected to the same server.

The set up is simple, creating a server.js file with all the sockets that we need. However, it got a bit tricky when we wanted to send in and pull out data from the phone. Remember how I said Xcode doesn't have Javascript support? Well, Everything in MapKit relies on coordinates so every time we update our location, we have to send our new coordinates to the server (which is easy), however sending it to the other phones got tricky because we couldn't pull the information out of it and it wasn't a JSON object (it was an AnyObject) so instead of adding more features to our project, we could only add annotations of other people's position. Eventually Maric found a way to parse the data that we got from the server via swiftJSON. 

Day 61

Chopsticks Project

Building the project for Chopsticks was pretty cool and David did a lot of heavy lifting. He already finished the front end of project and I supplied the knowledge of sockets and servers (since he didn't take MEAN yet). When you enter a the lobby, it'll prompt for a name. Only when the name is put in will the connection be made. We built a pseudo game lobby by having a tableview with names on the cells and when you click on them, they notify the user to play the game. If clicked yes, both users are going to a game lobby. Once a winner is announced, both users will be sent back to the original app with their socket connection deleted. The app will once again prompt for their name to establish a new socket connection.

This project led me to getting the elusive green belt! With that under wraps, my instructor told us that we will be doing a project every day for the next 3 days using different iOS libraries. The first one we will be using is Core Location. 

Day 60

iOS with Full MEAN

So yesterday we did some basic socket connections. Now, we're moving onto Full MEAN where we are going to use MongoDB. This means we need 4 additional files: mongoose.js file where we connect to our MongoDB. Routes.js to connect to our server side controllers from different HTTP's. Then we need our model file where we create our schemas and finally, our controller where we write our functions to retrieve and send info to the MongoDB.

Again, there really wasn't any issues since I've done it already but the trouble starts when we're getting information from the webserver. All the info in MEAN are in JSON format. Swift is not developed well to handle JSON data, instead preferring to opt to its NSData, NSwhatever data types. Luckily a TA and one of my classmate wrote a parseJSON function that works instead of the wrong one on the learning platform. With all these components, we are able to freely move information to and from a MEAN web server on our iPhone.

Over this weekend, I and David, my classmate will be building a project based on iOS with socket connections.

Day 59

iOS MEAN

Now that we have all the basics of building an iOS app, the instructor told us to mix things up by using sockets. Sockets, as I've explained back in the MEAN section, are little nodes of persistent connection that allows information to flow freely and in real time. Instead of writing Javascript as the front-end, our iOS app is going to be the front end. The server-side is just our server.js where it requires the socket node module. How do we connect our phone to the sockets? We download the sockets.io file from the Apple developer site, and we copy the files into our iOS project folder. 

We then write a connect function and the same socket emits that we would in Javascript. On our server side, we have the socket.on method to hear what we are getting. From then on, we can transmit info via a second parameter in the emit method. The first couple assignments were pretty easy with just transmitting messages from the iPhone to the server and then to the webpage. Tomorrow, we will be using full MEAN.

Day 58

Custom Cells and Multiple Views

Today I finished the iOS Intermediate chapter. We learned this past week about table view cells. What if we want different labels for every single view cells? We then have a custom cell. The only difference is to have a custom cell file (or put it in your view controller with the appropriate class) that contains all the features you have on the view. I also learned today how to segue into other views and why delegates are now so important. 

We can connect two different view controllers via navigation controllers. But there are multiple ways to present new controllers. We do everything modally because this allows us to go back as well as go forward to other controllers whereas if we do just show, we can only move back. There are two things that we need when we move between view controllers: 

1. Protocols that contains delegates
2. Prepare/perform segue functions

We link our button that starts the segue and we write the perform segue method. After which, we have a prepare for segue override function. The prepare segue function is very important because we decide there which view we are going to go to and how, as well as which delegate functions or variables we're passing over into the second view. 

I really struggled with this concept of passing variables and functions through the prepare segue. In the beginning I couldn't connect them but I realized that they must be declared in the second controller.

Day 57

Data Persistence via PLists

So far, every app I've made so far does not have data persistence, meaning that when I close out of the app, everything is reset. The CodingDojo learning platform gives us a way to store data via Plists. This involves creating a database file that uses the plist as well as another file that contains a program to encode and decode data(because things stored in plists have to be in UTF-8 unicode). Honestly, I don't really like this method, it's very clunky with the encoding and decoding and I don't know what is actually in my database if I were to put in something wrong.

I also learned about table views, a very common aspect of a lot of iOS apps. Going back to protocols and delegates, when we use table views, we either let our controller be the UITableViewController or if you were using a view controller with a table in it, then use UITableView. This is required to let the controller recognize that there is a table but also a good (or bad) thing about writing in Xcode is that, every time you implement a UI class, it already is a protocol. Meaning that whatever code you put into that class, has to conform. A cool function is to alt-click anything in your code and there will be documentation on what is required for that particular class. For tableview, there must be a function that returns how many rows there are and another function of what is going to be displayed in each row cells.

Day 56

Tipster and MVC

Over the weekend I finished tipster, an assignment where we make use of a slider UI slider to determine tip % where when you enter a value, the tip amount will change automatically when sliding the slider. A big annoyance that I dealt with was how the labels in the storyboard is laid out so that it will always do a ".." if the number is too big for the label dimension and how hard it was to change it. When it's all said and done, my code was pretty long so there is a lot of refactoring to be done. And as if the help me with this, today I learned about iOS MVC. I haven't talked about MVC's in a while, with my last post about it being all the way back in the MEAN stack but iOS apparently also has an MVC structure.

With Tipster and Tic Tac Toe, I put a lot of my logic in the models file since the view controller should be only be receiving and sending information to and from the view. iOS development is a lot more free-form with MVC, since you don't necessarily have to have a models file. This helps with the structure but one thing I realized when I tried implementing the style is passing data to and from the view controller and the data file. This can be fixed with writing functions in the model that takes in parameters and having the controllers call that function and pass in whatever values. Anyways, gonna be working on data persistence next!

Day 55

Tic Tac Toe and iOS MVC

So far, I've been writing a lot of basic iOS apps that uses only one button. On the storyboard, you can drag buttons (clickable objects) and labels (basic text) onto your view controllers so you can program what is being displayed or what happens when a certain button is clicked. My basic apps have just been changing colors/fonts or changing texts when buttons are pressed such as the Ninja Gold (which is tradition by now). Now today's assignment is Tic Tac Toe where there is a bit more logic. The first thing that I thought of was how to differentiate the buttons being clicked (as there 9 on the storyboard). There is a .tag attribute that can help with this, as I changed the sender tag of the 9 buttons from 1 to 9. 

I linked all the buttons to a UIButton action outlet, with the tags being the only difference. Now, how do I determine a winner? I wrote all the possible ways of winning and I used sets to ID winners. For example, after every button clicked, each player has a 'moves array' that will take in that tag, and I wrote out all possible winning moves (8) and changed the arrays to sets so that I can check for if the players move array contains a winning combo. Anyways, one of the things I learned doing this assignment is definitely how much (and sometimes how little) an object from the storyboard has.

This weekend I'm planning on getting ahead on the assignments and learning about iOS MVCs.

Day 54

Auto Layout Troubles

I think for many design fanatics, it's really fun to develop iOS apps because the Apple philosophy of building apps is UI first. What that means is the storyboard (the page that you build the visual aspect of your app on) is a really important part of the app development cycle. Things you put on there will be outlets or outlet action that will perform the code written or display the results of certain functions. Apple does a really good job making everything look nice and with the measurements laid out in front of you so you can get all the buttons or labels to align well each other. However, a big downside is that the box that is the playground for your app is not representative of what is going to be displayed on your phone.

Here comes auto layout where we have constraints that act as margins from HTML-CSS. This is where things are not intuitive. Constraints have to be on most parts of the objects you put on the storyboard and they all have to relate to each other, otherwise it would load the frames like you think they would. It's hard to explain without pictures but trust me, it was very frustrating to get over the hump when you first learn it because without having a proper storyboard, there's no point in how much code you write in the view controllers.

Day 53

Advanced Swift and iOS Intro

Two really important things learned today: protocols and delegates. Protocols define a blueprint of methods and properties that required for a certain functionality. These are behaviors that are expected but not implemented. Delegates are structs/classes that follow a certain protocol and passes off one of its functions to another instance for that instance to run. Protocols and delegates are really important in the MVC scheme of making an app. Imagine you are using an app that has multiple views or pages. You click on a navbar button to go to a certain area of the app and you have the ability to go back. How do all these things happen? Delegations and by extension protocols. Delegation requires protocols to work, and delegation allows for passing of information in-between as well as going to and from different controllers. I think to a typical reader who hasn't done a lot of OOP, it might be confusing but in terms of app development, it is highly relevant.

Day 52

Intermediate Swift and SwiftySinglyLists

One of the annoying things about Swift coming from Javascript is how safely your code has to be in Swift for it to be executed. For example, Swift brings up a new idea of optionals. In Swift, nil or null is a very bad thing. Optionals help with that: when you declare a variable as an optional (by having a '?' sign) you're stating that "hey, there might be a value for this variable but there might not be". This allows the program to run knowing that if nothing is in it, it will be ok because the variable expects that result. The annoying part is that when you have an optional..you can't really do anything with it. You have to unwrap it by declaring, which will return it back to whatever type it is supposed to be.

New things that I learned were structs and enumerations. Enumerations are data types with its values being related in some way. Think of a dropdown list of items. Structs are another data types that holds attributes. The most important distinction with structs and enum are that, when used, a copy of the data is being manipulated instead of the actual data. Structs are primarily used for things that are not too complicated and its attributes will not be changed. For all other data type manipulation, use class.

The assignments today were pretty hard to follow since we re-did the Singly Linked Lists in Swift. I'm not too well-versed in SLL's yet and although I can follow the code and what everything is doing, I have a hard time writing the correct code for the assignments.

Day 51

First Day of iOS!

iOS is primarily written in Swift 2.0, the new standard programming language of Apple. Swift, like Java is very strongly-typed, meaning there are very little room for interpretations, as every single variable and function and returns must be explicitly stated what type these data will come in and out as. It was cool to write in an internal environment like Xcode as it reminds of jGrasp but much more appealing on the eyes. I spent the day finishing up the rest of the Intro to Swift chapter which is more or less algorithm problems to help us write in Swift.

By the end of the day, I went on to the Intermediate Swift chapter and learned about closures. Functions are closures with a name. Closures are bits of code that can be executed or invoked. They can be passed through as an argument as well as be used as a return. Now, I'm not gonna lie, the learning platform is not a great resource for closure as I instead read the Swift documentation on closures. We can consider closures as lambdas from Python and Javascript. Remember the underscore library? Closures are useful they are easily passable as arguments in higher-order functions (functions with more than one argument).

Anyways, uneventful first day. We'll see what tomorrow brings.