xmlvm-users — For current and interested XMLVM users, for public discussions and anouncements.

Re: [xmlvm-users] SecureTextEntry...

[Arno P. <ar...@pu...>]

that is certainly true: unlike Xcode, the Java emulator allows you to 
develop on platforms other than Mac OS. Doing 'simplified' 
implementations of the UI widgets is also sensible. Well, hopefully 
someone has the calling to work on that.  :-)

Arno


On 5/23/10 7:02 PM, George Smith wrote:
>
> One of the important (to me and my partners) features of XMLVM was the
> ability to "mostly" develop an App for the iPhone/iPad on a developer's
> existing systems (be they Mac, Linux, or even Windows).  IMO, this does NOT
> mean that every Cocoa/Objective-C widget/class must have a fully functioning
> and UI simulating Java Emulator stand-in, but that there should be a
> marginally UI functional API conformant stand-in.  An example might be a
> Spin-Picker in Cocoa that renders as an appropriately sized and placed
> colored box, with JTextField or JComboBox in it.
>
> My $0.02, George Smith
>
> -----Original Message-----
> From: Arno Puder [mailto:ar...@pu...]
> Sent: Sunday, May 23, 2010 9:36 AM
> To: xml...@li...
> Subject: Re: [xmlvm-users] SecureTextEntry...
>
>
>
> On 5/23/10 6:11 PM, Adrian Buerki wrote:
>> There is a property secureTextEntry in the class UITextField. Seems
>> like that is the password field support I was looking for. However
>> this does not work in the iPhone Java emulator. I assume the problem
>> is just in the emulator, once cross compiled the text field would
>> behave correctly?
>
> the Objective-C side does what it is supposed to do. This feature is not
> implemented in the Java emulator, as you have noticed.
>
> That feature is easy to implement in the Java emulator and your patch is
> most certainly welcome. However, the question remains how far to push
> our Java emulator. The problem is that there are many very unique UI
> widgets in the iPhone SDK and it would mean a lot of work to provide a
> Java implementation. All of the new widgets Panayotis has implemented
> are only available on the Objective-C side. If someone feels the urge to
> do a Java version, what would certainly be nice.
>
> A few weeks ago I proposed a debugging architecture for XMLVM. The
> benefit of the proposal would be that we can leverage Apple's own iPhone
> emulator (or even the actual device) and there would be no need for our
> Java emulator. I still hope to do that one day.
>
> Arno
>
> ----------------------------------------------------------------------------
> --
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] SecureTextEntry...

[Arno P. <ar...@pu...>]

On 5/23/10 6:11 PM, Adrian Buerki wrote:
> There is a property secureTextEntry in the class UITextField. Seems
> like that is the password field support I was looking for. However
> this does not work in the iPhone Java emulator. I assume the problem
> is just in the emulator, once cross compiled the text field would
> behave correctly?

the Objective-C side does what it is supposed to do. This feature is not 
implemented in the Java emulator, as you have noticed.

That feature is easy to implement in the Java emulator and your patch is 
most certainly welcome. However, the question remains how far to push 
our Java emulator. The problem is that there are many very unique UI 
widgets in the iPhone SDK and it would mean a lot of work to provide a 
Java implementation. All of the new widgets Panayotis has implemented 
are only available on the Objective-C side. If someone feels the urge to 
do a Java version, what would certainly be nice.

A few weeks ago I proposed a debugging architecture for XMLVM. The 
benefit of the proposal would be that we can leverage Apple's own iPhone 
emulator (or even the actual device) and there would be no need for our 
Java emulator. I still hope to do that one day.

Arno

Re: [xmlvm-users] Apple agreements

[Ilya L. <ily...@gm...>]

since we're talking sensible, one feels it would not be out of place to
remark that it would also behoove the participants to retain -- on a public
mailing list -- a basic level of courtesy in their posts. there is an
unfortunate tendency in electronic communication to allow one's passion to
spill on the screen where it would be kept in check during a face-to-face
interaction. this tendency is further aggravated by the absence of cues such
as tone and body language -- particularly if one is averse to emoticons --
to indicate subtleties of meaning (e.g. sarcasm), which contributes to
private misconstruction of what is said (e.g. over-reaching,
hyper-controlling corporations = "paranoid 'evil corporation' stuff"). all
that brings us back to the indeed very sensible call to restrict the forum
to technical questions not likely to cause discord and contention.

On Sun, May 23, 2010 at 4:38 AM, Tor Lillqvist <tm...@ik...> wrote:

> > sounds like there might be another worthy project here -- cleaning up
> > tool-generated code to make it look man-made so as to avoid detection by
> > over-reaching, hyper-controlling corporations.
>
> Is it sensible to discuss on a public mailing list how to
> intentionally mislead one's contract partner? On the contrary, if one
> wants to show that Apple's fears are unfounded, shouldn't one be
> perfectly open about the technology used for a produce a well working
> and behaving iPhone app? (Like XMLVM is with Xokoban, for instance.)
>
> Also, please spare us the paranoid "evil corporation" stuff. Remember,
> nobody is forcing you to agree with Apple's terms. There are other
> equally over-reaching hyper-controlling corporations that have
> competing mobile device application markets with less restrictive
> terms.
>
> --tml
>

