Re: [xmlvm-dev] Generating Java iOS API

[Aaron V. <gru...@gm...>]

Wow, that's brilliant work!  This is a great direction to be moving in.

I took a quick look and had a few comments:

----------------------------------
UIColor.java:
	/**
	 * - (UIColor *)initWithHue:(CGFloat)hue
saturation:(CGFloat)saturation brightness:(CGFloat)brightness
alpha:(CGFloat)alpha;
	 * - (UIColor *)initWithRed:(CGFloat)red green:(CGFloat)green
blue:(CGFloat)blue alpha:(CGFloat)alpha;
	 */
	public UIColor(float arg1, float arg2, float arg3, float arg4,
UIColor.Colorspace colorspace) {}

This looks a bit strange to me... it's a ctor that maps to two objc
methods.  So apparently the inner enum colorspace is automatically
generated just for the purpose of distinguishing these constructors?

I think it would make more sense to have the generated colorspace
parameter be the first parameter rather than the last.

----------------------------------
CGFont.java:
	/**
	 * bool CGFontGetGlyphBBoxes(CGFontRef font, const CGGlyph glyphs[],
size_t count, CGRect bboxes[]) ;
	 */
	public boolean getGlyphBBoxes(short[] glyphs, int count,
Reference<CGRect> bboxes)

The mapping from CGRect[] to Reference<CGRect> at first glance didn't
seem correct, but inspecting Reference.java that it is basically a
stripped down type of List.  Could we use array or ArrayLists instead
of making a new container class?  If not, could Reference be renamed
to make it clear that it represents an array of values rather than a
single value.  Although I see that both "const SomeType arg[]" and
"const SomeType* arg" are translated to "References<SomeType>", since
they are functionally identical in C, but are semantically different.
(There are many instances of this.)

----------------------------------
Constant values are missing, for example
CGContext.java:
	/**
	 * void CGContextSetLineJoin(CGContextRef c, CGLineJoin join) ;
	 */
	public void setLineJoin(int join)

The CGLineJoin constants (kCGLineJoinMiter, kCGLineJoinRound,
kCGLineJoinBevel) are not defined anywhere.  These are defined in
CGContext.h as enum CGLineJoin.  I don't know what all the
implications are, but if this could be made into a Java enum instead
of converting it to int, I think that would be great.  (There are many
other such enums.)

----------------------------------
CGContext.java:
	/**
	 * void CGContextSelectFont(CGContextRef c, const char *name, CGFloat
size, CGTextEncoding textEncoding) ;
	 */
	public void selectFont(byte[] name, float size, int textEncoding)

I'd really like to see (const char*) parameters changed to String
instead of byte[], although I wonder if it will be possible to do this
conversion automatically in the C wrappers in a way that will work in
all cases.  (There are many instances of this.)

----------------------------------
UIKit.java:
	/**
	 * CGContextRef UIGraphicsGetCurrentContext(void);
	 */
	public static CGContext UIGraphicsGetCurrentContext()

I was expecting this to be UIGraphics.getCurrentContext(), rather than
UIKit.UIGraphicsGetCurrentContext().  But this was discussed
previously on the list, and the size of the UIKit grouping seems good
(not too large).  So for this I would just want to make sure there is
some clear documentation about where to find methods like this.

Cheers,
--Aaron V.

On Sun, Oct 9, 2011 at 4:33 PM, Arno Puder <ar...@pu...> wrote:
>
> Guys,
>
> as some of you already know, we are working on the automatic generation
> of the Java iOS API. So far, the generation of the API is a manual
> process. Needless to say that this process is sometimes inconsistent,
> error prone and does not scale. Currently XMLVM only supports a fraction
> of the complete iOS API.
>
> Generating the Java iOS API will be a quantum leap for XMLVM. Once we
> accomplish this, XMLVM will support 100% of the iOS API. There are two
> steps to this process: (1) generating the Java API and (2) generating
> the matching C wrappers. Panayotis has just completed the first version
> of a tool for (1). Those of you who have knowledge of the iOS API - both
> Java and Objective-C - are welcomed to take a look at the generated API.
> You can do so with the following instructions:
>
> git clone https://code.google.com/p/crossmobile/
> cd crossmobile/src/xmbuild
> ant skeleton
>
> Make sure that iOS SDK 4.3 is installed. Under the folder
> build/skeleton/src you can find the produced Java files. Please take a
> look at the generated Java files and send comments/questions/suggestions
> to this mailing list.
>
> Once we have settled on the Java API, we will work on part (2):
> automatically generating the C wrappers.
>
> Thanks to Panayotis for writing a parser tool to generate the Java API.
>
> Arno
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>