Android goes beyond Java, gains native C/C++ dev kit

Google's open source Android operating system is maturing and beginning to attract a more diverse audience of third-party developers. To accommodate the growing need for more power and flexibility, Google is opening up the platform to additional programming languages and new kinds of development.

The Android userspace is largely dominated by Java technologies that run on top of Google's custom Dalvik Java virtual machine. At launch, Java was the only officially supported programming language for building distributable third-party Android software. That's starting to change as Google introduces new options. On Thursday, the company announced the availability of the Android Native Development Kit (NDK) which will allow developers to build Android software components with C and C++.

The NDK will enable developers to code some of the performance-sensitive parts of their programs in C and reuse existing C code on the Android platform. It comes with some limitations, however, and is not intended to serve as a full alternative to Android's Java development model.

The NDK does not provide access to platform framework APIs. It's intended to be used alongside Java to code individual parts of programs that require existing C libraries or higher performance. JNI is used as the bridge between Java and native code.

The NDK includes a cross-compiler toolchain for generating ARM binaries that can be deployed in Android APK packages. Google says that native code should be used sparingly and is not appropriate for the vast majority of third-party Android applications. The company also points out that using it could reduce portability and have other negative consequences.

"The NDK will not benefit most applications. As a developer, you will need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but does always increase application complexity," the documentation says. "Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on."

In addition to delivering support for native code, Google is also extending Android to support popular dynamic scripting languages. Earlier this month, Google launched the Android Scripting Environment (ASE) which allows third-party developers to build simple Android applications with Python and Lua.

The ASE provides access to platform framework capabilities through a JSON RPC bridge. This means that scripts which run on top of the ASE can actually leverage other capabilities of the operating system, such as controlling the ringer volume, toggling WiFi, making calls, detecting the user's current location, launching activities, and handling intents. One of the most compelling aspects of the ASE is that it allows users to code new scripts on the device itself.

Object Relation Mapping and Java Persistence: Data Modeling and Legacy Schemas

These days, it’s essential to have a strong knowledge of object relational mapping. This reflects the need for retaining application data long after the application has run. As the need for data storage grows, so too does the need to work with legacy databases or schemas. A schema is simply a description of a database—i.e., its tables, data types, constraints, etc.

Before working with legacy schemas, it’s sometimes necessary to learn more complex mapping techniques. This knowledge will help you in working around what are often quirky legacy schemas. Very often, it’s simply not an option to modify a legacy schema.

A key concept in object relational mapping is the difference between entity and value types. Let’s now look at this concept.

Entity and Value Types
In Hibernate, types can be either entity or value. An entity type has a persistent identity that can outlive the application that creates it. In other words, an entity is persisted to the database, loaded from the database, updated, etc. A value type, on the other hand, doesn’t have a persistent identity and may be considered no more than a set of attributes that relate to a more important entity. For a developer who’s starting up the object relational mapping value chain, there is a temptation to just lump everything in to the one class definition. Doing so misses an important design opportunity.

In summary, a value type may be a component of an entity. We need to make this more concrete! A typical example of an entity type is a user—e.g., a system user. The postal address of a user is more likely to be a value type. In some ways, you can think of a value type as an attribute of an entity. Let’s now see an example of how to map an entity and value type.