Supplying an Application Launcher Icon

Supplying an Application Launcher Icon

One thing that we didn’t cover in Chapter 9 was customizing parts of the PhoneGap application beyond just the name references. If we are going to deploy an application to the Android marketplace, it’s probably a good idea to provide a custom icon for our application rather than simply use the PhoneGap default icon.

With regard to application icons, Google provide some excellent documentation that covers some of the dos and don’ts around icons in your application. This is definitely worth a read and can be found at the following URL: http://developer.android.com/guide/practices/ui_guidelines/icon_design.html.

Additionally, if you have Photoshop ( http://adobe.com/photoshop) available, then Google also provide a useful template for building application icons, which can be found with the icon design guidelines that we referenced in the previous paragraph.

Now, we aren’t going to go through the process of creating an application icon here, as this is more of a design-related task than a programming one, but you can use a variety of different tools to create the icon as long as a file named icon.png is generated at the end of the process. Additionally, as per the icon design guidelines provided by Google 3, different resolutions of the launcher icon should be supplied:

CHAPTER 12: Polishing and Packaging an App for Release

Once you have your relevant icon files, these are simply copied to the relevant res/drawable-?dpi folder (where ?dpi would be hdpi, mdpi, or ldpi, depending on the icon size). Figure 12–13 shows where each of the files have been placed in our working copy of the sample, and, while it’s not visible in the screenshot, the 72-pixel image is in the drawable-hdpi folder, the 48-pixel image is in the drawable-mdpi folder, and the 36- pixel image is in the drawable-ldpi folder.

Figure 12–13. Our updated icon.png file is placed in the res area of the project. With the icon in place, we are ready to rebuild and reinstall the application to the

emulator. If everything has gone to plan, you should see an updated launcher icon, as shown in Figure 12–14.

CHAPTER 12: Polishing and Packaging an App for Release

Figure 12–14. Our updated launcher icon now displays in the Android application launcher. With our application now looking the part, there is one more thing we have to do before

it’s ready to package up and ship to the Android marketplace.

Tweaking Application Permissions

If you have ever installed a native Android application, you are probably familiar with the

Download from Wow! eBook <www.wowebook.com>

screen that tells you what permissions the application is asking for before you complete the installation procedure. Figure 12–15 shows a screenshot of the permissions installation screen for the native Gowalla application, which gives you an idea of the kind of thing that applications request on installation.

CHAPTER 12: Polishing and Packaging an App for Release

Figure 12–15. The Gowalla installation screen provides an example of the permissions that an application may request.

Now, we really don’t want to have an application that requests permissions for operations that it does not use. This is because users may have an objection to granting certain permissions, and in this case the more permissions our application requests, the more chance it has of being rejected by a user during installation. As such, it is best to keep the required permissions to a minimum.

As part of the default sample PhoneGap project, we have an AndroidManifest.xml file that requests a large number of permissions, and most of these aren’t required for Moundz. For example, the following is an excerpt from the AndroidManifest.xml file showing the permission requests.

<uses-permission android:name="android.permission.CAMERA" /> <uses-permission android:name="android.permission.VIBRATE" /> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS" /> <uses-permission android:name="android.permission.READ_PHONE_STATE" /> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.RECEIVE_SMS" /> <uses-permission android:name="android.permission.RECORD_AUDIO" /> <uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" /> <uses-permission android:name="android.permission.READ_CONTACTS" /> <uses-permission android:name="android.permission.WRITE_CONTACTS" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

CHAPTER 12: Polishing and Packaging an App for Release

While we won’t go into the specifics of every permission here, details on what particular permissions provide can be found on the following page in the Android developer docs: http://developer.android.com/reference/android/Manifest.permission.html.

For the purposes of Moundz, it is pretty safe to remove the majority of these permissions and just reduce it to the permissions that provide our application web access and allow us to access location information. The reduced set of permissions would be something more like this:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS" /> <uses-permission android:name="android.permission.INTERNET" />

Depending on the type of application you are building, additional permissions may or may not be required, which is probably why they are included in the default AndroidManifest.xml file.