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 http://developer.android.com/guide/google/index.html.  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

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.

	BIRT	JasperReports
Target	Built with rich internet applications in mind (vs paper reports)	Pixel perfect reports and web-based ones, but anyway for paper reports mainly
Designer	Plug-in for Eclipse. Preconfigured Eclipse for BIRT with the plug-in available	Jasper iReport Designer
Designer performance	Faster than JasperReports one	Slow, especially when working with images. Designer freezes.
Designer bugs/errors	Present, 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).	Present, 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.
Designer from the user perspective	User friendly, and intuitive. If you know some web technologies or markup languages it will be easier to understand how to use it.	Non-intuitive, very complex. Lots of features that give you the opportunity to control every part of the report, practically at any time of the generation.
Tutorials and support	Mainly on the web, as videos or written ones. Community is always growing.	Documentation 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.
Reports construction	One 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	Master report and sub-reports. Sub-reports can be created separately, and included in the master report as references.
Adaptation to screen size	HTML based reports adapt themselves as HTML page adapt to the screen, practically no difference	Limited adaptation, basically scaling.
Report generation process	Write the report, and run it. That’s it.	Compilation 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.
Portrait and landscape reports	Supported	Supported, 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.
Grouping data	Supported, 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)	Supported, 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.
Scripting and programming	JavaScript 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.	Java. Debugging in Java, but limited, because in Java you mainly compile, fill and export the reports.
Newspaper layouts	Not supported	Supported
Formatting and styles	CSS 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.	Proprietary. Allows you to change practically anything, and works well.
Positioning of items inside the report	Supports 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.	Pixel-perfect, indents and margins only in pixels.
Data sources/ multiple data sources	Easy integration of multiple data sources, as 1-2-3. Create data source, create dataset and bind to it, and that’s it.	Nightmare. 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. Each sub-report will have its own data source connection.
Shape drawing	Not supported. Just images	Yes. There is a palette with predefined shapes like lines, circles etc. Very useful. But obviously this works only for PDF output.
Export formats	Many. 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.
PNG support	YES	NO, so no transparency
Xpath support	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.
Resources integration, like images for instance	Yes, easy.	Hard. Dynamic images for example must be passed as parameters from Java code.
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.
Conclusion	User 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	Non-intuitive 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.

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.