DJ Chung: Always Learning

My First Fork: facebook-ios-sdk

Wed, 27 Feb 2013 14:27:12 -0500

Recently, I’ve been making a more concerted effort to contribute to open source software. As someone who recently picked up programming, besides my friends, OSS has been my best teacher. I can’t tell you how many tutorials I’ve gone through, how many hours I’ve spent on StackOverflow or how many libraries I’ve used on my own projects I found on Github.

On to my first fork. My friend Jordan and I were talking about OSS and even though I’ve open sourced some of my own software, I’ve never contributed to a project. I told him I didn’t even know where to start, or even how to do it. So we just searched “iOS” on Github and facebook’s sdk popped up. Jordan suggested contributing to facebook’s iOS sdk. My response was, “How the hell can I contrib…wait.”

I had been playing around with the sdk last week and I had extended one of their samples - Facebook gives you some great examples and very detailed installation instructions on their developer site. I wanted to include a search feature for FriendPickerSample, a way to list all of your Facebook friends and select them to be used for invites, tagging, etc. Interestingly enough, Facebook gives you a tutorial just for that. However, I wanted instant search, I wanted the search to update every time I typed in a letter. So I built it. It was actually very little code, I just had to implement one UISearchBarDelegate method and it worked!

I told Jordan about this and he thought this would be a good feature to add to the FriendPickerSample. I was a little hesitant because I was intimidated by the thought of trying to contribute to Facebook’s sdk. Jordan suggested I email the maintainer and ask if he’d be open to this contribution, “they’re people too.” So I emailed onebit about the feature and asked what his thoughts were - just a shot in the dark. Then, an hour later, I got a reply! It was probably the best email I could have received in that situation. He thought that the feature was “Cool!” and that it “sounds like an improvement.” He was very supportive and of course, he couldn’t promise that the change would be accepted, but encouraged me to fork the repo and submit a pull request.

I had never forked a repo in my life. It’s not hard at all, but I just had never done it and I didn’t know what the etiquette was for submitting a pull request. With Jordan’s help, I forked the repo, added my feature and submitted a pull request. My first fork and pull request!

The combination of contributing to such a widely used sdk, onebits’ response and my first time contributing to another project was a rush. It felt like a blur, but I did learn a few things. Jordan advised me to look at how Facebook’s commit messages were structured so that I could format mine accordingly. This will help the maintainer easily understand what’s going on. But I think the biggest lesson I learned was through a fear that I overcame.

“They’re people too.”

Jordan’s comment resonated with me. I was really intimidated by the thought of trying to add to Facebook’s sdk and emailing onebit. I haven’t even been programming that long, who am I to do even try? My own insecurities about my programming skills were hindering me from even trying. But Jordan’s encouragement and onebit’s friendly response made me realize that I’ve got nothing to lose. Maybe my pull request won’t get accepted, maybe my code really isn’t all that great and maybe I didn’t do something correctly, but I did something I had never done before and took one more step forward in my programming journey. That’s what matters. I know I have areas to work on as programmer, but I’m learning and there’s no reason for my own insecurities to stop me from trying something out of my comfort zone. With respect to my programming skills, I try to remind myself, it’s not where you are now, but where you are going.

Notes:

onebit was gracious enough to suggest that I email him with the pull request so that he’d be able to look at it easily. I emailed him and though I haven’t yet received a response, I’m looking forward to his feedback.

About the pull request, it’s more than just a few lines of code than I mentioned. This is because in FriendPickerSample, the search bar isn’t set up, so I had to include that per the howto I linked above. Also, I made the code iOS 4.x compatible so I couldn’t take advantage of new methods available for iOS 5+, which added to the lines of code.

There are so many great, free resources about programming, there are virtually no barriers if you own a computer and have internet access. It is truly the perfect time to learn how to code - just watch this video from Code.org if you need any more convincing. In my pursuit of programming, I have stood on the shoulders of giants and it motivates me to contribute. I think the computer science community is as close to a real life antithesis of the Tragedy of the Commons as any.

Three Pieces of Advice for Learning Algorithms for the First Time

Fri, 15 Feb 2013 14:06:00 -0500

I just completed my first programming assignment for my Algorithms course through Coursera - if you’re looking to continue or supplement your education, I highly recommend Coursera, I’ve been impressed with the quality of content and breadth of their course offerings.

