Skip to content

Latest commit

 

History

History
110 lines (67 loc) · 4.16 KB

README.md

File metadata and controls

110 lines (67 loc) · 4.16 KB
Raw

XDAG iOS Wallet

This project is based on XDAG C implementation, and developed for iOS platform.
XDAG iOS Wallet is maintained by xdagger community developers, the official XDAG iOS Wallet.

Building

  1. git clone sources
git clone [email protected]:XDagger/xdag-ios.git
  1. run pod install in project root directory.
pod install
  1. Open .xcworkspace

URI scheme for QRCode

URI scheme for making xdag payments

 xdagurn = "xdag:" xdagaddress [ "?" xdagparams ]
 xdagaddress = *base64
 xdagparams  = xdagparam [ "&" xdagparams ]

Requirements

  • iOS 8.0+ / macOS 10.10+
  • xcode 9
  • Swift 4.0

How to contribute

Want to contribute on XDAG iOS Wallet? Awesome! Here are the instructions to get you started. They are not perfect yet. Please let us know what feels wrong or incomplete.

This is an Open Source project and we welcome contributions of all sorts. There are many ways to help, from reporting issues, contributing code, and helping us improve our community.

Reporting Issues

If you find bugs, mistakes, inconsistencies in the XDAG Wallet project's code or documents, please let us know by filing an issue at the appropriate issue tracker (we use multiple repositories). No issue is too small.

The main issues for bug reporting are as follows:

Implementation Design

When considering design proposals for implementations, we are looking for:

  • A description of the problem this design proposal solves
  • Discussion of the tradeoffs involved
  • Discussion of the proposed solution

Translations

This community moves very fast, and documentation swiftly gets out of date. For now, we are encouraging would-be translators to hold off from translating large repositories. If you would like to add a translation, please open an issue and ask the leads for a given repository before filing a PR, so that we do not waste efforts.

If anyone has any issues understanding the English documentation, please let us know! We are very sensitive to language issues, and do not want to turn anyone away from hacking because of their language.

Git

We use a simple git branching model:

  • master must always work
  • develop is the branch for development
  • create feature-branches to merge into develop
  • all commits must pass testing so that git bisect is easy to run

Just stay current with develop (rebase).

Commit messages

Commit messages must start with a short subject line, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.

Code

Write clean code. Universally formatted code promotes ease of writing, reading, and maintenance.

Documentation

Update documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness, as well as a clean documentation build.

Pull Requests

Pull requests descriptions should be as clear as possible. Err on the side of overly specific and include a reference to all related issues. If the pull request is meant to close an issue please use the Github keyword conventions of closes, fixes, or resolves. If the pull request only completes part of an issue use the connects keywords. This helps our tools properly link issues to pull requests.

Code Review

We take code quality seriously; we must make sure the code remains correct. We do code review on all changesets. Discuss any comments, then make modifications and push additional commits to your feature branch. Be sure to post a comment after pushing. The new commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.

Merge Approval

We use Thank you for your efforts. in comments on the code review to indicate acceptance. A change requires Thank you for your efforts. from the maintainers of each component affected. If you know whom it may be, ping them.

Support Developers

Solar (XDAG 4f1Sp/UD55JX5+kQCevUCpyenaPwqmpC)