Building an app from the ground up, details and edit screens

Building an app from the ground up, details and edit screens

Welcome back! Two episodes ago, the {low-code} 🚍 journey started down an interesting new pathway. We have been building a mobile portal app for the Hammerhead Turtle Co. (HHTC). In the last episode we built the home screen, which is the screen that will show the users the web tools that are available to them.


Listen to a recording of this post:


This screen also includes live links to the sites these tools are connected to. But the specifications for the project required other functionalities that user groups identified as functions that would add value to the mobile portal app. One of them is the ability for users to add their own links to the system, so they can have all the things that they use regularly under one roof. The design team also identified a note taking function as a value-added feature that would also help the users.

In this episode we will add a details screen that is tied to the home screen. This details screen is where users will be able to look at their notes about the tool. We will also add an edit screen. The latter will be tied to both the home screen, and the details screen. Why? I have previously mentioned that when the user calls up, or navigates to the edit screen, it depends on the OnSelect command issued, how the form will behave.

If the form is going to allow the user to edit content, the form must open with the content the user desires to edit. Then the user can submit those changes to the data source for updating. On the other hand, if users want to add new information, then the form needs to be blank so users can enter new information, then submit that information to the data source, adding to the rest of the data. The key thing to remember here, is that we are using one form to carry out two functions and it is just how we invoke it that determines which function it will carry out.

In this build, we will be, again, making copies of the master screen. First, we will make a copy of the master screen and rename it details screen. Then we will connect it to the data source to show the details of the selected application, along with the notes. The video below shows you how to do this.

Once we complete as much as we can on the details screen, we will take the master screen and make another copy. Rename the copy to edit screen. From there we will build the edit functionalities, including a rich text editor control for the notes section of the edit screen. Once we have that ready, we will be able to tie it to the home screen with a new icon, which we will add by creating a copy of the home icon. Then changing its shape to match the desired function. We will modify the home icon to serve as the cancel changes function. On the details screen, we will create a trash icon to delete a record and an edit icon to call up the edit screen to update that record. See the video for more information.

I thought it would be useful to provide a few of the functions to call the edit screen. They are listed here so you can have them readily available.

  • New Record: OnSelect=[fx] NewForm(Form1);Navigate(EditScreen,ScreenTransition.None). This means: the OnSelect property of the new record icon is set to invoque Form1 (the name the developer gave the edit form) and navigate to the EditScreen (the name the developer gave the edit screen) without using a screen transition effect.
  • Edit an Existing Record: This has two functions that are executed for two properties. Item=[fx] HomeGallery.Selected. This means: for Form1 (name the developer gave the Edit Form in the EditScreen) you set the Item property to point to the item selected in the home screen gallery.
  • If the user interacted with the third item in the home screen, this is the item we will be editing, Onselect=[fx] EditForm(Form1);Navigate(EditScreen,ScreenTransition.Cover). This means: the OnSelect property of the edit icon in the details screen is set to invoque Form1 (the name the developer gave the edit form) and navigate to the EditScreen (the name the developer gave the edit screen) using a screen cover transition effect.

At the end of the session, it will feel like we have completed the app. However, we are still missing a few desired functionalities that the user focus groups from HHTC asked for. Those are the search box, the filtering function, and sorting the records alphabetically. We will get into that in the next session.

Dr. Carlos Solís is Associate Vice President for the Technology Innovation Office.

Print Friendly, PDF & Email