Sunday, November 25, 2012

Android Development Capabilities Presentation

In the very very far September 2012 I was asked by a colleague to create a little presentation on Android, in order to give him an overview what Android is capable of.
My experience with Android is not so big, but even so, I managed to create an abstract of the Android API Guide pages available at  The feedback was good, and I was asked to share the presentation. Even if the presentation requires an animator, it can be useful for those ones who never touched Android Development. It includes the following points:

General presentation
Activities and UI
Services, Content providers, Broadcast receivers, Loaders
Settings and Data storage
Tasks, back-stack, processes and threading
Location and Device administration API

I did not include in this presentation such thing like JNI interaction, description of existing Google services. Please treat this as an abstract to the API pages, and no more. If someone will have some ideas or requests, please comment. Hope this will be helpful!

Android Development Capabilities Presentation

Saturday, March 31, 2012

BIRT vs JasperReports comparison

Recently I had the task to do the same report in BIRT and in JasperReports, to understand what are the limits of the report engines and to be able to make a choice between them, for future use of the one of them in a project.

I would like to mention that I never used any reporting engine before, so at the end of this task I made some conclusions that I would like to share with others, conclusions based on three weeks time of using these engines.




with rich internet applications in mind (vs paper reports)

perfect reports and web-based ones, but anyway for paper reports


for Eclipse. Preconfigured Eclipse for BIRT with the plug-in

iReport Designer


than JasperReports one

especially when working with images. Designer freezes.


but not as many as in the case of JasperReports. Designer
bugs/errors harder to correct in XML due to the fact that a lot of
XML generated (like in the case of a HTML page).

more than in the case of BIRT, but easier to correct in XML. (For
example changes in the UI that are not registered in the report,
or that at an instant of time does not affect the report). Closing
and opening the report solves the problem.

from the user perspective

friendly, and intuitive. If you know some web technologies or
markup languages it will be easier to understand how to use it.

very complex. Lots of features that give you the opportunity to
control every part of the report, practically at any time of the

and support

on the web, as videos or written ones. Community is always

present, but does not always is sufficient. Lots of report
examples included in the distribution of the JasperReports engine,
but it might be difficult to understand how to achieve the same
results as in the examples, because one little property in the
designer can make a big difference on the output.


single report in which you put all you want. Even there some
pretend that BIRT has the sub-report logic, I didn’t find it
so obvious as in the case of JasperReports

report and sub-reports. Sub-reports can be created separately, and
included in the master report as references.

to screen size

based reports adapt themselves as HTML page adapt to the screen,
practically no difference

adaptation, basically scaling.

generation process

the report, and run it. That’s it.

of the reports in Java-byte-code, after that these reports can be
filled with data, and in the end exported in the desired format.

and landscape reports


but not in the same report. If you need both landscape and
portrait pages in your report, you must create sub-reports and
merge them after with some third-party software.


but you cannot group already grouped data (In the case of nested
groups, like in JasperReports, or I didn’t find the solution
how to do this)

and works very well. Nested groups allow you to create groups on
already grouped data. Limitation: data must be sorted already for
the grouping to work.

and programming

and Java. Can be used at the same time. Debugging is a bit
difficult to configure. Does not always work, and you need to
delete the debug configuration and to recreate it to work again.

Debugging in Java, but limited, because in Java you mainly
compile, fill and export the reports.




and styles

based, but not full CSS support. No inheritance present for
styles, so you cannot create styles that inherit. Obviously CSS
inheritance logic is applied (if a style is applied to a child,
then it overrides the style of the parent, even the parameters
that you didn’t specify for the child), but this in some
cases might lead to copy-paste code for styles.

Allows you to change practically anything, and works well.

of items inside the report

indents in practically any known units (mm, %, pixels etc.).
Absolute positionning works only for HTML output. You cannot
overlap items, the only way to do that is to use negavite margins,
but as the report is generated from top to bottom, from left to
right, this might not work.

indents and margins only in pixels.

