Archive | Android Dev

Tags: , , , , ,

McObject, Object-Oriented Embedded Database for Android

Posted on 02 January 2008 by Hatem Ben Yacoub

McObject, Object-Oriented Embedded Database for AndroidMcObject announced today that Perst, its all-Java object-oriented, open source embedded database, has been verified as compatible with the Android mobile device platform backed by Google and the Open Handset Alliance.

McObject is offering the Android-ready Perst, as well as TestIndex, a demo application showing Perst and Android’s bundled SQLite database performing the same tasks side by side. Both are available as free downloads, with complete source code, from http://www.mcobject.com/android.

Perst

With Perst, users of Android-based phones will benefit from responsive, richly-featured embedded software made possible by a database system that delivers high performance and a small footprint, and by the efficiency that results from true Java developer-oriented features.

Perst stores data directly in Java objects. This eliminates the need for data-packing or unpacking code to map between the application’s data model and the database’s data model, as is required by relational and object-relational databases. The Perst API is flexible, easy-to-use and very fast compared to alternative commercial Java OODBMSs.

Perst is a very compact embedded database, with a core consisting of only five thousand lines of code. This small footprint imposes little demand on system resources. Moreover, Perst does not require administration. Perst supports transactions with the ACID (Atomic, Consistent, Isolated and Durable) properties, and expands developers’ coding efficiency by making Java objects as easy to use as possible.

For example, for access to objects, Perst implements specialized collection classes optimized for different data layouts and access patterns, including:

  • Classic B-Tree implementation;
  • R-tree indexes for spatially-oriented applications such as GIS and navigation;
  • Main-memory database containers, based on T-Tree indexes, optimized for real-time memory-only access;
  • Patricia Trie index, which speeds searches in networking and telephony applications;
  • TimeSeries class to efficiently deal with small fixed-size objects;
  • Specialized versions of collections for thick indices (indices with many duplicates), and bit indices (keys with a restricted number of possible values).

In addition to its core functionality, Perst provides optional features such as garbage collection, detection of hanging references, automatic schema evolution, XML import/export utilities, master-slave replication support (with the option to run read-only queries on slave nodes), an SQL subset to filter elements of any collection, and integration with the AspectJ and JAssist AOP tools.

To read McObject’s complete announcement of Perst and TestIndex for Android, see http://www.mcobject.com/pressroom.php?step=3&article=91.

Popularity: 43%

Comments (0)

Tags: , , , , , , , ,

Developer Interview with Brendan Burns, DroidDraw and Android-GL

Posted on 12 December 2007 by Hatem Ben Yacoub

DroidDrawSome of the very cool tools that popped out from Android developers, a Java applet called DroidDraw, which aims to provide a complete GUI creation tool for developers. OHM had an interview with Brendan Burns, who is behind the DroidDraw and Android-GL projects.

OHM : Can we know a little about yourself ?

Brendan : I’m a professor of computer science at Union College in Schenectady, NY. I just graduated a year and a half ago from the University of Massachusetts with a PhD in Robotics. Before grad. school, I worked in the software industry for a couple of years; mostly web-apps. I’ve done a bunch of different development over the years.

OHM : So you have a PhD in robotics, and you are interested into mobile development also ?

Brendan : I like to code. My term ended in the middle of November, and I wanted a project to keep me busy.

I had just taught graphics as my fall course and so I thought I’d play around and port some of the code from the class over to Android. Since I’d never done OpenGL on an embedded device, then I was thinking about building an app for the Challenge and I realized it was really annoying to build a GUI in XML. So I wrote the GUI builder.

OHM : Are you entering the challenge alone or in a team ?

Brendan : I’m not sure, probably by myself. I’m not 100% committed to entering. I have to come up with a really good idea, and so far my ideas are only ok.

OHM : So what about Android-GL, are you planning to build something with it ?

Brendan : I was thinking about it, but the renderer still has some bugs in it. While I was working on that I found a reported and number of them and I’ve seen reports from other people as well.

Also, I’m not 100% convinced that 3D plus mobile is the best solution, since most devices still don’t have accelerated graphics

