Starting with NetBeans and the Android SDK

Android is an operating system based on Linux with a Java programming interface. This means you will need some sort of basic understanding of Java to do Android programming. Certainly, as soon as I make that statement, someone will point to the tools available that require no knowledge of any programming language at all. Most of us know these tools will only allow you to go so far and when (not 'if') a problem arises, resolving it can be very tedious. If you do not have any knowledge of Java at this time, please contact me immediately.

Android is currently primarily developed by Google. The Android Software Development Kit (Android SDK) provides all necessary tools to develop Android applications. This includes a compiler, debugger and a device emulator, as well as its own virtual machine to run Android programs. However, using an IDE (Integrated Development Environment) can be very helpful. Right now the leading IDEs are NetBeans and Eclipse. If you have experience with one or the other, please just stay with that one. I find the learning curve for Eclipse to be a bit steeper and longer than for NetBeans so as an instructor, I tend to choose NetBeans. There are so many exercises on the Internet right now, half of them built for Eclipse, if you find it difficult to translate my instructions, I will help you find an alternate that requires no translation.

Android allows background processing, provides a rich user interface library, supports 2-D and 3-D graphics using the OpenGL libraries, access to the file system and provides an embedded SQLite database.

Android applications consist of different components and can re-use components of other applications. This leads to the concept of a task in Android; an application can re-use other Android components to archive a task. For example you can write an application which uses the Android Gallery application to pick a photo.

Web Apps

Web apps have universal access. Browsers of every shape and variety are everywhere. Any device on the network can access the content. At the top level, it is platform independent (more or less). If it can run a browser, it usually can run a Web App. This goes for PCs, Macs, Linux, Android, iPhone, Blackberry, etc. One can have automatic updates. Since the content comes from server, it is never out of date - as long as it was designed properly in the first place.

There are some very strong disadvantages to Web Apps, however. There are relatively few GUI controls and those that do exist are quite weak. The programmer has access to textfields, text areas, buttons, checkboxes, radio buttons, list boxes, and combo boxes. That's it! There is very limited direct drawing. One cannot interact with local resources. This means you cannot read files, call programs, or access devices on the user's machine. Let's say you have an ordering/inventory app. Now you want to generate a report. First the user must input the data. The data is sent to the server for authentication, validation, and processing. Here it is added to a database. Does this database hold everyone's data or do you have a separate file for every user? I'm sure you can see some rather large problems either way. Now send the information back to the user. The user wants a report on this or that subset of the information - back to the server. Okay, you see the picture. What if the server or router is down or too busy? There is no way to save a file on the user's device/machine that could be accessed in the case of a poor or non-existent Internet connection. As for adding functionality to an existing app, forget it. There are other problems, but you get the point.

Mobile Apps

There are many GUI controls available to the mobile app programmer and more coming every day. Mobile apps support direct drawing. This is what made Angry Birds possible. A mobile app can interact with a local resource. It can read files (e.g., contacts list), have local database, access GPS, initiate phone calls, get input from the microphone, create voice output, read screen orientation, etc. Communication is quite efficient. This means you can make use of whatever networking protocol is best for your needs. Since Android is based on Java, the Android apps are easier to write (Objective C for iPhone) Mobile apps should be designed for small displays with a touch screen. Many apps and GUI controls are optimized for this environment.

There are also disadvantages to Mobile Apps. At this time there is no one universal access. I have a Smart Phone and a tablet (both Android) some apps will run on one or the other, but not both. Plus, an Android app cannot run on iPhone, Blackberry, PC, Mac or Linux box. It is not always easy to manage updates.

During deployment on an Android device, the Android system will create a unique user and group ID for every Android application. Each application file is private to this generated user, e.g. other applications cannot access these files. In addition each Android application will be started in its own process. Therefore by means of the underlying Linux operating system, every Android application is isolated from other running applications.

If data should be shared, the application must do this explicitly, e.g. via a Service or a ContentProvider.

Android also contains a permission system. Android predefines permissions for certain tasks but every application can define additional permissions. An Android application declare its required permissions in its AndroidManifest.xml configuration file. For example an application may declare that it requires Internet access.

Permissions have different levels. Some permissions are automatically granted by the Android system, some are automatically rejected.In most cases the requested permissions will be presented to the user before installation of the application. The user needs to decide if these permissions are given to the application. If the user denies a permission required by the application, this application cannot be installed. The check of the permission is only performed during installation, permissions cannot be denied or granted after the installation.

The following gives a short overview of the most important Android components.

Activity

An Activity represents the presentation layer of an Android application. A simplified description is that an Activity represents a screen in your Android application. This is slightly incorrect as Activities can be displayed as dialogs or can be transparent. An Android application can have several Activities.

