Reactive Apps+Server

Hi,

I would like to write a reactive app. That is an App that a user can log in, and if the user makes changes in a database (MySQL), those changes are automatically “broadcasted” to all other users who have running Apps, and the data gets updated in the controls. I have difficulties understanding how this can be done with Xojo.

Creating an app, i am running a server, I have apps connecting to the server via different IP addresses (presumably, although in some cases, it could be the same IP addresses but different users, such as if a number of users are behind the same subnet/firewall). And when the server processes a change in the database, there is a need to call methods (or raise events) for all other apps connected, so that update code can run.

But, how can this be done in Xojo ?

thank you,

Dan

I’m assuming that you’re talking about everyone hitting the same web app. In that case, each user has their own WebSession object. So, if you need other users to get information from one session to the others you can have the app object send that data to all the current sessions by iterating through the sessions. Each session then has to deal with the information as you need.

At one point there was a Chat example but I don’t see it in the current examples list.

Hi Bob,

Thank you for your response.

I noticed the chat app a little while ago, its in the Examples, Sample Applications folder, but couldn’t figure it out – the chat app for some reason doesn’t run on my computer (win7) – pressing run makes it seem to start, just to abort without error, and no browser window loading.

Looking at the code, I don’t see code that iterates through sessions. There is the App object which has an array defined which just adds messages to a web listbox and apparently this automagically gets sent to all web apps currently connected to the server. I don’t understand the mechanism at work …

In general i am also wondering if there exists an object that is “server bound” i.e. it only exists once on the server, and properties (values) could be shared across web apps. One way to accomplish this is to use the database, but i am wondering if for performance and consistency reasons it wouldn’t be better to have the such shared data stored on the server in memory.

thanks,

Dan

p.s. i looked at the websession object and can’t see how it can be used to send data

Okay. Found it.

It’s doing exactly what I was saying. When the user opens the app in their browser (they get assigned a session automatically) and the ChatPage is opened. In the ChatPage.Open event it adds itself to an array in the app object. Remember all code runs on the server and the browser only sends events to the server.

So when the user hits the send button it calls the App.SendMessageToAllClients which iterates though the array and sends the data to all ChatPages.

The same thing could be done by having the app iterate through the sessions using SessionCount and SessionAtIndex. http://documentation.xojo.com/index.php/WebApplication.SessionAtIndex Then each session could iterate through the pages in that session to find the right page using PageCount/PageAtIndex http://documentation.xojo.com/index.php/WebSession.PageAtIndex and passing in the data that way.

thanks.

Yes, I now figured out how to do this with Session after seeing that via Session one can access a Page. Below is some code I came up with – although I’d like to really understand how the chat works.

dim wp as WebPage1

app.counter=app.counter+1

For i As Integer = 0 To App.SessionCount-1
wp = WebPage1(App.SessionAtIndex(i).PageWithName(“WebPage1”, false))

if wp <> nil then 
  wp.updateCount
end if 

Next

many thanks,

Dan

The code above btw, runs in the session.open event hander

I think I figured it out now.

Apparently, the server keeps track for each web page the web client it belongs to. So, to update a listbox on any web clients its enough to globally keep a reference to of the web pages the listbox is included.

I think this is quite amazing.

Dan

It can be hard to wrap your mind around Xojo web apps. NOTHING really runs in the users browser. All code is executed on the server. So the Sessions and WebPages all execute their code on the server so they only thing they’re ‘pushing’ to the client browsers is the HTML/Javascript string so it can render everything.

I wonder how Xojo compares to Meteor (www.meteor.com)…

I am essentially seeking to develop similar reactive functionality across web app clients.

[quote=183092:@Daniel Gross]I wonder how Xojo compares to Meteor (www.meteor.com)…

I am essentially seeking to develop similar reactive functionality across web app clients.[/quote]

I’ve never used meteor but looking at their documentation I can tell you this: If you want a website (emphasis on site) use a tool that makes websites.

Xojo makes web apps. Big difference. Some of it usability, some of it is scalability. Some people have gotten Xojo to look like and act like a website but I don’t think you’ll be happy with it. An example: Xojo web apps can’t use the Browser back button because it will leave the web app. That’s not how most web sites work but many web apps are just like that.

Figure out what you really want to do, first, and then figure out the tools to do it. Xojo web apps are not for every occasion.

Many thanks for the thoughtful reply and infos.

For this prototype project I am trialing now, i am very happy with Xojo, and hence web app. I am hoping that I will be able to wrap the app into a chrome plugin, but even if i can’t do this, i would be happy with the result.

For another project, I am not sure yet whether it will require a website or whether a web app would suffice. Possible several web apps could do the job.

There are many things to like about Meteor. One in particular is its approach to reactivity programming, and in particular how reactivity infrastructure coding has apparently been made invisible for the programmer – i.e. its non-existent. The programmer uses regular programming abstractions, which are automagically made persistent and reactive.

I am hoping to create something similar for Xojo – at least, it would be nice if i can get there, from where i am now.

Agreed for the most part. Relatively static content is handled better in other systems. One trick to remember is that you can always host a Xojo web app in an iframe of a larger, static site (i.e. WordPress).

You can actually work around this and support back/forward buttons, but it takes some work and forethought.