sources/ multiple data sources

integration of multiple data sources, as 1-2-3. Create data
source, create dataset and bind to it, and that’s it.

If you need to use multiple data sources in your report, think
very well before choosing Jasper. Multiple data sources must be
passed from Java, and passed as parameters to sub-reports. Also,
even if your master report does not use any data source, or other
root sub-report, then you must specify at least JREmptyDataSource,
because otherwise the sub-reports will not be able to use the data
source at all. True for DB connections, XML data sources etc.
sub-report will have its own data source connection


supported. Just images

There is a palette with predefined shapes like lines, circles etc.
Very useful. But obviously this works only for PDF output.


Exporting to PDF and HTML give different results for both report
engines, so if you want multiple export choices to be supported,
you must test every option. Exporting to other format types
results in a “WTF is this?” when you see the results.



so no transparency


YES, but not full xPath supported. For example “/root/volumes[id='1']” does not give any results. Birt Xml  driver
supports only attribute filters

YES, full.

integration, like images for instance


Dynamic images for example must be passed as parameters from Java

Integration of other PDF files into the generated report

Not supported. Suggested tools: iText, and only after generation

Not supported. Suggested tools: iText, and only after generation.


friendly, easy to use, especially if you know some on web
technologies. Community is growing constantly and new features are
added. Sometimes the reports do not look like you want them to
look, even if theoretically they should. To design such reports
you must know some Java and JavaScript. Creation time is at least
1.5x faster than in the case of JasperReports. Even with all drawbacks, I would go with BIRT

and very complex designer, but allows a very fine control over the
process of generation of the report. PDF reports look exactly as
you designed them (In comparison with BIRT). No need to know any
programming language, reports can be created fully in the
designer. Creation time of the reports needs at least 1.5x more
time than in the case of BIRT (From my experience, not knowing any
of these engines)

If anyone has some suggestions, or I made a mistake somewhere, please contact me ;)
Hope this will be useful for someone!

P.S. This comparison was make in Q1 2012.

Monday, February 6, 2012

Christian de Cambiaire's explorer software using JMonkeyEngine 3

Last year I obtained my master degree in Informational Technology, Audio-Video and Imaging at INP Toulouse, ENSEEIHT. Right after the presentation of my master work (which, by the way, I posted on this blog, the video), I had an offer to work during the summer on a project for a french painter Christian de Cambiaire.

Christian de Cambiaire is an artist that uses a software, created in 2002 on his initiative, to generate random images by moving some rectangles on a Panel using java.awt.Graphics. The software was getting old, and Christian wanted to make some improvements on it, especially to add the third dimension.

Christian addressed himself to my master degree research director, Jean-Pierre Jessel, who gave me the opportunity to participate to.

At the beginning, my task was to do a research on the possible solutions to add a third dimension to a Java 2D software. The main problem was that the software was pretty simple, apart from the specific movement logic of the rectangles on the screen. All the movements were done using mathematical equations implemented by hand.

The first idea was to use OpenGL and C++, but because the original software was in Java, I thought it will be smarter to search for something in Java, and anyway, in C++ it would have been more difficult. After some research, I ended with the conclusion that JMonkeyEngine 3 is the best game engine I can use to achieve what I want. I stopped myself to a game engine because it can speed up development time and introduce new possibilities for improvements of the software based on the JME3 SDK, and in my case this was what I needed.

Below are the videos of the two versions of Explorer software. First one is the video of the old 2D version, and below it is the one that I created in 3D. If you're interested in the software, feel free to contact Christian de Cambiaire.

The old 2D version:

The 3D version created by me for Christian de Cambiaire and in collaboration with Jean-Pierre Jessel, in JME3:

The software is using JME3, java swing, and can be run in fullscreen. Has also a debug mode, in which you can check FPS, and supports command line arguments to launch automatically from CD, when inserted into CD-ROM.

For any information on the software please contact Christian de Cambiaire, because he's the copyright holder.