Skip to content

Commit

Permalink
docs: improve developer documentation of the Asgardeo Android SDK.
Browse files Browse the repository at this point in the history
  • Loading branch information
Achintha Isuru committed Aug 13, 2024
1 parent 68289b9 commit 5fa4f9c
Show file tree
Hide file tree
Showing 6 changed files with 101 additions and 11 deletions.
29 changes: 27 additions & 2 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ We would love for you to contribute to our mobile SDKs and help make it even bet
As a contributor, here are the guidelines we would like you to follow:

- [Commit Message Guidelines](#commit-message-guidelines)
- [Releases](#releases)

## Commit Message Guidelines

Expand Down Expand Up @@ -65,5 +66,29 @@ The scope should be the name of the npm package affected (as perceived by the pe

The following is the list of supported scopes:

* `android` - Changes to the main `android` package.
* `android-core` - Changes to the `android-core` package.
* `asgardeo-android` - Changes to the `main` package.
* `asgardeo-android-core` - Changes to the `core` package.
* `asgardeo-android-core-auth-direct` - Changes to the `core-auth-direct` package.

## Releases

After merging a PR, the release process will be handled by the maintainers. The release process will be as follows:

### For Asgardeo Android SDK

The release process for the Asgardeo Android SDK will be as follows:

1. The maintainers will go through the PRs merged since the last release to identify the changes.
2. The maintainers will go to the following GitHub Actions workflow: [Release](https://github.com/asgardeo/mobile-ui-sdks/actions/workflows/release.yml).
3. The maintainers will trigger the workflow by clicking on the `Run workflow` button and select `android` as the workflow to run.
4. The maintainers will provide which version to bump based on the changes identified.
5. The changes will be published to the [Maven Central repository](https://central.sonatype.com/artifact/io.asgardeo/asgardeo-android). This will take upto 24 hours to reflect the changes in the Maven Central repository.

### For Documentation

The release process for the documentation will be as follows:

1. The maintainers will go through the PRs merged since the last release to identify the changes.
2. The maintainers will go to the following GitHub Actions workflow: [Deploy Documentation](https://github.com/asgardeo/mobile-ui-sdks/actions/workflows/deploy-gh-pages.yml).
3. The maintainers will trigger the workflow by clicking on the `Run workflow` button.
4. The changes will be published to the [GitHub Pages](https://asgardeo.github.io/mobile-ui-sdks/).
69 changes: 69 additions & 0 deletions android/ARCHITECTURE.MD
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# Architecture of the Asgardeo Android SDK

The Asgardeo Android SDK is designed to provide a seamless integration experience for your Android applications with Asgardeo. Currently this SDK has the following components:

- **Main SDK (asgardeo-android)**:
This is the main SDK that provides all the necessary functionalities to integrate your Android application with Asgardeo.

- **Core SDK (asgardeo-android-core)**:
This is the core SDK that provides the core functionalities(not any UI components) to integrate your Android application with Asgardeo.

- **Core Auth Direct SDK (asgardeo-android-core-auth-direct)**:
This is a part of the core SDK that provides the core authentication functionalities using [app-native authentication](https://wso2.com/asgardeo/docs/guides/authentication/app-native-authentication/) to integrate your Android application with Asgardeo.

## How each component is connected
![alt text](./document-images/main-architecure.png)

Using the main SDK, you can integrate your Android application with Asgardeo. The main SDK internally uses the core SDK to provide the necessary functionalities. The core SDK uses the core auth direct SDK to provide the core authentication functionalities using app-native authentication.

The main SDK and the core SDK does not have any code in their components. They are just a collection of dependencies that are required to integrate your Android application with Asgardeo. The core auth direct SDK has the actual code that provides the core authentication functionalities using app-native authentication.

## Architecture of the Core Auth Direct SDK
![alt text](./document-images/core-auth-direct-sdk.png)

The above image depicts the full-scale architecture of the Asgardeo Android Core Auth Direct SDK. This SDK can be divided into four main layers:

- Provider Layer
- Core Config Layer
- Core Layer
- Data Layer

Let's look at each of these layers separately.

### Provider Layer
This layer has all the functions needed by an Android developer to integrate app native authentication into their Android application. As shown in the diagram, the provider layer consists of three main components:

- Authentication Provider
- Token Provider
- Provider Managers

Both the Authentication and Token providers have wrapper functions that call functions in a provider manager, which then call the implemented functions in the core layer.

The Authentication Provider exposes functionality necessary for app native authentication, such as `initializeAuthentication()`, `authenticateWithUsernameAndPassword()`, and `logout()`.

The Token Provider exposes functionality to handle tokens, such as `getAccessToken()` and `validateAccessToken()`.

Provider Managers have manager classes that call functions in the core layer, for example, the user provider manager calls functions related to getting user information.

### Core Config Layer
When using the SDK, the developer can either use the discovery endpoint or add all the necessary endpoints like authorize and token endpoints. This layer sets the SDK configurations based on the data provided by the developer. If the developer has entered the discovery endpoint of their Asgardeo organization, this layer will call it, fetch all necessary endpoints, and set them accordingly.

### Core Layer
This layer contains all the implementations and is where the magic happens in the SDK. It consists of three components:
- Authentication Core
- Native Authentication Handler Core
- Managers

The Authentication Core and Native Authentication Handler Core are wrapper classes for functions implemented in the Managers. The provider layer interacts with these core classes without knowing the implementation details, which are encapsulated in the Managers.

The Authentication Core class holds wrapper functions for app native authentication-related functions. Additionally, the SDK provides functionality to call native authentication APIs directly, such as Google's credential manager API.

The Native Authentication Handler Core wraps those native functions, implemented in the native authentication handler managers.

The Managers handle specific unit actions; for example, the user manager handles API calls related to getting user information from Asgardeo. If you look closely in the managers component in the core layer you will see a manager called AppAuth Manager, which is responsible for calling the Android AppAuth SDK, to handle the lifecycle of the token. Since this SDK already has this logic implemented, we chose to use it directly in our SDK instead of reinventing the wheel.

### Data Layer
The final layer in the SDK is the Data Layer. This layer is responsible for storing and retrieving token information in the phone memory. To store data, this SDK uses the datastore library provided by Android. This layer allows developers to skip the login interface when a user returns to their app and already has a valid token.

### Why so many layers ?
Now that you have a better understanding of the architecture of the Asgardeo Android Core Auth Direct SDK, you might be wondering why there are so many layers in the Asgardeo Android Core Auth Direct SDK. The reason is to increase the maintainability of the SDK. By having multiple layers, the higher layers, such as the provider layer, are abstracted from the implementation details. This separation allows us to modify the implementation without affecting the developer's code, ensuring a more robust and flexible SDK.
6 changes: 5 additions & 1 deletion android/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,4 +18,8 @@

# Asgardeo Android SDK

To see the full details of the Asgardeo Android SDK, refer to following <a href="https://asgardeo.github.io/mobile-ui-sdks/android/introduction.html" target="_blank">documentation link</a>.
To see the full details on how to integrate the Asgardeo Android SDK, refer to following <a href="https://asgardeo.github.io/mobile-ui-sdks/android/introduction.html" target="_blank">documentation link</a>.

## Architecture of the Asgardeo Android SDK

The full details on the architecture of the Asgardeo Android SDK can be found [here](./ARCHITECTURE.md).
Binary file added android/document-images/core-auth-direct-sdk.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added android/document-images/main-architecure.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
8 changes: 0 additions & 8 deletions pull_request_template.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,6 @@
## Purpose
> Describe the problems, issues, or needs driving this feature/fix and include links to related issues in the following format: Resolves issue1, issue2, etc.
$subject

## Related Issues
> List related issues in the following format: Resolves #123, #456, etc.
Expand All @@ -12,9 +10,6 @@ $subject
## Approach
> Describe how you are implementing the solutions. Include an animated GIF or screenshot if the change affects the UI (email [email protected] to review all UI text). Include a link to a Markdown file or Google doc if the feature write-up is too long to paste here.
## User stories
> Summary of user stories addressed by this change>
## Release note
> Brief description of the new feature or bug fix as it will appear in the release notes
Expand All @@ -27,9 +22,6 @@ $subject
## Certification
> Type “Sent” when you have provided new/updated certification questions, plus four answers for each question (correct answer highlighted in bold), based on this change. Certification questions/answers should be sent to [email protected] and NOT pasted in this PR. If there is no impact on certification exams, type “N/A” and explain why.
## Marketing
> Link to drafts of marketing content that will describe and promote this feature, including product page changes, technical articles, blog posts, videos, etc., if applicable
## Automation tests
- Unit tests
> Code coverage information
Expand Down

0 comments on commit 5fa4f9c

Please sign in to comment.