Charmed Quark Systems, Ltd. - Support Forums and Community
Android RIVA Client: taRiva - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (https://www.charmedquark.com/vb_forum)
+-- Forum: Third Party Development (https://www.charmedquark.com/vb_forum/forumdisplay.php?fid=8)
+--- Forum: Android Related Products (https://www.charmedquark.com/vb_forum/forumdisplay.php?fid=24)
+--- Thread: Android RIVA Client: taRiva (/showthread.php?tid=6721)



Android RIVA Client: taRiva - batwater - 11-25-2010

Fonceur Wrote:Since it is a full disconnect on sleep, followed by a brand new connection on wake, there is no way to get back to the previous point...

Understood, thanks for implementing the reconnect!


Android RIVA Client: taRiva - SamVimes2 - 11-25-2010

There was some discussion in the iRIVA thread about using a variables driver to maintain state - there are a few different variations, but basically, your navigation scheme would update a "Variable.LastTemplate" with a template name each time you loaded one, and your startup template would load "$(Variable.LastTemplate)" in its OnLoad action.

Dean has indicated that some kind of session broker/manager might make it into RIVA at some point in the future, allowing a session to keep running in memory on the server even after a client had disconnected, so that the same client could reconnect mid-session. Feel free to nag him to move it up the list :-)


Android RIVA Client: taRiva - batwater - 11-25-2010

SamVimes2 Wrote:There was some discussion in the iRIVA thread about using a variables driver to maintain state - there are a few different variations, but basically, your navigation scheme would update a "Variable.LastTemplate" with a template name each time you loaded one, and your startup template would load "$(Variable.LastTemplate)" in its OnLoad action.

Interesting, I will have to look into that.

SamVimes2 Wrote:Dean has indicated that some kind of session broker/manager might make it into RIVA at some point in the future, allowing a session to keep running in memory on the server even after a client had disconnected, so that the same client could reconnect mid-session. Feel free to nag him to move it up the list :-)


Nag, Nag, Nag, please. Confusedhock: Seriously though, considering the proliferation of smart-phones and tablets and having 2 of the 3 main platforms covered (I'm sure we will eventually see the new WinMobile covered as well) this would be a good thing from a UAF (user acceptance factor) Not only having the bases covered this also plays well into the "green" concept of allowing the devices to go to sleep, saving energy and then coming back on line where they left off. All good things :cool

Thanks for listening!
-Ben


Android RIVA Client: taRiva - Dean Roddey - 11-25-2010

It would have to be some along the latter lines. Trying to get back to where you were won't ever really work. You could have been in a popup or some other situation where lots of state info was driving it. And most folks probably only have one base template with an overlay, so you'd always be effectively on the same template.


Android RIVA Client: taRiva - Dean Roddey - 11-25-2010

BTW, the way it's likely to happen is that we are going to have to implement the licensing limits for clients at some point. That will involve also a benefit, which is that the definition of clients will move to the master server config, and you will be able to indicate that the so-and-so client is one of the clients on my system, and that it will log in with this identifying name, and you'll add that to the login on that client (in the environment or whatever that type of client uses.)

This way, the master server knows what all of them are, and can re-identify them if they log back in, and it can track the number of clients slots because it's not a runtime thing anymore, it's a configuration thing. And that will also mean that for ones that are configured as RIVA server clients, you'd be able to indicate that you'd like this one to remain active all the time, so that you can connect to it at any time. Others you could configure to come and go as the client to reduce overhead, such as perhaps one you'd use from the road.


Android RIVA Client: taRiva - sic0048 - 11-26-2010

SamVimes2 Wrote:There was some discussion in the iRIVA thread about using a variables driver to maintain state - there are a few different variations, but basically, your navigation scheme would update a "Variable.LastTemplate" with a template name each time you loaded one, and your startup template would load "$(Variable.LastTemplate)" in its OnLoad action.

That is what I was going to suggest. It is actually pretty easy to do as well. Simply add 1 Write field in the templates OnLoad action that sets a variable driver field to the name of the current template.

Then on the initial template (the default template that gets loaded first), include an action that will read the variable field and load that template. It is easiest if you actually write the exact name of the template into the variable driver field and then use the contents of the field to load the template. Otherwise you'll have to use a bunch of if/else commands.

So it will look something like this:

Each Template = Fieldwrite (variable_driver.template_field)

The Preload of the Main Template = Load Overlay(or template)%(variable_driver.template_field)

(The structure of the commands is not correct, but hopefully you get the idea).


Android RIVA Client: taRiva - Fonceur - 11-26-2010

sic0048 Wrote:Simply add 1 Write field in the templates OnLoad action that sets a variable driver field to the name of the current template.
The issue with that solution is that it breaks down as soon as you have more than one client... Unless you go for some kind of one user per client and maintain their states (like say one variable driver per user), similar to what Dean is suggesting...


Android RIVA Client: taRiva - sic0048 - 11-26-2010

I simply create a unique login for each device. Since the device will auto login, there isn't any action required by the user. I then use the rtv "user" variable to write to the correct variable driver field. So the action commands are the same so only one set of templates are needed.

It looks something like this...
Fieldwrite (%(rtv_user)_template_name)

Edit - this assumes I've created one variable driver field for each user. Something like Brian_template_name, droidx_template_name, etc, etc.

Hope that helps.


Android RIVA Client: taRiva - Fonceur - 11-26-2010

sic0048 Wrote:I then use the rtv "user" variable to write to the correct variable driver field.
Ah ok, I didn't know that there was already a command to determine the connected user. Makes perfect sense then.


Android RIVA Client: taRiva - SamVimes2 - 11-26-2010

that's very clever!