[xmlvm-users] SecureTextEntry...

[Adrian B. <kil...@gm...>]

Hey guys

There is a property secureTextEntry in the class UITextField. Seems
like that is the password field support I was looking for. However
this does not work in the iPhone Java emulator. I assume the problem
is just in the emulator, once cross compiled the text field would
behave correctly?

I have a fix for the
org.xmlvm.iphone.internal.renderer.UITextFieldRenderer class. If my
assumption I right and that is all to be done, I'd be happy to send a
patch. If the Objective-C part has to be touched, I need some pointers
to where to look at...

Regards, Adrian

Re: [xmlvm-users] Latest version of XMLVM

[Jochen H. <jo....@go...>]

Hi all,

I just checked out trunk of the XMLVM project, build the project and
samples, and started the Xcode project (with Xcode 3.2.1) of Xokoban.
Everything worked fine without any problems.

Kudos to the project and Panayotis to this excellent integration.

Bye, Jochen

On Sat, May 22, 2010 at 12:09 PM, Arno Puder <ar...@pu...> wrote:

>
> very nice work, Panayotis!  :-)
>
> On 5/22/10 11:58 AM, Panayotis Katsaloulis wrote:
> > Hello all!
> >
> > You might have seen that  a patch of mine was just committed to the xmlvm
> source tree.
> > I am very excited about it, since it's a work of months and I believe
> that this makes xmlvm a competitive tool to write native iPhone
> applications, with other not open source projects, as Mono touch.
> >
> > Here is a brief list of what it provides:
> >
> > a) Improved creating of XCode project - only one target exists
> "xproject". Target "xrebuild" not needed any more.
> >
> > b) Compiling of XCode project is much faster - only changed files will be
> recompiled
> >
> > c) Comma separated list of libraries are supported, for the argument
> "--lib",  when creating project files. If a specific default library is not
> required, a minus "-" prefix will remove it. A plus "+" prefix  will add it.
> If no prefix is present, then this has the same effect as a plus.
> >
> > d) Colon or semicolon (depending of the operating system) separated list
> of resource files and directories, for the argument "--resource". Also minus
> and plus prefix is supported, like with argument "--lib"
> >
> > e) Give extra parameters (non specific) for project creation with the
> "-Dkey=value" argument. Parameters that handle various project options, such
> as the name of the project, version, identifier, pre-render icon and hidden
> status bar are defined.
> >
> > f) AppStore XCode target is added, optimized for App Store submission.
> Also other targets have extra optimization flags.
> >
> > g) Use of nbproject/xcode.properties file to give specific properties to
> ant build scripts of xcode projects
> >
> > h) Added missing classes: CAAction, CAAnimation, CAMediaTiming,
> CATransition, MFMailComposeResult, MFMailComposeViewController,
> MFMailComposeViewControllerDelegate, MPMovieControlMode,
> MPMoviePlayerController, MPMovieScalingMode, NSCalendar, NSCalendarUnit,
> NSDate, NSDateComponents, NSFileManager, NSLocale, NSNumberFormatter,
> NSNumberFormatterStyle, NSRange, NSStringEncoding, NSTimeZone,
> UIActionSheet, UIActionSheetDelegate, UIDatePicker, UIDatePickerMode,
> UIKeyboardAppearance, UIKeyboardType, UIPageControl, UIReturnKeyType,
> UIScrollViewDelegate, UISearchBar, UISearchBarDelegate, UIStatusBarStyle,
> UITableViewCellEditingStyle, UITableViewCellSeparatorStyle,
> UITableViewCellStyle, UITableViewRowAnimation, UITextAutocapitalizationType,
> UITextAutocorrectionType, UITextFieldDelegate, UIViewAnimationCurve,
> UIViewAnimationDelegate, UIViewAnimationTransition,
> OptionalSelectorException, UIPageControlRenderer, UISearchBarRenderer
> >
> > i) Added missing features in many classes, especially in: NSData,
> NSString, UIApplication, UIButton, UIImage, UILabel, UIPickerViewDelegate,
> UIScrollView, UISegmentedControl, UITableView, UITableViewController,
> UITableViewDataSource, UITableViewDelegate, UITextField, UITextView, UIView,
> UIViewController, UIWebView, UIWindow,
> >
> > j) All iPhone compatibility objects inherit from NSObject. It is possible
> from Java to retain/release an object or add code to it's dealloc selector.
> >
> > k) Animations added
> >
> > l) Safer memory management with introduction of associations, property
> returning macros and setting of null to returning variables
> >
> > m) Implementing a mechanism of optional methods in delegates (see
> org.xmlvm.iphone.internal.OptionalSelectorException), for use only in
> simulator
> >
> > n) fix a UIControlDelegate error - old code will break.
> >
> > o) Other additions and bug fixes
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Apple agreements

[Arno P. <ar...@pu...>]

