This course teaches students how to write software for mobile devices while reinforcing the principles of good object-oriented software development. To that end, this course will cover all the necessary topics required for writing Android applications. We will apply the fundamentals of object-oriented programming using Java. Students will also become well versed in XML, the Android Software Development Kit, the Android Studio IDE, Android application components and features, and many other topics of interest. In addition to the basics of Android programming, we will cover several specialized topics on mobile programming, including networking, using location data, streaming media, etc.
As discussed in the Threads lesson, if you want to run a task in the background without blocking the User Interface (UI) thread, you must do that work in another thread. You have already been introduced to a couple ways to accomplish that. But there are downsides to those techniques which can cause massive developer headaches. This lesson will introduce a special abstract class provided to us by Android known as an AsyncTask, built specifically to address the problems you may encounter when writing your own threading code.
AsyncTasks are great, but is it always advisable to use an AsyncTask to push the application's work to another thread? That depends on your app. An AsyncTask is created by creating a new thread from a running Activity, which means that you must first launch that Activity and its associated user interface (UI). But what happens when the Activity is destroyed? The AsyncTask (being that it's on its own thread) will continue to run until it's done doing its work, at which time, presumably, there will be some code in the AsyncTask's onPostExecute() method that updates the Activity UI...which does not exist! To avoid this, you'll need to add the proper code in the Activity's onDestroy method to gracefully cancel the AsyncTask.
If you have a task that you want to run at a specific date and time, even when your application is not running, then you may consider using an Alarm. For example, an alarm can be used to trigger a Service with a long-running background task, or a task that needs to run at a given time interval. Alarms can be set to run just once, or at a regularly scheduled time. You can also specify whether the alarm should wake the device or not. There are four steps to creating an alarm:
You've already seen one way to provide notification to users in the form of Toast messages. While handy, Toasts are limited in terms of both the limited amount of time they're displayed and the fact that the user must have the application running. When you need your app to provide notifications to the user that persist until a specific action occurs (such as the user clicking on the notification), or when your app is not running, then status bar notifications are the way to go!