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
