The first video in our iOS 101 series. Learn the basics of using Xcode to create a simple iPhone app.

Video Tutorial: Hello, iPhone! is a post from: Ray Wenderlich

The post Video Tutorial: Hello, iPhone! appeared first on Ray Wenderlich.

Learn about the most common UIKit controls in iOS development, like text fields, sliders, segmented controls, and more.

Video Tutorial: Common UIKit Controls is a post from: Ray Wenderlich

The post Video Tutorial: Common UIKit Controls appeared first on Ray Wenderlich.

Learn the basics of using Auto Layout to make your user interfaces adapt to different screen sizes and orientations.

Video Tutorial: Beginning Auto Layout is a post from: Ray Wenderlich

The post Video Tutorial: Beginning Auto Layout appeared first on Ray Wenderlich.

Learn how to transition between different "screens" of your app with Storyboards and segues.

Video Tutorial: Storyboards and Segues is a post from: Ray Wenderlich

The post Video Tutorial: Storyboards and Segues appeared first on Ray Wenderlich.

We're excited to introduce a brand new feature of raywenderlich.com - high quality video tutorials!

Introducing raywenderlich.com Video Tutorials (Beta)! is a post from: Ray Wenderlich

The post Introducing raywenderlich.com Video Tutorials (Beta)! appeared first on Ray Wenderlich.

Learn the basics of how to make your first Android app and learn the ins and outs of working with Android Studio.

Make Your First Android App: Part 1/3 is a post from: Ray Wenderlich

The post Make Your First Android App: Part 1/3 appeared first on Ray Wenderlich.

Learn how to easily manage a stack of view controllers in your app using navigation controllers.

Video Tutorial: Navigation Controllers is a post from: Ray Wenderlich

The post Video Tutorial: Navigation Controllers appeared first on Ray Wenderlich.

This tutorial is the second of three parts. If you’re looking to start from scratch, Part One is the tutorial for you!

The first part of this series covered a lot of zoomed-out Android concepts, as well as the general structure of Android projects. In this part of the tutorial, you’ll learn more “on the ground” Android: how a layout file works and the specifics of Android layouts and views.

By the time you’re done with this section, you’ll have an app with:

• An image from a PNG file;
• An editable text field for writing messages;
• A button to submit your input;
• A text view that shows your most recent message;
• A list that displays all your messages;
• An option to share your message through Facebook, Twitter, SMS or email; and
• A greeting that saves and retrieves your name each time you open the app.

You should already be at the point where you have a “Hello World” app running on your emulator or device. At the end of the last section, you changed the text so that it greets you personally, like mine:

It’s great that you’ve come this far — but now it’s time to take it to the next level! There’s a lot to do, so let’s get to it!

Getting Started

Looking ahead, the first thing you should do is check that you’re making your app as simple as possible. You don’t want to introduce additional complexity unless it’s needed since extra complexity in how something is implemented means that it takes more time and requires more work if you were to later modify the bits with the extra complexity.

The project that Android Studio creates by default gives you a structure that works well for a lot of apps. It uses a Fragment. Fragments are like sub-activities. They contain UI elements that could either take up the whole screen or just a portion of it. They’re controlled by their parent Activity and can be swapped out for another Fragment quite easily.

But for your first app, the additional complexity of a Fragment isn’t really needed. So, you’ll remove this default Fragment setup.

First, open MainActivity.java and find the following section inside onCreate:

if (savedInstanceState == null) {
	getFragmentManager().beginTransaction()
			.add(R.id.container, new PlaceholderFragment())
			.commit();
}

Select and delete that bit of code.

Second, scroll to the bottom of the file and find the section defining the PlaceholderFragment class:

/**
 * A placeholder fragment containing a simple view.
 */
public static class PlaceholderFragment extends Fragment {
 
	public PlaceholderFragment() {
	}
 
	@Override
	public View onCreateView(LayoutInflater inflater, ViewGroup container,
			Bundle savedInstanceState) {
		View rootView = inflater.inflate(R.layout.fragment_main, container, false);
		return rootView;
	}
}

Carefully select and delete the whole class definition, making sure that the final closing bracket for MainActivity is not removed.

Next, open res/layout/fragment_main.xml. After opening the file, you may have to switch the editor to Text mode if you can’t see the raw XML. Click the appropriate tab at the bottom of the editor pane as shown below.

Select all the text inside fragment_main.xml and copy it. Then, open res/layout/activity_main.xml and replace its contents with the former contents of fragment_main.xml.

There’s Just a bit of clean up left to do. Remove this line:

xmlns:tools=http://schemas.android.com/tools

And this one:

tools:context=".MainActivity$PlaceholderFragment"

And these four lines which set the padding:

android:paddingLeft="@dimen/activity_horizontal_margin"
android:paddingRight="@dimen/activity_horizontal_margin"
android:paddingTop="@dimen/activity_vertical_margin"
android:paddingBottom="@dimen/activity_vertical_margin"

After all of these steps, your activity_main.xml should look something like this:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView
        android:text="@string/hello_world"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />
</RelativeLayout>

Now, right-click on fragment_main.xml on the left pane of Android Studio and select the Delete… option from the context menu.

Now that you’ve finished that bit of cleaning up, you’re all set to work with a simple Activity. And it’s time to learn how to make a layout for one!

XML Layout Basics

Android layouts are in XML format, in the form of a tree with a single root and a hierarchy of views. The hierarchy is very strict and straightforward: each view in the tree is termed the parent of the views it contains and the child of the view that contains it.

Open res/layout/activity_main.xml. You can see the XML for your activity here. There is a parent RelativeLayout and a child TextView.

Look at the TextView specifically. You can see that it contains three attributes. Of those, two are present in every view you’ll ever put into your Android layouts: layout_width and layout_height. The values for these attributes can take several forms:

• wrap_content: This constant value specifies that the view will be just large enough to fit whatever is inside it, whether that’s an image, text or child view.
• match_parent: This constant sets the view to be as big as its parent.
• Explicit values: You could set the dimension to a specific number of pixels (Ex: 5px), but it is usually wiser to use density independent pixels (Ex: 5dp). A dp is a pixel on a “medium-density” (mdpi) device, and the number of actual pixels automatically scales for devices designated as low-density (ldpi), high-density (hdpi), extra-high-density (xhdpi), etc.

In other words, using straight-up pixels would result in your views being all sorts of crazy sizes, depending on whether a device has 160 pixels per inch or 300 pixels per inch, or what have you. Who knows! Let the Android system take care of the scaling and just use dp.

The final attribute of the TextView is simply text, in which you specify the text to be displayed. This attribute is a good example of how different views respond to different attributes. Adding a text attribute to a RelativeLayout or a Space wouldn’t accomplish anything because, unlike the TextView, they wouldn’t know what to do with it.

But the value of the attribute, @string/hello_world, isn’t what’s displaying, is it? What you specify in your layout file is not the actual string to be displayed but rather a string resource ID identifying the actual text. That way, all your app’s copy can be in one place – res/values/strings.xml.

Now let’s look at the parent node in the XML: RelativeLayout. What’s going on there?

Relative Layouts

The layouts in iOS apps used to be in purely absolute terms, like: “Place View X at pixels (x,y)”, but now iOS developers have AutoLayout. Android developers have always needed to keep device screen sizes in mind. Layout files are very well-suited for this consideration.

The default project Studio created for you sets you up with a useful layout: a RelativeLayout. It is currently the parent layout and the TextView element is its child.

A RelativeLayout is an intuitive and powerful thing. It holds a bunch of child views and positions them in relation to each other. Here are three examples of what you can easily do with a RelativeLayout:

Example 1: Use layout_alignParentBottom and the similar attributes for top, left and right to line up a view’s edge with the corresponding edge of the RelativeLayout, which may or may not also be the edge of the screen.

Example 2: You can use layout_toRightOf and the analogous attributes for left, above and below to position one View relative to another.

Example 3: You can use layout_alignRight and the analogous attributes to align a side of one View with another.

You can see how that could be useful! For now, though, let’s move on to the layout type you’ll be using for this tutorial.

Linear Layouts

A LinearLayout needs to have an orientation specified, either horizontal or vertical. Then it lines up its children in that orientation, in the order in which they are specified in your XML.

The children of LinearLayouts don’t respond to attributes like layout_toRightOf, but they do respond to two other attributes: layout_weight and layout_gravity.

Specifying a layout_weight expands the view to a proportion of its parent so that the parent weight is the sum of all child view weights.

Confused? Perhaps the following image might help explain it better.

Notice how the full height of the parent view is split up between the child views based on the layout weight assigned to each child view.

Assigning a layout_gravity to a view sets its horizontal and vertical positions within its parent LinearLayout. For example, a view might have a layout_gravity attribute with a value like left, right, and center_vertical. The previous values can also be combined, like this: top|center_horizontal.

Then, there’s gravity, not to be confused with layout_gravity. layout_gravity is about where you place the view itself. The gravity attribute defines how you place the content of a view within itself. If you want your text to be left or center justified, use gravity.

The following example shows how layout_gravity and gravity work in a vertical LinearLayout. Note that the top three have a layout_width of wrap_content while for the bottom three it’s set to match_parent:

One handy trick, which you’ll see in just a bit, is that you can nest layouts inside each other. Cue the theme music from Inception!

You don’t want your layouts to be as multi-layered as a Christopher Nolan movie, though. So, if you start to see your nested LinearLayouts scheme getting out of hand, consider switching to a RelativeLayout.

Before you move on to the next section, open res/layout/activity_main.xml and change the root node from a RelativeLayout — what Android Studio gave you as a default — to a LinearLayout.

To do that, you should replace these lines:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

And this one at the very end of the file:

</RelativeLayout>

With This:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
	android:layout_width="match_parent"
	android:layout_height="match_parent"
	android:orientation="vertical">

And this:

</LinearLayout>

Accessing Views From Within Java

Layouts are primarily the domain of your XML. But there are plenty of visual elements you will want to create, destroy, change, and trigger from within your Java code!

So first, edit the TextView in activity_main.xml to match the following:

<TextView
    android:id="@+id/main_textview"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_marginLeft="20dp"
    android:layout_marginTop="20dp"
    android:text="@string/hello_world"/>

Notice the addition of the id attribute. Using this tag (or attribute, if you prefer) allows you to access that specific View from within your code, so you can thereafter manipulate the View via code.

There's also a change to make in the text tag. The name of the string resource hello_world is a bit outdated now, don't you think? Right-click on the @string/hello_world part of the line and then choose Refactor > Rename.

Then, type in textview and click Refactor.

This not only changes the name of the resource ID in your layout file, it also changes the original resource ID in your strings.xml file. It also renames the resource ID wherever else it might be used in the project. This is a useful trick to remember when renaming something that appears all over your project!

Now open MainActivity.java and add the following line above onCreate:

TextView mainTextView;

Android Studio might throw an error at you. The TextView class hasn't been imported into MainActivity.java yet. Android Studio can quickly auto-import files for you. Just tap Option-Enter on your keyboard to automatically import TextView.

Next, add the following code to onCreate after the two existing lines of code:

		// 1. Access the TextView defined in layout XML
		// and then set its text
		mainTextView = (TextView) findViewById(R.id.main_textview);
		mainTextView.setText("Set in Java!");

Finally, run your app and look at the results!

The text set via Java code now appears on screen. What are the steps you just took to make that happen?

1. You added an id attribute to the View in XML.
2. You used the id to access the View via your code.
3. You called a method on the View to change its text value.

Buttons and Listeners

It’s time to build on your TextView and get more interactive! Next up is a Button.

Add a Button to activity_main.xml, directly after your TextView:

<!-- Set OnClickListener to trigger results when pressed -->
<Button
    android:id="@+id/main_button"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_marginTop="20dp"
    android:layout_marginLeft="20dp"
    android:text="@string/button" />

Notice there's an XML comment above the Button, a reminder of how to trigger results.

The layout_margin attributes simply add 20 density-independent pixels of space above and to the left of the Button to keep your layout from looking cramped. Remember that the value of 20 will be scaled by the screen density of the device to get an actual pixel value.

Then there's text, for which you need to add a line in strings.xml such as the following:

<string name="button">Update The TextView</string>

Next, open MainActivity.java and add the following right below the previous line you added for a TextView variable:

Button mainButton;

Make sure you Option-Enter to import any missing classes.

Now add the following code to the end of onCreate, after the code you added earlier:

		// 2. Access the Button defined in layout XML
		// and listen for it here
		mainButton = (Button) findViewById(R.id.main_button);
		mainButton.setOnClickListener(this);

Again, you see the same three steps as when you added code to access the TextView:

1. You add an id to the View in XML. Or, in this case, you add a view with an id attribute.
2. You access that View in code by using the id.
3. You call methods on that View.

This time, the method you called on the Button is setOnClickListener. What you put in the parentheses of that method becomes the answer to this question: Which Object is going to respond when this Button gets pressed?

To answer that question with simply the word this seems a little curt and unspecific, but Java knows that it means MainActivity itself is your intended listener.

This means that MainActivity has to implement the View.OnClickListener interface. If that sentence doesn't make much sense to you, I suggest finding an intro on what an interface is and how to create one, like this one.

Android Studio is smart and can help you do the implementation. Simply single-click on this, which is underlined in red, indicating an issue (in this case the fact that MainActivity currently does not support the necessary interface). Then, when a red light bulb appears at the beginning of the line, click on it and select Make 'MainActivity' implement 'android.view.View.OnClickListener'.

Simply click OK on the next dialog, which lets you know which method(s) Studio will automatically create for you.

Studio then generates the code necessary to make your MainActivity qualify as a union-certified OnClickListener.

First, it added a bit to the class declaration indicating that the Activity implements a specific interface:

public class MainActivity extends Activity implements View.OnClickListener

Second, Studio added a stub for a method you need to implement in order to get your OnClickListener license (other interfaces may require more than one method to be implemented): onClick. This method fires when your Button gets pressed.

The method currently does nothing. So add the following code to onClick to make it do something:

		// Test the Button
		mainTextView.setText("Button pressed!");

Can you tell from the code what should happen? Run your app and see if you're right...

The app now changes the text in the TextView when you press the Button. Cool! You'll be putting this Button to even better use later — to submit input.

Adding a Visual

It's always fun to include images in your UI. So how about adding an ImageView to show a little icon? Along the way, you'll also get to see how a nested LinearLayout works.

First off, what image will you show? Well, it's easiest to start with the image you're given by default. It's already in your project and here's where to find it.

Use the Project Navigator to expand the src/main/res directory:

You can see several directories within res, including values, which you dealt with when you edited strings.xml. Notice that several are named drawable, plus some letters that look like screen density abbreviations.

Indeed, those abbreviations correspond to the pixel density buckets used to classify Android devices in dots per inch (dpi):

• mdpi: medium
• hdpi: high
• xhdpi: extra high

There are now xxhdpi and xxxhdpi buckets with even higher densities. Personally, I think they should use Roman numerals for the next level up and call it xlhdpi, but on second thought that would probably be a terribly confusing way to go...

Look inside the drawable directories. You'll see a file named ic_launcher.png. This is simply the default launch image you're given, at several different sizes for different screens. The Android system will pick the right one for the device.

Now head back to activity_main.xml and replace the following section:

<!-- Set OnClickListener to trigger results when pressed -->
<Button
    android:id="@+id/main_button"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_marginTop="20dp"
    android:layout_marginLeft="20dp"
    android:text="@string/button" />

With this:

<!-- This nested layout contains views of its own -->
<LinearLayout
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:orientation="horizontal">
    <!-- Set OnClickListener to trigger results when pressed -->
    <Button
        android:id="@+id/main_button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginTop="20dp"
        android:layout_marginLeft="20dp"
        android:text="@string/button" />
    <!-- Shows an image from your drawable resources -->
    <ImageView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginTop="20dp"
        android:layout_marginLeft="20dp"
        android:src="@drawable/ic_launcher" />
    <!-- Closing tag for the horizontal nested layout -->	
</LinearLayout>