Anyway, here are three pieces of advice if you’re trying to learn algorithms for the first time like me.

1. Take a minute to stop and think

I know this sounds dumb and obvious, but since I’ve been out of a school setting for about four years, I’m used to just doing instead of taking a step back and deliberately planning out my next steps. Half the battle in solving a problem with algorithms is understanding the question. If you read a question and immediately race to your text editor to code up a solution, chances are, you don’t fully grasp the question. More often than not, this leads to seemingly endless hours down a rabbit hole and trying to brute force your way to solve a problem. These sorts of technical questions usually have nuances to them and these nuances are hints to solving the question. If you miss those hints, you’re headed down the wrong path.

2. Don’t code, talk and write

Once you understand the problem, talk it out. Talking out the problem helps me be very explicit about my approach. If I start talking out my steps and get to a point where I can’t even explain where to go myself, then I know I’ve reached a dead end. Also, if you can, talk to another person, if someone isn’t available, talk to yourself. I’ve found that when I think to myself, I make connections or assumptions that glaze over details.

When I was first trying to implement the merge sort algorithm, I had a little trouble wrapping my head around recursion. I went to my roommate, Moses, and he was gracious enough to talk it out with me for about half an hour. We stepped through the call stack, wrote out examples and talked out different ways to view the algorithm. This was a huge help. I then wrote pseudo code of what we discussed and this helped cement what I had just learned.

A good test to figure out if you actually understand something is if you can explain it out loud or write it down on a piece of paper. So before you start coding a solution, talk it out and write some pseudo code. You’ll know if you have the solution if you can do these two things. Writing the code is the last step, the hard work of actually solving the problem is already done.

3. Don’t plug and chug

When you actually get to coding the solution, check yourself that you don’t get to the point where you’re plugging and chugging, haphazardly coding in hopes of stumbling upon the solution. In the best case scenario, you’ll use your pseudo code and it will flawlessly transfer to actual code, but this rarely happens, if ever. You’ll run into snags. When you do, repeat steps one and two. Take a step back, talk and write it out. This will save time in the long run, trust me.

I fell victim of plugging and chugging when I was solving the inversion count problem (the first programming question of Coursera’s Algorithm class). I knew I had 95% of the problem figured out, but for some reason my counter was always wrong at the very last level of recursion. I printed out the counts at each iteration and everything was as expected except for the very last. Seeing the finish line, I just tried to change a few things here and there in hopes of figuring it out, I was programming by coincidence. I lost hours to this futile approach. I thought I’d be able to quickly figure it out by trying a few random pieces of logic here and there instead of taking a minute and deliberately thinking about the problem. It wasn’t until I stepped away from the code and talked out potential reasons why the counter screwed up at the last minute that I figured out what was wrong.

What was wrong? One line of code. On an edge case, I mistakenly added to the counter items I had already accounted for. Once I deleted that line, my code solved the problem.

Interestingly enough, these three thoughts all apply to programming in general. When I first started to learn how to program, I thought it was all about writing code. Yes, that’s a big part of it, but code itself is a tool. Programming and computer science is more about a way of thinking and an to approach to solving a problem. I’d argue that real programming is the process leading up to actually writing a line of code.

Horizontal Navigation of View Controllers

Thu, 07 Feb 2013 19:48:00 -0500

Horizontal navigation in iOS is an intuitive way to page through content, especially on a smaller screen, like the iPhone. There are some great apps out there that use it, like Groupon and Gilt.

These apps do a great job of showing lots of great content seemingly all at once. The swipe gesture gives the user a quick and easy feeling of scanning through information. Then, once the user finds something she’s interested in, she can drill down by interacting with the view displayed on the screen. This sort of navigation works great for Groupon and Gilt because their content can be categorized and each category has more granular details.

I first implemented horizontal navigation when I was building PictureMenu. When I was doing some research, I came across Apple’s example that used horizontal navigation, PageControl. Basically, you create a container view controller with a scrollview and you add your page controllers’ views to the scrollview.

PageControl had the navigation part down, but its pages were static view controllers and I needed to be able to implement functionalities like launching an action sheet, taking photos and pushing new view controllers.

