Options for iOS/Android

[JimKueneman]

My last question on SDK headers pointed me to the ObjectivePascal site.  This leads me to a new question.  I have been tinkering around trying to understand the mobile development paths in FPC/Lazarus for a long time.  I have a clear understanding of how to develop for the Mac/Windows/Linux on Lazarus using the LCL but for mobile it is a maze.  Here is what I think I understand:

1) There is an active community on the ObjectivePascal side which is focused mainly on using FPC but being more integrated into XCode
2) There are a number of apparently abandon or little recent progress attempts that take various other approaches.

I see it as there are a number of ways to approach the problem one is the way the Objective Pascal guys are doing it but this locks the code into iOS only I think.  Another would be to do something like FireMonkey (fpGUI is where I was thinking about this approach) and have almost 100% custom components.  Lastly would be a framework that allowed the native iOS/Android controls to be created and used, more like an extension of the VCL.

Can anyone elaborate on what approaches are currently out there and their current state and if they are active or hit technical roadblock?  I would really like something that I could compile into Mac/Windows/Linux/iOS/Android much like Delphi.

Thanks,
Jim

[Phil]

Jim,

I really only see 3 realistic approaches for using Free Pascal in iOS development. They assume that the iOS headers have been parsed using Ryan's parser and that UI design uses iOS native controls and conventions.

(1) Write UI code in Objective Pascal without a designer. Virtually any IDE or text editor can be used. Write scripts for doing all the stuff that Xcode does for you automatically when building the .app bundle.

(2) Take a "hybrid" approach with Xcode, where the project has "dummy" ObjC files that are used only for UI design using the Xcode designer; corresponding Pascal units are what get compiled into the executable. I used to have templates for creating this kind of project in Xcode, but they were too much work to maintain (and very little interest from developers), so they're abandoned. Instead, just create the project with a script using an existing boilerplate project:

https://dl.dropboxusercontent.com/u/28343282/ObjP/ProjectXC.html

(3) Use Xcode per normal and write UI in Swift; all other code (ie, bulk of app) goes into a Pascal dynamic library. This allows normal use of Xcode UI designer and all other Xcode features that make life easier for the developer. Library code can then be shared with Pascal apps on other platforms.

A variety of examples that use the same Pascal library are here:

https://dl.dropboxusercontent.com/u/28343282/MacXPlatform/PascalDynLibs.html


Thanks.

-Phil

[Leledumbo]

Can anyone elaborate on what approaches are currently out there and their current state and if they are active or hit technical roadblock?

The only working (and I recommend) path for Android is to use LazAndroidModuleWizard. I never code for iOS, but the same author who produces component set used by LazAndroidModuleWizard also creates the equal component set for iOS. The author of LazAndroidModuleWizard recently creates LazArduinoModuleWizard, if you can convince him (probably providing him iOS device) he might be willing to create LaziOSModuleWizard.

I would really like something that I could compile into Mac/Windows/Linux/iOS/Android much like Delphi.

That one doesn't exist for now, somebody must write LCL widgetset/fpGUI backend/mseGUI backend/whatever existing library for the last two if you need to write applications in GUI style implemented by those libraries. However, if you're OK with OpenGL canvas, both ZenGL and Castle Game Engine actually has such an implementation. The drawback is that you must code your apps like games, the UI is all custom drawn by OpenGL commonly using images or OpenGL primitives. All events are also managed by those engines.

[mse]

Another would be to do something like FireMonkey (fpGUI is where I was thinking about this approach) and have almost 100% custom components.

Or MSEide+MSEgui:
https://sourceforge.net/projects/mseide-msegui/
MSEide+MSEgui is more advanced than fpGUI but it is a completely new approach of a GUI framework which does not inherit much from Delphi VCL structure. When I started the project I already worked with Delphi VCL some time and wanted to make something better. ;-)
MSEide is a handy and very productive IDE for Free Pascal and gcc projects. AFAIK Graeme uses MSEide in order to develop his fpGUI applications.
MSEide has a powerful integrated form designer for MSEgui components with support for visual form inheritance and submodules (frames) with the ability to add componets/widgets to inserted frames and which updates descendant forms in realtime.
In order to port MSEgui to iOS/Android the first step probably would be to update the experimental OpenGL backend to use shaders and to make it OpenGL ES compatible.
Another option is to use native widgets which are connected by MSEifi datapoint- and event-components with the Pascal program. Because smartphone GUI's must be simple it should be doable. For designing the GUI one probably would use the platform tools.
All MSEgui edit- or display-widgets have a "ifilink" property which can be used to connect the program logic the same way -> the program logic units can be used in order to build the desktop version of the program with MSEgui widgets too.

