lbrenman

#PDF Viewer demo - from web site URL

1. check if PDF has been downloaded from web site and stored in file system
2. if not, then retrieve from web site and store in file system and open

• use docviewer on ios and exernal app (via intent) on android

3. if so, then open pdf

• use docviewer on ios and exernal app (via intent) on android

Note that Android, the file is stored in the externalStorageDirectory (SDCard) so deleting the application will not remove the pdf form the SDCard. Use a File Manager app (pn Android) to delete the file

lbrenman

#Stock Watch List using Appcelerator Arrow

See how Appcelerator Arrow can be used to create a mobile Stock Watch List.

The Appcelerator mBaaS is a powerful, scalable middleware platform for accelerating and optimizing mobile applications. In a prior post I described how to leverage the Appcelerator mBaaS, Node.ACS and ACS to create a Stock Watch List that could be utilized in a brokerage application. By storing the Watch List in the mBaaS, you are able to keep the Watch List synchronized among all your mobile devices. Furthermore, the mobile application is more performant since it does not need to make repeated calls to the stock quote service for each stock symbol in the Watch List; instead it can make a call to one API and the mBaaS does the rest. Refer to the blog post for more background on this.

This blog post will

lbrenman

#Watchlist Example

An example of a financial watch list API for storing a watch list on the cloud and fetching quote data when you retreive the watch list. The watch list is basically a list of stock symbols (e.g. AAPL, TXN, INTC, ...) stored in an ArrowDB. When the watch list is retreived, Arrow will use a block to fetch stock quote data from MarkitOndemand REST API using my stockquote Arrow connector (addstockquote.js). Alternatively, this can be done with the connector by accessing the markitondemand REST API directly (addstockquote_.js).

Why do a watch list in the cloud instead of on device? So that the watch list will be synced across multiple devices for the same user.

Concept is based on a similar concept implemented in ACS/Node.ACS:

MarkitOndemand APIs are:

lbrenman

#Arrow Custom Authentication Scheme Example

Arrow supports various API authentications out of the box. The first three, None, Basic and APIKey simply require setting APIKeyAuthType in the conf/default.js file and Arrow takes care of the rest. This post provides an example of the 4th method called plugin which is used for custom or 3rd party API authentication. Appcelerator Arrow Authentication is described here.

I will also demonstrate how to implement some API Management features such as:

1. Suporting multiple API Keys for different users
2. Auto API Key generation
3. Tracking API usage per user

lbrenman

var Arrow = require("arrow");

var Model = Arrow.Model.reduce("appc.salesforce/Account","Account",{
	"fields": {
		"Name": {
			"type": "string",
			"description": "Account Name",
			"readonly": false,
			"maxlength": 255,
			"required": true,

lbrenman

#Arrow Authentication Scheme

https://gist.github.com/lbrenman/f884ea1f43d75ed98deb

*Using Basic APIKey Authentication provides a single key for all users of the API

• What if want to provide a different API Key for different users/customers

• this is an API Management feature

• Today, we don’t support this but it can easily be built using Arrow Authentication Scheme
• Further, ArrowDB can be used to store the users and their keys for authentication
• Then, access to the API can use different keys (passed in a header) and the user API can use a separate private key that only the admin/Arrow project developer knows

lbrenman

<Alloy>
  <Window backgroundColor="white">
    <Label>Hello Boyd</Label>
  </Window>
</Alloy>

lbrenman

#Appcelerator Arrow - Server-Side Field Validation

Much has been written about client-side vs server-side validation. The basic issue is when is it best to notify the user that the data entered, say in a form, is incorrect? The closer to the user that you perform validation (e.g. in the front end app) the faster the response and the better the user experience. If you don't do client side validation and post incorrect data and get an error reply from the back end application then the user has to wait just to find out that the form was filled in incorrectly. On the other hand, if you do all the validation in the client application then you run the risk of needing to deploy a new application when the validation logic/rules change. In most application scenarios, you will most likely do both: basic validation on the client and additional validation on the server.

This blog post will describe some of the facilities provided for performing field validation in an Arrow API.

##Getting Started

lbrenman

var Arrow = require("arrow");
var jobTitle = new Array("SA", "SE", "VP", "SAM", "SDR");

var Model = Arrow.createModel("employee",{
	"fields": {
		"fname": {
			"type": "String"
		},
		"lname": {
			"type": "String",

lbrenman

var Arrow = require("arrow");

var Model = Arrow.Model.reduce("appc.salesforce/Account","Account",{
	"fields": {
		"Name": {
			"type": "string",
			"description": "Account Name",
			"readonly": false,
			"maxlength": 255,
			"required": true,