Hi Jolyon, I think that mono support OS X which you can write c# code to run on OS X.
Regards Leigh On 29 July 2015 at 09:56, Jolyon Smith <[email protected]> wrote: > Yes, there is no denying that it would be a hard sell to get elements > introduced into an enterprise or even ISV setting. > > But for the enthusiast/hobbyist/independent ObjectPascal (in particular) > developer it has much to offer against the likes of Delphi or even FPC > (which ime is frustratingly lacking in the polish you may be used to from > commercial dev tools and falls *far* short of the "just works" goal when > it comes to mobile dev... I suppose if you enjoy spending more time getting > your compiler to even work than you do developing apps, then it may appeal). > > Even if you are keen on (or willing to suffer C#) Elements has some > advantages even compared to the comparably affordable version of Xamarin, > not least being complete platform support (Indie Xamarin does not support > OS X or System.SqlClient, for example). > > And using Elements I am at least also learning the platform SDK's, so if I > ever am asked to do Android or iOS development "properly", everything I am > learning in the meantime can be applied directly (I am no stranger to Java > / Eclipse or Objective-C / X Code, I just prefer ObjectPascal). > > > On 29 July 2015 at 08:13, Jeremy Coulter <[email protected]> wrote: > >> I guess for me, not ever seeing a role advertised that requires >> RemObjects experience, I would be confined to tinkering with the free >> version of the "Silver" tool. >> And given its not main-stream, it would be hard to get it into our >> development environment. >> Thats not saying it itsnt a good tool, just the commercial reality. >> However, like all of you, I am getting a little concerned about EMB. >> direction. For me personally, having to re-install my controls every six >> months or so is just not economic. Instead of releasing new versions ever 6 >> months or so, do one a year with six month updates that doesnt require me >> to re-install all my controls. >> >> Jeremy >> >> On Wed, Jul 29, 2015 at 8:03 AM, Jolyon Smith <[email protected]> >> wrote: >> >>> RemObjects # of users - sorry, I have no idea. >>> >>> Community support - there are two prongs to this... >>> >>> First, the RemObjects forums are quite active with contributions both >>> from users and RemObjects staff thmselves. To give an example of the type >>> of support you get, on one occasion during my early days with the product I >>> encountered a problem using a particular aspect of the Android SDK which >>> was traced to an esoteric bug in the compiler. This was identified in a >>> few days and by the end of that week a build had been provided to me >>> personally to test, before the fix was incorporated in a subsequent beta >>> and later release build. >>> >>> As a subscriber you have access to the current and previous releases and >>> betas and you also have a "private downloads" area where specific builds >>> may be provided to you. Betas are updated on a more or less monthly basis >>> with full releases usually coming quarterly, along with regular updates on >>> the development plans (a "roadmap" if you like" via the blog, as well as >>> formal updates to those plans with each release (they tell you what the new >>> release delivers and what they are working on next). >>> >>> http://blogs.remobjects.com/blogs/mh/2015/07/16/p7096 >>> >>> I should add that I am enjopying only *BASIC* support. Premium support >>> is a cost-extra option, should you feel the need for it. >>> >>> >>> Second, "Community Support" is also on offer from beyond the strictly >>> delineated boundary of "RemObjects Users" itself. by virtue of the fact >>> that you are developing directly against the platform SDK's. I have >>> learned all my Android and iOS development from the Java and Objective-C >>> examples online and by perusing questions and answers on Stack Overflow >>> couched in terms of those platform native languages and API's. Applying >>> that knowledge to RemObjects elements is a trivial exercise in syntax >>> conversion. >>> >>> >>> On the point of Java and "one language everywhere".... something to bear >>> in mind here is that when you compile RemObjects Elements code - whether >>> ObjectPascal (Oxygene), C# or Swift - for Android, what the compiler emits >>> is Java byte-code. It is indistinguishable from the output of a Java >>> compiler! The front end language syntax may be different, but the output >>> is essentially Java. This applies equally to consuming other Java code. >>> Classes etc from Java are simply consumed directly in your code by adding >>> the relevant JAR to your project references. >>> >>> So in a way, RemObjects Elements is an active participant in that "Java >>> everywhere" phenomenon - when compiling for a Java platform. In the >>> Oxygene compiler they have cleaned up the syntax of some of the aspects of >>> Java, whilst retaining this compatibility. For example. Java has no formal >>> specification for the concept of a "property". But you can still declare >>> properties in Oxygene for Java - the compiler emits corresponding getXXX >>> and setXXX methods as you would expect (even if you have not explicitly >>> declared these accessor methods). Equally, if you consume a Java class >>> (e.g. from the Android SDK) which implements get/set methods, then these >>> can be accessed as if they were properties: >>> >>> Java methods: v = o.getName(); / o.setName(v); >>> Oxygene: v := o.Name; / o.Name := v >>> >>> Similarly if provide your class implementing a read/write "Name" >>> property to a Java developer (in a jar file) then they will see a class >>> with getName and setName methods, just as they would normally expect. >>> >>> Equally when compiling for .net then Elements is an active participant >>> in that ecosystem/platform. And ditto w.r.t iOS / OS X when compiling for >>> those platforms. >>> >>> >>> As I think I said, impressive and innovative technology. :) >>> >>> >>> >>> >>> >>> On 29 July 2015 at 00:25, John Bird <[email protected]> wrote: >>> >>>> I don’t know RemObjects C# or Oxygene. I read the site and their >>>> viewpoint on using native API’s is a worthwhile debate. I would have >>>> these queries: >>>> >>>> 1 – Where does it rate on the number of users? Community support, >>>> code snippets etc is as important as everything else. >>>> >>>> 2 – It is the opposite of “one language fits everywhere” yet the >>>> language currently scoring top on the Tiobe index of programming languages >>>> does just that – Java. >>>> >>>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >>>> >>>> >>>> I noticed Delphi is up another few places, to 13. Pascal is rated >>>> separately too at 20. >>>> >>>> On the comments about the IDE, at work have used D5 , D2007, XE2 XE5 >>>> XE7 XE8 and each version was a definite improvement. >>>> >>>> *From:* Jolyon Smith <[email protected]> >>>> *Sent:* Tuesday, July 28, 2015 5:03 PM >>>> *To:* NZ Borland Developers Group - Delphi List >>>> <[email protected]> >>>> *Subject:* Re: [DUG] EMBARCADERO MY GRIPE >>>> >>>> I'll say it one more time... RemObjects manage to provide very good >>>> support for good quality products with extensive, impressive and innovative >>>> technology that does indeed "just work" (as in effortlessly, not "barely" >>>> LOL) at a very reasonable price. $49 Turbo Pascal it certainly isn't, but >>>> lined up against the likes of Delphi and Xamarin and particularly after >>>> adjusting for inflation (for comparison with the $49 TP) it isn't far off. >>>> >>>> Cheap(er) = lower quality is *not* a rule, and certainly not a >>>> Universal Constant. >>>> >>>> >>>> >>>> _______________________________________________ >>>> NZ Borland Developers Group - Delphi mailing list >>>> Post: [email protected] >>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>> Unsubscribe: send an email to [email protected] >>>> with Subject: unsubscribe >>>> >>> >>> >>> _______________________________________________ >>> NZ Borland Developers Group - Delphi mailing list >>> Post: [email protected] >>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>> Unsubscribe: send an email to [email protected] with >>> Subject: unsubscribe >>> >> >> >> _______________________________________________ >> NZ Borland Developers Group - Delphi mailing list >> Post: [email protected] >> Admin: http://delphi.org.nz/mailman/listinfo/delphi >> Unsubscribe: send an email to [email protected] with >> Subject: unsubscribe >> > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe >
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
