0 Comments
Check out my tutorial on "How to read iOS Documentation". Everyone in class: "Teacher? Question: How do I do this and that and this? I can't figure it out!" This happens usually several times during the day. "Read the documentation". "It' explained in the documentation!". And then everyone starts pulling out their hairs in frustration, because HOW do you read the f****** documentation?
In the beginning it very hard to figure out how to use the documentation correctly to actually figure out what you need to do to in order to make "things" happen in your app. It is written in English, but it might as well have been written by Klingons. So therefore you end up using sites such as StackOverflow a lot search for solution. Which can help sometimes, but in the end, knowing how to read the documentation will get you a lot further! So this tutorial is my approach to reading and using the iOS Documentation. I am not saying this is the right way, the best way or the smartest way. It' just my way to make sense of the Documentation. We are not aiming to learn people how to code, but to get people interested in learning how to code. We went back to the drawing board with the new concept we agreed on with Martijn. After some thinking and drawing we came up with the prototype you see below. You can also test it out with Marvel with this link. There are apps like Swifty and SwiftBites that does similar things, but we think our approach will be a bit different. We are not aiming to learn people how to code, but to get people interested in learning how to code. To do this we will make fun and interactive tutorials that will give everyone a taste of how it is to code, and most importantly, the feel of achievement when you see something you made appear on the screen of your iPhone.
After we had finished our user-stories and prototype we started designing the user interface of the app. We skipped some important steps here that should be part of any app development, such as making wireframes, thinking about the user flow and more, but since we only have 5 weeks to complete this project we cut a few corners. Here is the design we came up with today, and we are quite happy with it so far. It incorporates the design elements of The App Academy, while at the same time it gives a fun and playful feel to it. You can also try out the prototype at Marvel with this link. What do you think? Make a coding quiz for people who are interested in coding. Let them test their knowledge, gain more knowledge and hopefully get them interested in further developing their coding skills This week we started our new and final project here at The App Academy. This will last for 5 weeks and we now have to work with a Product Owner that has an idea for an app he or she wants to build. We have three team and three totally different projects. I am working with Willy again, which I am very happy with. Our Product Owner is Mr. App Academy himself, Martijn Wuite. His idea was: make a coding quiz for people who are interested in coding. Let them test their knowledge, gain more knowledge and hopefully get them interested in further developing their coding skills. We used most of Tuesday for brainstorming. Which features does the app need, how should the quiz games be, would people compete against eachother, which backend would we use etc. Of course PostIts are mandatory for this type of brainstorming. In the end we had a good idea of what type of app Martijn was looking for, so on Wednesday we started sketching some rough prototype sketches. These helped us think about the flow of the app, which information should be visible and which type of screens we need. We, and by we I mean Willy because I can't draw, sketched the screens and then used a prototyping app called Marvel to easily try out the app we had thought of. You can see the result with this link. After we made the prototype we went to our Product Owner to discuss what we had made and our thoughts about the app. Although we liked the Quiz concept we had made we also felt like this would not serve the ultimate goal of the app that Martijn is looking for: to get more people interested in coding.
Me and Willy had come up with another concept as well that we pitched to Martijn. We called it the Code Challenge, and it involved the user to finish short snippets of code which then would be visualized once they are done. For example to display a picture. The user would have to fill in blanks in a already half-completed code-snippet. If he or she would get it right, then the picture they chose would be displayed. We felt this provide a much bigger sense of accomplishment than a quiz would, and we think that it is by tapping into THIS feeling that we would get more people interested in coding. Martijn agreed with us and he liked the concept a lot. We learned that even though a Product Owner has a very good idea in his head, it does not always mean that that is the best or the only idea that will ultimately get him to his end-goal. So communication with the Product Owner is very important in projects like this. Which is why Agile and Scrum is so often used in the software industry. So then it was back to the drawing board for me and Willy with a new concept to work out. Below is the Code Challenge concept we showed to Martijn. We finished our first app this week! The SoDutch App!! Me and Willy are really happy about the app. We managed to complete all the requirements and also to add some extra features we like. It is really satisfying to finally have made something that works, that is not from a tutorial or from a book. This was our idea and we made it! (not on the AppStore as this is a small project, but hopefully soon) "Of course you made a SoDutch app!" - my friends (Yes I know I need to charge my phone.....)
We only had two weeks to finish it, so its not the most advanced or beautiful app in the world, but hey, we are quite proud of it! Now we have one week of review, then we start a new project that will last for 5 weeks. Excited to figure out what the projects will be. Check out the SoDtuch app here - or just click on the Portfolio above in the menu. Today we started our first project - where we will build our own first app. I am teamed up with Willy and we since we are both expats in The Netherlands we chose to build an app that focuses on the Dutch - particularly on "What makes the Dutch so Dutch?".
In the app we have to incorporate these features:
Shouldn't be too difficult right? Let's see. Here we go! Btw, think we already have a good name for the app: SoDutch! During class we are using a lot of tutorials to help us learn how to code. These are both from the two books we are using (The Big Nerd Ranch) and from internet.
One excellent resource for iOS tutorials (and others) are Ray Wenderlich. There are many tutorials here that explain easily what you should do and what is happening. If you want to have a start to look into iOS programming, or if you are already programming, this is a very good website to check out! Week 2 of the iOS Bootcamp has moved on to iOS programming. In the first week we learned the basics of Swift, and this week we have gotten to use that in practise. We have moved on to the iOS Programming book from The Big Nerd Ranch (https://www.bignerdranch.com/we-write/ios-programming/) and we finally get to write code that will show up on our iPhones. The solution is in the code - Jero (class mate) We have been making lists, deleting and editing entries in lists and displaying maps and web sites. The challenges at the end of each chapter can be quite challenging (hence the word), but everyone gets to the end eventually, which is great to see.
We are working towards a 2 week project where we know we will at least make use of tables, maps and the camera. If you are reading this then you are probably among one of the many who have gotten at least one or two grey hairs from trying to understand Closures in Swift, myself included. So here goes, lets try to make Closures understandable. One thing to remember before we start: every function is a closure. But not every closure is a function. I´ll get back to this a bit later. func printNestedFunction(param1: String, param2: String) -> String { There are three type of closures; First you have Global functions – they have a function name and cannot capture any values. An example of a global function is like this: func printGlobalFunction() { print(“Hello from the other side”) } printGlobalFunction() Here the func denotes that is it a function. The printHello is the function name. There are no parameters passed into the function, hence the empty ( ). There are no return parameters and the function body is everything that is between the curly brackets { }. Second, there are Nested functions – they have a function name and can capture values from their enclosing functions. Nested function have function inside the bodies of other functions. func printNestedFunction(param1: String, param2: String) -> String { return "I must have \(param1) a \(param2) times” } printNestedFunction(“called”, "1000") The parameters within the brackets , param1: String and param2: Int, are passed into the function to be used. The return type is denoted by the -> sign, and our return type is this time a String. One thing that is special with nested functions and closured is that they can return a function as a type. That would look something like this: func myNestedFunction() -> (String, String) -> () { func apologyToYou(apology: String, forWhat: String ) { print(“To tell you I´m \(param1), for \(param2)”) } return apologyToYou } let apology = myNestedFunction() apology(“sorry”, forWhat: “everything that I´ve done”) Closure expressions – they don’t have a name and can capture values from their context. This is a way of writing function-like expressions without a full declaration and name. Simply put, its a way to write very short and concise pieces of code. The closures are wrapped in a pair of curly brackets { }, and that is the reason I mentioned earlier that all functions are closures, but not all closures are functions. If you look at the functions above, these also have function bodies within a pair of curly brackets. So technically all of them are closures. But the difference is that with closure expressions is that closure expression is a very simplified and short code. Here is how the syntax is set up for closure expressions: { (parameters) -> return type in statements } An example would be like this: var neverHome = { () -> String in return “But when I call you never seem to be home" } Here the () -> String defines the function type followed by a in keyword that defines the body of the closure. It is also possible to further shorten these expressions, called shorthand syntax, and there are some higher-order functions that are very useful, such as map(), filter() and sort(), but that will be for another time. But I will give you an example of how much you can shorten a code expression by using shorthand, just as a teaser: From: [1, 2, 3].map( { (i: Int) ->Int in return i * 2 } ) To: [1, 2, 3].map { $0 * 2 } This is a very short, but hopefully easy explanation about Closures in Swift. There are a ton of website that I would recommend you to read in order to get a better grip on Closures. I will list a few below:
http://airspeedvelocity.net/2014/06/11/a-basic-tutorial-on-functions-and-closures-in-swift/ https://www.weheartswift.com/closures/ http://code.tutsplus.com/tutorials/swift-from-scratch-closures--cms-23138 Its a new year and its full of new opportunities for everyone. My recent challenge is the iOS BootCamp at The App Academy here in Amsterdam. 12 weeks of learning iOS and Swift development. Its hopefully the start of a new career and a new life. I am quite excited to start. I will try to update this blog as much as possible to keep you in the loop about how it is.
Some thoughts on the first day is of course necessary. We are a group of 7 people, each with very different backgrounds. Marketing, journalism, translator and more. It seems like a good and diverse group and it will be interesting to see how each will do with the challenges ahead. I am one of the few with some previous experience with programming. The days are from 9 till 6, with homework in the evening and weekends. They don't call it a bootcamp for nothing! But then that is also why we pay for this right? The teachers and helpers also seems very good, so I am really looking forward to the next coming 12 weeks. Let's start! |
Archives
April 2016
Categories
All
|