Mobiletuts+

Reading NFC Tags with Android

Ralf Wondratschek — Thu, 16 May 2013 17:32:40 +0000

Are you curious about what NFC is and how it can be integrated into your own Android applications? This tutorial will quickly introduce you to the topic before diving in and teaching you how to build a simple NFC reader app!

What is NFC?

NFC is the abbreviation for Near Field Communication. It is the international standard for contactless exchange of data. In contrast to a large range of other technologies, such as wireless LAN and Bluetooth, the maximum distance of two devices is 10cm. The development of the standard started in 2002 by NXP Semiconductors and Sony. The NFC Forum, a consortium of over 170 companies and members, which included Mastercard, NXP, Nokia, Samsung, Intel, and Google, has been designing new specifications since 2004.

There are various possibilities for NFC use with mobile devices; for example, paperless tickets, access controls, cashless payments, and car keys. With the help of NFC tags you can control your phone and change settings. Data can be exchanged simply by holding two devices next to each other.

In this tutorial I want to explain how to implement NFC with the Android SDK, which pitfalls exist, and what to keep in mind. We will create an app step by step, which can read the content of NFC tags supporting NDEF.

NFC Technologies

There are a variety of NFC tags that can be read with a smartphone. The spectrum ranges from simple stickers and key rings to complex cards with integrated cryptographic hardware. Tags also differ in their chip technology. The most important is NDEF, which is supported by most tags. In addidition, Mifare should be mentioned as it is the most used contactless chip technology worldwide. Some tags can be read and written, while others are read-only or encrypted.

Only the NFC Data Exchange Format (NDEF) is discussed in this tutorial.

Adding NFC Support in an App

We start with a new project and a blank activity. It is important to select a minimum SDK version of level 10, because NFC is only supported after Android 2.3.3. Remember to choose your own package name. I’ve chosen net.vrallev.android.nfc.demo, because vrallev.net is the domain of my website and the other part refers to the topic of this application.

	<uses-sdk
		android:minSdkVersion="10"
        android:targetSdkVersion="17" />

The default layout generated by Eclipse is almost sufficient for us. I’ve only added an ID to the TextView and changed the text.

	<TextView
        android:id="@+id/textView_explanation"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/explanation" />

To get access to the NFC hardware, you have to apply for permission in the manifest. If the app won’t work without NFC, you can specify the condition with the uses-feature tag. If NFC is required, the app can’t be installed on devices without it and Google Play will only display your app to users who own a NFC device.

	<uses-permission android:name="android.permission.NFC" />
    <uses-feature
        android:name="android.hardware.nfc"
        android:required="true" />

The MainActivity should only consist of the onCreate() method. You can interact with the hardware via the NfcAdapter class. It is important to find out whether the NfcAdapter is null. In this case, the Android device does not support NFC.

	package net.vrallev.android.nfc.demo;
	import android.app.Activity;
	import android.nfc.NfcAdapter;
	import android.os.Bundle;
	import android.widget.TextView;
	import android.widget.Toast;
	/**
	 * Activity for reading data from an NDEF Tag.
	 *
	 * @author Ralf Wondratschek
	 *
	 */
	public class MainActivity extends Activity {
		public static final String TAG = "NfcDemo";
		private TextView mTextView;
		private NfcAdapter mNfcAdapter;
		@Override
		protected void onCreate(Bundle savedInstanceState) {
			super.onCreate(savedInstanceState);
			setContentView(R.layout.activity_main);
			mTextView = (TextView) findViewById(R.id.textView_explanation);
			mNfcAdapter = NfcAdapter.getDefaultAdapter(this);
			if (mNfcAdapter == null) {
				// Stop here, we definitely need NFC
				Toast.makeText(this, "This device doesn't support NFC.", Toast.LENGTH_LONG).show();
				finish();
				return;
			}
			if (!mNfcAdapter.isEnabled()) {
				mTextView.setText("NFC is disabled.");
			} else {
				mTextView.setText(R.string.explanation);
			}
			handleIntent(getIntent());
		}
		private void handleIntent(Intent intent) {
			// TODO: handle Intent
		}
	}

If we start our app now, we can see the text whether NFC is enabled or disabled.

How to Filter for NFC Tags

We have our sample app and want to receive a notification from the system when we attach an NFC tag to the device. As usual, Android uses its Intent system to deliver tags to the apps. If multiple apps can handle the Intent, the activity chooser gets displayed and the user can decide which app will be opened. Opening URLs or sharing information is handled the same way.

NFC Intent Filter

There are three different filters for tags:

ACTION_NDEF_DISCOVERED
ACTION_TECH_DISCOVERED
ACTION_TAG_DISCOVERED

The list is sorted from the highest to the lowest priority.

Now what happens when a tag is attached to the smartphone? If the system detects a tag with NDEF support, an Intent is triggered. An ACTION_TECH_DISCOVERED Intent is triggered if no Activity from any app is registered for the NDEF Intent or if the tag does not support NDEF. If again no app is found for the Intent or the chip technology could not be detected, then a ACTION_TAG_DISCOVERED Intent is fired. The following graphic shows the process:

In summary this means that each app needs to filter after the Intent with the highest priority. In our case, this is the NDEF Intent. We implement the ACTION_TECH_DISCOVERED Intent first to highlight the difference between priorities.

Tech Discovered Intent

We must specify the technology we are interested in. For this purpose, we create a subfolder called xml in the res folder. In this folder we create the file nfc_tech_filter.xml, in which we specify the technologies.

	<?xml version="1.0" encoding="utf-8"?>
	<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
	    <tech-list>
	        <tech>android.nfc.tech.Ndef</tech>
	        <!-- class name -->
	    </tech-list>
	</resources>
	<!--
	<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
	    <tech-list>
	        <tech>android.nfc.tech.IsoDep</tech>
	        <tech>android.nfc.tech.NfcA</tech>
	        <tech>android.nfc.tech.NfcB</tech>
	        <tech>android.nfc.tech.NfcF</tech>
	        <tech>android.nfc.tech.NfcV</tech>
	        <tech>android.nfc.tech.Ndef</tech>
	        <tech>android.nfc.tech.NdefFormatable</tech>
	        <tech>android.nfc.tech.MifareClassic</tech>
	        <tech>android.nfc.tech.MifareUltralight</tech>
	    </tech-list>
	</resources>
	-->

Now we must create an IntentFilter in the manifest, and the app will be started when we attach a tag.

	<?xml version="1.0" encoding="utf-8"?>
	<activity
		android:name="net.vrallev.android.nfc.demo.MainActivity"
        android:label="@string/app_name" >
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.nfc.action.TECH_DISCOVERED" />
        </intent-filter>
        <meta-data
            android:name="android.nfc.action.TECH_DISCOVERED"
            android:resource="@xml/nfc_tech_filter" />
    </activity>

If no other app is registered for this Intent, our Activity will start immediately. On my device, however, other apps are installed, so the activity chooser gets displayed.

NDEF Discovered Intent

As I mentioned before, the Tech Discovered Intent has the second highest priority. However, since our app will support only NDEF, we can use the NDEF Discovered Intent instead, which has a higher priority. We can delete the technology list again and replace the IntentFilter with the following one.

	<intent-filter>
		<action android:name="android.nfc.action.NDEF_DISCOVERED" />
		<category android:name="android.intent.category.DEFAULT" />
		<data android:mimeType="text/plain" />
	</intent-filter>

When we attach the tag now, the app will be started like before. There is a difference for me, however. The activity chooser does not appear and the app starts immediately, because the NDEF Intent has a higher priority and the other apps only registered for the lower priorities. That’s exactly what we want.

Foreground Dispatch

Note that one problem remains. When our app is already opened and we attach the tag again, the app is opened a second time instead of delivering the tag directly. This is not our intended behavior. You can bypass the problem by using a Foreground Dispatch.

Instead of the system having distributed the Intent, you can register your Activity to receive the tag directly. This is important for a particular workflow, where it makes no sense to open another app.

I’ve inserted the explanations at the appropriate places in the code.

	package net.vrallev.android.nfc.demo;
	import android.app.Activity;
	import android.app.PendingIntent;
	import android.content.Intent;
	import android.content.IntentFilter;
	import android.content.IntentFilter.MalformedMimeTypeException;
	import android.nfc.NfcAdapter;
	import android.os.Bundle;
	import android.widget.TextView;
	import android.widget.Toast;
	/**
	 * Activity for reading data from an NDEF Tag.
	 *
	 * @author Ralf Wondratschek
	 *
	 */
	public class MainActivity extends Activity {
		public static final String MIME_TEXT_PLAIN = "text/plain";
		public static final String TAG = "NfcDemo";
		private TextView mTextView;
		private NfcAdapter mNfcAdapter;
		@Override
		protected void onCreate(Bundle savedInstanceState) {
			super.onCreate(savedInstanceState);
			setContentView(R.layout.activity_main);
			mTextView = (TextView) findViewById(R.id.textView_explanation);
			mNfcAdapter = NfcAdapter.getDefaultAdapter(this);
			if (mNfcAdapter == null) {
				// Stop here, we definitely need NFC
				Toast.makeText(this, "This device doesn't support NFC.", Toast.LENGTH_LONG).show();
				finish();
				return;
			}
			if (!mNfcAdapter.isEnabled()) {
				mTextView.setText("NFC is disabled.");
			} else {
				mTextView.setText(R.string.explanation);
			}
			handleIntent(getIntent());
		}
		@Override
		protected void onResume() {
			super.onResume();
			/**
			 * It's important, that the activity is in the foreground (resumed). Otherwise
			 * an IllegalStateException is thrown.
			 */
			setupForegroundDispatch(this, mNfcAdapter);
		}
		@Override
		protected void onPause() {
			/**
			 * Call this before onPause, otherwise an IllegalArgumentException is thrown as well.
			 */
			stopForegroundDispatch(this, mNfcAdapter);
			super.onPause();
		}
		@Override
		protected void onNewIntent(Intent intent) {
			/**
			 * This method gets called, when a new Intent gets associated with the current activity instance.
			 * Instead of creating a new activity, onNewIntent will be called. For more information have a look
			 * at the documentation.
			 *
			 * In our case this method gets called, when the user attaches a Tag to the device.
			 */
			handleIntent(intent);
		}
		private void handleIntent(Intent intent) {
			// TODO: handle Intent
		}
		/**
		 * @param activity The corresponding {@link Activity} requesting the foreground dispatch.
		 * @param adapter The {@link NfcAdapter} used for the foreground dispatch.
		 */
		public static void setupForegroundDispatch(final Activity activity, NfcAdapter adapter) {
			final Intent intent = new Intent(activity.getApplicationContext(), activity.getClass());
			intent.setFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP);
			final PendingIntent pendingIntent = PendingIntent.getActivity(activity.getApplicationContext(), 0, intent, 0);
			IntentFilter[] filters = new IntentFilter[1];
			String[][] techList = new String[][]{};
			// Notice that this is the same filter as in our manifest.
			filters[0] = new IntentFilter();
			filters[0].addAction(NfcAdapter.ACTION_NDEF_DISCOVERED);
			filters[0].addCategory(Intent.CATEGORY_DEFAULT);
			try {
				filters[0].addDataType(MIME_TEXT_PLAIN);
			} catch (MalformedMimeTypeException e) {
				throw new RuntimeException("Check your mime type.");
			}
			adapter.enableForegroundDispatch(activity, pendingIntent, filters, techList);
		}
		/**
		 * @param activity The corresponding {@link BaseActivity} requesting to stop the foreground dispatch.
		 * @param adapter The {@link NfcAdapter} used for the foreground dispatch.
		 */
		public static void stopForegroundDispatch(final Activity activity, NfcAdapter adapter) {
			adapter.disableForegroundDispatch(activity);
		}
	}

Now, when you attach a tag and our app is already opened, onNewIntent is called and no new Activity is created.

Reading Data From an NDEF Tag

The last step is to read the data from the tag. The explanations are inserted at the appropriate places in the code once again. The NdefReaderTask is a private inner class.

	package net.vrallev.android.nfc.demo;
	import java.io.UnsupportedEncodingException;
	import java.util.Arrays;
	import android.app.Activity;
	import android.app.PendingIntent;
	import android.content.Intent;
	import android.content.IntentFilter;
	import android.content.IntentFilter.MalformedMimeTypeException;
	import android.nfc.NdefMessage;
	import android.nfc.NdefRecord;
	import android.nfc.NfcAdapter;
	import android.nfc.Tag;
	import android.nfc.tech.Ndef;
	import android.os.AsyncTask;
	import android.os.Bundle;
	import android.util.Log;
	import android.widget.TextView;
	import android.widget.Toast;
	/*
	 * ... other code parts
	 */
	private void handleIntent(Intent intent) {
		String action = intent.getAction();
		if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(action)) {
			String type = intent.getType();
			if (MIME_TEXT_PLAIN.equals(type)) {
				Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
				new NdefReaderTask().execute(tag);
			} else {
				Log.d(TAG, "Wrong mime type: " + type);
			}
		} else if (NfcAdapter.ACTION_TECH_DISCOVERED.equals(action)) {
			// In case we would still use the Tech Discovered Intent
			Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
			String[] techList = tag.getTechList();
			String searchedTech = Ndef.class.getName();
			for (String tech : techList) {
				if (searchedTech.equals(tech)) {
					new NdefReaderTask().execute(tag);
					break;
				}
			}
		}
	}

	/**
	 * Background task for reading the data. Do not block the UI thread while reading.
	 *
	 * @author Ralf Wondratschek
	 *
	 */
	private class NdefReaderTask extends AsyncTask<Tag, Void, String> {
		@Override
		protected String doInBackground(Tag... params) {
			Tag tag = params[0];
			Ndef ndef = Ndef.get(tag);
			if (ndef == null) {
				// NDEF is not supported by this Tag.
				return null;
			}
			NdefMessage ndefMessage = ndef.getCachedNdefMessage();
			NdefRecord[] records = ndefMessage.getRecords();
			for (NdefRecord ndefRecord : records) {
				if (ndefRecord.getTnf() == NdefRecord.TNF_WELL_KNOWN && Arrays.equals(ndefRecord.getType(), NdefRecord.RTD_TEXT)) {
					try {
						return readText(ndefRecord);
					} catch (UnsupportedEncodingException e) {
						Log.e(TAG, "Unsupported Encoding", e);
					}
				}
			}
			return null;
		}
		private String readText(NdefRecord record) throws UnsupportedEncodingException {
			/*
			 * See NFC forum specification for "Text Record Type Definition" at 3.2.1
			 *
			 * http://www.nfc-forum.org/specs/
			 *
			 * bit_7 defines encoding
			 * bit_6 reserved for future use, must be 0
			 * bit_5..0 length of IANA language code
			 */
			byte[] payload = record.getPayload();
			// Get the Text Encoding
			String textEncoding = ((payload[0] & 128) == 0) ? "UTF-8" : "UTF-16";
			// Get the Language Code
			int languageCodeLength = payload[0] & 0063;
			// String languageCode = new String(payload, 1, languageCodeLength, "US-ASCII");
			// e.g. "en"
			// Get the Text
			return new String(payload, languageCodeLength + 1, payload.length - languageCodeLength - 1, textEncoding);
		}
		@Override
		protected void onPostExecute(String result) {
			if (result != null) {
				mTextView.setText("Read content: " + result);
			}
		}
	}

