remove guides, add hackathon and docs
This commit is contained in:
Jarrad Hope
parent
fc2fd5ff60
commit
d41248ae9a
|
|
@ -1,47 +0,0 @@
|
|||
## Background for DApp Developers
|
||||
|
||||
More and more developers without much blockchain experience are now starting to develop Decentralized Apps, DApps, on Ethereum. And that’s exactly what we want! With more developers with a broad range of experiences and backgrounds, we’ll have a richer ecosystem of DApps for users and a better Web 3.0.
|
||||
|
||||
However, many developers then come with [questions which arise logically](https://www.quora.com/How-is-an-ethereum-dapp-hosted) from their other development experience — but questions which long-time blockchain users might not think of. In this article, we just want to give some background information to clear up some of these questions. If any of your questions aren’t answered, please come raise them on the Status [Slack](http://slack.status.im), and we might be able to address them in future articles.
|
||||
|
||||
### [What’s a decentralized app?](http://ethereum.stackexchange.com/questions/383/what-is-a-dapp)
|
||||
|
||||
One way to think of a blockchain is as a decentralized database. When you run a node in the blockchain, you’re hosting a local copy of this database. When this aspect of the blockchain became clear, developers naturally began to think of uses for the database other than validating transactions (as on Bitcoin).
|
||||
|
||||
In Ethereum, much of the business logic of your application, as well as transaction history, gets stored on the blockchain. For instance, if you made a fantasy football DApp, you’d [create a smart contract](https://medium.com/@ConsenSys/a-101-noob-intro-to-programming-smart-contracts-on-ethereum-695d15c1dab4), an address on the blockchain that can send and receive funds programmatically. You’d program your DApp to send and receive funds only in certain ways and under certain conditions. You’d allow your users to send funds to this smart contract to place their bets, and the smart contract would lock the funds in place until the football scores were available from a trusted source, and then pay out to the winner.
|
||||
|
||||
Already, in a very important sense, your app is decentralized! No central server stores your users’ data, and no central server makes the decisions about routing and handling money. All this happens on the blockchain, as Ethereum runs the code in your smart contract.
|
||||
|
||||
### Okay, how would my users access this app?
|
||||
|
||||
So now the backend of your app is decentralized. But what about your frontend — HTML, JavaScript, CSS? And how can your users access this backend?
|
||||
|
||||
Here’s what used to happen. You’d get a server, on DigitalOcean for instance. You’d download some implementation of the Ethereum network — a client like geth (Go-Ethereum) — so that your server can connect to and make calls to the Ethereum blockchain. You’d build your frontend any way you normally build your front end: React, Meteor, heck you can go all Web 1.0 with just HTML and minimal JS if you want. You serve that frontend on your server by making it available at a port and configuring your DNS to point to that address, the way you normally do.
|
||||
|
||||
Then, using the [Web3.js library](https://github.com/ethereum/web3.js/), your app would make calls to the geth network running on your server. Just as any web app sends info to, or gets info from, a database, your application will call your smart contract. In this way, your users access your app like any other web page, and your server accesses the decentralized part of your app.
|
||||
|
||||
### Wait, so who’s storing my app?
|
||||
|
||||
Well. If you just write a simple smart contract, Mist Wallet will also allow you to publish it to the Ethereum network (by compiling it to Ethereum Virtual Machine code, and then making it live on the network). In the future, Status will also allow you to publish to the Ethereum network from your mobile phone.
|
||||
|
||||
But neither Mist nor Status is storing the business logic of your app. That lives on the blockchain, and is served and stored peer-to-peer. Spookily, it’s everywhere and nowhere!
|
||||
|
||||
### And I have to set up an Ethereum node to access the backend?
|
||||
|
||||
To save you the trouble of setting up an Ethereum node, the fine folks at Ethereum and ConsenSys have come up with two solutions, and Status now provides a third mobile-based solution. The [Mist browser](https://blog.ethereum.org/2016/07/12/build-server-less-applications-mist/), the MetaMask plugin for Chrome, and the [Status mobile app](http://status.im) all handle making the calls to the Ethereum network. You still use Web.js to program your app, but you don’t have to run a local geth node. As a result, if your users are using Mist, MetaMask, or Status, you can provide your app like a normal web page, and your users access it like a normal web page.
|
||||
|
||||
### Doesn’t that mean the front end isn’t decentralized? Is there a decentralized way to host my front end code?
|
||||
|
||||
As you astutely point out, the front end is not decentralized at this point in your app development. Some DApps, like [Aragon, are hosting](https://medium.com/@ericxtang/an-ethereum-dapp-case-study-f4dd7c1cbe7a) the front end both in a centralized and a decentralized way, so you actually can do both at the same time.
|
||||
|
||||
To make your front end decentralized as well, you’ll need to [use Swarm](https://medium.com/@codeAMT/how-to-launch-swarm-for-dapp-testing-8003e55380e2) or [IPFS](http://ipfs.io). These are distributed file servers. Swarm is actually one of the [core Ethereum technologies](http://ethereum.stackexchange.com/questions/375/what-is-swarm-and-what-is-it-used-for), while IPFS is an [independent file system](https://en.wikipedia.org/wiki/InterPlanetary_File_System). To use a distributed file server, your website needs to be packaged as a single file.
|
||||
|
||||
Fortunately, as you probably know, the latest and greatest in web application technology is Single Page Application (SPA) architecture. Examples include [Meteor](https://github.com/ethereum/wiki/wiki/Dapp-using-Meteor), which plays very well with Reactive approaches to programming a complex webapp. As a result, you can build your web page, then package it up into a single file, and then publish it to Swarm or IPFS. This process still isn’t as easy or seamless as it should be and will be soon.
|
||||
|
||||
Your users will access your DApp with “www” if you host it on a centralized server (such as DigitalOcean or Amazon S3 or whatever), and with “bzz://” for Swarm, or “file://” for IPFS.
|
||||
|
||||
If you publish your front end in a decentralized way, your DApp really is full-stack decentralized, with both front and back ends being served from peer-to-peer networks. There are [many reasons](https://blog.ethereum.org/2014/08/18/building-decentralized-web/) to prefer developing with such an architecture, including safety, in some cases speed, and resilience to network attacks or downtime.
|
||||
|
||||
### Hope this helps!
|
||||
|
||||
Because there aren’t many explicit discussions of web-app vs. DApp hosting and architecture, we just wanted to provide some background information which will aid in understanding future, more practical, tutorials.
|
||||
|
|
@ -1,319 +0,0 @@
|
|||
## Giving Your DApp Commands on Status: Introduction to the Status Chat API
|
||||
|
||||
*(warning: the Chat API is still a work in progress. Come ask in the Slack if you hit bumps!)*
|
||||
|
||||
## Introduction
|
||||
|
||||
One of the first things you’ll notice when you start using Status is that you can send and receive funds just by issuing simple commands.
|
||||
|
||||
|
||||
*Easily send or request eth*
|
||||
|
||||
This is no accident! Today, more people use smartphones than computers, and when people are on their smartphones, they spend a lot of their time in messaging applications. Smartphone users enjoy using messaging to control applications, because it’s simple and convenient.
|
||||
|
||||
Status allows users to interact with a wide array of DApps using the same intuitive chat interface. In the near future, Status users will be able to have group chats where most of the participants are DApp chatbots. All DApp developers will benefit from this synergy, because a common chat interface for multiple DApps makes using your DApp more convenient, and effectively makes your DApp more powerful.
|
||||
|
||||
In this guide, we’ll explore how you can use the Status Chat API while developing your DApp on Status to create custom commands for your users. As a result of developing on Status, you’ll have a DApp that your users can access on MetaMask, Mist, and Status — and that invites mobile users with native mobile commands. With little extra developer time invested, you’ll gain a mobile app.
|
||||
|
||||
If you haven’t already, you can [join our Slack](https://slack.status.im), and download the [Android binary](https://test.status.im). We’d love to chat with you as you get started.
|
||||
|
||||
## Delivering Your Commands to Status
|
||||
|
||||
The majority of this tutorial covers the Status Chat API. First, though, let’s touch on how you’ll make your commands available after you’ve written them using the API.
|
||||
|
||||
To add a command to your DApp in Status, you’ll write your commands in JavaScript, put them in a file named `commands.js`, and make the file publicly available at `https://yourAwesomeDApp.com/commands.js`. When your DApp goes live and is added to Status, Status will take the file from that URL and create your commands.
|
||||
|
||||
If you decide to use the Truffle or Embark DApp development frameworks, they have standard locations which will put your commands.js file at the right URL. For Truffle, that’s the folder `public`, and for Embark, that’s the folder dist. So in Truffle, you’ll have `public/commands.js`, and in Embark, you’ll have `dist/commands.js`.
|
||||
|
||||
|
||||
|
||||
*commands.js locations on a Mac: Embark on the top, Truffle on the bottom*
|
||||
|
||||
The file itself will be the same whether you develop with Truffle, with Embark, or a different framework or no framework. You just need to place the file at the right location to make it available during development and after your DApp goes live.
|
||||
|
||||
During development, this location will be part of your local computer file system. If you’re developing with `truffle-box-status` or the `embark-status` plugin, you’ll be able to see your DApp on Status at `localhost:8080/commands.js` (for example), and Status will create your commands the same way. After you’ve finished development, you’ll need to host your DApp in the traditional way or in a decentralized way such as Swarm to make the whole thing publicly available.
|
||||
|
||||
Your users can see possible commands in one of two ways. If they’re chatting directly with your DApp, they can type a forward slash, “/”, and that will bring up a list of suggestions. Or they can click the bullet point icon to the left of the chat input box. If you haven’t defined any commands, clicking the bullet point list icon will just fill in the command `/browse`, which is a globally available Status command.
|
||||
|
||||
Your users will be able to access your DApp’s commands in a group chat as well, as long as your DApp has been added to the chat. In that case, your commands will show as `/yourAwesomeDApp/your-command`.
|
||||
|
||||
## The Status Commands
|
||||
|
||||
You can take advantage of three methods: `status.command()`, `status.response()`, and `status.on()`. These methods (along with a few methods used only by Status) are defined in the [Status GitHub repo](https://github.com/status-im/status-react/blob/develop/resources/status.js) at `resources/status.js`, in the `status` var.
|
||||
|
||||
Let’s walk through each, and the parameters each command takes. We’ll also build a toy `hello` example as we go. For easy reference, you’ll find the code for that example, as well as a summary of the methods and parameters, at the end of this article.
|
||||
|
||||
### status.command()
|
||||
|
||||
We’ll start with the the most important method available to you, the one that you’ll use for your DApp’s unique commands. You’re allowed to pass up to 12 parameters into `status.command()`.
|
||||
|
||||
1. `name`. This is what your users will type in following a forward slash to invoke the command. For instance, if you wrote `name: “hello”`, your user might invoke `/hello`.
|
||||
2. `title`. Remember that when your user starts typing a command, a list of suggestions appears. In the list of suggestions, the title appears on the left, above the description.
|
||||
3. `description`. Similarly, in the list of suggestions, the description appears on the left, below the title.
|
||||
4. `color`. This parameter defines the background color of the name of your command as it appears in the list of suggestions. Give commands different colors to help your users easily distinguish commands, and to harmonize with your DApp’s brand and color scheme.
|
||||
|
||||
You can see that these first four parameters control how your command will appear to your users in the list of suggestions. In addition, the `name` parameter gives your users a way to invoke your command. Here’s an example of the first four parameters defining a `/hello` command:
|
||||
|
||||
status.command({
|
||||
name: “hello”,
|
||||
title: “HelloBot”,
|
||||
description: “Helps you say hello”,
|
||||
color: “#7099e6”,
|
||||
});
|
||||
|
||||
5. `preview`. This option defines what your user will see as a result of *their* action, before any other response. The `preview` parameter takes a function, which should return a `status.component`.
|
||||
|
||||
|
||||
|
||||
For instance, if you use the command `/location`, from the Mailman DApp on Status, you’ll see a preview of a geographic location. This command is intended to send the user’s location to someone else, and so it doesn’t depend on the recipient’s response.
|
||||
|
||||
To continue with our `hello` example, you could add to the parameters you’ve already written above:
|
||||
|
||||
preview: function () {
|
||||
return status.components.text({}, “you’re saying hello”);
|
||||
},
|
||||
|
||||
We’ll discuss the `status.components` — there are only seven! — in the next section, after covering the other parameters to `status.command`.
|
||||
|
||||
6. `short-preview`. While `preview` controls how your command appears within your DApp’s chat, the `short-preview` parameter controls how your commands get shown in the list of chats, before your users tap on your chat.
|
||||
|
||||
|
||||
|
||||
7. `icon`. Suppose your user is interacting with your command. Each command can have a custom icon to appear in the command preview. For instance, if you request ETH from someone, a green two-way arrow appears in the preview. Or you can look again at the result of the `/location` command in the picture above. Next to `/location`, and above the map, there’s a small pin icon. Both are examples of command icons, another way to improve your design for your users.
|
||||
|
||||
8. params. This important option is where you define possible inputs to your command. It requires an array holding an object, with possible parameters `name`, `placeholder`, `suggestions`, and one of the `status.types`.
|
||||
|
||||
Here’s a simple example, which you might add to your `/hello` command:
|
||||
|
||||
params: [{
|
||||
name: “hello”,
|
||||
type: status.types.TEXT
|
||||
placeholder: "Why not say hello"
|
||||
}],
|
||||
|
||||
These `params` are available in any parameter, including in `params` itself. For instance, if your users sends `/hello whatsup`, the input `whatsup` will be available in your command under `params.hello`.
|
||||
|
||||
Naturally, the `type` dictates what sort of data your users may input. The available Status types are: `status.types.TEXT`, `status.types.NUMBER`, `status.types.PHONE`, and `status.types.PASSWORD`.
|
||||
|
||||
|
||||
*Notice the placeholder “Type your password”*
|
||||
|
||||
The `placeholder` parameter here only applies if your users haven’t put any input into the command, not even the name of the command. You can use it to include helpful guidance where necessary. This parameter will probably prove useful if you end up using `status.response()`, one of the other methods available to you, which we’ll cover in another section.
|
||||
|
||||
|
||||
*After you enter /faucet, two suggestions pop up.*
|
||||
|
||||
As another parameter inside `params`, you can also include `suggestions` for your users’ input. This should return a component to be rendered.
|
||||
|
||||
For instance, if you are using the Console DApp and you select the `/faucet` command, you’ll see two suggestions to choose from.
|
||||
|
||||
Let’s add this idea to our `hello` example:
|
||||
|
||||
params: [{
|
||||
name: “hello”,
|
||||
type: status.types.TEXT
|
||||
suggestions: helloSuggestions
|
||||
}],
|
||||
|
||||
That’s simple, but what’s `helloSuggestions`? Let’s make a function, which will return a `scrollView` that will hold two suggestions: “Hello”, and “Goodbye”. Don’t get intimidated by the length, there’s actually not much to it.
|
||||
|
||||
*// Three little helpers - don't worry about them, they're just for
|
||||
// style.*
|
||||
|
||||
function suggestionsContainerStyle(suggestionsCount) {
|
||||
return {
|
||||
marginVertical: 1,
|
||||
marginHorizontal: 0,
|
||||
keyboardShouldPersistTaps: true,
|
||||
height: Math.min(150, (56 * suggestionsCount)),
|
||||
backgroundColor: "white",
|
||||
borderRadius: 5,
|
||||
flexGrow: 1
|
||||
};
|
||||
}
|
||||
var suggestionSubContainerStyle = {
|
||||
height: 56,
|
||||
borderBottomWidth: 1,
|
||||
borderBottomColor: "#0000001f"
|
||||
};
|
||||
|
||||
var valueStyle = {
|
||||
marginTop: 9,
|
||||
fontSize: 14,
|
||||
fontFamily: "font",
|
||||
color: "#000000de"
|
||||
};
|
||||
|
||||
*// The main star of our show! It will return two touchable buttons.*
|
||||
|
||||
function helloSuggestions() {
|
||||
var suggestions = ["Hello", "Goodbye"].map(function(entry) {
|
||||
return status.components.touchable(
|
||||
{onPress: [status.events.SET_VALUE, entry]},
|
||||
status.components.view(
|
||||
suggestionContainerStyle,
|
||||
[status.components.view(
|
||||
suggestionSubContainerStyle,
|
||||
[
|
||||
status.components.text(
|
||||
{style: valueStyle},
|
||||
entry
|
||||
)
|
||||
]
|
||||
)]
|
||||
)
|
||||
);
|
||||
});
|
||||
|
||||
*// Let's wrap those two touchable buttons in a scrollView*
|
||||
var view = status.components.scrollView(
|
||||
suggestionsContainerStyle(2),
|
||||
suggestions
|
||||
);
|
||||
|
||||
*// Give back the whole thing inside an object.*
|
||||
return {markup: view};
|
||||
}
|
||||
|
||||
The main point of this example is that your `suggestions` parameter should accept users’ input, and then return a component to be rendered.
|
||||
|
||||
9. `suggestionsTrigger`. Now that we’ve covered `params` and the possibility of `suggestions`, it’s easy to see that `suggestionsTrigger` will take a string corresponding to an event which triggers showing suggestions. If you don’t include this parameter, the default is `"on-change"`, so your suggestions will show when your users select the command.
|
||||
|
||||
10. `fullscreen`. If your command has suggestions, this param controls whether that list of suggestions expands to fill the entire screen. If your command has a lot of suggestions, you might want set `fullscreen` to true, so that your users don’t have to pull the list upwards. On the other hand, if your command has only a few suggestions and you set `fullscreen` to true, your users will have to pull the list downwards to keep it from hiding the screen. Choose whichever will be most convenient to your users, considering your command’s suggestions.
|
||||
|
||||
|
||||
*/send’s validator function says “la la la” is not a valid amount of ETH!*
|
||||
|
||||
11. `validator`. This parameter allows you to check your users’ input before sending off the command. It takes a function, which should return an error if the input is invalid.
|
||||
|
||||
You can easily see an example if you try to send an amount of ETH that’s not a number! To continue with our `/hello` example, you might write something like:
|
||||
|
||||
validator: function(params) {
|
||||
if (!params.hello) {
|
||||
return status.components.text({}, “Say hello”);
|
||||
}
|
||||
}
|
||||
|
||||
This will raise an error if your user doesn’t input a string. Notice that you should return your message inside one of the `status.components`.
|
||||
|
||||
12. `handler`. Of course, you probably want the command to do something when your users call it! The `handler` parameter takes a function to accomplish this. For instance, suppose your user inputs `/hello howdy`. “Howdy” is a valid string, and will pass the `hello` validator. From there, your `handler` could take over to send this greeting to another user:
|
||||
|
||||
handler: web3.shh.post(params.hello),
|
||||
|
||||
If you don’t provide a `handler`, your user will issue the command and then see the `preview`, but nothing else will happen.
|
||||
|
||||
### The Status Components
|
||||
|
||||
There aren’t many of these components, and you’ll feel very comfortable with them if you’re at all familiar with React. The [`scrollView`](https://facebook.github.io/react-native/docs/scrollview.html), [`webView`](https://facebook.github.io/react-native/docs/webview.html), [`text`](https://facebook.github.io/react-native/docs/text.html), [`image`](https://facebook.github.io/react-native/docs/image.html), [`view`](https://facebook.github.io/react-native/docs/view.html), and [`touchable`](https://facebook.github.io/react-native/docs/touchablehighlight.html) take standard React props (each of those underlined words is linked). `validationMessage` is a custom Status component that just takes two strings, and will return them wrapped in text components inside a `view`. Here’s a list, taken straight from the Status code:
|
||||
|
||||
components: {
|
||||
view: view,
|
||||
text: text,
|
||||
image: image,
|
||||
touchable: touchable,
|
||||
scrollView: scrollView,
|
||||
webView: webView,
|
||||
validationMessage: validationMessage
|
||||
}
|
||||
|
||||
### status.response()
|
||||
|
||||
Now that you’ve covered all the parameters for `status.command()`, you can easily understand `status.response()`. This method takes the same parameters that `status.command()` does. The difference is that with this method you can actively ask a user to issue a command.
|
||||
|
||||
For example, the Status DApp Wallet allows you to `/request` money. In that case, the person you’re requesting money from will see the result of `status.response(send)` — they’ll be asked to give a command, `/send`, in response to your `/request` command.
|
||||
|
||||
The Wallet example illustrates that as a DApp developer, you may wish to use `status.command()` and `status.response()` together to create dialogues of commands. You could also use `status.response()` by itself to prompt your users to enter necessary information as part of the onboarding process for your DApp.
|
||||
|
||||
Because `status.command()` and `status.response()` take the same parameters, you can sometimes use nearly the same code for both of them. You simply have to consider when you want to ask a user to issue a command, and when you want to just make the command available. Most of the time, you’ll use `status.command()`.
|
||||
|
||||
To return to our `hello` example, if we used all the same code inside our method but used `status.response()`, a user would be asked to respond to another user’s greeting. Hello back!
|
||||
|
||||
### status.on()
|
||||
|
||||
The method `status.on()` allows your DApp to respond to events. This method requires an event name as a string, and a callback function. For instance, you might define:
|
||||
|
||||
status.on(“init”, function(params, context) {
|
||||
status.sendMessage(“Hello, man!”);
|
||||
});
|
||||
|
||||
With the `"init"` option, your DApp will trigger `status.sendMessage()` when the Status app loads your DApp — your DApp will greet your users even before they have clicked on it. Other options include `“text-change”` and `“message”`.
|
||||
|
||||
## That’s All For Now, Folks
|
||||
|
||||
Please join other DApp developers in [our Slack](https://slack.status.im) in the #dapp-chat or #dev-status channels.
|
||||
|
||||
Finally, here’s the TL;DR of what we’ve covered.
|
||||
|
||||
### status.command()
|
||||
|
||||
1. `name`:string
|
||||
|
||||
1. `title`:string
|
||||
|
||||
1. `description`:string
|
||||
|
||||
1. `color`:string, containing valid hex color.
|
||||
|
||||
1. `preview`:function
|
||||
|
||||
1. `icon`:string
|
||||
|
||||
1. `params`:array holding object with parameters `name`, `type`, `placeholder`, and `suggestions`.
|
||||
|
||||
1. `suggestionsTrigger`
|
||||
|
||||
1. `fullscreen`:boolean. If not included, default is `false`.
|
||||
|
||||
1. `validator`:function
|
||||
|
||||
1. `handler`:function
|
||||
|
||||
1. `short-preview`
|
||||
|
||||
Example `commands.js` file to create `hello` command:
|
||||
|
||||
status.command({
|
||||
name: “hello”,
|
||||
title: “HelloBot”,
|
||||
description: “Helps you say hello”,
|
||||
color: “#7099e6”,
|
||||
preview: function () {
|
||||
return status.components.text({}, “you’re saying hello”);
|
||||
},
|
||||
params: [{
|
||||
name: “hello”,
|
||||
type: status.types.TEXT
|
||||
suggestions: helloSuggestions
|
||||
}],
|
||||
suggestionsTrigger: 'on-change',
|
||||
fullscreen: false,
|
||||
validator: function(params) {
|
||||
if (!params.hello) {
|
||||
return status.components.text({}, “Say hello”);
|
||||
}
|
||||
},
|
||||
handler: web3.post.shh (params.hello)
|
||||
|
||||
});
|
||||
|
||||
### Status Components
|
||||
|
||||
Standard React Native components, except for `validationMessage`, which just wraps standard components.
|
||||
|
||||
components: {
|
||||
view: view,
|
||||
text: text,
|
||||
image: image,
|
||||
touchable: touchable,
|
||||
scrollView: scrollView,
|
||||
webView: webView,
|
||||
validationMessage: validationMessage
|
||||
}
|
||||
|
||||
### status.response()
|
||||
|
||||
Takes all the same parameters as `status.command()`. Use `status.response()` to ask a user to issue a command, whether in response to another command, or as part of your DApp setup.
|
||||
|
||||
### status.on()
|
||||
|
||||
Requires an event name as a string, and a callback function.
|
||||
|
|
@ -1,209 +0,0 @@
|
|||
## Starting a DApp on Status with Truffle and Embark
|
||||
|
||||
*(warning: the Truffle/Embark functionality is still a work in progress. Come ask in the [Slack](http://slack.status.im) if you hit bumps!)*
|
||||
|
||||
Web 3.0 is here! The new distributed web gives new building blocks to developers and entrepreneurs to create new Distributed Apps, or DApps. And Status helps put your DApp in the hands of mobile users across the globe.
|
||||
|
||||
In this tutorial, we’ll use the Truffle and Embark frameworks to create a basic DApp ready for further development, and we’ll deploy it on mobile using Status. After we’re done, you’ll be ready to continue developing your DApp, and when you eventually go live, your users will be able to access your DApp by browsing through the Status app, the Chrome MetaMask extension, or the Ethereum Mist browser. One development process, three ways of accessing your DApp!
|
||||
|
||||
### A Quick Overview Before We Get Started
|
||||
|
||||
Broadly speaking, for both Truffle and Embark, you’ll get the Status app running and connected to your computer, either on a simulator or on a real phone. Next, you’ll install some necessary dependencies. Then, you’ll start testrpc, a mini-Ethereum network that runs on your computer. Finally, you’ll install the Status Truffle box or the Status Embark plugin, create a basic demo app, and add it to Status.
|
||||
|
||||
## Installing Status
|
||||
|
||||
To develop on Status, you need to have Status running either:
|
||||
|
||||
* on a real phone,
|
||||
|
||||
* in an Android simulator, or
|
||||
|
||||
* in an iOS simulator.
|
||||
|
||||
You can go to [https://test.status.im](https://test.status.im) to download for Android. At the time of writing, we’re out of invitations for Testflight iOS, but you can sign up for early iOS access [on our website](http://status.im).
|
||||
|
||||
If you are running in an Android simulator, you also need to run on the command line: `adb forward tcp:5561 tcp:5561`
|
||||
|
||||
If you don’t have a smartphone, or you only have an iPhone but want to get started right away, you can build Status yourself for either Android or iOS by following [these guidelines](https://wiki.status.im/contributing/development/building-status/). Following those guidelines, you can install an Android simulator, or start up Status in the Xcode simulator. Our wiki guidelines should be all you need, but if you get lost come ask around in [our Slack](https://slack.status.im).
|
||||
|
||||
## Enabling Debugging
|
||||
|
||||
|
||||
*With your phone connected, /debug “On”*
|
||||
|
||||
We’ll assume you have Status open, and that if you’re using a physical phone it’s connected to your computer. Now we need to enable debugging from within the Status app. After you’re logged in to Status, click on Console and run `/debug`, then pick “On.” You’ll get back a message telling that debugging is on, and that you can use the [status-dev-cli](https://github.com/status-im/status-dev-cli) tools if you want. You don’t need those right now, because you’ll be using the pre-configured Status Truffle box or the Embark plugin.
|
||||
|
||||
The message also shows you your IP address, which you’ll need later for Embark.
|
||||
|
||||
## Installing Git, Node, and NPM
|
||||
|
||||
We’ll use the version control tool Git to install the Truffle and Embark frameworks. If you have Xcode installed, Git is probably already installed. To see if it’s installed, open Terminal or any command line program and just enter `git`. You should see a list of common Git commands. If you don’t, you can install Git with [these instructions](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git).
|
||||
|
||||
We’ll also use node and the Node Package Manager (NPM) to install some dependencies, so make sure you have the latest versions installed. In particular, `testrpc` will complain if you don’t have at least Node 6.9.1.
|
||||
|
||||
On OSX, the easiest way to install node is with [Homebrew](https://brew.sh). You can run `brew install node`, and the check the version with `node --version`.
|
||||
|
||||
### Installing testrpc
|
||||
|
||||
To install testrpc, you just need to enter this on your command line:
|
||||
|
||||
npm install -g ethereumjs-testrpc
|
||||
|
||||
What’s `testrpc`? When you deploy your DApps, you are asking the Ethereum network to create an address for them. When you use your DApps, you pay the Ethereum network for the steps that your code takes. Your DApps talk to the Ethereum network through remote procedure calls, or RPC’s. A local network makes this whole process very fast, so that it’s easy to develop your DApps. Essentially, `testrpc` gives you a small Ethereum network on your computer.
|
||||
|
||||
For more about gas and ether, see the top answer on this [StackExchange question](http://ethereum.stackexchange.com/questions/3/what-is-gas-and-transaction-fee-in-ethereum).
|
||||
|
||||
## Using Truffle
|
||||
|
||||
While the steps up till now apply to using both Truffle and Embark, now we’ll cover steps specific to each framework. Let’s start with Truffle. If you just want to use Embark, you can skip to the next section.
|
||||
|
||||
### Running testrpc
|
||||
|
||||
If you try to run `truffle migrate` in the next section without `testrpc` running, it’s going to give you an error. So let’s get it going. Open Terminal or any command line program and enter the command:
|
||||
|
||||
`testrpc`
|
||||
|
||||
That’s it! It will show you a list of available accounts, private keys, Wallet, and mnemonic.
|
||||
|
||||
Now open a new shell (such as a new Terminal window or tab) for the next part. You’ll leave testrpc running in the first window, and use the second window for the rest of the tutorial.
|
||||
|
||||
### Installing Truffle
|
||||
|
||||
Now that you have `testrpc` running, and a new shell open, you’ll run:
|
||||
|
||||
npm install -g truffle // Version 3.0.5+ required.
|
||||
|
||||
This installs the Truffle framework, and you can find its GitHub [page here](https://github.com/trufflesuite/truffle).
|
||||
|
||||
With the Truffle framework installed, we can grab the Status Truffle Box, and get a basic DApp running. All the Truffle boxes also include the app frameworks React and Redux, which were designed by Facebook and are widely used by app developers. You can find the other Truffle [boxes here](https://truffle-box.github.io/), but for this tutorial you should use the Status Truffle Box, because it’s set up to be added to Status.
|
||||
|
||||
To install the Status Truffle box, all you have to do is run this command in the same Terminal window:
|
||||
|
||||
git clone [https://github.com/status-im/truffle-box-status.git](https://github.com/status-im/truffle-box-status.git)
|
||||
|
||||
With the Status Truffle box successfully cloned, let’s walk through the next steps of running your DApp.
|
||||
|
||||
# Change into the truffle box directory
|
||||
cd truffle-box-status
|
||||
|
||||
# install the node dependencies
|
||||
npm install
|
||||
|
||||
|
||||
*Example on OS X: testrpc running on the left, and installing Truffle on the right*
|
||||
|
||||
# Compile the contracts from Solidity (much like JavaScript) into
|
||||
# runnable EVM code
|
||||
truffle compile
|
||||
|
||||
# Publish the compiled contracts to your network. testrpc must
|
||||
# already be running
|
||||
truffle migrate
|
||||
|
||||
As you run the `migrate` command, you can look at the window with `testrpc` running, and you’ll see your transactions being published to your local network.
|
||||
|
||||
### Running our Truffle DApp on Status
|
||||
|
||||
Now we are ready to see our DApp running on Status.
|
||||
|
||||
From within your DApp directory, run:
|
||||
|
||||
# Run your JavaScript
|
||||
npm run start
|
||||
|
||||
This should tell you that the the app is running, and that the DApp has been added to the Status Contacts.
|
||||
|
||||
|
||||
*The DApp added to the default Contacts*
|
||||
|
||||
After you’ve clicked on your DApp within Status, you’ll see that the chat area at the bottom shows `/browse [http://localhost:](http://localhost:8080/)3000/` for iOS, and `/browse [http://10.0.3.2:3000/](http://10.0.3.2:3000/)` for Android.
|
||||
|
||||
In fact, you can also browse to that address from Console with the command `/browse`, just like you could browse to any other web address inside Status. You can also enter that address into your browser, and you’ll see the same thing.
|
||||
|
||||
## Using Embark
|
||||
|
||||
Now that we’ve covered Truffle, let’s take a look at Embark.
|
||||
|
||||
### Installing Embark and Starting the Network
|
||||
|
||||
Now that you have Status running and your dependencies installed, you’ll run:
|
||||
|
||||
npm -g install embark
|
||||
|
||||
This installs the Embark framework, and you can find its GitHub [page here](https://github.com/iurimatias/embark-framework).
|
||||
|
||||
With the Embark framework installed, we can make a demo DApp:
|
||||
|
||||
embark demo
|
||||
|
||||
#change into the directory
|
||||
cd embark_demo
|
||||
|
||||
Next we want to run the network. You can run a full Ethereum node with `embark blockchain`, but for development you probably want to run `testrpc` with:
|
||||
|
||||
embark simulator
|
||||
|
||||
### Configuring our Embark DApp forStatus
|
||||
|
||||
Now we are almost ready to see our DApp running on Status — this part is short and easy. Open a new shell tab in the same DApp directory, and run:
|
||||
|
||||
npm install embark-status --save
|
||||
|
||||
In the same directory, open the file `embark.json` and edit the `plugins` key:
|
||||
|
||||
"plugins": {
|
||||
"embark-status": {
|
||||
"deviceIp": "your-device-ip",
|
||||
"whisperIdentity": "dapp-test",
|
||||
"name": "MyDapp"
|
||||
}
|
||||
}
|
||||
|
||||
You can get the device IP from the Status Console, which was shown after you ran `/debug “On"` above. For instance, if `/debug` told me my IP was `10.0.3.15`, the entire `embark_demo/embark.json` file would look like this:
|
||||
|
||||
{"contracts": ["app/contracts/**"],
|
||||
"app": {
|
||||
"css/app.css": ["app/css/**"],
|
||||
"images/": ["app/images/**"],
|
||||
"js/app.js": ["embark.js", "app/js/_vendor/jquery.min.js", "app/js/_vendor/bootstrap.min.js", "app/js/**"],
|
||||
"index.html": "app/index.html"
|
||||
},
|
||||
"buildDir": "dist/",
|
||||
"config": "config/",
|
||||
"plugins": {
|
||||
"embark-status": {
|
||||
"deviceIp": "10.0.3.15",
|
||||
"whisperIdentity": "dapp-test",
|
||||
"name": "MyDapp"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Finally, if you’re running Status on Android, enable port forwarding with:
|
||||
|
||||
adb forward tcp:5561 tcp:5561
|
||||
|
||||
### Running the DApp
|
||||
|
||||
Now we’re ready to run the DApp on Status. From within your DApp directory, run:
|
||||
|
||||
# start your DApp
|
||||
embark run
|
||||
|
||||
The Embark console will appear within your shell with useful information about the SimpleStorage contract it has created, compiled, and deployed. It will also tell you that the DApp has been added to Status!
|
||||
|
||||
|
||||
|
||||
*The Embark simulator runs in one Terminal window on the top, and the Embark console on the bottom*
|
||||
|
||||
You should be able to tap the Contacts tab within Status and see your DApp there. After you’ve clicked on your DApp within Status, you’ll see that the chat area at the bottom shows `/browse [http://localhost:](http://localhost:8080/)8000/` for iOS, and `/browse [http://10.0.3.2:8000/](http://10.0.3.2:3000/)` for Android.
|
||||
|
||||
In fact, you can also browse to that address from Console with the command `/browse`, just like you could browse to any other web address inside Status. You can also enter that address into your browser, and you’ll see the same thing.
|
||||
|
||||
## You’re Off to the Races
|
||||
|
||||
Using Status, you can now develop mobile DApps as easily as developing for MetaMask or Mist! But Status offers extra goodies as well.
|
||||
|
||||
In particular, Status will help you allow your users to chat with your DApp! The chat interface will let your users easily and intuitively accomplish tasks. In the future, your users will be able to hold group conversations where all the other participants are DApps, which is kind of amazing.
|
||||
|
||||
Later we’ll have an easy mechanism to make your DApp available for others to use on Status, but for now please just submit a pull request using our [guide on adding DApps](http://wiki.status.im/contributing/development/adding-dapps/).
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 136 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 38 KiB |
12
mkdocs.yml
12
mkdocs.yml
|
|
@ -32,18 +32,6 @@ pages:
|
|||
- Blog: 'community/blog.md'
|
||||
- Tell a Friend: 'community/tell-a-friend.md'
|
||||
# - Transcripts: # Slack
|
||||
- Guides:
|
||||
- For Users:
|
||||
- User Guide: 'getting-started/user-guide.md'
|
||||
- Grow our Community: 'community/how-to-grow-our-community.md'
|
||||
- For Developers:
|
||||
- Developer Introduction: 'contributing/development/introduction.md'
|
||||
- Building Status: 'contributing/development/building-status.md'
|
||||
- Background for DApp Developers: 'guides/developers/background-for-developers.md'
|
||||
- Starting a DApp on Status with Truffle and Embark: 'guides/developers/starting-a-dapp-on-status-with-frameworks.md'
|
||||
- Introduction to the Status Chat API: 'guides/developers/introduction-to-status-chat-api.md'
|
||||
|
||||
|
||||
- Proposals:
|
||||
- Commiteth (WIP): 'proposals/commiteth.md'
|
||||
- Contact Sharing (WIP): 'proposals/contact-sharing.md'
|
||||
|
|
|
|||
|
|
@ -55,6 +55,12 @@
|
|||
</li>
|
||||
{%- endif %}
|
||||
{%- endblock %}
|
||||
<li>
|
||||
<a href="https://hackathon.status.im" target="_blank">Hackathon</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://docs.status.im" target="_blank">Docs</a>
|
||||
</li>
|
||||
|
||||
{%- block search_button %}
|
||||
<li class="search-link">
|
||||
|
|
|
|||
Loading…
Reference in New Issue