cordova How about Cordova + uniGUI ?

[Fred Montier]

Any thoughts ? Any expert on that subject ?
Any PWA ideas ?

[Norm]

Cordova + uniGUI is not a possibility.

The way Cordova works is that it builds a wrapper around web applications written with HTML+JS+CSS and outputs it as a native mobile app targeting iOS or Android. What is crucial is that Cordava expects the components that make up the web application to consist of a single html file and accompanying js & css files. What Unigui (ExtJS) produces is too fragmented to work with Cordova.

Cordova itself, while magical in what it does, is poor at producing good UI's. So it depends on frameworks like Ionic and Onsen UI for building the user interface. An interesting development is that Ionic are working on their own Cordova equivalent called Capacitor that is looking very promising and, in my view, will replace Cordova.

[Fred Montier]

Nop. Of course it won't pack win binaries in Cordova. That is not the point in my question. Cordova is not for UI. Never was. You can pack a simple start page and call it a PWA-ish , just joking, with it.  But I was thinking as an entry point to uniGUI backend.

Using uniGUI as a backend to a start page is more likely as many packaging tool are doing this to deliver "fake" PWAs. The problem is a stateful x stateless using Cordova, if there is any issue, on that delivery "phase" towards the stores.

OnsenUI  (only) is long gone. Dead end. Is a nice UI pack and very light but not more than that. I'm more in love with Webix. Like that UI  pack, there are dozens.

By the way, I'm working in 3 projects using Onsen right now. I loved how light-weight and easy to use it is. But more like a bag of UI Comps than the whole revamp Webix does to UI. And they are more focusing in the Monaca cloud solution. Something that Embarcadero should had a whole cycle solution working by now based in pascal only, to not alienate the "old-timers" like me.

But they are shutting down now for almost a year (not much improvement in UI area). I tried and works like a charm to uniGUI front end replacing ext.js comps and no problems in Apple "eco", that you can find using Ext.JS by uniGUI. Many users had complains about it in theirs IPhones. Some times load the uniGUI app, and others don't. So, we change all UI for Onsen and using uniGUI as back end. Light and fast. And funny thing, really looks like an Apple native app in iPhone.

Anyways, Onsen: old and broken examples (like the Youtube API)  and no community around it. 

But thanks anyway for your words. I found weird that nobody here at the forum  never try it with uniGUI as back end solution , of course , it never will be full flagged pwa.

 

[Norm]

Sorry Fred,  I misunderstood your question.

Of course any Cordova created app would work with UniGUI as the back-end.

I've been using VueJS with UniGUI as back-end successfully for some time now to create serious PWA apps that, once launched, can easily work without internet and, if necessary, buffer the data until internet is available. VueJS has added great state management with the Pinia addition.

Of course I had to build my own UniGUI session management. It's a shame that your call for a bare-bones uniGUI has not been taken seriously by FMSoft. All they need to do is give us the option to have session management that is not tied to ExtJS.

I hope Farshad is listening.

[Stemon63]

Interesting topic...
Is there any example of how you use Unigui as a backend?

 

[Norm]

Hi Stemon

It’s not easy to provide an example of “using UniGUI as backend" because the code is all over the place. What I can do is to provide an idea of the concept I use. This is going to be a bit of a ramble and I apologize in advance but I don’t see how I can answer your question otherwise. Who knows, this might result in an interesting forum discussion.

It is obvious that any web-based application can talk to your UniGUI app, regardless of the language it is written in. Also, everybody knows that a full-stack web application consists of a front-end and a back-end. I occasionally work on small projects that are built solely around UniGUI. But when it comes to complex UI’s I prefer to use a frontend specific framework that will talk to my UniGUI backend, and VueJS has become my go-to solution. VueJS is easy to learn without being an expert in HTML & JS, e.g. you don’t have to know anything about promises, async etc  to produce a respectable application and there are tons of free add-on component for anything you can think of.

The reason for using a frontend framework are obvious:

-         - Automatic PWA

-         - Full responsiveness

-          - Fast

-          - Offline capability etc.

The question is why use UniGUI as backend when I could be using one of the traditional solutions like NodeJS which offer better session and state management. The reason is simple, Delphi.

-          - I think Delphi is still one of the most powerful development environments around and I love UniGUI for keeping the language alive.

-          - I have tons of “behind the UI” business code in Delphi that I have been able to bring into the UniGUI backend with very little change.

Now to your question about how I use UniGUI as a backend:

When you compile a VueJS application it spits out 3 files, an INDEX.HTML, a JS & CSS and also an ASSETS folder that contains all required images etc. In addition VueJS will spit out all the files you need to run the application as a PWA (Service Worker, Manifest.json, Favicon and multiple home screen icons).

I copy all these into the “files” folder of my UniGUI exe and I simply serve the index.html to the first GET request that hits my url. For all intends and purpose that is all that is needed for the frontend application to run in any browser. Provided the browser does not need to come back to GET or POST data you can turn the internet off and the application will continue to run happily.  There is no need to look after sessions etc. That is how you can create a happy website. If the website has the function of serving database based information or images this can be retrieved from UniGUI and stored in the browser-based IndexDB before turning off the internet. For larger databases Google provides the free and powerful Firebase9 that is easy to use, but obviously require an internet connection.