The app now successfully reads the content.

Useful Apps

To check whether data is read and written properly, I personally like to use following apps:

NFC TagInfo by NFC Research Lab for reading data
TagInfo by NXP SEMICONDUCTORS for reading data
TagWriter by NXP SEMICONDUCTORS for writing data

Conclusion

In this tutorial I have shown you how the data from a NDEF tag can be extracted. You could expand the example to other mime types and chip technologies; a feature to write data would be useful as well. The first step to work with NFC was made. However, the Android SDK offers much more possibilities, such as an easy exchange of data (called Android Beam).

About the Author

Ralf Wondratschek is a computer science student from Germany. In addition to his studies, Ralf works as a freelancer in the field of mobile computing. In the last few years he has worked with Java, XML, HTML, JSP, JSF, Eclipse, Google App Engine, and of course Android. He has published two Android apps to date which can be found here.

You can find out more about the author’s work on his homepage vrallev.net.

Sources

http://www.nfc-forum.org/home/n-mark.jpg

http://commons.wikimedia.org/wiki/File%3A%C3%9Cberlagert.jpg

http://developer.android.com/images/nfc_tag_dispatch.png

Connecting to an External Database With NuSOAP

Tomasz Wójcik — Wed, 15 May 2013 17:57:52 +0000

Many mobile applications use external databases that are located remotely on the Internet. In the following tutorial, we will create a simple database, connect to it, and receive or send data from this source. To do this we will use a Windows Phone 7 Silverlight based application and a NuSOAP web service. Let’s begin!

1. Install the Software

Before we start we need to install the following programs:

Windows Phone 7.5 SDK
Silverlight 5 Toolkit
PHP Library to run the web service (NuSOAP)

Obviously, we will also need some sort of web hosting where we can create a database. Most of the free hosting options will be enough for us, but they may have some limitations which I will discuss later on in this tutorial.

We also need an FTP client. In this tutorial I will use a FireFTP add-on to Mozilla Firefox. But you can use anything you want.

When all the programs are installed, we can continue.

2. Creating an External Database

Step 1

To begin, check that the hosting uses phpMyAdmin because I use it in the examples. But if you choose to use something else all the commands should be similar.

First we need to create a simple database, in our case it will contain only one table and three attributes:

ID – this value identifies the record. It must be set as an autoincrement field.
FirstName
LastName

The table name is MyUsers.

To do this just click “create table”:

Step 2

After that, fill in the cells as shown in this screenshot:

The table structure should now look like this:

Step 3

At this step we must note a few important points:

Host address

As I wrote earlier, free hostings have limits, one of these is to possibly connect only from localhost, remember that!

Database user

Our username to log into the database:

Database password
Database name

3. NuSOAP Server – Starting Web Service

Step 1

Starting our web service is very simple:

First, we must copy some files to the ftp server. I recommend a ftp server because it is directly connected to our hosting because of the localhost issue.

Once we’re connected, we need to copy the nusoap.php file which was downloaded earlier. We also require a file that will contain specific functions written by us that is necessary for our application; I called it MyService.php.

Step 2

After we copy the files, our FTP root directory should look like the image below:

Now open the MyService.php file and write into it:

<?php
// Pull in the NuSOAP
code require_once('nusoap.php');
// Create the server instance
$server = new soap_server();
// Initialize WSDL support
(MyService is name of our service)
$server----->configureWSDL('MyService', 'urn:MyService');
        // Character encoding
        $server->soap_defencoding = 'utf-8';
        //-------------------------------------------------
        //Registrations of our functions
        //-------------------------------------------------
        //Our web service functions will be here.
        //-------------------------------------------------
        $HTTP_RAW_POST_DATA = isset($HTTP_RAW_POST_DATA) ? $HTTP_RAW_POST_DATA : '';
        $server->service($HTTP_RAW_POST_DATA);
?>

The most important points are explained in the upper comments to code.

Step 3

From now on our service should work. We can check this by typing in the web browser:

http://www.ourdomain.com/MyService.php

If all went well you should see something like this:

After we successfully started the web service, we can go to the next step.

4. Writing Web Service Functions

In our service we need two functions:

The first function adds data to the online database.
The second function receives data from it.

Step 1

Let’s open MyService.php. We need to register the new function, to do this we should type:

    $server->register(
        'InsertData',   //Name of function
      	array('FirstName' => 'xsd:string', 'LastName' => 'xsd:string'), //Input Values
      	array('return' =>'xsd:boolean'), //Output Values
    	  'urn:MyServicewsdl',  //Namespace
        'urn:MyServicewsdl#InsertData',  //SoapAction
        'rpc',       //style
        'literal',   //can be encoded but it doesn't work with silverlight
        'Some_comments_about_function'
    );

Remember that it needs to be placed before the body function and after the server directives.

Here is some code explanation:

      'FirstName' => 'xsd:string'

“FirstName” is the name of variable, “string” is the type of variable (i.e. it can be int, longint, boolean, etc.).

When the function registers, we need to write the body of it. Below is the code and explanation:

    function InsertData($FirstName, $LastName) {
    	$connect = mysql_pconnect("Host","UserName","UserPassword"));
    	if ($connect) {
    		if(mysql_select_db("DatabaseName", $connect)) {
          mysql_query("INSERT INTO MyUser SET FirstName='$FirstName', LastName='$LastName'");
    			return true;
    		}
    	}
    	return false;
    }

          InsertData($FirstName, $LastName)

Here’s the name of the function and its attributes. They must be the same as in the registration section.

          $connect = mysql_pconnect("Host","UserName","UserPassword");

Here we can insert the data we noticed when we created the database.

          if(mysql_select_db("DatabaseName", $connect)) {

And also here.

After that it is a simple MySQL query that adds data to our database:

          mysql_query("INSERT INTO MyUser SET FistName='$FirstName', LastName='$LastName'");

Step 2

Now it’s time to write the second function. The structure will be similar to the first.

Here is the code of method registration:

      $server->register(
          'GetData',
        	array('ID' => 'xsd:int'),
        	array('return' =>'xsd:string'),
      	  'urn:MyServicewsdl',
          'urn:MyServicewsdl#GetData',
          'rpc',
          'literal',
          'Some comments about function 2'
      );

The main differences are in the Input/Output values section (changed types of variables).

Here’s the body function code:

       function GetData($ID) {
      	$connect = mysql_pconnect("Host","UserName","UserPassword");
      	if ($connect) {
      		if(mysql_select_db("DatabaseName", $connect)) {
            $sql = "SELECT FirstName, LastName FROM MyUser WHERE ID = '$ID'";
      			$result = mysql_fetch_array(mysql_query($sql));
      			return $result['FirstName']."-".$result['LastName'];
      		}
      	}
      	return false;
      }

Here is a little code explanation:

         return $result['FirstName']."-".$result['LastName'];

This line states what must return to the Windows Phone application.

Step 3

After writing all the functions the MyService.php file should look like this:

<?php
// Pull in the NuSOAP code
require_once('nusoap.php');
// Create the server instance
$server = new soap_server();
// Initialize WSDL support
configureWSDL('MyService', 'urn:MyService');
                // Character encoding
                $server->soap_defencoding = 'utf-8';
                //-------------------------------------------------
                //Register InsertData function
                $server->register(
                        'InsertData',
                      	array('FirstName' => 'xsd:string', 'LastName' => 'xsd:string'),
                      	array('return' =>'xsd:boolean'),
                    	  'urn:MyServicewsdl',
                        'urn:MyServicewsdl#InsertData',
                        'rpc',
                        'literal',
                        'Some comments about function'
                    );
                //Register GetData function
                $server->register(
                        'GetData',
                      	array('ID' => 'xsd:int'),
                      	array('return' =>'xsd:string'),
                    	  'urn:MyServicewsdl',
                        'urn:MyServicewsdl#GetData',
                        'rpc',
                        'literal',
                        'Some comments about function 2'
                    );
                //-------------------------------------------------
                //Body InsterData function
                function InsertData($FirstName, $LastName) {
                	$connect = mysql_pconnect("Host","UserName","UserPassword");
                	if ($connect) {
                		if(mysql_select_db("DatabaseName", $connect)) {
                      mysql_query("INSERT INTO MyUser SET FirstName='$FirstName', LastName='$LastName'");
                			return true;
                		}
                	}
                	return false;
                }
                //Body GetData function
                function GetData($ID) {
                	$connect = mysql_pconnect("Host","UserName","UserPassword");
                	if ($connect) {
                		if(mysql_select_db("DatabaseName", $connect)) {
                      $sql = "SELECT FirstName, LastName FROM MyUser WHERE ID = '$ID'";
                			$result = mysql_fetch_array(mysql_query($sql));
                			return $result['FirstName']."-".$result['LastName'];
                		}
                	}
                	return false;
                }
                //-------------------------------------------------
                $HTTP_RAW_POST_DATA = isset($HTTP_RAW_POST_DATA) ? $HTTP_RAW_POST_DATA : '';
                $server->service($HTTP_RAW_POST_DATA);
        ?>

To validate the functions we can again type http://www.ourdomain.com/MyService.php in the browser. Now the site should look a little bit different, but similar to this:

Now we’re ready to go to next step.

5. Creating a Simple Layout for a Windows Phone Application

Step 1

Firstly, we must create a Windows Phone app. Let’s run Microsoft Visual Studio for Windows Phone 2010. After Visual Studio starts, click “File” then “New Project”. You should see a dialog window like in the screenshot below:

Our app will use Silverlight, so we must check this template. We can also change the project name, like localisations, etc. In my case, the project name is “MyApplication”. After you have done this, click the OK button.

Step 2

At this point we must note what we need in our app. We need:

Two text boxes for sending data to the database (First Name, Last Name)
One text box to receive the data (ID)
Two buttons to approve our actions

Adding objects (such as buttons) to our application is easy, just drag it from “ToolBox” and drop it onto preview of the app. Keep in mind that you have a free hand in setting your own layout.

This is how it looks on my app:

Another important aspect is the names of the elements used in Visual Studio (they’re used later in code).

To change it, just click on element. Then in properties you can see text like “Textbox1″, click on it, and change it to something that you can remember, that is crucial. I used these names for my elements:

“FirstNameBox”, “LastNameBox”, and “IdBox” for text boxes
“SendBTN” and “ReadBTN” for buttons

That’s all we need to do in this step, we can move on.

6. Connecting to Service

To connect to the web service we must right click on “Reference” in “Solution Explorer” dialog and select “Add Service Reference…”

Here how this looks:

After that a new window will appear. In it we must write the address of our web service and the name of namespace.

In our case an address will be created, like on this scheme: http://www.ourdomain.com/MyService.php?wsdl.

After entering an address and clicking “Go” you should see something like this:

If you see the operations called “GetData” and “InsertData” that means the connection was successfully created! Remember to type namespace, in my case it is “MyService”. Now click OK.

7. Writing Windows Phone Functions

We’re almost at the end of this tutorial; we only need to write two simple functions.

Step 1

The first function will be behind the “Send” button, so double click it. Now we must add at the top of the file a “using” directive of our service:

      using MyApplication.MyService;

Let’s look at the send function behind the “Send” button, now it is empty:

        private void SendBTN_Click(object sender, RoutedEventArgs e)
        {
        }

Our complete function should look like this:

        private void SendBTN_Click(object sender, RoutedEventArgs e)
        {
            //Creating new proxy object of our service
            MyServicePortTypeClient send = new MyServicePortTypeClient();
            send.InsertDataCompleted += new EventHandler<InsertDataCompletedEventArgs>(send_InsertDataCompleted);
            //Calling method, as a parameters we type text contained in FirstNameBox and LastNameBox
            //This data will be sent to web service and later to database
            send.InsertDataAsync(FirstNameBox.Text, LastNameBox.Text);
        }
        void send_InsertDataCompleted(object sender, InsertDataCompletedEventArgs e)
        {
            //If our server return true, that means we're added data to database...
            if (e.Result)
                MessageBox.Show("Successfully added!");
            //...if return false we aren't.
            else
                MessageBox.Show("Some problems occured!");
        }

The most important points are explained in the code comments, but we must be aware of the following:

Method “send_InsertDataCompleted” executes when we get an answer from the server. Also this function is not in the “SendBTN” object, it is outside.

Now it’s time to test our work! Start to debug and fill out the boxes with some data. Here I have entered John as a first name and Doe as a last name, then I clicked Send:

Let’s see how the database looks now:

Yes, the new record with ID = 1 has appeared and everything is going well.

Step 2

Now we’ve reached the final function for receiving. It is similar to the previous method. Double click on the “Read” button and copy the code:

      private void ReadBTN_Click(object sender, RoutedEventArgs e)
        {
            //Creating new proxy object of our service
            MyServicePortTypeClient read = new MyServicePortTypeClient();
            read.GetDataCompleted += new EventHandler<GetDataCompletedEventArgs>(read_GetDataCompleted);
            //Calling method, as a parameters we type text contained in IdTextBox
            //but we must change text type of string to integer (ID in web service have integer type)
            read.GetDataAsync(Convert.ToInt32(IdBox.Text));
        }
        void read_GetDataCompleted(object sender, GetDataCompletedEventArgs e)
        {
            MessageBox.Show(e.Result);
        }

This is the same process as before, “read_GetDataCompleted” executes after getting data from the database. In this method we’ll use a message box to show our result, i.e. first and last name. There is one more step to do; we need to change the type of text in IdBox from string to integer because the variable called ID in the web service has an integer type. To do this I used a function called “Convert.ToIn32()”

8. Testing

Now we can see if this works. Enter ID into “IdTextBox”. I entered “1″, then clicked the “Read” button.

Everything is working! Our application is now complete!

Conclusion

In this tutorial we created a database using a Windows Phone 7 Silverlight based application and NuSOAP web service. This database is helpful to receive or send data. External databases are important because they are used by many mobile applications.

Create a Weather App with Forecast – Project Setup

Bart Jacobs — Mon, 13 May 2013 19:52:08 +0000

In March of this year, the company behind Dark Sky and Forecast.io introduced Forecast. Forecast is a simple weather API that provides both short- and longterm weather data. In this series, I will show you how to create a beautiful weather application for iOS powered by Forecast.

Introduction

Earlier this year, the Dark Sky Company introduced Forecast, a simple yet powerful weather API that provides short and longterm weather predictions. In this series we will create an iOS application that is powered by the Forecast API. Forecast is free for up to a thousand API calls per day, so feel free to sign up for a developer account and follow along with me.

Even though a number of open source wrappers for the Forecast API are available, in this series we will use the AFNetworking library to query the Forecast API. In the first part of this series, we will create the project’s foundation and implement a basic user interface. Even though our application is simple in scope, it will support multiple locations and that is what we will focus on in this article.

1. Project Setup

Step 1: Creating the Project

Fire up Xcode and create a new project based on the Empty Application template (figure 1). Name the application Rain and enable Automatic Reference Counting (figure 2).

Figure 1: Setting Up the Project

Figure 2: Configuring the Project

Step 2: Adding Libraries

For this project, we will be using three open source libraries, SVProgressHUD created by Sam Vermette, AFNetworking created by Mattt Thompson, and ViewDeck created by Tom Adriaenssen.

Since I am an avid fan of CocoaPods, I will be using it to install and manage the libraries of our project. If you are not familiar with CocoaPods, then I recommend visiting the website of CocoaPods or reading my introduction to CocoaPods. You can also manually add each library to your project if you prefer to not use CocoaPods.

Close your project, browse to the project’s root, and create a file named Podfile. Open Podfile in your favorite text editor and replace its contents with the snippet below. In the project’s pod file, we specify the platform, deployment target, and the pods we want to include in the project.

platform :ios, '6.0'
pod 'ViewDeck', '~> 2.2.11'
pod 'AFNetworking', '~> 1.2.1'
pod 'SVProgressHUD', '~> 0.9.0'

Open the Terminal application, browse to the project’s root, and install the libraries by executing pod install. In addition to installing the three pods that we specified in the project’s pod file, CocoaPods has already created an Xcode workspace for us. Open the new workspace by executing the open Rain.xcworkspace command from the command line.

Step 3: Adding Dependencies

Before we can continue, we need to link our project against a handful of frameworks. The AFNetworking library depends on the Mobile Core Services and System Configuration frameworks and the ViewDeck library makes use of the Quartz Core framework. Select the project from the Project Navigator on the left, select the Rain target in the list of targets, open the Build Phases tab at the top, and expand the Link Binary With Libraries drawer. Click the plus button to link your project against the aforementioned frameworks. We will be using the Core Location framework a bit later in this article so now is good time to link your project against that framework as well (figure 3).

Figure 3: Linking the Project Against a Handful of Frameworks

Step 4: Edit the Precompiled Header File

Before we start implementing the basic structure of our weather application, it is a good idea to edit the precompiled header file of our project. Add an import statement for each of the frameworks we added to our project a moment ago and do the same for the AFNetworking, SVProgressHUD, and ViewDeck libraries.

#import <Availability.h>
#ifndef __IPHONE_3_0
#warning "This project uses features only available in iOS SDK 3.0 and later."
#endif
#ifdef __OBJC__
    #import <UIKit/UIKit.h>
    #import <Foundation/Foundation.h>
    #import <QuartzCore/QuartzCore.h>
    #import <CoreLocation/CoreLocation.h>
    #import <MobileCoreServices/MobileCoreServices.h>
    #import <SystemConfiguration/SystemConfiguration.h>
    #import "AFNetworking.h"
    #import "SVProgressHUD.h"
    #import "IIViewDeckController.h"
#endif

2. Laying the Foundation

The concept and structure of the application is simple. The application manages three views, (1) a view in the center showing the current weather for a particular location, a view on the right showing the weather for the next few days, and a view on the left with a list of locations. The basic structure will make more sense once we’ve implemented it. To create this structure, we make use of the terrific ViewDeck library, created and maintained by Tom Adriaenssen. The ViewDeck library is one of the most powerful implementations of the sliding view design pattern originally introduced in Facebook for iOS.

Step 1: View Controllers

Before we put the ViewDeck library to use, we need to create the view controller classes that will manage the three views I mentioned in the previous paragraph. Create three UIViewController subclasses named MTWeatherViewController, MTForecastViewController, and MTLocationsViewController, respectively (figure 4). Don’t forget to create a user interface or XIB file for each class (figure 4).

Figure 4: Creating the Three Main View Controller Classes

Step 2: Creating a View Deck Controller

Open MTAppDelegate.m and import the header file the three UIViewController subclasses. Add a class extension and create a property of type IIViewDeckController and name it viewDeckController. The reason for this will become clear in a moment.

#import "MTAppDelegate.h"
#import "MTWeatherViewController.h"
#import "MTForecastViewController.h"
#import "MTLocationsViewController.h"
@interface MTAppDelegate ()
@property (strong, nonatomic) IIViewDeckController *viewDeckController;
@end

In application:didFinishLaunchingWithOptions:, we start by creating an instance of each of the three UIViewController subclasses. We then initialize an instance of the IIViewDeckController class and pass the view controller objects as arguments to initWithCenterViewController:leftViewController:rightViewController:. As the initializer indicates, the view deck controller that we create manages a center, left, and right view controller. The rest of the implementation of application:didFinishLaunchingWithOptions: should be familiar to you. We initialize the application window and set the view deck controller as its root view controller.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Initialize View Controllers
    MTLocationsViewController *leftViewController = [[MTLocationsViewController alloc] initWithNibName:@"MTLocationsViewController" bundle:nil];
    MTForecastViewController *rightViewController = [[MTForecastViewController alloc] initWithNibName:@"MTForecastViewController" bundle:nil];
    MTWeatherViewController *centerViewController = [[MTWeatherViewController alloc] initWithNibName:@"MTWeatherViewController" bundle:nil];
    // Initialize View Deck Controller
    self.viewDeckController = [[IIViewDeckController alloc] initWithCenterViewController:centerViewController leftViewController:leftViewController rightViewController:rightViewController];
    // Initialize Window
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    // Configure Window
    [self.window setRootViewController:self.viewDeckController];
    [self.window makeKeyAndVisible];
    return YES;
}