Views and ViewGroups

Views are user interface widgets, e.g. buttons or text fields. The base class for all Views is the android.view.View class. Views have attributes which can be used to configure their appearance and behavior.

A ViewGroup is responsible for arranging other Views. ViewGroups is also called layout managers. The base class for these layout managers is the android.view.ViewGroup class which extends the View class. ViewGroups can be nestled to create complex layouts. You should not nestle ViewGroups too deeply as this has a negative impact on the performance.

Intents

Intents are asynchronous messages which allow the application to request functionality from other components of the Android system, e.g. from Services or Activities. An application can call a component directly (explicit Intent) or ask the Android system to evaluate registered components based on the Intent data (implicit Intents ). For example the application could implement sharing of data via an Intent and all components which allow sharing of data would be available for the user to select. Applications register themselves to an Intent via an IntentFilter. Intents allow to combine loosely coupled components to perform certain tasks.

Services

Services perform background tasks without providing a user interface. They can notify the user via the notification framework in Android.

ContentProvider

A ContentProvider provides a structured interface to application data. Via a ContentProvider your application can share data with other applications. Android contains an SQLite database which is frequently used in conjunction with a ContentProvider. The SQLite database would store the data, which would be accessed via the ContentProvider.

BroadcastReceiver

BroadcastReceiver can be registered to receive system messages and Intents. A BroadcastReceiver will get notified by the Android system, if the specified situation happens. For example a BroadcastReceiver could get called once the Android system completed the boot process or if a phone call is received.

(HomeScreen) Widgets

Widgets are interactive components which are primarily used on the Android homescreen. They typically display some kind of data and allow the user to perform actions via them. For example a Widget could display a short summary of new emails and if the user selects an email, it could start the email application with the selected email.

Other

Android provide many more components but the list above describes the most important ones. Other Android components are Live Folders and Live Wallpapers . Live Folders display data on the homescreen without launching the corresponding application while Live Wallpapers allow to create annimated backgrounds.

Google provides the Android Development Tools (ADT) to develop Android applications with Eclipse. ADT is a set of components (plug-ins) which extend the Eclipse IDE with Android development capabilities.

ADT contains all required functionalities to create, compile, debug and deploy Android applications from the Eclipse IDE. ADT also allows to create and start AVDs.

Dalvik Virtual Machine

The Android system uses a special virtual machine, i.e. the Dalvik Virtual Machine to run Java based applications. Dalvik uses an own bytecode format which is different from Java bytecode.

Therefore you cannot directly run Java class files on Android, they need to get converted in the Dalvik bytecode format.

Android applications are primarily written in the Java programming language. The Java source files are converted to Java class files by the Java compiler.

The Android SDK contains a tool called dx which converts Java class files into a .dex (Dalvik Executable) file. All class files of one application are placed in one compressed .dex file. During this conversion process redundant information in the class files are optimized in the .dex file. For example if the same String is found in different class files, the .dex file contains only once reference of this String.

These dex files are therefore much smaller in size than the corresponding class files. The .dex file and the resources of an Android project, e.g. the images and XML files, are packed into an .apk (Android Package) file. The program aapt (Android Asset Packaging Tool) performs this packaging. The resulting .apk file contains all necessary data to run the Android application and can be deployed to an Android device via the adb tool.

The Android Development Tools (ADT) performs these steps transparently to the user.

If you use the ADT tooling you press a button the whole Android application (.apk file) will be created and deployed.

I hope that you will all take part in the instruction part of this course. Learning is one thing. Being able to explain what you have learned is another. We have a Discussion Forum I would like you to to use quite often. Use it to ask questions, answer questions, and share things you have learned outside of the normal reading.

I don't follow any one textbook because they are usually out of date by the time they are published (yes, even this material is now out of date). Therefore, you can learn much more by just reading a little here and there and then sharing it on the Android section of the forum.

You will need to register. Click on the "Register" button on the top left set of buttons. If you don't see it there, it's because I was getting spammed and I had to disable it. Please just send me your real name (this won't show up anywhere), the name you want to use on the forum (make sure it won't give any hint to your real name), and the password you want to use (no spaces or 'illegal' characters).

Some instructors feel that providing the code that is in the text is helpful because the student can at least start with a working version. Others feel that entering the code helps students to see relationships and emphasizes the need to follow directions.

I can see both views. If you want to download the code from the publisher (when it's available), feel free to do so. If you have a hard time finding it, I can post it on the forum for you. If you want to post it, please go ahead.

The most important part about learning is doing what makes sense to you. Use whatever you need to make your life better and easier. I am very willing to lead, pointing out the important parts, and providing as many resources as I can.