Most of these functionalities work just fine with the PageControl example, but there are a few functions that don’t. One specific instance is when you’re presenting an UIImagePickerController. You may want to present this be sending a message to whatever page view controller you’re currently in and while that does present the picker, it will cut off the top portion of the picker since your controller’s view is a subview of the container’s view. This means your container view controller must present the picker so that the picker can use the entire screen. So, I created a property that is a container view controller type in the page controller that uses the picker and set it as the original container view controller. I then use this property to present and dismiss the picker.

Presenting from page view controller:

Results in the top portion of the camera view cut off (notice the Auto button):

Compare to presenting from the container view controller property of the page view controller:

Results in using the full view:

If you’re looking to use horizontal navigation and want to each page to have its own functionality, check out my implementation, DJHorizontalNav and let me know what you think!

To Learn How to Program, It Has To Fulfill A Need

Wed, 09 Jan 2013 13:03:40 -0500

One response from my last post about how learning to program changed the way I think was the following:

Have fallen off the “learn to program band-wagon” many times myself, maybe due to me setting unrealistic goals for myself or learning the wrong way. Could you walk us through how you disciplined your self to stay focused and concentrate on learning how to program?

This is a great question. I have fallen off the “learn to program band wagon” a few times as well. What was the difference this time? Necessity.

When I committed myself to learn iOS, I had recently shut down an online business I was running and was living off savings. If I couldn’t learn how to program, learn how to acquire freelance clients and learn how to execute projects, I’d run out of money and would have had to move on to plan B. I didn’t have a plan B. In my mind, I had to make this work.

This may seem dramatic and reckless, but trust me when I say that it was a calculated risk. First of all, I had enough savings to last me six months (living frugally). Second, I knew there was a big upside to learning iOS given the market demand, especially where I live, San Francisco. Third, one of my good friends, Steve, had already done exactly what I was trying to do and was a huge help - I was/am in the perfect environment (here’s my post about my environment). In my mind, the success of this new adventure was dependent on my execution. It’s the type of calculated risk I will (hopefully) take 100% of the time. I will always take a chance on myself. If you don’t believe in yourself, who will? Also, I knew the worst case scenario was that I’d have to find something else to do and I knew I would at least pick up a new skill.

I’m not suggesting that you have to put all of your eggs in the programming basket to stick with it, but rather that programming has to fulfill a need.

Do you need to learn how to program to make a living?

Do you need to learn how to program to solve a math problem?

Do you need to learn how to program to build a fun website you’ve been thinking about?

There are varying degrees of “need” and it’s different for everyone, but my guess is that the stronger the need, the more pain, frustration and punches you’re willing to take on the never ending journey of learning how to program.

My experience with learning for the sake of learning has been miserable. When I first tried to learn how to program, I started because my close friends were programmers - I just wanted to be in the club. I did every tutorial out there on Python/Django and Ruby on Rails. They were helpful in getting a basic understanding, but I never really made much progress beyond the tutorials and fell off within a few weeks. I just didn’t really need it.

This may be a topic for another post, but when you’re actually going through the process of learning how to program, once you’ve done a few tutorials and have a basic grasp of fundamental concepts, you need a project. You have to try to build something. You have to try to get something out there, whether it’s a silly website for your group of close friends (here’s mine) or a simple app to keep score for bar games (again, here’s mine). Otherwise, you just don’t need to learn how to program.

How Learning to Program Changed the Way I Think

Sun, 06 Jan 2013 18:59:00 -0500

I have been a full time developer (mainly iOS) for one year and it has changed the way I think.

Confidence

When I first started getting freelance work, my biggest fear was that I wouldn’t be able to deliver technically. What if I just didn’t know how to do something? As a solo developer, that thought was horrifying. When you become a developer, you realize that there is no way you’ll know how to implement every technical feature, yet. However, you come to realize that you can learn how to implement every technical feature. Part of this comes from the endless resources available: documentation, Stack Overflow, forums and blogs, but the other part is the mindset you develop as you overcome technical hurdles.

I remember working on Picturemenu and realizing that at the end of every week, I had implemented a feature I had no idea how to do at the beginning of the week. After a few weeks of this, I started to develop confidence in my ability to learn and figure things out. My classic response to the question, “Do you know how to do it?” was, “Not right now, but I’ll figure it out.”

