Mobile Application Development (AD-703 (B)) - Unit 4 Short Notes

How unit 4 is examined

This unit covers testing an app, publishing it, storing settings with preferences, and organising resources; no topic was asked in recent papers, so each is short but complete.

Testing Android applications

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Testing an Android application means running it on emulators and real devices, with unit and UI test tools, to find bugs and confirm it works before release.</mark>

Key points.

1. Unit tests use JUnit, run on the local JVM and check plain logic such as calculations, without needing a device.
2. Instrumented tests run on an emulator or device and check code that needs the Android framework.
3. Espresso is the UI testing framework that simulates taps and typing and then checks what appears on screen.
4. The Monkey tool sends random events to the app to find crashes, and Logcat with the debugger is used to trace errors.

Publishing Android application

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Publishing is preparing a signed release build of the app and distributing it to users, usually through the Google Play Store.</mark>

Key points.

1. First test the app, remove debug code and set the version code and version name in the manifest.
2. The release APK or App Bundle must be digitally signed with a private key stored in a keystore, and the same key is needed for every update.
3. A Google Play developer account is created with a one-time registration fee, and the app is uploaded through the Play Console.
4. The listing needs a title, description, screenshots, icon and content rating before the app goes live; other channels are third-party stores or direct APK download.

Using Android preferences

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Preferences store small amounts of private data as key-value pairs, using the SharedPreferences class, so that settings survive after the app closes.</mark>

Key points.

1. A SharedPreferences object is obtained with getSharedPreferences(name, MODE_PRIVATE), so only the app can read the file.
2. Values are written through SharedPreferences.Editor, using putString(), putInt() or putBoolean(), and then saved with apply() or commit().
3. Values are read with getString(key, default), where the default is returned if the key is missing.
4. A settings screen can be built from an XML file in res/xml using PreferenceFragment, which saves the user's choices automatically.

Managing Application resources in a hierarchy

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Application resources are the non-code files such as layouts, images and strings that are kept in the res/ folder, in subfolders named by type and configuration.</mark>

Key points.

1. Each resource type has its own subfolder in res/, such as layout, drawable, values, menu and raw.
2. A qualifier added to the folder name, such as layout-land, drawable-hdpi or values-hi, holds the alternative resource for that screen orientation, density or language.
3. At run time Android picks the folder whose qualifiers best match the device, and falls back to the default folder without a qualifier.
4. Every resource gets an integer ID in the generated R class, used in code as R.string.app_name and in XML as @string/app_name.

Working with different types of resources

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Android resources are typed files: strings, colors, dimensions, styles, drawables, layouts and more, each defined once and referenced by name.</mark>

Key points.

1. Simple values such as strings, colors, dimensions and styles are written in XML files inside res/values, for example <string name="hello">Hello</string>.
2. Drawables are images or XML shapes in res/drawable, and layouts are XML files in res/layout.
3. Keeping text in strings.xml supports localization, since a folder such as values-hi supplies the Hindi text automatically.
4. Resources are accessed in code with getResources().getString(R.string.hello) and in XML with @string/hello or @color/red.

Last-minute revision

• Unit tests use JUnit on the local JVM; Espresso tests the UI on a device or emulator.
• Monkey sends random events; Logcat shows log messages and errors.
• A release build must be signed with a keystore private key.
• The manifest holds versionCode (integer, must rise per update) and versionName (shown to the user).
• Apps are uploaded to Google Play through the Play Console after a one-time registration fee.
• SharedPreferences store key-value pairs in a private XML file.
• Write with an Editor and save with apply() (asynchronous) or commit() (synchronous).
• Resources live in res/; qualifiers like -land, -hdpi, -hi select alternatives.
• The R class holds resource IDs; @string/name is the XML reference.
• Strings, colors and dimensions go in res/values.

Memory hooks

• Test, Sign, Upload: the three steps of release.
• Editor edits, apply applies: no change is saved without apply() or commit().
• R is the Registry of IDs.
• Folder plus dash plus qualifier: values-hi means Hindi values.

Coverage checklist

• Testing Android applications: no past questions; definition and four tools covered.
• Publishing Android application: no past questions; signing, versioning and Play Console covered.
• Using Android preferences: no past questions; SharedPreferences read and write covered.
• Managing Application resources in a hierarchy: no past questions; res folders and qualifiers covered.
• Working with different types of resources: no past questions; resource types and access covered.