Description

Stunt is aimed at getting information from clients while an application is in development. We like to think of it as analytics for developers, because we inteded it to collect data from an application that is important from an application development stand point.But it can easily can be changed to collect any analytical data from an application that we deem important. We have convenience methods for sending string reports, sending images, sending any kind of files. We have implemented an example client for Android. Later on we can have one for iOS.

Architecture

Access
We use the API key to authenticate to the service. We have some code inplace, which would make it easy to switch to Token based authentication. Currently we have selected not to use it, since we don't want to have an initial call to get or refresh a Token. We want to make it easy to just send our report to the server at any moment without any preconditions. Although even if we decide to switch to Token authentication later, we can implement it in a way that the Stunt framework would ask and refresh the token whenever it is needed, without requiring the user to have a "register" call before any other report calls.

For the Android client implementation we have variables in StuntConst.java file:
    public static final int REPORTRATE_INSTANT = 0;
    public static final int REPORTRATE_TIME = 1;
    public static final int REPORTRATE_ON_EVENT_COUNT = 2;

This is that we intendet to implement reporting in different condition. But then we decide in the use case that we have in mind we don't need the latter to and implemented only the Instant mode of reports.
Also if we need the reporting to be more persistent we would implement a check if the report has been successfuly sent and if not we would keep the report until the next time we try to send a report and so on, until the application is running. If we want reports to be even more stubborn we would not keep such aggregated reports (only) in memory, but we will persist them to disk, so that we can even send them if the application is closed and later started again.

Database
We are currently using a SQLite database that is created in the current working directory of the application. Yes, yes we know. But is what is most convenient for development for us. If we are going to be using it with more than one or two user simultaneously this is not what we would want to use, since SQLite does not support concurent access. We could easily serialize the database access, but the users that are on the queue would ver quickly reach the point where their connectins will timeout often. But fear not. With one line of change we can use any other database. We intend to use it with Heroku's Postgre SQL:
database_stunt.go -> func DbInit:
db, err = sql.Open(DB_TYPE, DB_NAME) we should pass the database type and access URL.
In the constants_stunt.go file we can find the database tables and their structure.
TABLE_reports
TABLE_clientinfo
TABLE_invites
tables are suffixed with an API key. This way each API key has separate such tables from other api keys. It is a means of sharding the data, because there is no need to store all reports for all API keys in one set of these tables.


How to use the Stunt

The code in the repostory is a GoClipse (Eclipse) project. Ofcourse it can be easily setup to be built and used without GoClipse, like we are doing when deploying to Heroku.

Android application setup
  1. In AndroidManifest.xml add two meta-data tags at the end of the application tag:
  2. <meta-data android:name="stunt_enabled" android:value="true"/>
    <meta-data android:name="stunt_api_key" android:value="your_api_key_from_the_stunt_portal"/>
    
  3. Add Stunt source files or archive to you project.
  4. There is no registration needed, just use the appropriate “report” method.

Stunt web portal

  1. If you do not have an account create one by supplying an email and password on the registration page.


  2. Login using the email and password that you used to create an account.


  3. API Keys menu item - create an API key to be used in a client application.


  4. API Keys page