Hello everyone,
I spend the last few days building a POC in Honeycode and overcame many impediments but also failed. What really amazed me was how fast I could see results. Starting with the sample projects, breaking everything and fixing it again, and instead of going to the whiteboard designing the ideas directly in the potentially shippable product is an amazing experience.
The use case is very similar to the "Project Tracker" sample, so I'll use this one as showpiece.
My hope is that others encountered the same situations and would share how to solve/circumvent them. Actually, I am sure there is a need for solutions since I found topics for the "classic experience" for both.
- Unique columns
Allowing 1:n relationships between tables proved to be very valuable when modeling our use case. However, when linking by the content of a text field there is potential for collisions.
Example: In the "Project Tracker" sample, insert a new row in the table "Project" with "Project[Project] = Admin portal". You will notice that in the column "Task" there are two linked rows from the "Task" table. This happens because there is already a project with the name "Admin portal" and this free text is used to join the tables.
Impediment: When joining tables via text fields without the option to enforce uniqueness of the content the referential integrity of the data cannot be guaranteed.
Classic solution: Unique and Required columns - #4 by AndrewB
Sadly, in New Experience the Action of the Submit button is hard coded to "Add record"
Workaround: Combined join key. We added a column to the "Project" table which most likely creates a unique value:
=CONCATENATE(Project[Project], " by ", Project[Owner], " on ", Project[Start date])
(the result of the typecast date to text is lovely)
- Transfer data between screens
A central element of apps build in New Experience is a screen displaying detailed data of a parent object with a list of child objects below. There is a button to add a child object (which navigates to a new screen with data input fields) but the information of the parent object is lost.
Example: In the "Project Tracker" sample, navigate to the "Project details" tab while running the app. Click the "Add task" button and you will have to select the Project (Choose project) from a drop down list for the new task. This comes with three problems (i) the user might simply missclick on the wrong project (ii) when there are two projects with the same name they are indistinguishable (iii) when there are many projects the list gets comically large.
Impediment: When adding a child object it is not possible to use data of the calling parent object to auto fill fields.
Classic solution: Setting Variables & App Navigation
Sadly, in New Experience the Actions of the Buttons are hard coded.
Workaround: Well....... we are stuck. Expecting the users to choose from a list with several hundred entries is simply not feasible and we are not sure how to leave the POC stage. Any feedback/ideas welcome!
A solution we would love: introduce a $PARENT variable. When the "Add" button is used from a screen with only a list lie "Project overview" it is empty. When called from a screen that shows details of one entry of another table like the "Project details" screen, populate it with the data of the parent, e.g. $PARENT[Project]=Project[Project].
Bonus: Are there good/best practices how to do Application Lifecycle Management in Honeycode? My current feeling is the solution might include a lambda function which periodically copys and deletes Workbooks.
Best,
Till