Mobile News Round-up – October 31, 2013

Welcome to our latest mobile summary of the week, covering October 2 through to October 30. Every week this time we will look at mobile software stack news, tutorials and commentaries we’ve seen online.

120,000 Apps in BlackBerry World (Spoiler: 47,000 Made by One Developer)

Blackberry App inventory shows motivating developer communities with $10,000 app bounty incentives is a poor substitute for inspiring drive from within.

Linkedin ‘Intro’duces Insecurity & Linkedin Intro, doing impossible on iOS

Linkedin’s new multi app mobile strategy launches under a buzz of security and privacy concerns. Reminding us when it comes to ‘social as a services’ platform’s we are both the product and the customer.

Mobile At Scale

@clayallsopp shares mobile trends from Facebook hosted mobile at scale mini-conf. Featuring talks by developers from Facebook, LinkedIn, Twitter, Pinterest, Dropbox, and Mailbox.

Stripe gives Payments infrastructure for mobile, web and now Node.js

Mobile Card payment processor Strip officially adopts Bjørn Hansen Node.js npm module giving confidence in using $ npm install stripe for backend payment processing.

Relying on a Google API and going over the quota on launch day reminds us to mind or p’s and q’s (profit’s and quota’s, that is) on free-mium mobile backend services. @ryanoldenburg retrospects pushbullet’s experiencing hitting Google Cloud Messaging (GCHM) quota ceiling on launch.

Snapchat Mulls Raising Money at $3 to $4 Billion Valuation

Snapchat follows twitter, Instagram and Facebook with its ‘twist’ to mobile app messaging as they seek a multi-billion dollar valuation.

What’s next?

Recipes for LoopBack Models, part 5 of 5: Model Synchronization with Relational Databases

Last time, we looked at using LoopBack while defining models from scratch. In the last part of this 5-part series, we demonstrate how to synchronize your data.

Now I have defined a LoopBack model, can LoopBack create or update the database schemas for me?

LoopBack provides two ways to synchronize model definitions with table schemas:

  • Auto-migrate: Automatically create or re-create the table schemas based on the model definitions. WARNING: An existing table will be dropped if its name matches the model name.

  • Auto-update: Automatically alter the table schemas based on the model definitions.


Let’s start with auto-migration of model definition. Here’s an example:

Assuming the model doesn’t have a corresponding table in the Oracle database, you can create the corresponding schema objects to reflect the model definition:

This creates the following objects in the Oracle database:

  • A table CUSTOMER_TEST.

  • A sequence CUSTOMER_TEST_ID_SEQUENCE for keeping sequential IDs.

  • A trigger CUSTOMER_ID_TRIGGER that sets values for the primary key.

Now we decide to make some changes to the model. Here is the second version:


If we run auto-migrate again, the table will be dropped and data will be lost. To avoid this problem use auto-update, as illustrated here:

Instead of dropping tables and recreating them, autoupdate calculates the difference between the LoopBack model and the database table definition and alters the table accordingly. This way, the column data will be kept as long as the property is not deleted from the model.


This series has walked through a few different use cases and how LoopBack handles each. Take a look at the table below for a round-up of what was covered.

RecipeUse CaseModel Strict ModeDatabase
Open ModelTaking care of free-form datafalseNoSQL
Plain ModelDefining a model to represent datatrue or falseNoSQL or RDB
Model from discoveryConsuming existing data from RDBtrueRDB
Model from introspectionConsuming JSON data from NoSQL/RESTfalseNoSQL
Model synchronizationMaking sure models are in synctrueRDB





What’s next?

Using a Digital Ocean Droplet for On Demand Node.js Mobile Backend


The tagline “Digital Ocean provides blazing fast SSD cloud servers at only $5/month” does not do Cloud provider Digital Ocean justice.

In addition to the performance of the server instance (a droplet in Digital Ocean lingo), Digital Ocean has become a favorite of developers for the following reasons:

  • low cost performance
  • Droplets standup fast, very fast ( 59 seconds fast )
  • Static external IP address for every droplet
  • Droplet’s disk, RAM, and IP address are all reserved while the droplet is off
  • Snapshot feature allows you to save the droplet after you have destroyed the instance.
  • Preserving costs and making for a fast standup of your configuration for developer Sandbox preserving costs)
  • You will be able to create a new droplet from the snapshot image anytime to bring it back online.

Creating and Configuring your Digital Ocean Virtual Machine

  1. Login to Digital Ocean and Create your droplet in less than a minute. Image
  2. Configure your host name Image
  3. Select your configration size. Image
  4. Select your region. Image
  5. Select your Image, in this walk through I will create it from Linux Ubuntu 12.04 x32. However you can start from an “Application” image such as Docker or WordPress, or from one of your own “SnapShot” image ( these are great for standing up a dev stage fast). Image
  6. Count to 60. Image