Build and run the application in the iOS Simulator or on a physical device to see the ViewDeck library in action. Even though the views of the view controllers are empty, the fundamental application structure is ready.

3. Adding Locations

As I mentioned in the introduction, in this tutorial we will also add the ability to add locations to the list of locations managed by the application. The MTLocationsViewController class is in charge of managing the list of locations and presenting them in a table view. The user can add the current location to the list of locations by tapping the table view’s first row, which will be labeled “Add Current Location”. Adding a new location with the Core Location framework is a responsibility of the MTWeatherViewController class as we will see in a few minutes.

This leaves us with a problem. How is the weather view controller notified when the user has tapped the first row of the locations view controller? Notification center? Delegation is a better choice in this context. Whenever I encounter the need for a one-way communication between two objects, I tend to choose for delegation in favor of notifications. A delegate protocol is much easier to wrap your head around and extending it is as simple as declaring another method.

Another option would be to pass a reference to the weather view controller to the locations view controller, but I don’t like this type of tight coupling. Tight coupling makes code less reusable and it results in unnecessarily complex object hierarchies when the code base grows over time. Delegation is the right choice for this problem.

Step 1: Declaring the Delegate Protocol

Open MTLocationsViewController.h and update the header file as shown below. We create a property for the view controller’s delegate and we declare the MTLocationsViewControllerDelegate protocol. The protocol defines two methods, (1) controllerShouldAddCurrentLocation:, which is invoked when the first row in the view controller’s table view is tapped, and (2) controller:didSelectLocation:, which is invoked when the user select a location from the list of locations.

#import <UIKit/UIKit.h>
@protocol MTLocationsViewControllerDelegate;
@interface MTLocationsViewController : UIViewController
@property (weak, nonatomic) id<MTLocationsViewControllerDelegate> delegate;
@end
@protocol MTLocationsViewControllerDelegate <NSObject>
- (void)controllerShouldAddCurrentLocation:(MTLocationsViewController *)controller;
- (void)controller:(MTLocationsViewController *)controller didSelectLocation:(NSDictionary *)location;
@end

Step 2: Adding the Table View

Revisit MTLocationsViewController.h one more time. Create an outlet for the view controller’s table view and make sure to conform the MTLocationsViewController class to the UITableViewDataSource and UITableViewDelegate protocols.

#import <UIKit/UIKit.h>
@protocol MTLocationsViewControllerDelegate;
@interface MTLocationsViewController : UIViewController <UITableViewDataSource, UITableViewDelegate>
@property (weak, nonatomic) id<MTLocationsViewControllerDelegate> delegate;
@property (weak, nonatomic) IBOutlet UITableView *tableView;
@end
@protocol MTLocationsViewControllerDelegate <NSObject>
- (void)controllerShouldAddCurrentLocation:(MTLocationsViewController *)controller;
- (void)controller:(MTLocationsViewController *)controller didSelectLocation:(NSDictionary *)location;
@end

Open MTLocationsViewController.xib, add a table view to the view controller’s view, and set the table view’s dataSource and delegate outlets to the File’s Owner object. Select the File’s Owner object and connect its tableView outlet with the table view that we added to the view controller’s view (figure 5).

Figure 5: Adding a Table View to List the Locations

Step 3: Populating the Table View

Before we implement the UITableViewDataSource and UITableViewDelegate protocols, we need to create a property that will serve as the table view’s data source. Create a class extension at the top of MTLocationsViewController.m and create a property named locations of type NSMutableArray. It will store the locations managed by our application.

#import "MTLocationsViewController.h"
@interface MTLocationsViewController ()
@property (strong, nonatomic) NSMutableArray *locations;
@end

Implementing the UITableViewDataSource and the UITableViewDelegate protocols is pretty straightforward. We start by declaring a static string constant for the cell reuse identifier. In the view controller’s viewDidLoad method we invoke setupView, a helper method in which we configure the view controller’s user interface. In setupView, we tell the table view to use the UITableViewCell class to instantiate new table view cells for the reuse identifier we declared earlier.

static NSString *LocationCell = @"LocationCell";

- (void)viewDidLoad {
    [super viewDidLoad];
    // Setup View
    [self setupView];
}

- (void)setupView {
    // Register Class for Cell Reuse
    [self.tableView registerClass:[UITableViewCell class] forCellReuseIdentifier:LocationCell];
}

Implementing the UITableViewDataSource and UITableViewDelegate protocols is trivial as you can see below. Two implementation details require a bit explaining. We store each location as a dictionary with four keys, (1) city, (2) country, (3) latitude, and (4) longitude. With this in mind, the implementation of configureCell:atIndexPath: should become a bit clearer. Note that configureCell:atIndexPath: is nothing more than another helper method.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return 1;
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return ([self.locations count] + 1);
}
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:LocationCell forIndexPath:indexPath];
    // Configure Cell
    [self configureCell:cell atIndexPath:indexPath];
    return cell;
}
- (void)configureCell:(UITableViewCell *)cell atIndexPath:(NSIndexPath *)indexPath {
    if (indexPath.row == 0) {
        [cell.textLabel setText:@"Add Current Location"];
    } else {
        // Fetch Location
        NSDictionary *location = [self.locations objectAtIndex:(indexPath.row - 1)];
        // Configure Cell
        [cell.textLabel setText:[NSString stringWithFormat:@"%@, %@", location[@"city"], location[@"country"]]];
    }
}
- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath {
    return NO;
}
- (BOOL)tableView:(UITableView *)tableView canMoveRowAtIndexPath:(NSIndexPath *)indexPath {
    return NO;
}

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
    [tableView deselectRowAtIndexPath:indexPath animated:YES];
    if (indexPath.row == 0) {
        // Notify Delegate
        [self.delegate controllerShouldAddCurrentLocation:self];
    } else {
        // Fetch Location
        NSDictionary *location = [self.locations objectAtIndex:(indexPath.row - 1)];
        // Notify Delegate
        [self.delegate controller:self didSelectLocation:location];
    }
    // Show Center View Controller
    [self.viewDeckController closeLeftViewAnimated:YES];
}

The tableView:didSelectRowAtIndexPath: also requires a short explanation. If the user taps the first row, labeled Add Current Location, the delegate is notified that the current location should be added to the list of locations. If any other row in the table view is tapped, the corresponding location is passed as the second argument of controller:didSelectLocation:, another delegate method of the MTLocationsViewController delegate protocol. This informs the delegate that the application should set the new location as the application’t default location and the weather data for that location should be fetched.

The last line of tableView:didSelectRowAtIndexPath: is also worth mentioning. The IIViewDeckController instance assigns itself to the view controllers it manages. The viewDeckController property provides access to a view controller’s view deck controller, which is convenient if you need to access the view controller’s view deck. It works very much like the navigationController property of a view controller instance. In the last line of tableView:didSelectRowAtIndexPath:, we tell the view deck controller to close the left view, which means that the center view becomes visible again.

Step 4: Keys and Constants

Before we continue populating the locations table view, we need to pay attention to some best practices. We currently use string literals to access the values of the location dictionary. Even though this works perfectly fine, it is better and safer to use string constants for this purpose. To make all this easy and maintainable, we declare the string constants in a central location. Let me show you how this works.

Create a subclass of NSObject and name it MTConstants. Replace the contents of MTConstants.h and MTConstants.m with the snippets shown below. It should be clear that MTConstants is not an Objective-C class. It is nothing more than a central place to store a set of constants specific to our project.

#pragma mark -
#pragma mark User Defaults
extern NSString * const MTRainUserDefaultsLocation;
extern NSString * const MTRainUserDefaultsLocations;
#pragma mark -
#pragma mark Notifications
extern NSString * const MTRainDidAddLocationNotification;
extern NSString * const MTRainLocationDidChangeNotification;
#pragma mark -
#pragma mark Location Keys
extern NSString * const MTLocationKeyCity;
extern NSString * const MTLocationKeyCountry;
extern NSString * const MTLocationKeyLatitude;
extern NSString * const MTLocationKeyLongitude;

#import "MTConstants.h"
#pragma mark -
#pragma mark User Defaults
NSString * const MTRainUserDefaultsLocation = @"location";
NSString * const MTRainUserDefaultsLocations = @"locations";
#pragma mark -
#pragma mark Notifications
NSString * const MTRainDidAddLocationNotification = @"com.mobileTuts.MTRainDidAddLocationNotification";
NSString * const MTRainLocationDidChangeNotification = @"com.mobileTuts.MTRainLocationDidChangeNotification";
#pragma mark -
#pragma mark Location Keys
NSString * const MTLocationKeyCity = @"city";
NSString * const MTLocationKeyCountry = @"country";
NSString * const MTLocationKeyLatitude = @"latitude";
NSString * const MTLocationKeyLongitude = @"longitude";

To make MTConstants really useful, add an import statement for MTConstants.h to your project’s precompiled header file so the constants declared in MTConstants are available throughout the project.

#import <Availability.h>
#ifndef __IPHONE_3_0
#warning "This project uses features only available in iOS SDK 3.0 and later."
#endif
#ifdef __OBJC__
    #import <UIKit/UIKit.h>
    #import <Foundation/Foundation.h>
    #import <QuartzCore/QuartzCore.h>
    #import <CoreLocation/CoreLocation.h>
    #import <MobileCoreServices/MobileCoreServices.h>
    #import <SystemConfiguration/SystemConfiguration.h>
    #import "AFNetworking.h"
    #import "SVProgressHUD.h"
    #import "IIViewDeckController.h"
    #import "MTConstants.h"
#endif

We can now update configureCell:atIndexPath: (MTLocationsViewController.m) as shown below. Not only will this give use code completion and a very, very small performance gain, the true benefit of this best practice is that the compiler will warn us in case of typos. I’m sure I don’t have to tell you that typos are one of the most common causes of bugs in software development.

- (void)configureCell:(UITableViewCell *)cell atIndexPath:(NSIndexPath *)indexPath {
    if (indexPath.row == 0) {
        [cell.textLabel setText:@"Add Current Location"];
    } else {
        // Fetch Location
        NSDictionary *location = [self.locations objectAtIndex:(indexPath.row - 1)];
        // Configure Cell
        [cell.textLabel setText:[NSString stringWithFormat:@"%@, %@", location[MTLocationKeyCity], location[MTLocationKeyCountry]]];
    }
}

At the moment, the locations property is empty and so will the table view. In initWithNibName:bundle:, we invoke loadLocations, a helper method that loads the array of locations. In loadLocations, load the array of locations that is stored in the application’s user defaults database. Note that we use another string constant that we declared in MTConstants.h.

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self) {
        // Load Locations
        [self loadLocations];
    }
    return self;
}

