[Estimated Reading Time: 2 minutes]

When discussing mobile device application development using Oxygene or other RemObjects Elements technologies, the question of user interface designers doesn’t usually take long to come up (particularly with Delphi developers). Up to now the answer has always been Xcode Interface Builder for iOS/OS X, Visual Studio WinForms/WPF Designers for .Net and… um… your favourite text editor for Android (if you don’t like the XML editing facilities in Visual Studio).

But not for much longer.

Actually, the response w.r.t Android is usually more along the lines of “Well, you can use your favorite Android layout designer or editor”. One of those might have been Android Studio, but when I tried this in the past I found that it didn’t like layout files hanging out on their on, and required them to be part of an Android Studio project/solution (or maybe that was Eclipse ?).

Either way, it didn’t work particularly well (for me) and so I stuck with editing the XML.

Android Studio was perhaps the most obvious target on which to aim for any integrated solution, now being the anointed Google IDE, but that was in beta and so presumably in at least a potential state of flux.

But recently you may have heard that Android Studio went 1.0.

Whether “Going Gold” was a factor or not, hot on the heels of that development comes some exciting news from RemObjects.

Yes – integration with the Android Studio layout designer !

From within Visual Studio you simply right-click a layout file and select “Open in Android Studio” from the context menu then layout your design (or design your layout?). It’s as simple as that (or appears to be – I haven’t yet had opportunity to try it myself).

A ‘Gifideo’ has been posted in the RemObjects forums demonstrating the integration in action:

Android Studio Integration

Click on the image above to see the animated GIF in action.