[airpas]

msegui/ide is good as a lightweight rad with a nice set of components,  but has some drak sides : the project file is not backword compatible (if u have a project made with the version 3 , then it probably wont work with the new 4.2 ) , another thing is the source code , its not commanted at all , that means the author does not reckon for contribution :/ .
and the most important thing  , the documentation .

[mse]

msegui/ide is good as a lightweight rad with a nice set of components,  but has some drak sides : the project file is not backword compatible (if u have a project made with the version 3 , then it probably wont work with the new 4.2 ) ,

If stored properties of MSEgui components change I add code which automatically converts old *.mfm's while loading. Please load all forms in the new MSEide, RightClick-'Touch all forms' in one of the forms, 'File'-'Save all', that will write updated *.mfm files to disk.
If the conversion code is expensive I remove it after some MSEgui versions. If one loads an incompatible form afterwards the *.mfm file will be opened in source editor for manual fix-up. Often it is enough to delete the problematic rows.
IIRC the last time I removed conversion code was before MSEide+MSEgui version 3.0.

another thing is the source code , its not commanted at all , that means the author does not reckon for contribution :/ .

That is not true! What is not obvious by reading the code *is* documented. The fact that I still can work with MSEgui code written in 1999 proves it. ;-)

and the most important thing  , the documentation .

The problem with the documentation is that it is scattered to many different places. None of the MSEide+MSEgui users was able to take over the task to coordinate the documentation process. Recently Michael Ebner made a new attempt:
http://wiki.freepascal.org/Reference:_MSEgui/TFace
http://wiki.freepascal.org/Reference:_MSEgui/TFont
http://wiki.freepascal.org/Reference:_MSEgui/TFrame
http://wiki.freepascal.org/Reference:_MSEgui/TLabel
http://wiki.freepascal.org/Reference:_MSEgui/TMseComponent
http://wiki.freepascal.org/Reference:_MSEgui/TSimpleWidget
http://wiki.freepascal.org/Reference:_MSEgui/TWidget
Maybe you can help?
If you have questions simply ask:
https://www.mail-archive.com/mseide-msegui-talk%40lists.sourceforge.net/
https://sourceforge.net/p/mseide-msegui/mailman

[Blade]

The only working (and I recommend) path for Android is to use LazAndroidModuleWizard. I never code for iOS, but the same author who produces component set used by LazAndroidModuleWizard also creates the equal component set for iOS. The author of LazAndroidModuleWizard recently creates LazArduinoModuleWizard, if you can convince him (probably providing him iOS device) he might be willing to create LaziOSModuleWizard.

I find this quite interesting.  Sad that a LaziOSModuleWizard never came about, or at least not yet.  I wonder if the author who produced the iOS component set is still active or willing.  Appears he did an update in 2018, https://blog.naver.com/simonsayz/221209784815

[Michael Collier]

Hi Phil

What you say intrigues me..
But the link seems broken for item (3) https://dl.dropboxusercontent.com/u/28343282/MacXPlatform/PascalDynLibs.html
Do you have another link available please?

Jim,

I really only see 3 realistic approaches for using Free Pascal in iOS development. They assume that the iOS headers have been parsed using Ryan's parser and that UI design uses iOS native controls and conventions.

(1) Write UI code in Objective Pascal without a designer. Virtually any IDE or text editor can be used. Write scripts for doing all the stuff that Xcode does for you automatically when building the .app bundle.

(2) Take a "hybrid" approach with Xcode, where the project has "dummy" ObjC files that are used only for UI design using the Xcode designer; corresponding Pascal units are what get compiled into the executable. I used to have templates for creating this kind of project in Xcode, but they were too much work to maintain (and very little interest from developers), so they're abandoned. Instead, just create the project with a script using an existing boilerplate project:

https://dl.dropboxusercontent.com/u/28343282/ObjP/ProjectXC.html

(3) Use Xcode per normal and write UI in Swift; all other code (ie, bulk of app) goes into a Pascal dynamic library. This allows normal use of Xcode UI designer and all other Xcode features that make life easier for the developer. Library code can then be shared with Pascal apps on other platforms.

A variety of examples that use the same Pascal library are here:

https://dl.dropboxusercontent.com/u/28343282/MacXPlatform/PascalDynLibs.html


Thanks.

-Phil

[trev]

You are replying to a post from 2016 - six years ago. Phil has not logged on since 2018. You are unlikely to receive an answer.

[Michael Collier]

oops, thank you.. I must have been thinking of Blades reply from a few months ago when I posted, thanks for letting me know