- (void)loadLocations {
    self.locations = [NSMutableArray arrayWithArray:[[NSUserDefaults standardUserDefaults] objectForKey:MTRainUserDefaultsLocations]];
}

Step 5: Delegate Assignment

As I mentioned earlier, the MTWeatherViewController instance will serve as the delegate of the locations view controller. Revisit MTAppDelegate.m and update application:didFinishLaunchingWithOptions: as shown below.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Initialize View Controllers
    MTLocationsViewController *leftViewController = [[MTLocationsViewController alloc] initWithNibName:@"MTLocationsViewController" bundle:nil];
    MTForecastViewController *rightViewController = [[MTForecastViewController alloc] initWithNibName:@"MTForecastViewController" bundle:nil];
    MTWeatherViewController *centerViewController = [[MTWeatherViewController alloc] initWithNibName:@"MTWeatherViewController" bundle:nil];
    // Configure Locations View Controller
    [leftViewController setDelegate:centerViewController];
    // Initialize View Deck Controller
    self.viewDeckController = [[IIViewDeckController alloc] initWithCenterViewController:centerViewController leftViewController:leftViewController rightViewController:rightViewController];
    // Initialize Window
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    // Configure Window
    [self.window setRootViewController:self.viewDeckController];
    [self.window makeKeyAndVisible];
    return YES;
}

By making this change, a warning should immediately pop up telling you that MTWeatherViewController does not conform to the MTLocationsViewControllerDelegate protocol. The compiler is right so let’s fix this.

Open MTWeatherViewController.h, import the header file of MTLocationsViewController, and conform MTWeatherViewController to the MTLocationsViewControllerDelegate protocol.

#import <UIKit/UIKit.h>
#import "MTLocationsViewController.h"
@interface MTWeatherViewController : UIViewController <MTLocationsViewControllerDelegate>
@end

Wait. Another warning? We haven’t implemented the two required methods of the delegate protocol yet hence the warning. Open MTWeatherViewController.m and add a stub implementation for each of the delegate methods.

- (void)controllerShouldAddCurrentLocation:(MTLocationsViewController *)controller {
    NSLog(@"%s", __PRETTY_FUNCTION__);
}
- (void)controller:(MTLocationsViewController *)controller didSelectLocation:(NSDictionary *)location {
    NSLog(@"%s", __PRETTY_FUNCTION__);
}

Step 6: Fetching the Current Location

It is finally time to fetch the current location of the device. Add a class extension at the top of MTWeatherViewController.m and declare two properties, (1) location (NSDictionary) to store the application’s default location and (2) locationManager (CLLocationManager), which we will use to fetch the device’s location. Conform the MTWeatherViewController class to the CLLocationManagerDelegate protocol and declare an instance variable named _locationFound of type BOOL. The purpose of _locationFound will become clear in a few minutes.

#import "MTWeatherViewController.h"
@interface MTWeatherViewController () <CLLocationManagerDelegate> {
    BOOL _locationFound;
}
@property (strong, nonatomic) NSDictionary *location;
@property (strong, nonatomic) CLLocationManager *locationManager;
@end

In the class’s designated initializer, initWithNibName:bundle:, we initialize and configure the location manager. We assign the view controller as the location manager’s delegate and set the location manager’s accuracy property to kCLLocationAccuracyKilometer. There is no need for better accuracy as we only need the location for weather data.

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self) {
        // Initialize Location Manager
        self.locationManager = [[CLLocationManager alloc] init];
        // Configure Location Manager
        [self.locationManager setDelegate:self];
        [self.locationManager setDesiredAccuracy:kCLLocationAccuracyKilometer];
    }
    return self;
}

The next piece of the puzzle is implementing, locationManager:didUpdateLocations:, one of the methods of the CLLocationManagerDelegate protocol, which is invoked each time the location manager has updated the device’s location. The second argument of locationManager:didUpdateLocations: is an array CLLocation instances. The implementation of locationManager:didUpdateLocations: also reveals the purpose of _locationFound. Despite the fact that we tell the location manager to stop updating the location as soon as locationManager:didUpdateLocations: is invoked, it is not uncommon that another update of the location invokes locationManager:didUpdateLocations: again even after sending the location manager a message of stopUpdatingLocation. If this were to happen, the same location would be added twice to the list of locations. The simple solution is to use a helper variable, _locationFound, that keeps track of the state that we’re in.

- (void)locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations {
    if (![locations count] || _locationFound) return;
    // Stop Updating Location
    _locationFound = YES;
    [manager stopUpdatingLocation];
    // Current Location
    CLLocation *currentLocation = [locations objectAtIndex:0];
    // Reverse Geocode
    CLGeocoder *geocoder = [[CLGeocoder alloc] init];
    [geocoder reverseGeocodeLocation:currentLocation completionHandler:^(NSArray *placemarks, NSError *error) {
        if ([placemarks count]) {
            _locationFound = NO;
            [self processPlacemark:[placemarks objectAtIndex:0]];
        }
    }];
}

We extract the first location from the array of locations and use the CLGeocoder class to reverse geocode that location. Reverse geocoding simply means finding out the name of the (closest) city and the location’s country. The completion handler of reverseGeocodeLocation: returns an array of placemarks. A placemark object is nothing more than a container for storing location data for a coordinate.

- (void)processPlacemark:(CLPlacemark *)placemark {
    // Extract Data
    NSString *city = [placemark locality];
    NSString *country = [placemark country];
    CLLocationDegrees lat = placemark.location.coordinate.latitude;
    CLLocationDegrees lon = placemark.location.coordinate.longitude;
    // Create Location Dictionary
    NSDictionary *currentLocation = @{ MTLocationKeyCity : city,
                                       MTLocationKeyCountry : country,
                                       MTLocationKeyLatitude : @(lat),
                                       MTLocationKeyLongitude : @(lon) };
    // Add to Locations
    NSUserDefaults *ud = [NSUserDefaults standardUserDefaults];
    NSMutableArray *locations = [NSMutableArray arrayWithArray:[ud objectForKey:MTRainUserDefaultsLocations]];
    [locations addObject:currentLocation];
    [locations sortUsingDescriptors:@[[NSSortDescriptor sortDescriptorWithKey:MTLocationKeyCity ascending:YES]]];
    [ud setObject:locations forKey:MTRainUserDefaultsLocations];
    // Synchronize
    [ud synchronize];
    // Update Current Location
    self.location = currentLocation;
    // Post Notifications
    NSNotification *notification2 = [NSNotification notificationWithName:MTRainDidAddLocationNotification object:self userInfo:currentLocation];
    [[NSNotificationCenter defaultCenter] postNotification:notification2];
}

In processPlacemark:, we extract the data that we’re looking for, city, country, latitude, and longitude, store it in a dictionary, and update the array of locations in the application’s user defaults database. Note that we sort the array of locations before updating the user defaults database. The view controller’s location property is updated with the new location and a notification is sent to notify any object interested in this event.

That’s not all, though. I have also overridden the setter of the view controller’s location property. Because the MTWeatherViewController class is in charge of adding new locations, we can delegate a few additional responsibilities to this class, such as updating the default location in the user defaults database. Because other parts of the application also need to know about a change in location, a notification with name MTRainLocationDidChangeNotification is posted. We also invoke updateView, another helper method that we will implement shortly.

- (void)setLocation:(NSDictionary *)location {
    if (_location != location) {
        _location = location;
        // Update User Defaults
        NSUserDefaults *ud = [NSUserDefaults standardUserDefaults];
        [ud setObject:location forKey:MTRainUserDefaultsLocation];
        [ud synchronize];
        // Post Notification
        NSNotification *notification1 = [NSNotification notificationWithName:MTRainLocationDidChangeNotification object:self userInfo:location];
        [[NSNotificationCenter defaultCenter] postNotification:notification1];
        // Update View
        [self updateView];
    }
}

Step 7: Adding a Label

We won’t spend much time on the user interface in this tutorial, but to make sure that everything works as we expect, it is good to have some visual feedback by adding a label to the weather view controller’s view displaying the selected location. Open MTWeatherViewController.h and create an outlet of type UILabel and name it labelLocation.

#import <UIKit/UIKit.h>
#import "MTLocationsViewController.h"
@interface MTWeatherViewController : UIViewController <MTLocationsViewControllerDelegate>
@property (weak, nonatomic) IBOutlet UILabel *labelLocation;
@end

Open MTWeatherViewController.xib, add a label to the view controller’s view, and connect the outlet with the newly added label (figure 6). In updateView (MTWeatherViewController.m), we update the label with the new location as shown below.

Figure 6: Adding the Location Label to the Weather View Controller

- (void)updateView {
    // Update Location Label
    [self.labelLocation setText:[self.location objectForKey:MTLocationKeyCity]];
}

Step 8: Implementing the Delegate Protocol

Thanks to the work we have done so far, implementing the two methods of the MTLocationsViewControllerDelegate protocol is easy. In controllerShouldAddCurrentLocation:, we tell the location manager to start updating the location. In controller:didSelectLocation:, we set the view controller’s location property to the location that the user selected in the locations view controller, which in turn invokes the setter method we overrode a bit earlier.

- (void)controllerShouldAddCurrentLocation:(MTLocationsViewController *)controller {
    // Start Updating Location
    [self.locationManager startUpdatingLocation];
}
- (void)controller:(MTLocationsViewController *)controller didSelectLocation:(NSDictionary *)location {
    // Update Location
    self.location = location;
}

4. Final Touches

Before wrapping up the first installment of this series, we need to add a few final touches. When the user launches the application, for example, the location property of the MTWeatherViewController class needs to be set to the location stored in the application’s user defaults. In addition, when the user launches our application for the very first time, a default location is not yet set in the application’s user defaults. This isn’t a big problem, but to offer a good user experience it would be better to automatically fetch the user’s current location when the application launches for the first time.

We can make both changes by amending the weather view controller’s viewDidLoad as shown below. The view controller’s location property is set to the location stored in the user defaults database. If no location is found, that is, self.location is nil, we tell the location manager to start updating the location. In other words, when the application is launched for the first time, the current location is automatically retrieved and stored.

- (void)viewDidLoad {
    [super viewDidLoad];
    // Load Location
    self.location = [[NSUserDefaults standardUserDefaults] objectForKey:MTRainUserDefaultsLocation];
    if (!self.location) {
        [self.locationManager startUpdatingLocation];
    }
}

There is one more loose end that we need to tie up. When a new location is added to the array of locations, the weather view controller posts a notification. We need to update the MTLocationsViewController class so that it adds itself as an observer for these notifications. By doing so, the locations view controller can update its table view whenever a new location is added.

Revisit MTLocationsViewController.m and update the initWithNibName:bundle: as shown below. We add the view controller as an observer for notifications with a name of MTRainDidAddLocationNotification. The implementation of didAddLocation: is straightforward, that is, we add the new location to the array of locations, sort the array by city, and reload the table view.

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self) {
        // Load Locations
        [self loadLocations];
        // Add Observer
        [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(didAddLocation:) name:MTRainDidAddLocationNotification object:nil];
    }
    return self;
}

- (void)didAddLocation:(NSNotification *)notification {
    NSDictionary *location = [notification userInfo];
    [self.locations addObject:location];
    [self.locations sortUsingDescriptors:@[[NSSortDescriptor sortDescriptorWithKey:MTLocationKeyCity ascending:YES]]];
    [self.tableView reloadData];
}

Don’t forget to remove the view controller as an observer in the view controller’s dealloc method. It is also good practice to set the view controller’s delegate property to nil in dealloc.

- (void)dealloc {
    // Remove Observer
    [[NSNotificationCenter defaultCenter] removeObserver:self];
    if (_delegate) {
        _delegate = nil;
    }
}

Build and run the application to see how all this works together. You may want to run the application in the iOS Simulator instead of a on physical device, because the iOS Simulator supports location simulation (figure 7), which makes it much easier to test location based applications such as the one we created.

Figure 7: Simulating Locations with the iOS Simulator

Conclusion

Even though we haven’t even touched the Forecast API, we did quite a bit of work in this article. I hope you have tried CocoaPods and are convinced of its power and flexibility. In the next installment of this series, we focus on the Forecast API and the AFNetworking library.

iOS SDK: Customizing Popovers

Aaron Crabtree — Thu, 09 May 2013 15:47:26 +0000

Popovers are a great way to display supplementary information in an iPad app. Inevitably, as with most iOS objects, a little customization goes a long way in creating a design that is unique and fits in with your own app. In this tutorial, we will build a basic popover, then explore customizations one at a time, giving you an easy-to-follow path to implement customizations in your own app.

1. Setting Up Your Project

Step 1

Launch Xcode and choose File > New > Project to create a new project. Select an iOS Single View Application and click Next.

Figure 1

Step 2

Fill in the text fields with your project name, organization name, and company identifier. Select iPad from the Devices drop down and make sure the box next to Use Automatic Reference Counting is checked. Leave the boxes for Use Storyboards and Include Unit Tests unchecked and click Next. Choose a location to save your file and click Create.

Figure 2

2. Adding a Navigation Controller

Step 1

Let’s use a navigation controller so that we can add a button to show the popover. Click on AppDelegate.m and find the application:didFinishLaunchingWithOptions: method. Add the following code to create a navigation controller and set it as the root view controller.

UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:self.viewController];
self.window.rootViewController = navController;

Step 2

Now we can add a plus button to the navigation bar. Click on ViewController.m and add the following code to the viewDidLoad method just below [super viewDidLoad];.

UIBarButtonItem *popoverButton = [[UIBarButtonItem alloc]
initWithBarButtonSystemItem:UIBarButtonSystemItemAdd
                     target:self
                     action:@selector(showPopover:)];
self.navigationItem.rightBarButtonItem = popoverButton;

The UIBarButtonSystemItemAdd creates a plus button; we’ll add it to the right side of the navigation bar. Next we’ll implement the showPopover: method used as the selector.

3. Showing the Popover

Step 1

Before implementing the showPopover: method, let’s add a property for the popover controller. Click on the ViewController.h file and add the following property.

@property (nonatomic, strong) UIPopoverController *popController;

Step 2

Navigate back to the ViewController.m file and declare the showPopover: method in the class extension as demonstrated below.

@interface ViewController ()
- (void)showPopover:(id)sender;
@end

Step 3

Add the following code to define the method under @implementation.

- (void)showPopover:(id)sender
{
    if (self.popController.popoverVisible) {
        [self.popController dismissPopoverAnimated:YES];
        return;
    }
    UIViewController *contentViewController = [[UIViewController alloc] init];
    contentViewController.view.backgroundColor = [UIColor yellowColor];
    UIPopoverController *popController = [[UIPopoverController alloc] initWithContentViewController:contentViewController];
    popController.popoverContentSize = CGSizeMake(300.0f, 600.0f);
    self.popController = popController;
    [self.popController presentPopoverFromBarButtonItem:sender
                    permittedArrowDirections:UIPopoverArrowDirectionUp
                                    animated:YES];
}

First we check to see if the popover is already being shown on the screen. If it is visible, the popover is dismissed and the method returns. If the popover is not being shown on the screen, we create a view controller to be displayed in the popover. Then we create the popover controller and set its size. The last line of code tells the popover controller to present itself from the navigation bar button that was tapped – in this case the plus button -and allows the arrow direction to point up only. One benefit to using this method is that if the user taps another button on the navigation bar, the tap is passed through to the navigation bar.

