Part V
Appendixes
Appendix A
Java vs. the Android
Language and APIs
For the most part, Android programs are written in the Java language, and they use the Java 5 Standard Edition (SE) library APIs. I say “for the most part” because there are a few differences. This appendix highlights the differences between regular Java and what you’ll find in Android. If you’re already proficient in Java development on other platforms, you should take a close look to see what things you need to “unlearn.”
A.1 Language Subset
Android uses a standard Java compiler to compile your source code into regular bytecodes and then translates those bytecodes into Dalvik instructions. Therefore, the entire Java language is supported, not just a subset. Compare this to the Google Web Toolkit (GWT), which has its own Java to JavaScript translator. By using the stock compiler and bytecodes, you don’t even need to have the source code for libraries that you want to use in your applications.
Language Level
Android supports code compatible with Java Standard Edition 5 or earlier. Java 6 and 7 class formats and features are not yet supported but could be added in future releases.
LANGUAGE SUBSET 
279
Intrinsic Types
All Java intrinsic types including byte, char, short, int, long, float, double, Object, String, and arrays are supported. However, on some lowend hardware, floating point is emulated. That means it’s performed in software instead of hardware, making it much slower than integer arithmetic. Although occasional use is fine, avoid using float or double in performance-critical code unless your algorithm really requires floating point or you’re sure your application will be running on a high-end device.
Multithreading and Synchronization
Multiple threads are supported by time slicing: giving each thread a few milliseconds to run and then performing a context switch to let another thread have a turn. Although Android will support any number of threads, in general you should use only one or two. One thread is dedicated for the main user interface (if you have one), and another thread is used for long-running operations such as calculations or network I/O.
The Dalvik VM implements the synchronized keyword and synchroni- zation-related library methods such as Object.wait( ), Object.notify( ), and
Object.notifyAll( ). It also supports the java.util.concurrent package for more sophisticated algorithms. Use them as you would in any Java program to keep multiple threads from interfering with each other.
Reflection
Although the Android platform supports Java reflection, as a general rule you should not use it. The reason is simple performance: reflection is slow. Consider alternatives such as compile-time tools and preprocessors instead.
Finalization
The Dalvik VM supports object finalization during garbage collection just like regular Java VMs. However, most Java experts advise you not to rely on finalizers because you cannot predict when (or if) they will run. Instead of finalizers, use explicit close( ) or terminate( ) methods. Android is targeted toward resource-constrained hardware, so it’s important that you release all resources as soon as you no longer need them.
STANDARD LIBRARY SUBSET 
280
A.2 Standard Library Subset
Android supports a relatively large subset of the Java Standard Edition 5.0 library. Some things were left out because they simply didn’t make sense (such as printing), and others were omitted because better APIs are available that are specific to Android (such as user interfaces).
Supported
The following standard packages are supported in Android. Consult the Java 2 Platform Standard Edition 5.0 API documentation1 for information on how to use them:
•java.awt.font: A few constants for Unicode and fonts
•java.beans: A few classes and interfaces for JavaBeans property changes
•java.io: File and stream I/O
•java.lang (except java.lang.management): Language and exception support
•java.math: Big numbers, rounding, precision
•java.net: Network I/O, URLs, sockets
•java.nio: File and channel I/O
•java.security: Authorization, certificates, public keys
•java.sql: Database interfaces
•java.text: Formatting, natural language, collation
•java.util (including java.util.concurrent): Lists, maps, sets, arrays, collections
•javax.crypto: Ciphers, public keys
•javax.microedition.khronos: OpenGL graphics (from Java Micro Edition)
•javax.net: Socket factories, SSL
•javax.security (except javax.security.auth.kerberos, javax.security.auth.spi, and javax.security.sasl)
•javax.sql (except javax.sql.rowset): More database interfaces
•javax.xml.parsers: XML parsing
•org.w3c.dom (but not subpackages): DOM nodes and elements
•org.xml.sax: Simple API for XML
Note that although the regular Java SQL database APIs (JDBC) are included, you don’t use them to access local SQLite databases. Use the
1. http://java.sun.com/j2se/1.5.0/docs/api
THIRD-PAR TY LIBRARIES 
281
android.database APIs instead (see Chapter 9, Putting SQL to Work, on page 178).
Not Supported
These packages, normally part of the Java 2 Platform Standard Edition, are not supported by Android:
•java.applet
•java.awt
•java.lang.management
•java.rmi
•javax.accessibility
•javax.activity
•javax.imageio
•javax.management
•javax.naming
•javax.print
•javax.rmi
•javax.security.auth.kerberos
•javax.security.auth.spi
•javax.security.sasl
•javax.sound
•javax.swing
•javax.transaction
•javax.xml (except javax.xml.parsers)
•org.ietf.*
•org.omg.*
•org.w3c.dom.* (subpackages)
A.3 Third-Party Libraries
In addition to the standard libraries listed earlier, the Android SDK comes with a number of third-party libraries for your convenience:
•org.apache.http: HTTP authentication, cookies, methods, and protocol
•org.json: JavaScript Object Notation
•org.xml.sax: XML parsing
•org.xmlpull.v1: XML parsing