SAFE Mobile Browser
The SAFE Mobile Browser is a mobile web browser for the SAFE Network.
Maintainer: Ravinder Jangra (firstname.lastname@example.org)
|Azure DevOps||Android - MacOS|
|Azure DevOps||iOS - MacOS|
Table of Contents
- User Guide
- Further Help
The SAFE Mobile Browser is a cross-platform mobile (Android, iOS) browser, built to provide web browsing experience to the users on the SAFE Network.
The app currently uses the MaidSafe.SafeApp NuGet package to fetch the content from the network.
- Fetch static websites from the SAFE Network.
- Bookmarks (sync with SAFE Desktop Browser).
The latest version of the SAFE Mobile browser can be downloaded using following links and QR code for the Android and iOS devices.
|Platform||OS & Architecture||Downlaod Link||QR Code|
|Android||5.1+ (armeabi-v7a, x86_64)||AppCenter, GitHub|
|iOS||iOS 11+ (ARM64, x64)||AppCenter|
Note: We use Azure App Center to distribute iOS builds. Please register here so we can add you in our testing group so you can download and install the app.
Browsing SAFE websites
Once installed, mobile browser can be used to browse the websites hosted on Alpha-2 network.
Note: Make sure to whitelist/update your IP address on invite server before you start browsering.
|Browser launch page||Fetching website from the SAFE Network|
Working with bookmarks
To use bookmarks feature in mobile browser, we need to authenticate the app using SAFE mobile Authenticator app.
|Authenticate||Add bookmark||Remove bookmark||Manage bookmarks|
- Common UI code and SAFE logic for mobile browser
- Platform: Android, iOS
- Platform specific/dependent code
- Custom controls for native UI
- Platform assets
- Platform dependent service code
- Visual Studio 2017 or later editions with the following workloads:
As an open source project, we're excited to accept contributions to the code from outside of MaidSafe and are striving to make that as easy and clean as possible.
With enforced linting and commit style clearly laid out, as well as a list of more accessible issues for any project labelled with Help Wanted.
GitHub project boards are used by the maintainers of this repository to keep track and organise development priorities.
There could be one or more active project boards for a repository. One main project will be used to manage all tasks corresponding to the main development stream (master branch). A separate project may be used to manage each PoC and/or prototyping development, and each of them will track a dedicated development branch.
New features which imply a big number of changes will be developed in a separate branch but tracked in the same main project board, re-basing it with master branch regularly and fully testing the feature on its branch before it's merged into the master branch after it was fully approved.
The main project contains the following Kanban columns to track the status of each development task:
Triage: New issues which need to be reviewed and evaluated before taking the decision to implement it.
Low Priority: Issues that will be picked up in the current milestone.
In Progress: Task is assigned to a person and it's in progress.
Needs Review: A Pull Request which completes the task has been sent and it needs to be reviewed.
Reviewer approved: The PR sent was approved by reviewer/s and it's ready for merge.
Ready for QA: The fix for the issue has been merged into master and is ready for final QA testing.
Done: QA has verified that the fix is complete and does not affect anything else.
Issues should clearly lay out the problem, platforms experienced on, as well as steps to reproduce the issue.
This aids in fixing the issues but also quality assurance, to check that the issue has indeed been fixed.
Issues are labelled in the following way depending on its type:
bug: The issue is a bug in the product.
feature: The issue is a new and inexistent feature to be implemented.
enhancement: The issue is an enhancement to either an existing feature in the product or to the infrastructure around the development process.
blocked: The issue cannot be resolved as it is blocked by another task. In this case, the task that it is blocked by should be referenced.
documentation: A documentation-related task.
e/__: Specifies the effort required for the task.
p/__: Specifies the priority of the task.
Commits and Pull Requests
Commit message should follow these guidelines and should therefore strive to tackle one issue/feature, and code should be pre-linted before commit.
PRs should clearly link to an issue to be tracked on the project board. A PR that implements/fixes an issue is linked using one of the GitHub keywords. Although these type of PRs will not be added themselves to a project board (just to avoid redundancy with the linked issue). However, PRs which were sent spontaneously and not linked to any existing issue will be added to the project and should go through the same process as any other tasks/issues.
Where appropriate, commits should always contain tests for the code in question.
Changelog and releases
The changelog is currently maintained manually, each PR sent is expected to have the corresponding modification in the CHANGELOG file, under the 'Not released' section.
The release process is triggered by the maintainers of the package once it is merged to master.
Copyrights in the SAFE Network are retained by their contributors. No copyright assignment is required to contribute to this project.
Licensed under the General Public License (GPL), version 3 LICENSE.