4. Testing the Standard Popover

At this point, we have implemented a standard popover. Build and run your project and tap the plus button to see a basic popover appear. Let’s take a look at the basics of customizing its appearance.

5. Subclassing `UIPopoverBackgroundView`

Step 1

In order to customize the appearance of the popover, we’ll need to subclass UIPopoverBackgroundView. Click File > New > File, choose an iOS Cocoa Touch Objective-C Class, and click Next.

Figure 3

Step 2

Name the class PopoverBackgroundView and choose UIPopoverBackgroundView from the Subclass of drop down.

Figure 4

Step 3

There are two UIPopoverBackgroundView properties that need to be overridden. Add the following code to synthesize the arrow direction and arrow offset, overriding the setter and getter methods for these two properties.

@synthesize arrowDirection  = _arrowDirection;
@synthesize arrowOffset     = _arrowOffset;

Step 4

There are three class methods that need to be overridden. Let’s define some values to use with the methods.

#define kArrowBase 30.0f
#define kArrowHeight 20.0f
#define kBorderInset 8.0f

Step 5

Add the code below to override the arrowBase, arrowHeight and contentViewInsets methods.

+ (CGFloat)arrowBase
{
    return kArrowBase;
}
+ (CGFloat)arrowHeight
{
    return kArrowHeight;
}
+ (UIEdgeInsets)contentViewInsets
{
    return UIEdgeInsetsMake(kBorderInset, kBorderInset, kBorderInset, 		kBorderInset);
}

The arrowBase method determines the width of the arrow’s base, while the arrowHeight method determines the height of the arrow. The contentViewInsets method indicates how far from the edge of the background to display the content.

Step 6

Let’s add a background color so we can see the different pieces clearly. Add the following code inside the if statement in the initWithFrame: method.

self.backgroundColor = [UIColor grayColor];

6. Setting the Popover Background View Class Property

Before we can test the popover, we’ll need to import and set the popover controller’s popover background view class property. Click on the ViewController.m file and import the popover background view header file as demonstrated below.

#import "PopoverBackgroundView.h"

While we’re still in the ViewController.m file, add the following line of code just below where we created the UIPopoverController in the showPopover: method.

popController.popoverBackgroundViewClass = [PopoverBackgroundView class];

7. Testing the Popover Background View

Build and run the project and tap the plus button to see the popover. You can see that the standard popover has been replaced with the customizations we’ve added so far. The gray border around the popover shows the insets returned from the contentViewInsets method. You can adjust the insets as needed to achieve a desired look. We’ll draw an arrow later in the tutorial to display on the screen.

8. Setting the Shadows and Rounded Corners

The wantsDefaultContentAppearance method determines whether the default inset shadows and rounded corners are displayed in the popover. By returning NO, the popover background view will no longer show the default shadows and rounded corners, allowing you to implement your own. Add the following code to override the method.

+ (BOOL)wantsDefaultContentAppearance
{
    return NO;
}

Build and run the project and you will be able to see the difference.

9. Adding the Arrow

Step 1

We’ll need to create and manage the arrow ourselves; let’s declare a property for an image view that will display the arrow. Add the following code to the class extension.

@property (nonatomic, strong) UIImageView *arrowImageView;

Now we can instantiate the image view. Replace the code inside the if statement in initWithFrame: with the following code.

self.backgroundColor = [UIColor clearColor];
UIImageView *arrowImageView = [[UIImageView alloc] initWithFrame:CGRectZero];
self.arrowImageView = arrowImageView;
[self addSubview:self.arrowImageView];

Step 2

Let’s change the border inset by updating the the kBorderInset defined in PopoverBackgroundView.m with the following code.

#define kBorderInset 0.0f

Step 3

In order to draw the arrow, we’ll need to declare a method to perform the drawing. Add the following method declaration in the class extension in PopoverBackgroundView.m.

- (UIImage *)drawArrowImage:(CGSize)size;

Step 4

Now add the method definition under @implementation.

- (UIImage *)drawArrowImage:(CGSize)size
{
    UIGraphicsBeginImageContextWithOptions(size, NO, 0);
    CGContextRef ctx = UIGraphicsGetCurrentContext();
    [[UIColor clearColor] setFill];
    CGContextFillRect(ctx, CGRectMake(0.0f, 0.0f, size.width, size.height));
    CGMutablePathRef arrowPath = CGPathCreateMutable();
    CGPathMoveToPoint(arrowPath, NULL, (size.width/2.0f), 0.0f);
    CGPathAddLineToPoint(arrowPath, NULL, size.width, size.height);
    CGPathAddLineToPoint(arrowPath, NULL, 0.0f, size.height);
    CGPathCloseSubpath(arrowPath);
    CGContextAddPath(ctx, arrowPath);
    CGPathRelease(arrowPath);
    UIColor *fillColor = [UIColor yellowColor];
    CGContextSetFillColorWithColor(ctx, fillColor.CGColor);
    CGContextDrawPath(ctx, kCGPathFill);
    UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();
    return image;
}

Instead of using an imported image, the code above programmatically creates the arrow.

Step 5

Each time the bounds of the popover background view subclass changes, the frame of the arrow needs to be recalculated. We can accomplish this by overriding layoutSubviews. Add the following code to PopoverBackgroundView.m.

- (void)layoutSubviews
{
    [super layoutSubviews];
	CGSize arrowSize = CGSizeMake([[self class] arrowBase], [[self class] arrowHeight]);
    self.arrowImageView.image = [self drawArrowImage:arrowSize];
    self.arrowImageView.frame = CGRectMake(((self.bounds.size.width - arrowSize.width) kBorderInset), 0.0f, arrowSize.width, arrowSize.height);
}

The frame of the arrow’s image view and the arrow’s image are calculated based on the bounds of the popover background view, the border’s insets, and the arrow’s base and height.

10. Testing the Popover

Build and run your project to see the customized popover. Even though the border inset is set to zero, the arrow is adjusted to line up with the inside edge of the right inset. By subtracting the border inset when determining the x coordinate for the image view frame for the arrow, we are able to align the image view appropriately.

Conclusion

This tutorial is designed to get you up and running with customizing a popover. There are many directions you can take the project from here; for example, adding another image view to display a custom border image. To do this, you would follow a similar pattern like we did when we created the image view for the arrow. Furthermore, you may want to customize the popover based on the arrow’s direction. In layoutSubviews, a series of if statements could help you test for the arrow’s direction so you could adjust the arrow accordingly. Leave a comment or question below if you have a specific direction you’d like to go with your customizations.

Build an AudioPlayer with PhoneGap: Application Tuning

Aurelio De Rosa — Wed, 08 May 2013 15:44:00 +0000

This is the third and final part of the series about Audero Audio Player. In this article, I will go over the remaining files so that you can finish the project and play around with it.

Series Overview

Style Tuning

jQuery Mobile does a lot of the work for you by enhancing pages’ elements for devices with smaller screens. However, there are some that I don’t care for, and we’ll adjust these in our style.css file. This is also used to style the player’s markup.

By default, even if you don’t have buttons within the header or the footer of a page, the framework still reserves some space on both side of the elements and truncates long titles. This behavior is applied to other elements as well. We can change it simply by applying the rule white-space: normal !important; to our targeted elements as .ui-title.

The source of the stylesheet is shown here:

.ui-header .ui-title,
.ui-footer .ui-title,
.ui-btn-inner *
{
  white-space: normal !important;
}
.photo
{
  text-align: center;
}
#player-play,
#player-stop
{
  display: inline-block;
  width: 48px;
  height: 48px;
}
#player-play
{
  background-image: url('../images/play.png');
}
#player-stop
{
  background-image: url('../images/stop.png');
}
#time-slider
{
  display: none;
}
div.ui-slider-track
{
  margin: 0;
  width: 100%;
}

jQuery Mobile Custom Configuration

jQuery Mobile has a default configuration that should be good enough for most projects with simple requirements. However, there will be times when you will want to modify or take control of some default behavior. You can achieve this by writing a configuration file. The file jquery.mobile.config.js is exactly where we’ll have the configuration. Please note that you must include the configuration file before the jQuery Mobile files. When jQuery Mobile starts, it fires the mobileinit event, which is the one you must bind to override the default settings.

We’ll make the change by assigning values to the properties of the $.mobile object. I won’t change a lot of properties. I’ll instead change the option to have the text shown on the page loader widget, and the theme.

The full source of the file is listed below:

$(document).on(
   'mobileinit',
   function()
   {
      // Page Loader Widget
      $.mobile.loader.prototype.options.text = 'Loading...';
      $.mobile.loader.prototype.options.textVisible = true;
      // Theme
      $.mobile.page.prototype.options.theme  = 'a';
      $.mobile.page.prototype.options.headerTheme = 'a';
      $.mobile.page.prototype.options.contentTheme = 'a';
      $.mobile.page.prototype.options.footerTheme = 'a';
      $.mobile.page.prototype.options.backBtnTheme = 'a';
   }
);

Build Configuration

The Adobe PhoneGap Build service gives you the ability to specify the metadata of an application, like author and description, by using a configuration file. This file is called config.xml. Explaining the format in depth is outside the scope of this series, but I’ll give you a brief overview. If you want to read more on this topic, take a look at the official documentation page.

The config.xml file follows the W3C widget specification and must stay inside the app’s root, at the same level of the index.html file. Its first line is the XML declaration, and the root of the document is a <widget> tag that has several possible attributes. The most important ones are id (the unique identifier for your project), and version (which specifies the version of the application). Inside the <widget> tag, you can write the metadata of your application. In our file we’ll use a lot of them, but the most important are the following:

name (required): The name of the application. It doesn’t have to be unique.
description (required): The description of the application. It’s particularly important because it will be shown in the app’s marketplace listing.
icon (optional): The icon to display on the devices that will install your app. If you do not specify it, the Cordova logo will be used.
splash (optional): This tag sets the splash screen of the application, which is the image shown during loading.
feature (optional): Specifies the features you want to use. For example, Android, before installing any app, shows the user the permissions it requires and, if the user agrees, it goes on.
preference (optional): A set of preferences you want to apply to your app. It’s a closed tag and you can have zero or more <preference> tags inside the file. It has two attributes, and both are required: name and value. There are a lot of preferences that you can define, but the most important one in my opinion is specifying the Cordova version used.

The <access> tag is also very important because, to cite the documentation, it provides your app with access to resources on other domains – in particular, it allows your app to load pages from external domains that can take over your entire webview. Recalling what we discussed in the section Managing External Links from the previous post, to open the external links in the Cordova WebView, we must add them to the app whitelist. Since our application won’t retrieve links from external and unsafe sources, we can shorten the process to allow for any external resource using the * special character. For example:

<access origin="*" />

I’ve pointed out the key points of the format, and now you can understand the source of the configuration file. The complete file is below:

<?xml version="1.0" encoding="UTF-8"?>
<widget xmlns     = "http://www.w3.org/ns/widgets"
        xmlns:gap = "http://phonegap.com/ns/1.0"
        id        = "com.audero.free.player.auderoaudioplayer"
        version   = "1.0.0">
   <name>Audero Audio Player</name>
   <description>Audero Audio Player is a basic audio player that collects the audio files and then allows the user to listen to them. This app also enables you to update the list at any time to include other files that may have been downloaded after running the operation for the first time. You can also remove any unwanted audio from the list by clicking an icon on the right side of the song's name. The sound list is ordered alphabetically with letter dividers to organize and group the list items, and has a search box to filter the files.</description>
   <author href="http://www.audero.it" email="aurelioderosa@gmail.com">Aurelio De Rosa</author>
   <feature name="http://api.phonegap.com/1.0/network"/>
   <feature name="http://api.phonegap.com/1.0/media"/>
   <feature name="http://api.phonegap.com/1.0/file"/>
   <feature name="http://api.phonegap.com/1.0/notification"/>
   <preference name="phonegap-version" value="2.3.0" />
   <preference name="target-device" value="universal" />
   <access origin="*" />
   <!-- Icons -->
   <icon src="icon.png" width="64" height="64" gap:role="default" />
   <icon src="images/icon-72x72.png" width="72" height="72" gap:platform="android" gap:density="hdpi" />
   <icon src="images/icon-96x96.png" width="96" height="96" gap:platform="android" gap:density="xhdpi" />
   <icon src="images/icon-72x72.png" width="72" height="72" gap:platform="ios" />
   <!-- Splash Screens -->
   <gap:splash src="splash.png" />
   <gap:splash src="images/splash-160x220.png" gap:platform="android" gap:density="ldpi" />
   <gap:splash src="splash.png" gap:platform="android" gap:density="mdpi" />
   <gap:splash src="images/splash-450x650.png" gap:platform="android" gap:density="hdpi" />
</widget>

Running the Application

In the last section, all the business logic, HTML and CSS files for the application were built, so now it’s time to set the entry functions for the application and play. The targeted function will be the initApplication() method of the Application class. It will run once Cordova is fully loaded, ensuring that you can safely call the Cordova APIs. To do this, we’ll set initApplication() as a callback function for the deviceready event by adding the following code to the index.html file. You can see this by looking at the next snippet:

<script>
  $(document).on('pagebeforecreate orientationchange', Application.updateIcons);
  $(document).one('deviceready', Application.initApplication);
</script>

Possible Improvements

You are now at the end of the project. That being said, every project has room for improvements and new feature, so before I conclude the series, I would like to suggest some of these to you.

The first feature that you can add is the internationalization (i18n) of the application. Our player doesn’t have much text, so translating it into other languages should be very easy. To translate the application, you can use the Globalization API, an API added to the core starting from version 2.2.0. In addition, a specific jQuery library like jquery-i18n-properties or jQuery-i18n would surely be useful for this feature.

Other minor suggestions are:

Allow the user to create playlist.
Create a “Play All” button to play all the songs in the list.
Create a ratings system for the audio so that the user can filter and order songs by rating.
Add a “Repeat” button so that the user can continue listening to the current song.

These suggestions are just some of the potential improvements you can make to the Audero Audio Player. Using the information from this tutorial and your own skills, you can do much, much more.

Conclusion

As you’ve seen throughout this series, you can build powerful and useful apps using web technologies and popular frameworks. Now it’s your turn to play around with this project. Try starting your own project to test what you learned in this series!

Tuts+ Premium Cash Back Offer: 3 Days to Go

Joel Bankhead — Tue, 07 May 2013 16:30:36 +0000

This offer ends soon! Act now and don’t miss out on cash back when trying a monthly Tuts+ Premium subscription.

At $19 a month, Tuts+ Premium is fantastic value. But it’s even better when we hand your first $19 right back to you!

For a limited time we’re offering $19 cash back to new Tuts+ Premium monthly subscribers when signing up via PayPal. If you’ve been thinking about checking out our extensive library of courses, tutorials, eBooks and guides there’s never been a better time to join up and dive in.

This offer ends at noon on the 20th of May AEST, so act fast.

Become a Tuts+ Premium Member and take your creative & technical skills to a new level.

What can you learn on Tuts+ Premium? Glad you asked! Currently, more than 15,000 members are sharpening their skills in a wide range of areas including web design, web development, Photoshop, vectors, video effects, and many more.

With Tuts+ Premium you learn from expert instructors in every field, such as:

Designer Justin Maller (Nike, Verizon, DC Shoe Co.)
Illustrator Russell Tate (McDonald’s, Coca-Cola)
Developer Burak Guzel (Software Engineer at Facebook)

