Is porting a Windows app created w/Lazarus to Android practical?

[Derz]

I have an existing Windows GUI app created with Lazarus and feel it would be great to have on my Android phone.

However, I am wondering if this is a practical endeavor, particularly since I know very little about the Android OS.  So much is hidden or unavailable to users without rooted phones (and I would not want to root my S22).  Perhaps it would be better to experiment with simple apps first with LAMW, and see how that goes?

My app uses Lazarus StringGrid (including several "on Events"), file I/O, menu, toolbar, edit boxes and buttons, URL Launch, Cut Copy Paste..

I would particularly like to hear from anyone who has attempted something like this.  Is there an approach you'd recommend?

[lainz]

Hi, if porting means doing a new app: yes.

The advantage is that if you separated the business logic with the UI it should be less code to do.

But I/O is not that easy, because it has permissions and restrictions. (Usually you write the data in the app folder, thats invisible for the end user, and for you as well, except when you're debugging).

The UI must be completely new, according to mobile standards.

[Leledumbo]

Not sure what you mean by practical, but it is doable. Difficulty however depends on how the Windows app is coded. If you properly separate logic from presentation, it will be fairly easy.

So much is hidden or unavailable to users without rooted phones (and I would not want to root my S22).

You don't need root 96.69% of the time.

Perhaps it would be better to experiment with simple apps first with LAMW, and see how that goes?

Yes, I suppose that's the path you have to take first instead of hoping a magical transformation. With the screen size and touch based interface, it's not practical for LCL to be used in its current form, which is why LAMW didn't take that route (Custom Drawn used to take that, but it didn't go far, it cannot go far).

I would particularly like to hear from anyone who has attempted something like this.  Is there an approach you'd recommend?

Just as I wrote above: separate logic from presentation first, if the current one hasn't. You can take a look at how I structure my project, so that the main logic is contained in its own unit, with CLI, GUI and Android interface, as well as a dynamic library callable from languages understanding C ABI.

[maxerist]

I would particularly like to hear from anyone who has attempted something like this.  Is there an approach you'd recommend?

I'm not not that pro in LAMW, but I'm a half way to a result that might fit my needs with a software that was developed in/for Windows, ported later to Linux and now it needs to do something useful on Android :)

My random thoughts about the topic:

• if you have units without Windows dependency, they will likely be compatible out of the box. And ideal path here is to fine tune them porting an existing LCL/VCL app into Linux. In this case you will mostly keep your desktop forms and logic intact while fighting all things platform specific.
• if you have data modules (TDataModule) even with inheritance, this code will also might work right out of the box if it has not windows dependency.  This is useful for someone who has a large amount of database logic coming even from Delphi (Borland database framework-based). Obviously, the db driver should be compatible with Android. In my case this was a custom SQLite one working now on Windows/Linux/Android
• You should forget all about LCL/VCL controls in your new apps and turn yourself  to a new mindset (working with layouts mostly like they're explained in official Android SDK). The easiest way is to mass-compile and run the demos. They're very often very simple to understand, fast to compile and run and to modify in order to confirm your suspicions :). So, with everything connected and set up the usual time between opening an lpi file and seeing the result on your connected device is a matter of minutes, maybe even less than a minute. Now if I have some new control of interest, I find a demo with it using full-text search compile/run it
• Be prepared that the form designer in LAMW might be a mixed experience. It helps a lot, but often doesn't always show exactly how the layout will look on the device. So, trying to choose font size or relative sizes of elements and everything like this will likely require to running and seeing it with your own eyes. Luckily, the compiler is fast, it won't take much :)
• LAMW is a bridge working with native Android UI elements. LAMW has both pascal and java runtime. The former is compiled into libcontrols.so binary when you press Ctrl-F9, the latter is compiled when you prepare the apk file. You can finally edit even the java part and implement some calls to Android runtime that the developers either missed or decided not worth implementing. Sure you have to understand what JNI is for this. An example. The developers experimented with ShowAlert call (a simple modal message with and Ok button) but dropped it in later versions. I returned it for my own purpose with some adjustments.
• Android UI is non-blocking. This might be the biggest surprise for those coming from the desktop. This means that everything modal should be implemented differently. You just can't if MessageDlg(...) then and expect the code to wait for the user response. Android doesn't work like this. Sometimes changing the logic to fit this is painful sometimes not so.
• Be aware of any randomly popped up dependencies, they might keep the app comping but crash on run. The notorious case is to leave Controls in uses clause, it will pull some startup code that won't allow app to run. In any unexplained case, look into logcat, the Java exception will always be there
• My very serious hint is to set up a working debugger, there's a topic here at forum about this. If you're new to some platform/framework, you just often can't suggest to yourself why something is not working, the step-by-step debugger is a big help. It's not just about your own mistakes, LAMW has some speical implicit requirements you might just forget. For example, in order to use a j* class in runtime and not in design-time you still need to place it somewhere on a form, in this case a required code snippets are added, but if you forget to to this, you can see that just something doesn't work. With debugger you really can see in LAMW code that some object is nil and remember what you forget to do

Just my two cents...

[loaded]

I have an existing Windows GUI app created with Lazarus and feel it would be great to have on my Android phone.

You're not the only one who thinks so! That's what I thought too.
I would like to give an example;

My application running on windows;
https://youtu.be/5yhI1uq-3yM

Translated to Android;
https://youtu.be/gBS0AMrJ50s
Although it was a bit difficult (for me) , I think it was worth it.

[c4p]

Wow, impressive!
A lot of work has gone into that.