You added a new LinearLayout inside the existing root layout, directly underneath the TextView as its new sibling. You also moved the existing Button into the nested layout and added a new ImageView, as well.

By wrapping your Button in a second, horizontal LinearLayout, you are able to place a Button and an ImageView side-by-side horizontally, even as the root layout has a vertical orientation.

As for the ImageView itself, the important attribute is src, to which you give your drawable image resource. Note the format you use to reference the drawable image.

Run the app, and you'll see the new image right beside the button!

Involving the Keyboard

Now it's time to get some user input... by introducing an EditText. This is a special subclass of TextView that opens the keyboard and displays what the user types as its content.

Add the EditText XML to activity_main.xml as a sibling to the TextView and the horizontal LinearLayout. Be careful not to get it caught inside the nested layout! Instead, add it right after the closing for the embedded linear layout.

<!-- Displays keyboard when touched -->
<EditText
    android:id="@+id/main_edittext"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_marginTop="20dp"
    android:layout_marginLeft="20dp"
    android:hint="@string/hint" />

Notice the special attribute, hint. You’re using this text as a placeholder in the input field. The app will overwrite it once the user starts typing.

As usual, you need to define the string resource for your hint in res/values/strings.xml:

<string name="hint">A Name</string>

Now open MainActivity.java and add a new variable for the EditText (below the other two existing variables):

EditText mainEditText;

As before, remember to use Option-Enter to automatically add the missing imports.

Next, add the following code to the end of onCreate:

	// 3. Access the EditText defined in layout XML
	mainEditText = (EditText) findViewById(R.id.main_edittext);

The above code, similar to the previous code, simply gets a reference to the EditText control and saves it in the assigned variable.

Now that you have a reference to the EditText control, you need to do something with user input. Replace the current contents of onClick with the following:

	// Take what was typed into the EditText
	// and use in TextView
	mainTextView.setText(mainEditText.getText().toString()
			+ " is learning Android development!");

Run your app, and try typing a few things!

Now you receive user input with an EditText, submit it with a Button, and display it in a TextView. Very nice! But how about visualizing more than one piece of data at a time?

The ListView

The ListView is a useful control that visualizes a list of items. It's analogous to a UITableView in iOS.

You define a ListView just as you would any other view in your XML. Add one to activity_main.xml as a sibling to the TextView, the horizontal LinearLayout, and the EditText by adding the following lines after the lines for the EditText control:

<!-- List whose dataset is defined in code with an adapter -->
<ListView
    android:id="@+id/main_listview"
    android:layout_width="match_parent"
    android:layout_height="0dp"
    android:layout_weight="1"
    android:layout_marginTop="20dp" />

Wait... what? How in the world could setting layout_height to 0dp be a good idea? After all, no matter what screen you're on, 0 is always going to scale to 0.

Well, take a look at what directly follows: a layout_weight. Since you haven’t given anything else in your layout a weight yet, the ListView is going to expand to fill as much space as possible, no matter what value you give the layout_height.

The general practice, then, is to use a value of 0 so the layout inflater has one fewer dimension to think about and can get the job done a bit quicker.

Now open MainActivity.java and, as before, add a new variable to hold a reference to the ListView:

ListView mainListView;
ArrayAdapter mArrayAdapter;
ArrayList mNameList = new ArrayList();

You'll note that instead of a single variable, the above code adds three new variables. The one for the ListView makes sense. But what about the others? The others are for supplying the ListView with data to display. All will be explained in a bit :]

But first, add the following code to the end of onCreate:

	// 4. Access the ListView
	mainListView = (ListView) findViewById(R.id.main_listview);
 
	// Create an ArrayAdapter for the ListView
	mArrayAdapter = new ArrayAdapter(this,
			android.R.layout.simple_list_item_1,
			mNameList);
 
	// Set the ListView to use the ArrayAdapter
	mainListView.setAdapter(mArrayAdapter);

Some of that looks familiar by now: finding the ListView using its id. But what else is going on?

mArrayAdapter is an example of an adapter, which is basically a go-between so your ListView can get the data it needs.

When you create mArrayAdapter, you have to specify the datasource (mNameList) and the target XML view for the data (simple_list_item_1).

But hang on, you didn't write anything with an id of simple_list_item_1! So where is that coming from?

Notice the android.R.layout part before simple_list_item_1. There are several important concepts here, but let's look at the R bit first. R (or, R.java, if you prefer) is a dynamically created class which gives you access to the resources in your project. If interested, you can read more about accessing resources via the R class, here.

As the linked article above explains, you can use the R class to get a resource ID by specifying a resource type and a resource name. The resource type would be something like string, drawable, or layout - matching the various resource types you see in your project. And thus, the layout part in android.R.layout.simple_list_item_1 simply specifies that you are referring to a layout resource.

But what about the android prefix? Why is it there? It is an indicator that you didn't create the view; it's already part of the Android platform. It represents a simple TextView that a default list cell can use.

The datasource in this case is mNameList, which is simply a list of Strings. It's initialized, but empty. So the next step is to add some data that the ListView can display.

Add the following code to the end of onClick:

	// Also add that value to the list shown in the ListView
	mNameList.add(mainEditText.getText().toString());
	mArrayAdapter.notifyDataSetChanged();

You simply add whatever the user typed into the EditText to the list of names and then shoot a signal to the adapter to update what's shown in the ListView.

Now run your app.

You should be able to type a name into the EditText, then see the name used in the TextView and added to a new row in the ListView when you press the Button. Cool!

Detecting List Selections

Looking at the items in a list is cool, but this is an app, and interactivity is even better! So next you’re going to set up a way to detect user selections from the list.

First, modify the class definition in MainActivity.java to add support for another interface. To do this, modify this line:

public class MainActivity extends Activity implements View.OnClickListener {

To look like this:

public class MainActivity extends Activity implements View.OnClickListener, AdapterView.OnItemClickListener {

All you've really done is add support for a new interface - AdapterView.OnItemClickListener, which, as the name suggests, listens for item selections from a ListView. MainActivity is really stacking up the credentials!

Next, add the following code to the end of onCreate:

		// 5. Set this activity to react to list items being pressed
		mainListView.setOnItemClickListener(this);

The above code sets MainActivity as the listener for any item clicks on mainListView.

Finally, add the following method to the end of the MainActivity class (but before the final closing curly brace):

	@Override 
	public void onItemClick(AdapterView parent, View view, int position, long id) {
		// Log the item's position and contents
		// to the console in Debug
		Log.d("omg android", position + ": " + mNameList.get(position));
	}

This implements onItemClick, thus setting up MainActivity to live up to the title of being a card-carrying OnItemClickListener.

But what's happening inside onItemClick? There's a weird Log.d in there, and then something with a get(position)...

Take a look at what you’re passing along to onItemClick. In particular, look at int position, which is an integer equal to the index of the item the user pressed on the list (counting up from 0).

You take that position, as well as the item at that index in your list of names, and log them. Logging is a very basic, but very useful debugging technique.

Run your app, enter a few values and add them to the list, just as before. Then select an item. There's no visible effect for the moment.

With the app still running, click the 6: Android button in Studio, as shown below:

When you click this button, a console called logcat pops up. It will read off tons of stuff from your emulator or device, the majority of which is not of much interest to you at this point. The log statements you generated with your selections are here, but there's too much noise to see them.

Here are some useful ways to filter out the noise and see only what you want:

Notice the option for Log level. When you put your Log command into code, it specifically was the Log.d command. The d is for "debug" level. The levels are:

• v: Verbose
• d: Debug
• i: Info
• w: Warning
• e: Error

When you select a log level for logcat, it will only show messages at that level or higher. And the levels start at verbose and go up to error, in the same order as listed above. So, if you select the log level as Warning, then you'll see all warnings and errors but nothing else.

Meanwhile, you can use the text box to the right of the log level drop-down to apply a filter and show only those messages that contain the text you typed in.

Now that you know this, set the log level to Debug and type omg android into the filter text box.

Great! You now have a clean feed of log statements and you can detect when a certain item gets selected in your list. The ability to log will come in handy as you create more complicated apps and want to stay informed of the inner workings of your code.

The Action Bar

Your app has several different views now, and it's time to think about other ways to add functionality. Older Android devices used to have a Menu device button that would display a bunch of options depending on the situation, but since Honeycomb in early 2011, Android has used the Action Bar to display any options for the current view.

The Action Bar provides a familiar base for your users. Since it's present across apps, making good use of the Action Bar means a significant part of your app's functionality will be immediately intuitive to an Android user. Conversely, neglecting the Action Bar would confuse all your users who expect it to work — and that would be weird!

The Action Bar is already in your app — it just has no options attached to it yet. That will be your first order of business next!

Sharing

Soon you'll have a chance to show off the fact that you're learning Android, from within your own app! You'll do this using an intersection of the Android concept of the Intent and the Action Bar, known as a ShareActionProvider.

One of the advantages of an Intent is that you can construct it in either a specific (explicit) or generic (implicit) manner. You used an example of the explicit type when you specifically defined the Intent that launches your app, which the manifest then identifies as MainActivity. Now you'll see an example of the implicit type.

A generic Intention really helps in this case. After all, some of us prefer to share things with the entire world, and others with just a few friends. Rather than wondering what a potential user's favorite social network might be and integrating them one by one, you can politely tell the Android device that you'd very much like to share a bit of content (thus expressing an Intent), and Android will graciously take it from there!

Navigate to src/main/res/menu/main.xml and open it.

You'll note that there's some auto-generated XML in there, but you don't need it. Replace the whole thing with this:

<!-- Defines the menu item that will appear on the Action Bar in MainActivity -->
<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <!-- Share item -->
    <item
        android:id="@+id/menu_item_share"
        android:showAsAction="ifRoom"
        android:title="Share"
        android:actionProviderClass= "android.widget.ShareActionProvider" />
</menu>

The ShareActionProvider is built-in (hence the android.widget prefix) and ready-to-use. So, when a user selects your menu item, the necessary functionality is already in place for you to make use of.

Now head over to MainActivity.java and add the following variable at the top of the file (where the previous variables are):

ShareActionProvider mShareActionProvider;

Next, you need to add the following two methods to the class - the first one, onCreateOptionsMenu, might already be implemented in the class. If it is, simply replace the existing implementation with the new one.

@Override
public boolean onCreateOptionsMenu(Menu menu) {
 
	// Inflate the menu.
	// Adds items to the action bar if it is present.
	getMenuInflater().inflate(R.menu.main, menu);
 
	// Access the Share Item defined in menu XML
	MenuItem shareItem = menu.findItem(R.id.menu_item_share);
 
	// Access the object responsible for
	// putting together the sharing submenu
	if (shareItem != null) {
		mShareActionProvider = (ShareActionProvider)shareItem.getActionProvider();
	}
 
	// Create an Intent to share your content
	setShareIntent();
 
	return true;
}
 
private void setShareIntent() {
 
	if (mShareActionProvider != null) {
 
		// create an Intent with the contents of the TextView
		Intent shareIntent = new Intent(Intent.ACTION_SEND);
		shareIntent.setType("text/plain");
		shareIntent.putExtra(Intent.EXTRA_SUBJECT, "Android Development");
		shareIntent.putExtra(Intent.EXTRA_TEXT, mainTextView.getText());
 
		// Make sure the provider knows
		// it should work with that Intent
		mShareActionProvider.setShareIntent(shareIntent);
	}
}

onCreateOptionsMenu gets called once, when the activity first starts. Similar to how you specified which layout XML file you wanted to use for the activity in onCreate, you now direct the menu inflater to look at main.xml for the menu items that go on the Action Bar.

From there, you can access the menu item you defined in XML by its id, menu_item_share, and then you can access its action provider. Previously, you specified that this item's action provider was a ShareActionProvider. So, you can safely cast to that type in your code and hang onto a reference to it via the mShareActionProvider variable.

Then, you call setShareIntent. This method creates an Intent, but not just any Intent. It creates an Intent whose action you've set to ACTION_SEND. It's truly as generic as it looks: you're going to tell Android you want to take the action of sending something.

From there, you set the Intent's content type, subject — used by email programs and the like, as the subject header of the message —, and text. The text matches whatever is currently in your TextView. After you’ve packed up everything the Intent needs to know, you pair it with mShareActionProvider.

This code will work, but only "kind of." As-is, you only call setShareIntent once, at the creation of the menu. It would be much better to update the Intent whenever the TextView changes — otherwise you're stuck with the initial message forever!

Add the following code to the end of onClick:

	// 6. The text you'd like to share has changed,
	// and you need to update
	setShareIntent();

Here, you simply make sure that the share intent is always up-to-date.

Run the app, and try out the new sharing feature - tapping the share icon on the Action Bar should reveal a lot of choices!

The ShareActionProvider automatically puts together an array of possible avenues for sharing content based on the apps you have installed on a given device. This array of options will differ from device to device. The emulator will most likely have far fewer options for sharing, whereas you may have apps like Twitter and Facebook on an actual device and could share through those networks, too.

Remembering Your Name

Everything you've done so far with regard to user input only persists while the app is running. But what about between sessions? Let's see some data persistence in action, with a new feature that will record and remember your name each time you open the app.

There are a few good options on Android to persist data, and the simplest one is SharedPreferences.

SharedPreferences stores data in key-value pairs, meaning that you specify a name (the key) for a piece of data (the value) when you save it, and you can retrieve it later by using the original key.

Let's see how it works in action, shall we?

First, add the following constants and variable to MainActivity.java (to the same place as the previous variables):

	private static final String PREFS = "prefs";
	private static final String PREF_NAME = "name";
	SharedPreferences mSharedPreferences;

The above sets PREF and PREF_NAME at the top of the class. You’ll use PREF as a filename to keep your SharedPreferences in a single location. You’ll use PREF_NAME as the key for storing your name in shared preferences.

The final line adds a variable named mSharedPreferences for storing a reference to the shared preferences class. You only need to access it in a few places, but it will be useful to hang onto it.

Next, add the following lines to the end of onCreate:

		// 7. Greet the user, or ask for their name if new
		displayWelcome();

The new code calls a new method, displayWelcome. So implement that by adding the following code:

	public void displayWelcome() {
 
		// Access the device's key-value storage
		mSharedPreferences = getSharedPreferences(PREFS, MODE_PRIVATE);
 
		// Read the user's name,
		// or an empty string if nothing found
		String name = mSharedPreferences.getString(PREF_NAME, "");
 
		if (name.length() > 0) {
 
			// If the name is valid, display a Toast welcoming them
			Toast.makeText(this, "Welcome back, " + name + "!", Toast.LENGTH_LONG).show();
		}
	}

In the new method, the first thing you do is access SharedPreferences, with MODE_PRIVATE meaning that only your OMGAndroid app can access the data stored here. This means that your saved data will not get overwritten by another application which might have used the same key as you.

Then you simply ask the preferences object for whatever value is stored using the key PREF_NAME. The second parameter for the method can be used to set a default value to be returned in case there is no value stored using the key you provide. So, you use an empty String as the default value here.

Finally, you check to see if the retrieved String actually has any content, and display a message if so. Your message takes the form of a Toast, which is a short-lived pop-up message that appears for a bit and then fades away. Give the Toast a message it should display, specify one of its built-in lengths to remain on the screen and then simply tell it to show. Easy!

Displaying the Name Dialog

What you've set up so far will show your name if the application can retrieve it out of the preferences. But obviously, that's no use to you yet since you have no mechanism in place to save your name in the first place!

You'll use a Dialog to achieve that. Dialogs are small windows that alert the user. They may contain ways for the user to provide input or make choices. You're going to use an AlertDialog, specifically.

Add the following code to the end of displayWelcome, creating an else branch for the if condition that's already there:

	} else {
 
			// otherwise, show a dialog to ask for their name
			AlertDialog.Builder alert = new AlertDialog.Builder(this);
			alert.setTitle("Hello!");
			alert.setMessage("What is your name?");
 
			// Create EditText for entry
			final EditText input = new EditText(this);
			alert.setView(input);
 
			// Make an "OK" button to save the name
			alert.setPositiveButton("OK", new DialogInterface.OnClickListener() {
 
				public void onClick(DialogInterface dialog, int whichButton) {
 
					// Grab the EditText's input
					String inputName = input.getText().toString();
 
					// Put it into memory (don't forget to commit!)
					SharedPreferences.Editor e = mSharedPreferences.edit();
					e.putString(PREF_NAME, inputName);
					e.commit();
 
					// Welcome the new user
					Toast.makeText(getApplicationContext(), "Welcome, " + inputName + "!", Toast.LENGTH_LONG).show();
				}
			});
 
			// Make a "Cancel" button 
			// that simply dismisses the alert
			alert.setNegativeButton("Cancel", new DialogInterface.OnClickListener() {
 
				public void onClick(DialogInterface dialog, int whichButton) {}
			});
 
			alert.show();
	 }

The app will reach this else condition when there is no valid name saved using the PREF_NAME key. You use an AlertDialog.Builder to give your AlertDialog a title, a message, and an EditText in the center for the user to type in their name.

Then, you add two buttons to the AlertDialog: a positive and a negative button. The first thing you define for each is the text displayed on the button - "OK" and "Cancel" are pretty standard choices. The second thing you define for each button is an OnClickListener.

This time your OnClickListeners are specifically DialogInterface.OnClickListeners, and you are defining them right away. Notice how the parameters for onClick are slightly different.

For the positive button's listener, onClick does quite a bit. First, it reads the name that the user typed into the dialog's EditText.

It then saves that name into SharedPreferences using a helper called a SharedPreferences.Editor. You simply tell the editor what to save and where, tell it to commit the changes, and that's it!

Finally, it displays a Toast identical to the other welcoming one.

The negative button's listener is far simpler: it does nothing! Nothing!

Run your app and check out your Dialog.

Type in your name, press OK and see the Toast greeting. From now on, your app will remember your name and greet you each time you launch it!

Where to Go From Here?

You covered a lot of UI concepts in this part of the tutorial! Take a few minutes to play around with your app a little, maybe sharing something with a friend!

You can get the full source code for this part of the tutorial on GitHub or as a .zip.

Those looking for a challenge should try:

• Implementing the Dialog you just made as a DialogFragment, as in the example here.
• Setting up the EditText to expect names as its input so that it capitalizes first letters.
• Dismissing the keyboard associated with the EditText.
• Making the Done button on the keyboard do the same thing as the Update TextView button.
• Modifying font sizes on the various views.

Hopefully you have found this helpful! If you have any comments or questions, feel free to leave them below. And of course, don't miss Part Three, in which you set up your app to interact with data online!

The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

Make Your First Android App: Part 2/3 is a post from: Ray Wenderlich

The post Make Your First Android App: Part 2/3 appeared first on Ray Wenderlich.

This tutorial is the third and final part of the series devoted to helping you make your first Android app! Check out Part One to get started with Android and Part Two to learn more about Android UI and project structure.

In this final part of the tutorial, you’ll learn how to leverage the powerful capabilities of the web to search and display data and images. More specifically, you’ll make an app that searches the Open Library API — a database of over 20 million books —, displays information and cover images of the books it finds, and allows you to recommend books to friends!

When you’re done, you’ll know how to:

• Add powerful third-party libraries to your app via Gradle;
• Access a typical RESTful API;
• Understand JSON format and parse JSON results;
• Responsibly download web images without affecting your UI performance;
• Customize list cells with multiple views; and
• Build intuitive native app navigation between activities.

These are very useful and transferable skills for all sorts of Android apps you’ll want to make in the future.

To begin this part of the tutorial, you should be at the point where you have an app that takes user input, lists names, and shares messages through social networks. Your app should also ask for your name when you first open the app and greet you by name thereafter.

So the personal part is done — now it’s time to interwebify!

Getting Started

It’s time to do a bit of rebranding. No longer is this just a little demo app — it is a book search and recommendation engine!

The default Android icon can only take you so far. Download the following files and drag them onto the src/main/res/drawable-hdpi directory to add them to your project:

• ic_books.png
• img_books_large.png
• img_books_loading.png

Click OK when asked to confirm the move.

Your src/main/res/drawable-hdpi directory should now look something like this:

Open AndroidManifest.xml. As you recall, this is “the boss” of your app. If you want to change the app’s icon, you need to talk to the boss.

Find the opening application tag and change the icon attribute line from:

	android:icon="@drawable/ic_launcher"

To:

	android:icon="@drawable/ic_books"

From now on, the app icon will be a stack of books instead of the default Android icon. Depending on your Studio version (and/or SDK version) you may also see that the application has an attribute for setting the application name. You’re going to update the application name as well, but not in the manifest.

First, while you’re still looking at the manifest, you need to let the manifest know that you plan to start accessing the Internet. Between the uses-sdk and application tags, add the following:

<!-- NEED TO ADD TO BE ABLE TO GO ONLINE AND GET DATA -->
<uses-permission android:name="android.permission.INTERNET"/>

If you don’t let “the boss” know your plans, it won’t file the appropriate paperwork with Android to make the web call happen. But now you’re good to go.

Now it’s time to change your app’s name. Open res/values/strings.xml and replace the strings for everything except action_settings with the following new values:

<string name="app_name">Bookmaster General</string>
<string name="textview">Search For Books!</string>
<string name="button">Search</string>
<string name="hint">Title and/or Author</string>

That’s right — I used the title Bookmaster General.

Finally, remove this line from onCreate in MainActivity.java:

mainTextView.setText("Set in Java!");

Run your app, you should see the new icon in the top left corner and the new application name on the Action Bar.

Your device or emulator’s home screen should also reflect the name and icon updates. For example:

Now that you’ve rebranded your app, it’s time to start adding the web interactions!

Networking Considerations

There are a lot of things to keep in mind when adding networking capabilities to your app. For example, you need to consider how to keep all the network interactions off the UI thread, so that the user can continue to use your app without everything locking up until a download completes. If you were using an app and it became completely unresponsive for lengths of time, you’d get pretty frustrated!

Thankfully, you can solve issues such as this by simply using third-party libraries. These have been specially designed and supported by Android experts to facilitate networking. Some of the most well-regarded include Retrofit, Volley, and Android Async Http. For the purposes of this tutorial, you’ll use Android Async Http.

Image downloads are also a consideration since each image takes time to download. Also, in the case of a list of books, if you have your list set to download images as needed, you might find that you end up downloading the same image over and over as your user scrolls through the list of items. You really don’t want that type of behavior. You’ll use another third-party library called Picasso to manage image downloads for you.

A way to easily manage your project’s dependencies would sure be great! That leads us to Gradle.

A Glance at Gradle

When you created your project in Android Studio, you may remember mentions of Gradle and Maven. Refer to Part One if you need a reintroduction. Now you’ll see them in action.

Open OMGAndroid/build.gradle. Note that there are two build.gradle files in your project. You want the one that’s within the OMGAndroid folder – not the one at the project root level:

Some of the stuff happening in here is beyond the scope of this tutorial, but if you become serious about Android development, I recommend looking into Gradle a little more, starting of course, with the Gradle website. For now, just notice that the Android plugin is being applied to the project (apply plugin: 'android').

You might also see a reference to the Maven Central Repository (mavenCentral()) but depending on on Android Studio changes, the Maven Central references could also have moved to the other build.gradle file. Suffice it to say that if you see a line similar to mavenCentral(), that’s setting up a reference to the Maven Central Repository.

Scroll down to the area labeled dependencies. There might be two places this word appears (again, depending on the Android Studio version); you want the one that at the end of the file, after the android section. There may already be a support library listed there, or it may be empty. You’re going to add two new libraries.

Add the libraries like this:

dependencies {
 
	...
 
	// there may or may not be a support library above these
	compile 'com.loopj.android:android-async-http:1.4.4'
	compile 'com.squareup.picasso:picasso:2.1.1'
}

Then find the Sync Project with Gradle Files button on the Studio toolbar and press it. It looks like this:

Believe it or not, that’s it! Just like that, you’ve included the Android Async Http and Picasso libraries in your project and you can start using them whenever you like.

It’s so easy because both of these libraries are available via the Maven Central Repository, to which your project already contains a reference. So, when you tell Gradle which libraries you’d like to use, it simply grabs them from the source and you’re good to go.

If you need to include any libraries which are not available on the Maven Central Repository, then you’d still have to go through the old school method of copying the source (or the library) into your project. But most of the time, you won’t have to go through all that pain since the Maven Repository contains a lot of third-party libraries for you to use. So you’ll probably be able to find an alternative to the library you’re interested in. If interested, you can even browse all the libraries available on the Maven Repository.

JSON Basics

Great! Now it’s time to meet your datasource: the Open Library API. It’s a constantly-updated database of books, searchable by author and title. The wealth of data is enormous!

Try this query as an example: http://openlibrary.org/search.json?q=hunger+games+suzanne+collins

This is a relatively simple URL to understand; whatever is typed in after the ?q= is the query string that will be used to search the database. Feel free to change it to a different author name/title and compare results, remembering to use + to separate words.

The result is in the form of a large JSON response. Take a minute to look around at the sort of data the response includes.

If you’re not familiar with the JSON format, I suggest a quick glance through the JSON page. The basics are that there are two ways data can be arranged in JSON: arrays and objects.

JSONArrays list objects of the same type. For example, a list of books might look like this:

JSONObjects are a collection of key-value pairs. For example, a very simple object describing a book might be:

The results from your queries to the Open Library API are really just expansions on those two basic structures. They are larger, and nested into several levels, but the ideas remain the same.

Creating a Query

Now that you know roughly what to expect from the datasource, it’s time to set up the code to go make a sample query!

Add the following variable at the top of MainActivity.java:

	private static final String QUERY_URL = "http://openlibrary.org/search.json?q=";

The above is simply a reference to the URL you’ll be calling. It’s much better to hold this URL as a static String, so you don’t have to go searching through your code for it. Remember that you’re going to append the search string after the ?q=.

Next, add this new method:

	private void queryBooks(String searchString) {
 
		// Prepare your search string to be put in a URL
		// It might have reserved characters or something
		String urlString = "";
		try {
		   urlString = URLEncoder.encode(searchString, "UTF-8");
		} catch (UnsupportedEncodingException e) {
 
			// if this fails for some reason, let the user know why
			e.printStackTrace();
			Toast.makeText(this, "Error: " + e.getMessage(), Toast.LENGTH_LONG).show();
		}
 
		// Create a client to perform networking
		AsyncHttpClient client = new AsyncHttpClient();
 
		// Have the client get a JSONArray of data
		// and define how to respond
		client.get(QUERY_URL + urlString,
				new JsonHttpResponseHandler() {
 
					@Override
					public void onSuccess(JSONObject jsonObject) {}
 
					@Override
					public void onFailure(int statusCode, Throwable throwable, JSONObject error) {}
				});
	}

queryBooks handles the network call to the API. It encodes the input searchString into URL format, then appends that to the base URL you specified at the top of the class.

Calling new AsyncHttpClient() simply creates an instance of the HTTP client. It’s got a lot of great methods built-in, but the only one you need here is get(String url, ResponseHandlerInterface responseHandler).

The get method takes in two parameters:

• String url is simply the URL from which you’d like to fetch data. You supply an input made of the base URL defined at the top of the class, plus the search string.
• JsonHttpResponseHandler, which you define now, even though you don’t know whether the network call will succeed or fail, or how long it will take either way. It contains methods called onSuccess and onFailure to respond to the two cases once the handler does get a response from the server.

You might have noticed that onSuccess and onFailure are currently method stubs with no code. Fix that by fleshing out the onSuccess to match the following:

@Override
public void onSuccess(JSONObject jsonObject) {
	// Display a "Toast" message
	// to announce your success
	Toast.makeText(getApplicationContext(), "Success!", Toast.LENGTH_LONG).show();
 
	// 8. For now, just log results
	Log.d("omg android", jsonObject.toString());
}

Next, implement onFailure as follows:

@Override
public void onFailure(int statusCode, Throwable throwable, JSONObject error) {
	// Display a "Toast" message 
	// to announce the failure
	Toast.makeText(getApplicationContext(), "Error: " + statusCode + " " + throwable.getMessage(), Toast.LENGTH_LONG).show();
 
	// Log error message
	// to help solve any problems
	Log.e("omg android", statusCode + " " + throwable.getMessage());
}

In both cases, you simply present a Toast and log the results. Soon, though, the success case will get a lot more exciting.

Making the API Call

queryBooks is a great method and all, but it still needs to be hooked up to the EditText and Button to complete the search capability.

Fortunately, that’s pretty simple. In MainActivity.java, find onClick and replace the current implementation with this:

	// 9. Take what was typed into the EditText and use in search
	queryBooks(mainEditText.getText().toString());

Now, every time the user taps the button, this method takes the user’s input in the EditText control and queries the Open Library for books and authors matching that string. Run your app and try it out to see what happens!

Remember that you haven’t yet hooked up the results to anything that will display them on the screen. But open LogCat and you can see the resulting JSON spilled out whenever the API call finishes.

This is already exciting and clearly has the potential to be something cool very soon! But it’s still just a jumble of data. Your next challenge, then, is to display this data on the screen in a more organized manner.

Creating the List Rows

First, you need to set up the layout for each of the rows in your list. A simple row of text won’t cut it anymore — you need space for a thumbnail image on the left and then two rows of text for the title and author, respectively. A layout which would look something like this:

Right-click on the res/layout folder in the Studio left pane, and select New > Layout resource file.

Name your file row_book.xml with a root element of RelativeLayout.

The new file will open in Design mode. So, switch to Text mode, as before. Now change the layout_height attribute from this:

	android:layout_height="match_parent"

To this:

	android:layout_height="75dp"

You simply set the layout to have a specific height instead of matching the height of the parent container.

Next, you’re going to add three views inside the RelativeLayout, and then you’ll witness a few of the capabilities of this type of layout in action. First, add the thumbnail view:

<ImageView
    android:id="@+id/img_thumbnail"
    android:layout_width="50dp"
    android:layout_height="50dp"
    android:layout_marginLeft="25dp"
    android:layout_alignParentLeft="true"
    android:layout_centerVertical="true"
    android:scaleType="centerInside"/>

The ImageView has the width and height set and there’s a little margin to the left of the picture. This is stuff you’ve seen before.

Then it gets interesting with layout_alignParentLeft and layout_centerVertical. These attributes are available since this ImageView is a child of a RelativeLayout. Because of these two attributes, the ImageView stays tight to the left of the cell with that margin intact, and centers vertically.

The last attribute, scaleType, specifies how you’d like the image to display within the amount of space it’s given. Especially given the unpredictable list of screen sizes you’d have to support, it’s often important to set this beforehand.

Using centerInside means that you’ll preserve the aspect ratio of the image and that both dimensions will fit inside the given space. You might, however, have some blank space above and below the image if it’s too short, or space on the sides if it’s too thin. If you’re interested, you can read up on the various ScaleType options.

Next, add a TextView for the book’s title:

<TextView
    android:id="@+id/text_title"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_marginLeft="25dp"
    android:layout_toRightOf="@+id/img_thumbnail"
    android:layout_alignTop="@+id/img_thumbnail"/>

Read through the XML first and see if you can tell what’s going on. The commands should be starting to make a bit of sense by now. The only thing that might give you pause might be the @+id/img_thumbnail bit – but that’s just a reference to another control by ID. In this case, the ID refers to the ImageView you added previously.

Basically, the title will sit to the right of the thumbnail, such that the top of the title will be at the same height as the top of the thumbnail. There’s some space in between the two controls, as well.

Finally, add the TextView for the author’s name:

<TextView
    android:id="@+id/text_author"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_below="@+id/text_title"
    android:layout_alignLeft="@+id/text_title"/>

By now, these attributes should all make sense. The author’s name will be below the title, with its left side aligned to that of the title.

Adapting JSON for a ListView

In Part Two, you made a ListView, at which point I mentioned that ListViews are a bit picky. They don’t want to deal with the data directly — you can hardly blame them after seeing that confusing JSON response that popped into LogCat earlier. The simple, built-in adapter you used in Part Two won’t cut it here; you need a custom one.

Right-click on the com.example.omgandroid folder (or whatever package name you used when creating the project) and select New > Java Class.

Then type in JSONAdapter as the new class name.

Once you have your new class open in the editor, add the following code so the class looks like this:

public class JSONAdapter {
 
