\subsection{Managing the Intents}

\begin{frame}
  \frametitle{Intents}
  \begin{itemize}
  \item Intents are basically a bundle of several pieces of information,
    mostly
    \begin{itemize}
    \item \code{Component Name}
      \begin{itemize}
      \item Contains both the full class name of the target
        component plus the package name defined in the Manifest
      \end{itemize}
    \item \code{Action}
      \begin{itemize}
      \item The action to perform or that has been performed
      \end{itemize}
    \item \code{Data}
      \begin{itemize}
      \item The data to act upon, written as a URI, like
        \code{tel://0123456789}
      \end{itemize}
    \item \code{Category}
      \begin{itemize}
      \item Contains additional information about the nature of the
        component that will handle the intent, for example the launcher
        or a preference panel
      \end{itemize}
    \end{itemize}
  \item The component name is optional. If it is set, the intent will
    be explicit. Otherwise, the intent will be implicit
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Intent Resolution}
  \begin{itemize}
  \item When using explicit intents, dispatching is quite easy, as
    the target component is explicitly named. However, it is quite
    rare that a developer knows the component name of external
    applications, so it is mostly used for internal communication.
  \item Implicit intents are a bit more tricky to dispatch. The system
    must find the best candidate for a given intent.
  \item To do so, components that want to receive intents have to
    declare them in their manifests \emph{Intent filters}, so that the
    system knows what components it can respond to.
  \item Components without intent filters will never receive implicit
    intents, only explicit ones
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Intent Filters 1/2}
  \begin{itemize}
  \item They are only about notifying the system about handled implicit
    intents
  \item Filters are based on matching by category, action and data.
    Filtering by only one of these three (by category for example) is fine.
    \begin{itemize}
    \item A filter can list several actions. If an intent action field
      corresponds to one of the actions listed here, the intent
      will match
    \item It can also list several categories. However, if none of the
      categories of an incoming intent are listed in the filter,
      then intent won't match.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Intent Filters 2/2}
  \begin{itemize}
  \item You can also use intent matching from your application by
    using the \code{query*} methods from the PackageManager to get a
    matching component from an Intent.
  \item For example, the launcher application does that to display
    only activities with filters that specify the category
    \code{android.intent.category.LAUNCHER} and the action
    \code{android.intent.action.MAIN}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Real Life Manifest Example: Notepad}
\begin{minted}[fontsize=\scriptsize]{xml}
<manifest package="com.example.android.notepad">
  <application android:icon="@drawable/app_notes"
               android:label="@string/app_name" >

    <activity android:name="NotesList"
              android:label="@string/title_notes_list">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
      <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <action android:name="android.intent.action.EDIT" />
        <action android:name="android.intent.action.PICK" />
        <category android:name="android.intent.category.DEFAULT" />
        <data android:mimeType="vnd.android.cursor.dir/vnd.google.note" />
      </intent-filter>
    </activity>
  </application>
</manifest>
\end{minted}
\end{frame}

\begin{frame}
  \frametitle{Broadcasted intents}
  \begin{itemize}
  \item Intents can also be broadcast thanks to two functions:
    \begin{itemize}
    \item \code{sendBroadcast} that broadcasts an intent that will be
      handled by all its handlers at the same time, in an undefined order
    \item \code{sendOrderedBroadcast} broadcasts an intent that will
      be handled by one handler at a time, possibly with propagation
      of the result to the next handler, or the possibility for a
      handler to cancel the broadcast
    \end{itemize}
  \item Broadcasts are used for system wide notification of important
    events: booting has completed, a package has been removed,
    etc.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Broadcast Receivers}
  \begin{itemize}
  \item Broadcast receivers are the fourth type of components that can
    be integrated into an application. They are specifically designed
    to deal with broadcast intents.
  \item Their overall design is quite easy to understand: there is
    only one callback to implement: \code{onReceive}
  \item The lifecycle is quite simple too: once the \code{onReceive} callback
    has returned, the receiver is considered no longer active and can
    be destroyed at any moment
  \item Thus you must not use asynchronous calls (Bind to a service
    for example) from the \code{onReceive} callback, as there is no way
    to be sure that the object calling the callback will still be alive
    in the future.
  \end{itemize}
\end{frame}
