I seem to be doing technical contortions to make my app work and improve performance. Each change makes the app more complex and more fragile. My head hurts. So, I am taking a step back and sharing my approach to my app to see if I’m not understanding the right way to use Glide.
All help and comments very much appreciated. I’m posting the basic approach here and will immediately post what problems/concerns/challenges I’m having in a subsequent post.
These descriptions are simplified to make it easier to follow and stay out of the weeds.
At the highest level, I’m trying building an app with just two essential screens.
- A form screen that allows users to input a date and a location
- A results screen that displays the date, a description of the location and an image of the location on that date. The results screen would have a button that advances the date. Press the button, the results screen updates based on the new date.
My decomposition is essentially 6 pieces.
- a form screen
- 2 static tables of data, one for the locations and the other for the images
- an input table for the form screen to record user choices
- an display table, derived from other tables to be the data source for the results screen
- a result screen
Of course there are some helper tables required to do the lookup of images, the lookup of location information and massage the date formats.
I’m trying to keep my input table simple very simple and decoupled from any downstream calculations (Single Responsibility principle). (No, I’m not smart, I just did it wrong the first few times.) I’ve discovered that if a form target table does a any significant calculations (worse if they propagate to helper tables), the display of the form screen becomes very slow 3 to 8 seconds.
Similarly, I am aggregating all the final display information into one table with little or no calculation, for the same reasons. Relatedly, the submit button actions that generate a screen (detail, edit, form, new) only can reference a single data source. My display table feeds a “new screen” attached to the form submit button.
Does this decomposition make sense? Any fundamental errors in my approach?
[I’ll put my challenges/concerns in a second post immediately after this one.]
Thanks for sticking with me this far. I really, really appreciate this forum and all the help you provide.
Challenge 1:
I have only found 2 ways to put data from one table into another, thru relation/lookup columns or a single value column. In both cases because the data coming from another source cannot be changed. For example, the date in my display table cannot be changed in the result screen. To get the button to work, I added a date-offset column and a offset-date column to the display table. The button increments the date-offset and the offset-date gets updated. It’s the offset-date that’s used in the display, not to original date.
Problem with this approach is that the date-offset is retained and the user doesn’t see the date he selected on subsequent result screens. That means that the date offset needs to be initialized to zero every time results are derived. I can’t find a way to do it.
- Is this the simplest approach?
This raises a of a more general question:
- How do I reset helper tables (without an explicit user action to do so)? This is the crux of much of my complexity. Probably one of my most important questions.
Relatedly, a few questions about workflows. It appears that workflows can only be triggered by user actions, schedules, emails and webhook. It also appears that user action workflows can only be associated with the table used in the user action. Is that correct?
- How do you attach workflows to tables that have no user interaction? (Which is another form of “can workflows be triggered by table updates?”)
- Is there anyway to have one workflow trigger another? attached to a different table?
Challenge 2:
The form screen table adds a new row each time a user uses it. My approach to accessing user data is to reference that table using a last-row, single value column - the latest row of table from the last person who used the screen. This work great when there is a single user, but when multiple people are using the app concurrently, I’m guessing the helper tables are not user specific and so the results the a user may see could may not be his.
For example, my results screen is derived from the last row of the input table. Imagine a user trying to advance the date in his results screen and having it refresh to something completely different because his row in no longer the last row! Yikes.
All help appreciated. Drinks on me!
Is there a reason you have to use an input table? I feel like you can just write your form directly to the display table.
I don’t understand some of this, I read your previous threads as well and was not really sure on the use case. If you can explain the real-life use case of this app, maybe it’ll help a bit.
The input data is used to lookup information used in the display table, not directly displayed in it.
With regard to real example, where can I provide you more detail?
Also, do you have a suggestion for resetting helper tables
The simplest use case:
- A form screen that allows users to input a date and a location
Sailor picks a date and location.
- A results screen that displays the date, a description of the location and an image of the location on that date. The results screen would have a button that advances the date. Press the button, the results screen updates based on the new date.
Sailor gets a screen with info about the location and an image that shows tide and current information on that day.
Button advances the date, updating the screen, so they can see if the tide/currents are better the next day.
Does this help?