OHM
: how did you find coding on Android platform ?

Brendan
: Its pretty easy I think. Its very similar to J2SE, more similar than J2ME which I did a little coding for.

There are some major differences between the OpenGL ES API and the regular OpenGL API - no glBegin(…)/glVertex(…)/glEnd() - that took some getting used to, but that’s the direction that the regular OpenGL API is headed also as far as I’ve heard. I think OpenGL 3.0 does away with that style of 3D coding. So it wasn’t a bad thing to learn more about.

OHM : so Java before Android was not much different than after Android ?

Brendan : Yeah, I think so, because I’m not in the mobile industry, and I don’t have a strong sense for the use of Java in that market. So I don’t really know if Android will mark a major shift toward Java or not.

One thing that is interesting about Android is that after two quick SDK releases, its slowed down !

You can tell that there are internal releases being developed, because the release stamp on the bottom of the docs pages keeps changing (Today its: Build m3-rc31 - 04 Dec 2007 17:47). So I’m curious about Google’s SDK release plans/schedule.

OHM : Which feature are you waiting for in the next release ?

Brendan : I’m waiting for Bluetooth support to be activated, So I can drive my Lego NXT Robot from Android !

Thanks Brendan for your time.

Popularity: 58%

Comments (7)

Tags: , , , , ,

db4objects Announces db4o Database for Android

Posted on 07 December 2007 by Hatem Ben Yacoub

Db4odb4objects, provider of object oriented database for the .NET and Java, have just announced officially the availability of their solution db4o for the Android platform. Db4o is a distributed company with engineers from all over the world, but really hats off for their amazing work to make their entire solution ready for Android in record time. So for now, Android developers have full object oriented solution ready to use.

Java programmers are delighted with Android’s full object oriented platform they are frustrated by its bundling with a relational database, requiring cumbersome plumbing between objects and tables. db4o fills the gap by providing a fast and secure, native Java object database that makes storing objects and sharing of data between applications simple and easy.

It’s true that Android came with “Content providers” but as Carl Rosenberger, db4object’s Chief Software Architect, said in a blog post “this is not Java, it’s not object-oriented, it’s not even SQL.” Which is the missing element in Android platform : The object database solution.

This Tuesday we had the chance to talk to Nik Wekwerth, the VP of Marketing db4objects, and he told us about db4o solution for Android and how it could help developers to make fully advanced object oriented applications. “It’s all about simplicity” he told us, “In Java you prefer always to stay in Object Oriented. Object is more flexible than SQL, it doesn’t lock your memory”.

There are currently two applications ported to db4o, the Password Manager application and MapMe. It shows the capabilities of db4o and the simplicity of using objects to store and retrieve data. There is no real benchmark at this time Nik told us, but it’s clear from these two samples that using db4o is much easier and very simple to maintain.

Where can you use db4o ? “If you look at our customers, database usage is very large from planes, high speed trains, photocopiers, research …” Added Nik. DB4o proved its performance in many critical usage and their world class leaders customers like BMW, Boeing, Bosch, IBM, Intel, Ricoh, and Seagate, are certainly enough for Android developers to make sure that they have in hands a high level database solution.

Developers can write software applications that enable the backup of user data to a back-end server or their home PC. A consumer use case could be to start a game on the phone, freeze it, and continue playing at home in the evening. Business use cases include field force automation, data acquisition such as with RFID, and complex navigation systems that use locally cached geodata.

Db4o is open source under GPL, you can get started by downloading db4o for Android and start porting your current relational application, or start your new project in a fully object oriented environnement.

Popularity: 31%

Comments (0)

Tags: , , ,

ME4Android, the JavaME Solution for Android

Posted on 28 November 2007 by Hatem Ben Yacoub

JavaMEAfter the Jbed’s Esmertec solution for JavaME on Android, a new solution have just arrived by Carlos Bazzarella from Poliplus software, called : ME4Android. The solution aims to help developers port their JavaME applications into Android automatically without any single code change, only by making a small modification in the build scripts. The demo Flyer application already available shows the capabilities of ME4Android to run midlets that use the low level user interface API.