	private static final String IMAGE_URL_BASE = "http://covers.openlibrary.org/b/id/";
 
	Context mContext;
	LayoutInflater mInflater;
	JSONArray mJsonArray;
 
	public JSONAdapter(Context context, LayoutInflater inflater) {
		mContext = context;
		mInflater = inflater;
		mJsonArray = new JSONArray();
	}
}

This is still just a basic class, beginning with the first part of the URL you’ll use to download images — more on that when you implement the image download code.

Next, there are three simple variables:

• A Context. This is a complex topic, but basically you only need it to tell Picasso, the image downloader library, what is going on in the app when you tell Picasso to get working.
• A LayoutInflater. You need this to inflate a View out of that list item XML you just wrote.
• A JSONArray. This is the datasource that will be coming in from the server in response to your query!

The JSONAdapter method is the class constructor – that’s what you call when you create a new instance of JSONAdapter. So, anyone who wants to ask JSONAdapter to do anything has got to create an instance of it first, which in turn requires submitting the Context and LayoutInflater via the constructor.

The constructor currently simply saves the passed in references and creates an empty JSONArray. You’ll pass the real data to the class after the search results are in.

Now you need to convert this class into an actual Adapter class. This is quite easy in an object-oriented programming language like Java – simply change the top line of the class from:

public class JSONAdapter {

To:

public class JSONAdapter extends BaseAdapter {

Right away, Android Studio will underline the line you just modified in red to let you know that you need to add more to JSONAdapter before it accurately extends BaseAdapter. Studio isn’t just a naysayer, though — it can help, too! Click underlined line, then click the red light bulb that pops up next to it, and then select Implement Methods from the menu.

When asked to select methods to implement, make sure all four methods are highlighted and click OK.

Magically, Android Studio creates four methods for you and the red underlining disappears. This means that you’ve satisfactorily extended BaseAdapter.

But… all the methods are empty. It’s time to go through each one in turn and make them do what you want.

So, first replace the current implementation for getCount with the following:

@Override 
public int getCount() {
	return mJsonArray.length();
}

getCount answers the question: How long does your ListView need to be? In this example, the answer is simply the length of your JSONArray. Each entry in that array represents a book and so each one gets a row in the ListView.

Now replace getItem with this version:

@Override 
public JSONObject getItem(int position) {
	return mJsonArray.optJSONObject(position);
}

getItem returns the book for a given position, counting up from 0. A single book is represented by a JSONObject. They all just happen to be store in a JSONArray. So all you have to do is look through the array for the JSONObject at the given position.

Next, replace the stub for getItemId with this code:

@Override 
public long getItemId(int position) {
	// your particular dataset uses String IDs
	// but you have to put something in this method
	return position;
}

This can be a very helpful method in some situations, but in this case, you don’t really need it. So, you just set it to position. Imagine a situation where you have a list of books, as a subset of a larger database, and each book has an ID in the larger database. If you needed to go back and query for more information based on a certain item’s ID number, this method would be helpful for you.

Putting Together the Insta-Row

The last method, getView, answers the ListView when it comes to the adapter and asks: What should I show at position X?

To begin to answer that question, you first need to create what’s called a view holder. Add the following to the end of your JSONAdapter code (but before the final closing curly brace):

// this is used so you only ever have to do
// inflation and finding by ID once ever per View
private static class ViewHolder {
	public ImageView thumbnailImageView;
	public TextView titleTextView;
	public TextView authorTextView;
}

This class is simply a packager of the three subviews that every row in your list will have. Think of it as a Do-It-Yourself kit for your list cells. All each row needs to do is get one of these, update it with the right data based on the row and presto: an Insta-Row!

The trick is that as you scroll around through who-knows-how-many books in your list, the app shows the data using the same cells, over and over. There are only just enough list cells to fill the screen, plus a few extras. Keeping all of the list cells in memory, even while they’re off-screen, would get crazy!

As a view scrolls out of sight, the recycling crew comes by and dumps out everything inside the view, but hangs onto the ViewHolder. That same view, and the ViewHolder, then get handed over to a list cell about to scroll into sight.

The re-used view is handed one of these ready-made Insta-Row kits (aka a ViewHolder), and simply fills the contents of each subview as needed, rather than inflating a brand new view from XML and creating all those subviews from scratch every single time.

For more details on the view recycling process, here is a helpful blog post about it.

With that in mind, replace the stub for getView with this code:

@Override 
public View getView(int position, View convertView, ViewGroup parent) {
	ViewHolder holder;
 
	// check if the view already exists
	// if so, no need to inflate and findViewById again!
	if (convertView == null) {
 
		// Inflate the custom row layout from your XML.
		convertView = mInflater.inflate(R.layout.row_book, null);
 
		// create a new "Holder" with subviews
		holder = new ViewHolder();
		holder.thumbnailImageView = (ImageView) convertView.findViewById(R.id.img_thumbnail);
		holder.titleTextView = (TextView) convertView.findViewById(R.id.text_title);
		holder.authorTextView = (TextView) convertView.findViewById(R.id.text_author);
 
		// hang onto this holder for future recyclage
		convertView.setTag(holder);
	} else {
 
		// skip all the expensive inflation/findViewById
		// and just get the holder you already made
		holder = (ViewHolder) convertView.getTag();
	}
	// More code after this
 
	return convertView;
}

If it happens to be the first time for the view, then you need to use your custom row XML using mInflater and find all your subviews using findViewById. But as mentioned earlier, the view might already exist — in which case you want to skip all that from-scratch stuff.

You use the setTag and getTag methods to hang onto the ViewHolder and easily pack/unpack it while scrolling around.

Next, you need to handle the image thumbnail of the book’s cover. Put this new code right after the // More code after this comment line:

	// Get the current book's data in JSON form
	JSONObject jsonObject = (JSONObject) getItem(position);
 
	// See if there is a cover ID in the Object
	if (jsonObject.has("cover_i")) {
 
		// If so, grab the Cover ID out from the object
		String imageID = jsonObject.optString("cover_i");
 
		// Construct the image URL (specific to API)
		String imageURL = IMAGE_URL_BASE + imageID + "-S.jpg";
 
		// Use Picasso to load the image
		// Temporarily have a placeholder in case it's slow to load
		Picasso.with(mContext).load(imageURL).placeholder(R.drawable.ic_books).into(holder.thumbnailImageView);
	} else {
 
		// If there is no cover ID in the object, use a placeholder
		holder.thumbnailImageView.setImageResource(R.drawable.ic_books);
	}

In this section, you first get the JSONObject for the precise book whose data you want to display. Of course, this is dependent on the item’s position in the list.

Next, you check to see if there’s a cover ID for that book. Unfortunately, many books don’t have covers in the Open Library database. So, you look to see if a cover is there by calling has("cover_i"), which returns a true-or-false boolean. If it returns true, then you parse out the cover ID from the JSONObject and use it to construct a URL specific to Open Library.

Once you have the URL, you simply tell Picasso to download it and display it in your ImageView. You also specify a placeholder image to show while the cover image is downloading.

If the book doesn’t have a cover assigned, you show the standard icon.

Finally, you need to populate the book title and author name. So, add the following code immediately after the block of code you added above:

	// Grab the title and author from the JSON
	String bookTitle = "";
	String authorName = "";
 
	if (jsonObject.has("title")) {
		bookTitle = jsonObject.optString("title");
	}
 
	if (jsonObject.has("author_name")) {
		authorName = jsonObject.optJSONArray("author_name").optString(0);
	}
 
	// Send these Strings to the TextViews for display
	holder.titleTextView.setText(bookTitle);
	holder.authorTextView.setText(authorName);

This step is similar to the last. As long as the JSONObject contains the title and author name, you parse the values and set the text of each TextView!

Connecting the List to the Adapter

The last thing you need to do before you can test your newly-webified app is connect the ListView to the JSONAdapter.

Remove the following code from onCreate in MainActivity.java:

// Create an ArrayAdapter for the ListView
mArrayAdapter = new ArrayAdapter(this,
		android.R.layout.simple_list_item_1,
		mNameList);
 
// Set the ListView to use the ArrayAdapter
mainListView.setAdapter(mArrayAdapter);

Also remove the following from onItemClick in MainActivity.java:

// 5. Log the item's position and contents
// to the console in Debug
Log.d("omg android", position
		+ ": "
		+ mNameList.get(position));

You don’t need any of that simple stuff now that you’ve got your own souped-up Adapter!

Now, to start using the your adapter class, replace this line at the beginning of the class:

ArrayAdapter mArrayAdapter;

With this:

JSONAdapter mJSONAdapter;

Next, add the following to the end of onCreate:

	// 10. Create a JSONAdapter for the ListView
	mJSONAdapter = new JSONAdapter(this, getLayoutInflater());
 
	// Set the ListView to use the ArrayAdapter
	mainListView.setAdapter(mJSONAdapter);

Great! You just created an instance of your snazzy new JSONAdapter, feeding it a Context and a LayoutInflater. Now your adapter is hooked up and can provide your ListView with the data it needs.

If you were to build and run, though, you would be rather underwhelmed by the results. Even after inputting a search String, the ListView remains empty. Why?

Because, if you recall, you created your Adapter using its constructor, public JSONAdapter(Context context, LayoutInflater inflater). That method creates an empty JSONArray as a placeholder.

An empty list is OK to start with, of course, but it sure would be great to update the list when your search is done! That’s not happening yet, so that’s next on your agenda.

Updating the List Data

To update the list, you need to add an update method to your adapter and then call it from your activity.

First, add the following method to JSONAdapter.java:

public void updateData(JSONArray jsonArray) {
	// update the adapter's dataset
	mJsonArray = jsonArray;
	notifyDataSetChanged();
}

This method accepts a JSONArray input, sets it as the adapter’s datasource, and calls notifyDataSetChanged to refresh the list. The adapter is already set up to know what to do with the data, so that’s all you need!

Now go back to MainActivity.java. You’re going to use your new method to update the list when the network call comes back. Find the following code in onSuccess, which is embedded within queryBooks:

// 8. For now, just log results
Log.d("omg android", jsonObject.toString());

Replace it with this instead:

// update the data in your custom method.
mJSONAdapter.updateData(jsonObject.optJSONArray("docs"));

This is simply a call to updateData with the newly-returned query response. As soon as the data comes back, you don’t waste any time — you send it straight to the adapter, which whips it into shape for the ListView!

It’s finally time — run your app, and search away!

Now you can type a search string into your EditText, tap the Search button and let the ListView (somewhat) magically populate from your web search. Not only that — you can scroll through all the results and look at book titles, author names, and thumbnails of the cover images. This is already a pretty cool app!

Showing Progress

One nice feature you may notice missing is some kind of progress bar or spinner to let the user know your app is “thinking.” There’s a convenient place to show one on Android — the Action Bar.

Add the following to onCreate in MainActivity.java, before everything else in the method except the call to super:

	// 11. Add a spinning progress bar (and make sure it's off)
	requestWindowFeature(Window.FEATURE_INDETERMINATE_PROGRESS);
	setProgressBarIndeterminateVisibility(false);

This whole request business simply gives you easy access to the progress bar when you need it. The place to turn it on is right as your network query begins, so add this line to queryBooks, immediately after creating your AsyncHttpClient:

// 11. start progress bar
setProgressBarIndeterminateVisibility(true);

You want the spinner to stop when the request is over, which could actually be in one of two spots – onSuccess or onFailure. Add the following line at the very beginning of onSuccess:

	// 11. stop progress bar
	setProgressBarIndeterminateVisibility(false);

And add the same line to the beginning of onFailure:

	// 11. stop progress bar
	setProgressBarIndeterminateVisibility(false);

Now, run the app again and do another search.

This time, you’ll notice a progress indicator pop up and start spinning in the Action Bar as your networking calls happen. Much better!

The Detail Activity

Seeing the list of all the books is exciting! The next logical step is to let the user select a book from the list to see more details or a larger version of the cover.

For this app, you’ll only show a larger version of the cover. But the techniques you use will pave the way for the additional challenge of displaying any further details that may interest you. Let’s get started!

First, add the following line to res/values/strings.xml:

<string name="activity_details">Book Details</string>

This is simply to provide a title for the activity. As mentioned before, it’s good to keep all the strings in one file!

Next is the layout XML. It won’t be complicated. Right-click on res/layout and select New > Layout Resource File.

Name it activity_detail.xml, with a Root Element of ImageView.

That’s almost it right there. All you need to do now is give the ImageView an id, a default image, and a bit of margin space for good measure. Edit activity_detail.xml to look like this:

<?xml version="1.0" encoding="utf-8"?>
<ImageView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/img_cover"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:layout_margin="25dp"
    android:src="@drawable/img_books_large"/>

That’s simple enough. This screen will now show a single ImageView with a 25dp margin all around, and the default image is img_books_large.

Next, you need to make a new Activity. Right-click on the com.example.omgandroid package (or the package name you set originally) and select New > Java Class, as before.

Name the class DetailActivity.

This creates a simple, empty class for you. Next, modify the class definition so that your new class extends Activity, like this:

public class DetailActivity extends Activity {

You already know you need to access the ImageView from your layout, so add the following method to your activity:

@Override
protected void onCreate(Bundle savedInstanceState) {
	super.onCreate(savedInstanceState);
 
	// Tell the activity which XML layout is right
	setContentView(R.layout.activity_detail);
 
	// Enable the "Up" button for more navigation options
	getActionBar().setDisplayHomeAsUpEnabled(true);
 
	// Access the imageview from XML
	ImageView imageView = (ImageView) findViewById(R.id.img_cover);
}

The above code simply tells the Activity to use the simple XML layout you made earlier, and then grabs the ImageView you need from it. But wait: what is that getActionBar stuff doing in there?

The Up and Back Buttons

You may have noticed, or simply used it without really thinking about it, the Up button in many Android apps. The proper Android design of the Up and Back buttons is well-documented here and is worth a read, but it all begins with enabling the button as you just did.

The other steps for enabling the Up button take place in your manifest. Open AndroidManifest.xml and add the launchMode attribute to MainActivity so that it looks something like this:

<activity
    android:name="com.example.omgandroid.MainActivity"
    android:label="@string/app_name"
    android:launchMode="singleTop">

So, do you remember my whole spiel about how the manifest is “the boss” who takes in “jobs” in the form of Intents and checks if there is a team member right for the task? Normally, the manifest would arrange for the system to start a brand-new instance of that Activity every time.

But, by setting the launchMode attribute to singleTop, you’re telling the manifest to use an already-existing instance of that Activity, if possible. That way, when you use either the Back or Up button to return to the main screen, your most recent search results will still be there and you won’t have to start from scratch!

Next, add a definition for the DetailActivity to the manifest, immediately after the one for MainActivity:

<activity
    android:name=".DetailActivity"
    android:label="@string/activity_details"
    android:parentActivityName=".MainActivity">
    <meta-data
        android:name="android.support.PARENT_ACTIVITY"
        android:value=".MainActivity"/>
</activity>

This looks pretty similar to the definition for MainActivity, except for the stuff about “parent activity.” Setting the parent activity tells the manifest which activity should be displayed when there’s a request to go up from DetailActivity.

An Intent to Show the Detail Activity

Now that you’ve set up your manifest to be aware of your DetailActivity, you need to send it an Intent to start it! This Intent is going to originate from the MainActivity, when the user selects a book from the list.

If you recall, the method that executes when a cell is selected from the ListView is onItemClick in MainActivity.java. It used to log information originally but now is empty. Add the following code to it:

	// 12. Now that the user's chosen a book, grab the cover data
	JSONObject jsonObject = (JSONObject) mJSONAdapter.getItem(position);
	String coverID = jsonObject.optString("cover_i","");
 
	// create an Intent to take you over to a new DetailActivity
	Intent detailIntent = new Intent(this, DetailActivity.class);
 
	// pack away the data about the cover 
	// into your Intent before you head out
	detailIntent.putExtra("coverID", coverID);
 
	// TODO: add any other data you'd like as Extras
 
	// start the next Activity using your prepared Intent
	startActivity(detailIntent);

Here, you create an Intent to take you from where you are now (this) to an instance of DetailActivity. But before you fire off the command using startActivity, there’s one more thing to remember to pack away.

As you’ve previously seen when you created setShareIntent, you can pack “extras” into an Intent in the form of key-value pairs. Since your DetailActivity needs to know the cover ID to display, you extract that ID from the book’s JSON data and send it along.

Build and run your app, and you will be able to click on a list item from your search results to see your new DetailActivity! You can also navigate back to the main screen using either the Up or Back button.

Right now, you only see the placeholder image, but you know where this is headed :]

Add the following variables at the beginning of DetailActivity.java (right after the class definition line):

	private static final String IMAGE_URL_BASE = "http://covers.openlibrary.org/b/id/"; // 13
	String mImageURL; // 13

This sets the base URL for cover images on the Open Library API. You also create mImageURL to hang onto any specific URL so that different methods within your Activity can use it without needing to create the image URL all over again each time.

Next, add the following code to the end of onCreate:

		// 13. unpack the coverID from its trip inside your Intent
		String coverID = this.getIntent().getExtras().getString("coverID");
 
		// See if there is a valid coverID
		if (coverID.length() > 0) {
 
			// Use the ID to construct an image URL
			mImageURL = IMAGE_URL_BASE + coverID + "-L.jpg";
 
			// Use Picasso to load the image
			Picasso.with(this).load(mImageURL).placeholder(R.drawable.img_books_loading).into(imageView);
		}

The above code digs into the Intent that brought you to this Activity and sees if it contains a String with the name coverID. If so, you proceed to use Picasso to download the image, just as you did in all the row cells. You display a “loading” image until the desired image is ready.

Build and run, and you’ll see the actual cover for the book you chose from the list!

Sharing the Image

The last thing to do is allow your users to share these cover images. You’ve already seen sharing in action and the code is almost identical here.

First, add another variable to DetailActivity.java:

	ShareActionProvider mShareActionProvider; // 14

This is just another variable to hold a reference to the ShareActionProvider for your Activity.

Next, add this new method to the class:

	private void setShareIntent() {
 
		// create an Intent with the contents of the TextView
		Intent shareIntent = new Intent(Intent.ACTION_SEND);
		shareIntent.setType("text/plain");
		shareIntent.putExtra(Intent.EXTRA_SUBJECT, 
			"Book Recommendation!");
		shareIntent.putExtra(Intent.EXTRA_TEXT, mImageURL);
 
		// Make sure the provider knows 
		// it should work with that Intent
		mShareActionProvider.setShareIntent(shareIntent);
	}

This should look very familiar, as it is nearly the same as the method you added to MainActivity earlier. The only difference is the use of mImageURL as the text to be shared.

One final thing left to do – you need to add the share button to the Action Bar. You can again reuse code from MainActivity. Add this method to DetailActivity.java:

@Override
public boolean onCreateOptionsMenu(Menu menu) {
 
	// Inflate the menu
	// this adds items to the action bar if it is present.
	getMenuInflater().inflate(R.menu.main, menu);
 
	// Access the Share Item defined in menu XML
	MenuItem shareItem = menu.findItem(R.id.menu_item_share);
 
	// Access the object responsible for 
	// putting together the sharing submenu
	if (shareItem != null) {
		mShareActionProvider 
			= (ShareActionProvider) shareItem.getActionProvider();
	}
 
	setShareIntent();
 
	return true;
}

Here, you could potentially use different menu XML files to populate the Action Bar on different screens/activities. But for your purposes, the same menu/main.xml file will do.

Build and run your app, and you’ll have a pretty powerful app! Your app now takes in your search query, returns a list of books,allows you to take a closer look at a book cover, and share that cover image with friends!

Where to Go From Here?

Congratulations on putting together your app! This tutorial has introduced you to a variety of Android capabilities and techniques, and I hope you feel comfortable with the basics of development on the Android platform.

You can get the full source code for this app on GitHub or as a .zip.

If you’re looking for a few more challenges, how about trying some of these?

• Add a contentDescription attribute to your ImageViews for accessibility. Here’s an explanation.
• Display more details about the book in the Detail View, like more information about the book or even the first few lines of the book.
• Reposition some of the views to a different layout structure.
• Investigate android:background and add background colors to your layouts and views.
• Add a hashtag to the share text.

Thank you for following this tutorial series. Please leave any comments or questions below!

The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

Make Your First Android App: Part 3/3 is a post from: Ray Wenderlich

The post Make Your First Android App: Part 3/3 appeared first on Ray Wenderlich.

Learn how to make a game like Flappy Bird for iOS using Sprite Kit in this video tutorial, starting with making the bird flap!

Video Tutorial: How To Make a Game Like Flappy Bird Part 1: Player Movement is a post from: Ray Wenderlich

The post Video Tutorial: How To Make a Game Like Flappy Bird Part 1: Player Movement appeared first on Ray Wenderlich.

Learn how to use AFNetworking: an easy-to-use network API for iOS!

Update 1/18/2014: Fully updated for iOS 7 and AFNetworking 2.0 (original post by Scott Sherwood, update by Joshua Greene).

In iOS 7, Apple introduced NSURLSession as the new, preferred method of networking (as opposed to the older NSURLConnection API). Using this raw NSURLSession API is definitely a valid way to write your networking code – we even have a tutorial on that.

However, there’s an alternative to consider – using the popular third party networking library AFNetworking.

The latest version of AFNetworking (2.0) is now built on top of NSURLSession, so you get all of the great features provided there. But you also get a lot of extra cool features – like serialization, reachability support, UIKit integration (such as a handy category on asynchronously loading images in a UIImageView), and more.

AFNetworking is incredibly popular – it won our Reader’s Choice 2012 Best iOS Library Award. It’s also one of the most widely used, open-source projects with over 10,000 stars, 2,600 forks, and 160 contributors on Github.

In this AFNetworking 2.0 tutorial, you will learn about the major components of AFNetworking by building a Weather App that uses feeds from World Weather Online. You’ll start with static weather data, but by the end of the tutorial, the app will be fully connected to live weather feeds.

Today’s forecast: a cool developer learns all about AFNetworking and gets inspired to use it in his/her apps. Let’s get busy!

Getting Started

First download the starter project for this AFNetworking 2.0 tutorial here.

This project provides a basic UI to get you started – no AFNetworking code has been added yet.

Open MainStoryboard.storyboard, and you will see three view controllers:

From left to right, they are:

• A top-level navigation controller
• A table view controller that will display the weather, one row per day
• A custom view controller (WeatherAnimationViewController) that will show the weather for a single day when the user taps on a table view cell

Build and run the project. You’ll see the UI appear, but nothing works yet. That’s because the app needs to get its data from the network, but this code hasn’t been added yet. This is what you will be doing in this tutorial!

The first thing you need to do is include the AFNetworking framework in your project. Download the latest version from GitHub by clicking on the Download Zip link.

When you unzip the file, you will see that it includes several subfolders and items. Of particular interest, it includes a subfolder called AFNetworking and another called UIKit+AFNetworking as shown below:

Drag these folders into your Xcode project.

When presented with options for adding the folders, make sure that Copy items into destination group’s folder (if needed) and Create groups for any added folders are both checked.

To complete the setup, open the pre-compiled header Weather-Prefix.pch from the Supporting Files section of the project. Add this line after the other imports:

#import "AFNetworking.h"

Adding AFNetworking to the pre-compiled header means that the framework will be automatically included in all the project’s source files.

Pretty easy, eh? Now you’re ready to “weather” the code!

Operation JSON

AFNetworking is smart enough to load and process structured data over the network, as well as plain old HTTP requests. In particular, it supports JSON, XML and Property Lists (plists).

You could download some JSON and then run it through a parser (like the built-in NSJSONSerialization) yourself, but why bother? AFNetworking can do it all!

First you need the base URL of the test script. Add this to the top of WTTableViewController.m, just underneath all the #import lines.

static NSString * const BaseURLString = @"http://www.raywenderlich.com/demos/weather_sample/";

This is the URL to an incredibly simple “web service” that I created for you for this tutorial. If you’re curious what it looks like, you can download the source.

The web service returns weather data in three different formats – JSON, XML, and PLIST. You can take a look at the data it can return by using these URLS:

• http://www.raywenderlich.com/demos/weather_sample/weather.php?format=json
• http://www.raywenderlich.com/demos/weather_sample/weather.php?format=xml
• http://www.raywenderlich.com/demos/weather_sample/weather.php?format=plist (might not show correctly in your browser)

The first data format you will be using is JSON. JSON is a very common JavaScript-derived object format. It looks something like this:

{
    "data": {
        "current_condition": [
            {
                "cloudcover": "16",
                "humidity": "59",
                "observation_time": "09:09 PM",
            }
        ]
    }
}

When the user taps the JSON button, the app will load and process JSON data from the server. In WTTableViewController.m, find the jsonTapped: method (it should be empty) and replace it with the following:

- (IBAction)jsonTapped:(id)sender
{
    // 1
    NSString *string = [NSString stringWithFormat:@"%@weather.php?format=json", BaseURLString];
    NSURL *url = [NSURL URLWithString:string];
    NSURLRequest *request = [NSURLRequest requestWithURL:url];
 
    // 2
    AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:request];
    operation.responseSerializer = [AFJSONResponseSerializer serializer];
 
    [operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
 
        // 3
        self.weather = (NSDictionary *)responseObject;
        self.title = @"JSON Retrieved";
        [self.tableView reloadData];
 
    } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
 
        // 4
        UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Error Retrieving Weather"
                                                            message:[error localizedDescription]
                                                           delegate:nil
                                                  cancelButtonTitle:@"Ok"
                                                  otherButtonTitles:nil];
        [alertView show];
    }];
 
    // 5
    [operation start];
}

Awesome, this is your first AFNetworking code! Since this is all new, I’ll explain it one section at a time.

1. You first create a string representing the full url from the base URL string. This is then used to create an NSURL object, which is used to make an NSURLRequest.
2. AFHTTPRequestOperation is an all-in-one class for handling HTTP transfers across the network. You tell it that the response should be read as JSON by setting the responseSerializer property to the default JSON serializer. AFNetworking will then take care of parsing the JSON for you.
3. The success block runs when (surprise!) the request succeeds. The JSON serializer parses the received data and returns a dictionary in the responseObject variable, which is stored in the weather property.
4. The failure block runs if something goes wrong – such as if networking isn’t available. If this happens, you simply display an alert with the error message.
5. You must explicitly tell the operation to “start” (or else nothing will happen).

As you can see, AFNetworking is extremely simple to use. In just a few lines of code, you were able to create a networking operation that both downloads and parses its response.

Now that the weather data is stored in self.weather, you need to display it. Find the tableView:numberOfRowsInSection: method and replace it with the following:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    if(!self.weather)
        return 0;
 
    switch (section) {
        case 0: {
            return 1;
        }
        case 1: {
            NSArray *upcomingWeather = [self.weather upcomingWeather];
            return [upcomingWeather count];
        }
        default:
            return 0;
    }
}

The table view will have two sections: the first to display the current weather and the second to display the upcoming weather.

“Wait a minute!”, you might be thinking. What is this [self.weather upcomingWeather]? If self.weather is a plain old NSDictionary, how does it know what “upcomingWeather” is?

To make it easier to display the data, I added a couple of helper categories on NSDictionary in the starter project:

• NSDictionary+weather
• NSDictionary+weather_package

These categories add some handy methods that make it a little easier to access the data elements. You want to focus on the networking part and not on navigating NSDictionary keys, right?

Still in WTTableViewController.m, find the tableView:cellForRowAtIndexPath: method and replace it with the following implementation:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"WeatherCell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];
 
    NSDictionary *daysWeather = nil;
 
    switch (indexPath.section) {
        case 0: {
            daysWeather = [self.weather currentCondition];
            break;
        }
 
        case 1: {
            NSArray *upcomingWeather = [self.weather upcomingWeather];
            daysWeather = upcomingWeather[indexPath.row];
            break;
        }
 
        default:
            break;
    }
 
    cell.textLabel.text = [daysWeather weatherDescription];
 
    // You will add code here later to customize the cell, but it's good for now.
 
    return cell;
}

Like the tableView:numberOfRowsInSection: method, the handy NSDictionary categories are used to easily access the data. The current day’s weather is a dictionary, and the upcoming days are stored in an array.

Build and run your project; tap on the JSON button to get the networking request in motion; and you should see this:

JSON success!

Operation Property Lists

Property lists (or plists for short) are just XML files structured in a certain way (defined by Apple). Apple uses them all over the place for things like storing user settings. They look something like this:

 
<dict>
  <key>data</key>
  <dict>
    <key>current_condition</key>
      <array>
      <dict>
        <key>cloudcover</key>
        <string>16</string>
        <key>humidity</key>
        <string>59</string>
        ...

The above represents:

• A dictionary with a single key called “data” that contains another dictionary.
• That dictionary has a single key called “current_condition” that contains an array.
• That array contains a dictionary with several keys and values, like cloudcover=16 and humidity=59.

It’s time to load the plist version of the weather data. Find the plistTapped: method and replace the empty implementation with the following:

- (IBAction)plistTapped:(id)sender 
{
    NSString *string = [NSString stringWithFormat:@"%@weather.php?format=plist", BaseURLString];
    NSURL *url = [NSURL URLWithString:string];
    NSURLRequest *request = [NSURLRequest requestWithURL:url];
 
    AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:request];
 
    // Make sure to set the responseSerializer correctly
    operation.responseSerializer = [AFPropertyListResponseSerializer serializer];
 
    [operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
 
        self.weather = (NSDictionary *)responseObject;
        self.title = @"PLIST Retrieved";
        [self.tableView reloadData];
 
    } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
 
        UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Error Retrieving Weather"
                                                            message:[error localizedDescription]
                                                           delegate:nil
                                                  cancelButtonTitle:@"Ok"
                                                  otherButtonTitles:nil];
        [alertView show];
    }];
 
    [operation start];
}

Notice that this code is almost identical to the JSON version, except for changing the responseSerializer to the default AFPropertyListResponseSerializer to let AFNetworking know that you’re going to be parsing a plist.

That’s pretty neat: your app can accept either JSON or plist formats with just a tiny change to the code!

Build and run your project and try tapping on the PLIST button. You should see something like this:

The Clear button in the top navigation bar will clear the title and table view data so you can reset everything to make sure the requests are going through.

Operation XML

While AFNetworking handles JSON and plist parsing for you, working with XML is a little more complicated. This time, it’s your job to construct the weather dictionary from the XML feed.

Fortunately, iOS provides some help via the NSXMLParser class (which is a SAX parser, if you want to read up on it).

Still in WTTableViewController.m, find the xmlTapped: method and replace its implementation with the following:

- (IBAction)xmlTapped:(id)sender
{
    NSString *string = [NSString stringWithFormat:@"%@weather.php?format=xml", BaseURLString];
    NSURL *url = [NSURL URLWithString:string];
    NSURLRequest *request = [NSURLRequest requestWithURL:url];
 
    AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:request];
 
    // Make sure to set the responseSerializer correctly
    operation.responseSerializer = [AFXMLParserResponseSerializer serializer];
 
    [operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
 
        NSXMLParser *XMLParser = (NSXMLParser *)responseObject;
        [XMLParser setShouldProcessNamespaces:YES];
 
        // Leave these commented for now (you first need to add the delegate methods)
        // XMLParser.delegate = self;
        // [XMLParser parse];
 
    } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
 
        UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Error Retrieving Weather"
                                                            message:[error localizedDescription]
                                                           delegate:nil
                                                  cancelButtonTitle:@"Ok"
                                                  otherButtonTitles:nil];
        [alertView show];
 
    }];
 
    [operation start];
}

