Android Development: Tricky Tasks — Native Solutions

 
By Sibers Android Team Leader Sergey Kiryukhin

If you want to develop an Android application, chances are you will be advised to use NDK. So, what exactly is this modern tool, and why do so many developers recommend it? This article will answer these questions, as well as explain the differences between using NDK and Java. You will gain a clear understanding of the advantages and disadvantages of NDK, as well as for what purposes NDK is recommended and for what purposes it is not recommended.

NDK (Native Development Kit) is a type of technology that is used to develop Android app components by using so-called “native language”. In many cases, Android applications that are written in Java have low productivity. When developing using Java, you will be able to use just 24 Mb of RAM, whereas developing with NDK will give you more than 24 Mb, thus increasing efficiency. In addition, by using NDK you will also have a greater increment of process execution speed.

Another handy feature of NDK is the option to use many native libraries. Since you can use various ready solutions for your project (e.g., a library which completes math tasks), the overall time for development decreases.

You must be aware of the fact that NDK cannot be the sole technology for development. You will have to use another platform as well due to some of the disadvantages of NDK. For example, NDK makes it impossible to work with events (keyboard, touchscreen or accelerometer) and sounds. For these tasks you should use Java because NDK native libraries can be easily implanted into Java shell.

NDK Advantages

NDK is especially good for tasks when process acceleration is needed, for example, as part of game development where you calculate a game physics engine or AI. These calculations require a lot of RAM despite the fact that the gameplay background itself may require only 3 Mb. Java copes with this work with difficulty, so the majority of games today are developed with NDK (“Angry Birds” for Android is a great example of a program developed with NDK). Sibers developers not only actively use NDK-tools, but also organize workshops based upon this technology for colleagues and interns. This article is a result of one such workshop.

More examples of beneficial usage of NDK include tasks regarding pattern recognition, data encryption and compression, images/video/audio processing, and all actual and modern trends which require a good deal of complicated calculations. It would be quite simple for a PC to perform these tasks, however mobile platforms have limited resources. In fact, Android is a more “convenient” development platform than the iPhone. The iPhone has many limits for potentially dangerous actions (e.g., access to user’s sms, emails, address book, wi-fi signal strength information etc). Thus these dangerous actions could never be legally realized on an iPhone application that needs to be approved by the iTunes App Store. The Android market does not restrict the usage of these actions.

Another nice and important advantage of NDK is the compatibility it has with OpenGL ES 2.X. This technology allows for the creation of more beautiful 3D graphics.

Disadvantages

While NDK improves efficiency in many cases, there are also situations when NDK works like Java, but requires even more development resources than Java. Take, for example, the development of an application with simple calculations and a lot of supplemental information to be displayed using a complicated user interface. Classic examples of this type of application are guide-books and shopping apps. In these cases using Java would be more beneficial, due to its effective tools for easy interface development. “Easy development” means that you save both money and time for your clients.

Interaction with Other Platforms

The use of native language makes porting applications easy, because NDK makes it possible to implement standard native code libraries. These libraries can be used for other iOS platforms development; however they do not simplify porting to Windows Phone 7, Blackberry, or Symbian. You will need to rewrite most of the code in these cases.

Porting C++ desktop apps to Android becomes simpler with NDK, but it does not mean that you can replace the app without any changes. This would be too complicated, slow, and inappropriate for a small screen.

To Sum Up…

You have now seen how the use of NDK helps solve many of the problems with Java, however development with this tool is not always ideal.

NDK should be used for:

• Developing components with complicated calculations (game physics, AI, pattern recognitions, data encryption and compression, images/video/audio processing);
• Making “a clone” of a C++ desktop application for Android.

NDK should not be used for:

• Creating user interfaces;
• Working with bulks of static data.

On Scripting Languages

By Sibers CTO Andrey Gavrilov

Whatever they do, scripting languages all have a big flaw, namely interaction with the parent objects system. It so fell out, I am now scripting a Java application on JavaScript. If you don’t know, Mozilla Rhino is perhaps the strongest realization of script languages under Java. Full concordance to the ECMA standards, stability, optimizations etc. All you need.

As you understand, scripting language (also called an extension language) is used not alone by itself but to control some parent application. It means that it accesses Java classes. And that’s where rock-n-roll begins – some classes exist both in JavaScript and in Java. Like String. And these Strings are very very different Strings.

What comes next? Many methods of these classes match each other. For example there exists a method replace in both “Javas”. But again – these are very very different replaces.

And you know what? The script generates no errors – it just uses the Java’s replace because somewhere before it had used the wrong String. That’s it.

It’s all spiced with the fact that some allotted in API classes are accessed only by JavaScript and use classes of Rhino.

A workaround? Explicit definition of types – everywhere! It helps although it does annoy.

JavaFX Thoughts

By Sibers CTO Andrey Gavrilov

Recently I’ve decided to make a short review of JavaFX which represents another case of a good idea implemented poorly.

The idea behind JavaFX is very simple – developer creates an interface oriented application using some script. Then this application can be launched from a web browser, desktop, or even from J2ME.

First point: JavaFX Mobile.
JavaFX is presented as an interface oriented language, and the interface is exactly the element which is copied with guarantee during its porting to a mobile phone. Why should be an extra extension for J2ME if mobiles have the issues with capacity even without such extensions?

Second point: Competition.
JavaFX functions on the regular Java machine, i.e. user of Windows XP and its higher versions should download full Java-Runtime in order to launch it. Taking its size into account, this is almost impossible to do. Actually it is better than Mozilla XUL, which works only in Mozilla, but worse than Microsoft Silverlight, which realizes absolutely the same ideas as Java FX but on any .NET platform. All these issues put together make JavaFX less suited for work than Adobe AIR, which is a desktop Flash, and can be launched on the web without any problems.