I agree. This list should focus on technical discussions around XMLVM 
and not Apple's business practices. I myself am an academic and my 
interest is to create new concepts and push the envelope of technology. 
As a variation of Tor's words: no one forces you to use XMLVM. I wish 
someone would comment on the amazing work that Panayotis has contributed 
this weekend.

Arno


On 5/23/10 10:38 AM, Tor Lillqvist wrote:
>> sounds like there might be another worthy project here -- cleaning up
>> tool-generated code to make it look man-made so as to avoid detection by
>> over-reaching, hyper-controlling corporations.
>
> Is it sensible to discuss on a public mailing list how to
> intentionally mislead one's contract partner? On the contrary, if one
> wants to show that Apple's fears are unfounded, shouldn't one be
> perfectly open about the technology used for a produce a well working
> and behaving iPhone app? (Like XMLVM is with Xokoban, for instance.)
>
> Also, please spare us the paranoid "evil corporation" stuff. Remember,
> nobody is forcing you to agree with Apple's terms. There are other
> equally over-reaching hyper-controlling corporations that have
> competing mobile device application markets with less restrictive
> terms.
>
> --tml
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Apple agreements

[Tor L. <tm...@ik...>]

> sounds like there might be another worthy project here -- cleaning up
> tool-generated code to make it look man-made so as to avoid detection by
> over-reaching, hyper-controlling corporations.

Is it sensible to discuss on a public mailing list how to
intentionally mislead one's contract partner? On the contrary, if one
wants to show that Apple's fears are unfounded, shouldn't one be
perfectly open about the technology used for a produce a well working
and behaving iPhone app? (Like XMLVM is with Xokoban, for instance.)

Also, please spare us the paranoid "evil corporation" stuff. Remember,
nobody is forcing you to agree with Apple's terms. There are other
equally over-reaching hyper-controlling corporations that have
competing mobile device application markets with less restrictive
terms.

--tml

Re: [xmlvm-users] Apple agreements

[Arno P. <ar...@pu...>]

as a matter of fact, we will soon add an optimizing post-processor to 
XMLVM. Of course, its intention is purely for optimizing purposes, but 
as a nice side effect, it will be *a lot* more difficult to detect that 
the application was created by XMLVM.

Now as Tor pointed out, what men can do, men can undo (of course the 
same is true for women). The question is, how much effort will Apple put 
into detecting such usages. My belief is: none at all! With the fear, 
uncertainty, and doubt they have been spreading with section 3.3.1, 
Apple effectively killed commercial products such as Adobe's CS5 or 
Novell's MonoTouch. XMLVM however is an open source project and it is 
your choice whether you use it or not.

Arno


On 5/23/10 9:34 AM, Ilya Lyashevsky wrote:
> sounds like there might be another worthy project here -- cleaning up
> tool-generated code to make it look man-made so as to avoid detection by
> over-reaching, hyper-controlling corporations.
>
> On Sat, May 22, 2010 at 6:38 PM, Tor Lillqvist <tm...@ik...
> <mailto:tm...@ik...>> wrote:
>
>      > whether it is actually possible for apple to determine if the code
>      > of a submitted app was created using XMLVM or any other tool that
>     outputs
>      > native code.
>
>     Of course it is. To an expert, it shouldn't be hard to recognize
>     patterns in the object code produced from source code generated by
>     XMLVM. (Or other similar tools.) After all, if you look at the
>     Objective-C output by XMLVM, it is easy to recognize. It doesn't look
>     like something a human would write, does it? Sure, an optimising
>     compiler will hide some of that, but still, I would be surprised if it
>     wasn't still recognizable on the object code level.
>
>     --tml
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Apple agreements

[Ilya L. <ily...@gm...>]

sounds like there might be another worthy project here -- cleaning up
tool-generated code to make it look man-made so as to avoid detection by
over-reaching, hyper-controlling corporations.

On Sat, May 22, 2010 at 6:38 PM, Tor Lillqvist <tm...@ik...> wrote:

> > whether it is actually possible for apple to determine if the code
> > of a submitted app was created using XMLVM or any other tool that outputs
> > native code.
>
> Of course it is. To an expert, it shouldn't be hard to recognize
> patterns in the object code produced from source code generated by
> XMLVM. (Or other similar tools.) After all, if you look at the
> Objective-C output by XMLVM, it is easy to recognize. It doesn't look
> like something a human would write, does it? Sure, an optimising
> compiler will hide some of that, but still, I would be surprised if it
> wasn't still recognizable on the object code level.
>
> --tml
>

Re: [xmlvm-users] Apple agreements

[Tor L. <tm...@ik...>]

> whether it is actually possible for apple to determine if the code
> of a submitted app was created using XMLVM or any other tool that outputs
> native code.

Of course it is. To an expert, it shouldn't be hard to recognize
patterns in the object code produced from source code generated by
XMLVM. (Or other similar tools.) After all, if you look at the
Objective-C output by XMLVM, it is easy to recognize. It doesn't look
like something a human would write, does it? Sure, an optimising
compiler will hide some of that, but still, I would be surprised if it
wasn't still recognizable on the object code level.

--tml

Re: [xmlvm-users] Apple agreements

[Arno P. <ar...@pu...>]