Join now and get instant access to your very own library of courses, tutorials, and eBooks, available whenever you need them. Become part of a community of over 15,000 members and start getting better at the skills you care about. Our dedicated team adds new content weekly, so there’s always something fresh to sink your teeth into.

Join Tuts+ Premium

How To Submit an iOS App to the App Store

Bart Jacobs — Mon, 06 May 2013 17:09:11 +0000

You have worked weeks or months on your first iOS application and you are ready to submit your masterpiece to Apple’s App Store. How do you do this? Is your application ready for submission? I am sure that some of these questions have entered your mind at one point or another. Is submitting an application as simple as sending Apple your application’s binary? Not quite. With this tutorial, I will provide you with a detailed map to get your application submitted to Apple’s App Store.

Introduction

Even though the App Store review process is a black box for the most part, that doesn’t mean that you can’t prepare yourself and your application for Apple’s review process. Apple provides guidelines to help you stay within the sometimes invisible boundaries of what is and isn’t allowed in the App Store.

The first time you submit an application to the App Store is exciting and nerve-racking at the same time. Even for experienced iOS developers, submitting an application to the App Store is often a stressful undertaking because it is something that most developers don’t do on a daily basis.

Throughout this article, I am assuming that you are a registered iOS developer which means that you are enrolled in Apple’s iOS Developer Program and are allowed to submit applications for publication in the App Store. To submit an iOS application to the App Store, you need to be a registered iOS developer. Red flag? Don’t worry. You can enroll in Apple’s iOS Developer Program by visiting this link and clicking the Enroll Now button.

Figure 1: Enrolling in Apple’s iOS Developer Program

1. Is your application ready?

Step 1: Testing

An application isn’t necessarily ready when you’ve written the last line of code or implemented the final feature of the application’s specification. Have you tested your application on one or more physical devices? Have you profiled your application for memory leaks and performance issues? Does your application crash from time to time? The family of iOS devices has grown substantially over the past years and it is important to test your application on as many iOS devices as you can lay your hands on. Common issues include not optimizing an application for the iPhone 5′s 4″ screen or the iPad Mini’s 7.9″ screen.

The iOS Simulator is a great tool, but it runs on your Mac, which has more memory and processing power than the phone in your pocket. I can assure you that the differences in performance between an old(er) iPhone 3GS and an iPhone 5 are like night and day. As an iOS developer, you should never get rid of an old iOS device as long as you build or maintain applications that can run on any of these older devices.

Apple’s Review Process isn’t airtight, but it is very capable of identifying problems that might affect your application’s user experience. If your application crashes from time to time or it becomes slow after ten minutes of use, then you have some work to do before submitting it to the App Store. Even if Apple’s review team doesn’t spot the problem, your users will. If the people using your application are not pleased, they will leave bad reviews on the App Store, which may harm sales or inhibit downloads.

Step 2: Rules and Guidelines

As I mentioned earlier, Apple provides developers with a number of documents that are a great help during the creation and development process of your application. The documents that you should be aware of are the iOS Human Interface Guidelines and the App Store Review Guidelines. Despite the availability of these documents, it seems that few developers take the time to browse them, let alone read them. It shouldn’t be a surprise that some applications are therefore rejected even though the reason for the rejection is clearly stated in these documents.

Even if you don’t intend to read the iOS Human Interface Guidelines or the App Store Review Guidelines, it is important to know about some of the rules that they talk about. Take a look at the short list below to get an idea of what your application should and shouldn’t do.

Your application …

doesn’t crash.
shouldn’t use private API’s.
shouldn’t replicate the functionality of native applications.
should use In App Purchase for in-app (financial) transactions.
shouldn’t use the camera or microphone without the user’s knowledge.
only uses artwork that you have the copyright of or you have permission to use.

Keep in mind that this is a tiny subset of the guidelines included in the aforementioned documents. The majority of the rules and guidelines are trivial, but some are not and you might even violate some of them inadvertently. Let me give you an example. Before Apple started using its own maps, the MapKit framework used Google’s maps. This was clear to the user because of the small Google logo in the bottom left corner of each map. However, if some part of your application’s user interface covered or obscured Google’s logo, your application would get rejected. This rule seems trivial, but it is a rule that is easily violated if you’re not careful. Even automated tests won’t cover you in this case.

2. Prerequisites

Before you can even start thinking about submitting your application to the App Store, you need to make sure that you have an App ID, a valid distribution certificate, and a valid provisioning profile. Let me show you what this entails.

Step 1: App ID

Every application needs an App ID or application identifier. There are two types of application identifiers, (1) an explicit App ID and (2) a wildcard App ID. A wildcard App ID can be used for building and installing multiple applications. Despite the convenience of a wildcard App ID, an explicit App ID is required if your application uses iCloud or makes use of other iOS features, such as Game Center, Apple Push Notifications, or In App Purchase.

If you’re not sure what App ID best fits your project, then I recommend reading Technical Note QA1713 for more information about this topic.

Step 2: Distribution Certificate

To submit an application to the App Store, you need to create an iOS provisioning profile for distribution. To create such a provisioning profile, you first need to create a distribution certificate. The process for creating a distribution certificate is very similar to creating a development certificate. If you have tested your application on a physical device, then you are probably already familiar with the creation of a development certificate.

If you need to refresh your memory, I suggest reading Apple’s detailed guide about signing certificates and provisioning profiles. The process is not difficult once you understand how the various pieces of the puzzle fit together.

Step 3: Provisioning Profile

Once you’ve created an App ID and a distribution certificate, you can create an iOS provisioning profile for distributing your application through the App Store. Keep in mind that you cannot use the same provisioning profile that you use for ad hoc distribution. You need to create a separate provisioning profile for App Store distribution. If you use a wildcard App ID for your project, then you can use the same provisioning profile for multiple applications.

Step 4: Build Settings

With the App ID, distribution certificate, and provisioning profile in place, it is time to configure your target’s build settings in Xcode. This means selecting the target from the list of targets in Xcode’s Project Navigator, opening the Build Settings tab at the top, and updating the settings in the Code Signing section to match the distribution provisioning profile you created earlier. Newly added provisioning profiles are sometimes not immediately visible in the Code Signing section of the build settings. Quitting and relaunching Xcode remedies this issue.

Figure 2: Configuring the Target’s Build Settings

Even though the code signing process is fairly simple once you understand it, it is something that trips up a lot of developers. I don’t know a single Cocoa developer who hasn’t run into code signing issues at some point in their career. Once you’ve taken this hurdle, the rest of the submission process is fairly easy.

Step 5: Deployment Target

It is useful to write a few words about your application’s deployment target. Each target in an Xcode project, has a deployment target, which indicates the minimum version of the operating system that the application can run on. It is up to you to set the deployment target, but keep in mind that modifying the deployment target is not something you can do without consequences once your application is in the App Store. If you increase the deployment target for an update of your application, then users who already purchased your application but don’t meet the new deployment target, cannot run the update. It gets really problematic when a user downloads an update through iTunes (not the device), replacing the previous version on their computer, and then discovers that the new update doesn’t run on their device.

I have two very simple tips with regards to your application’s deployment target. (1) Be very careful when you decide to increase the deployment target of an existing application. Mention this in the application’s release notes of the updates that precede the change and again in the update that uses the new deployment target. If your warn your customers well in advance, you have done all you can to prevent potential problems. (2) For new applications, I almost always set the deployment target to the last major release, iOS 6 at the time of writing. Because of the incredible adoption rate of new iOS releases, there is no harm in doing this. Some people think that they miss out on a large chunk of the market, but that is not true. Take the release of iOS 6 as an example. One month after the release of iOS 6, more than 60% of iOS devices had upgraded to the new version of iOS. Unfortunately, the same isn’t true for Android.

3. Assets

Step 1: Icons

You probably know that an application icon is a vital component of every iOS application, but you need to make sure that your application ships with the correct sizes of the artwork. Take a look at the list below for an overview.

iTunes Artwork: 1024px x 1024px (required)
iPad/iPad Mini: 72px x 72px and 114px x 114px (required)
iPhone/iPod Touch: 57px x 57px and 114px x 114px (required)
Search Icon: 29px x 29px and 58px x 58px (optional)
Settings Application: 50px x 50px and 100px x 100px (optional)

It goes without saying that you don’t need to include an application icon for the iPad/iPad Mini device family if your application only targets the iPhone/iPod Touch device family, and vice versa.

Step 2: Screenshots

Each application can have up to five screenshots and you must provide at least one. If you are developing a universal application, then you need to provide separate screenshots for iPhone/iPod Touch and iPad/iPad Mini. In addition, you can optionally include separate screenshots for the 3.5″ and the 4″ screen sizes of the iPhone/iPod Touch. This is quite a bit of work and you want to make sure that the screenshots show your application from its best side. Shiny Development sells a Mac application, Status Magic that helps you get the status bar in your screenshots right. Status Magic will save you quite a bit of time.

It is important to spend some time thinking about the screenshots. Your application’s screenshots are often the only thing that a customer can use to decide whether she purchases or downloads your application or not. What a lot of developers don’t know is that the screenshots don’t have to be actual screenshots. The hard rule is that the size of each screenshot needs to be that of the screen size of the target device. Many companies are creative with this rule. Take a look at the screenshots of Where’s My Water?, for example. By using this strategy, screenshots can be much more attractive and compelling.

Step 3: Metadata

Before you submit your application, it is a good idea to have your application’s metadata at hand. This includes (1) your application’s name, (2) the version number, (3) the primary (and an optional secondary) category, (4) a concise description, (5) keywords, and (6) a support URL. If you are submitting an update, then you can also provide information for the What’s new in this Version section.

Does your application require users to sign in? Then you also need to provide Apple with a test or demo account to make sure that the review team can immediately sign in and use your application without first having to sign up for an account.

4. Submission Preparation

The submission process has become much easier since the release of Xcode 4. You can now validate and submit an application using Xcode, for example. First, however, you need to create your application in iTunes Connect.

Visit iTunes Connect, sign in with your iOS developer account, and click Manage Your Apps on the right. Click the Add New App in the top left, select iOS App, and fill out the form.

Figure 3: Visit iTunes Connect to Get Started

Step 1: Basic Information

The App Name, which needs to be unique, is the name of your application as it will appear in the App Store. This can be different than the name that is displayed below your application icon on the home screen, but it is recommended to choose the same name. The SKU Number is a unique string that identifies your application. I usually use the application’s bundle identifier. The last piece of information is the Bundle ID of your application. This means selecting the (wildcard or explicit) App ID that you created earlier from the drop down menu.

Figure 4: Specifying Name, SKU Number, and Bundle ID

Step 2: Price and Availability

In the next step, you specify your application’s price and availability. Apple works with price tiers so that you don’t have to specify a price for each country that Apple operates in. You can also specify in which stores your application should – or shouldn’t – be available. The information that you enter in this step can be modified once your application is live in the App Store. In other words, you can change the price and availability of an application without having to submit an update.

Figure 5: Specifying Price and Availability

Step 3: Metadata

We’ve already covered the application’s metadata. The only aspect that I haven’t talked about yet is your application’s rating. Based on your application’s content and functionality, it is given a rating. This rating is not only useful for telling users about your application’s content and features, the rating is also used by the operating system for the parental controls features.

It is strongly recommended that you don’t try to outsmart the rating system. Apple is well aware of this and will reject your application if it doesn’t agree with the rating that you have set.

Figure 6: Entering Your Application’s Metadata and Assigning a Rating

Step 4: Ready to Upload Binary

Once your application’s metadata is submitted, you will be presented with a summary of your application. Under Versions, you should see the version that you submitted a moment ago. Click the View Details button and click the Ready to Upload Binary button in the top right. You are then asked one or more questions regarding your application and, if all went well, you should see a message telling you that you are now ready to upload your application binary. The status of your application has changed to Waiting for Upload.

Figure 7: Your Application’s Summary

5. Uploading Binary

To submit your application, you need to create an archive of your application. You can only create an archive by building your application on a physical device. If you select the iOS Simulator in the active scheme, you will notice that the Archive option in Xcode’s Product menu is grayed out. Connect an iOS device to your Mac, select it in the active scheme, and select Archive from Xcode’s Product menu.

Figure 8: Archiving Your Application using Xcode

If all went well, you should now have an archive and Xcode’s Organizer should automatically open and show you the archive you just created. Select the archive from the list and click the Distribute… button on the right. From the options you are presented with, select Submit to the iOS App Store. After entering your iOS developer account credentials and selecting the Application and Code Signing Identity, the application binary is uploaded to Apple’s servers. During this process, your application is also validated. If an error occurs during the validation, the submission process will fail. The validation process is very useful as it will tell you if there is something wrong with your application binary that would otherwise result in a rejection by the App Store review team.

Figure 9: Archiving Your Application using Xcode

Figure 10: Submit Your Application to the iOS App Store

Figure 11: Enter Your iOS Developer Account Credentials

Figure 12: Select Application and Code Signing Identity

Figure 13: An Error is Shown if Validation Fails

6. Waiting

If the submission process went without problems, your application’s status will change to Waiting for Review. It takes several days for Apple to review your application and the time it takes, tends to fluctuate over time. To get an idea of the average review times of iOS and Mac applications, I recommend visiting the website of Shiny Development (Dave Verwer). This will give you a good indication of how long the review process will take.

Conclusion

The submission process is quite lengthy for a new application, but submitting an update to the App Store is much less cumbersome. Keep in mind that the submission process is much more involving if your application is localized in various languages as your application’s metadata needs to be localized as well. However, localizing your application is well worth the effort as it often results in higher sales and positive customer feedback.

Wanted: Producer for Tuts+ Premium

Amanda Hackwith — Mon, 06 May 2013 15:02:46 +0000

Tuts+ Premium is hiring for an expert in mobile development. We’re looking for a developer who’s passionate and experienced with mobile design and development to produce courses with us! You need to be experienced in mobile development platforms, be proactive and engaged with the industry, and have a passion for teaching. Sound like you? Read on!

We’re looking for a new Producer to join the Tuts+ Premium Content team. A Producer is responsible for recruiting and producing courses for Tuts+ Premium members and is a vital part of the content team. They should have professional experience in designing and developing for mobile (apps, websites, etc) and additional experience in screencasting or teaching.

A Producer role requires a commitment of 20 hours a week and ability to perform daily responsibilities, but you’ll have flexibility in scheduling your time. This role is a contract position and is paid monthly.

An ideal Producer on our team will have:

At least 3+ years professional experience in mobile development or design. This could include successfully developing iOS/Android apps, web apps, or other mobile interfaces. Should love every aspect of mobile development–from concept and design, to development and deployment, on up to iteration and strategy. Hands-on knowledge of backend development is required.
Experience screencasting or teaching in a on-line environment preferred.
Preferred experience working with WordPress, S3 and other content publishing tools.
Excellent written and verbal communication skills to recruit and work with other talented professionals. Good working relationships in the mobile dev industry.
Experience working with high performance remote teams using a variety of web-based management tools and technologies. (Such as email, Basecamp, Skype and other web-based tools.)
A knack for time management, reliable performance and managing multiple projects at once.
A passion for teaching and strong ideas about how to make Tuts+ Premium even better!

Apply!

Think you fit the bill? Then we want to hear from you! Send a us a short email to amanda@envato.com telling us how you’re the perfect fit for the Tuts+ Premium team. Make sure to include links or samples to back up your claims. A great application will be sure to mention:

Your professional experience in mobile development and design. Links to public apps or sites is highly preferred.
Previous samples of screencasting and teaching work. The more you’ve done, the better!
Your member name if you’re already active with the community.
Your available hours and local time zone.
Your top suggestion or idea for Tuts+ Premium courses. If you were brought on as a Producer, what would be the first course you’d want to make?

Make sure to get your email in by May 14, 2013. While every email will be considered we may not be able to respond to every application, but if you sound like a good fit you’ll hear from us soon. Join the team and help us make Tuts+ Premium even better!

Android SDK: Working with Google Maps – Displaying Places of Interest

Sue Smith — Fri, 03 May 2013 11:30:37 +0000

With Google Maps in your Android apps, you can provide users with localization functions, such as geographical information. Throughout this series we have been building an Android app in which the Google Maps Android API v2 combines with the Google Places API. So far we have displayed a map, in which the user can see their current location, and we have submitted a Google Places query to return data about nearby places of interest. This required setting up API access for both services. In the final part of the series, we will parse the Google Places JSON data and use it to show the user nearby places of interest. We will also make the app update the markers when the user location changes.

This is the last of four parts in a tutorial series on Using Google Maps and Google Places in Android apps:

This is a snapshot of the final app.

1. Process the Place Data

Step 1

You will need to add the following import statements to your Activity class for this tutorial:

import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;
import android.util.Log;

In the last tutorial we created an inner AsyncTask class to handle fetching the data from Google Places in the background. We added the doInBackground method to request and retrieve the data. Now we can implement the onPostExecute method to parse the JSON string returned from doInBackground, inside your AsyncTask class, after the doInBackground method:

protected void onPostExecute(String result) {
	//parse place data returned from Google Places
}

Step 2

Back in the second part of this series, we created a Marker object to indicate the user’s last recorded location on the map. We are also going to use Markers to show the nearby places of interest. We will use an array to store these Markers. At the top of your Activity class declaration, add the following instance variable:

private Marker[] placeMarkers;

By default, the Google Places API returns a maximum of 20 places, so let’s define this as a constant too:

private final int MAX_PLACES = 20;

When we create the Markers for each place, we will use MarkerOptions objects to configure the Marker details. Create another array instance variable for these:

private MarkerOptions[] places;

Now let’s instantiate the array. In your Activity onCreate method, after the line in which we set the map type, create an array of the maximum required size:

placeMarkers = new Marker[MAX_PLACES];

Now let’s turn to the onPostExecute method we created. First, loop through the Marker array, removing any existing Markers. This method will execute multiple times as the user changes location:

if(placeMarkers!=null){
	for(int pm=0; pm<placeMarkers.length; pm++){
		if(placeMarkers[pm]!=null)
			placeMarkers[pm].remove();
	}
}

When the app code first executes, new Markers will be created. However, when the user changes location, these methods will execute again to update the places displayed. For this reason the first thing we must do is remove any existing Markers from the map to prepare for creating a new batch.

Step 3

We will be using Java JSON resources to process the retrieved place data. Since these classes throw certain exceptions, we need to build in a level of error handling throughout this section. Start by adding try and catch blocks:

try {
	//parse JSON
}
catch (Exception e) {
	e.printStackTrace();
}

Inside the try block, create a new JSONObject and pass it to the result JSON string returned from doInBackground:

JSONObject resultObject = new JSONObject(result);

If you look at the Place Search page on the Google Places API documentation, you can see a sample of what the query actually returns in JSON. You will see that the places are contained within an array named “results”. Let’s first retrieve that array from the returned JSON object:

JSONArray placesArray = resultObject.getJSONArray("results");

You should refer to the sample JSON result as we complete each section of this process – keep the page open in a browser while you complete the remainder of the tutorial. Next let’s instantiate the MarkerOptions array we created with the length of the returned “results” array:

places = new MarkerOptions[placesArray.length()];

This should give us a MarkerOptions object for each place returned. Add a loop to iterate through the array of places:

//loop through places
for (int p=0; p<placesArray.length(); p++) {
	//parse each place
}

Step 4

Now we can parse the data for each place returned. Inside the for loop, we will build details to pass to the MarkerOptions object for the current place. This will include latitude and longitude, place name, type and vicinity, which is an excerpt of the address data for the place. We will retrieve all of this data from the Google Places JSON, passing it to the Marker for the place via its MarkerOptions object. If any of the values are missing in the returned JSON feed, we will simply not display a Marker for that place, in case of Exceptions. To keep track of this, add a boolean flag:

boolean missingValue=false;

Now add local variables for each aspect of the place we need to retrieve and pass to the Marker:

LatLng placeLL=null;
String placeName="";
String vicinity="";
int currIcon = otherIcon;

We create and initialize a LatLng object for the latitude and longitude, strings for the place name and vicinity and initially set the icon to use the default icon drawable we created. Now we need another try block, so that we can detect whether any values are in fact missing:

try{
	//attempt to retrieve place data values
}
catch(JSONException jse){
	missingValue=true;
	jse.printStackTrace();
}

We set the missing value flag to true for checking later. Inside this try block, we can now attempt to retrieve the required values from the place data. Start by initializing the boolean flag to false, assuming that there are no missing values until we discover otherwise:

missingValue=false;

Now get the current object from the place array:

JSONObject placeObject = placesArray.getJSONObject(p);

If you look back at the sample Place Search data, you will see that each place section includes a “geometry” section which in turn contains a “location” section. This is where the latitude and longitude data for the place is, so retrieve it now:

JSONObject loc = placeObject.getJSONObject("geometry").getJSONObject("location");

Attempt to read the latitude and longitude data from this, referring to the “lat” and “lng” values in the JSON:

placeLL = new LatLng(
	Double.valueOf(loc.getString("lat")),
	Double.valueOf(loc.getString("lng")));

Next get the “types” array you can see in the JSON sample:

JSONArray types = placeObject.getJSONArray("types");

Tip: We know this is an array as it appears in the JSON feed surrounded by the “[" and "]” characters. We treat any other nested sections as JSON objects rather than arrays.

Loop through the type array:

for(int t=0; t<types.length(); t++){
	//what type is it
}

Get the type string:

String thisType=types.get(t).toString();

We are going to use particular icons for certain place types (food, bar and store) so add a conditional:

if(thisType.contains("food")){
	currIcon = foodIcon;
	break;
}
else if(thisType.contains("bar")){
	currIcon = drinkIcon;
	break;
}
else if(thisType.contains("store")){
	currIcon = shopIcon;
	break;
}

The type list for a place may actually contain more than one of these places, but for convenience we will simply use the first one encountered. If the list of types for a place does not contain any of these, we will leave it displaying the default icon. Remember that we specified these types in the Place Search URL query string last time:

food|bar|store|museum|art_gallery

This means that the only place types using the default icon will be museums or art galleries, as these are the only other types we asked for.

After the loop through the type array, retrieve the vicinity data:

vicinity = placeObject.getString("vicinity");

Finally, retrieve the place name:

placeName = placeObject.getString("name");

Step 5

After the catch block in which you set the missingValue flag to true, check that value and set the place MarkerOptions object to null, so that we don’t attempt to instantiate any Marker objects with missing data:

if(missingValue)	places[p]=null;

Otherwise, we can create a MarkerOptions object at this position in the array:

else
	places[p]=new MarkerOptions()
	.position(placeLL)
	.title(placeName)
	.icon(BitmapDescriptorFactory.fromResource(currIcon))
	.snippet(vicinity);

Step 6

Now, at the end of onPostExecute after the outer try and catch blocks, loop through the array of MarkerOptions, instantiating a Marker for each, adding it to the map and storing a reference to it in the array we created:

if(places!=null && placeMarkers!=null){
	for(int p=0; p<places.length && p<placeMarkers.length; p++){
		//will be null if a value was missing
		if(places[p]!=null)
			placeMarkers[p]=theMap.addMarker(places[p]);
	}
}

Storing a reference to the Marker allows us to easily remove it when the places are updated, as we implemented at the beginning of the onPostExecute method. Notice that we include two conditional tests each time this loop iterates, in case the Place Search did not return the full 20 places. We also check in case the MarkerOptions is null, indicating that a value was missing.

Step 7

Finally, we can instantiate and execute our AsyncTask class. In your updatePlaces method, after the existing code in which we built the search query string, start this background processing to fetch the place data using that string:

new GetPlaces().execute(placesSearchStr);

You can run your app now to see it in action. It should display your last recorded location together with nearby places of interest. The colors you see on the Markers will depend on the places returned. Here is the app displaying a user location in Glasgow city center, UK:

Perhaps unsurprisingly a lot of the places listed in Glasgow are bars.

When the user taps a Marker, they will see the place name and snippet info:

2. Update With User Location Changes

Step 1

The app as it stands will execute once when it is launched. Let’s build in the functionality required to make it update to reflect changes in the user location, refreshing the nearby place Markers at the same time.

Alter the opening line of the Activity class declaration to make it implement the LocationListener interface so that we can detect changes in the user location:

public class MyMapActivity extends Activity implements LocationListener {

A Location Listener can respond to various changes, each of which uses a dedicated method. Inside the Activity class, implement these methods:

@Override
public void onLocationChanged(Location location) {
	Log.v("MyMapActivity", "location changed");
	updatePlaces();
}
@Override
public void onProviderDisabled(String provider){
	Log.v("MyMapActivity", "provider disabled");
}
@Override
public void onProviderEnabled(String provider) {
	Log.v("MyMapActivity", "provider enabled");
}
@Override
public void onStatusChanged(String provider, int status, Bundle extras) {
	Log.v("MyMapActivity", "status changed");
}

The only one we are really interested in is the first, which indicates that the location has changed. In this case we call the updatePlaces method again. Otherwise we simply write out a Log message.

At the end of the updatePlaces method, add a request for the app to receive location updates:

locMan.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 30000, 100, this);

We use the Location Manager we created earlier in the series, requesting updates using the network provider, at delays of 30 seconds (indicated in milliseconds), with a minimum location change of 100 meters and the Activity class itself to receive the updates. You can, of course, alter some of the parameters to suit your own needs.

Tip: Although the requestLocationUpdates method specifies a minimum time and distance for updates, in reality it can cause the onLocationChanged method to execute much more often, which has serious performance implications. In any apps you plan on releasing to users, you should therefore limit the frequency at which your code responds to these location updates. The alternative requestSingleUpdate method used on a timed basis may be worth considering.

Step 2

Last but not least, we need to take care of what happens when the app pauses and resumes. Override the two methods as follows:

@Override
protected void onResume() {
	super.onResume();
	if(theMap!=null){
		locMan.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 30000, 100, this);
	}
}
@Override
protected void onPause() {
	super.onPause();
	if(theMap!=null){
		locMan.removeUpdates(this);
	}
}

We check for the GoogleMap object before attempting any processing, as in onCreate. If the app is pausing, we stop it from requesting location updates. If the app is resuming, we start requesting the updates again.

Tip: We’ve used the LocationManager.NETWORK_PROVIDER a few times in this series. If you are exploring localization functionality in your apps, check out the alternative getBestProvider method with which you can specify criteria for Android to choose a provider based on such factors as accuracy and speed.

Before We Finish

That pretty much completes the app! However, there are many aspects of the Google Maps Android API v2 that we have not even touched on. Once you have your app running you can experiment with features such as rotation and tilting. The updated maps service displays indoor and 3D maps in certain places. The following image shows the 3D facility with the app if the user location was in Venice, Italy:

This has the map type set to normal – here is another view of Venice with the hybrid map type set:

Conclusion

In this tutorial series we have worked through the process of integrating both Google Maps and Google Places APIs in a single Android app. We handled API key access, setting up the development environment, workspace and application to use Google Play Services. We utilized location data, showing the user location together with nearby places of interest, and displaying the data with custom UI elements. Although what we have covered in this series is fairly extensive, it really is only the beginning when it comes to building localization features into Android apps. With the release of Version 2 of the Maps API, Android apps are set to take such functions to the next level.

Build an AudioPlayer with PhoneGap: Application Logic

Aurelio De Rosa — Fri, 03 May 2013 00:11:06 +0000

This is the second part of the series about Audero Audio Player. In this article, we’re going to create the business logic of our player. I’ll also explain some of the Cordova APIs that were introduced in the previous article.

Series Overview

Creating the Player

In this section, I’ll show you the class called Player, which let us play, stop, rewind and fast-forward. The class relies heavily on the Media API; without its methods, our player will be completely useless. In addition to the Media API, this class takes advantage of the alert() method of the Notification API. The look of the alert varies among platforms. Most of the supported operating systems use a native dialog box but others, like Bada 2.X, use the classic browser’s alert() function, which is less customizable. The former method accepts up to four parameters:

message: A string containing the message to show
alertCallback: A callback to invoke when the alert dialog is dismissed
title: The title of the dialog (the default value is “Alert”)
buttonName: The button’s text included in the dialog (the default value is “OK”)

Bear in mind that Windows Phone 7 ignores the button name and always uses the default. Windows Phone 7 and 8 don’t have a built-in browser alert, so if you want to use alert('message');, you have to assign window.alert = navigator.notification.alert.

Now that I’ve explained the APIs used by Player, we can take a look at how it’s made. We have three properties:

media: the reference to the current sound object
mediaTimer: which will contain a unique interval ID created using the setInterval() function that we’ll pass to clearInterval() to stop the sound’s timer
isPlaying: a variable that specifies if the current sound is playing or not. In addition to the property, the class has several methods.

The initMedia() method initializes the media property with a Media object that represents the sound selected by the user. The latter is notified using the Notification API in case of error. The aim of the playPause, stop(), and seekPosition() methods should be obvious, so I’ll move on. The resetLayout() and changePlayButton() methods are very simple. They are used to reset or update the player’s layout according to the action performed by the user. The last remaining method is updateSliderPosition(), which is similar to the time slider. The latter has zero (the beginning of the slider) as the default value for the current position, set using the value="0" attribute. This must be updated accordingly while the sound is playing to give to the user visual feedback concerning elapsed playing time.

We’ve uncovered all the details of this class, so here is the source code of the file:

var Player = {
   media: null,
   mediaTimer: null,
   isPlaying: false,
   initMedia: function(path) {
      Player.media = new Media(
         path,
         function() {
            console.log('Media file read succesfully');
            if (Player.media !== null)
               Player.media.release();
            Player.resetLayout();
         },
         function(error) {
            navigator.notification.alert(
               'Unable to read the media file.',
               function(){},
               'Error'
            );
            Player.changePlayButton('play');
            console.log('Unable to read the media file (Code): ' + error.code);
         }
      );
   },
   playPause: function(path) {
      if (Player.media === null)
         Player.initMedia(path);
      if (Player.isPlaying === false)
      {
         Player.media.play();
         Player.mediaTimer = setInterval(
            function() {
               Player.media.getCurrentPosition(
                  function(position) {
                     if (position > -1)
                     {
                        $('#media-played').text(Utility.formatTime(position));
                        Player.updateSliderPosition(position);
                     }
                  },
                  function(error) {
                     console.log('Unable to retrieve media position: ' + error.code);
                     $('#media-played').text(Utility.formatTime(0));
                  }
               );
            },
            1000
         );
         var counter = 0;
         var timerDuration = setInterval(
            function() {
               counter++;
               if (counter > 20)
                  clearInterval(timerDuration);
               var duration = Player.media.getDuration();
               if (duration > -1)
               {
                  clearInterval(timerDuration);
                  $('#media-duration').text(Utility.formatTime(duration));
                  $('#time-slider').attr('max', Math.round(duration));
                  $('#time-slider').slider('refresh');
               }
               else
                  $('#media-duration').text('Unknown');
            },
            100
         );
         Player.changePlayButton('pause');
      }
      else
      {
         Player.media.pause();
         clearInterval(Player.mediaTimer);
         Player.changePlayButton('play');
      }
      Player.isPlaying = !Player.isPlaying;
   },
   stop: function() {
      if (Player.media !== null)
      {
         Player.media.stop();
         Player.media.release();
      }
      clearInterval(Player.mediaTimer);
      Player.media = null;
      Player.isPlaying = false;
      Player.resetLayout();
   },
   resetLayout: function() {
      $('#media-played').text(Utility.formatTime(0));
      Player.changePlayButton('play');
      Player.updateSliderPosition(0);
   },
   updateSliderPosition: function(seconds) {
      var $slider = $('#time-slider');
      if (seconds < $slider.attr('min'))
         $slider.val($slider.attr('min'));
      else if (seconds > $slider.attr('max'))
         $slider.val($slider.attr('max'));
      else
         $slider.val(Math.round(seconds));
      $slider.slider('refresh');
   },
   seekPosition: function(seconds) {
      if (Player.media === null)
         return;
      Player.media.seekTo(seconds * 1000);
      Player.updateSliderPosition(seconds);
   },
   changePlayButton: function(imageName) {
      var background = $('#player-play')
      .css('background-image')
      .replace('url(', '')
      .replace(')', '');
      $('#player-play').css(
         'background-image',
         'url(' + background.replace(/images\/.*\.png$/, 'images/' + imageName + '.png') + ')'
      );
   }
};

Managing the Audio Files

This section illustrates the AppFile class that will be used to create, delete, and load the sounds using the Web Storage API. This API has two areas, Session and Local, but Cordova uses the latter. All the sounds are stored in an item titled “files” as you can see by looking at the _tableName properties.

Please note that this API is only able to store basic data. Therefore, to fit our need to store objects, we’ll use the JSON format. JavaScript has a class to deal with this format called JSON. It uses the methods parse() to parse a string and recreate the appropriate data, and stringify() to convert the object in a string. As a final note, I won’t be using the dot notation of the API because Windows Phone 7 doesn’t support it, so we’ll use the setItem() and getItem() methods to ensure compatibility for all devices.

Now that you have an overview of how we’ll store the data, let’s talk about the data that we need to save. The only information that we need for each found sound is the name (name property) and an absolute path (fullPath property). The AppFile class also has a “constant”, called EXTENSIONS, where we’ll set the extensions that will be tested against each file. If they match up, the file will be collected by the application. We have a method to add a file (addFile()), one method to delete a file (deleteFile()), one method that deletes the whole database (deleteFiles()), and, lastly, two methods that retrieve the file from the database: getAppFiles() to retrieve all the files, and getAppFile() to retrieve just one. The class also has four comparison methods, two static (compare() and compareIgnoreCase()) and two non-static (compareTo() and compareToIgnoreCase()). The last method is the one used to retrieve the index of a certain file, getIndex(). The AppFile class enables you to perform all the basic operations you may need.

The code that implements what we’ve discussed can be read here:

function AppFile(name, fullPath)
{
   var _db = window.localStorage;
   var _tableName = 'files';
   this.name = name;
   this.fullPath = fullPath;
   this.save = function(files)
   {
      _db.setItem(_tableName, JSON.stringify(files));
   }
   this.load = function()
   {
      return JSON.parse(_db.getItem(_tableName));
   }
}
AppFile.prototype.addFile = function()
{
   var index = AppFile.getIndex(this.fullPath);
   var files = AppFile.getAppFiles();
   if (index === false)
      files.push(this);
   else
      files[index] = this;
   this.save(files);
};
AppFile.prototype.deleteFile = function()
{
   var index = AppFile.getIndex(this.fullPath);
   var files = AppFile.getAppFiles();
   if (index !== false)
   {
      files.splice(index, 1);
      this.save(files);
   }
   return files;
};
AppFile.prototype.compareTo = function(other)
{
   return AppFile.compare(this, other);
};
AppFile.prototype.compareToIgnoreCase = function(other)
{
   return AppFile.compareIgnoreCase(this, other);
};
AppFile.EXTENSIONS = ['.mp3', '.wav', '.m4a'];
AppFile.compare = function(appFile, other)
{
   if (other == null)
      return 1;
   else if (appFile == null)
      return -1;
   return appFile.name.localeCompare(other.name);
};
AppFile.compareIgnoreCase = function(appFile, other)
{
   if (other == null)
      return 1;
   else if (appFile == null)
      return -1;
   return appFile.name.toUpperCase().localeCompare(other.name.toUpperCase());
};
AppFile.getAppFiles = function()
{
   var files = new AppFile().load();
   return (files === null) ? [] : files;
};
AppFile.getAppFile = function(path)
{
   var index = AppFile.getIndex(path);
   if (index === false)
      return null;
   else
   {
      var file = AppFile.getAppFiles()[index];
      return new AppFile(file.name, file.fullPath);
   }
};
AppFile.getIndex = function(path)
{
   var files = AppFile.getAppFiles();
   for(var i = 0; i < files.length; i++)
   {
      if (files[i].fullPath.toUpperCase() === path.toUpperCase())
         return i;
   }
   return false;
};
AppFile.deleteFiles = function()
{
   new AppFile().save([]);
};

The Utility Class

The utility.js file is very short and easy to understand. It only has two methods. One is used to convert milliseconds into a formatted string that will be shown in the player, while the other is a JavaScript implementation of the well known Java method endsWith.

Here is the source:

var Utility = {
   formatTime: function(milliseconds) {
      if (milliseconds <= 0)
         return '00:00';
      var seconds = Math.round(milliseconds);
      var minutes = Math.floor(seconds / 60);
      if (minutes < 10)
         minutes = '0' + minutes;
      seconds = seconds % 60;
      if (seconds < 10)
         seconds = '0' + seconds;
      return minutes + ':' + seconds;
   },
   endsWith: function(string, suffix) {
      return string.indexOf(suffix, string.length - suffix.length) !== -1;
   }
};

Putting it All Together

This section discusses the last JavaScript file of the project, application.js, which contains the Application class. Its aim is to attach events to the app page’s elements. Those events will take advantage of the classes we’ve seen thus far and enable the player to work properly.

The code of the illustrated function is listed below:

var Application = {
   initApplication: function() {
      $(document).on(
         'pageinit',
         '#files-list-page',
         function()
         {
            Application.initFilesListPage();
         }
      );
      $(document).on(
         'pageinit',
         '#aurelio-page',
         function()
         {
            Application.openLinksInApp();
         }
      );
      $(document).on(
         'pagechange',
         function(event, properties)
         {
            if (properties.absUrl === $.mobile.path.makeUrlAbsolute('player.html'))
            {
               Application.initPlayerPage(
                  JSON.parse(properties.options.data.file)
               );
            }
         }
      );
   },
   initFilesListPage: function() {
      $('#update-button').click(
         function()
         {
            $('#waiting-popup').popup('open');
            setTimeout(function(){
               Application.updateMediaList();
            }, 150);
         }
      );
      $(document).on('endupdate', function(){
         Application.createFilesList('files-list', AppFile.getAppFiles());
         $('#waiting-popup').popup('close');
      });
      Application.createFilesList('files-list', AppFile.getAppFiles());
   },
   initPlayerPage: function(file) {
      Player.stop();
      $('#media-name').text(file.name);
      $('#media-path').text(file.fullPath);
      $('#player-play').click(function() {
         Player.playPause(file.fullPath);
      });
      $('#player-stop').click(Player.stop);
      $('#time-slider').on('slidestop', function(event) {
         Player.seekPosition(event.target.value);
      });
   },
   updateIcons: function()
   {
      if ($(window).width() > 480)
      {
         $('a[data-icon], button[data-icon]').each(function() {
            $(this).removeAttr('data-iconpos');
         });
      }
      else
      {
         $('a[data-icon], button[data-icon]').each(function() {
            $(this).attr('data-iconpos', 'notext');
         });
      }
   },
   openLinksInApp: function()
   {
      $("a[target=\"_blank\"]").on('click', function(event) {
         event.preventDefault();
         window.open($(this).attr('href'), '_target');
      });
   },
   updateMediaList: function() {
      window.requestFileSystem(
         LocalFileSystem.PERSISTENT,
         0,
         function(fileSystem){
            var root = fileSystem.root;
            AppFile.deleteFiles();
            Application.collectMedia(root.fullPath, true);
         },
         function(error){
            console.log('File System Error: ' + error.code);
         }
      );
   },
   collectMedia: function(path, recursive, level) {
      if (level === undefined)
         level = 0;
      var directoryEntry = new DirectoryEntry('', path);
      if(!directoryEntry.isDirectory) {
         console.log('The provided path is not a directory');
         return;
      }
      var directoryReader = directoryEntry.createReader();
      directoryReader.readEntries(
         function (entries) {
            var appFile;
            var extension;
            for (var i = 0; i < entries.length; i++) {
               if (entries[i].name === '.')
                  continue;
               extension = entries[i].name.substr(entries[i].name.lastIndexOf('.'));
               if (entries[i].isDirectory === true && recursive === true)
                  Application.collectMedia(entries[i].fullPath, recursive, level + 1);
               else if (entries[i].isFile === true && $.inArray(extension, AppFile.EXTENSIONS) >= 0)
               {
                  appFile = new AppFile(entries[i].name, entries[i].fullPath);
                  appFile.addFile();
                  console.log('File saved: ' + entries[i].fullPath);
               }
            }
         },
         function(error) {
            console.log('Unable to read the directory. Errore: ' + error.code);
         }
      );
      if (level === 0)
         $(document).trigger('endupdate');
      console.log('Current path analized is: ' + path);
   },
   createFilesList: function(idElement, files)
   {
      $('#' + idElement).empty();
      if (files == null || files.length == 0)
      {
         $('#' + idElement).append('<p>No files to show. Would you consider a files update (top right button)?</p>');
         return;
      }
      function getPlayHandler(file) {
         return function playHandler() {
            $.mobile.changePage(
               'player.html',
               {
                  data: {
                     file: JSON.stringify(file)
                  }
               }
            );
         };
      }
      function getDeleteHandler(file) {
         return function deleteHandler() {
            var oldLenght = AppFile.getAppFiles().length;
            var $parentUl = $(this).closest('ul');
            file = new AppFile('', file.fullPath);
            file.deleteFile();
            if (oldLenght === AppFile.getAppFiles().length + 1)
            {
               $(this).closest('li').remove();
               $parentUl.listview('refresh');
            }
            else
            {
               console.log('Media not deleted. Something gone wrong.');
               navigator.notification.alert(
                  'Media not deleted. Something gone wrong so please try again.',
                  function(){},
                  'Error'
               );
            }
         };
      }
      var $listElement, $linkElement;
      files.sort(AppFile.compareIgnoreCase);
      for(var i = 0; i < files.length; i++)
      {
         $listElement = $('<li>');
         $linkElement = $('<a>');
         $linkElement
         .attr('href', '#')
         .text(files[i].name)
         .click(getPlayHandler(files[i]));
         // Append the link to the <li> element
         $listElement.append($linkElement);
         $linkElement = $('<a>');
         $linkElement
         .attr('href', '#')
         .text('Delete')
         .click(getDeleteHandler(files[i]));
         // Append the link to the <li> element
         $listElement.append($linkElement);
         // Append the <li> element to the <ul> element
         $('#' + idElement).append($listElement);
      }
      $('#' + idElement).listview('refresh');
   }
};

Managing External Links

In the previous part of this series, I mentioned that an interesting point of the credits page was the attribute target="_blank" applied to the links. This section will explain why the openLinksInApp() method of the Application class makes sense.

Once upon a time, Cordova used to open external links in the same Cordova WebView that was running the application. When a link was open and the user clicked the “back” button, the last displayed page was shown exactly as it was before the user left it. In the newer version, this has changed. Nowadays, the external links are opened, by default, using the Cordova WebView if the URL is in your app’s whitelist. URLs that aren’t on your whitelist are opened using the InAppBrowser API. If you don’t manage the links in the right way, or if the user taps a link that is shown in the InAppBrowser or the system and then chooses to go back, all the jQuery Mobile enhancements are lost. This behavior happens because the CSS and JavaScript files are loaded by the main page, and the following ones are loaded using AJAX. Before uncovering the solution, let’s take a look at what’s the InAppBrowser.

The InAppBrowser is a web-browser that is shown in your app when you use the window.open call.

This API has three methods:

addEventListener(): Allows you to listen for three events (loadstart, loadstop, and exit) and attach a function that runs as soon as those events are fired
removeEventListener(): Removes a previously-attached listener.
close(): Used to close the InAppBrowser window.

So, what’s the solution? The aim of the openLinksInApp() function, coupled with the whitelist specified in the configuration file, is to catch the clicks on all the external links recognized by using the target="_blank" attribute, and open them using the window.open() method. With this technique, we’ll avoid the problem described, and our player will continue to look and work as expected.

Next Part

In the third and last installment of this series, we’ll see the last remaining files so that you can complete the project and play around with it.

Mobiletuts+

Reading NFC Tags with Android

What is NFC?

NFC Technologies

Adding NFC Support in an App

How to Filter for NFC Tags

NFC Intent Filter

Tech Discovered Intent

NDEF Discovered Intent

Foreground Dispatch

Reading Data From an NDEF Tag

Useful Apps

Conclusion

About the Author

Sources

Connecting to an External Database With NuSOAP

1. Install the Software

2. Creating an External Database

Step 1

Step 2

Step 3

3. NuSOAP Server – Starting Web Service

Step 1

Step 2

Step 3

4. Writing Web Service Functions

Step 1

Step 2

Step 3

5. Creating a Simple Layout for a Windows Phone Application

Step 1

Step 2

6. Connecting to Service

7. Writing Windows Phone Functions

Step 1

Step 2

8. Testing

Conclusion

Create a Weather App with Forecast – Project Setup

Introduction

1. Project Setup

Step 1: Creating the Project

Step 2: Adding Libraries

Step 3: Adding Dependencies

Step 4: Edit the Precompiled Header File

2. Laying the Foundation

Step 1: View Controllers

Step 2: Creating a View Deck Controller

3. Adding Locations

Step 1: Declaring the Delegate Protocol

Step 2: Adding the Table View

Step 3: Populating the Table View

Step 4: Keys and Constants

Step 5: Delegate Assignment

Step 6: Fetching the Current Location

Step 7: Adding a Label

Step 8: Implementing the Delegate Protocol

4. Final Touches

Conclusion

iOS SDK: Customizing Popovers

1. Setting Up Your Project

Step 1

Step 2

2. Adding a Navigation Controller

Step 1

Step 2

3. Showing the Popover

Step 1

Step 2

Step 3

4. Testing the Standard Popover

5. Subclassing UIPopoverBackgroundView

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

6. Setting the Popover Background View Class Property

7. Testing the Popover Background View

5. Subclassing `UIPopoverBackgroundView`