This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- AppSheet
- Feature Ideas
- Reusable Items and Sharing (Collaboration)
Topic Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
LinkedIn
Twitter
Idea Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following Feature Request is a long overdue outline I have of having Reusable Items in Appsheet.
It is part of a response in part @tony request:
This is just the initial outline. I will elaborate further in the future as and when I work on my Apps where it will trigger further thoughts.
1. What would be Reused and then Shared?
The basic concept of reuse could be based on table which is reused (for example the Person Table with all the details of a Person like Name, Email, Phone) where its structure is the same and it uses some Slices, Views, Actions, and Workflows that are common to all or some applications. Where there is reuse of some of these in an application, its inclusion should be optional, i.e. enabled to disabled.
Another concept of reuse of based on Expressions where Functions could be declared that could return a certain result, or simply undertake series of execute a set of expression statements. For example, Security Access which determines access based on expressions that evaluate Policy (sections of or whole applications), Organizational Rank, Group Allocations (Selected or as a Project), Individual Exclusions/Inclusions against that of a Person’s Identity.
Some Items like Data Slices, Views, Report could also have Parameters. An example of a parameter could relate to time periods, numeric/fiscal ranges, ranking/priority, categories, etc. Currently you have to create a separate Slice with all its attributes just to have time period for 7 days then make another one for 14 days. So a Slice could be declared as reusable and a new one could simply inherit all it characteristics (if there is any benefit in predefining it, e.g. Indexing and Sorting). Alternatively, it could just be dynamic. (Refer to Section ‘Implementation of a Reusable Item – Dynamic or Copied’ below.)
A Reusable Item perhaps might make reference to column in User Settings. The Reusable Items could instead have its own settings that perform like a Global Variable does in programming languages.
A Group of Reusable Items, particularly those based on a Table, could be defined as a Module, hence Modular Design.
Items that are reusable can that be shared, as described further in the next section.
2. Sharing Items (and Collaboration)
A reusable item could be shared in a library or gallery in these ways of collaboration:
• Between nominated applications
• Between nominated developer users
• Publicly for any developer
2.1 Between Nominated Applications
Currently, I reuse data sources with their tables between applications. For example: the PERSON Table is reused in different applications.
2.2 Between Nominated Developer Users
These might form within an organization or amount multiple organizations into a Team or a Work Group.
2.3 Publicly for any Developer
These would be available for any Developer to use. It could be similar to how Demo Apps work, that allow anyone to see and copy an application.
3. Implementation of a Reusable Item – Dynamic or Copied
A Reusable Item can be used in an Application either Dynamically or Copied.
3.1 Dynamic
The Reusable Item would in included via reference, much like a program library in a conventional programing environment, like #include in C Programing or Objects Libraries in C#/C++.
3.2 Copied
A Reusable Item could be copied as to be an adaptation of it. It would copy all of its contents into an application, rather than referring to them.
4. Versioning and Release Control
All items shall be versioned and published as releases as a form of control. This would avoid regressive problems of changes occurring that might be ahead of how its implemented in other applications. For example, if a Column is renamed or added in the Data Table, it could create an error that prevents other applications from operating.