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.