I did not call Apple's practices illegal. I was merely pointing out the 
fact that the US justice department is considering an anti trust case 
against Apple. You are perfectly right: Apple can do whatever they want 
with their platform. Its a little sad the way Apple is treating 
developers considering they are contributing to the success of the 
iPhone platform with all these AppStore applications.

However, I will say that just because Apple says so, it doesn't make it 
right. I know for a fact that XMLVM applications are being accepted by 
Apple although the submitters have agreed to the latest SDK license 
agreement (which from my perspective only underlines the fact that 
Apple's argument for poor performance are just a distraction).

I would urge you to read this story:
http://online.wsj.com/article/SB10001424052748704688604575125510326010610.html

Some laws just don't make any sense.

Arno


On 5/22/10 10:20 PM, Mark Wolfskehl wrote:
>>
>> Apple is free to write whatever they want in their license
>> agreement. It
>> is a whole different question whether their license
>> agreement complies
>> with various national laws. There are some stories that
>> Apple may face
>> some antitrust inquiry in the US:
>> http://apple.slashdot.org/story/10/05/03/1952258/Apple-May-Face-Antitrust-Inquiry?art_pos=28
>>
>> What Apple is doing right now is to create FUD (fear,
>> uncertainty,
>> doubt). There is little point to debate what they mean by
>> "originally
>> written in Objective-C". I refuse to even speculate what
>> they might mean
>> by that, because I don't want to succumb to FUD. At this
>> point I am not
>> aware that Apple has rejected any application written with
>> the help of
>> XMLVM. Our own showcase application Xokoban is certainly
>> still in the
>> AppStore:
>> http://itunes.apple.com/us/app/xokoban/id322302746?mt=8
>>
>> Arno
>>
> Hi Arno,
>
> I understand your frustration, as I'm sure Apple's new policy is throwing a whole business model into question.
>
> I don't like the policy myself, but I wouldn't go so far as terming it illegal.  The fact is that Apple is providing a proprietary product, in this case their iPhone SDK, under certain terms.  Nobody is being forced to accept those terms - they are free to walk away and say 'no thanks' to the SDK.
>
> Apple is making a calculation that people will not walk away from the platform.  But if people find that the terms are too onerous, they should walk away and prove Apple wrong.  If they do not, then they are agreeing that the terms are in fact acceptable when considering things overall and they are freely accepting the terms.
>
> So, from my perspective, if developers don't like Apple, then they should vote against them by walking away from their platform.  If not, business is business and since their acceptance means even under the new terms they think they can make money, that's all there is to it.
>
> I myself own an Android phone and not an iPhone.  I'm happy with it, and its open nature and Google's willingness to accept most applications into their store should make it attractive to developers.  So, there is an alternative.
>
> As for XMLVM, I do think it is very interesting just from a technology perspective, and it might not be a bad idea to just apply the technology to a different platform.  There must be businesses out there who would welcome the opportunity for compiled Java on their servers or other infrastructure for added performance - just to throw out an idea.
>
> Personally, I think it would be useful to translate JVM bytecode to .NET to be able to deploy Java  programs on Windows without requiring the user to install the JRE.  I know that's the opposite direction from what has been implemented, but I just wanted to put it out there as a suggestion.
>
> I hope you're able to find a profitable market for XMLVM.  There should be other applications out there, so I'm sure you'll work through it.
>
> Mark
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Apple agreements

[Ilya L. <ily...@gm...>]

i was reluctant to chime in, but it seems to me that one essential question
to ask is whether it is actually possible for apple to determine if the code
of a submitted app was created using XMLVM or any other tool that outputs
native code. at first glance, it seems unlikely to me. in which case it is
largely irrelevant what position apple adopts, especially when it comes to
smaller developers. though of course it could still pose problems for larger
outfits, which run the risk of facing litigation and so on if it violates
apple's license agreement and apple feels the violation is grievous enough
for them to take action.

On Sat, May 22, 2010 at 4:20 PM, Mark Wolfskehl <ma...@ma...> wrote:

> >
> > Apple is free to write whatever they want in their license
> > agreement. It
> > is a whole different question whether their license
> > agreement complies
> > with various national laws. There are some stories that
> > Apple may face
> > some antitrust inquiry in the US:
> >
> http://apple.slashdot.org/story/10/05/03/1952258/Apple-May-Face-Antitrust-Inquiry?art_pos=28
> >
> > What Apple is doing right now is to create FUD (fear,
> > uncertainty,
> > doubt). There is little point to debate what they mean by
> > "originally
> > written in Objective-C". I refuse to even speculate what
> > they might mean
> > by that, because I don't want to succumb to FUD. At this
> > point I am not
> > aware that Apple has rejected any application written with
> > the help of
> > XMLVM. Our own showcase application Xokoban is certainly
> > still in the
> > AppStore:
> > http://itunes.apple.com/us/app/xokoban/id322302746?mt=8
> >
> > Arno
> >
> Hi Arno,
>
> I understand your frustration, as I'm sure Apple's new policy is throwing a
> whole business model into question.
>
> I don't like the policy myself, but I wouldn't go so far as terming it
> illegal.  The fact is that Apple is providing a proprietary product, in this
> case their iPhone SDK, under certain terms.  Nobody is being forced to
> accept those terms - they are free to walk away and say 'no thanks' to the
> SDK.
>
> Apple is making a calculation that people will not walk away from the
> platform.  But if people find that the terms are too onerous, they should
> walk away and prove Apple wrong.  If they do not, then they are agreeing
> that the terms are in fact acceptable when considering things overall and
> they are freely accepting the terms.
>
> So, from my perspective, if developers don't like Apple, then they should
> vote against them by walking away from their platform.  If not, business is
> business and since their acceptance means even under the new terms they
> think they can make money, that's all there is to it.
>
> I myself own an Android phone and not an iPhone.  I'm happy with it, and
> its open nature and Google's willingness to accept most applications into
> their store should make it attractive to developers.  So, there is an
> alternative.
>
> As for XMLVM, I do think it is very interesting just from a technology
> perspective, and it might not be a bad idea to just apply the technology to
> a different platform.  There must be businesses out there who would welcome
> the opportunity for compiled Java on their servers or other infrastructure
> for added performance - just to throw out an idea.
>
> Personally, I think it would be useful to translate JVM bytecode to .NET to
> be able to deploy Java  programs on Windows without requiring the user to
> install the JRE.  I know that's the opposite direction from what has been
> implemented, but I just wanted to put it out there as a suggestion.
>
> I hope you're able to find a profitable market for XMLVM.  There should be
> other applications out there, so I'm sure you'll work through it.
>
> Mark
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Apple agreements

[Mark W. <ma...@ma...>]

> 
> Apple is free to write whatever they want in their license
> agreement. It 
> is a whole different question whether their license
> agreement complies 
> with various national laws. There are some stories that
> Apple may face 
> some antitrust inquiry in the US:
> http://apple.slashdot.org/story/10/05/03/1952258/Apple-May-Face-Antitrust-Inquiry?art_pos=28
> 
> What Apple is doing right now is to create FUD (fear,
> uncertainty, 
> doubt). There is little point to debate what they mean by
> "originally 
> written in Objective-C". I refuse to even speculate what
> they might mean 
> by that, because I don't want to succumb to FUD. At this
> point I am not 
> aware that Apple has rejected any application written with
> the help of 
> XMLVM. Our own showcase application Xokoban is certainly
> still in the 
> AppStore:
> http://itunes.apple.com/us/app/xokoban/id322302746?mt=8
> 
> Arno
> 
Hi Arno,

I understand your frustration, as I'm sure Apple's new policy is throwing a whole business model into question.

I don't like the policy myself, but I wouldn't go so far as terming it illegal.  The fact is that Apple is providing a proprietary product, in this case their iPhone SDK, under certain terms.  Nobody is being forced to accept those terms - they are free to walk away and say 'no thanks' to the SDK.

Apple is making a calculation that people will not walk away from the platform.  But if people find that the terms are too onerous, they should walk away and prove Apple wrong.  If they do not, then they are agreeing that the terms are in fact acceptable when considering things overall and they are freely accepting the terms.

So, from my perspective, if developers don't like Apple, then they should vote against them by walking away from their platform.  If not, business is business and since their acceptance means even under the new terms they think they can make money, that's all there is to it.

I myself own an Android phone and not an iPhone.  I'm happy with it, and its open nature and Google's willingness to accept most applications into their store should make it attractive to developers.  So, there is an alternative.

As for XMLVM, I do think it is very interesting just from a technology perspective, and it might not be a bad idea to just apply the technology to a different platform.  There must be businesses out there who would welcome the opportunity for compiled Java on their servers or other infrastructure for added performance - just to throw out an idea.

Personally, I think it would be useful to translate JVM bytecode to .NET to be able to deploy Java  programs on Windows without requiring the user to install the JRE.  I know that's the opposite direction from what has been implemented, but I just wanted to put it out there as a suggestion.

I hope you're able to find a profitable market for XMLVM.  There should be other applications out there, so I'm sure you'll work through it.

Mark

Re: [xmlvm-users] Latest version of XMLVM

[Arno P. <ar...@pu...>]

very nice work, Panayotis!  :-)