26 thoughts on “On The Shoulders of Giants…”

  1. The screenshot reminds me how great Xamarin has been in this field, who compiles Google’s designer bits from Java to C# and hosts it in VS/Xamarin Studio. Technically RemObjects is capable of doing the same, but of course Xamarin does not reveal all necessary details.

    1. Is that really how Xamarin works ?

      I thought Xamarin had it’s own layout language and designer, independent of any of the underlying platforms that its Mono based approach runs on ? RemObjects works fundamentally differently – there is no platform abstraction to lean on so unless 100% compatible tools are provided by RemObjects themselves, the simplest and most reliable route is to employ the UI tools native to each platform.

  2. “the question of user interface designers doesn’t usually take long to come up (particularly with Delphi developers)”



    It’s good to see other tools catching up. 🙂

    This is a great move for RemObjects. I like I really like the Android Studio layouts. In fact, I hope Delphi borrows heavily from it in the future.

    1. I’m not sure what that video is supposed to be showing. The FireMonkey designer ? What does that have to do with platform native tool chains ?

      It’s easy (and essential) to provide a designer when you also provide the layout framework. Of course, it then means that your framework isn’t actually native to the platform and requires a runtime engine to support your proprietary layout technology.

      But as long as you can make that framework lightweight, efficient and reliable, it may be worth it. Perhaps one day FireMonkey might meet those criteria.

      But so far, after numerous attempts (how many versions now ?), FireMonkey is still a bloated and inefficient behemoth with significant and fundamental problems even with the basics.

      A layout designer isn’t much use if the layouts you design don’t actually work. 😉

      1. The FireMonkey designer is in pretty good shape. You should take a look.

        The video was specifically for FireUI, which lets you customise for different form factors. If you’re curious, I can find you video that goes in to more detail.

        As for being easy, fi that’s the case then I’m not sure what’s taking the other guys so long…

        1. I think you’re missing the point that a designer in good shape is pointless if the thing it designs for is not. 😉

          As for being ‘easy’, I meant it relatively. When you own the UI framework making a designer for it is straightforward. The technology that your designer targets can’t change ‘underneath your feet’, and you have only one technology to deal with.

          When you target multiple layout technologies, it’s that much harder and only makes sense to leverage the existing designers from the providers of the underlying technology itself.

    1. It really hasn’t changed that much to warrant updating my impression. In fact, every time I try to do so I find that the current state is pretty much the same as the previous state. And the state before that.

      It’s big, slow, buggy as hell and really doesn’t seem to be improving in any of these key respects.

      New toys and bells and whistles are undoubtedly being added. Baubles to distract the easily distractable. And if you are impressed by slick designers to the extent that you can ignore the state of what lies beneath then all power to you.

    1. Correct. XE5 is the most recent that I was conned into paying for. One reason for finally giving up is writ large on that page of bug reports that I linked to. That entire first page of bugs were all reported in just the last month, and it’s only the first page. Note that some of these are regressions so even the bugs EMBT fix aren’t certain to stay fixed.

      You’ve got to be a special sort of masochist to enjoy using a current version of Delphi these days, and a particularly delusional one to try to argue that it is in any better shape than it actually, and very evidently, is.

      You can say my view is out of date all you like. But then it’s easy to say anything.

      Demonstrating that it is actually so…. good luck with that. So far the evidence flies in the face of your assertion. 😉

  3. FMX is still buggy in XE7. It’s getting better though. I don’t think that’s the issue though. Even if all the bugs were fixed you still end up with Swing for Object Pascal. It’s native nowhere. Combine that with the immense executable sizes and it just sucks for the user. Devs like it for the ability to reach both iOS and Android (ARM) with single codebase. But pity the poor user.

    1. Sorry David. This view is way out of date. Then again, I doubt you have a recent version. Oh. Sorry. Wait. What ? 😉

  4. I’m not an active FMX user though so you can call me on that. I just don’t believe in non-native UI.

  5. My point really is that even if FMX were free of bugs, it is still designed for the developer rather than the user.

    1. Indeed. Sorry, I didn’t mean to ignore your wider point. The original observation was itself broader (“big, slow and buggy as hell”). The bugs are just one corner of that particular triangle, as you say.

      In some respects FireMonkey is Delphi .NET all over again… focused on making a short-term pitch to the developer at the expense of the longer term viability of the approach. Delphi .NET at least had VCL compatibility driving it, with the aim of easing the transition from Win32 to .Net and in this respect it was perhaps successful. The problem was that once you had made that transition you were then stuck with all the compromises and issues that this approach had imposed.

      FireMonkey doesn’t even have this saving grace in that there is no friction-free path even from VCL to FireMonkey.

      Even the one USP that FireMonkey attempted to hold on to – hardware native binaries – is looking tenuous, now that the platform native frameworks are incorporating technologies to deliver exactly this (ART, .Net Native) for all the platform native apps out there. So the platform native developers not only have hardware native support now at no extra effort (or cost), but they have even better support than FireMonkey in this area, being able to support potentially many more hardware platforms that the platforms themselves support natively, rather than being confined to the one particular set of hardware that, e.g., FireMonkey is limited to.

      Not to mention the complete lack of .Net support within FMX.

      This latter may not be important from a mobile device perspective if you consider WinPhone a write-off, any more than the lack of Blackberry or Symbian support is. But it is important from the perspective of positioning Delphi as a viable, on-going platform for development beyond mobile (desktops and servers are still out there… servers in particular are actually a key component in the mobile landscape).

      You could argue that Embarcadero have simply given up on the desktop or the server, and it would be hard to disagree given the course they appear to be charting.

  6. David’s opinion has less of an agenda so is more useful and relevant.

    1. I have no agenda, only an informed opinion that has directed my recent decisions and preferences in this area.

      For whatever reason you project an agenda onto that opinion with apparently only one objective (an agenda, if you will ;)): to contrive a reason to dismiss the opinion. Not on the basis of any disagreement or counter argument on the points in the opinion, but simply because of who holds it.

      I find that both amusing and depressing.

    1. Coderage 9 ? From back in October ? Sorry Bruce, but that is patently not ‘more current’ than bugs reported in November/December. Your grasp of the calendar seems as tenuous as your grasp of much else in what the rest of us call ‘reality’.

      I wish you’d make up your mind. Even just once. Is the opinion valid, but only when espoused by certain people ? Or is it just plain invalid ? If the latter, where’s your rebuttal ? So far your rebuttal has consisted of “If you say it, I will disagree, whatever ‘it’ is.”

      As for obsessive… I have to wonder, do you have any other hobbies besides trolling my blog and denying reality ? O.o

      1. Now now. You’re the one who thought it would be funny to turn any news into a Delphi bashing opportunity. I think even the weather would have done it.

        1. Another stark disconnect with reality. There was and is no “Delphi bashing” in my post, so I really don’t know what you are talking about.

          I do not doubt that there are people out there who are intent merely on bashing Delphi (and, in your case, anything that isn’t Delphi). But commenting on observed problems isn’t “bashing”.

        1. Thanks for the clarification but your agenda was already abundantly clear. I feel sorry for you Bruce, if this is how you have to get your kicks. Very sad. 🙁

  7. Why have a discussion about FMX and Delphi if we talk about Elements. I want a green peach and discuss about the better taste a red apple vs. a green one. That’s odd somehow.

    Just can say – Remobjects well done.

    1. Indeed.

      There’s lots of new stuff coming from RemObjects. The Android Studio integration, Shared Code projects to name just two and lots more besides.

      I think I’ve said it before and hopefully won’t need to say it again, but in future I shall simply refuse to rise to Bruce’s bait. I can’t stop him reading this blog (though why he does I cannot fathom) or trolling commenting. But I can stop being an enabler for his denial.

Comments are closed.