Third point: Extra layer.
JavaFX uses Swing which is launched on Java only. While everything functions stably, it can be used without any problems, but as soon as any errors or issues arise with Silver – all Hell breaks loose. I’ve encountered similar problems during my experiments with Grails.

It’s a pity that JavaFX has these problems because I can’t wait to see a cool Open-Source Flash Killer since I don’t trust any languages with proprietary kernel.

Google Releases Guice – opensource ioc framework

By Anatoly Ivanov, Sibers Java Team Leader

Google again and again proves its high class. It has released a wonderful creation for most projects, especially small and mid-sized.

Evaluate excellent binding api:
binder.bind(Service.class).to(ServiceImpl.class);
Looks like a natural language (in elaboration of hibernate ideas).

The new Guice can perform annotation based dependecy injection (without any xml nightmare (Spring), fast and elegant) and aop (based on aop alliance).

Nevertheless, to be suitable for large projects Guice lacks some useful Hivemind features:

• module organization (which is absent in Spring as well). Modules are very convenient to write utility libraries or to divide the project into parts, and Hivemind finds and picks up modules automatically, which is its certain advantage.
• configurations. Hivemind allows describing the configuration scheme (like xml schema or dtd) and then configurating files in the config file; no parsers, much easier than dtd.

Google doesn’t surprise with configuration through annotations as Hivemind 2 had such a feature as well. Google feature seems to work faster, but it’s not essential as main delays usually appear at the level of making the repository and are negligible compared with the Hibernate initialization.

Summing up, if you ask me, both GWT and Guice cater for novice developers and not very difficult tasks. The tasks are not necessarily simple, but Guice doesn’t seem to be good for writing big repositiries (with more than 100 servers). It is also unilikely to be wide spread in big projects, where Spring seems to prevail. Small and mid-size projects, however, can fully use its advantages as Spring’s and Hivemind’s power is not always necessary and the latter are quite difficult to master.

Liferay: Overcoming Obstacles

By Anatoly Ivanov, Sibers Java Team Leader

Liferay Portal, which we have already announced and are using for our Java projects, as any application presents certain difficulties, which you may have encountered. Interested in our practices on how to make it work correct? This is what I come up with.

1. Filters
Portlet container should completely emulate servlet container work, namely wrap each request with filters. In fact, it initializes servlet filters, but only one in two or even more is activated each time (without noticeable regularity). It is due to the transaction per request approach, where the beginning of every request starts a transaction with the base and when the request is over, the transaction commits in the absence of any exceptions. Such an approach allows canceling any changes in the base during the current request (for example, in case of exceptions) as the portlet didn’t fix them and the database didn’t update with conflicts in different requests. Besides, without filters updating work with hibernate in the portlet, the session regularly failed.

Way out: Using subproject apache bridges (portlet filters) with working filters for the portlet. The problem is that portlet specification makes no provision for such filters on the supposition of servlet filters working correctly.

2. Myfaces bugs
The library is not fully debugged and sometimes digresses of the JSF specification, which results in time consuming looking for ways to do without bugs or changing to new library versions.

3. Debugging
Debugging under Liferay is quite awkward as it takes much time to start or shutdown the server, redeploy it, etc. Debugger can’t get involved and the search for problems is quite a task.

4. Liferay bugs
Liferay itself is not free of bugs. For instance, it doesn’t always form application classpath correctly, which leads to its malfunctioning. Sometimes Liferay goes into mysterious loops.

5. Changing library versions
This change may cause fall of jobsites because of the library’s bugs or its conflicts with other libraries.

6. JFS Porting
JFS porting for the portal is still an experimental area. As Lifray doesn’t provide standard compatibility means and portlet and JFS have different life cycles, an interlayer is essential for correct work.

Way out: In order to launch our JFS project under Liferay Portal, we are using an exterior project Tomahawk Bridge (http://palab.blogspot.com/) and its library. After lowering the version of myfaces-core till 1.1.4.1 there appeared some bugs in representation and navigation. However, developers are aware of these problems and are working on compatibility. In general, Liferay is starting to develop towards JFS compatibility.

Moreover, with JFS specifications satisfied, the project can work almost anywhere and be independent on the container. In our case JFS can be debugged in the frameworks of Tomahawk, which minimizes the time.

We are migrating!!! From JBoss to Liferay

No, no we do not move our office anywhere and don’t immigrate. Siberian woods in front of our office windows are too beautiful site to move from and the bears we usually feed on our way to work, would feel too lonely without us.

Our Java development team simply decided to choose Liferay Portal over JBoss Portal for our Java projects and thus we migrate our current projects. We came up with this decision for the following reasons:

1. New technologies support. This is one of the essential issues in choosing enterprise portals. Such popular new technologies as AJAX and Java Server Faces are better supported by Liferay portal since JBoss support of these two technologies is in the process of testing

2. Cross-platform support. Unlike JBoss, supported by any OS that runs JVM, Liferay does not have such limitation and is supported by any OS

3. Architecture. Organization structure in Liferay provides easier control over the tasks that users could perform.
    

4. Additional portlets. The number and variety of portlets used in Liferay is much larger than JBoss portlets.

5. Configuration. In order to configure Liferay you don’t have to edit its configuration file as you do while configuring JBoss.

So from now on Liferay becomes our favorite enterprise portal making life easier for you and for our development team as well!