On 5/22/10 11:58 AM, Panayotis Katsaloulis wrote:
> Hello all!
>
> You might have seen that  a patch of mine was just committed to the xmlvm source tree.
> I am very excited about it, since it's a work of months and I believe that this makes xmlvm a competitive tool to write native iPhone applications, with other not open source projects, as Mono touch.
>
> Here is a brief list of what it provides:
>
> a) Improved creating of XCode project - only one target exists "xproject". Target "xrebuild" not needed any more.
>
> b) Compiling of XCode project is much faster - only changed files will be recompiled
>
> c) Comma separated list of libraries are supported, for the argument "--lib",  when creating project files. If a specific default library is not required, a minus "-" prefix will remove it. A plus "+" prefix  will add it. If no prefix is present, then this has the same effect as a plus.
>
> d) Colon or semicolon (depending of the operating system) separated list of resource files and directories, for the argument "--resource". Also minus and plus prefix is supported, like with argument "--lib"
>
> e) Give extra parameters (non specific) for project creation with the "-Dkey=value" argument. Parameters that handle various project options, such as the name of the project, version, identifier, pre-render icon and hidden status bar are defined.
>
> f) AppStore XCode target is added, optimized for App Store submission. Also other targets have extra optimization flags.
>
> g) Use of nbproject/xcode.properties file to give specific properties to ant build scripts of xcode projects
>
> h) Added missing classes: CAAction, CAAnimation, CAMediaTiming, CATransition, MFMailComposeResult, MFMailComposeViewController, MFMailComposeViewControllerDelegate, MPMovieControlMode, MPMoviePlayerController, MPMovieScalingMode, NSCalendar, NSCalendarUnit, NSDate, NSDateComponents, NSFileManager, NSLocale, NSNumberFormatter, NSNumberFormatterStyle, NSRange, NSStringEncoding, NSTimeZone, UIActionSheet, UIActionSheetDelegate, UIDatePicker, UIDatePickerMode, UIKeyboardAppearance, UIKeyboardType, UIPageControl, UIReturnKeyType, UIScrollViewDelegate, UISearchBar, UISearchBarDelegate, UIStatusBarStyle, UITableViewCellEditingStyle, UITableViewCellSeparatorStyle, UITableViewCellStyle, UITableViewRowAnimation, UITextAutocapitalizationType, UITextAutocorrectionType, UITextFieldDelegate, UIViewAnimationCurve, UIViewAnimationDelegate, UIViewAnimationTransition, OptionalSelectorException, UIPageControlRenderer, UISearchBarRenderer
>
> i) Added missing features in many classes, especially in: NSData, NSString, UIApplication, UIButton, UIImage, UILabel, UIPickerViewDelegate, UIScrollView, UISegmentedControl, UITableView, UITableViewController, UITableViewDataSource, UITableViewDelegate, UITextField, UITextView, UIView, UIViewController, UIWebView, UIWindow,
>
> j) All iPhone compatibility objects inherit from NSObject. It is possible from Java to retain/release an object or add code to it's dealloc selector.
>
> k) Animations added
>
> l) Safer memory management with introduction of associations, property returning macros and setting of null to returning variables
>
> m) Implementing a mechanism of optional methods in delegates (see org.xmlvm.iphone.internal.OptionalSelectorException), for use only in simulator
>
> n) fix a UIControlDelegate error - old code will break.
>
> o) Other additions and bug fixes
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] Latest version of XMLVM