However, in almost all of my situations the UniGUI backend (MyApp) needs to keep in touch with the browser frontend in order to serve and receive data. I think this is the crux of your question. In this case I obviously need to create sessions, validate credentials and listen to and respond to subsequent HTTP requests. I should make in clear that, so far, my projects have been transactional in nature as far as data exchange is involved. So HTTP requests only involve GET & POST commands. There is no CRUD requirement.

These are the steps I follows:

-          The index.html file is served at initial request

-          A login POST in returned from the browser, with the required credentials.

-          MyApp validates the request and if successful generates a sessionID and feeds it back with a “successful” response

-          MyApp continues to maintain the session alive and respond to GET & POST request until either a LogOff request is received or the session times out.

SessionID : I generate this using a combination of the user’s IP Address and the current time-stamp. The ID must accompany all subsequent HTTP requests.

Session TimeOut : I use uniThreadTimer with appropriate CriticalSection locks to monitor and terminate non-active sessions. A session times out if no GET, POST or “Ping” requests have  arrived within a given period.

All GETs & POSTs are handled within a CriticalSection and they shepherded to a data module that does what it needs to do and returns a json response that is fed back. This is the weekest part of my solution because all HTTP requests are queued up and handled one at a time. This would not be practical for a very busy site. I don't see any other option however and so response has been excellent.

That is why a FMSoft provided session management would be so helpful. I continue to pay my subs with the hope that one day....

Anyway, here is a brief idea of what the ServerModule does.

procedure TUniServerModule.UniGUIServerModuleHTTPCommand(

  ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo;

  var Handled: Boolean);

var

  aParams : String;

  aStream : TStream;

  aPostBody : string;

  aHTML : String;

  aData : TStringList;

  aRespNo : Integer;

  aRespText : String;

  aLogInfo : String;

  aIPAddress : String;

begin

  aHTML := fsFilesPath +'index.html';

  if (ARequestInfo.Command = 'GET') and (ARequestInfo.URI = '/') then

  begin

    if FileExists(aHTML) then

    begin

      aData := TStringList.Create;

      try

        aData.LoadFromFile(aHTML);

        aPostBody := aData.Text;

        AResponseInfo.FreeContentStream := True;

        AResponseInfo.ContentStream := TStringStream.Create(aPostBody);

        AResponseInfo.ContentLength := AResponseInfo.ContentStream.Size;

        AResponseInfo.ResponseNo  := 200;

        AResponseInfo.ContentType := 'text/html';

        Handled := True;

      finally

        aData.Free;

      end;

      exit;

    end

    else

    begin

      AResponseInfo.ResponseNo  := 500;

      AResponseInfo.ContentType := 'text/html';

      Handled := True;

    end;

  end

  else if ARequestInfo.Command = 'POST' then

  begin

    aParams := UpperCase(ARequestInfo.URI);

    aIPAddress := ARequestInfo.RemoteIP;

    aLogInfo := 'POST' + ', '+ aParams;

    aStream := ARequestInfo.PostStream;

    if assigned(aStream) then

    begin

      aStream.Position := 0;

      aPostBody := ReadStringFromStream(aStream);

      aRespNo := HandleHTTPPostRequest(aPostBody, aIPAddress, aRespText);

      AResponseInfo.ResponseNo := aRespNo;

      AResponseInfo.FreeContentStream := True;

      AResponseInfo.ContentStream := TStringStream.Create(aPostBody);

      AResponseInfo.ContentLength := AResponseInfo.ContentStream.Size;

      AResponseInfo.ContentType := 'application/json';

      Handled := True;

   end

  end

end;

[Stemon63]

Hi Norm,
Thanks so much for the detailed explanation. Very interesting.
But a spontaneous question arises in my mind:
At this point, if Unigui must basically act as a backend server, why not use VueJs as a frontend and specialized tools written in Delphi, such as Xdata, Mormot, KbmMW, DelphiMVCFramework, as backend?
Thanks a lot

[Norm]

Your question is a very valid and logical one. The reason we are using UniGUI is because it allows us to bring over our large volume of legacy code with little change.

Our area of software development is in the financials field. We have invested a lot of money and time in developing what I call a Financial Accounting Engine that we now use in all our projects. I designed the software over ten years ago and contracted some Delphi experts to help with the coding. We chose the DBISAM SQL database for our product instead of the Borland BDE because it is written in Delphi and has many hooks that allowed us to design our own middleware to address things like providing a JSON based API that allowed third-party products to interface with our financial system.

When we started looking at web access we seriously looked at TMS WebCore and XDATA as a potential pathway but it had too many unknowns and the effort required for the conversion was unsustainable.

I am very happy with the UniGUI solution we have implemented in spite of the shortcomings  I mentioned in my previous post.

To give you an idea of the kinds of projects we work on we have implemented a financial system for Wholesale Bakers that supply products to cafes and restaurants (bread, bagels, croissants etc). Before the end of each day the owners use our PWA app on their devices to place orders for the next day. At the end of the day the system generates and dispatches invoices for the ordered goods and provides the baker with reports listing both the quantities of each product and recipe measurements of ingredients required for each product category (flour, yeast, sugar etc).

[Stemon63]

OK, Norm. I understand 🙂