Forum > Operating Systems

Mobile dev.: Lazarus or Xamarin?

<< < (2/4) > >>

Phil:

--- Quote from: tk on October 17, 2016, 12:55:32 pm ---Thank you all I will go this way.

--- End quote ---

Here are the steps I would use:

(1) Make sure your Pascal codebase actually compiles and runs correctly under iOS and Android, both 32-bit and 64-bit arm. These platforms supply libraries for HTTP. If you're not using them, then you need to make sure your desktop-tested communication code works on mobile too.

(2) Decide whether you really want to mirror exactly your Pascal classes in your wrapper classes. In my libraries, I did not want that at all. I wanted a more "controlled" subset of methods exposed via the wrapper classes.

(3) I'm not aware of any tool that does what you want to do. You may find that a lot more work than you think. It depends on how much you want to expose in your library. A handful of methods? Just do it by hand like I did in the example NDFD library. 500 methods? Well, maybe there it might make sense.

If you do create that kind of parser/generator, please let us know. I'm looking now to wrap the GDAL library functions in Pascal classes. It has hundreds of functions, so automating it could be very useful.

-Phil

tk:

--- Quote from: Phil on October 17, 2016, 04:57:27 pm ---Make sure your Pascal codebase actually compiles and runs correctly under iOS and Android, both 32-bit and 64-bit arm. These platforms supply libraries for HTTP. If you're not using them, then you need to make sure your desktop-tested communication code works on mobile too.

--- End quote ---

This I have to. Actually there are/will be several dyn libs. The central one where I want the generator for uses small scale plugins (other dyn libs written also in Lazarus) to do the actual UDP/HTTP communication. I/we hope the central dyn lib will work. If the UDP/HTTP plugin does not work on Android or iOS I have to create another plugins for them. Now I use Synapse for UDP/HTTP plugins and it works for me under all major desktop OSes (Win/Linux/OSX).


--- Quote from: Phil on October 17, 2016, 04:57:27 pm ---A handful of methods? Just do it by hand like I did in the example NDFD library. 500 methods? Well, maybe there it might make sense.

--- End quote ---

For starters I have 5 classes and about 120 methods (20 classic methods  + about 50 properties (=50 getters+50 setters)). But there will be more. I think the generator has sense.

Actually I've made the COM TLB in Delphi already, the (r)idl and COM altogether works very well for me. Shame such great thing it is not platform independent.

My idea is to take such ridl (for starters even more reduced ridl, no guids etc.) and basically do the same thing as Delphi TLB generator or Visual Studio Interop Assembly generator does.
It will only use the lowest-common ABI denominator, the C header file, as you said in my other post (and what swig also uses).
No parser needed (actually only a standard XML parser for my XMLish ridl format).
I could even imagine to build a simple GUI in Lazarus later that could manage the XML ridl file in a similar way as Delphi ridl designer does.
This will need some work but definitely it will be less work than to manage 100+ methods by hand now, and doing maintenance later also by hand.

Phil:

--- Quote from: tk on October 17, 2016, 06:17:15 pm ---Now I use Synapse for UDP/HTTP plugins and it works for me under all major desktop OSes (Win/Linux/OSX).

--- End quote ---

If you need test code for various HTTP clients, the example NDFD library in part 3 can be compiled to use Synapse, Indy, FPC's HTTP client, or Apple Foundation-based code that uses the NSURLConnection class:

https://developer.apple.com/reference/foundation/nsurlconnection

Note that mobile generally means asynchronous.


--- Quote from: tk on October 17, 2016, 06:17:15 pm ---It will only use the lowest-common ABI denominator, the C header file, as you said in my other post (and what swig also uses).

--- End quote ---

Sounds like you already have the library written and the C header file for it? If so, you're already half way there. Instead of just talking about it, I would just plunge in and start writing those wrapper classes. In general, creating those is the least of one's problems, as I predict you'll discover for yourself.

tk:

--- Quote from: Phil on October 17, 2016, 06:37:36 pm ---If you need test code for various HTTP clients, the example NDFD library in part 3 can be compiled to use Synapse, Indy, FPC's HTTP client, or Apple Foundation-based code that uses the NSURLConnection class:

--- End quote ---

Thanks, this will definitely help me if I will have problems with the HTTP plugin.


--- Quote from: Phil on October 17, 2016, 06:37:36 pm ---Sounds like you already have the library written and the C header file for it?

--- End quote ---

Yes I have the dll but now only as a COM server, compiled in Delphi XE.
The same codebase is compilable/runnable in Lazarus (under Win, Linux&OSX halfway tested), but I have no dll/so/dylib, it only works when directly linked to a Lazarus app.

EDIT: Finally the library should work for major desktop and mobile platforms, if that was not clear to you before.

EDIT2: And of course, I would like to discuss this before I spend weeks on doing something that might not be needed at all (although, in the case of the generator I've talked about, I don't see incredible amount of work before me now, should not be that hard...).

Phil:

--- Quote from: tk on October 17, 2016, 06:54:21 pm ---Yes I have the dll but now only as a COM server, compiled in Delphi XE.
The same codebase is compilable/runnable in Lazarus (under Win, Linux&OSX halfway tested), but I have no dll/so/dylib, it only works when directly linked to a Lazarus app.

EDIT: Finally the library should work for major desktop and mobile platforms, if that was not clear to you before.

--- End quote ---

Yes, that's good. You'll want to be able to test it in as many ways as you can. With one of my libraries, I also test the code linked in as well as part of a COM server that's registered when the .exe runs. It's important that the code work the same everywhere.

With COM, clients discover the server via the Registry. With a library, you either let the OS load it (if it can find it), or you manually locate and load it yourself. The NDFD example library only does the former, meaning that the library needs to be somewhere where the OS can find it. With Windows, that typically means in the same folder as the .exe; with Linux, that typically means putting it in /usr/lib; with OS X, that typically means putting it inside the .app bundle. Note that with iOS, you must put the library in a local framework within the bundle.

To load the library manually ("dynamically"), you can declare a library function like this to provide flexibility:


--- Code: ---{$IFDEF LOAD_DYN}type TNdfdGetLibVersion = procedure{$ELSE}procedure NdfdGetLibVersion{$ENDIF}
  (VerBuf    : NdfdPChar;
   VerBufLen : NdfdUInt); {$IFDEF USE_CDECL}cdecl{$ELSE}stdcall{$ENDIF};
  {$IFNDEF LOAD_DYN}external LibNameBase;{$ENDIF}


--- End code ---

In Pascal, to load the library, use LoadLibrary. Then determine if it has the functions you need using GetProcAddress. With other languages, you'll need to figure out how to do this. I omitted this option to keep my example library relatively simple.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version