App for indoor bouldering - bad performance - please advise


Since this is my first App ever, please don't be too strict to me, I know that my code is far away from being good in any manner.

During the Covid time, we started a project for indoor bouldering and we needed an app for this. Maybe you have heared about the "MoonBoard", our board is comparable to this. But not the app.. It is really not the same, my app is just for the "basic" functions.

I had lots of headaches when I made the app, mostly I had timing problems since I need to work with a MySQL database. The app is using the AI2 mySQL Interface (puravidaapps), so it is needed to have the script for querying the DB via php on a web server. Please note that if you test my blocks, you need to prepare a web server with the script and you need to edit the variables URL and SQLKEY on all screens.

Unfortunately, this app is terribly slow, even on good smartphones. The more boulder problems = list entries, the slower the app. I know I have some loops in my code, but I think that modern devices should easily be able to handle this. Maybe my logic is just crappy and that´s the reason why the app is so slow.

So far, the app is working and by now, around ten people are using it regularly. But you need to be veeeery patient when you use it..

Could you please have a look at my blocks and advise?
Since I´m a programming noob, I would be more than happy!


database.txt (65.5 KB)
App.aia (2.4 MB)

Here are some general obsrvations...

Screen1 is full of rubble, maybe from incomplete transition from multiscreen design?

Check that you are closing screens as often as you open screens.

Your database has primary indices, but no secondary indices or foreign keys to support queries with SQL JOINs or WHERE clauses. That could slow down queries.

You have multiple TinyDBs, but some of them share the default NameSpace of TinyDB1, while others don't. That needs tightening up. Big TinyDBs are slow TinyDBs.

You have a lot of Clocks, to break up multi-stage processing of database interactions. But all your database interactions funnel through one procedure and one web component. That imposes fixed minimum time intervals on each step of your database interactions. Consider adding web components for specific database interactions, with their own completion events, where you can launch the next database request. That would eliminate waiting for clock timers to fire.

Thank you for your reply and the suggestions!

I had no time to review my code the last months, but finally, I "enhanced" it using your suggestions.

However, the app is still very slow.
What I could find out is that ColinList has trouble with performance when having several hundreds of list items. Can you confirm? Also, is there an alternative to ColinList? I could only find paid extensions, which I don't like to use.

Have a nice day!
BR Constantin

You can try the built-in ListView component, it has changed in the last version. Now also supports images, main text and text detail.

Loading list views with hundreds of items is inefficient.

Filtering should be done in the database queries, to return just what is strictly needed for display.

Show how you have enhanced your database structure to allow efficient selection and filtering at the database level.

1 Like

Sorry for my late reaction, I had no time for this project..

Thank you! I have tested the new internal ListView, sooooooo much faster than ColinTreeListView! However: I can't change the style of the Listview (margin between image and text) and also, it has no "ExtraButton"-functionality.
Is there a way to solve those two issues? Then I would be perfectly happy.

I also had a look on jQuery Listview, but I don't understand if I could use it for my project, as I have a huge list with dynamic data. If it is possible, please let me know how, thank you!

Thank you! I have followed your suggestions, exactly as you wrote. Filtering is now done on database level