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
