Welcome to the Depth Dive, where we take a stack of information and really extract the most important nuggets of knowledge and insight tailored just for you. Today, we're doing something a little different. It's like a fascinating TimewARP. We're diving into the Android Application Development Cookbook, second edition, which, believe it or not, was published way back in March
twenty sixteen. Our mission here is basically to give you a shortcut, a shortcut to understanding what Android app development looked like, you know, nearly a decade ago. We'll uncover the core ideas, some practical recipes for problems developers face then, and maybe some surprising things that we're cutting edge and see how much or maybe how little things have really changed. Our main source is that cookbook by Rick Boyer and Kyle mu It's very much designed for developers who learn
by doing a by jumping into code. It's literally broken down into these recipes with sections like getting ready, how to do it, how it works. So let's imagine you're an Android dep back in twenty sixteen, staring at a blank screen. What were the absolute first things you'd write? What were those fundamental building block?
Yeah, it's really interesting looking back, what's fascinating is how clearly the book lays out these core components that honestly are still pretty foundational today, even of how we implement them has evolved quite a bit. The absolute bedrock for almost any Android app then, and you could argue still now,
were activity activities. Right, Think of an activity as like a single screen in your app, or a distinct user interface view every single screen, your main menu settings, a photo viewer that would typically be its own activity, and these were all declared in that central file, the Android Manifest dot XML.
Ah, the manifest okay exactly.
And crucially specific things called intent filters in there, like main and launcher. They told the system which activity was the main entry point, you know, the one that gets the icon on your phone's home screen.
Okay, So activities are like the individual rooms in a house, and the Manifest is the blueprint saying this room is the front door. Got it? But how did these rooms talk to each other inside the same app, or even like talking to other apps on the phone.
That's where the incredibly powerful intent object came in. It's essentially a message object. Think of it as a way to say I want to do something, Yeah, but without needing to know exactly who we'll do it. So, for example, you could use intents dot action view. You tell the system, hey, I want to view this capacity URL maybe huh, and Android would figure out okay, the default web browser should handle this and launch it for you.
Right, So the app doesn't need to know which browser the user has installed exactly.
And what was really clever and still is is that different types of data could launch completely different apps. A location might open a map app, a contact file might open the contact app. It showed how flexible the system was letting apps work together without hard coding dependencies.
That's huge, that interoperability. Okay, so that's talking between apps. What about just moving between screens inside your own appic from a list to a detail screen.
Intents handle that too. You just create an intent specifying the target activity, say moving from your main activity to a second activity. As simple as that, And if you needed to send some information along, you'd use put extra. It worked with name value pairs, like packing little bits of data into the intent.
Like sticking a post it note on the message.
Pretty much yeah, exactly like a post it and the receiving activity would just grab that data using methods like get string extra looking for the name you give it.
Okay, And what if you needed to get something back from that second screen. Let's say you launched a contact picker and you need the phone number the user picked.
Ah, right, for that, you wouldn't just start the activity. You'd use start activity for results the result makes sense, and the result would come back to the original activity in a special callback method on activity results. And for apps doing lots of this, maybe calling different activities for results, there was something called a request code. There's a number you defined when you started the activity, so that when on activity result was called, you could check that code
and know which request was returing its result. Kept things organized, right, because the mobile world is just so dynamic, isn't it. You're in an app, a phone call comes in, you switch to another app, The system might even kill your app in the background, off the needs memory. It feels like a constant battle with the OS. So what did this all mean for a developer trying to make an app feel smooth and seamless even with all those interruptions.
That's the million dollar question really, and connecting this to the bigger picture, understanding the activity life cycle was just absolutely critical paramount for app stability user experience, especially back then on devices that maybe didn't have tons of memory. Think about this, just rotating your phone. Yeah, by default, Android would completely destroy your current activity and then recreate it from a scratch.
Wait, destroy it just for rotating?
Yeah, destroy and recreate, which, as you can imagine, could lead to a really terrible user experience if you weren't ready for it. All the user's input gone, the scroll position lost.
Wow. Okay, so how did developers handle that? That's where these life cycle callback methods were vital, Things like on
save instance state and on restore instance. On save instance date gave you a chance right before the activity was potentially destroyed to save small bits of data like user input or UI state okay, And then if the activity was recreated on restore instance state or on create what would be called and you could get that save data back and restore the state so the user could just pick up where they left off.
So you had to manually save and restore anything important every time a configuration might change, like rotation.
Pretty much.
Yes.
The book details the core life cycle states active, pause, stopped, destroyed, and the methods tied to them. On create on resume, on pause, on stop, on destroy. The US was described as ruthless with resource management. If your app went into the pause or stop state, it was fair game for the OS to kill it to reclaim memory.
That sounds like a lot of manual work and potential for bugs.
It absolutely was a major source of frustration. Bilbote's got to be really careful about calling the superclass methods, understanding when each callback fired what they could safely do in each one. It's honestly one of the main reasons modern Android development shifted towards things like view model from the architecture components.
Right to abstract away some of that life cycle complexity exactly.
View models survive configuration changes like rotation, automatically holding UI related data without you needing to manually save and restore it in the activity nearly as much. It simplified things massively.
Okay, so we've got the basic structure with activities and intents and a sense of the constant dance with the OS life cycle. But an app is nothing without its interface. This is where it gets really interesting, right, optimizing what the user actually sees and interacts with. It's not just what you put on screen, but how you put.
It there absolutely, and that raises the question, how do you build a complex, good looking UI that still performs well, especially considering the huge variety of Android devices out there. Even back then, the techniques in the cookbook, even from twenty sixteen, really emphasize that performance starts with design, and the foundation of UI design was layouts and view.
Groups w groups. That's like a container precisely.
A view group is the base class for containers, and layout classes, which inherit from view group, are what you use to actually organize the UI elements, the buttons, the text fields, the images. They define the structure.
What were the main layout types developers were using back then?
The book covers several key ones. Relative layout was really powerful. It let you position views relative to each other or relative to the parent container. You could say, this button goes to the right of that text view or center this image. Very flexible for complex screens. Okay, yeah, Linear layout much simpler. It just arranged views one after another, either vertically in a column or horizontally in a row.
Simple but probably useful, very and.
Its key feature was layout weight. This allowed views within the linear layout to take up proportional space. Like one element takes seventy percent of the width, the other takes thirty percent. Super useful for dividing space.
Dynamically right and for grids like a calculator or a photo gallery.
For grid like structures, there was table layout and grid layout. They approached it slightly differently how they defined rows and columns, but both serve that purpose. And of course you could nest these layouts, put a linear layout inside a relative layout inside another linear layout. That's how you built up really complex UI hierarchies.
But nesting sounds like it could get complicated fast and maybe slow things down. Were there tools to help optimize these layouts?
You bet? Performance was definitely a concern. The cookbook highlights a couple of essential tools from that era. First, the hierarchy Viewer hierarchy veer. Yeah, there's a tool that let you visually inspect your layout structure as a tree. You could see how deeply nested things were, identify redundant layouts. Super useful for fine bottlenecks. The catch was, back then it usually required a rooted device or an emulator to use it.
Ah, okay, bit of a hurdle.
A bit, yeah, But then there was lint. Lint was and still is part of the Android SDK integrated into Android Studio. Think of it as like a static code analyzer, but specifically for androids.
So it would warn you about problems exactly.
It would flag potential layout issues automatically, things like deep layouts, warning you if your view hierarchy was nested too many levels deep which killed performance, or nested weights in linear layouts, another notorious performance trap. It also flagged things like useless parent layouts or useless leaf views that weren't contributing anything really helpful for keeping UIs lean.
And what if you had a part of the UI that was complex but maybe wasn't used very often, like a detailed error message panel. Was there a way to avoid loading that all the time?
Yes, that's where view stub came in. It was described as a lazy load mechanism. Basically, it was a placeholder in your layout. This very lightweight took up almost no memory or inflation time initially only when you explicitly told the view stub to inflate, usually in your code, when that specific UI was actually needed. Would it load the real more complex layout it was referencing great for reducing initial screen load time and memory usage for rarely seeing UI components clever.
Okay, so that's the structure. What about the actual things the user sees and taps on? The widgets?
Right, the views and widgets. The book mentions all the common built in ones you'd expect text view for text, button, checkbox, even things like clock, date, picker, calendar, A whole toolbox of standard UI elements.
But could you make your own if the standard ones weren't enough.
Absolutely, customization was key. You could extend an existing widget to add functionality, or you could create a totally custom view from scratch by extending the base view class. Doing that often meant you had to get your hands dirty overwriting methods like on measure to tell Android how big your custom view should be, and on draw to actually draw its appearance on the screen. Using the canvas.
API sounds like more work, but powerful.
Definitely more work, but it gave you complete control. Another common technique mentioned was creating compound controls. This just meant grouping several existing controls together into a single reusable component, like creating a custom search bar widget made up of a text view and a button.
Okay, so you build a layout, put the widgets in, but then you need consistent styling, right colors, font sizes. How is that handled?
That's where styles and themes came in. They were crucial for maintainability and achieving a consistent look and feel. Styles were defined in an XML file, usually styles dot XML. A style was basically a collection of attributes like android dot layout with android dot background, android dot text color, android dot text size. You could define a style once like a CSS class, exactly like a CSS class to define it once, then apply that style to multiple views button, textview, etc.
In your layouts. So if you needed to change the standard button color across your app, you just changed it in the style definition, not on every single button.
Much cleaner in themes, How are they different?
Themes were broader. They applied to an entire activity or even the whole application, rather than individual views. Themes affected things like the default appearance of standard widgets or window attributes like the status bar color, or whether the activity had a title bar or an action bar. You could even use a theme to make an activity look like a floating dialogue box, for instance.
And dealing with different Android versions was a big thing back then, right with Holo themes the material design coming in. How did themes handle that?
Yeah, that was a major challenge, the fragmentation. The book explains how developers used resource qualifiers. You could define different theme versions and folders like values v eleven for Android three point zero Honeycomb which introduced the Holo theme, or values v twenty one for Android five point Oho Lollipop with material design.
Ah, so the system would automatically pick the right one based on the device's Android version.
Correct, the system handles selecting the most appropriate resources. But even more importantly, the app compat library was absolutely essential. It was a support library from Google that backpoorded newer UI elements and theme features like the action bar and material design components to older Android.
Versions, so you could use newer features without dropping support for older phones exactly.
App Compat was a lifeline for developers trying to provide a reasonably consistent and modern looking UI across that fragmented landscape. It smoothed over a lot of the version differences.
Okay, so building on that, the app looks good, it's structured, well, now it needs to actually respond to the user in smart ways, provide feedback guide them. What were the standard ways to handle interaction like menus and alerts.
Right. This is where the user experience really starts to take shape, making the app feel interactive and intuitive. The cookbook dies into several key areas here, starting with menu systems. Menus were and still are a fundamental way to provide options and actions to the user.
What were the main kinds of menus available back in twenty sixteen, Well, the main.
One was the options menu. That's the standard menu, typically appearing in the action bar at the top of the screen. If there wasn't enough space, items would go into that familiar three dot overflow menu.
Okay, the standard stuff.
Yeah. Developers used XML attributes like show as action to suggest whether an item should appear directly in the bar bedroom or always being the overflow never. Then there was contextual mode or Contextual Action Mode CM. This was seen as a big improvement introduced around Android three point zero. You typically trigger it with a long press on an item like a list item or some text.
Ah like a right click on desktop.
Exactly like a right click, it would bring up a temporary action bar at the top with action specific to the item or items you selected. It supported selecting multiple items too, for batch actions. Like deleting multiple emails. Way better than the older floating context menus.
Okay, that sounds useful any other menu types.
There was also the pop up menu. This was simpler, just a little menu that pops up, often anchored to a specific view, providing some extra actions. It wasn't necessarily tied to acting on the view that triggered it, more like providing related options in nearby, like a spinner, but in a menu format.
Got it. So beyond menus for explicit actions, how did apps grab the user's attention or give quick feedback without being too disruptive?
For that, you had various alerts and notifications. For immediate physical feedback. Apps could use the vibrator service to make the phone vibrate simple enough, or play sounds using the ringtone manager to pla say, the default notification sound. The book even mentions a newer API twenty three feature set torch mode to flash the camera light briefly as an alert.
Using the flashlight for alerts.
That's novel, Yeah, a bit unusual, but shows the kind of low level control you had for quick non blocking messages. Toasts or the standard toasts.
Right, those little gray boxes that pop up briefly at the bottom exactly.
They'd show a short text message and then fade away, simple, unobtrusive. You could even customize their layout if you wanted something fancier.
Than just text, and for messages that needed a user response like a confirmation.
That's where alert dialogue came in the classic message box. You could create dialogues with a title, a message, and up to three standard buttons positive, negative, neutral like yes, no cancel. You could also add icons or even put lists inside them single choice lists, multi choice lists, or embed a completely custom layout if needed. Very flexible.
What about showing progress like if something was loading.
There was progress dialogue. It showed a spinning wheel or a progress bar, typically indicating loading or some indeterminate task. However, the cookbook explicitly advised developers to avoid progress dialogue if possible.
Why I avoid it.
Because it was modal. It blocked the user from interacting with the rest of the app until it was dismissed, which could be really frustrating if the task took a while. The recommendation was to integrate a progress bar directly into your apps layout instead, so the user could still interact with other parts of the UI. Wall waiting.
That's a key usability point even back then. Okay, so that's in app alerts. What about the system notifications, the ones that appear in the notification.
Drawer, Ah notifications. Yeah, super important for engaging users when the app wasn't in the foreground. Developers built these using notification compat builder. That compact part signifies it came from the support library, helping ensure compatibility across different Android versions. You'd set things like a small icon, a title, the main content text, and.
Could you add buttons to notifications like reply or archive?
Yes? Absolutely, you could add action buttons using something called pending intent. A pending intent is basically a token that you give to the Android system. It wraps an intent and grants the system permission to send that intent on your app's behalf at a later time, even if your app isn't running.
So the notification itself could trigger an action in your app securely exactly.
It's how notification actions worked. Clicking a reply button might launch a specific activity in your app, or trigger a background service to handle the reply. Later Android versions added
more features like expanded notifications. Android four point one plus could show more content, like a longer text snippet or an image using set style, and Android five point zero brought specialized styles like media player notifications with playback controls, though the book notes this wasn't in the compat library yet, and also heads up notifications.
Oh those ones that pop up over everything.
Yeah, the really intrusive ones. They appeared on top of whatever app you were using. They were reserved for high priority things and required setting priority macs and usually having a sound or vibration to trigger them. You sparingly definitely.
Okay, so we've got menus, alerts, notifications. What about handling direct touch on the screen and tapping into all those sensors phones have, right.
Making the app physically responsive. The book covers touchscreen and sensors quite well. For the basics simple clicks and long presses you'd use on click listener and on long click listener. You can set these up in your Java colon code or even directly in the XML layout using the Android dot on click attribute. For simple cases, any of you could have these listeners.
And for more complex gestures swiping, pinching.
For common gestures like detecting swipes, flings, double taps, single taps, the gesture detector compact class from the support library was the way to go. It's simplified detecting these standard motions for multi touch, specifically pinched to zoom, there was scale gesture detector. It would track two fingers and provide you with a scale factor indicating how much the user was trying to zoom in or out. You'd then use that factor to resize an image or map for example.
Okay, and that common pattern pulling down to refresh a list.
Ah, yes, swipe to refresh. That was made much easier with the swipe refreshed layout widget. You just wrap your list view like a blist view or recycle view inside this layout, set up a listener and it would handle detecting the pull gester and showing the standard refresh indicator for you much less boilerplate code.
Nice. Now beyond the screen, what about sensors, accelerometer, compass.
Yeah, The Android sensor framework opened up a lot of possibilities for context to wear apps. First, you could query the sensor manager to see what sensors were actually available on the specific device accelerometer, gyroscope, light sensor, magnetic field sensor, proximity sensor, et cetera. Not all devices had all sensors right, you had to check first definitely. Then to get data,
you'd register a sensor event listener. This listener has a callback method on sensor changed, which gets called repeatedly by the system whenever there's a new sensor data. It provides a sensor event object containing the actual values.
And the cookbook had an example.
It did a really neat one creating a simple compass. It showed how to get data from both the magnetic field sensor and the accelerometer. Then you'd use methods like sensor manager dot get rotation matrix and sensor manager dot get orientation to combine that data and calculate the device's orientation relative to magnetic.
North and use that to rotate a compass needle image.
Exactly, you'd update the rotation of an image view showing a compass needle based on the calculated orientation angles. A great practical example of you use using sensor.
Fusion cool and finally just basic device orientation portrait versus landscape.
Yep. You can easily check the current configuration for configuration dot orientation landscape or orientation portrait. The book also mentioned using Android dot config changes in the manifest to prevent the default activity recreation on orientation changes, but strongly cautioned that this was usually not the right approach. It was better to handle the recreation properly with state.
Saving right avoiding the life cycle rather than handling it.
Got it.
Okay, we've covered a huge amount on the UI and interaction, but apps need data and they need to connect. This next bit seems crucial. How did developers manage data storage and network communication back in twenty sixteen? It sounds complex, It really was, and.
This segment highlights the challenge of doing it efficiently and reliably on mobile and reads the question how do these cookbook solutions scale? The book lays out the main data storage options available.
Then what were they?
First? You had shared preferences, super simple key value storage for private primitive data I think user settings, maybe log in token, easy to use for small bits.
Of data, okay, like a little settings file exactly.
Then internal storage. This was for saving private files directly to the device's internal memory. Other apps couldn't access these files, and they got deleted automatically if the user uninstalled your app. The downside usually less space available compared to external storage, but it's always there.
And external storage the SD card usually.
Right or simulated external storage. This was for files you might want the user to access directly, or larger files could be public or private within your app specific external folder. The big caveat external storage might not always be available. If the user mounted the device as USD storage on a computer or move the SD card, your app couldn't access it. You always had to check its.
State permissions needed for that too.
I bet write external storage and re external storage.
Okay, what about more structured data, not just key value pairs.
That's where squad database came in. Android has built in support for Squily. It provided a private relational database for your app. Great for storing lots of structured data, contacts, inventory, game scores, anything complex. You could even expose this data to other apps securely using something called the content provider, but mostly it was for internal app data.
The standard for local databases then.
Yeah. Lastly, lastly, the book broadly mentions cloud storage, basically saving data off the device, either to your own private servers or using third party cloud service providers.
Gotcha, So focusing on files for a moment, how did developers actually read and write files? Maybe manage temporary data?
Standard java file io, mostly using file input stream. File input stream often wrapped with buffer reader or print writer for text files. The cookbook showed examples for both internal and external storage. For temporary data, there was a dedicated
cash directory you could get via getcash dear. The idea was you put temporary files here, and the Android system was free to delete these files if the device started running low on storage, so you couldn't rely on cash files persisting important distinction.
What about including files directly in the app package, like audio clips or maybe some data files?
Two main ways for that. You could put files in the reservo folder. These were treated like other resources. They got a resource ID or brought up idio. Android verified the existed a compile time, and you access them via that ID. Good for things like media files okay, and the other way the assets folder. Files placed here were compiled into the APK as well, but they didn't get resource IDs. You access them more like a traditional filesystem,
using their file names via the asset manager. This was useful if you needed to access files by dynamically generated names, or if you were using a library that expected filepaths instead of resource IDs. The trade off was less compile time safety.
Right. Okay, let's dive deeper into secollite. That seems like a core piece. How did the cookbook approach actually using the database, creating adding data?
It focused heavily on the practical cr rout operations create, read, update, delete. The main tool for managing the database was the slee out open helper class.
That's quite open helper It's subclass.
This helper it had methods like on create, where you'd define your initial database schema that create table statements, and on upgrade, where you'd put logic to handle migrating data if you change your schema in a future app update. This was managed by incrementing the database version constant ah.
Managing those schema changes is always.
Tricky, always. The helper simplified it somewhat. The cookbook used a simple dictionary database example words and definitions to show how to insert new words, query for definitions, update entries, and delete them using methods on the squad day database object you got from the helper. It also pointed out an important convention, including an integer primary key column named ID.
This wasn't strictly required by Scorelight, but many Android framework classes, especially UI adapters like simple cursor adapter expected it, so it was best practice.
Good tip. Now, database queries can be slow. Doing that on the main UI thread is bad right leads to freezes.
Absolutely a cardinal sin and and or development. Blocking the main thread leads to sluggishness and potentially the dreaded application not responding anur dialogue.
So how did they handle background database access cleanly? Back then, the.
Recommended approach in the cookbook, especially for loading data to display in the UI, was using loaders, yes, specifically cursor loader for database queries. Loaders were part of the Android
framework designed to simplify asynchronous data loading. The big benefits were they automatically performed the database query on a background thread, so the UI thread wasn't blocked, and if you were using them with a content provider, they could automatically monitor the underlying data source for changes and reload the data to update the UI, although without a content provider you might need to manually trigger a reload.
So they handled the background thread and delivering results back to the UI thread exactly.
You'd implement loadermanager dot loader callbacks. The on create loader method would create and return your cursor latter specifying the query. The loader did the work in the background. Then the onload finished callback, which ran on the UI thread, would deliver the resulting data a cursor in this case, ready for you to update your UI adapter. It abstracted away a lot of the threading complexity.
Okay, that sounds much better than raw threads shifting gears. Now to communication off the device, what about interacting with phone features like calls and SMS.
Apps could definitely do that, though it required specific permissions. For making a phone call, you'd use an intent with the ax that you would call action and the phone number. Pretty straightforward, but needed the gellphone permission.
And could you listen for call events like know when a call ends.
Yes, you could create a phone state listener and register it with the Telephony Manager. This listener had callbacks for various state changes, including running off hook and IDOL call ended.
Okay.
Sending SMS for SMS, you'd use the SIMS manager get the default instance, then call, send text message, passing the destination number, message body, etc. Required the send SMS permission. The book even mentioned handling long messages using divide.
Message and receiving SMS.
That involves setting up a broadcast receiver You'd declare it in your manifest with an intent filter for the Android Dot provider telefany dot SMS received action and request the receives MS permission. When an SMS arrived, your receiver's on receive method would be called with the message details. Pretty low level access to core functions definitely okay.
Broader network stuff displaying web content or checking if the phone is online.
Web and network communication yeah. Essential for just displaying web pages within your app. WebView is the component you could load URLs, html, strings, whatever. A key part was using a WebView client. By setting your own client, you could intercept page navigation. For example, you could force links clicked within the WebView to open in the same WebView rather than launching an external browser, keeping the user within your app up. You could even restrict navigation to only specific domains.
Making it feel more integrated. And just checking connectivity yep, you'd.
Use the Connectivity Manager system service. You could get the active network info object and check if it was connected and its type Wi Fi mobile. This required the Internet and access network state permissions, crucial before attempting any network operation right now.
The cookbook mentioned a library called Volley as a new option back in twenty sixteen for network requests, What was the deal with Volley?
Ah? Volley. Yes, it was introduced by Google and positioned as a simpler way to handle common network operations compared to using HTTPURLA connection directly, which involved a lot of boil play.
Code, so it simplified things it did.
It managed a request queue and a threadpool defaulting to four threads, automatically handled basic response caching to disc transparently, and even allowed setting priorities for requests.
Sounds good? What was it best for?
The book highlights that Volley really shown for making law? What's small network requests efficiently? Think fetching Jason data for a list or downloading images as a user scrolls. It's built in support for string Jason and image requests made these common tasks much easier.
So what were the downsides? The limitations?
The big one mentioned was that Volley was explicitly not recommended for large downloads or streaming operations. Why not because it processed and parsed the entire response in memory. Trying to download a huge file or stream video with Volley would likely lead to out of memory air crashes. It just wasn't designed for that. It also had mechanisms for canceling requests using tags, which was important to avoid wasting bandwidth if the user navigated away.
So a great tool for specific use cases, but not a silver bullet for all networking. That's a really important insight. Okay, we've covered data and connectivity. Now for the final stretch getting the app ready for the real world, polishing it, maybe connecting to back end services. What did the cookbook say about app readiness?
Yeah, and this section really touches on some critical aspects and it raises that question again, how much of this twenty sixteen wisdom still applies directly and where have things fundamentally shifted. One huge shift discussed was the Android six point zero run time permission.
Model, Right, that was a massive change. Before that, you just accepted all permissions when installing the app, didn't you exactly?
It was all or nothing. If you didn't like one permission and app asked for, your only choice was to not install it. Android six point zero API twenty three change that completely. Users could now grant or deny permissions individually at the time the app actually needed them, not upfronted installation, and they could even revoke permissions later through the system settings.
Huge win for user privacy and control, But what did it mean for developers?
It meant a significant code change. Developers now had to explicitly check if they had a permission using check self permission. If not, they often needed to show some rationale to the user explaining why the permission was needed. That was should show request permission rationale, and then they had to actually request the prom mission using request permissions and handle the user's response grant or deny in a callback.
So a lot more interactive permission handling needed.
Definitely. It forced developers to be more thoughtful about the permissions they requested and when they requested them. A big step change, but only affected apps running on Android six point zero plus devices targeting that EPI level or higher.
Okay, what about tasks that needed to run periodically, maybe even when the app wasn't running, like checking for updates every few hours.
That was the domain of the alarm manager. You'd use it to schedule your app to be woken up at specific times or intervals to perform tasks. The key benefit was that the OS managed the scheduling. Your app didn't need to be constantly running in the background, consuming resources. Just to wake up. Occasionally the OS would wake it up via intent when the alarm fire.
What kinds of alarms were there?
There were different types based on the clock used. OURTC used the real time clock wall clock time, while elapsed real time use the time since the divis I booted, and there were wake up versions of both which would actually wake the device CPU if it was asleep when the alarm fired. Non wake up alarms would only fire the next time the device woke up for some.
Other reason, and the cookbook had best practices.
Yes, keep alarms in frequent, avoid using wake up alarms unless absolutely necessary to conserve battery, and use inexact timing where possible to allow the system to bash alarms together again for battery efficiency.
Did alarm survive reboots?
Crucially, no alarm manager alarms were cleared when the device rebooted. If your app needed persistent scheduled tasks, it had to include a broadcast receiver that listened for the action boot, completed broadcast, and reschedule its alarms every time the device started up. A common gotcha.
Ah Okay, now what about that fundamental problem of doing long running work without freezing the UI we mentioned loaders for data, But what about other background tasks?
The classic solution, presented in a twenty sixteen cookbook was acing task Acing task.
Still hear about that one, often not in a good way.
Yeah, yeah, it has a mixed reputation now, But back then it was a standard, relatively simple way to handle background work with UI updates. The problem it solves was clear doing network requests, heavy calculations, or anything slow on the main UI thread caused the app to hang, leading to an RS. The rules were simple, don't block the main thread, do all UI updates on the main thread.
So how did acy task help?
It provided a simple structure. You'd override do end background, which ran on a background worker thread. That's where you put your long running code. When doing background finished, it could return a result. Then on post execute, which automatically ran back on the main UI thread, received that result, allowing you to safely update your UI like showing the downloaded data or hiding a progress bar. It also had on pre execute UI thread before and on progress update UI thread for progress.
Sounds straightforward enough, What were the catches? Why the bad reputation? Now?
The main issue hinted at even in the cookbook was its type coupling with the activity or fragment that started it. If you started an acing task from an activity and the user rotated the screen, destroying and recreating the activity before the task finished, uh oh yeah, the acing task might hold an implicit reference to the old destroyed activity context.
This could lead to memory leaks, and if the task tried to update the UI on post execute, it could crash because the activity was trying to update didn't exist anymore, or it updated the wrong instance it created.
These orphan tasks so convenient, but fragile if not handled very carefully.
Extremely That's why the book suggested maybe using it with fragments, specifically retained fragments or loaders as potentially safer alternatives for handling background tasks tied to UI life cycles. Modern Android uses core routines, RX Java or work Manager, which handle life cycles much more elegantly.
Makes sense. What about other advanced features voice input, push messages.
Yeah, the cookbook touched on those two. Speech recognition was possible using the Google Speed service available since Android two point two ap eight. You'd launched an intent to start the voice recognizer and get the results back. For push notifications, the standard back then was Google Cloud Messaging GCM.
GCM before FCM, firebased Cloud Messaging.
Exactly, GCM was the predecessor. The architecture involved three parts, your application server, Google's GCM servers, and the Android device running your app. The flow was your app registers with GCM servers to get a unique device registration token. Your app sends this token to your back end server. When your server wants to send a push message, it sends the message content and the token to Google's GCM server. GCM then handles delivering that message down to the correct.
Device and the app received it.
Yes, the app needed to implement specific services, an instance I listener service to handle token generation and refresh, and a GCM listener service with an on message received callback to actually handle incoming push messages. It worked back to API eight.
Okay and letting users sign in easily.
Google sign in was becoming common. It allowed users to sign into your app using their existing Google accase out, avoiding the need for them to create yet another username and password. It involved using the Google app a client, a central entry point for Google APIs back then, and adding a standard sigin button to your layout. Once signed in, you could access basic profile info like their name, email, photo, url, etc. With their permission, of.
Course, streamlining log in okay. Finally, the cookbook looked at back end as a service BASH options. What was the idea there?
The idea was simple, Building and maintaining your own server back end for an app is hard work. You need server infrastructure, databases, user management, APIs. It's a lot. BASS providers offered a shortcut. They provided ready made back end infrastructure, cloud databases, user authentication, push notification services, file storage, serverless functions, all accessible via NS. That was the pitch. Focus on the front end experience, let the BASS handle the back
end heavy lifting. The cookbook compared several providers available in twenty sixteen based on things like their free tiers, monthly users, API calls, features like push support and storage limits.
Who are some of the players back then?
The book detailed setup for a few app forty two which seemed focused on games, back endless offering, MBS hosting, APIs Buddy focusing on device sensors, Kinvey one of the earlier big players, and notably.
Firebase AH Firebase, which Google had recently acquired around that time.
Exactly Firebase was highlighted particularly for its real time auto syncing, database authentication, and hosting. Its acquisition by Google signaled a big push into this bast space. Each provider had slightly different strength set of processes. Some used MAVE and GRADEL, others needed manual library inclusion and pricing models. It really represented an emerging alternative to DIY back ends.
Wow, we've really journeyed back to twenty sixteen ANDREID development. We've taken this deep dive into the Android Application Development Cookbooks second Edition, giving you hopefully a really comprehensive tour.
We explored everything from those fundamental activities and intents, the nuts and bolts of UI design with layouts, styles, themes, the complexities of data management and life cycle, all those user interaction points like menus and notifications, right through to app readiness concerns like run time permissions, background tasks with ACYNC task and that emerging world of back end as
a service. We really hope this deep dive has given you more than just a history lesson, maybe a shortcut to being well informed about a really pivotal time and Android's evolution, and maybe spark some aha moments about the core principles that while still drive a lot of mobile development today, even if the tools look different. It's honestly fascinating to see how many of those fundamental recipes from
twenty sixteen laid the groundwork, even with all the changes since. So, as you think about everything we discussed today from twenty sixteen, you know, wrestling with the activity life cycle manually, the pitfalls of async task, the early days of malaysious, what foundational concepts do you think still ring true, maybe as core design principles, and which parts feel completely alien now
totally revolutionized or abstracted away in modern Android development? And maybe think about this, what recipes would be absolutely essential in an Android application development cook book if it were published to day. What would be the chapter headings reflecting the biggest shifts and the most critical techniques developers need to master now compared to back in twenty sixteen,