[Panayotis K. <pan...@pa...>]

Hello all!

You might have seen that  a patch of mine was just committed to the xmlvm source tree.
I am very excited about it, since it's a work of months and I believe that this makes xmlvm a competitive tool to write native iPhone applications, with other not open source projects, as Mono touch.

Here is a brief list of what it provides:

a) Improved creating of XCode project - only one target exists "xproject". Target "xrebuild" not needed any more.

b) Compiling of XCode project is much faster - only changed files will be recompiled

c) Comma separated list of libraries are supported, for the argument "--lib",  when creating project files. If a specific default library is not required, a minus "-" prefix will remove it. A plus "+" prefix  will add it. If no prefix is present, then this has the same effect as a plus.

d) Colon or semicolon (depending of the operating system) separated list of resource files and directories, for the argument "--resource". Also minus and plus prefix is supported, like with argument "--lib"

e) Give extra parameters (non specific) for project creation with the "-Dkey=value" argument. Parameters that handle various project options, such as the name of the project, version, identifier, pre-render icon and hidden status bar are defined.

f) AppStore XCode target is added, optimized for App Store submission. Also other targets have extra optimization flags.

g) Use of nbproject/xcode.properties file to give specific properties to ant build scripts of xcode projects

h) Added missing classes: CAAction, CAAnimation, CAMediaTiming, CATransition, MFMailComposeResult, MFMailComposeViewController, MFMailComposeViewControllerDelegate, MPMovieControlMode, MPMoviePlayerController, MPMovieScalingMode, NSCalendar, NSCalendarUnit, NSDate, NSDateComponents, NSFileManager, NSLocale, NSNumberFormatter, NSNumberFormatterStyle, NSRange, NSStringEncoding, NSTimeZone, UIActionSheet, UIActionSheetDelegate, UIDatePicker, UIDatePickerMode, UIKeyboardAppearance, UIKeyboardType, UIPageControl, UIReturnKeyType, UIScrollViewDelegate, UISearchBar, UISearchBarDelegate, UIStatusBarStyle, UITableViewCellEditingStyle, UITableViewCellSeparatorStyle, UITableViewCellStyle, UITableViewRowAnimation, UITextAutocapitalizationType, UITextAutocorrectionType, UITextFieldDelegate, UIViewAnimationCurve, UIViewAnimationDelegate, UIViewAnimationTransition, OptionalSelectorException, UIPageControlRenderer, UISearchBarRenderer

i) Added missing features in many classes, especially in: NSData, NSString, UIApplication, UIButton, UIImage, UILabel, UIPickerViewDelegate, UIScrollView, UISegmentedControl, UITableView, UITableViewController, UITableViewDataSource, UITableViewDelegate, UITextField, UITextView, UIView, UIViewController, UIWebView, UIWindow, 