This should look pretty familiar by now. The biggest change is that in the success block you don’t get a nice, preprocessed NSDictionary object passed to you. Instead, responseObject is an instance of NSXMLParser, which you will use to do the heavy lifting in parsing the XML.

You’ll need to implement a set of delegate methods for NXMLParser to be able to parse the XML. Notice that XMLParser’s delegate is set to self, so you will need to add NSXMLParser’s delegate methods to WTTableViewController to handle the parsing.

First, update WTTableViewController.h and change the class declaration at the top as follows:

@interface WTTableViewController : UITableViewController<NSXMLParserDelegate>

This means the class will implement the NSXMLParserDelegate protocol. You will implement these methods soon, but first you need to add a few properties.

Add the following properties to WTTableViewController.m within the class extension, right after @interface WTTableViewController () :

@property(nonatomic, strong) NSMutableDictionary *currentDictionary;   // current section being parsed
@property(nonatomic, strong) NSMutableDictionary *xmlWeather;          // completed parsed xml response
@property(nonatomic, strong) NSString *elementName;
@property(nonatomic, strong) NSMutableString *outstring;

These properties will come in handy when you’re parsing the XML.

Now paste this method in WTTableViewController.m, right before @end:

- (void)parserDidStartDocument:(NSXMLParser *)parser
{
    self.xmlWeather = [NSMutableDictionary dictionary];
}

The parser calls this method when it first starts parsing. When this happens, you set self.xmlWeather to a new dictionary, which will hold hold the XML data.

Next paste this method right after this previous one:

- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary *)attributeDict
{
    self.elementName = qName;
 
    if([qName isEqualToString:@"current_condition"] ||
       [qName isEqualToString:@"weather"] ||
       [qName isEqualToString:@"request"]) {
        self.currentDictionary = [NSMutableDictionary dictionary];
    }
 
    self.outstring = [NSMutableString string];
}

The parser calls this method when it finds a new element start tag. When this happens, you keep track of the new element’s name as self.elementName and then set self.currentDictionary to a new dictionary if the element name represents the start of a new weather forecast. You also reset outstring as a new mutable string in preparation for new XML to be received related to the element.

Next paste this method just after the previous one:

- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string
{
    if (!self.elementName)
        return;
 
    [self.outstring appendFormat:@"%@", string];
}

As the name suggests, the parser calls this method when it finds new characters on an XML element. You append the new characters to outstring, so they can be processed once the XML tag is closed.

Again, paste this next method just after the previous one:

- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName
{
    // 1
    if ([qName isEqualToString:@"current_condition"] ||
       [qName isEqualToString:@"request"]) {
        self.xmlWeather[qName] = @[self.currentDictionary];
        self.currentDictionary = nil;
    }
    // 2
    else if ([qName isEqualToString:@"weather"]) {
 
        // Initialize the list of weather items if it doesn't exist
        NSMutableArray *array = self.xmlWeather[@"weather"] ?: [NSMutableArray array];
 
        // Add the current weather object
        [array addObject:self.currentDictionary];
 
        // Set the new array to the "weather" key on xmlWeather dictionary
        self.xmlWeather[@"weather"] = array;
 
        self.currentDictionary = nil;
    }
    // 3
    else if ([qName isEqualToString:@"value"]) {
        // Ignore value tags, they only appear in the two conditions below
    }
    // 4
    else if ([qName isEqualToString:@"weatherDesc"] ||
            [qName isEqualToString:@"weatherIconUrl"]) {
        NSDictionary *dictionary = @{@"value": self.outstring};
        NSArray *array = @[dictionary];
        self.currentDictionary[qName] = array;
    }
    // 5
    else if (qName) {
        self.currentDictionary[qName] = self.outstring;
    }
 
	self.elementName = nil;
}

This method is called when an end element tag is encountered. When that happens, you check for a few special tags:

1. The current_condition element indicates you have the weather for the current day. You add this directly to the xmlWeather dictionary.
2. The weather element means you have the weather for a subsequent day. While there is only one current day, there may be several subsequent days, so you add this weather information to an array.
3. The value tag only appears inside other tags, so it’s safe to skip over it.
4. The weatherDesc and weatherIconUrl element values need to be boxed inside an array before they can be stored. This way, they will match how the JSON and plist versions of the data are structured exactly.
5. All other elements can be stored as is.

Now for the final delegate method! Paste this method just after the previous one:

- (void) parserDidEndDocument:(NSXMLParser *)parser
{
    self.weather = @{@"data": self.xmlWeather};
    self.title = @"XML Retrieved";
    [self.tableView reloadData];
}

The parser calls this method when it reaches the end of the document. At this point, the xmlWeather dictionary that you’ve been building is complete, so the table view can be reloaded.

Wrapping xmlWeather inside another NSDictionary might seem redundant, but this ensures the format matches up exactly with the JSON and plist versions. This way, all three data formats can be displayed with the same code!

Now that the delegate methods and properties are in place, return to the xmlTapped: method and uncomment the lines of code from before:

- (IBAction)xmlTapped:(id)sender
{
    ...
    [operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
 
        NSXMLParser *XMLParser = (NSXMLParser *)responseObject;
        [XMLParser setShouldProcessNamespaces:YES];
 
        // These lines below were previously commented
        XMLParser.delegate = self;
        [XMLParser parse];    
    ...
}

Build and run your project. Try tapping the XML button, and you should see this:

A Little Weather Flair

Hmm, that looks dreary, like a week’s worth of rainy days. How could you jazz up the weather information in your table view?

Take another peak at the JSON format from before, and you will see that there are image URLs for each weather item. Displaying these weather images in each table view cell would add some visual interest to the app.

AFNetworking adds a category to UIImageView that lets you load images asynchronously, meaning the UI will remain responsive while images are downloaded in the background. To take advantage of this, first add the category import to the top of WTTableViewController.m:

#import "UIImageView+AFNetworking.h"

Find the tableView:cellForRowAtIndexPath: method and paste the following code just above the final return cell; line (there should be a comment marking the spot):

 cell.textLabel.text = [daysWeather weatherDescription];
 
    NSURL *url = [NSURL URLWithString:daysWeather.weatherIconURL];
    NSURLRequest *request = [NSURLRequest requestWithURL:url];
    UIImage *placeholderImage = [UIImage imageNamed:@"placeholder"];
 
    __weak UITableViewCell *weakCell = cell;
 
    [cell.imageView setImageWithURLRequest:request
                          placeholderImage:placeholderImage
                                   success:^(NSURLRequest *request, NSHTTPURLResponse *response, UIImage *image) {
 
                                       weakCell.imageView.image = image;
                                       [weakCell setNeedsLayout];
 
                                   } failure:nil];

UIImageView+AFNetworking makes setImageWithURLRequest: and several other related methods available to you.

Both the success and failure blocks are optional, but if you do provide a success block, you must explicitly set the image property on the image view (or else it won’t be set). If you don’t provide a success block, the image will automatically be set for you.

When the cell is first created, its image view will display the placeholder image until the real image has finished downloading.

Now build and run your project. Tap on any of the operations you’ve added so far, and you should see this:

Nice! Asynchronously loading images has never been easier.

A RESTful Class

So far you’ve been creating one-off networking operations using AFHTTPRequestOperation.

Alternatively, AFHTTPRequestOperationManager and AFHTTPSessionManager are designed to help you easily interact with a single, web-service endpoint.

Both of these allow you to set a base URL and then make several requests to the same endpoint. Both can also monitor for changes in connectivity, encode parameters, handle multipart form requests, enqueue batch operations, and help you perform the full suite of RESTful verbs (GET, POST, PUT, and DELETE).

“Which one should I use?”, you might ask.

• If you’re targeting iOS 7 and above, use AFHTTPSessionManager, as internally it creates and uses NSURLSession and related objects.
• If you’re targeting iOS 6 and above, use AFHTTPRequestOperationManager, which has similar functionality to AFHTTPSessionManager, yet it uses NSURLConnection internally instead of NSURLSession (which isn’t available in iOS 6). Otherwise, these classes are very similar in functionality.

In your weather app project, you’ll be using AFHTTPSessionManager to perform both a GET and PUT operation.

Update the class declaration at the top of WTTableViewController.h to the following:

@interface WTTableViewController : UITableViewController<NSXMLParserDelegate, CLLocationManagerDelegate, UIActionSheetDelegate>

In WTTableViewController.m, find the clientTapped: method and replace its implementation with the following:

- (IBAction)clientTapped:(id)sender 
{
    UIActionSheet *actionSheet = [[UIActionSheet alloc] initWithTitle:@"AFHTTPSessionManager"
                                                             delegate:self
                                                    cancelButtonTitle:@"Cancel"
                                               destructiveButtonTitle:nil
                                                    otherButtonTitles:@"HTTP GET", @"HTTP POST", nil];
    [actionSheet showFromBarButtonItem:sender animated:YES];
}

This method creates and displays an action sheet asking the user to choose between a GET and POST request. Add the following method at the end of the class implementation (right before @end) to implement the action sheet delegate method:

- (void)actionSheet:(UIActionSheet *)actionSheet clickedButtonAtIndex:(NSInteger)buttonIndex
{
    if (buttonIndex == [actionSheet cancelButtonIndex]) {
        // User pressed cancel -- abort
        return;
    }
 
    // 1
    NSURL *baseURL = [NSURL URLWithString:BaseURLString];
    NSDictionary *parameters = @{@"format": @"json"};
 
    // 2
    AFHTTPSessionManager *manager = [[AFHTTPSessionManager alloc] initWithBaseURL:baseURL];
    manager.responseSerializer = [AFJSONResponseSerializer serializer];
 
    // 3
    if (buttonIndex == 0) {
        [manager GET:@"weather.php" parameters:parameters success:^(NSURLSessionDataTask *task, id responseObject) {
            self.weather = responseObject;
            self.title = @"HTTP GET";
            [self.tableView reloadData];
        } failure:^(NSURLSessionDataTask *task, NSError *error) {
            UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Error Retrieving Weather"
                                                                message:[error localizedDescription]
                                                               delegate:nil
                                                      cancelButtonTitle:@"Ok"
                                                      otherButtonTitles:nil];
            [alertView show];
        }];
    }
 
    // 4
    else if (buttonIndex == 1) {
        [manager POST:@"weather.php" parameters:parameters success:^(NSURLSessionDataTask *task, id responseObject) {
            self.weather = responseObject;
            self.title = @"HTTP POST";
            [self.tableView reloadData];
        } failure:^(NSURLSessionDataTask *task, NSError *error) {
            UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Error Retrieving Weather"
                                                                message:[error localizedDescription]
                                                               delegate:nil
                                                      cancelButtonTitle:@"Ok"
                                                      otherButtonTitles:nil];
            [alertView show];
        }];
    }
}

Here’s what’s happening above:

1. You first set up the baseURL and the dictionary of parameters.
2. You then create an instance of AFHTTPSessionManager and set its responseSerializer to the default JSON serializer, similar to the previous JSON example.
3. If the user presses the button index for HTTP GET, you call the GET method on the manager, passing in the parameters and usual pair of success and failure blocks.
4. You do the same with the POST version.

In this example you’re requesting JSON responses, but you can easily request either of the other two formats as discussed previously.

Build and run your project, tap on the Client button and then tap on either the HTTP GET or HTTP POST button to initiate the associated request. You should see these screens:

At this point, you know the basics of using AFHTTPSessionManager, but there’s an even better way to use it that will result in cleaner code, which you’ll learn about next.

World Weather Online

Before you can use the live service, you’ll first need to register for a free account on World Weather Online. Don’t worry – it’s quick and easy to do!

After you’ve registered, you should receive a confirmation email at the address you provided, which will have a link to confirm your email address (required). You then need to request a free API key via the My Account page. Go ahead and leave the page open with your API key as you’ll need it soon.

Now that you’ve got your API key, back to AFNetworking…

Hooking into the Live Service

So far you’ve been creating AFHTTPRequestOperation and AFHTTPSessionManager directly from the table view controller as you needed them. More often than not, your networking requests will be associated with a single web service or API.

AFHTTPSessionManager has everything you need to talk to a web API. It will decouple your networking communications code from the rest of your code, and make your networking communications code reusable throughout your project.

Here are two guidelines on AFHTTPSessionManager best practices:

1. Create a subclass for each web service. For example, if you’re writing a social network aggregator, you might want one subclass for Twitter, one for Facebook, another for Instragram and so on.
2. In each AFHTTPSessionManager subclass, create a class method that returns a shared singleton instance. This saves resources and eliminates the need to allocate and spin up new objects.

Your project currently doesn’t have a subclass of AFHTTPSessionManager; it just creates one directly. Let’s fix that.

To begin, create a new file in your project of type iOS\Cocoa Touch\Objective-C Class. Call it WeatherHTTPClient and make it a subclass of AFHTTPSessionManager.

You want the class to do three things: perform HTTP requests, call back to a delegate when the new weather data is available, and use the user’s physical location to get accurate weather.

Replace the contents of WeatherHTTPClient.h with the following:

#import "AFHTTPSessionManager.h"
 
@protocol WeatherHTTPClientDelegate;
 
@interface WeatherHTTPClient : AFHTTPSessionManager
@property (nonatomic, weak) id<WeatherHTTPClientDelegate>delegate;
 
+ (WeatherHTTPClient *)sharedWeatherHTTPClient;
- (instancetype)initWithBaseURL:(NSURL *)url;
- (void)updateWeatherAtLocation:(CLLocation *)location forNumberOfDays:(NSUInteger)number;
 
@end
 
@protocol WeatherHTTPClientDelegate <NSObject>
@optional
-(void)weatherHTTPClient:(WeatherHTTPClient *)client didUpdateWithWeather:(id)weather;
-(void)weatherHTTPClient:(WeatherHTTPClient *)client didFailWithError:(NSError *)error;
@end

You’ll learn more about each of these methods as you implement them. Switch over to WeatherHTTPClient.m and add the following right after the import statement:

// Set this to your World Weather Online API Key
static NSString * const WorldWeatherOnlineAPIKey = @"PASTE YOUR API KEY HERE";
 
static NSString * const WorldWeatherOnlineURLString = @"http://api.worldweatheronline.com/free/v1/";

Make sure you replace @”PASTE YOUR KEY HERE” with your actual World Weather Online API Key.

Next paste these methods just after the @implementation line:

+ (WeatherHTTPClient *)sharedWeatherHTTPClient
{
    static WeatherHTTPClient *_sharedWeatherHTTPClient = nil;
 
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        _sharedWeatherHTTPClient = [[self alloc] initWithBaseURL:[NSURL URLWithString:WorldWeatherOnlineURLString]];
    });
 
    return _sharedWeatherHTTPClient;
}
 
- (instancetype)initWithBaseURL:(NSURL *)url
{
    self = [super initWithBaseURL:url];
 
    if (self) {
        self.responseSerializer = [AFJSONResponseSerializer serializer];
        self.requestSerializer = [AFJSONRequestSerializer serializer];
    }
 
    return self;
}

The sharedWeatherHTTPClient method uses Grand Central Dispatch to ensure the shared singleton object is only allocated once. You initialize the object with a base URL and set it up to request and expect JSON responses from the web service.

Paste the following method underneath the previous ones:

- (void)updateWeatherAtLocation:(CLLocation *)location forNumberOfDays:(NSUInteger)number
{
    NSMutableDictionary *parameters = [NSMutableDictionary dictionary];
 
    parameters[@"num_of_days"] = @(number);
    parameters[@"q"] = [NSString stringWithFormat:@"%f,%f",location.coordinate.latitude,location.coordinate.longitude];
    parameters[@"format"] = @"json";
    parameters[@"key"] = WorldWeatherOnlineAPIKey;
 
    [self GET:@"weather.ashx" parameters:parameters success:^(NSURLSessionDataTask *task, id responseObject) {
        if ([self.delegate respondsToSelector:@selector(weatherHTTPClient:didUpdateWithWeather:)]) {
            [self.delegate weatherHTTPClient:self didUpdateWithWeather:responseObject];
        }
    } failure:^(NSURLSessionDataTask *task, NSError *error) {
        if ([self.delegate respondsToSelector:@selector(weatherHTTPClient:didFailWithError:)]) {
            [self.delegate weatherHTTPClient:self didFailWithError:error];
        }
    }];
}

This method calls out to World Weather Online to get the weather for a particular location.

Once the object has loaded the weather data, it needs some way to communicate that data back to whoever’s interested. Thanks to the WeatherHTTPClientDelegate protocol and its delegate methods, the success and failure blocks in the above code can notify a controller that the weather has been updated for a given location. That way, the controller can update what it is displaying.

Now it’s time to put the final pieces together! The WeatherHTTPClient is expecting a location and has a defined delegate protocol, so you need to update the WTTableViewController class to take advantage of this.

Open up WTTableViewController.h to add an import and replace the @interface declaration as follows:

#import "WeatherHTTPClient.h"
 
@interface WTTableViewController : UITableViewController <NSXMLParserDelegate, CLLocationManagerDelegate, UIActionSheetDelegate, WeatherHTTPClientDelegate>

Also add a new Core Location manager property:

@property (nonatomic, strong) CLLocationManager *locationManager;

In WTTableViewController.m, add the following lines to the bottom of viewDidLoad::

self.locationManager = [[CLLocationManager alloc] init];
self.locationManager.delegate = self;

These lines initialize the Core Location manager to determine the user’s location when the view loads. The Core Location manager then reports that location via a delegate callback. Add the following method to the implementation:

- (void)locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations
{
    // Last object contains the most recent location
    CLLocation *newLocation = [locations lastObject];
 
    // If the location is more than 5 minutes old, ignore it
    if([newLocation.timestamp timeIntervalSinceNow] > 300)
        return;
 
    [self.locationManager stopUpdatingLocation];
 
    WeatherHTTPClient *client = [WeatherHTTPClient sharedWeatherHTTPClient];
    client.delegate = self;
    [client updateWeatherAtLocation:newLocation forNumberOfDays:5];
}

Now when there’s an update to the user’s whereabouts, you can call the singleton WeatherHTTPClient instance to request the weather for the current location.

Remember, WeatherHTTPClient has two delegate methods itself that you need to implement. Add the following two methods to the implementation:

- (void)weatherHTTPClient:(WeatherHTTPClient *)client didUpdateWithWeather:(id)weather
{
    self.weather = weather;
    self.title = @"API Updated";
    [self.tableView reloadData];
}
 
- (void)weatherHTTPClient:(WeatherHTTPClient *)client didFailWithError:(NSError *)error
{
    UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Error Retrieving Weather"
                                                        message:[NSString stringWithFormat:@"%@",error]
                                                       delegate:nil
                                              cancelButtonTitle:@"OK" otherButtonTitles:nil];
    [alertView show];
}

When the WeatherHTTPClient succeeds, you update the weather data and reload the table view. In case of a network error, you display an error message.

Find the apiTapped: method and replace it with the following:

- (IBAction)apiTapped:(id)sender
{
    [self.locationManager startUpdatingLocation];
}

Build and run your project (try your device if you have any troubles with your simulator), tap on the API button to initiate the WeatherHTTPClient request, and you should see something like this:

Here’s hoping your upcoming weather is as sunny as mine!

I’m Not Dead Yet!

You might have noticed that this external web service can take some time before it returns with data. It’s important to provide your users with feedback when doing network operations so they know the app hasn’t stalled or crashed.

Luckily, AFNetworking comes with an easy way to provide this feedback: AFNetworkActivityIndicatorManager.

In WTAppDelegate.m, add this import just below the other:

#import "AFNetworkActivityIndicatorManager.h"

Then find the application:didFinishLaunchingWithOptions: method and replace it with the following:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [AFNetworkActivityIndicatorManager sharedManager].enabled = YES;
    return YES;
}

Enabling the sharedManager automatically displays the network activity indicator whenever a new operation is underway. You won’t need to manage it separately for every request you make.

Build and run, and you should see the little networking spinner in the status bar whenever there’s a network request:

Now there’s a sign of life for your user even when your app is waiting on a slow web service.

Downloading Images

If you tap on a table view cell, the app takes you to a detail view of the weather and an animation illustrating the corresponding weather conditions.

That’s nice, but at the moment the animation has a very plain background. What better way to update the background than… over the network!

Here’s the final AFNetworking trick for this tutorial: AFHTTPRequestOperation can also handle image requests by setting its responseSerializer to an instance of AFImageResponseSerializer.

There are two method stubs in WeatherAnimationViewController.m to implement. Find the updateBackgroundImage: method and replace it with the following:

- (IBAction)updateBackgroundImage:(id)sender
{
    NSURL *url = [NSURL URLWithString:@"http://www.raywenderlich.com/wp-content/uploads/2014/01/sunny-background.png"];
    NSURLRequest *request = [NSURLRequest requestWithURL:url];
 
    AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:request];
    operation.responseSerializer = [AFImageResponseSerializer serializer];
 
    [operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
 
        self.backgroundImageView.image = responseObject;
        [self saveImage:responseObject withFilename:@"background.png"];
 
    } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
 
        NSLog(@"Error: %@", error);
    }];
 
    [operation start];
}

This method initiates and handles downloading the new background. On completion, it returns the full image requested.

In WeatherAnimationViewController.m, you will see two helper methods, imageWithFilename: and saveImage:withFilename:, which will let you store and load any image you download. updateBackgroundImage: calls these helper methods to save the downloaded images to disk.

Find the deleteBackgroundImage: method and replace it with the following:

- (IBAction)deleteBackgroundImage:(id)sender
{
	NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
	NSString *path = [[paths objectAtIndex:0] stringByAppendingPathComponent:@"WeatherHTTPClientImages/"];
 
    NSError *error = nil;
    [[NSFileManager defaultManager] removeItemAtPath:path error:&error];
 
    NSString *desc = [self.weatherDictionary weatherDescription];
    [self start:desc];
}

This method deletes the downloaded background image so that you can download it again when testing the application.

For the final time: build and run, download the weather data and tap on a cell to get to the detailed view. From here, tap the Update Background button. If you tap on a Sunny cell, you should see this:

Where To Go From Here?

You can download the completed project from here.

Think of all the ways you can now use AFNetworking to communicate with the outside world:

• AFHTTPOperation with AFJSONResponseSerializer, AFPropertyListResponseSerializer, or AFXMLParserResponseSerializer response serializers for parsing structured data
• UIImageView+AFNetworking for quickly filling in image views
• Custom AFHTTPSessionManager subclasses to access live web services
• AFNetworkActivityIndicatorManager to keep the user informed
• AFHTTPOperation with a AFImageResponseSerializer response serializer for loading images

The power of AFNetworking is yours to deploy!

If you have any questions about anything you’ve seen here, please pay a visit to the forums to get some assistance. I’d also love to read your comments!

AFNetworking 2.0 Tutorial is a post from: Ray Wenderlich

The post AFNetworking 2.0 Tutorial appeared first on Ray Wenderlich.

Learn how to spawn obstacles periodically over time in this video tutorial series on how to make a game like Flappy Bird.

Video Tutorial: How To Make a Game Like Flappy Bird Part 2: Spawning Obstacles is a post from: Ray Wenderlich

The post Video Tutorial: How To Make a Game Like Flappy Bird Part 2: Spawning Obstacles appeared first on Ray Wenderlich.

Beer ahead!
Photo: Krzysztof Szkurlatowski

For many years, Core Data has been an integral part of many OS X and iOS apps, supporting the persistence and querying of user data. Apple constantly tinkers with Core Data API, in an effort to make it easier for developers to use and integrate into apps.

That said, the truth is that Core Data remains a challenging API to master. Even when you know how to use Core Data, mundane, everyday tasks can feel clunky and cumbersome. Good thing there is MagicalRecord, a third-party library for Core Data created by MagicalPanda – and good that this MagicalRecord tutorial is focused on bringing you up to speed with MagicalRecord quickly and easily :]

MagicalRecord is easy to use, well developed and popular. As described by the project’s author, the point of MagicalRecord is to “clean up” Core Data code and enable simple one-line fetches of data, while still allowing custom performance optimizations. How does it do this? It provides convenience methods, which wrap common boilerplate for Core Data setup, query and update. Its design also features influences from Ruby on Rails’ ActiveRecord persistence system (an instance of the venerable Active Record design pattern).

But enough theory! Just follow along this MagicalRecord tutorial to see how MagicalRecord works its, well, magic.. In this tutorial, you’ll create an app that will keep track of your favorite beers. It will allow you to:

1. Add a beer of your liking
2. Rate the beer
3. Make notes about the beer
4. Take a photo of the beer – in case you’ve had one too many to make sense of your notes

Getting Started

To follow this tutorial, you should already have a basic understanding of Core Data, at the level provided by a basic Core Data tutorial. Beyond that, you don’t need any prior experience with Core Data.

To begin, start by downloading this Starter Project. Once you have it, go ahead and run the application so you can check it out.

It has a basic navigation controller with an Add button, table view, search bar (if you pull down on the table) and a segmented control for sorting alphabetically or by rating. If you click the Add button you’ll go to the UI, where you’ll enter and view beer information. If you try to enter anything, it won’t save – yet.
Now take a look around the code. In the Project Navigator you’ll see:

• All of the view controllers that you use to make the application work
• An ImageSaver utility class
• Images that you’ll use later for populating initial data
• An Images.xcassets library that has a few images that are used by the UI
• AMRating – an easy to use third-party library for a rating control
• And finally, MagicalRecord

While you’re poking around, you may notice there is no Core Data model, nor does AppDelegate.m contain any code to set it up. This is the perfect scenario for any project you started without Core Data, only to realize later that Core Data is the way to go.

Exploring MagicalRecord

In the Project Navigator, go ahead and expand the MagicalRecord group. Inside, you’ll find groups for Categories and Core, as well as CoreData+MagicalRecord.h. Expand the Categories group, and open the file named NSManagedObjectModel+MagicalRecord.h.
You’ll notice that the methods in the header are all prefixed MR_. In fact, if you go through any of the files in the Categories group, you’ll notice all of the methods are prefixed with MR_.
I don’t know about you, but I find it rather confusing to begin every method with the same two letters. Good thing MagicalRecord makes it easy to change them up with Shorthand Support.

Again, in the Project Navigator, expand the Supporting Files group, and open BeerTracker-Prefix.pch. This is the precompiled header for the project. The starter project has added two lines to this file:

#define MR_SHORTHAND
#import “CoreData+MagicalRecord.h”

These two lines enable MagicalRecord for your project:

1. MR_SHORTHAND tells MagicalRecord that you do not want to have to type MR_ before any MagicalRecord method. You can look in MagicalRecord+ShorthandSupport.m to find out more how this works. As it goes beyond the scope of this tutorial, it will not be discussed here.
2. By importing CoreData+MagicalRecord.h, you can now access any of the MagicalRecord APIs in any of your project files without having to import them in every file you need them.

Beer Model

To start keeping track of your favorite beers, you’re going to need a model, because you can’t expect yourself to remember them, right? From the Xcode menu, select File\New\File…. From the list on the left hand side, select Core Data and choose Data Model from the options.

Name the file BeerModel.xcdatamodeld and put it in the BeerTracker group.

In the project navigator, select the new bundle BeerModel.xcdatamodeld to start editing it. Add an entity named Beer. Add an attribute named name with a type of String.

Add another Entity named BeerDetails. This entity will track of the details for a beer, such as user rating, notes and where to find the image. Add the following attributes to BeerDetails, with the corresponding types:

• Attribute: image Type: String
• Attribute: note Type: String
• Attribute: rating Type: Integer 16

Next, you’re going to create a relationship between the two, so the Beer entity knows which BeerDetails belong to it. Under BeerDetails, create a new relationship and name it “beer” with the destination Beer. By selecting the destination beer, you’ve established the first part of the relationship between the entities.

Finish setting up the relationship by selecting the Beer entity. Add a relationship named beerDetails, with the destination of BeerDetails, and the inverse of Beer. Now your Beer entity will have a BeerDetails entity to call its own.

The next step is to create data classes to represent the entities. You’ll use Xcode for this, but you need to be careful because of some quirks in Xcode’s behavior.

First, edit the Core Data model by selecting it in the Xcode project navigator; ensure that you highlight the Beer entity in the “ENTITIES” pane — and NOT the BeerDetails entity.

Next, in the Xcode menu, go to Editor\Create NSManagedObject Subclass…. Check BeerModel, then select Next. Under Entities to Manage, select the checkboxes for both the Beer and BeerDetails, if not selected by default, and double-check that Beer is highlighted. Press Next and then Create. This will generate new classes of Beer and BeerDetails corresponding to the entities with those names. Take a moment to look at the new classes, and you’ll see that each class has properties corresponding to the entity attributes you defined.

In particular, check the properties that represent the relationship between entities. You should see that the Beer class holds a property beerDetails of type BeerDetails * object. But, you’ll also see that the BeerDetails class holds a property beer of type NSManagedObject*. Why doesn’t the property have a type of Beer *? This is due to a limitation in Xcode’s “Create NSManagedObject Subclass” command. It has no effect on this project, so feel free to ignore it.

Now that you’ve created the data object classes, it’s time to initialize the Core Data stack. Open AppDelegate.m, and in application:didFinishLaunchingWithOptions: add the following lines of code just before the return statement:

// Setup CoreData with MagicalRecord
// Step 1. Setup Core Data Stack with Magical Record
// Step 2. Relax. Why not have a beer? Surely all this talk of beer is making you thirsty…
[MagicalRecord setupCoreDataStackWithStoreNamed:@"BeerModel"];

If you’ve ever worked with an Xcode project created with Core Data enabled, you’ve likely seen how much code it takes to setup Core Data initialize it within the AppDelegate file. With MagicalRecord, all you need is that one line!

MagicalRecord provides a few alternative methods for setting up your Core Data stack, depending on the following:

• Your type of backing store
• On whether you want auto-migration
• And on the name of your Core Data Model file

If your model file has the same base name as your project (e.g., a model file BeerTracker.xcdatamodeld, within a project named BeerTracker), then you can use one of MagicalRecord’s first three convenience methods–setupCoreDataStack, setupCoreDataStackWithInMemoryStore, or setupAutoMigratingCoreDataStack.
But, since your model file is named differently, then you have to use one of the other two setup methods, setupCoreDataStackWithStoreNamed: or setupCoreDataStackWithAutoMigratingSqliteStoreNamed:.

With the setup methods described as AutoMigrating, you can change your model, and if it is possible to auto migrate your store, MagicalRecord will handle it for you. Normally, Core Data requires you to add some code to handle small changes you make to your model.

Brewing a Beer (entity)

Now that your model and Core Data stack are set up, you can start adding beers to your list. Open BeerViewController.h, and after @class AMRatingControl, add:

@class Beer;

Also, add a Beer property after @interface:

@property (nonatomic, strong) Beer *beer;

Now switch to BeerViewController.m, and import Beer.h and BeerDetails.h at the top:

#import "Beer.h"
#import "BeerDetails.h"

In viewDidLoad, add the following block of code:

- (void)viewDidLoad {
    // 1. If there is no beer, create new Beer
    if (!self.beer) {
        self.beer = [Beer createEntity];
    }
    // 2. If there are no beer details, create new BeerDetails
    if (!self.beer.beerDetails) {
        self.beer.beerDetails = [BeerDetails createEntity];
    }
    // View setup
    // 3. Set the title, name, note field and rating of the beer
    self.title = self.beer.name ? self.beer.name : @"New Beer";
    self.beerNameField.text = self.beer.name;
    self.beerNotesView.text = self.beer.beerDetails.note;
    self.ratingControl.rating = [self.beer.beerDetails.rating integerValue];
    [self.cellOne addSubview:self.ratingControl];
 
    // 4. If there is an image path in the details, show it.
    if ([self.beer.beerDetails.image length] > 0) {
        // Image setup
        NSData *imgData = [NSData dataWithContentsOfFile:[NSHomeDirectory() stringByAppendingPathComponent:self.beer.beerDetails.image]];
         [self setImageForBeer:[UIImage imageWithData:imgData]];
     }
}

When BeerViewController loads, it will be because you have:

• Either selected a beer, or…
• Selected the Add button from the MasterViewController

Now, when the view loads you will want to do the following:

1. Check if a beer object loaded. If not, this means you are adding a new Beer.
2. If the beer doesn’t have any BeerDetails, create a BeerDetails object.
3. To setup the view, grab the beer’s name, rating and note content. If there is no name for the beer (in the instance of a new beer, it will give it the name “New Beer”).
4. If the beer contains a path to an image, it will load the image into the UIImageView.

There are a few more things you need to set up so that you can edit and add new beers. First, you need to be able to add or edit the name. Edit textFieldDidEndEditing: so it appears as below:

- (void)textFieldDidEndEditing:(UITextField *)textField {
    if ([textField.text length] > 0) {
        self.title = textField.text;
        self.beer.name = textField.text;
    }
}

Now, when you finish adding the name textField, it will set the beer’s name to whatever the contents of the textField are, so long the field is not empty.

To save the note content to the beer’s note value, find textViewDidEndEditing:, and edit it so it appears as below:

- (void)textViewDidEndEditing:(UITextView *)textView {
    [textView resignFirstResponder];
    if ([textView.text length] > 0) {
        self.beer.beerDetails.note = textView.text;
    }
}

Next, make sure the rating for the beer updates when the user changes it in the View Controller. Find updateRating, and add the following:

- (void)updateRating {
    self.beer.beerDetails.rating = @(self.ratingControl.rating);
}

When the user taps the UIImageView on the details page, it allows them to add or edit a photo. A UIActionSheet displays, which allows the user to pick an image from their Camera Roll, or to snap a new picture. If the user wants to take a picture, you’ll need to make sure the image also saves to the disk. Instead of saving the image to Core Data (which can cause performance issues) you’ll want to save the image to the user’s documents directory, with all their other pictures, and just use the image path for Core Data.

Manage interaction between the camera and the photo library by implementing methods of the UIImagePickerControllerDelegate protocol. You need to make the BeerViewController the delegate for the UIImagePickerController, since it’s the controller handling this storyboard scene. Find imagePickerController:didFinishPickingMediaWithinfo:, and add the following:

- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info {
    // 1. Grab image and save to disk
    UIImage *image = info[UIImagePickerControllerOriginalImage];	
    // 2. Remove old image if present
    if (self.beer.beerDetails.image) {
        [ImageSaver deleteImageAtPath:self.beer.beerDetails.image];
    }
    // 3. Save the image
    if ([ImageSaver saveImageToDisk:image andToBeer:self.beer]) {
        [self setImageForBeer:image];
    }
    [picker dismissViewControllerAnimated:YES completion:nil];
}

Here’s what’s happening in the code shown above:

1. imagePickerController:didFinishPickingMediaWithInfo: indirectly passes a reference to the user’s image of choice, where the image itself is in the info dictionary, under the UIImagePickerControllerOriginalImage key
2. If the Beer object already contains an image, the app will delete it from the disk, so you don’t fill up the user’s storage unnecessarily.
3. The new image then saves to the disk, and the path is added to the BeerDetails image attribute. Open ImageSaver and find saveImageToDisk:andToBeer to see how this looks. Once the image successfully saves, it shows in the UIImageView.
4. The picker is dismissed.

You’ll need to modify ImageSaver just a little to get it to work. Now that you’ve got your Beer classes created, you can uncomment the import lines, and the line that sets the image’s path in the entity. Open ImageSaver.m and modify the import statements to this:

#import "ImageSaver.h"
#import "Beer.h"
#import "BeerDetails.h"

Now you’ll need to uncomment the line found within the IF statement:

if ([imgData writeToFile:jpgPath atomically:YES]) {
        beer.beerDetails.image = path;
}

The ImageSaver class is now fully ready to accept an image, and save it to the phone’s documents directory, and the path to the BeerDetails object.

From here, the user has two options: Cancel or Done, which saves the new beer. When you created the view, a Beer entity was created, and inserted in the managedObjectContext. Canceling should delete the Beer object. Find cancelAdd, and add the following:

- (void)cancelAdd {
    [self.beer deleteEntity];
    [self.navigationController popViewControllerAnimated:YES];
}

MagicalRecord provides a nice method for deleting an entity, which automatically removes the entity from the managedObjectContext. After deleting, the user will return to the main list of beers.

If the user chooses Done, it will save the beer and return to the main list. Find addNewBeer. It simply pops the view controller, going back to the list. When the view disappears, it will call viewWillDisapper:. This in turn calls saveContext.

Right now saveContext is empty, so you’ll need to add some code to save your entity. Add the following to saveContext:

- (void)saveContext {
    [[NSManagedObjectContext defaultContext] saveToPersistentStoreWithCompletion:^(BOOL success, NSError *error) {
        if (success) {
            NSLog(@"You successfully saved your context.");
        } else if (error) {
            NSLog(@"Error saving context: %@", error.description);
        }
    }];
}

There’s a lot going on here in just a few lines of code! In AppDelegate.m, you set up the Core Data stack with MagicalRecord. This created a default managedObjectContext that the entire app can access. When you created the Beer and BeerDetails entities, they were inserted into this defaultContext . MagicalRecord allows you to save any managedObjectContext you may have using saveToPersistentStoreWithCompletion:. The completion block gives you access to an NSError object, if the save failed. Here, you’ve added a simple if/else block that logs what happens after you try to save the defaultContext.

Are you ready to test it out? Go ahead and run your app! Select the + button, fill out any information you want. Then select done.

When you do, you’ll notice you don’t see your new beer show up in the list. Don’t fret, it’s not broken and you’ll learn how to fix this in just a bit. You also might notice your debugger has a whole bunch of information in it. Contrary to what your logic might say, this is really good for you!

A Magical Debugger

When the app started, MagicalRecord logged four things during the Core Data stack setup. It is showing that the Core Data setup process happened, and that it created a defaultContext. This is the same defaultContext that was referenced earlier when you saved your beer object.

The next several logs come from when you selected Done and performed a Save with MagicalRecord. You can see the following were logged during your save:

1. The defaultContext saved to the Main Thread.
2. Any parents of the context will be saved, designated with the flag 1.
3. The save will be not be synchronous, designated with the flag 0.
4. The final logs show that MagicalRecord knows that two objects need to be saved (a Beer and BeerDetails entity), and that it successfully saved.

MagicalRecord logs a lot of information for you. If you’re having a problem, or something isn’t behaving as expected, you should check your logs for some really useful information.

 #define MR_ENABLE_ACTIVE_RECORD_LOGGING 1

 #define MR_ENABLE_ACTIVE_RECORD_LOGGING 0

Noch ein Bier, bitte

If this app is going to be worth all this work, you’ll need to be able to see the beers you’ve added. Open MasterViewController.m, and import Beer.h, and BeerDetails.h at the top.

In order to get all of the beers’ Core Data saved, you’ll need to do a fetch. In viewWillAppear:, add the fetch just before the call to reloadData.

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    // Check if the user's sort preference has been saved.
    ...
    [self fetchAllBeers];
    [self.tableView reloadData];
}

When the view loads the first time, or when returning from viewing or adding a beer, it will fetch and load all the beers into the table.

Find fetchAllBeers, and add the following:

- (void)fetchAllBeers {
    // 1. Get the sort key
    NSString *sortKey = [[NSUserDefaults standardUserDefaults] objectForKey:WB_SORT_KEY];
    // 2. Determine if it is ascending
    BOOL ascending = [sortKey isEqualToString:SORT_KEY_RATING] ? NO : YES;
    // 3. Fetch entities with MagicalRecord
    self.beers = [[Beer findAllSortedBy:sortKey ascending:ascending] mutableCopy];
}

The MasterViewController allows a user to sort beers by rating – ordered from a “5-beer” rating to a “1-beer” (Get it? Beers instead of stars? Uber kuhl!) rating, or alphabetically (A-Z). The first time the app launches, it creates an NSUserDefault value to sort by rating, and establishes that as the default. In this method, you have:

1. Retrieved the sort key stored in NSUserDefaults
2. If the sort key is “rating,” the ascending variable is set to NO. If alphabetically, it is set to YES.
3. Perform a fetch.

Yep, that’s really all there is to it!

Once again, you are using a MagicalRecord method to interact with Core Data. findAllSortedBy:ascending is just one of the many ways to perform a fetch of Core Data entities using MagicalRecord. Some others include (pay attention – you’ll need to use one of these later):

• findAllInContext: – will find all entities of a type in context provided
• findAll – will find all entities on the current thread’s context
• findAllSortedBy:ascending:inContext: – similar to the one used earlier, but limited to the provided context
• findAllWithPredicate: – allows you to pass in an NSPredicate to search for objects.
• findAllSortedBy:ascending:withPredicate:inContext: – allows a sort to be done, with an ascending flag, in a particular context. It also allows you to pass in an NSPredicate for filtering.

There are many, many others you can take advantage of – just check out NSManagedObject+MagicalFinders.m.

To add the beer’s name and rating to a cell, find configureCell:atIndex:, and add the following:

- (void)configureCell:(UITableViewCell*)cell atIndex:(NSIndexPath*)indexPath {
    // Get current Beer
    Beer *beer = self.beers[indexPath.row];
    cell.textLabel.text = beer.name;	
    // Setup AMRatingControl
    AMRatingControl *ratingControl;
    if (![cell viewWithTag:20]) {
        ratingControl = [[AMRatingControl alloc] initWithLocation:CGPointMake(190, 10) emptyImage:[UIImage imageNamed:@"beermug-empty"] solidImage:[UIImage imageNamed:@"beermug-full"] andMaxRating:5];
        ratingControl.tag = 20;
        ratingControl.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin;
        ratingControl.userInteractionEnabled = NO;
        [cell addSubview:ratingControl];
    } else {
        ratingControl = (AMRatingControl*)[cell viewWithTag:20];
    }
    // Put beer rating in cell
    ratingControl.rating = [beer.beerDetails.rating integerValue];
}

Now find prepareForSegue:sender:, and within the if statement that checks if the segue identifier is “editBeer,” add:

if ([[segue identifier] isEqualToString:@"editBeer"]) {
    NSIndexPath *indexPath = [self.tableView indexPathForSelectedRow];
    Beer *beer = self.beers[indexPath.row];
    upcoming.beer = beer;
}

This will pass the Beer object to the BeerViewController, so that it displays the Beer’s information, allowing you to edit it.

Go ahead and run your project again.

You’ll now see the beer you added earlier, with its rating. You can also select the beer and edit its information. When you go back, the table will be updated! Sehr gut!

Try viewing an individual Beer, and without editing information, go back to the main list. Take a look at the log. You should see:

-[NSManagedObjectContext(MagicalSaves) MR_saveWithOptions:completion:](0x8b6bfa0) NO CHANGES IN ** DEFAULT ** CONTEXT - NOT SAVING

When you leave the details view, the code you’ve written will save the default context in viewWillDisappear:. However, since no changes were made, MagicalRecord recognizes there is no need to perform a save operation, and so it skips the process. The benefit of this is there is no need for you to think about whether you need to save – just try and save, and let MagicalRecord figure it out for you.

Finishing Touches

There are a few more things you’ll want the app to do for your users – like letting them delete beers, pre-populatin the list with your favorite beers and perform searches.

Delete

In MasterViewController.m, find tableView:commitEditingStyle:forRowAtIndexPath:, and add the following code:

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath {
    if (editingStyle == UITableViewCellEditingStyleDelete) {
        Beer *beerToRemove = self.beers[indexPath.row];
        // Remove Image from local documents
        if (beerToRemove.beerDetails.image) {
            [ImageSaver deleteImageAtPath:beerToRemove.beerDetails.image];
        }
        // Deleting an Entity with MagicalRecord
        [beerToRemove deleteEntity];
        [self saveContext];
        [self.beers removeObjectAtIndex:indexPath.row];
        [tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationFade];
    }
}

Notice that there is a call to saveContext. You’ll need to add some code there to make sure the delete went through. You’ve already done this once – can you figure out how to make it work? Ready……? Go!

// Save ManagedObjectContext using MagicalRecord
[[NSManagedObjectContext defaultContext] saveToPersistentStoreAndWait];

Run the app and delete a beer (using the traditional swipe of a cell). If you re-launch the app and the beer is still gone, you did something very right! It saved your change, and that means you’ve used MagicalRecord correctly. Pat yourself on the back!

Demo Data

It might be nice to give your users some initial data so they can see how easily they can keep track of their favorite beers. In AppDelegate.m, import Beer.h, BeerDetails.h. Then, just after you setup the Core Data stack, add the following:

// Setup App with prefilled Beer items.
if (![[NSUserDefaults standardUserDefaults] objectForKey:@"MR_HasPrefilledBeers"]) {
    // Create Blond Ale
    Beer *blondAle = [Beer createEntity];
    blondAle.name  = @"Blond Ale";
    blondAle.beerDetails = [BeerDetails createEntity];
    blondAle.beerDetails.rating = @4;
    [ImageSaver saveImageToDisk:[UIImage imageNamed:@"blond.jpg"] andToBeer:blondAle];
 
    // Create Wheat Beer
    Beer *wheatBeer = [Beer createEntity];
    wheatBeer.name  = @"Wheat Beer";
    wheatBeer.beerDetails = [BeerDetails createEntity];
    wheatBeer.beerDetails.rating = @2;
    [ImageSaver saveImageToDisk:[UIImage imageNamed:@"wheat.jpg"] andToBeer:wheatBeer];
 
    // Create Pale Lager
    Beer *paleLager = [Beer createEntity];
    paleLager.name  = @"Pale Lager";
    paleLager.beerDetails = [BeerDetails createEntity];
    paleLager.beerDetails.rating = @3;
    [ImageSaver saveImageToDisk:[UIImage imageNamed:@"pale.jpg"] andToBeer:paleLager];
 
    // Create Stout
    Beer *stout = [Beer createEntity];
    stout.name  = @"Stout Lager";
    stout.beerDetails = [BeerDetails createEntity];
    stout.beerDetails.rating = @5;
    [ImageSaver saveImageToDisk:[UIImage imageNamed:@"stout.jpg"] andToBeer:stout];
 
    // Save Managed Object Context
    [[NSManagedObjectContext defaultContext] saveToPersistentStoreWithCompletion:nil];
 
    // Set User Default to prevent another preload of data on startup.
    [[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"MR_HasPrefilledBeers"];
    [[NSUserDefaults standardUserDefaults] synchronize];
}

The starter app you downloaded at the beginning of this tutorial includes four frosty beer images. Here, you just create four different beers, and save them. Storing a flag in NSUserDefaults makes sure the app pre-fills the data model only once when it launches for the very fist time.

Run the app again, so you can see all the new beers. Try deleting one and re-launching the app; it won’t come back. If you want to see all the sample beers again, delete the app from the simulator or device, and re-launch.

Searching

Now that you have more than 1 beer, test the search capabilities. The starter app already included a Search Bar, – scroll to the top of the table to see it. The only thing you need to add is the logic to search the list of beers.

Earlier, you used a MagicalRecord helper method to do a fetch of all beers, and it simply returned all of the beers. Now, you want to retrieve all the beers that match a specific search term.

For this, you’ll need to use an NSPredicate. Earlier, this tutorial explained a method for fetching with an NSPredicate – can you guess how to do the search? The logic should live inside of doSearch in the MasterViewController.m file.