I think this mindset has been the most positive change for me and it has carried over to all parts of my life. Knowledge is finite, but the ability to learn is infinite.

Dedication

Programming is a craft and in order to become great, like at anything, you must have a long term perspective and dedicate yourself to becoming better each day. I realized that my failed attempts at learning to program before this past year was because I had a very myopic view of programming. I had the mindset that maybe I’ll do programming here and there for a little while and then move on to something else. I thought that I could just read a book and know how to program. I was wrong. It wasn’t until I committed to become an iOS developer that I saw significant strides. There’s a pretty steep learning curve to programming and I’ve fallen off three or four times. If you don’t see yourself programming for at the minimum, the next two years of your life, you’re not going to put up with all of the frustration that comes along with it - it’s just not worth it.

Along with dedication comes perseverance. One of the traits that I admire most of programmers and have been developing myself is persistence. Your code will always have bugs. Debugging can turn into a war of attrition. You have to be persistent when tracking down bugs and be willing to take the self inflicted punches along the way as you figure out that the reason why your code doesn’t work is because you forgot to reset a boolean variable.

Appreciation

As consumers, we take the process it takes to produce a product for granted. We complain about how we don’t like the color of an icon, how slow an app is or how something just sucks. These can all be valid points, but when you’re on the other end as a producer, you realize (usually) how much time, effort and thought goes into making a product from start to finish. It’s not a trivial task.

Apps range from very simple to very complex, but even the simplest app requires a certain amount of effort in making things work. You have to write the code, make the icon, submit it to the AppStore (trust me, submitting to the AppStore for the very first time can be a harrowing experience). As end users, we don’t care about all of that, and we shouldn’t, but as a producer, you develop a new found appreciation for great products, beautiful design and craftsmen. This way of thinking adds more depth to life. You look at things differently. Music, physical products and nature all become magical as you realize that it all came from nothing.

Finding Primes: Sieve of Eratosthenes

Wed, 02 Jan 2013 12:30:29 -0500

Have you ever tried finding the first n prime numbers?

It’s not something you think about every day, but I’ve been going through some of the problems on Project Euler and finding prime numbers seems to be a recurring exercise.

In solving these problems, I ran across the ancient algorithm, Sieve of Eratosthenes, to find prime numbers. The basic algorithm to find all prime numbers within a range is, you start with the first prime number of that range, you go through that array of numbers and divide each number by that first prime number (not including itself), if the number in the array is divisible, you throw it out of the array. You then repeat this for the next number in the array once you go through dividing and removing numbers from the array until you reach the end of the array.

Here’s a concrete example: Find all of the prime numbers from [2, 10]

2, 3, 4, 5, 6, 7, 8, 9, 10

Start with 2 and start removing all numbers divisible by two:

2, 3, 4, 5, 6, 7, 8, 9, 10

Do the same with the next number, 3:

2, 3, 5, 7, 9

As you go through with 5 and 7, there are no more numbers divisible, so you’re left with an array of all primes in [2, 10]:

2, 3, 5, 7

Here’s some code finding the sum of the primes less than 2,000,000:

Lifted By Others

Sun, 23 Dec 2012 20:47:00 -0500

I have this poster in my room at my parent’s home. I love the quote by William Blake at the bottom, “No bird soars too high, if he soars with his own wings.”

About a week ago I renewed my yearly Apple Developer’s License. That means I started building iPhone apps one year ago. I distinctly remember writing my first line of Objective-C on the very desk that I am writing this post.

One year ago, I committed to learn how to program and make iPhone apps. Since then, I’ve launched three of my own apps into the AppStore, started an iPhone app consulting business, acquired clients and began working at a design firm as an iOS engineer staffed on projects for Fortune 500 companies. Needless to say, my life has changed. I don’t think I can even begin to convey how much I’ve learned in the past year, but one lesson I do want to share from the past year is the importance of being in an environment that is conducive to reaching your goals.

You can only go so far on your own. I owe so much to my close friends who have challenged me, encouraged me and inspired me. Here are a few of the countless examples of the influences in my life that have pushed me to places beyond my own imagination:

Steve Derico. Steve has been the most influential person in my development as an iPhone developer. He was the first one to tell me that I could become one and has spent countless hours teaching me everything from code, freelancing and design. I cannot thank him enough. Early on, I asked Steve if I could buy him dinner in exchange for an hour of his time coding, debugging and asking questions. Those were the most invaluable hours for my growth as a developer. Without him, I probably would have gotten stuck and maybe even given up, but he has always been a constant source of encouragement. Just knowing that someone believes in you goes a long way. Thank you, Steve.

Hackathon guys. Even before I started doing iOS development, some of my friends and I would stay up all night, eat terrible food, drink red bull and work on side projects. This still continues today. Steve, Nick, Sam, Matt and I will hack through the night together on our respective projects. By working in the same place, we push each other to be productive and help each other when we can. I’ve picked up so much just having short conversations in passing, by asking, “Hey Sam, how would you approach this…” Then, there is the 2 AM run to Safeway to get junk food - not the healthiest idea, but it’s always an experience.

I’ve been fortunate enough to be immersed in such a great environment to learn how to become an iPhone developer. I am a testament to how valuable such a supportive environment can be. I hope that I can contribute even a fraction of the value I’ve received to that community.

Surround yourself with those that inspire and encourage you, and oh the places you’ll go.

For fun: Hackathon footage from August 19th, 2010:

Learning algorithms: Insertion Sort

Wed, 05 Dec 2012 15:16:19 -0500

I am an iOS engineer, but I don’t have much of a computer science background. I took one intro CS course at Duke and it was pretty terrible. However, with all of the free, high quality online courses available, I can learn just about anything. I’ve started taking MIT’s Intro to Algorithms.

I was watching the first lecture and taking notes. This is generally how I approached school: go to lecture, take notes, read the text book, do homework. I thought that’s what I would do for this online course, but I realized how much more flexibility I have with online videos and with all of the course material available at once. This means I can pause the video, skip to different lectures or try something out during the lecture. I think that last part is the way I’m going to learn the most. Usually, I would just watch the lecture and just listen. Now, I’m going to put more emphasis on doing some of the examples on my own.

The first algorithm presented was a classic sorting algorithm, insertion sort (I had no idea what it was). Insertion sort is an algorithm that takes an array of numbers and sorts them from least to greatest. The high level overview is that you pick a number at an index != 0, which we will call “key” and compare it to the value at the previous index. If the key is less than the value, you “insert” it at the previous index and then you move onto the next index until you get to the end of the array.

The lecture notes gave the pseudo code, but I wanted to code it on my own to really understand insertion sort. Here’s my code (in ruby):

Have the Audacity to Build

Thu, 02 Feb 2012 14:42:12 -0500

Yesterday was one of the most inspirational days I’ve had in awhile and it wasn’t because I read a heartwarming story, watched a compelling Youtube video or listened to uplifting music. It was because I built something.

I’ve been learning how to make iPhone apps for about a month and yesterday, I submitted my first two iPhone apps to the AppStore for review. I’ll find out in a week if they are approved.

I had been talking about learning how to program for over a year, but I haven’t had much to show for it. But yesterday I shipped something I built. Is it perfect? No. Is it insanely great? Not at all. But it’s a start and that’s the key.

Submitting to the AppStore was pretty magical. It was magical because it broke down a lot of my walls. Well, maybe it didn’t break down my walls, but it did take a good chunk out of my wall of fear of failure.

I’ve always followed the well-worn path and have been pretty successful at it. I’m pretty book smart, so I got good grades in high school, went to a prestigious college and even wrote a book about it…(shameless, I know). I was pretty set on continuing that theme into my professional career - whether it be medical school or a job at a large corporation - but for some personal reasons (maybe I’ll share those in a future post) that was not going to be part of my journey, at least not right now.

When you have continued success with a certain way of life, it’s frightening to change course. This characterizes my past two years since I graduated from Duke. I was frightened by not having the safety blanket of being considered successful by association. If I told you I worked at Google, just by association you could make a lot of assumptions about my abilities, salary, stability, etc. When you don’t have that association crutch you’ve always had, you begin to doubt yourself.

It’s a continual process to overcome that doubt, but what I’ve found helpful is that you have to have the audacity to build and then take one step. Whether it be deciding to learn a new language and doing one tutorial or coming up with an idea and actually starting a business entity, the mere fact that you took one small step toward building something is progress. Just keep the momentum going and take more one step, then another and another…

