Typical Flow of a Mobile Application

The typical application will go through the following steps, sometimes repeating a step and sometimes going one or more steps back.

1. Find desired Noah installation.

   • Discover the Remote Host Id using the Noah Mobile Alias

   • The Noah Mobile Alias can be found in the Noah Mobile Setup dialog in Noah.

2. Login and receive token. 

   • To get access to Noah data, the user must login on to Noah through Noah Mobile. The user types his/her usual Noah credentials on the dedicated Noah Mobile authentication site. Authentication is based on OAuth2 Implicit Grant.

   • The outcome of the login process is a token that the application can use to gain access to Noah data.

   • 1. The application opens a web browser, and points it towards the authentication web site.
     2. User types in credentials at the authentication web site.
     3. The browser is redirected to another web site (the “redirect URI” in OAuth terminology). Embedded in the url (address) is the token.
     4. The application extracts the token from the url, and can now use the token to access Noah data. 
     5. The most complex part is “catching” the url after the redirection. This can be done by using a web browser embedded in the app, or an un-embedded webbrowser. Please see below.

3. Register application (if this is the first time you have access the Remote Server). The application must be registered on the Noah installation in order to allow the administrator to decide the Data Access Level. The application should register only once in its lifetime, although it is not harmful to register multiple times.

4. Request Settings for Noah Installation. These will rarely change, so requesting them one time after login should be enough.

5. Select existing patient or create new patient. Create a patient (First and last names are mandatory when creating a new patient) or search for patients that match the search text. Note that there might be an upper limit on the number of patients returned, even though more patients match the search text. This is to prevent overwhelming amounts of data, if the search text is too short.

6. Make changes to patient data if needed. 

7. Select an existing action or create a new action. 
   Note: Referenced actions and public/private data are not included by default in the action returned to the App. This is because this data is often not needed (e.g. when showing a list of actions which the user can choose between). To get these types of data, use GetActionReferences(…), GetActionPublicData(…) and GetActionPrivateData(…) from the MobileAccessLayer, or use the equivalent functions in the WebAPI. 
   A new action can be added by using the CreateAction(…) method. The action will be associated with the session with the same date. If no such exist, a new session will automatically be created.

8. Make changes to action data as necessary. 

9. Repeat process as many times as wished for, by going to step 5 or 7. 

10. Log off. 

    • You perform a Log off by deleting the access token permanently.

Using a non-embedded web browser (This approach is typical for Android and iOS apps):

1. Make your application a Single instance application (if needed).

2. Add a Custom Uri Scheme so your application is automatically opened whenever the browser is redirected to a special url (which could be in reverse domain name notation).

3. Start authentication by going to the authentication URI (or use the AccessLayers InvokeImplicitGrantAuthentication(…) method) to open the authentication web site.
   Now, when the browser is redirected, the browser will (re)open the application again, but since it is a single instance application, the already running application will be passed the url as an argument. Extract the token from the url (or use the Token class’ FromArgs(…) method to extract the token).

Using an embedded web browser (This approach is used by the sample apps provided by HIMSA):

1. Add a web browser to the application.

2. Monitor the event the browser fires when a new site has been loaded.

3. Point the browser toward the address provided the by Access Layers GetImplicitGrantAuthenticationUri(…).
   Now, when the browser is redirected, the monitored event will fire. Get the redirected url from the browser and extract the token (or use the Token class’ FromUri(…) method to extract the token).
   
   Notes:
   • Web browsers should be of a newer date.
   • The application should not remember the token when it closes.