j) All iPhone compatibility objects inherit from NSObject. It is possible from Java to retain/release an object or add code to it's dealloc selector.

k) Animations added

l) Safer memory management with introduction of associations, property returning macros and setting of null to returning variables

m) Implementing a mechanism of optional methods in delegates (see org.xmlvm.iphone.internal.OptionalSelectorException), for use only in simulator

n) fix a UIControlDelegate error - old code will break.

o) Other additions and bug fixes

Re: [xmlvm-users] LGPL / status from Apple?

[Arno P. <ar...@pu...>]

I have been constantly reminding the "Apple guy" whose message I 
forwarded to this list a while ago. He never came back with a 
clarification. I think he went way out of his way of writing that 
message in the first place. Because of the fact that Apple in general 
isn't more specific (apart from some very top-level emails where people 
claim they originate from Steve Jobs himself) I come to the conclusion 
that Apple is exercising FUD. I'm not with Apple; I cannot tell you 
their intentions. If you fall for the FUD, then don't use XMLVM.

Arno


On 5/21/10 2:07 AM, Mark Wolfskehl wrote:
> I agree that the LGPL is the more appropriate license for XMLVM in its current state of development.
>
> Has there been any additional feedback from Apple as to whether they consider XMLVM to be acceptable in terms of their new iPhone SDK licensing agreement and for posting in the app store?
>
> Mark
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] C# to Java

[<len...@gm...>]

Given a C# program how can I convert it to Java source code using XMLVM? Thanks Lennie
Sent via my BlackBerry from Vodacom - let your email find you!

Re: [xmlvm-users] LGPL / status from Apple?

[Mark W. <ma...@ma...>]

I agree that the LGPL is the more appropriate license for XMLVM in its current state of development.

Has there been any additional feedback from Apple as to whether they consider XMLVM to be acceptable in terms of their new iPhone SDK licensing agreement and for posting in the app store?

Mark

Re: [xmlvm-users] will XMLVM comply with appstore for OS4?

[Arno P. <ar...@pu...>]

Apple is free to write whatever they want in their license agreement. It 
is a whole different question whether their license agreement complies 
with various national laws. There are some stories that Apple may face 
some antitrust inquiry in the US:
http://apple.slashdot.org/story/10/05/03/1952258/Apple-May-Face-Antitrust-Inquiry?art_pos=28

What Apple is doing right now is to create FUD (fear, uncertainty, 
doubt). There is little point to debate what they mean by "originally 
written in Objective-C". I refuse to even speculate what they might mean 
by that, because I don't want to succumb to FUD. At this point I am not 
aware that Apple has rejected any application written with the help of 
XMLVM. Our own showcase application Xokoban is certainly still in the 
AppStore:
http://itunes.apple.com/us/app/xokoban/id322302746?mt=8

Arno


On 5/20/10 5:43 PM, Erol Fox wrote:
> The recent change to section 3.3.1 looks directly targeted at projects
> like this.
>
> Will XMLVM apps make it through the app store? Is constant appstore
> compliance a commitment of the project?
>
>
>
> ------------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] will XMLVM comply with appstore for OS4?

[Erol F. <er...@li...>]

The recent change to section 3.3.1 looks directly targeted at projects like
this. 

 

Will XMLVM apps make it through the app store? Is constant appstore
compliance a commitment of the project?

Re: [xmlvm-users] XMLVM goes LGPL

[Gergely K. <ger...@ma...>]

Dear Core Team,

Thank you for this change! I think this new license will ensure the long
term success of XMLVM.

Best Regards,
Gergely

2010/5/20 Arno Puder <ar...@pu...>

>
> Guys,
>
> the XMLVM core team has decided to change the license under which XMLVM
> will be distributed. Starting today we will release all of XMLVM under
> the LGPL license. This means that there is no more need to apply for a
> linking exception and you can use XMLVM in commercial products without
> having to open source your own application. Here is a link explaining
> the terms and conditions of the LGPL:
> http://en.wikipedia.org/wiki/LGPL
>
> In the following days we will change all headers of XMLVM in the code
> repository to reflect the new license. Note that we still require
> contributors to electronically sign the Contributors License Agreement
> (CLA).
>
> We hope that by using a more liberal license for XMLVM we encourage you
> guys to innovate and do great things with XMLVM.
>
> The XMLVM core team
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>



-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

Re: [xmlvm-users] XMLVM goes LGPL

[Panayotis K. <pan...@pa...>]

On May 20, 2010, at 10:25 AM, Arno Puder wrote:

> 
> Guys,
> 
> the XMLVM core team has decided to change the license under which XMLVM 
> will be distributed. Starting today we will release all of XMLVM under 
> the LGPL license. This means that there is no more need to apply for a 
> linking exception and you can use XMLVM in commercial products without 
> having to open source your own application. Here is a link explaining 
> the terms and conditions of the LGPL:
> http://en.wikipedia.org/wiki/LGPL
> 
> In the following days we will change all headers of XMLVM in the code 
> repository to reflect the new license. Note that we still require 
> contributors to electronically sign the Contributors License Agreement 
> (CLA).
> 
> We hope that by using a more liberal license for XMLVM we encourage you 
> guys to innovate and do great things with XMLVM.
> 
> The XMLVM core team