I’m a sucker for inspirational things so I couldn’t leave this one out. This is a gem:

My Beef with Interface Builder

Wed, 18 Jan 2012 23:20:24 -0500

I’ve been generally impressed with XCode 4. I’ve never used it before until about a month ago and I’ve picked it up pretty quickly. I’ve primarily used KomodoEdit and Textmate before I started iOS programming so the Interface Builder was something completely new. I really liked it…at first.

Using a GUI to hook up outlets, actions, drop in views and controllers was fun at first and very easy. However, after going deeper with iOS, using IB can be a pain because you don’t have as much control over the code.

For instance, today I was building a UITableView and I used IB to drop in a UITableView object. I made sure to include the UITableViewDataSource and UITableViewDelegate protocols in my ViewController and implemented the required methods. I used the Attributes inspector to set the style of my UITableView and I programmatically set the datasource and delegate to my ViewController. Build, run. Nothing.

I couldn’t figure out what was wrong, but I looked at my XIB file and glanced at my Connections inspector. Even though I had programmatically set my datasource and delegate, it showed that these two properties were not connected. I had to manually set these in my XIB file. This is annoying.

It seems like there’s a divide between using IB to build apps or actually writing code. XCode 4 seems to be riding in the middle and little details like setting the datasource and delegate slip through the cracks. I like writing the code out, you have full control and you know how everything is connected. I think I’m going to try to manually program things from now on, and maybe I’ll use IB to mock up prototypes quickly. But for building complicated apps, relying heavily on IB seems like a nightmare.

Key Points When Setting Segues Directly

Wed, 11 Jan 2012 12:38:02 -0500

In learning to use Storyboarding both programmatically and directly, here are a few key points I’ve found.

When setting segues directly…

If a button leads to a segue, CTRL-Drag it to the next View Controller. Distinctly name each segue in the Identifier field of the Inspector option in the Utilities tab!
Each button that leads to segue will have its own ViewController that is created and pushed on top of the view stack.
In your
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender implementation, use if statements to select the correct segue.identifier to send appropriate messages to your segue.destinationViewController object.

One key reason to set segues directly is if each segue has a unique UI. This way, you can fully customize each the UI of the view for each resulting segue.

Also, when you set the segue directly, you do not need to call

- (void)performSegueWithIdentifier:(NSString *)identifier sender:(id)sender

because this code is used when you have a button as a target-action to manually call execute the segue when pressed. However, when directly setting the segue in Storyboard, your buttons do not have target-actions, but rather direct segues (via CTRL-drag) to the next ViewController. Therefore, that connection will know to execute the segue.

Here are all of the if statements in
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender I was referring to:

Four Checkpoints When Creating Segues Programmatically

Wed, 11 Jan 2012 03:54:00 -0500

Storyboarding is a new feature in XCode 4.2 and is only compatible with iOS5. Storyboarding enables you to manage all of your views in one place and create segues (transitions between views). Segues can be created graphically through the storyboard, but you can make segues programmatically.

The code is based on the CS193P Lecture 6 demo that creates segues programmatically.

Here are some checkpoints when you are creating segues programmatically:

1. Link the segue

This one is a little tricky. Most of the time, you want to trigger a segue when you click a button. So it’s natural for you to CTRL-drag from a button to another ViewController. However, if your buttons have a target-action that calls the segue in code, then it’s your ViewController that triggers the segue. So in this case, CTRL-drag from your ViewController to the next ViewController.

2. Is your segue identifier set?

Highlight the connection between two views in your MainStoryboard.storyboard with your Utilities tab showing (far right tab). Look at the Attributes section, make sure you give a descriptive name for the Identifier field. This is how you are going to refer to this specific segue in your code.

3. Call - (void) performSegueWithIdentifier:(NSString *)identifier sender:(id)sender

Like the method name, this actually performs the segue, so call it when you actually want the segue to happen in your code. The identifier parameter is the name you set for your segue, see #2. Sender is the object that is responsible for triggering the segue, so for example, it could be a button or the ViewController itself.

4. Implement - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender

When implementing, make sure you check each segue identifier so you know what segue it should perform. For instance, this is the code from the demo:

Once you check for the correct identifier, you can send messages to your segue.destinationViewController, the ViewController that controls the resulting View from the segue.

Assignment 2 Hack (2011 Fall CS193P)

Fri, 30 Dec 2011 21:50:57 -0500

Assignment 2 requires you to create a programmable calculator where you can store values for variables. In reading over the actual question, I really had no idea where to start. I don’t think the directions are all that clear, but maybe that’s just me.

After reading question 1, I just assumed that there needs to be some variable key on the calculator which you could set the value for and then reuse. So that’s what I did.

How is this a hack? Because that’s not what the question asks for. In reality, the question only asks you to be able to store variables so that you can hard code in values for those variables - not all that flexible. How do I know this? Thanks to Jeffrey Lam who posted the (real) solution to his Github account.

So here’s my logic:

To set the value of the variable, first I enter the numeric value, then I hit the variable button followed by the enter key.
When the variable button is pressed, the variable itself is added to the stack and its value is retrieved.

The hack is that when retrieving the value of a variable, the value is the second to last object in the stack that hold all operands entered because the variable is added to the same stack when its button is pressed.

Here’s the code:

In the Controller:

In the Model:

Create public methods:

- (double)getVariableValue:(NSString *)var;

- (void)setVariable:(NSString *)var;

Implement them:

Update the enterPressed method:

Once these are set, you can store any numeric value into your variable. This isn’t the intended answer of the assignment, but it was definitely a good learning experience.

Write Pseudo Code Before Coding

Thu, 29 Dec 2011 02:13:00 -0500

I took one semester of Computer Science in college, second semester of my senior year. It was an intro class and I learned some Java. Of all the classes I took at Duke, it was one of the most poorly taught. Maybe it was because I had no background in CS and didn’t know what to expect, but given the amount of griping I did with other classmates, I’m going to stick to my statement. However, one thing I did learn and I now see great value in is writing pseudo code before actually writing a line of code.

What is pseudo code? Pseudo code is just an outline of the code you want to write disregarding formal syntax. It’s can be in sentence form or short hand code. Just lay out, step by step what you want your code to do. An example is probably the best way to describe this:

While working on the first homework assignment of CS 193P, I had to create a backspace button for a calculator. This is the pseudo code I wrote:

Make a button that doesn’t return anything (void).

Implement the button with this code:

if user is in the middle of entering number check if there is only one number entered.

if so, display, “Enter operand” as a message to let user know there is no number entered anymore.

if there is more than one digit entered, cut off the last digit and return the substring.

print the substring or the message on the display.

Pretty simple, but it forces you to lay out a road map and consciously think about what the code you want to write. This really helps me because when I just dive into the code, I just hack away with whatever comes to my mind. I often lose sight of where I’m going and can get lost on rabbit trails.

Pseudo code is just for a reference, you don’t necessarily have to follow it exactly. But I like having the initial plan as a starting point.

I also recommend you physically writing out the pseudo code. I think it makes it more intentional. You may think it takes more time to do this and if it’s a trivial method, you’re probably right. But for more complicated solutions, I think this will actually save you time and headache in the long run.

Oh and here’s the actual code:

Stanford CS 193P (F'11) Assignment 1 Highlights

Sat, 24 Dec 2011 02:01:00 -0500

I finished up Assignment 1 from Stanford CS 193P and put it on Github. The assignment is to make a calculator app with basic functionality. The first assignment was a great intro and I highly recommend reading through the walkthrough as it is very thorough. I want to highlight a one of the questions from the problem set.

Make a clear (C) button (Problem #5)

This task is a pretty simple one, create a clear button (C) that erases any previous input from the display screen and the historyDisplay screen. The historyDisplay screen is from #4 - it essentially shows the history of what you typed into the calculator.

This is a great task because it combines a lot of concepts and requires a pretty good understanding of how the Model, View and Controller work together.

A quick note about how the calculator works. When a number is entered (touching digits and then pressing the Enter key), that number is added to an NSMutableArray. The next operand (number) is entered (adds to NSMutableArray) followed by the operator. The operator then performs the calculation with respect to the two previous number entries. For instance, 25 + 3.58 is calculated by: 25 Enter 3.58 +.

Let’s get back to making this Clear button.

The first step is to drag a button from the Object Library onto your storyboard (View). The button needs to be able to talk to the Controller via an Action, so CTRL Click and drag the arrow into your controller (.m) file. There is no need to send an argument to this action. I named this action clearPressed.

For the actual code, when C is pressed, I want to clear display and historyDisplayed, so I just my setter function and set them both to a blank:

I’m not done because I need to now delete the number I added to the NSMutableArray in my model so that when I continue using my calculator, my discarded operand does not get used. This means I need to create a method in my model that removes the last object in my array.

Because I need to use it in my controller, I need to make this model function, I called it clearAll, public. So I declared it in my model header (.h) file as:

- (void)clearAll;

In my model implementation file (.i), I send a message to my NSMutableArray to removeLastlObject so delete the last entered number. Here’s the code:

Now I can use this function in my controller implementation file:

My model is called brain.

So now when the C button is pressed, the display is cleared and the number is removed from the array and you’re ready to enter another number!

This was a good question that makes sure you understand how MVC work together.

Three iOS Concepts to Help Get You Started

Tue, 20 Dec 2011 03:02:00 -0500

I just began iOS development and I’ve come across some concepts that are mentioned over and over - I’m going through iOS Programming: The Big Nerd Ranch Guide (2nd Ed.) and Stanford CS 193P iPhone Application Development. I have a hunch that these concepts will be essential as I dive deeper into iOS development.

Just as a side note, I have experience developing in PHP, Python/Django and a little bit of Java, but no prior C or Objective C experience.

1. Model - View - Controller (MVC)

MVC is the way iOS (as well as Ruby on Rails and Python/Django) software is organized. Your code is separated up into these three parts and each part has a specific role in your software.

Model:

The Model holds your app’s data and information or otherwise referred to as objects. In essence it is what your application is. For instance, if you’re creating an app that shares photos, the model is where your array of photos are stored, where you define how big your photos can be and how many photos a user can have.

Controller:

The Controller is the brain of your application. It talks to the Model so that it can determine how to represent the data or objects on the screen.

View:

The View is what is actually displayed on your screen, like buttons, sliders and text inputs. Views are connected to the Controller so that on screen actions are linked with methods in the Controller who then accesses data in the Model to retrieve an object (ex: a photo) to be relay back to the View so that it can display it on the screen.

Having distinct pieces of code allows you to manage and organize your software as it becomes more and more complex. As you write more and more code, you’ll know where to write that specific piece of code and where to find it later on if you need to change it.

2. Objective - C Method Syntax

When I first saw an Obj. - C method declared, I was a little confused. Here is sample from the first lecture in Stanford CS 193P:

- (void)orbitPlanet:(Planet *)aPlanet atAltitude:(double)km

The full name of this method is orbitPlanet:atAltitude. Let’s break this line of code up piece by piece.

Methods start off with a - and (void) is the return type. You must specify a return type, if you are return a double float point, you would write (double). orbitPlanet is part of the name of the function and it takes in a parameter called “aPlanet” that is of type Planet *. The * means that it is a pointer to the object, Planet. A pointer is a reference to an object, it is a link or line to that object.

atAltitude is another method pieced together to orbitPlanet that takes in a parameter, km, which is a (double). The parameter names are arbitrarily defined, you can make up any name you like.

3. @property/@synthesize

In Objective - C, you don’t directly access instance variables, you use properties. Properties are a combination of setter and getter methods. Setter methods store values into a variable that looks like setMyValue. Getter methods retrive the value and has a name like myValue.

You can defined setter and getter methods two ways:

- (void)setMyScore(double):mathTest;

- (double)myScore;

@property (nonatomic) double myScore;

A and B are equivalent. The (nonatomic) is related to threading, a topic which I’ll write about later, but here’s a good explanation.

If you use @property to declare getters and setters, you must use @synthesize to implement the property. Here’s how you would implement @property:

@synthesize myScore = _myScore

@synthesize creates storage to hold the value and _myScore is the name of the storage location, it creates an instance variable. Make sure you have a different name than myScore and stick to that convention. For instance, use an underscore (_) and the property name.

So these are a few basic concepts to help you get started. I’ll keep the posts coming as I learn more.

Let’s build some cool apps!