Be careful how you do this so that you do not create any lingering hard or circular references, i.e. a session has closed but its page is still taking up memory because you have a reference to it in a global location somewhere. WeakRefs are good here.

Thanks Taylor.

Can you explain this a bit further, perhaps with a short example. I am not sure how WeakRefs would be used.

It seems to me that Xojo is essentially the opposite of a stateless web app – its not only stateful, but state is global across all sessions, but, classes and instance variables/properties seem to be non-global – although, in theory i may even be able to write an app where a reference to an object is handed across different apps that connect via different sessions.

[quote=183124:@Daniel Gross]Thanks Taylor.

Can you explain this a bit further, perhaps with a short example. I am not sure how WeakRefs would be used.[/quote]

Let’s say that you’re going to keep an array of WebListBoxes that need to be updated. You keep them in a Module property (i.e. a global if you will) called UpdateLists. Every time a Session opens you grab the ListBox and append it to UpdateLists.

It’s important to remember that there’s a list box in the client browser, but the Xojo server app holds the instance of the WebListBox class with all the properties representing state. The browser list box is merely a reflection of this server side instance.

If you do not remove the ListBox from UpdateLists in Session.Close then the user may close their browser, but at least part of the memory allocated for the Session (i.e. the ListBox) will remain because you’re holding a reference to it in UpdateLists. Now if you are careful to make sure every ListBox that you add is removed later then you’ll be fine. But if there’s a bug which prevents removal, you’ll have a memory leak.

A WeakRef does not count for purposes of object/memory retention. If you add WeakRefs to UpdateLists in Session.Open, and a bug prevents their removal in Session.Close, the memory will still be released. If the Session closed and the ListBox instance is gone, the corresponding WeakRef will return nil.

Whether or not to use WeakRefs is a design decision. Not saying you have to. Just be careful when keeping references to Sessions, pages, controls, etc. so that you do not create a memory leak. A desktop app accepts input from one person and gets restarted frequently. A web app is expected to run for very long periods and handle many users, so memory leaks can become critical. If a mistake means that Sessions are never disposed of and your web app is popular it will quickly run out of memory.

Xojo Web is definitely stateful. I’m not sure precisely how you’re using “global”, but…if there are 1,000 connected browsers then there will be 1,000 instances of Session.

  • There is only one set of shared properties for any class.
  • Each instance of Session (or any class) will have its own set of non-shared properties. In this sense they are not global.
  • However, any piece of code in the app can get to the public properties of an instance if it can get, or is provided, said instance. In this sense instances and their properties are globally accessible. You can have code which loops through every Session instance and reads the public properties, for example.
  • Pages are stored in a non-shared property of a Session instance. (Though we get to those pages via methods like PageAtIndex, so the property is private, but can be accessed with public methods.)
  • Controls are stored in a non-shared, private property of WebPage. Again, there is a set of public methods for accessing the contents of this property.

I hope this is helping and not actually making things more confusing. As I said in the other thread, Xojo web is much closer to ASP.NET…in this respect…then to, say, a JavaScript app talking to a PHP back end.

Thanks for the explanation. I need to reflect on this a bit to grasp the details.

I am trying to create an Model View Controller (MVC) type architecture. There would be model and controller classes in addition to the implicitly instantiated view objects.

I am wondering where should the references to model and controller classes be held. Here are a number of options:

  1. as App properties – this is probably incorrect since App is likely instantiated only once on the server.
  2. as Session properties – this could work, depending on whether sessions is persistent across all the time a user works via a browser with a web app (what about time outs, due to inactivity)
  3. as a MainPage window property.
  4. as module property

Which of these choices is best-practice?

Also, is there a document describing the lifecycle of key objects such as app, session, MainPage, modules and custom classes/objects.

thanks,

Dan

“Also, is there a document describing the lifecycle of key objects such as app, session, MainPage, modules and custom classes/objects.”

With lifecycle I am, relative to any significant event that affects the objects, such as system startup, browser connecting, time-out, etc.

[quote=183165:@Daniel Gross]I am wondering where should the references to model and controller classes be held. Here are a number of options:

  1. as App properties – this is probably incorrect since App is likely instantiated only once on the server. [/quote]

A Xojo web application on the server has one App instance. So not a good place.

A Session instance represents a browser window or tab. If you create/connect two tabs in a browser you literally have two Session instances in the Xojo web app. If there’s a break in communication then that Session instance is lost, and if the user reloads a new one is created.

This is important to think about early on if you want greater persistence. You end up having to create your own UserSessions and finding a way to map Sessions to them. A bit complicated, but doable.

Each Session will have a unique instance of your page. I don’t know if that helps or not. In trying to apply MVC to Xojo web, you might think of a page as being the view. It’s not necessarily wrong for the view to hold instances of the model and controller, but you may prefer to have them in Session.

This has the same problem that App does (one module property per web app).

Since the Xojo framework doesn’t formally implement or adhere to MVC, it’s up to you. In my experience Xojo projects…and many .NET projects for that matter…end up with M(VC) if you will. The window (desktop) or page (web) ends up being both the view and the controller through event handlers. You may see strong model abstraction, but not very strong separation between view and controller.

Personally I’m adamant about a properly abstracted model. But in event orientated frameworks like Xojo’s I’m less adamant about proper views and controllers unless the project calls for it.

I’m not sure if that’s in the docs some where or not.