Limitations in native iOS components for Firemonkey

2
votes

I am very attracted to the idea of using native components for iOS development, so I am testing the two options currently available: TMS iCL and D.P.F iOS Native Components. Unfortunately I found that both of them have limitations that make them cumbersome or impossible to use, though I still hope that I just overlooked something and therefore I ask here.

Limitation I found:

  • TMS iCL: it requires all native components in the whole application to be on the same form!
  • D.P.F.: there is no FMX wrapper that allows you to combine it with FMX forms/components.

Here is a simplified edition of what I need. I have 3 forms, a main form with the main menu (as buttons) and two forms I want to slide in. This is the component structure:

MainForm
  UINavigationController
    UIButtonA
    UIButtonB
  UIViewController1
    FMXwrapper that wraps Form3 (only in TMS iCL)

Form2
  UIViewController2
    UIButton2

Form3
  Various Firemonkey custom controls

Implementation with TMS iCL: FMXwrapper makes it possible to slide in Form3 (which has FMX components), using the command UINavigationController.PushViewController(UIViewController1). I can also slide in UIViewController2, but the components on this form (UIButton2) is not shown, which seem to happen because it is on another form. If TMS iCL really requires all components to be on the same form, then it is useless, unless you make very small apps, but maybe there is a solution to this?

Implementation with D.P.F.: You can actually embed forms from other units, so here I can slide in Form2, but it will only show DPF components on those forms. Therefore sliding in Form3 does not show any components. Is there any solution or workaround to make that work?

Any suggestions how to solve the limitations in either of the component sets?

2
iosdelphifiremonkeydelphi-xe6
I don't think TMS iCL has that restriction. I use TMS iCL across 8 different forms. However, your UIViewController is making it so the other forms are actually in the current form. Same thing goes for DPF IOS. You can mix FMX and DPF IOS forms within the same application. But if you are using that view controller the two forms are actually one. – FMXExpress
With TMS iCL, when I call UINavigationController.PushViewController(UIViewController2), it does slide in the ViewController2 on Form 2, but the components on ViewController2 are not shown. That is the problem I have. – Hans

2 Answers

1
votes

Use a UITabBarController on Form1 with multiple tabs (instead of Form2). You can slide between the tabs for native controls.

To get the FMX Form3 to slide in you could set TForm.Transparent := True;. Then use Form3.Show; to show the form. Have a TPanel/TRectangle in Form3 that contains your controls. Set TPanel.Position.X := Screen Width; and then animate sliding it in from the right after TForm.Show;

1
votes

I contacted TMS to solve the problem with showing components from other forms. The components simply needs to be initialized on the form first. The simple solution is to quickly show and hide Form2 in MainForm.FormShow. However, with many "hidden" forms it might cause flickering so TMS suggested to make a small function (see below)

As a bonus, here is my evaluation of the two componentsets:

TMS iCL: Simple but stable

  1. They implement very few of the native properties as published properties in the FMX control. It is not a big problem as you can still access the native object directly and modify its properties, but it requires a more knowledge about the iOS classes and how they work.
  2. It does not include a working Windows target userinterface.
  3. It has the FMX wrapper, which allows you, to some extend, place FMX components inside native components. (normally when you mix native components with FMX components on a form, the native are always in front, so you cannot use native navigation components because they take up the full screen and covers the FMX components)

D.P.F native controls: Comprehensive but less stable

  1. They implement a lot more native properties as published properties in the FMX control. It makes it a lot faster to work with, especially if you are not familiar with the iOS native controls and their properties.
  2. It does allow you to test your program on Windows (which is much faster than running it on the iOS simulator), as the controls actually works in Windows. Of course the graphics is simplified, but the purpose of this is to test functionality and not the user interface.
  3. There is no way to mix FMX and native components, though you can place native components on a form with FMX components with the limitation as mentioned in TMS point 3.

Conclusion: In the end I decided to buy TMS iCL, for two reasons:

  1. I have a lot of custom controls that I don't want to convert to iOS custom controls, so the FMX wrapper is indispensable for me.
  2. I can get support. For a company this is much cheaper than a free solution without support where you have to spend hours to figure out everything yourself.

The procedure suggested by TMS:

TMainForm
...
procedure InitializeControl(AControl: TControl);
...

implementation

...

procedure TMainForm.InitializeControl(AControl: TControl); 
var  I: Integer;
begin
  if not Assigned(AControl) then
    Exit;

  if AControl is TTMSFMXNativeUIBaseControl then
  begin
    (AControl as TTMSFMXNativeUIBaseControl).Initialize;
    for I := 0 to AControl.ControlsCount - 1 do
      InitializeControl(AControl.Controls[I]);
  end;
end;

...

InitializeControl(Form2.TMSFMXNativeUIViewController2);