DJ Chung

  • Archive
  • RSS

Have the Audacity to Build

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:

  • 3 months ago
  • Permalink
  • Share
    Tweet

My Beef with Interface Builder

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. 

  • 4 months ago
  • Permalink
  • Share
    Tweet

Key Points When Setting Segues Directly

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:


  • 4 months ago
  • Permalink
  • Share
    Tweet

Four Checkpoints When Creating Segues Programmatically

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. 

  • 4 months ago
  • Permalink
  • Share
    Tweet

Assignment 2 Hack (2011 Fall CS193P)

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. 

  • 4 months ago
  • Permalink
  • Share
    Tweet

Write Pseudo Code Before Coding

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: 

  • 5 months ago
  • Permalink
  • Share
    Tweet

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

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. 

  • 5 months ago
  • 1
  • Permalink
  • Share
    Tweet

Three iOS Concepts to Help Get You Started

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:

A.

- (void)setMyScore(double):mathTest;

- (double)myScore;

B.

@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!

  • 5 months ago
  • 1
  • Permalink
  • Share
    Tweet

Portrait/Logo

I live in the Bay Area, build iPhone apps and try to make a dent in the universe. This is a blog about my journey.

Follow @DJCHUNG

Pages

  • About Me
  • Work
  • RSS
  • Random
  • Archive
  • Mobile

Effector Theme by Carlo Franco.

Powered by Tumblr