This is good news!
Thank you XMLVM core team!
:D

[xmlvm-users] XMLVM goes LGPL

[Arno P. <ar...@pu...>]

Guys,

the XMLVM core team has decided to change the license under which XMLVM 
will be distributed. Starting today we will release all of XMLVM under 
the LGPL license. This means that there is no more need to apply for a 
linking exception and you can use XMLVM in commercial products without 
having to open source your own application. Here is a link explaining 
the terms and conditions of the LGPL:
http://en.wikipedia.org/wiki/LGPL

In the following days we will change all headers of XMLVM in the code 
repository to reflect the new license. Note that we still require 
contributors to electronically sign the Contributors License Agreement 
(CLA).

We hope that by using a more liberal license for XMLVM we encourage you 
guys to innovate and do great things with XMLVM.

The XMLVM core team

Re: [xmlvm-users] Location based functionality implemented?

[Gergely K. <ger...@ma...>]

Hi,

It is pretty straightforward to add a new Java wrapper for an Objective-C
class

1. Check out the XMLVM source in Eclipse

2. You need to add 3 files
- src/xmlvm2objc/compat-lib/java/org/xmlvm/iphone/WrappedClassName.java
In this file you implement the method stubs that will mirror the Objective-C
interface in Java

- src/xmlvm2objc/compat-lib/org_xmlvm_iphone_WrappedClassName.h
- src/xmlvm2objc/compat-lib/org_xmlvm_iphone_WrappedClassName.m

These 2 files implement the wrapper in the Objective-C side.

In the basic case you will use an Objective-C category to add the Java
wrapper methods.

in the .h:

typedef OrigWrappedClassName org_xmlvm_iphone_WrappedClassName

@interface OrigWrappedClassName (cat_org_xmlvm_iphone_WrappedClassName)

// Java specific constructor
-(void) __init__org_xmlvm_iphone_WrappedClassName__;

// This is an example method declaration of Java getX(String, int)
// Check the other files to see the pattern
// This name mangling is required to support polymorphism in ObjC
-(int)  getX___java_lang_String_int: (java_lang_String*) s : (int) i;

@end

In the .m file

@implementation OrigWrappedClassName (cat_org_xmlvm_iphone_WrappedClassName)

- (void) __init_org_xmlvm_iphone_WrappedClassName
{
}

- (int) getX___java_lang_String_int: (java_lang_String*) s : (int) i
{
// Here we implement the wrapper -> call the hypothetical original getX
method
int res = [self getX: s : i];
return res;
}

@end

Now, in your Java code you can write

WrappedClassName x = new WrappedClassName();
int i = x.getX("foobar", 99);

If you run your modified XMLVM on the above code, in your cross compiled
project you will have
- your org_xmlvm_iphone_WrappedClassName.* files
- the cross compiled code from above

It will _not_ include the stubs from the xmlvm2objc/compat-lib/java folder
in any form

The cross compiled code will instantiate the
org_xmlvm_iphone_WrappedClassName, which is just a typedef for the
OrigWrappedClassName. So there is no wrapping overhead, you use the same
objc class.
The cross compiler generated the call for the wrapper method, which we
defined in the category. In ObjC categories are used to extend already
existing classes.

Hope this helps.

Best Regards,
Gergely

2010/5/5 Charlie McIver <Cha...@s1...>

>  Ok – its time I tried to do something cool with XMLVM.
>
>
>
> Has anyone done any location based functionality yet?
>
>
>
> Although I’m new to iPhone development and XML VM (got the demos to work
> and a new app based on the demo building!), and I don’t have the iPhone SDK
> / XCode stuff, looking at the Apple Web site, I think I need to implement
> the CLLocation class, which I think means I need to do it in the java
> compatibility layer, and probably something down in the objective C stuff
> (eesh)  and maybe in the simulator in some fashion.
>
>
>
> This is probably wishful thinking, but is there any simple examples of
> someone doing this I can learn from, without having to understand the whole
> of XMLVM?
>
>
>
> Maybe I should be starting simpler…
>
>
>
> Cheers,
>
>
>
> Charlie
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>


-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

[xmlvm-users] Location based functionality implemented?

[Charlie M. <Cha...@S1...>]

Ok - its time I tried to do something cool with XMLVM.

 

Has anyone done any location based functionality yet?

 

Although I'm new to iPhone development and XML VM (got the demos to work
and a new app based on the demo building!), and I don't have the iPhone
SDK / XCode stuff, looking at the Apple Web site, I think I need to
implement the CLLocation class, which I think means I need to do it in
the java compatibility layer, and probably something down in the
objective C stuff (eesh)  and maybe in the simulator in some fashion.

 

This is probably wishful thinking, but is there any simple examples of
someone doing this I can learn from, without having to understand the
whole of XMLVM?

 

Maybe I should be starting simpler...

 

Cheers,

 

Charlie