Well, not really RAD Studio as such, more like Mobile Studio (whether as part of RAD Studio Ent+ or the Mobile Add-On) since everything shown was oriented around the Android support and emphasising the fact that an application written for iOS can simply be recompiled and will run on Android. Or Windows or OS X, as before of course. About which nothing was said (or, to be fair, asked either).
As such, there’s really not much to be said that hasn’t already been said in other World Tour Reports and that had not already been anticipated.
The Android support works as expected and, as expected, from my perspective, it is an extremely pessimistic expectation that it works toward. Namely, there seems to be no appetite for attracting new users to Delphi.
Some mention was made of “talking to universities” but frankly with the approach they have taken I do not think they will get anywhere with this. Universities are increasingly concerned with commercial relevance and FireMonkey simply isn’t going to score highly in that department.
The emphasis seems to be “use what you know to do this new stuff” and not as much “we believe we have a compelling story to tell to all mobile developers“. Some numbers suggesting the advantage in reduced team sizes and development costs of using Delphi were thrown up on the slides at one point but at this stage any such numbers are entirely theoretical, given that there aren’t any established ISV’s using Delphi to support a range of mobile platforms with which to compare, like for like, with the established successful multi-platform development sites.
The problem I see them having in taking their story beyond the borders of the existing Delphi user base is that once you scratch beneath the “one codebase” headline, the shortcomings and compromises are quickly exposed.
Now, whether those matter is a subjective question.
My guess is that it will matter more to mobile developers, as distinct from Delphi developers looking to do a bit of mobile.
Going Native
The word “native” was predictably ever present, sometimes attached to the word “code” and sometimes to the word “style”. But I am still not convinced. I think “native” is like what they say about “sex”. Anyone talking about it all the time usually isn’t doing it. 🙂
It can be argued both ways, but for my money Embarcadero’s interpretation of “native” doesn’t work for me. Yes it’s unmanaged code, which is what we tended to mean when we were comparing .NET vs Win32 on Windows for example. The problem being that “unmanaged” also happened to coincide with “native” on that platform. .NET was a runtime that sat – for the most part – on top of the OS. With the mobile platforms there really isn’t as much – if any – distinction between the managed runtimes and the platforms they support. They are, in a very real sense, the platform.
On Android in particular, Java is the native environment even though it involves a managed runtime (Dalvik). There is something that illustrates the distinction quite well I think. Consider this screenshot:
This shows a debug session of a simple Android application (the Oxygene Android Application template in fact) and the Android VM (a Parallels Desktop instance) that the application is running in.
In the Visual Studio tool bar you will see “CrossBox: Local: 192.168.1.16:5555“. This indicates that the debugger is attached to the Android device (the VM) at that address. Essentially CrossBox is to Oxygene as PA Server is to Delphi.
If I had a physical device connected then the device ID would be shown rather than an IP address. An IP address is involved here because I am debugging in a virtual machine. Not the Android emulator, but another Parallels VM instance, running an installation of Android-X86. That’s Android running on an Intel X86 processor (albeit virtualised in this particular case).
Obviously I cannot attach a USB cable between two VM’s, but fortunately the Android debugger is prepared for this. I simply need the IP address of the Android VM (obtainable from the Tablet Status info) and then run:
adb connect <ip address>
In a Windows command prompt. At which point my Android VM is detected and presented as a debug target by Crossbox. The Android machine that my application then runs on is a virtualised Intel x86 machine running my Android application.
As far as I know, you cannot do this with a compiler that emits a Java stub that then bootstraps into native ARM code. The Java stub will run but then fall flat on it’s face when it tries to run ARM instructions on an X86 processor.
But I do not have XE5 – not even in beta – to actually try this.
The Java, the Whole Java and Nothing But the Java
For those who for some reason still aren’t aware, you will also notice that the source code of this Android application is very much Pascal. Not Java. The “for Java” part of Oxygene Cooper refers to the fact that the compiler emits Java byte code out of its rear end, instead of X86 instructions and has nothing to do with the language.
It also extends to the fact that the compiler is able to make use of other Java libraries directly. No need for wrappers or other shenanigans to “get at” the underlying platform.
Furthermore, there is no supplementary framework required to make this application run. No mono.NET (as some people seem to think is required by Oxygene) or any other framework beyond that provided by the platform itself.
It is an Android application pure and simple.
Very simple in fact.
“How simple ?” you ask …
48KB simple. That’s how simple.
We did not get shown how big a “Hello World” Android application is in Delphi, but with the need to drag along the FireMonkey platform, I doubt anyone would take a bet that it won’t be an order (or orders) of magnitude larger than 48KB.
Touchy Feely Lookey Likey
One of the “5 mistakes to avoid” suggested for mobile developers was forgetting the user experience. That is, if your app does not look and feel like an app that the user is used to, they likely will not want to use it.
Your apps must look at home on their devices.
And FireMonkey helps you do this right? With all it’s pixel-perfect bitmap styles and what have you. No?
Well yes. And no. Consider the humble Tab Bar.
A Tab Bar in a FireMonkey application will certainly change it’s appearance to suit either Android or iOS as appropriate, thanks to the different styles that can be applied. But it won’t change it’s position.
On iOS, the convention – and the user expectation – is that a Tab Bar is positioned at the bottom of the screen. On Android, not only does the Tab Bar look different but it is positioned at the top of the screen.
This is in fact the subject of a question on stack overflow, posted by someone seemingly intent on breaking the rule of User Expectations (which also illustrates the difference between iOS and Android tab bars for those not familiar.
With FireMonkey, if you want your application to reconfigure itself for the different platforms then you will have to either:
- Write code to manipulate your UI (or construct it) to reflect differences in the platforms at runtime
or
- Maintain different forms for each different platform
The same applies not just for different platforms but for different devices on the same platform. An application UI designed for an Android or iOS tablet will rarely simply scale down to a phone, or sometimes not even to a smaller tablet/phablet.
Each difference in layout, whether to reflect device or platform, will mean code to modify the layout or different forms. Unlike the form design infrastructure provided by the iOS and Android platforms, where the form layout is free of code and (largely) decoupled from your application behaviours, a form in Delphi and FireMonkey is full of code, even if only simple code to invoke more complex behaviours in business objects.
You may indeed have only “one codebase” from which to generate all your different versions of your application for different platforms and devices, but I suspect that (if you are to get a worthwhile result) you will end up writing a lot of code simply to manage the user interface and not at all related to the business of your app.
If, that is, you wish to do mobile properly.
It should be mentioned at this point that we were told that a brand new form designer is in the works for Delphi that will apparently address at least some of these issues, though how was not explained and neither was when mentioned (but the impression I got was that it is not something you can expect in XE5).
Finally on this note, it was mentioned that iOS 7 support will be offered “very quickly” by Embarcadero, once it is finalised by Apple. In current beta’s the look and feel is seemingly still being refined and each time there is an update there is a graphic designer in Embarcadero whose job it is to tweak the iOS styles for FireMonkey to reflect those changes.
Let’s think about that for a minute:
iOS 7 “support” is dependent upon… a graphic designer.
Meanwhile, if you are using Delphi for iOS you will already have an Apple iOS Developer subscription.
You will already be receiving – or able to obtain – iOS 7 beta SDKs.
Of course, you still need that Apple subscription even if you are using Xcode or even Oxygene but in both of those cases you can get cracking with creating iOS 7 applications, complete with the actual iOS 7 look and feel, as soon as you get the SDK’s from Apple (we’re up to beta 6 of iOS 7 already).
The Final Stage: Acceptance
It seems now unavoidably the case that Embarcadero are not concerned with securing the future of Delphi by attracting new users, or if they are then they have a very strange way of going about it which is doomed to fail. Which throws the longer term future of Delphi into serious doubt imho, irrespective of the technical merits – or otherwise – or quality of the delivery.
We used to joke that Delphi was the new COBOL.
Sadly, we don’t joke about it any more.
Native code on an Android device is either ARM, Intel or MIPS last time I looked at the different devices and the Android SDK/NDK 🙂
As I said, it can be argued both ways. But I see it differently to you as I think will most people assessing the FireMonkey approach objectively alongside the alternatives. 🙂
Just for comparison, what is the minimum size of a Hello World FireMonkwy app for Android?
Who are these “most people” you claim to speak for ? 🙂
I don’t claim to “speak for” most people, I merely state what I believe, that the majority (that would be “most”, right?) of mobile developers will understand “native” to mean “to the platform” as apposed to “to the CPU” and so find Embarcadero’s claim to be at odds with their expectations.
I may be wrong. It is just what I think. [shrug].
You’re not alone in that thinking. I find EMBT’s new buzzword unsettling for the fact that it would let them claim that Google’s own apps aren’t “native”! There’s nothing more “native” on Android than Google Play, Google Maps, etc. Dalvik is the way Google has always intended applications to be available for Android; it abstracts away the underlying hardware, which has been vital for allowing so many different kinds of Android devices to exist.
And the minimum size is relevant because… (?) put your old aged argument there. 😛
It was an observation, relevant to the extent that it shows that the application produced is not dependent upon a runtime scaffold that has to be incorporated with each and every application.
On mobile devices with limited storage, and with both Google and Apple app stores having limits on the size of applications (50MB / 60MB respectively) they will allow, application executable size could actually be very relevant, though that was not a point I was making with this observation.
For me… the native thing is about speed, that’s exactly what Delphi developers, like it was “Turbo” Pascal, etc. so a natural thing to think is that if you compile “native code” = “Processor code” so wht you say about “Native code = “Platform code” that .NET semi translates at processro code which is good but extrictly isn’t processor code. Finally we the delphi developers are expecting a super fast affordable tool, and in this point and think embarcadero is missing this.
Greetings.
Sorry for my last post, it was not well writen. i’ll try to rewrite it
For me… the native thing is about speed, that’s exactly what Delphi developers expect from delphi compiler, like back in time it was “Turbo” Pascal, in that time turbo means super fast, now the native word means that, so if you compile “native code” then your going “turbo” (“native code” = “Processor code” that’s David I is saying and i’m agree) but the thing is that native code isn’t all for a fast platform, for example the memory managment is so relevant that even apple drop garbage colection in favor of ARC, and we know there are more examples..
You say “Native code = “Platform code”. Your right and i agree with you from this point of view, ive been following your posts and i feel like you disapoited about delphi evolution. don’t miss understand me, i really apreciate the efforts for improveing Delphi but years go by and results aren’t impresive and price is higher.
Finally we the delphi (pascal) developers are expecting a super fast affordable compiler and IDE, and in this point I think embarcadero is missing this goal.
Greetings.
Google say that the NDK should not be used unless absolutely necessary. The only form of application they deem “necessary” is games.
FireMonkey is notoriously sluggish on iOS devices, yet has always been native. The problem being that as well as your business logic code, you are also running an entire GUI abstraction framework. Instead of the OS firmware rendering your edit controls, you have a whole slew of FireMonkey code doing the drawing of your edit controls. For example.
All the “advantage” of native code will be eaten up by that overhead I suspect.
David, did you get the memo that Google strongly advised to NOT use the NDK if it’s not absolutely necessary and won’t do your application any good if used just because one would like to write in a certain language other than Java?
“Native”, or “true” native (as some like to emphasize) for the Android platform is Java. Nothing else. Everything that is cpu assembly that must run on a managed platform has restrictions and is a technical debt upfront.
But back to the actual problem: I take it from your comment, that Delphi compiles to ARM, Intel AND MIPS and puts all three CPU-code executables into one Android application to be able to run on all supported Android devices? How many megabytes is such an App then?
I red it to, but we all know that JVM are slow, that’s why i dislike Java, and sometimes is nice to break the rule, accepting the consecuencies i’m with embarcadero on this one, and hey check this out, http://www.delphifeeds.com/postings/107427-delphi_brings_arc_to_android,
We can replace garbage colection with ARC, this is really cool, I see a great benefit breaking this time the rules. What do you think?
I see someone advocating the advantages of ARC in simplifying the way code has to be written at a time when they are also promoting the notion of writing code once and recompiling for different platforms unaltered.
And then they have to point out that if that code is to work as expected on all those platforms then you can’t take advantage of the ability to simplify that the new technology brings and, in fact, your code will behave differently. Which (they don’t mention) may or may not cause problems for you.
>I red it to, but we all know that JVM are slow,
No, we don’t all know this. This is an urban legend that was true in the earliest days of Java. Today, though, with JIT performance, it’s simply not the case – along with the other story Delphi users talk about regarding GC halting programs. Hasn’t been true for ten years or more. Dalvik is also NOT the Java Virtual Machine; pure Java bytecode does NOT run on Dalvik. Dalvik is specially engineered for lower memory footprint and better performance on mobile devices than the standard JVM.
>We can replace garbage colection with ARC, this is really cool, I
>see a great benefit breaking this time the rules. What do you think?
The article referenced in that article about GC has been making the rounds among Delphi users. Since it’s told them what they want to hear, no one has bothered to check for any criticism of the article’s conclusions (there was a lot, including by Dan Bricklin, legendary developer of the first spreadsheet).
Dalvik and Android hasn’t stopped Android from becoming wildly popular, Android tablets and phones such as the Samsung Galaxy line from becoming huge sellers, etc. “99% of existing Android software is just TOO SLOW” doesn’t seem to be a complaint anyone’s making. Delphi’s marketing pitch is a solution in search of a problem.
At the benchmark shootout webpage, Java beats FreePascal in many benchmarks:
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=fpascal&lang2=java&data=u64q
and both Java and C# (in)famously beat Delphi in the SciMark benchmark in 2011:
http://webandlife.blogspot.com/2011/12/c-performance-vs-delphi-performance.html
I remember when other compilers were gaining MMX, 3DNow, etc. optimizations and Delphi still had a checkbox asking if you wanted it to avoid the original Pentium 60 floating point division bug. 😉 The compiler was yet another part of the package they let languish for quite some time.
I’ve noticed Android apps sometimes having “senoir moments”, periodically pausing. Just the garbage collector doing it’s thing, and not noticeable on iOS apps.
Give me ARC anyday over GC.
You really don’t know what is responsible for those “senior moments”. It is just as – if not more – likely to be some miscreant application background process as it is to be the GC.
iOS devices are certainly not immune from senior moments.
Fantastic, direct to the point.
Your posts are very helpful and have been helping us in our decision to continue or not with Delphi.
We already decide that we will use xCode for iOS and Android Studio for Android. Embarcadero is not a trustworthy company and stable to invest our future in.
And here, a payed announcement. LOL! You really are so obvious! The post start talking about EMB but, surprise!, that turns out in a great explanation on how good (?) is Oxygene. C’mon folks, somebody here is searching for the CTO position at Remobjects.
Nope, no payment, reward or inducements offered or sought. The same cannot be said of course of Delphi MVP’s or Embarcadero salaried employees, so please do be sure to take your accusations of bias to their blogs and make that point. Just in the interest of balance. 😉
For myself, I am merely a customer of RemObjects. A happy one. And the thing about happy customers is that some of us like to tell others how happy they are.
There are two ways to deal with a competitor: The first is to acknowledge and address the points where you believe your product has an advantage. The second approach has to be used when you have no such points, and that is to ignore them, pretend they don’t exist and hope that your customers don’t notice them either.
During the entire 4 hours yesterday, RemObjects and Oxygene was not mentioned or referenced by Embarcadero at all. In their world the choice is Delphi or Xcode and Eclipse etc.
Some of the claims made for the advantages of Delphi and FireMonkey whilst they compare favourably in comparisons with Xcode and Java fall apart when Oxygene is acknowledged. So it is little surprise that Embarcadero should try to ignore them and only sensible to highlight them for those seriously interested in an informed, objective assessment of all of the alternatives.
You seem not to be in that frame of mind, as is your choice.
Just as it is my choice on my blog to write about what I wish from my point of view.
Im also a customer of RemObjects, a happy customer i must say, for the RO and DA libraries. Oxygene is for me , just unnecessary. What is the point of use Visual Studio + XCODE to release a Apple application when you can do the same in a more comfortable way, using just XCODE? When you work with Oxygene, and that is a litrle detail you forget to point, you must do all the UI design ON XCODE and come back to Oxygene (VS) doa refresh and write BY HAND, connect BY HAND events of the UI to the code. That is already uncomfortable on XCODE alone, even poor is using Oxygene + VS. And what is the gain on all this? Code in pascal? You must be kidding… In Oxygene you finish coding the same way than on Objective C, just using reserved words from pascal. Again, what is the point of that? If you like XCODE (or are ver productive then) why in the hell you just dont use XCODE? Oxygene have no reason to exist, for that i mentioned.
The same for android. If you use Oxygene for every thing you plan to (even convert a string to integer) you must KNOW the Android API! Then is ridiculous using Oxygene, again, to code java using pascal sin taxis. Better use Android tools! And with andorid is even por. You have NO UI DESIGNER. I say it again, using OXYGENE you have no External editors for UI, you must use your own approach and that work poor!
Now, you have another option. You are a delphi users, using that for years, knowing all the good stuff delphi have. You can code TODAY with little knowledge of every platform, a iOS app, turn a check and get a Android application… You can EVEN use FRAMES on your applications! Man, Oxygene can beat that, is that simple. Your post just talk about the details enhancing Oxygene, for me are irrelevant. For me the delphi solution for mobile have the fastest time to market rigth now. Maybe the ui becomes slow on some specific operations but who cares, im sure EMB will fix this on the days become. Man, i dont plan to write a game for iOS, if i will plan some day to do, i will learn XCODE and run away from a experiment like Oxygene.
>Maybe the ui becomes slow on some specific operations but
>who cares, im sure EMB will fix this on the days become.
WOW, you must be a new Delphi user! 😉
Yes, i am, just use it from Delphi 1, and despite some bad moments on the past on the transitions between Borland/Inprise/Codegear/EMB, you cant denegate the quality is every time better and better. After Delphi 2005 release, every release is better. If you dont think so you dont use every day Delphi, sorry.
>and despite some bad moments on the past on the
>transitions between Borland/Inprise/Codegear/EMB,
That’s a lot of transitions!
>you cant denegate the quality is every time better and
>better.
Really? What about the same bugs that persist version after version, such as the essentially non-functioning Code Insight in the IDE? Here’s another IDE bug that dates to 2005:
http://qc.embarcadero.com/wc/qcmain.aspx?d=21276
Here’s a wonderful example of a serious performance regression that finally got a fix, but then an XE3 update came and went without the patch and instead the fix only showed up in XE4 (the good old “pay to get bug fixes” move):
http://qc.embarcadero.com/wc/qcmain.aspx?d=111942
Here’s another fave: someone realizes the Delphi regex code can be *1000* times slower than Python:
https://newsgroups.embarcadero.com/message.jspa?messageID=495865
This occurs in XE through XE3. The forum figures out the cause (poorly written code in Delphi that does a lot of Unicode conversions) and opens a QC bug complaint. That was September of 2012. One year later (even with a solution being given to Embarcadero) the bug still remains open. This is getting better and better?
Once upon a time Windows was a monopoly. A new version of its desktop OS only had to compete against the prior version of itself. Now in a world with multiple mobile OSes and devices, web-based applications, etc. it’s not good enough to just be better than the last version. Windows has to be better than actual competition (which, not being used to, it’s not doing so well against).
If you’ve used every version of Delphi since 1, then you’re probably as locked into Delphi as many Windows users have been. In that case, you’re only looking at whether there’s any improvement at all between versions. But with a huge variety of viable closed and open source development tools/languages available today, it’s not good enough for Delphi X to better than Delphi X-1. It has to be better than all the competition, and honestly, you just don’t see this level of poor quality control or laziness towards bug fixes in most other tools today.
Where can I get one of these sin taxis that you mention – they sound like fun (syntax is the word I think you are after).
Amsterdam ? 🙂
Making fun of how a non-native speaker writes is not very polite.
That being said, they do sound like fun.
I think there is a difference between enjoying a chuckle at an innocent and understandable mistake and making fun of someone for making the mistake.
Having met Alister and knowing him even the little that I do, I think I can safely say – and I hope he doesn’t mind if I do – that he is absolutely not the sort of person who would make fun of anyone for any reason.
No really sin taxis is very funny, it means that you get in a car for sin, perhaps some girls… you get the point. No offence Daniel it was just funny to think about this subject.
I wouldn’t go that far, Mark, to call Embarcadero not trustworthy. They just made a big mistake (like pretty much the same people under another label did back then with Kylix). That mistake is not even technology-wise but merely approach-wise.
They simply took the wrong approach to mobile and multi-platform development and that manifested itself in that abomination of technology that is FireMonkey.
If they would have chosen another approach, like emitting platform-native executables, and provided support to also consume platform-native libraries, and then provided a framework to support a single-sourced data access and business-logic layer while enabling the developers to leverage each platforms specific interaction possibilities (not only UI, but complete UX including sensors, (multi)touch, etc.) – that could have created a new and cool way to do mobile development. Well, at least with the power of the Delphi community behind it.
The approach it took, sadly, is a one-way-road and encourages developers to disrespect the UX wishes and needs of their desired user base.
Well, FireMonkey developers will notice that. At least, when their apps won’t be as successful as their platform-native counterparts from their competitors. Then they will have spent a lot of money, and time. We just can warn them. Not more. But also, not less.
“With FireMonkey, if you want your application to reconfigure itself for the different platforms then you will have to either: Write code to manipulate your UI (or construct it) to reflect differences in the platforms at runtime
or Maintain different forms for each different platform”
You have many options with FM to support multi-devices, screen sizes, orientations, etc for different target platforms – for XE5 platforms will include Windows(32/64), OSX, iOS (5.1 and later) and Android (Gingerbread, Ice Cream Sandwich and JellyBean): 1) use anchors, alignments, layouts, tab controls and other UI containers to have one form work on all devices, platforms, screen sizes, resolutions and orientations. 2) use form families to have specific forms for specific form factors and devices, 3) write some code to interrogate the client size, device type, device orientation, etc and do any special customization you care to do. 4) create forms entirely at runtime using code and components. 5) Constrain UIs to a specific orientation by setting a custom orientation choice in the Project Options Application settings. Just to name 5 for now.
And that are the reasons to love Delphi and now FM. 🙂
I do not understand the criticism from this point of view …for other points instead you have my support.
Can you show me the ide form designer you used to develop Android Oxygen application ?
I have developped quite fast my mobile application in IOS for my ERP… very soon I could see it in android without doing almost nothing.
Really I prefer see my application gui consistent in different platorm ( only with simple and general style difference to better integrate in the mobile OS ).
The value of my app is not related to the tabs position in Android.
Every dev tools had to be right for the job.
Every framework has drawback.Every framework has drawback.
My impression is that if you want the best possible … stay with java with android and xcode for IOS.
With Delphi you don’t need strong knowledge of java-android or xcode world to and their framework to start.
With Oxygene you need it … and you need to know and support a 3° framework and language.
You probably end developping a better , light and gui-consistent app … and you are able to share a lot of code.I am happy for you.
I am very happy with Delphi ( obviusly I like to see less bug and less money ) and the possibility that finally give me to invest my time in creating solution on every device instead of learning ,support and integrate n tools.
Oxygen and Delphi adopt a radically different approach.
I do not see a clear winner from the comparison.
Choose the one best suited to your specific business … and that’s all.
I haven’t yet reached this point with Oxygene, but the simple answer is that the form designer you choose to use for Android form design is entirely up to you. You are free to use any of the available Android form design tools, including the one in Eclipse and/or whatever tools are in AndroidStudio, because Oxygene works natively with the Android platform. An Oxygene Android form layout is just that: an Android form layout.
Or you can cut the raw XML yourself (with the assistance of code completion in the Oxygene editor) if that’s what you prefer.
The point of developing specifically for each platform is that what is convenient for you (consistent UI across all mobile platforms) is not what many users will want, or expect. Even David Intersimone in his own presentation makes this point as one of the mistakes to avoid. You will rarely be successful if you simply deploy on different platforms that does not look and behave according as expected by the users of those different platforms.
You seem to fit into the market that Embarcadero are aiming for – you don’t want the hassle and bother of having to do mobile development “properly” (to put it in simplistic terms), you just want to do it quickly and easily. That isn’t intended as a disparaging remark, merely an observation of your differing goals. If it works for you and your users, that’s great. Good luck.
“I haven’t yet reached this point with Oxygene, but the simple answer is that the form designer you choose to use for Android form design is entirely up to you.”
Well, you are on the hello world step. And that have sense you love Oxygene. I want to see you when you need to have a new screen or assign a image to a button… I love the concept when i start, but then i see the caveats. Oxygene sucks big time on the design, that is the true. As you have no experience with Oxygene you dont see that. You better think twice or the next time try to do a real app with Oxygene. You can see many real world app with FM for android and iOS (same code, you know…) but ZERO real world app from Oxyegen. Just show me one…
It’s the same way I felt about Delphi when I was at the Hello World stage, and there weren’t many “real world apps” written in Delphi at that point either (apart from Delphi itself). Borland dogfooded Delphi which was good enough for me.
RemObjects created Oxygene because they needed it – they too dogfood it.
In any event, Delphi turned out OK for me, well for 18 years or so anyway, and I have no reason at this stage to think that Oxygene won’t as well. 🙂
Where are these many real world FM apps? In two years we’ve seen an analog clock, a states and capitals game with a reproducible crash, and a bunch of moving blocks whose own creator disparaged the framework as requiring him to implement all but the most simple 3D code himself. Now there’s a picture viewer with two on-screen buttons.
This is what Digia is showing off of their Qt for mobile platforms, and it’s not even finished yet!
http://youtu.be/TzNWqoJRFsc
and this (actual screen recording):
http://youtu.be/vhWS_bN-T3k
That’s FAR cry from the “Delphi clock”, isn’t it? I’ve seen Mr. Intersimone disparage Qt before, including saying “I’d love to see your feature matrix comparing FM and Qt.” I’d love to see YOUR feature matrix. If you don’t have one, that means EMBT jumped into this market without knowing anything at all about their biggest competitor (which I guess doesn’t matter if you believe no one will buy your product except existing users, and they’ll die before using something other than Pascal). I remember Reagan telling Gorbachev to tear down the Berlin Wall. I say to you, Mr. Intersimone: build us this app! Let’s see a FM version of Qt’s demo app; the source code is available for porting. Knock our socks off and show us something that doesn’t look like a toy app.
Jolyon, when I was still trying to come up with ideas to save Delphi like you, I wanted them to do what video chip makers do: partner with a major developer before release. They’d get massive feedback on FM for Android, and the day XE 5 hit there would be a AAA app in the Google Play store showing off the product (assuming FM for Android worked). NVidia and AMD do this with AAA gaming titles, and it helps to show off the new features, attract buyers, and provide advertising. The developer gets help optimizing their software and early access. But like you’ve now realized, it’s like they just don’t care – except for traveling around the world (gee, I wonder why). Deep down they know they’re not selling to anyone except existing customers and they think we’re all like TeamB and will buy whatever they offer no matter what. 🙁 A captive audience vendor-locked in to Delphi.
How many people were at the event? More or less than previous ones?
Did you see anyone you didn’t recognise from previous events?
I wasn’t going to bang on that drum in case I attracted more sccusations of negativity and was going to leave those observations as implicit in the comment about “expectations” having been met. But since you asked specifically…
I didn’t do a head count (this year or last) but I would say there were about the same number of people present as last year, perhaps slightly fewer. There were still many empty seats though the smaller venue made this less painfully obvious. I didn’t notice any new faces.
This was probably the biggest Delphi event I’ve attended in Auckland (perhaps 100-150 people?), obviously there is plenty of interest in building Android applications in Delphi. There were also plenty of faces I’ve never seen before and I spoke to as many people as I could manage (no recordings this time unfortunately).
I think the smaller venue gave a false impression. I do not think there were more people than at the XE3 event, for example, but the room was easily half the size or less than on that occasion, so the amount of empty space relative to the number of people was vastly reduced.
Must say I agree with your comments on FM. I dont understand the necessity of having a common UX layer with the two major downfalls.
– Applications are large in size.
– And as soon as the platform on which the app runs changes, eg iOS7, your app no longer fits and requires additional work.
Surely it would be preferrable to provide wrappers for each supported platform’s controls. And then enforce a design pattern that would allow for high levels of reuse across the platforms with only a thin UX layer which would require redesign for each platform.
I’ll give you 5 quid if you can tell us something, without reservations, that you liked at the presentation.
Drinks and snacks don’t count. Nor does David I’s t-shirt, which are usually spectactular.
David I was in a sober black-t (or very dark blue – I wasn’t really paying much attention to questions of wardrobe) on this occasion. But he did mention having bought some of those programmable/controllable Philips LED lights and was able to get “tie-dye lighting” in his home. 🙂
Something I liked in the presentation …. availability of bread-and-butter facilities such as “ShowMessage()” across all target platforms is something that I miss at this stage in Oxygene but – at the risk of introducing a “reservation” – that is easily addressed. Keep your 5 quid even if you feel I earned it (which I don’t think I did, despite wracking my brains to try to recall something). If you are sticking with Delphi your need is greater. 😉
>Something I liked in the presentation …. availability of bread-
>and-butter facilities such as “ShowMessage()” across all target
>platforms is something that I miss at this stage in Oxygene
Save your money. As Stephen Ball pointed out at
http://blogs.embarcadero.com/stephenball/2013/07/10/opening-a-file-with-the-default-program-on-windows-and-mac/
there isn’t even a cross-platform way to launch a file such as a PDF yet in Delphi on the desktop. This is because for 18 years no one’s bothered to provide a function for this, relying on the Win32 library. Now you need to use compiler directives and the native library of each OS just to do this simple task. 🙁 So much for “cross-platform”. Qt has a function to do this, FreePascal has a function to do this, Python has a function to do this… honestly everything I checked could do this. It’s one of those things you assume can be done… but not Delphi.
This was actually one of the final straws that made me give up on the idea that Delphi could realistically be saved… that and the TeamB’ers in the forum aggressively arguing that saying that people with XE4 can apply for the beta doesn’t explicitly say that people without it can’t too (which is as bizarre an interpretation of English as saying that “those over 21 may be served alcohol” doesn’t say that those under 21 can’t be served too so it’s not telling you you have to be 21 to drink). They then savaged Luigi for bringing this up and Nick demanded he apologize to the forum and presumably Embarcadero! I told them all off and haven’t looked at non-technical since. In its final days, Delphi Island is becoming a somewhat surreal environment for sure. I just don’t need it anymore. I’ll always appreciate the early days when I helped my best friend build his logistics business with it from 1995-2003 but now I think we all need to consider abandoning ship before there are fish swimming past our eyeballs.
So I notice you mention “Oxygene Cooper”. This is one of the things that confuses me about Oxygene – the versions and what they do. Is there just one Oxygene which does all the various platforms – iOS, Windows, Windows RT, Android, Linux – or are there several different flavors?
Also, if I bought Oxygene would I then be able to create apps for all the platforms without having to recode for each one? Would I have to pay more money if I started out on Windows and then decided to, for example, produce an Android app with Oxygene? How does their financial model work?
Another thing springs to mind too – I see, in part, where you’re coming from with the whole “this (XE5) is mainly going to attract/retain existing Delphi users” but how is Oxygene different from that? I mean, if it’s essentially, as you point out above, Object Pascal then isn’t the same problem of attracting developers to consider Pascal as a development language going to equally apply to Oxygene as it does to Delphi.
When I looked at Oxygene it seemed to consist of native SDK stuff translated into Pascal. Not true for everything, of course, but essentially close in most cases. Is there an equivalent of Firemonkey for Oxygene – and by this I mean a platform-agnostic way of writing code to manipulate components that then handle the OS-specific implementation? Firemonkey, especially with LIveBindings seems to be an attempt to handle that issue – the “I don’t want to write lots of weird code for each platform” scenario. The anchors, layouts and so on that DavidI mentions also bolster that if you want to automate things a little although personally I prefer to code things myself with judicious use of layouts where they make sense or obviate the most risk of visual or layout disaster.
Oxygene comes in three basic variants: .NET (Echoes), Java (Cooper) and Cocoa (Nougat)
Looking at the Oxygene store it doesn’t look like you can buy single platform editions of Oxygene (not something I had even looked for before), so yes, $699 gets you .NET, Java incl. Android and Cocoa (iOS and OS X) all “in the box”. They all install into the same instance of VisualStudio and they share a common language. There is no specific Linux support that I am aware of as yet (other than via mono and .NET on Linux).
You can easily share source code between projects targeting the different platforms but that code either has to avoid platform specific calls or use ifdefs as required. There is as yet no comprehensive cross-platform runtime library equivalent to the RTL in Delphi. But there is no reason why one should not exist over time, and indeed just such an exercise is already in-hand in the form of an open source project (hosted on Github) called “Sugar”.
With this in place – or your own alternative – you can write if not all then certainly the vast majority of your application logic in shared code, with only the platform specific UI having to be developed for each platform.
But since both Android and Cocoa are very different from the Win32 model, having an architecture that not only supports but is actually built on the concept of a decoupled UI and MVC architecture, and since Oxygene fully participates in this decoupled MVC infrastructure, “writing the UI” is a much more lightweight proposition than that for a Delphi UI, whether VCL or FireMonkey.
The anchors and layouts that David I mentioned in his comment were also mentioned in the presentation yesterday.
What he didn’t mention in his comment was the acknowledgement that he gave yesterday, that this will not address the problem of controls being placed automatically according to the expectations of the platform. A Tab Bar placed at the top of a form according to layouts and anchors will be at the top of the screen unless those layouts and anchors are changed, whether in code at runtime or in design.
“Form families” were mentioned as a way of associating forms that were essentially different versions of the same form, at which point someone in the audience pointed out that if you have two form layouts this requires two separate form units along with some other comments about how cumbersome things became, and it was at that point that David I mentioned that these were the things that the new form designer that is being developed was intended to address.
You know what they say: If it aint broke don’t fix it. With a new form designer apparently considered as required this would suggest that the current one even with anchors, layouts and form families is, at least to some extent, currently broke. But you wouldn’t reasonably expect anyone at Embarcadero to say as much, obviously.
But apparently according to other commenters (not yourself), “bias” is something that only sullies critical observations and unfavourable comparisons. 😉
“You can easily share source code between projects targeting the different platforms but that code either has to avoid platform specific calls or use ifdefs as required.”
Actually , for even convert a integer to string the things change between andorid, apple and windows so… you cant share code between plattaforms on Oxygene, is a big lie.
Writing a StrToInt() method that has a common API across all supported platforms is a matter of a few moments, if that’s the way you want to do it. There are a number of ways to skin that cat. Mapped types and Sugar provide a more modern way, but if you prefer you can recreate the Delphi way that is more familiar, if you prefer to be stuck with the way that was conceived almost 20 years ago that is.
The language isn’t the runtime and the runtime isn’t fixed in stone, unless you are the sort of developer that can’e be bothered to help themselves and has to be spoonfed the basics by their tools vendor.
>The language isn’t the runtime and the runtime isn’t fixed in
>stone, unless you are the sort of developer that can’e be
>bothered to help themselves and has to be spoonfed the basics
>by their tools vendor.
There I have to disagree with you. Rich and powerful runtime libraries are a very useful thing (ask any Java or .NET developer). It seems that Oxygene isn’t implementing its own RTL on top of the platforms its targeting (yet; you’ve mentioned Sugar). That’s a definite drawback and does seem a bit unfinished in that regard. I just downloaded Jython and had no problem converting between strings and integers the same way as in regular Python(which is also the same across all platforms). No need to map a type or recreate anything with Jython. It looks like IronPython (Mono/.NET) in the same way. Meanwhile they each can import/use any library on their host platforms.
A language and its standard library are indeed different things but I don’t think there’s anything wrong with a developer expressing consternation at the realization that a language is using a different one on each platform its on. Needing to do everything the Java way takes one half the way to Java itself and makes it much more difficult to port existing code. It all depends on why one is looking to use language X on platform Y in the first place, what they’re already familiar with, etc.
Absolutely. The point I was trying to make is that the creation of such runtime libraries is not the exclusive preserve of the tool/language vendors.
Even the Delphi RTL is missing certain things in it’s RTL. If you are the sort of developer that comes to a dead-stop until your tools vendor plugs the gap or the sort who gets on with plugging the gap yourself, is what makes the difference. With Delphi in particular, an awful lot of what is on offer in this area has to cater for a huge amount of baggage in the form of maintaining backwards compatibility with existing code, so instead of a clean, well designed cross-platform RTL, what you have is a 20 year old RTL grafted over brand new platforms.
Oxygene has a long way to go to catch up on those 20+ years, but without all that baggage to drag along behind it, I do not think it will take 20+ years for it to do so. 🙂
>There is no specific Linux support that I am aware of as yet (other than
>via mono and .NET on Linux).
From what I read, the latest version of Oxygene no longer supports the MonoDevelop cross-platform compiler at the moment, so now you no longer have the option of developing your code in an IDE on Linux either. 🙁
I’ve never tried running an Oxygene program on Linux, but I do use Mono programs on Linux with success so I imagine there’s no problem in that regard.
I believe the issue is that the changes required to support the new platforms mean that they no longer support the MonoDevelop IDE but you can still target mono itself, you just have to do it from within the VisualStudio environment.
This isn’t an area I have looked into though as Linux doesn’t feature in my plans.
Oxygene does not integrate into the MonoDevelop IDE, but Oxygene fully supports building apps for/with Mono. Half of our own company infrastructure is made of Oxygene-written services running on Linux (and Mac) servers.
Pursuing MonoDevelop as an IDE was simply not worth the resources it took to “keep up” with the ever-changing IDE APIs vs. the relatively little demand for it from users. (literally not ONE user even commented when we dropped support for MonoDevelop).
We do have things in the works for a non-Windows working environment for Oxygene — something we’ll start talking more about sometime early next year.
I found your blog when I was doing some research into replacing Delphi and/or porting to other platforms. I appreciate your detailed posts as you’ve experimented with Oxygene.
I’ve used Delphi since v2 in 1996. I bought each version through 6, then stuck there until Delphi 2007. Then stayed there until XE2. And I’m still on XE2.
I was never employed to use Delphi. When I bought D2 I was being paid at work to use PowerBuilder (does that even still exist?). I’ve been what the industry started calling a “microISV” since the turn of the century. I’m a developer with one primary B2C product that I originally wrote in 1996 and have continued to support and expand since then. Now, though, that product needs to migrate to new platforms to follow the costumers.
I was excited when I first heard about Delphi supporting Mac and iOS. That is, until I realized I was going to have to completely retool my product to use Firemonkey *first*. Then I might be able to port it…assuming all the 3rd-party components I use also ported themselves to Firemonkey. In a way that made them useful on those other platforms. Blah blah blah.
After additional research I realized my best result would come from “going native” for each platform. I had even started experimenting with Android development, using Eclipse, and beginning to learn Java. I wasn’t sure how I would leverage the experience to get on Ipad, but I was willing to at least *start*…
Then I bumped into Oxygene. And, probably more importantly, Sugar. Suddently, the possibility of actually sharing non-UI code between platforms looked … well … *possible*. And I get to keep using Pascal.
But then, with a $699 entry point, a $499 yearly renewal, and a relatively small number of active developers using a tool built and maintained by a relatively small company, it started feeling a lot like Delphi all over again.
So I haven’t totally decided which way I’m going: totally native; or Oxygene.
I don’t expect you to answer the question for me, but I do appreciate your detailed posts on this. Thanks!
-David
Your point made me wonder so I did some calculations and you might be interested in my next post, where-in I present the results. 🙂
David – Forgive me, but you seem to have given up on Delphi because you’ll have to re-do your interface, but are contemplating embracing Oxygene so you can “share non-UI code between platforms” and “continue using Pascal”. Is that not a bit inconsistent?
I am not a Delphi fanboy – XE3 left a sour taste in the mouth, to put it mildly, and I own Oxygene as well as Delphi – but XE4 for iOS works really pretty well. Firemonkey is a lot better than it was in XE2. If the improvements have continued in XE5 – and I agree that’s not a given – I think it could be worth looking at.
Richard
Not wishing to speak for David, but if I have to re-do my interface in two different tools then the claims of not having to re-do the interface made for Delphi are meaningless and so other advantages/disadvantages come in to play such as cost, reliability of the vendor and, on a more technical note, being a “first class citizen” on the different mobile platforms and learning truly relevant new skills (Cocoa and Android frameworks/SDKs).
I don’t consider it “inconsistent”, because the issue isn’t as simple as “re-do your interface”.
I don’t feel like compiling and summarizing all my notes from xplat research other than to say: I came to the conclusion that if I wanted to have meaningful ports of my product to tablets, I would need to design *for* those tablets. Take into consideration the UI/UX conventions. And to do that, I would need work within the native development tool chains. And, really, after 17 years of continued development, it wouldn’t hurt to take the opportunity to seriously simplify my product. Not for Windows, where 17 years of accumulated users would *not* thank me, but for the tablets where it would make the most sense.
The downside? I have to learn a couple new languages and only the *experience* of design and development carries from one port to the next. I had already decided that’s what I would do when I stumbled across Oxygene.
I have a 30-day trial of Oxygene that I’m playing with. As I mentioned before, I haven’t finalized my decision. For $700 (versus *free* + learning Java), I want to be sure.
-David
Another limitation : XE5 seems to have used the NDK (which likely makes sense for them since they just need to do Delphi->C++ for this). However it would be interesting to see the limitations – for example there does not seem to be Google Play Services SDK available for NDK; Nor does NDK support various Android platform SDK features like broadcast receivers, content providers, services and such – i’m sure some of these thigns can be accomplished but now we’re relying on Embarcadero to document all these since Andoid SDK documents and samples won’t apply.
Exactly right. As I understand it – and requests for clarification have been met with stony silence from EMBT so I can only go on what I understand – even something as simple as implementing an Intent Filter (which requires an Activity entry point) will be dependent upon Embarcadero implementing some generic entry point Activity and exposing this through compiler hocus pocus to the FireMonkey framework on the Delphi side.
David, I’m in a similar situation. Been using Delphi since V1 and have been a “MicroISV” since the late 90s. I have religiously stuck with it and defended it against the “Delphi is Dead” brigade since Borland (or rather Inprise) dropped the ball with Delphi between 2001-2006. Having a core codebase that was originally developed in 1998/99 my business logic, DB access and UI code are all wrapped around each other and completely interdependent (these were the days of putting business logic and DB access behind button clicks and way before MVC patterns). I am still on Delphi 7 for my main product and last year I seriously considered moving to XE3 to get to Mac and with the promise of iOS and Android support to follow. When working with a trial of XE3 and FireMonkey I realised just what a fudge it was and the nightmare task I was faced with converting my UI code from VCL to FireMonkey. I employ a couple of other developers and they have for a couple of years been trying to persuade me to move away from Delphi, essentially fearing for their careers should they find themselves unemployed. Having had tough times in my business over the past 3-4 years I also was fearing what my potential prospects would be should I need to find employment. After a few weeks wasted trying to get FireMonkey to do what I wanted and realising it is something I do NOT want to work with for the next x number of years and certainly not something I want to bet our future I was starting to come around to the “Delphi is Dead” way of thinking. The pricing and attitude of Embarcadero (not even bothering to attract new developers) effectively nailed the coffin shut on Delphi for us. So I looked long and hard at Oxygene and it is a fantastic solution for a great price. Unfortunately the future prospects for my employees, myself (if it came to that), attracting new developers have, sadly put the blockers on it. We’ve decided on moving to C# with support for .NET, WinRT, Windows Phone, ASP.NET and through Xamarin to Mac, Android and iOS. I worked out that to move to FireMonkey would require a 70% refactoring/rewriting of our app so have decided to go the whole hog and rewrite in C# which gives us all better future prospects. It’s been a tough, soul-searching decision but we’re more than happy with our decision.