ed87a2781c
This PR creates data types for Addresses and Keys so that they are
not represented by Strings anymore. This avoids mistakenly use
the wrong keys because they are all alike for the type system.
New Protocols:
=============
StringEncoded -> Protocol that makes a type can be expressed in an
string-encoded fashion either for UI or Interchange purposes.
Undescribable -> A protocol that implements methods that override default
decriptions used by debuggers, loggers and event trackers to avoid types
conforming to it to be leaked to logs.
Deleted Protocols:
==================
UnifiedFullViewingKey --> turned into a struct.
UnifiedAddress --> turned into a struct
new Error Type:
================
````
enum KeyEncodingError: Error {
case invalidEncoding
}
````
This error is thrown when an Address or Key type (addresses are public
keys in the end) can be decoded from their String representation,
typically upon initialization from a User input.
New Types:
=========
SaplingExtendedSpendingKey -> Type for Sapling Extended Full Viewing Keys
this type will be replaced with Unified Spending Keys soon.
SaplingExtendedFullViewingKey -> Extended Full Viewing Key for Sapling.
Maintains existing funcionality. Will be probably deprecated in favor of
UFVK.
TransparentAccountPrivKey -> Private key for transparent account. Used
only for shielding operations. Note: this will probably be deprecated soon.
UnifiedFullViewingKey -> Replaces the protocol that had the same name.
TransparentAddress -> Replaces a type alias with a struct
SaplingAddress --> Represents a Sapling receiver address. Comonly called zAddress. This address corresponds to the Zcash Sapling shielded pool.
Although this it is fully functional, we encourage developers to
choose `UnifiedAddress` before Sapling or Transparent ones.
UnifiedAddress -> Represents a UA. String-encodable and Equatable. Use of
UAs must be favored instead of individual receivers for different pools.
This type can't be decomposed into their Receiver types yet.
Recipient -> This represents all valid receiver types to be used as
inputs for outgoing transactions.
````
public enum Recipient: Equatable, StringEncoded {
case transparent(TransparentAddress)
case sapling(SaplingAddress)
case unified(UnifiedAddress)
````
The wrapped concrete receiver is a valid receiver type.
Deleted Type Aliases:
=====================
The following aliases were deleted and turned into types
````
public typealias TransparentAddress = String
public typealias SaplingShieldedAddress = String
````
Changes to Derivation Tool
==========================
DerivationTool has been changed to accomodate this new types and
remove Strings whenever possible.
Changes to Synchronizer and CompactBlockProcessor
=================================================
Accordingly these to components have been modified to accept the
new types intead of strings when possible.
Changes to Demo App
===================
The demo App has been patch to compile and work with the new types.
Developers must consider that the use (and abuse) of forced_try and
forced unwrapping is a "license" that maintainers are using for the
sake of brevity. We consider that clients of this SDK do know how to
handle Errors and Optional and it is not the objective of the demo
code to show good practices on those matters.
Closes #461
|
||
|---|---|---|
| .. | ||
| ZcashLightClientSample | ||
| ZcashLightClientSample.xcodeproj | ||
| ZcashLightClientSampleTests | ||
| assets | ||
| README.md | ||
| ZcashLightClientSample-Mainnet-Info.plist | ||
README.md
iOS demo app
This is a demo app that exercises code in https://github.com/zcash/ZcashLightClientKit, which has all the iOS-related functionalities necessary to build a mobile Zcash shielded wallet.
It relies on Lightwalletd, a backend service that provides a bandwidth-efficient interface to the Zcash blockchain. There is an equivalent Android demo app.
Contents
Requirements
Demo app requires a target device running iOS 12+.
Exploring the demo app
After building the app, the emulator should launch with a basic app that exercises the SDK (see picture below). To explore the app, click on each menu item, in order, and also look at the associated code.
The demo app is not trying to show what's possible, but to present how to accomplish the building blocks of wallet functionality in a simple way in code. It is comprised of the following self-contained demos. All data is reset between demos in order to keep the behavior repeatable and independent of state.
Demos
| Menu Item | Related Code | Description |
|---|---|---|
| Get address | GetAddressViewController.swift | Given a seed, display its z-addr |
| Latest block height | LatestHeightViewController.swift | Given a lightwalletd server, retrieve the latest block height |
| Sync blocks | SyncBlocksViewController.swift | Download compact blocks from the lightwalletd server. |
| Get balance | GetBalanceViewController.swift | Calculates the balance of the current wallet address. |
| Send funds | SendViewController.swift | Send a transaction, the most complex demo. |
| Transaction details | TransactionDetailViewController.swift | See status of a transaction: pending or confirmed, sent or received. |
| All transactions | TransactionsTableViewController.swift, TransactionsDataSource.swift | Displays as much available transaction information on the wallet. |
| Paginated transactions | PaginatedTransactionsViewController.swift | Demonstrates how to paginate transactions. |
Getting started
We’re assuming you already have a brilliant app idea, a vision for the app’s UI, and know the ins and outs of the Android lifecycle. We’ll just stick to the Zcash app part of “getting started.”
Similarly, the best way to build a functioning Zcash shielded app is to implement the functionalities that are listed in the demo app, in roughly that order:
- Generate and safely store your private key.
- Get the associated address, and display it to the user on a receive screen. You may also want to generate a QR code from this address.
- Make sure your app can talk to the lightwalletd server and check by asking for the latest height, and verify that it’s current with the Zcash network.
- Try interacting with lightwalletd by fetching a block and processing it. Then try fetching a range of blocks, which is much more efficient.
- Now that you have the blocks process them and list transactions that send to or are from that wallet, to calculate your balance.
- With a current balance (and funds, of course), send a transaction and monitor its transaction status and update the UI with the results.
Resources
You don’t need to do it all on your own.
- Chat with the team who built the kit: Zcash discord community channel, wallet
- Discuss ideas with other community members: Zcash forum
- Get funded to build a Zcash app: Zcash foundation grants program
- Follow Zcash-specific best practices: Zcash wallet developer checklist
- Get more information and see FAQs about the wallet: Shielded resources documentation