Standing up your Node.js mobile services with StrongLoop


Now that your Virtual Machine droplet is up, check your email for your login, password and IP Address. The email will look like:

  1. From the terminal ssh to your new instance with `ssh root@′ and the password provided.

  2. Now let’s configure the server with the StrongLoop Node distro, to make this step easier I created a small install script to install dependencies get you up quickly.

The script will update apt-get and install some of the usual suspects: python-software-properties, vim git subversion curl , memcached, build-essential, etc ( feel free to modify for your specific configurations) s. Additionally it will download and install the latest StrongLoop Debian distro fromStrongLoop. Finally the script will create a /var/apps folder for you to hold your Node applications.

To run the script on your server:

  1. copy the contents of to your copy buffer with CMD+Copy
  2. From the terminal you can simply ‘wget‘ Just copy past the script to your command line with.
  3. …and then run the command with ‘chmod +x; ./’
    1. Stand Up your LoopBack Mobile Server with the following commands

You can verify the installation by starting your server with ‘slc run app.js’ and open a web browser on your local machine to the servers address and the default port

Now that you have a LoopBack mobile server with mobile models for product, store, and customer you can use them from your mobile application development workflow.

Integrating your Native iOS App


Now we can integrate a mobile application with our Digital Ocean SSD virtual machine and theLoopBack Node API server using the native LoopBack iOS SDK.

The best part is we don’t even need to install Node or LoopBack on our local dev machine ( although this is useful if you want to run your development cycle on your local box when your disconnected from the network ). You can download the iOS Framework SDK directly from ([] and start with your process.

  1. Clone the iOS example apps on your local machine
  1. Open the TableView example in XCode (you should also checkout the MapView and Remote Procedure projects as well).

You can open the XCode project with the following command on your local dev machine.

  1. Update the endpoint URL to match your newly instantiated Digital Ocean virtual machine IP address, by modifying the AppDelegate.m file in the tableview-example group:

change :


  1. Run the project in the simulator with the ( ⌘ + R ) hot key or press the play triangle in the top left corner of XCode.

The Examples app will leverage the “product” model that you defined when creating your LoopBack Node Server instance, so you can simply explore the code in the ViewController.m file to see how to Create, Read, Update and Delete Mobile defined models from your Objective-C iOS mobile Application.

There is no need to define a static model schema, since LoopBack will allow the Mobile Developer to define the Model attributes dynamically from the mobile Application.

Make sure and checkout the LoopBack documentation on how to leverage the built in filter functionsand also to Connect your Node.js mobile objects to additional connectors or Server data stores such as MongoDB or Oracle.

‘Snapshot’ your Droplet for on demand mobile backend

Now that you have your StrongLoop Loopback server configured and your mobile application connected, you can take advantage of the Digital Ocean Snapshot feature. This makes it fast and easy to spin up a mobile backend in a few seconds with zero server configuration.

What’s next?

Node.js News Round-up – October 29, 2013

Welcome to our latest summary of the week in Node.js news covering October 22 through October 28. Every week this time we will look at some of the Node.js-related news, tutorials and commentaries we’ve seen online.

Performance Comparison Between Node.js and Java EE

Marc Fasel has been impressed with Node.js and its high performance, and decides to pit it against Java EE to beat performance targets. The task: fetching JSON documents from CouchDB.

Apigee Adds Support for Node.js to Become a Better API Manager

Nathaniel Mott reports on Apigee betting on the growing importance of public APIs in software development.

Elevator Pitch: Nick Sturiale of Ignition Partners

Peter Delevett chats with Nick Sturiale, a venture capitalist in Palo Alto who calls buzzwords and bias some of the biggest threats to a startup’s health. He’s also a StrongLoop investor.

Phusion Passenger’s Node.js Support has Been Open Sourced

Phusion Passenger is a fast and robust web server and application server for Ruby, Python and Node.js. Hongli Lai reports that Phusion Passenger’s Node.js support, originally an Enterprise-only feature, is now open source.

Continuous Deployment to Nodejitsu with Codeship

Manuel Weiss and the Codeship proudly announce a new member of their deployment family.

What’s next?

Recipes for LoopBack Models, part 4 of 5: Models by Instance Introspection

Last time, we looked at using LoopBack with relational databases, allowing you to consume existing data. This time around, we are looking at your options when the data does not have a schema.

I have JSON documents from REST services and NoSQL databases. Can LoopBack get my models from them?

Yes, certainly! Here is an example:


Now we understand that we can define the models from scratch, or discover them from relational databases or JSON documents. How can we make sure that the database models are in sync with LoopBack if some of the database models don’t exist or are different? LoopBack has APIs to facilitate the synchronization. We will demonstrate how next time, in the final part of this series.

What’s next?