Comment on page

Publishing Apps

Introduction
If your app is blendable, it might be used in complex UI systems consisting of multiple apps coming from different vendors.
To make sure that apps play well together, we recommend that you follow certain conventions.
These conventions exist for two reasons:
1.to prevent conflicts between apps in the same database
2.to provide a common ground, expectable user experience
Mapping File
Each app that have blendable views should have a <AppName>.map.md file which contains the list of them.
The file should be provided at the root of the App Warehouse package. If the app is open source, the file should be provided in the code repository, preferably at the root.
Every view must be explained in the file and preferably illustrated with a screenshot.
In the future, the information in this file is used for automated blending as well as for testing purposes.
Sample Images.map.md (source):
# Blendable views
​
## /images/partials/contents/{[Simplified.Ring1.Content](https://github.com/Starcounter/Simplified/blob/master/Ring1/Content.cs)}
​
Shows a simple page for `Content` preview, image or video. In case of unexisting
content, shows empty file preview image.
​
![screenshot](docs/screenshot-content.png)
Entry Point URI
Every blendable web app should have the entry point URI that follows the pattern /<appname>, e.g. /kitchensink (lowercase).
When you access this URI, the app main screen should be presented.
If there is no main screen, show a splash screen saying that the app is running.
Sample MainHandlers.cs (source):
Handle.GET("/people", () =>
{
    return Self.GET("/people/organizations");
});
UI Metadata
By convention, a blendable web app must provide a metadata JSON that responds to the app-name blending token.
System apps and navigation apps like Launchpad will display a link to the entry point URI using the app name from this metadata. They will also use the icon, if provided.
The response JSON can consist of the following properties:
Property
Explanation
name
Required. Human readable app name.
description
Optional. Short (single sentence) description of the app.
html
Optional. URI to a view that contains the app icon.
Sample MainHandlers.cs (source):
Handle.GET("/cssvariablesmanager/app-name", () => new AppName());
Sample BlendingHooks.cs (source):
Blender.MapUri("/cssvariablesmanager/app-name", "app-name");
Sample AppName.json (source):
{
  "name": "CssVariablesManager",
  "description": "CssVariablesManager",
  "html": "/cssvariablesmanager/AppIcon.html"
}
App Icon
The icon is an image (preferably inline SVG) in the HTML file which path is provided as the html property in the app-name metadata.
Check out the Icons cookbook to learn more about icons.
Sample AppIcon.html (source):
<template>
    <svg slot="cssvariablesmanager/app-icon" viewBox="0 0 185 185" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
        <use xlink:href="/cssvariablesmanager/images/cssvariablesmanager.svg#css-file" />
    </svg>
    <template is="declarative-shadow-dom">
        <slot name="cssvariablesmanager/app-icon"></slot>
    </template>
</template>
Required and Sample Data
The app should not create required nor sample data without the user's consent.
Required Data
If the app requires any data to operate (for example a list of the world's countries in the Country table), it should present a nagging information with a button that creates the data:
on the top of the main page
possibly in every view that needs the required data
Sample Data
If the app offers some nice-to-have sample data, it should offer a button that creates this data:
on the main page, in a welcome message that is dismissible once (not per user)
on the Settings page​
Settings Page
If your app is configurable, it's good for to provide a user interface for changing the app settings.
By having a settings page mapped to the common token, your configuration UI can appear along settings pages from other apps. This is good because it gives the end user a single go-to place to configure all apps.
The common pattern is to have the settings page addressable by /<appname>/settings, blended to the token settings.
The settings page might contain a button to do a "Factory Reset" of the app (restores required data) or a "Sample data" button that populates the database with sample data.
Sample and prefab apps that have a settings page:
​https://github.com/Starcounter/Products​
​https://github.com/Starcounter/SignIn​
Submitting to the App Warehouse
To make your app discoverable by others, you're invited to publish it in the App Warehouse.
Submitting apps to the App Warehouse requires an invitation.
​Contact Starcounter for more information.

UDP Sockets

Working with Starcounter

Last modified 5yr ago

Property	Explanation
`name`	Required. Human readable app name.
`description`	Optional. Short (single sentence) description of the app.
`html`	Optional. URI to a view that contains the app icon.