SPEAKER NOTES: Welcome to Week 3! Today we're diving into three critical aspects of Android development that students often overlook but are essential for professional apps. Opening hook: "How many of you have used an app that was only in English and wished it was in your native language? Or seen an app with inconsistent colors and spacing? Today we'll learn how to avoid these problems." Let students know this is foundational material they'll use in every Android app they build.
SPEAKER NOTES: We'll start with the foundation: how Android organizes resources and why this matters.
SPEAKER NOTES: Once we understand resources, we'll see how they enable automatic language support across the globe.
SPEAKER NOTES: Finally, we'll tie everything together with the manifest file that tells Android about your app. Emphasize that Part 1 (Resources) is the foundation for Part 2 (Localization), and the Manifest ties everything together.
SPEAKER NOTES: You'll learn to create properly structured resource files that professional developers use.
SPEAKER NOTES: You'll add support for Spanish, French, or any language to an app - without changing your code!
SPEAKER NOTES: You'll understand the manifest file that tells Android about your app's permissions and components.
SPEAKER NOTES: You'll understand WHY we separate resources from code and how it makes your life easier. These skills are immediately applicable to Assignment 1 and their projects.
SPEAKER NOTES: Start with the big picture: Resources are the WHAT, code is the HOW. Key point: In professional development, you NEVER hardcode strings or colors directly in your code.
SPEAKER NOTES: These are visual assets that users see.
SPEAKER NOTES: These are the building blocks of your app's visual design.
SPEAKER NOTES: Analogy: "Think of resources like a style guide or brand book - all your design decisions live in one place, and your code just references them." Emphasize that even though we use Compose (not XML layouts), we still use XML for strings, colors, and dimensions.
SPEAKER NOTES: Marketing wants to change 'Submit' to 'Send' across the entire app? With resources, you change ONE line in strings.xml, not 47 hardcoded strings.
SPEAKER NOTES: Your app gets popular in Spain? You add one folder (values-es) and you're done. No code changes needed.
SPEAKER NOTES: User has large font settings? Android automatically uses your sp units to scale text appropriately.
SPEAKER NOTES: Company rebrand? Update colors.xml once instead of hunting through 200 files. This is the "why" - critical for student buy-in.
SPEAKER NOTES: Switch to Android Studio and show this structure in a real project. Key points: - values/ is the DEFAULT - always provide this - The -suffix (like -es, -night) tells Android WHEN to use these resources - drawable vs mipmap: drawable is for images IN your app, mipmap is for your app ICON (different densities) Note: Android Studio creates most of this automatically when you create a new project. Common mistake: Students forget that values-es only needs strings.xml, not colors.xml (unless colors change by language, which is rare).
SPEAKER NOTES: Open strings.xml in Android Studio - show real examples. Key teaching points: - name attribute: descriptive, not the actual text ("submit_button" not "submit") - %s is a placeholder for a String, %d for an integer - Android Studio will warn you if you hardcode strings in code Best practice: Create the resource FIRST, then use it in code. Don't write "Submit" in code and "fix it later." Question to ask: "What happens if you delete a string resource that's being used?" (Compile error - that's GOOD! Better than runtime crash)
SPEAKER NOTES: Colors are critical for consistency and theming. Key point: Use SEMANTIC names ("primary", "error") not DESCRIPTIVE names ("purple", "red"). Why? Because if you rebrand and primary becomes blue, you don't want to find/replace "purple" everywhere. Hex format: #RRGGBB or #AARRGGBB (alpha for transparency) Material Design colors: Google provides recommended color palettes at material.io Dark theme: You'll typically have colors.xml in values/ and values-night/ with different values for light/dark modes.
SPEAKER NOTES: Dimensions are often overlooked but create visual consistency. dp = density-independent pixels. A 16dp button is the same physical size on a phone and tablet. sp = scale-independent pixels. Respects user's font size preferences (accessibility!). Common pattern: Use multiples of 4 or 8 (8dp, 16dp, 24dp, 32dp) for Material Design consistency. Why resources? So you can change spacing across your entire app in one place. "Make all padding bigger" = change 3 lines, not 150. Note: In Compose, you often use .dp extension directly (16.dp), but resources still useful for complex/reusable values.
SPEAKER NOTES: Now we connect XML resources to Compose code - this is where the magic happens. Live demo opportunity: Open a Compose file and show these in action. Key points: - stringResource() takes the resource ID and optional parameters for %s, %d placeholders - These functions are @Composable, so they can only be called from other @Composable functions - The functions automatically pick the right resource based on device language, theme, etc. Common student mistake: Trying to use stringResource() in a regular (non-Composable) function. Solution: Pass the string as a parameter or use Context.getString() in viewModel. Note: R.string.greeting with "Alice" will replace %s with "Alice".
SPEAKER NOTES: The R class is Android's way of giving you compile-time safety. Important: R is generated from your XML files. Add a string? R updates. Delete a string? R updates and any code using it will show a compile error. WARNING: Sometimes Android Studio's R class gets "out of sync". Solution: Build > Clean Project, then Build > Rebuild Project. Type safety: R.string.app_name is an Int (resource ID), not a String. You need stringResource() to get the actual text. Fun fact: R stands for "Resources". The class is in your package namespace to avoid conflicts with other libraries. If autocomplete suggests multiple R classes, make sure you're importing YOUR app's R, not android.R.
SPEAKER NOTES: Android Studio has a "Hardcoded text" inspection that will underline violations. Pay attention to these warnings!
SPEAKER NOTES: Semantic vs descriptive naming: - Bad: "blue", "light_gray", "dark_red" (describes implementation) - Good: "primary", "background", "error" (describes purpose) - Why? When you rebrand, "primary" can change from blue to green without renaming everything.
SPEAKER NOTES: Organization tips: - Comment sections in your XML: <!-- Navigation strings
SPEAKER NOTES: Transition: "Now that we understand resources, let's see how they enable one of Android's most powerful features: automatic localization." Key distinction: - Internationalization (i18n): Making your app CAPABLE of supporting multiple languages (what we're doing with resources) - Localization (l10n): Actually translating content to specific languages This is where the resource system really shines - we already set up the infrastructure in Part 1.
SPEAKER NOTES: Start with impact: "Localization can double or triple your user base." Real example: WhatsApp supports 60+ languages. Instagram supports 32+. These aren't accidents - localization drives growth. Better UX: Imagine using an app entirely in a language you don't speak fluently. Frustrating! Professional: Companies expect mobile apps to be localized. It's a table-stakes feature.
SPEAKER NOTES: Hard facts to drive the point home: 20% English speakers: That means 80% of potential users prefer another language! Higher ratings: Users rate apps higher when they're in their native language (1-1.5 star difference on average). Required markets: China, Japan, parts of Europe have regulations or strong cultural preferences for localized apps. Good news: Android makes this EASY with the resource system we just learned.
SPEAKER NOTES: This is Android's "secret sauce" - automatic resource selection based on device configuration. How it works: At runtime, Android checks the device's language, screen size, orientation, etc., and automatically loads the best-matching resources. Language codes: ISO 639-1 (es=Spanish, fr=French, de=German, ja=Japanese, zh=Chinese) Region codes: ISO 3166-1-alpha-2 with 'r' prefix (rMX=Mexico, rES=Spain) Why Spanish (Mexico) vs Spanish (Spain)? Different vocabulary ("computadora" vs "ordenador" for computer). You can combine qualifiers! values-es-land-night = Spanish, landscape, dark mode.
SPEAKER NOTES: Naming rules are strict - order matters! Correct order: language-region-screen-orientation-theme - values-es-land ✅ - values-land-es ❌ (won't work!) Full precedence table is in Android docs, but for this class: language → screen size → orientation → theme. Android picks the MOST SPECIFIC match. Device is Spanish + Landscape? Checks: 1. values-es-land (exact match!) 2. values-es (language match) 3. values (fallback) Always provide values/ as fallback!
SPEAKER NOTES: Live demo time! In Android Studio: 1. Right-click res folder 2. New → Android Resource File 3. File name: strings 4. Resource type: Values 5. Available qualifiers → Locale → es (Spanish) 6. Click OK Android Studio creates values-es/strings.xml automatically! IMPORTANT: Keep the same string names (keys) across all files. Only the VALUES change.
SPEAKER NOTES: Side-by-side comparison - notice: 1. Same name attributes ("app_name", "welcome") 2. Different text content 3. Spanish uses special characters (ó, ¡) - XML handles these fine! Your code stays exactly the same: stringResource(R.string.welcome) Android automatically picks English or Spanish based on device language. No if/else needed! Note: If Spanish user device requests a string that's only in values/, Android falls back to English. This is why values/ must be complete.
SPEAKER NOTES: Placeholders let you inject dynamic data into translated strings. Format specifiers (Java printf style): - %s = String - %d = decimal integer - %f = floating point - %1$s, %2$s = positional (for reordering) IMPORTANT: Word order varies by language! English: "Welcome, Alice" but German might be "Alice, willkommen". Use positional parameters: "Welcome, %1$s" vs "%1$s, willkommen". stringResource() takes varargs after the resource ID - just pass your values in order. Common mistake: Forgetting to pass the parameter! "Welcome, %s!" without a value = crash.
SPEAKER NOTES: Plurals are tricky because different languages have different plural rules! English: 1 item, 2 items (simple) Russian: different forms for 1, 2-4, 5-20, 21, 22-24, etc. (complex!) Japanese: no plural distinction Android handles this automatically with <plurals>. quantity values: - zero (0) - one (1) - two (2, for languages that distinguish it) - few (e.g., 2-4 in Russian) - many (e.g., 5+ in Russian) - other (default/everything else) Not all languages use all quantities. English only needs "one" and "other". Note the two count parameters: First is which quantity to select, second is %d value to insert.
SPEAKER NOTES: Testing is crucial - don't just assume it works! Method 1 (LIVE DEMO): 1. Open emulator Settings 2. System → Languages → Add language → Español 3. Drag Spanish to top 4. Return to your app - should be Spanish! 5. To switch back: Long-press language switcher notification Method 2 (Android 13+): Per-app language settings. User can have system in English but your app in Spanish. Method 3: In Android Studio, Composable preview can show different locales without running app. Add @Preview(locale = "es") to your composable. Test with REAL devices if possible - different regions may expose issues.
SPEAKER NOTES: values/ is your safety net. Missing Spanish string? Falls back to English. Missing default? App crashes!
SPEAKER NOTES: Typos are deadly. values-es has "welcme" instead of "welcome"? Android won't find it, falls back to English.
SPEAKER NOTES: German text can be 30% longer than English. "Ok" → "In Ordnung". Design flexible layouts! Don't use fixed widths.
SPEAKER NOTES: Concatenation breaks word order. "You have" + count + "items" doesn't work in all languages. Use format strings with placeholders.
SPEAKER NOTES: Google Translate is a START, not an end. Professional translators understand context, idioms, cultural nuances. For serious apps, budget for translation. Bonus tip: Use string resource names that make sense in English - translators won't see the code, only the strings. Common pitfalls and how to avoid them:
SPEAKER NOTES: Transition: "We've learned how to organize content (resources) and make it work globally (localization). Now let's talk about how Android knows about your app - the manifest." This is the "boring but essential" section. Every Android app MUST have this file.
SPEAKER NOTES: Open AndroidManifest.xml in Android Studio to show a real example. Package name: Uniquely identifies your app (com.example.myapp). Like a domain name - must be unique on Play Store. Components: Android needs to know what Activities, Services, etc. exist in your app. Permissions: Security model - apps can only do what they declare and user approves. API level: Tells Android what minimum version is required to run your app. Icon/label: What users see in the app drawer. Intent filters: How your app responds to system events ("I can open image files!"). Passport analogy: Just like you can't enter a country without a passport, Android won't run an app without a valid manifest.
SPEAKER NOTES: Walk through each section: package: Your app's unique identifier. Usually com.yourcompany.appname. Can't change this after publishing! uses-permission: Declares what device features/data you need. Goes OUTSIDE <application>. application: Container for all your app's components. icon: Uses @mipmap (not @drawable) for launcher icons - Android provides different densities. label: Notice @string/app_name - localized! activity: Each screen in your app needs to be declared here. android:name=".MainActivity": The dot means it's in your package. Full name: com.example.myapp.MainActivity exported="true": Other apps (like the launcher) can start this activity. intent-filter with MAIN+LAUNCHER: This is the entry point - shows in app drawer and launches when tapped.
SPEAKER NOTES: Two-step process for dangerous permissions: Step 1: Manifest declaration (what we're learning today) - tells Android your app MIGHT need camera. Step 2: Runtime request (Week 5) - show dialog asking user for permission when you actually need it. Best practice: Request permission in context. Don't ask for camera permission on app launch - wait until user taps "Take Photo" button. Then they understand WHY you need it. Handle denial: If user says no, disable the feature gracefully. Don't crash! Show a message: "Camera access required to take photos. You can enable it in Settings." Users can revoke permissions anytime! Check permission status before using camera/location/etc. We'll implement this properly in a few weeks - for now, just know it requires both manifest AND code.
SPEAKER NOTES: Application element wraps all your app components. icon: @mipmap/ic_launcher references mipmap/ folder (not drawable/). Android chooses correct density (mdpi, hdpi, xhdpi, etc.). label: Notice @string/app_name! This makes your app name localizable. Change strings-es.xml and Spanish users see Spanish app name in launcher! theme: References themes.xml - defines your app's colors, typography, shapes. We'll cover theming in detail later. allowBackup: true = Android backs up your app's data to Google Drive. false for apps with sensitive data. supportsRtl: true = your layouts will flip for Arabic/Hebrew (right-to-left languages). Important for localization! Other common attributes: name (custom Application class), debuggable (auto-set by build type).
SPEAKER NOTES: Every Activity must be declared in the manifest. Forget to declare it? Crash when you try to launch it! name=".MainActivity": Shorthand for com.example.myapp.MainActivity (package + class name). exported (REQUIRED as of API 31/Android 12): - true: Other apps can launch this (needed for launcher) - false: Only your app can launch this (most internal activities) Leaving it out = build error on newer Android! label: Can override application label for specific Activity. Useful for detail screens. Intent filter: Declares what this Activity can do. - MAIN + LAUNCHER: This is THE app entry point. Only one Activity should have this! - Other intent filters: Open URLs, handle file types, etc. (advanced topic). Multiple activities? Declare each one in separate <activity> tags.
SPEAKER NOTES: SDK versions are defined in build.gradle, but affect manifest behavior. minSdk = 24 (Android 7.0 Nougat, released 2016): - Can't install on older devices - Can use APIs from Android 7.0+ - Covers ~95% of active devices (as of 2024) - Lower = more devices, but older APIs targetSdk = 34 (Android 14): - Tells Android you've TESTED on Android 14 - Android applies latest behavioral changes - Must update yearly for Play Store Trade-off: Lower minSdk = more users, but limited API features. Higher minSdk = fewer users, but modern APIs. For this class: minSdk 24 is a good balance. For real apps: check your analytics to see what devices your users have.
SPEAKER NOTES: Other useful attributes you might see: allowBackup: Automatic backup to Google Drive. Good for most apps. networkSecurityConfig: Security settings for HTTPS. Advanced topic - allows custom certificates, cleartext traffic (for development). supportsRtl: Already mentioned - crucial for Arabic/Hebrew. hardwareAccelerated: GPU rendering (default true). Rarely need to change. Others not shown: - largeHeap: Request more memory (for image/video apps) - usesCleartextTraffic: Allow HTTP (not just HTTPS) - only for development! - name: Custom Application class Most apps only need the basics: icon, label, theme.
SPEAKER NOTES: Every permission you request makes users MORE suspicious. Only ask for what you truly need. Don't copy-paste from StackOverflow without understanding!
SPEAKER NOTES: Hardcoded strings in manifest = not localizable. Use @string references for labels, always.
SPEAKER NOTES: exported is now REQUIRED for activities with intent-filters (Android 12+). Set it explicitly to avoid confusion.
SPEAKER NOTES: Don't clutter the manifest with things that can be in code. It's for system-level configuration only. Common mistakes: - Forgetting to declare new Activities (crash!) - Requesting unnecessary permissions (bad UX) - Not updating targetSdk (Play Store rejects) The manifest is auto-generated by Android Studio with good defaults. Only change what you understand!
SPEAKER NOTES: Recap the big picture before diving into details. "We covered three essential pillars of Android development today. These aren't flashy features, but they're the foundation of EVERY professional Android app."
SPEAKER NOTES: Resources: "If you only remember one thing: NEVER hardcode strings, colors, or dimensions. Always use resources." Localization: "Android makes supporting multiple languages trivially easy - just create values-XX folders. There's no excuse for English-only apps!" These two topics are interconnected - resources enable easy localization.
SPEAKER NOTES: Manifest: "This is the 'business card' of your app. Android won't even launch your app without a valid manifest." Permissions: "Remember the two-step process for dangerous permissions: declare in manifest, request at runtime. We'll implement the runtime part in a few weeks." Most of the time, Android Studio generates the manifest correctly. But you need to UNDERSTAND it to debug issues and add features.
SPEAKER NOTES: Wednesday will be hands-on practice applying today's concepts. "We'll build a real app together that supports English and Spanish, uses proper resource organization, and has a correctly configured manifest." "Come prepared with questions! This is foundational material you'll use in EVERY assignment and project." Homework: zyBook reading covers these topics in more detail with interactive exercises.
SPEAKER NOTES: Common questions to anticipate: Q: "Do we really need to use resources for EVERYTHING?" A: "Yes. It seems tedious at first, but it saves massive time later. Professional Android devs ALWAYS use resources." Q: "What if I want to support 10 languages?" A: "Same process, just create values-es, values-fr, values-de, etc. The code stays identical!" Q: "Can I change the package name after publishing?" A: "No! Choose carefully. It's your app's permanent identity on the Play Store." Q: "Why is Android Studio generating R errors?" A: "Clean and rebuild. R is auto-generated, so build issues can corrupt it." If no questions: "Great! See you Wednesday for hands-on practice. Remember - resources, localization, and manifest are the foundation of professional Android development."