ME4Android sample
Sample Flyer application running on Android

We asked Carlos on full JavaME support for Android and he told us in email “right now ME4Android does not support a complete JavaME stack but in the long run it will, specially when the source code becomes available.”

The good news is that ME4Android will be open sourced with Android, Carlos confirmed to OHM “Since Android will eventually be fully open sourced, I intend to do the same with ME4Android. Actually as soon as Google releases all of their source code, I’ll do the same.”

When asked about Esmertec solution, he told us “I am familiar with Esmertec Jbed and given the fact that it will bean optional commercial component on the free Android platform, you can guarantee that it will not be used much and will never have 100% deployment on Android. ME4Android as a free alternative with complete source code available has absolutely no barriers for adoption and provides the best bridge for JavaME developers to take to Android.”

ME4Android could be the solution for JavaME developers looking for a quick way to get their application running on Android at low cost. Actually they can continue to develop on their own platforms, then just wait for full JavaME support using ME4Android from Poliplus or Jbed from Esmertec. Handset Manufacturers will have to decide on this.

Popularity: 19%

Comments (1)

Tags: , , , , ,

Running C++ Native Applications on Android, The Final Point

Posted on 22 November 2007 by Hatem Ben Yacoub

C++ programmingWith the launch of Android mobile platform, Google announced that developers can use Java as programming language to create applications for the platform and using Dalvik as the Java virtual machine. The choice of Java was itself a limitation for many developers, especially low level progammers used to deal directly with different mobile hardware issues…

It’s true that, for example, Symbian support programming in C++, but here is the full and real situation. There is a lot of application developed for Symbian, but you have to always compile your application for the different platforms separately. Applications for Symbian 3rd edition don’t run on 2nd, or 1st edition devices. Sometimes applications for S60 3rd edition are compatible with N73, but not with N80, while it should be the same operating system and there is no reason for an application to be hardware dependant.

Now back to Android, the fact is only Java language is supported doesn’t mean that you cannot develop applications in other languages. This have been proved by many developers, hackers and experts in application development for mobile. The guys at Elements Interactive B.V., the company behind Edgelib library, succeeded to run native C++ applications on the Android platform, even that at this time there is still many issues on display and sound … etc. This include the S-Tris2 game and a 3D animation demo of Edgelib.

Wouter ten Brink, Elements Interactive CTO, told us by email “As our company focuses on native (C++) development only, we will keep looking for solutions to bring native applications to Android.”. He added “Personally, I believe Google will eventually offer a way to run native code, but we’ll have to see what will happen on this area the coming months.”

Performance Vs Portability

It’s clear that Google, by making Dalvik the Java Virtual Machine for Android, is looking for maximum portability against performance. The MSM chipsets, currently supported by Android, include a Java hardware acceleration, which is supposed to provide high performance for Java applications running on Android Handsets. But it’s not everything.

The Google answer on running C/C++ applications on Android from the FAQs is : “No. Android applications are written using the Java programming language”. Very simple answer, but the problem here is for developers and companies having ready to use code and applications for other mobile platform and looking to get their code ported to Android at low cost.

Java-Not-In-Time and JIT

The performance issue in reality isn’t due to Java itself, but to the virtual machine running Java code on mobile devices. You can run Java very fastly on PCs today with JIT VMs, thing not available for mobile devices, which make Java applications and games very slow on mobile. So what about Dalvik ? Dan Morrill posted on the Android developers group that “a just-in-time compiler is definitely on the Dalvik roadmap”.

This should answer the performance question about Java, Android and Dalvik, even that we don’t know much at this time on the Dalvik VM.

Conclusion

Finally the choice of Java on Android is to make mobile application developement faster and easier for developers, and to make Android platform more stable. Probably many don’t agree on coding in Java for Android and looking for native support. This could solve some problems for native developers, but will open the door for a huge new problems and incompatibilities. If Google decided to make Android the best open mobile platform, it’s also their choice to keep this platform safe for a better future.

Popularity: 44%

Comments (1)

Advertise Here
Advertise Here
Close
E-mail It