When you want to start developing application using quickP2P API you fist need to register as provider and then register your application in network using one of provider portals hooked up with network . All entities of your application regarding quickP2P will be enclosed in application scope. This means that although multiple providers having multiple applications can be present in network, your application sees only objects that belong to it. Of course what is usually common is that you can have your own super-node(s) hosted on your servers for single application you have.

So you start by registering as provider. After successful registration and log in you get to dashboard screen:  This is dashboard screen of provider portal:

Next thing you need to do is to register your application. Click on "Applications" button below provider contact data.

In bottom left corner there is button "New Application Request" where you enter basic information about your application and submit request to us so we could enable it. It will appear in applications list but it will not have status active until we enable it.

On a picture above you see example of enabled application. Notice 3 buttons:

  • "View Active Peers"  - enables you to have insight in currently active peers in your application and metadata
  • "List Virtual Networks" - enables you to have insight in created virtual networks and metadata
  • "List Virtual users" - enables you to have insight in created virtual users and metadata
  • "List Virtual objects" -  enables you to have insight in created general purpose virtual object and their metadata

These 4 options are most useful during development, because programmers can easily see if they are making some mistake.

Let's take a look at peers list: 

 

On picture you can see 3 records of currently active peers we filtered by query:

"Properties.platform":"windows"  (note quotes for later discussions about queries done from API)

 Besides common networking data we see in records, most important column would be "Properties". You notice that it has some JSON data format like:

{ "someproperty1" : "some value", "someproperty2" : "some value" }

 What is interesting about that is that we can put any property by our will and later be able to search peers by their value. Our query is exactly that "Properties.platform":"windows" ."platform" property would be custom property someone decided it would need meta data from its application (although he had OS column given automatically from API).

Let us now look at Virtual User List:

Virtual users and Virtual networks are part of permanent indexing metadata storage system.  Do not mix that with peers. Record about peer exists as long as peer is online.  VUser and VNetwork on other hand we can imagine like two database tables on which we can do INSERT/UPDATE/DELETE/SELECT operations.

 We also see "Properties" column here we can use in same way as for peers. Difference is that this data stays saved after peer using VUser object closes  session  with super-node.   You notice first property "Username". Because it is so common that peer-to-peer applications have username/password authentication we explicitly embedded their use , same stands for VNetwork "name" property. You can add other properties by your will and in special case if you don't need username/password authentication and you have need to use permanent meta-data storage  you can just fix them in some way.

VUser has also two additional fields (looking at VNetwork) "Member Of networks" and "Currently bound Peers".

"Member Of networks" filed that stores list of unique identificators of VNetworks VUser belongs to.  List we see on picture is from application that does not use VNetworks at all so all are empty.

 "Currently bound Peers"  shows list of peers that are currently  authenticated with VUser object.  Multiple peers can be authenticated using same VUser object.

We will not talk about Virtual networks and objects lists because they are very similar to VUser list and we mentioned all important things regarding this document section.

Next thing towards starting our application development would be to decide what to use because on some platforms you can chose between .NET and native c++. Here is some listing that may help you decide:

 

.NET API

Native C++ API

Java wrapper for native c++ API

Windows

Normal .Net DLL

.dll +.lib+headers

Dll + java wrapper sources

Linux

Mono

.so + headers

so + java wrapper sources

Mac OS

Mono

Cocoa .a + headers - you can mix with Obj C++ or use  just c++

 

IOS

Mono

Cocoa touch .a + headers - you can mix with Obj C++

 

Android

Mono

(NDK) .so + headers

(SDK)so + java wrapper sources