Hi all.
I’m currently developing a client app (iOS, OSX, Win) in Delphi. Feeling the need for a plan B, should Embarcadero/Idera fail to deliver, I’m looking at Oxygen and Xamarin. I’d rather not learn C#, so Oxygen seems compelling.
My app is talking to a REST API (Node.js server) via HTTPS. Login is done via Oauth2. The app can be used off line and caches data in a local SQLite database. Data is synched with server upon Internet connection.
The app is quite heavy on graphics. Large bitmaps are painted in a “scrollable tiles”-fashion to preserve memory. Via layer handling other graphics are drawn upon the base image. PDF reports are generated from these layered drawings.
In Delphi all of the above is cross platform via Firemonkey and the common cross platform library (RTL). I.e. I only have to write the REST/JSON stuff once. And I can render all of my complex graphics with a single engine on all platforms.
How much of this would I be able to put into a shared library in Oxygen? It seems that even http stuff are platform specific in Oxygen. At first glance it seems lika I’d have to write almost all of the essential parts once for every platform. Am I missing something?
Thanks
//Michael
In my personal opinion,
You should ditch Delphi as soon as you can.
Even i don’t favor fire monkey approach (one source code and runs anywhere approach, Poor UI is inevitable!),
I can find better solutions that takes similar approach but way better.
I’ve ditched Delphi years ago and never look back.
If you want to make awesome app,
First thing you have to admit is that there is no such code reuse.
although, main benefit of element’s compiler (which i like) is use same syntax and same mapped class with Sugar
could gives you flexibility that allows you to use same code base for business logic type of code.
But those kind of code also have to react System UI and http and some sort of platform specific API
If you have massive business logic focused app such as “Accounting ERP”,
those kind of app may utilize massive same code base with Sugar
If it is not, you gotta make app for each platforms with minimum or zero same code base (well that’s life).
Platform specific isn’t bad, soon you’re going to talk just like fellow java or ios programmer.
for example, “A” said “what do you use Rest API communication layer?” then
i can say "I use retrofit it is awesome"
Remember! Don’t lock yourself as much as you can!
You can’t communicate with your fellow Android conference developer with saying that “I use Indy”
Reason why I like developing with Elements
i don’t have to switch my brain’s syntax mode. i can just use same syntax for each platforms natively.
If i am going to mac, i am going to use Fire IDE Once @mh will finish the unicode keyboard input issue
Conclusion,
Sharing same code base is sort of (possible but hard) elusive dream ( or you’ll give up native feeling ).
1 Like
Thank you very much for your elaborate answer.
I don’t know if you are aware of what’s been happening over at Embarcadero the last couple of days. A lot of speculations, but bad enough for me to bail out. I’ll have to find out what tool to use instead. Oxygene is one of the top contenders, but I need to get a grasp of the stability of RemObjects.
- Does someone know how many people are working with Elements/Oxygene?
- How many users/clients does RemObject have?
- Did MS’ purchase of Xamarin make a dent in RemObjects?
- Is RemObjects a healthy company? (economical and cultural)
- What’s your take on stability, support and general “moving forward spirit”?
I’ll probably go the Cocoa way. But I wonder if there will be better/more support for learning Cocoa if I also learn Swift. I suppose many Delphi users are investigating alternatives right now. This might lead to an upswing for RemObjects.
One solution could be to learn Cocoa with Oxygen and later on port to Swift if needed. Should be quite easy since it’s the same framework.
1 Like
Our company is preparing a native cross-platform library based on Elements with an environment similar to RADStudio to design components, forms, languages, themes, databases, … no Mono, no OpenGL, no HTML, no CSS, no Javascript … 100% native.
Best regards,
Jose A.
2 Likes
Yes maybe financial stability of Remobjects could be your concern.
I am not a RemObjects staff.
however i am not worrying the problem.
why? one word marginal cost…
Element is taking zero or minimum abstraction
which means that the company can make support version for newest release of ios or android with ease.
on the otherhand, xamarin has alot of moving parts so complex to support for next android ios releases.
of cource, develpper gets impact once remobjects ceases the future releasse
but, even that situation, we have a alternative contingency plan at least android, we can make plain jar files from elements for core parts and utilize in plain java
my surrounding programmers doesnt aware the awesome RemObjects toolchain however, if i can grab a chance to make an awesome app with RemObjects toolchain, then i want to make it so.
I am learning android development with silver
i can notice minor bugs in auto completion and some highlight but it is ok.
but oxygene seems more stable.
my only hope for oxygene is a option that replace begin and end with {}
yes swift can do that but i hope…
Thank you again.
I have now tried out some tools and have come to a preliminary decision.
I’ll put about a week into React Native to see where the limits are. I have already tried it enough to see that the bulk of my app will be many times faster to code in React Native than in Delphi. This also suits me well because I’m writing the REST server in Node.js.
But I’m quite sure that React Native won’t be up to the task regarding my graphics needs. Fortunately these are isolated to one place in the app and React Native makes it easy to wrap native libraries and also communicate back and forth with the library in several ways.
It would be really nice if the library could be built with Oxygen. I’ll post this as a separate question. Otherwise I’ll probably end up learning Swift.
//Michael
I evaluated React Native too, However, Telerik’s NativeScripts looks better in similar approach.
If you familiar AngularJS, then you will feel right at home.
but above two frameworks are commonly showing delay when they change views that contains complex layout (it is about 1 sec)
Since both framework can access each platform’s api directly,
you’re choosing between Development Speed or 100% nativeness
I would be extremely interested in providing feedback for a visual IDE for Remobjects.
If done right, this will be the secret sauce that the compiler is missing. What do I mean by right?
The single most important decision you can make is to optimize for someone’s naming convention. Delphi and Apple have a legacy naming convention with prefixes on everything. Microsoft .NET and Java have a much cleaner naming convention. So TForm becomes Form or better yet Window, Page, View, etc.
Second, there is no reason today why a default MVC style app cannot be RAD. The Controller is essentially code-behind with commands or actions (good thing). With those, there should be no need for non-visual components to clutter your view if you provide pre-packaged commands that do what components use to do. No need to get caught up in the MVVM debate. It is just a controller with those types of behaviors if you want. Simple and clean.
A great name for such a product in keeping with Remobjects would be Sugar.UI.
If you’ve decided to emulate XAML as your UI language, please check out http://noesisengine.com. This is a complete implementation in C++ with a C# binding. I’m not fond of XAML but it is a Microsoft standard and Noesis is cross-platform.
If you are looking for a WinForms like designer, check out http://www.greatis.com/dotnet/formdes/
If you looking for a 2D graphics library, check out https://skia.org. This is an example where I would replace their SKCanvas prefix with Canvas in your library.
Anyway, some thoughts, let me know if they are helpful.
And if you need C# bindings, check out http://www.xinterop.com/
Our RAD IDE is MVC based, and is built with our own framework. In windows our framework is based on WPF.
Our IDE is designed to be easily extended with new components and new IDE functionality.
As soon as it is available a beta, we invite you to participate in its test. 
1 Like
Any idea about timeline for the beta? Q3? Q4?
This post was published in cross platform fundamentals so will the WPF framework function on other platforms besides Windows?
Are you targeting legacy WPF, Silverlight or UWP compatibility?
Personally, i prefer the simpler design of Xamarin.Forms. One has to wonder if that is the future replacement to the bloated WPF framework. For example, Xamarin introduces a BindableObject and BindingContext vs. DependencyProperty and DependencyObject.
Here is an alternative that can be used to replace the complexity of XAML where the setters could automatically call IPropertyChanged. You could have default getters and setters for simple types plus generic getters and setters for custom types:
unit Sugar.UI;
interface
type
PropertyStore = class
private
_Key: string;
class var _Values: string;
public
constructor Create;
class function GetKey: string;
class function GetValue(key: string; name: string): string;
class function HasValue(key: string; name: string): boolean;
class function GetString: string;
class procedure SetString(value: string);
end;
Test = class(PropertyStore)
public
property Example: string read GetString write SetString;
end;
implementation
constructor PropertyStore.Create;
begin
_Key := PropertyStore.GetKey;
end;
class function PropertyStore.GetKey: string;
begin
result := ‘key’;
end;
class function PropertyStore HasValue(key: string; name: string): boolean;
begin
result := true;
end;
class function PropertyStore GetValue(key: string; name: string): string;
begin
result := ‘value’;
end;
class function PropertyStore GetString: string;
begin
result := _Values;
end;
class procedure PropertyStore SetString(value: string);
begin
_Values := value;
end;
end.
Our framework is agnostic regarding the API of each platform chosen and how to work on each platform, we designed our own technologies for responsive windows, layouts, menus, notifications, dialogs, animations, vector images, multilanguage system, privileges system, styles for components, data model … but, however, all is based on native components of each platform.
Our binding system is based uniquely on our data model system, so it is not as general as found in other systems, however, it is very easy and powerful enough.
Our main goal is that the programmer can develop applications with very modern appearance, responsive to the device, which construction is very easy and very flexible at the same time.
Our roadmap is as follows:
- Implementation using the native Android framework (Completed)
- Implementation using native WPF framework (Completed)
- Development of our designer for components, forms, languages, privileges, themes and data models (in development)
- Adaptation of the Android implementation with new technologies incorporated in WPF framework.
- Implementation using the native iOS framework.
- Implementation using the native MAC framework.
- Implementation using the native framework UWP
- More platforms …
We would like to finalize our designer’s development for endings of year.
1 Like
‘At first glance it seems lika I’d have to write almost all of the essential parts once for every platform.’
That’s the way it works and that’s good. The very essential parts of your application are very likely more than less clever algorithms hopefully. I think it’s better to benefit from a lightweight integration assistance than to rely on the one click solution for everything. In the end no one knows what tomorrow will bring but we know who - the OS vendor 
.
Delphi reached a steady state I think. It’s no surprise that Delphi servers the needs of the Delphi developers in a first place and more futuristic requirements like the support of mobile devices in a second.
Any progress on the framework?
The project is progressing well, but much slower than we would like, since we have to simultaneously tackle other projects in order to survive.
We can not give dates for the first beta yet. 
Anyway to open source the project so that others can contribute? I’m working on a framework too and it would be nice to align to your efforts.
Adam,
Doing the project open source is something we could come to think of, but there are many years of effort invested in the project and we would like us to return some money for that effort.
What kind of framework are you building?
Can you give us details?