Hello guys, I would like to receive suggestions or critics about a modification I need or not to do that will require several hours of work because it would be a complete redesign of the data management of one app.
Originally the app had to manage only one language (italian), and a fix content and help system, everything not editable by the client. The client is not the end user of the app, he just sells the app to his customers, the users of the app. So, the data management was based on TinyDB that is persistent and simple to manage also in multi screen app.
The client now asked to support 6 languages and the ability to modify/insert the contents by itself and eventually modify/correct something in the app help system. So, I thought that the most reasonable solution was to use a local DB based on sqllite 3 that makes possible to realize also a support program running on MS Windows or Linux. But after some test the results are that using sqlite query to load the app widgets is too slower compared to TinyDB.
So, the quickest solution I can make is to load the TinyDB tables (i have several TinyDB instances) from the sqlite DB adding some checks to write them once or if the user needs to update the DB. But seems to me that the most natural and performant solution should using dictionaries writing them at each startup of the app. To don't slow the app during the change of the screen I would write the dictionaries in Screen1 that manages the startup but the problem I have is to pass the dictionaries between the screens because they are not global to every screen.
Because each screen needs at least 2 dictionaries I am trying to pass them throw a list.
I made a test converting 2 TinyDB instances to dictionaries, it works and the speed also increased well.
The only thing I do not like so much is passing the dictionaries between screens using a list and I am asking if anyone had a similar problem and he solved better then me or someone knows an extension that may be useful in this context.
To be honest, until now, every time I need to pass more data between screens I always pass forward and back a list containing the data also of different type, of course I have to put attention to assign the right variable following its index in the list.
N.B. The app is quite complex, before the modifications it had about 4000 blocks, 7 screens and each screen at least 2 views so think to design or modify it to work just using one screen is not possible.
Sure but they are persistent, saved somewhere in flash so, having already a sqlite DB is like having a double only to solve the speed problem because reading from sqlite is too slower in this case. Instead dictionaries are stored in RAM.
I learned that simplesqlite is not persistant among screens. I mean that if you open the DB in Screen1 and you need it also in other screens it is not sufficient to leave open the DB and have a simplesqlite instance in each screen where it is needed, you have to assign the name of the DB and open it in each screen. Did you find a different solution to pass several data between screens instead using lists?
There is no such thing in AppInventor. You can use initial values if the data is to be in ram (This method probably uses intents and is used in java to pass data between two Activity) or TinyDb. And to avoid passing data between screens, you should use arrangement layouts instead of screens...
As I suggested, store and load with tinydb between screens. it is not in memory, but likely the quickest option.
For updates to sqliteDB, you may need a routine to take the user to a particular screen to fulfil that requirement, to save having to load/open the sqliteDB on each screen
And, for what it is worth, with all your data shunting shenanigans, it might at least make sense to setup a test project that uses virtual screens on just one real screen. This should reduce your block count, and make data sharing (amongst the virtual screens) much easier.
Too complex to manage using just one screen... the aia I am modifying has 7 screens and each one has 2 or 3 virtual views at least, there about 4000 blocks in total. There are few procedures copied in some screens.
Yes, I did in little projects but in this case there are 7 screens, each one has at least 2 o 3 arrangement layouts and in total there are about 4000 blocks. I think it is too big to be managed in only one screen.
And where exactly is the problem to do it like this in each screen?
Alternatively use a sqlite extension which is easier to use and does not need assignments or opening the database before being able to use it..
Since you use the same data on several screens, it means that you are repeating many blocks on screens. Building everything in one screen, and modifying your blocks, would lower the total number of blocks.
No, not really. The screens have a specific behaviour so the data are mapped quite well to the screens. There is only a set of data common to every screen used to setup the GUI colors, fonts and so on, so that changing a DB table you can change the GUI appearance.