My Cloud Home apps run on a display-less Android device. The device SDK provides an alternative UI rendering mechanism wherein you can build UI screens using standard web technologies and embed it into the application. The device SDK forms the primary bridge between the Web UI and the backend Android application.
Since the UI part of the My Cloud Home device app runs in a separate application (browser), the app should have a minimal user interface for communicating to the business logic part.
Typical examples for UI usage are application configuration, setting up and sign/signout. On-device apps should follow the "fire and forget" principle of operation. Users would not be looking at the screen for getting constant updates. Once configured successfully, the app should run reliably in the background.
The application's UI design should not expect a user involvement of more than one hour. If the application requires notifying the users about the progress, completion, or anything else, then refer to the notification mechanism given in Sending Notification to User section.
Now, let us understand how you can build a UI with the above conditions:
The UI part of the application would have a couple of HTML pages. In each HTML page, there would be multiple requests to the server to get images, CSS and JavaScript. Since these web components are hosted within the on-device app, all the HTTP requests should reach the on-device app through the My Cloud Home routing channel. However, all the requests to the My Cloud Home are secured through an access token and must carry an HTTP header ‘Authorization: Bearer <token>’ or ‘access_token=<token>’ in the request parameter. Access token can be attached to HTTPs requests in the following two ways:
The Access Token has limited scope and can be used only for accessing web related files (images, CSS and JavaScript). The token expires in a predefined time.
1. Append Access Token manually in each HTTPs request
If your application has a limited UI and does not have any nested JavaScript libraries or calls, then appending access token is the easiest way. In this approach, when an on-device app receives the HTTPs GET request (typically the index.html) for the first time, it can get the Access Token using getAccessToken() API.
@Override
public NanoHTTPD.Response get(NanoHTTPD.IHTTPSession session)
{
String uri = session.getUri();
String accessToken = getAccessToken(session);
return createHtmlResponse(uri);
}
The Access Token received in response can be appended to the subsequent HTTPs requests. For example, <a class="button-link" href="./user_profile?access_token=###TOKEN###">Start</a>
private String getLandingPageViewSource(String accessToken)
{
try {
StringBuilder builder = new StringBuilder();
BufferedReader reader = new BufferedReader(new InputStreamReader(mContext.getAssets().open("index.html")));
String line = "";
while ((line = reader.readLine()) != null) {
if (line.contains("###TOKEN###") && !TextUtils.isEmpty(accessToken)){ // This is hack to add access token to an html url
line = line.replace("###TOKEN###", accessToken);
}
builder.append(line);
}
reader.close();
return builder.toString();
} catch (Exception e) {
Log.e(TAG, e.getMessage());
return "
Sorry "<h1>index.html cannot be loaded </h1>";
}
}
2. Use a cookie to save access_token for all HTTPs requests
If your application has an extensive UI and requires many HTTPs calls to the server, then it would be challenging to append access token to each URL request manually. In this case, set the access_token in a cookie and follow the general cookie guidelines.
Saving access_token in a cookie is not secure, and you must follow cookie management guidelines to mitigate this issue.
Set the cookie to expire after the user closes the browser window and clear/remove it when the user closes the browser tab.
You can also save the cookie with a different name than 'access_token'.
Click the buttons below to visit the My Cloud Home On-Device Developer Home & Workflow pages