Amazon Greengrass launches as a snap on Ubuntu

Personal note: Take a look at Ubuntu Core with Qt for Internet of Things development (6/25/2017)

Last week, Amazon launched Greengrass, their new IoT platform allowing developers to create intelligent edge software. Amazon is collaborating with a variety of manufacturers to make Greengrass available on as many devices as possible from home gateways, industrial gateways to smart microphones. This is a reflection of the increased appetite from hardware vendors and developers to bring software definable devices to market, where third party developers can add new functionalities to existing devices and get rewarded for it. By deploying more intelligence at the edge, developers can build devices with more offline functions, faster responses that are cheaper for them to operate and give users an improved experience. By offering software definable devices they also give themselves the opportunity to offer a continuously improving experience but also new paid services that help them monetise their device even after they’ve been purchased.

Image result for ubuntu

AWS Greengrass is a step in this direction and solves one of the major problems associated with the software definable internet of things, namely how to give developers a simple and familiar development experience on edge devices by letting them re-use their backend code. With AWS Greengrass developers can now use the same skills and code they use in the cloud to write Lambda functions of MQTT based rules to write internet of things applications right at the edge of the network.

For device makers, building a software definable device using AWS Greengrass is, therefore, the guarantee of building an attractive option for developers. To facilitate this process Amazon has collaborated to make Greengrass available as a snap – the universal Linux packaging format. Snaps allow software companies like Amazon to distribute their software in immutable packages that will run consistently across hardware independent of the operating system they use and regardless of the state of that OS. This makes it simple for device manufacturers like Advantech to include Amazon Greengrass in their devices and thus propose a certified Greengrass device for developers to use. Combined with Ubuntu Core, the all snap version of Ubuntu for IoT devices, Greengrass as a snap also offers an opportunity for device makers and developers to monetise their software by building an app store for things.

Where is Java used in Real World?

If you are a beginner and just started learning Java, you might be thinking where exactly Java is used? You don’t see many games written in Java except Minecraft, desktop tools like Adobe Acrobat, Microsoft Office are not written in Java, neither is your operating systems like Linux or Windows, so where exactly people use Java? Does it have any real-world application or not? Well, you are not alone, many programmers ask this question before starting with Java, or after picking Java is one of the programming language of choice at graduate level. By the way, you can get a clue of where Java is used by installing Java at your desktop, Oracle says more than 3 billion devices run Java, that’s huge number, isn’t it? Most major companies use Java in one way or other. Many server side applications are written in Java to process tens of millions of requests per day, high frequency trading applications are also written in Java e.g. LMAX trading applications, which is built over their path breaking inter-thread communication library, Disruptor. In this article, we will see more precisely, what kind of projects are done in Java, which domain or sector Java is dominating and where exactly Java is useful in real-world?

Real World Java Applications

There are many places where Java is used in real world, starting from commercial e-commerce website to android apps, from scientific application to financial applications like electronic trading systems, from games like Minecraft to desktop applications like Eclipse, Netbeans and IntelliJ, from open source library to J2ME apps etc. Let’s see each of them in more detail.

1) Android Apps
If you want to see where Java is used, you are not too far away. Open your Android phone and any app, they are actually written in Java programming language, with Google’s Android API, which is similar to JDK. Couple of years back Android has provided much needed boost and today many Java programmer are Android App developer. By the way android uses different JVM and different packaging, but code is still written in Java.

2) Server Apps at Financial Services Industry
Java is very big in Financial Services. Lots of global Investment banks like Goldman Sachs, Citigroup, Barclays, Standard Charted and other banks use Java for writing front and back office electronic trading system, writing settlement and confirmation systems, data processing projects and several others. Java is mostly used to write server side application, mostly without any front end, which receives data form one server (upstream), process it and sends it other process (downstream). Java Swing was also popular for creating thick client GUIs for traders, but now C# is quickly gaining market share on that space and Swing is out of its breath.

3) Java Web applications
Java is also big on E commerce and web application space. You have a lot of  RESTfull services being created using Spring MVC, Struts 2.0 and similar frameworks. Even simple Servlet, JSP and Struts based web applications are quite popular on various government projects. Many of government, healthcare, insurance, education, defense and several other department have their web application built in Java.

Real world application of Java

4) Software Tools
Many useful software and development tools are written and developed in Java e.g. Eclipse, InetelliJ Idea and Netbans IDE. I think they are also most used desktop applications written in Java. Though there was time when Swing was very popular to write thick client, mostly in financial service sector and Investment banks. Now days, Java FX is gaining popularity but still it is not a replacement of Swing and C# has almost replaced Swing in Finance domain.

5) Trading Application
Third party trading application, which is also part of bigger financial services industry, also use Java. Popular trading application like Murex, which is used in many banks for front to bank connectivity, is also written in Java.

6) J2ME Apps
Though advent of iOS and Android almost killed J2ME market, but still there is large market of low end Nokia and Samsung handset which uses J2ME. There was time when almost all games, application, which is available in Android are written using MIDP and CLDC, part of J2ME platform. J2ME is still popular on products like Blu-ray, Cards, Set top boxes etc. One of the reason of WhatsApp being so popular is because it is also available in J2ME for all those Nokia handset which is still quite big.

7) Embedded Space
Java is also big in the embedded space. It shows how capable the platform is, you only need 130 KB to be able to use Java technology (on a smart card or sensor). Originally Java was designed for embedded devices. In fact, this is the one area, which was part of Java’s initial campaign of “write once, run anywhere” and looks like it is paying up now.

8) Big Data technologies
Hadoop and other big data technologies are also using Java in one way or other e.g. Apache’s Java-based HBase and Accumulo (open source), and  ElasticSearch as well. By the Java is not dominating this space, as there are technologies like MongoDB which is written in C++. Java has potential to get major share on this growing space if Hadoop or ElasticSearch goes big.

9) High Frequency Trading Space
Java platform has improved its performance characteristics a lot and with modern JITs, its capable of delivering performance at C++ level. Due to this reason, Java is also popular on writing high performance systems, because Though performance is little less compared to native language, but you can compromise safety, portability and maintainability for more speed and it only takes one inexperienced C++ programmer to make an application slow and unreliable.

10) Scientific Applications
Nowadays Java is often a default choice for scientific applications, including natural language processing. Main reason of this is because Java is more safe, portable, maintainable and comes with better high-level concurrency tools than C++ or any other language.

In 1990s Java was quite big on Internet due to Applet, but over the years, Applet’s lost its popularity, mainly due to various security issues on Applet’s sand boxing model. Today desktop Java and Applets is almost dead. Java is by default Software industries darling application development language, and given its heavy usage in financial services industry, Investment banks and E-commerce web application space, any one learning Java has bright future ahead of him. Java 8 has only reinforced the belief that Java will continuing dominating software development space for years to come.

If you don’t want to check or remember the IP address of Raspberry Pi on LAN

The flexible way: Set up avahi / zeroconf. Zeroconf is ‘a set of techniques that automatically creates a usable Internet Protocol (IP) network without manual operator intervention or special configuration servers.’[3]. Avahi is an implementation of zeroconf which ‘ships with most Linux and *BSD distributions’ [4], but not the Raspberry Pi’s Debian distribution. Zeroconf will be familiar to Apple users as Bonjour and is pretty clever tech which means that things Just Work when sharing stuff across computers on a network. In this context, it means that once we’ve set it up on the Raspberry Pi, we’ll be able to address it as:


regardless of what IP address it’s been assigned on your local network. This is handy if its IP address is likely to change regularly, and even means we’ll continue to be able to address it if we’re on a different network (say, shuffling between home and work networks).
Information in this section largely gathered from 4dc5.

  1. Install avahi with the following commands on the Raspberry Pi:
    sudo apt-get install avahi-daemon

    and then on older Debian installs:

    sudo update-rc.d avahi-daemon defaults

    or on newer Raspbian installs:

    sudo insserv avahi-daemon

    (if in doubt, you’re probably on the newer one).

  2. Create a configfile for Avahi at /etc/avahi/services/multiple.service. I did this with the following command:
    sudo pico /etc/avahi/services/multiple.service

    The contents of this file should be something like the following, courtesy of aXon on the Rasperry Pi forums:

    <?xml version="1.0" standalone='no'?>
    <!DOCTYPE service-group SYSTEM "avahi-service.dtd">
            <name replace-wildcards="yes">%h</name>
  3. Apply the new configuration with:
    sudo /etc/init.d/avahi-daemon restart

    The Raspberry Pi should now be addressable from other machines as raspberrypi.local, for example:

    ssh pi@raspberrypi.local
  4. Get Windows to play nice with avahi
    If you’ve done the first steps correctly and you open up PuTTY and you try to address your Raspberry Pi as raspberrypi.local; it will tell you:
    This happens for a very good reason: your Windows PC can’t interpret the UDP-datagrams avahi sends and most firewalls don’t even allow them to get read. So you’ll have to do a couple of things extra to get it working.

  1. Get Bonjour for Windows Just install it, the quick next next next next procedure will suffice. Now your computer is able to interpret the UDP datagrams which are multicasted by the Raspberry Pi. But we’re not out of the woods just yet; if you try to ping to your Raspberry Pi:

    C:\Windows\System32>ping raspberrypi.local
    Ping-request cannot find host raspberrypi.local.
    Check the name and try again.
  2. Tell your firewall: trust me, I’m an engineer.
    Stereotypically, the firewall forbids us to have some fun. First of all, the 5353 UDP port is blocked on most firewalls, so you have to add an exception for it. Also, you’ll have to grant Internet access to the mDNSresponder.exe. This way, whenever your computer tries to connect with a host *.local, mDNS sends a multicast over the local subnet to ask whether anyone calls himself *.local. If mDNS isn’t granted network access, nothing gets multicasted and nobody answers the phone.
    Note: If you have the McAfee firewall, you’ll also have to enable UDP control. If it isn’t enabled, all UDP datagrams are ignored.
  3. Enjoy the pleasure of typing raspberrypi.local in PuTTY
    After these steps, you should be able to ping to raspberrypi.local and even address it that way in PuTTY. YMMV, if you’re still having troubles at this point, try to ping to raspberrypi.local with the firewall turned off. If it works: hey presto, you’ve got your culprit, and you can start an educated Google search.


How to access Ruby web server such as WEBrick or Puma (Rails framework) from other computers on LAN

Alright, so you are familiar with

rails s -b IP_ADDRESS -p PORT

To run the server on the localhost is simple (The default binding IP is

rails s

To make it accessible from another computer on the LAN, you will need to specify your IP address and the port (normally port 80). If your LAN firework blocks port 80, you will need to specify another port then, such as 3000 or 8080.


Teensy 3.5 & 3.6 – Powerful Microcontrollers For Making Awesome DIY Electronic Projects

Teensy is a microcontroller development board used for building all sorts of awesome DIY electronic projects.

Over the last year I’ve been designing 2 new Teensy models using far more powerful microcontroller chips; a huge step up in capability from prior Teensy and other Arduino compatible boards.  Now, hopefully with your backing, it’s time to move from development & prototype phase to the first production run of these new, much more powerful products.

The scope of this Kickstarter project involves completing a first production run and publishing good Arduino-compatible support software, with these 2 new Teensy boards as the physical rewards shipped to backers.

However, this new hardware is meant to be a stepping stone to open an ambitious new chapter of software design & platform enhancements.  As I’ve done with Teensy for many years, I intend to develop increasingly powerful but easy-to-use software libraries and even improvements to the Arduino platform to enable everyone to more easily create awesome, incredible DIY projects.

A Brief History of Teensy

Teensy has always been about bringing more powerful microcontroller features to the DIY Electronics world, not just hardware, but advanced libraries that allow more powerful features to be used easily from Arduino.

Teensy 1.0 (late-2008) offered 12 Mbps native USB at a time when all Arduino compatible boards used slow serial.  It was the first board Arduino compatible board to feature very fast USB communication.

Teensy 2.0 (2009) added support for USB Keyboard, Mouse & MIDI.  At this time nearly all Arduino libraries were hard-coded for Diecimila/Duemilanove.  In 2010-2011, I added thin abstraction layers to Servo, Firmata, OneWire, IrRemote & many more, as well as fixed many issues and optimized code, which later paved the way for compatibility for later Arduino products (Mega, Leonardo, etc).  Starting from this early period, I contributed many optimizations & improvements back to Arduino, to benefit everyone, not just Teensy users.

Teensy became more widely used from 2011.  So did the early addressable LED strips.  Inspired by a conversation with Phil Burgess, I created code to stream USB packets to LEDs.  This pushed Teensy 2.0 to its technical limits, but several people used it to build some awesome LED projects.


Teensy 3.0 (2012) was the first 32 bit Teensy, launched here on Kickstarter.  While Maple deserves the credit for being the first 32 bit Arduino compatible board, Teensy 3.0 began a major effort to port every widely used Arduino library and begin developing new libraries to truly use the far more capable hardware.

By early 2013, much less expensive addressable LEDs appeared.  Many people were interested in using them for video walls, inspired by those earlier projects.  At first this seemed impossible due to their tight timing requirements.  But using the flexible DMA controller and timers in Teensy 3.0, I created the OctoWS2811 LED library which has been used by many thousands of people to create truly outstanding large LED products.

Small color TFT screens also became inexpensive around this time.  At 320×240 resolution, these update quite slowly using 8 bit microcontrollers.  Running the same code on Teensy 3.0 results in a 3 to 4 times speedup.  But by developing a special optimized library to take advantage of the more sophisticated hardware FIFO and control signal hardware, much better performance was achieved.

Teensy 3.1 & 3.2 (2014) Teensy was updated to a faster chip with 4 times larger RAM.  The increased memory size opened up the possibility of very flexible audio.  I spent nearly 2 years developing the Teensy Audio Library, which is actually a toolkit of dozens of audio processing components.  To help people use it, I created this design tool, borrowing GUI code from the Node-Red project.


With some help from Alysia Dynamik, in late-2015 we created a workshop and tutorial demonstrating many of the audio library features.  This video walkthough can give you a good idea of how I’ve tried to put this 32 bit hardware to use, crafting a library that not only makes audio processing possible, but easy to do from Arduino sketches.

Since this video was made, several more audio features have been added, including quad channel input & output and USB audio streaming, where Teensy appears to your PC as a USB sound card and audio data streams bidirectionally between your PC and the audio library.

Each new generation of more capable Teensy hardware has brought the opportunity to develop these advanced libraries.  Now, hopefully with your backing, it’s time to again step up to more powerful hardware.

Technical Features & Specifications

Features specific to Teensy 3.6:

  • 180 MHz ARM Cortex-M4 with Floating Point Unit
  • 1M Flash, 256K RAM, 4K EEPROM
  • Microcontroller Chip MK66FX1M0VMD18 (PDF link)
  • USB High Speed (480 Mbit/sec) Port
  • 2 CAN Bus Ports
  • 32 General Purpose DMA Channels
  • 11 Touch Sensing Inputs

Features specific to Teensy 3.5:

  • 120 MHz ARM Cortex-M4 with Floating Point Unit
  • 512K Flash, 192K RAM, 4K EEPROM
  • Microcontroller Chip MK64FX512VMD12 (PDF link)
  • 1 CAN Bus Port
  • 16 General Purpose DMA Channels
  • 5 Volt Tolerance On All Digital I/O Pins

Features common to both:

  • 62 I/O Pins (42 breadboard friendly)
  • 25 Analog Inputs to 2 ADCs with 13 bits resolution
  • 2 Analog Outputs (DACs) with 12 bit resolution
  • 20 PWM Outputs
  • USB Full Speed (12 Mbit/sec) Port
  • Ethernet mac, capable of full 100 Mbit/sec speed
  • Native (4 bit SDIO) micro SD card port
  • I2S Audio Port, 4 Channel Digital Audio Input & Output
  • 14 Hardware Timers
  • Cryptographic Acceleration Unit
  • Random Number Generator
  • CRC Computation Unit
  • 6 Serial Ports (2 with FIFO & Fast Baud Rates)
  • 3 SPI Ports (1 with FIFO)
  • 4 I2C Ports
  • Real Time Clock
    The pin assignments have been designed to preserve compatibility with the 28 breadboard-friendly pins of prior Teensy 3.x models.  All 28 of these pins support the same features as the older models.

More I/O pins are available at small surface mount pads on the back side.  The 6th serial port, 4th I2C port and 3rd SPI port are on these pins.  They’re not as easy to access as the main 42 through-hole pins on the outside edge, but for projects where you really need access to a huge number of I/O signals or those extra communication ports, these boards do give you a way to access them (but keep the board to a reasonably small “Teensy” size).

Teensy 3.6 has a second USB port which is capable of 480 Mbit/sec speed.  It’s intended to used in USB host mode, so you can connect USB devices like a keyboard or memory stick.  This USB port is accessed using 5 pins, which are compatible with the commonly available internal PC cables for USB.

The Arduino IDE is the primary method used to program Teensy.  Like prior models, my goal for Teensy is the best possibility compatibility with all Arduino functions and widely used libraries.

Development Timeline

I started planning for a high-end Teensy about 3 years ago.  This paper model was among the very first steps.  This paper model was made before Teensy 3.2 existed (early 2014), when we were still using the Mini54 chip to implement the bootloader. It has sat on the corner of my desk all this time, as a reminder to make a more capable Teensy model.

As you can see, the concept of a 48 pin breadboard friendly form factor with the micro SD socket existed from the very early days.  Originally 10 more through-hole pins were planned between the pushbutton and chip, with 8 of them providing the last Serial, I2C & SPI ports.  You can see these 10 pins on all the later prototype boards, but they were ultimately changed to to bottom-side SMT pads to allow room for the USB host port.

This circuit board is the first prototype which actually worked, made in early 2015.  A few others were made earlier but didn’t work and were never debugged.  As you can see from the white wire, this version also had some mistakes.

NXP/Freescale published datasheets for the MK66 chip in mid-2015 and the chips became available in late-2015, long after this prototype was made with the earlier MK22 chip.

To say this early prototype “worked” may be a bit of an exaggeration.  I had quite a bit of trouble with my code and the newer flash memory controller.  NXP/Freescale calls this controller “FTFE”.  The ones in other Teensy models are “FTFL” and “FTFA”.  Their documentation looks very similar, but subtle differences set my efforts back by many months.  FTFE only supports 64 bit word size.  It also seems to have very strange undocumented behavior in some conditions, which aren’t treated as errors at all by the smaller FTFL & FTFA controllers.

Two more prototype boards (no photos) were made, based on the update from the MK22 chip to MK64 & MK66.  The pin assignments changed somewhat, mostly to allow an Ethernet PHY shield to use the on-chip Ethernet peripheral.  The extra power pins were brought near the center of the board, to see these connections short for a future Ethernet shield, which would require the RMII interface which clocks at 50 MHz.

In May 2016, the last prototype was adapted to make this beta test board.  It has the final pinout with sockets added at the intended form-factor.

In June, we began a beta test period, first sending 10 of these boards to long-established community contributors in mid-June, and another 16 later in July.  As you can read in that incredibly long forum thread, a pretty tremendous amount of beta testing has occurred over the last couple months!

Before finalizing the pinout, I wanted to be absolutely certain we could have a working Ethernet shield.  The RMII signals seemed simple enough, but lingering questions remained about the RMII clock.  So in July I designed this Ethernet shield using the LAN8720A chip.

I was able to write and confirm a simple ping sketch.  Some of the beta testers, especially forum user Manitou, stepped up to do much more testing, including benchmarks that show the hardware really is capable of back-to-back packet processing at 100 Mbit/sec speed!

A pretty incredible amount of testing has been done over these last two months, including impressive benchmarks on the native SD port and some initial results with the 480 Mbit/sec USB port.  Most of the Arduino libraries have been ported or updated.

In July I turned my attention to the PCB layout.  The design uses 6 layers.  Cramming all this into the Teensy form-factor, routing so many signals from the 144 ball BGA using “escape routing” mostly on just 2 sides without any other PCB area for signals to cross back to the other side of the PCB was quite a challenge.  This was by far the most difficult PCB layout I’ve ever done.  After a few solid weeks of work, it was finally all routed, even preserving 2 of the layers for only ground and power planes.

As you can guess by the purple color of my prototypes, I love OSH Park, and I tend to make many iterations as I work on a project.  But they don’t offer a 6 layer service, nor small slots which I wanted to use for a strong USB connector.  It seems nearly all 6 layer prototype services are quite expensive.  We ended up having our normal PCB vendor make the 6 layer prototype in the form of the actual panels we’ll use for production.

All Teensy 3.x boards are assembled in the USA, at a local contract manufacturer that’s only a 15 minute drive away.  Robin and I met with them, and they were eager to do a test run, especially since this our first PCB with this BGA chip and the USB connector using slots.

The boards from this pre-production run work great, I was quite relieved to learn after making this small run of boards using a brand new PCB layout (have I mentioned how much I wish for OSH Park’s awesome service for 6-layer boards).  The final production boards will be identical, with the minor exception of those extra holes in the panel frame were relocated, to better fit special fixture equipment they use with applying the solder paste.

Even though most of the technical work to design this board is completed, much work remains to be done for a final release.  How we will test these is the next major task as we fully test every board before shipping them out.  Much work also remains on documentation everyone needed for a properly supported development board.  I’ll be writing updates.  These high-end components and 6 layer boards also involve quite a financial investment (PJRC is a tiny company, just a few people) which is where the magic of Kickstarter comes in.  We’ll gauge the size of this first production run of boards based on the response here, so I hope you’ll consider backing this project to help us complete the last step of a full production release.

Future Software Development Goals

Teensy has always been about so much more than just its hardware, about bringing more advanced but easy-to-use software libraries to the Maker & DIY hardware communities.  In this last section, I’d like to share some of my ambitions for where this far more powerful hardware can take us.

Kickstarter requires all projects to have clear goals, to be able to define a point where the creator can say “it’s finished”.  For Teensy 3.5 & 3.6, that goal is shipping all the rewards, and a non-beta software release that provides compatibility with all the standard Arduino functions, libraries that come built-in to Arduino, and the 76 of the 77 other commonly used Arduino libraries that ship with Teensyduino 1.29 (one is specific to only 8 bit AVR).  These should not be considered part of completing this project.

  • USB Types for MTP Disk, USB ethernet
  • Audio library, many ambitious ideas: network in/out streaming, real-time pitch shifting (phase vocoder), tempo/beat analysis, granular synthesis & effects, etc
  • LED music visualization (prime use of the floating point unit)
  • SD library to use DMA and pre-fetching, thread/interrupt safe caching
  • Ethernet library, drop-in replacement for Arduino’s Ethernet lib
  • Arduino Event Processing API
  • USB Host Library Exansion & optimization
  • Debug features integrated into the Arduino IDE

While some work has been started on a few of these, most of these are “wish list” ideas.  Much of the best work I’ve done for Teensy over the years, such as the OctoWS2811 library for video-speed control of large LED projects as been inspired by comments.  So please do comment.  It really can lead to great things!

Risks and challenges

Manufacturing of any hardware can involve risk of delays. Vendors may deliver materials late, assembly issues can lead to setbacks, and issues with testing, package and shipping can come up.

PJRC (my small company) has 16 years of experience manufacturing and selling microcontroller development boards, and I personally have 24 years of professional electrical engineering experience. Many people who backed the Teensy 3.0 Kickstarter in 2012 have commented it was one of the few campaigns they’ve ever seen ship on time. We recently completed a tiny preproduction run of beta test boards, which builds a high degree of confidence we will be able to manufacture these boards without significant delays.

I am confident we’ll avoid such issues, based on how well the pre-production run went. It’s a major personal goal of mine to see every single reward shipped on time! But unforeseen issues can always come up. If they do, we certainly do have the resources and experience to quickly deal with setbacks.

The short-term software goals, excellent compatibility with Arduino and widely used Arduino libraries are looking very promising. Beta testing over the last 2 months has already resolved many issues, with nearly all libraries confirmed working. Of course, software is notoriously difficult to ever become absolutely bug free.

Long-term future software development goals, while not technically within the scope of this project’s rewards, are of course important. They’re also very ambitious ideas which may take a very long time, or may change in scope, or may not come to fruition. I do have a good history of developing these sorts of software projects, but no particular grand software idea is ever 100% certain until it’s actually implemented.

Posting Form Data With $http In AngularJS

By default, when you go to post data in an AngularJS application, the data is serialized using JSON (JavaScript Object Notation) and posted to the server with the content-type, “application/json”. But, if you want to post the data as a regular “form post,” you can; all you have to do is override the default request transformation.

When you define an AJAX (Asynchronous JavaScript and XML) request in AngularJS, the $http service allows you to define a transform function for both the outgoing request and the incoming response. These are optional; and, by default, AngularJS provides transform functions that deal with JSON. This is a very flexible format because the post data can have an arbitrarily nested structure; but, it requires additional processing on the server.

If you want to post the data as a regular form post, two things need to happen:

  • The content-type needs to be reported as “application/x-www-form-urlencoded”.
  • The data needs to be serialized using “key=value” pairs (much like a query string).

Both of these requirements can be fulfilled within a request transform function, which has access to the outgoing headers collection and the non-serialized data. The goal of the transform function is to update the headers (as needed) and to return the modified data that will be injected into the underlying XMLHttpRequest object.

I didn’t find a serialization function in AngularJS that was designed for form-posts; so, I copied(ish) the .param() implementation in jQuery. In the following demo, I’m posting the data using this transform function. The server is then dumping out the content of the FORM scope and returning it in the result, which we are rending on the page.

    Posting Form Data With $http In AngularJS

    Posting Form Data With $http In AngularJS

<!-- Initialize scripts. --> <a href="http://../jquery/jquery-2.1.0.min.js">http://../jquery/jquery-2.1.0.min.js</a> <a href="http://../angularjs/angular-1.2.4.min.js">http://../angularjs/angular-1.2.4.min.js</a> // Define the module for our AngularJS application. var app = angular.module( "Demo", [] ); // -------------------------------------------------- // // -------------------------------------------------- // // I control the main demo. app.controller( "DemoController", function( $scope, $http, transformRequestAsFormPost ) { // I hold the data-dump of the FORM scope from the server-side. $scope.cfdump = ""; // By default, the $http service will transform the outgoing request by // serializing the data as JSON and then posting it with the content- // type, "application/json". When we want to post the value as a FORM // post, we need to change the serialization algorithm and post the data // with the content-type, "application/x-www-form-urlencoded". var request = $http({ method: "post", url: "process.cfm", transformRequest: transformRequestAsFormPost, data: { id: 4, name: "Kim", status: "Best Friend" } }); // Store the data-dump of the FORM scope. request.success( function( html ) { $scope.cfdump = html; } ); } ); // -------------------------------------------------- // // -------------------------------------------------- // // I provide a request-transformation method that is used to prepare the outgoing // request as a FORM post instead of a JSON packet. app.factory( "transformRequestAsFormPost", function() { // I prepare the request data for the form post. function transformRequest( data, getHeaders ) { var headers = getHeaders(); headers[ "Content-type" ] = "application/x-www-form-urlencoded; charset=utf-8"; return( serializeData( data ) ); } // Return the factory value. return( transformRequest ); // --- // PRVIATE METHODS. // --- // I serialize the given Object into a key-value pair string. This // method expects an object and will default to the toString() method. // -- // NOTE: This is an atered version of the jQuery.param() method which // will serialize a data collection for Form posting. // -- // function serializeData( data ) { // If this is not an object, defer to native stringification. if ( ! angular.isObject( data ) ) { return( ( data == null ) ? "" : data.toString() ); } var buffer = []; // Serialize each key in the object. for ( var name in data ) { if ( ! data.hasOwnProperty( name ) ) { continue; } var value = data[ name ]; buffer.push( encodeURIComponent( name ) + "=" + encodeURIComponent( ( value == null ) ? "" : value ) ); } // Serialize the buffer and clean it up for transportation. var source = buffer .join( "&amp;" ) .replace( /%20/g, "+" ) ; return( source ); } } ); // -------------------------------------------------- // // -------------------------------------------------- // // I override the "expected" $sanitize service to simply allow the HTML to be // output for the current demo. // -- // NOTE: Do not use this version in production!! This is for development only. app.value( "$sanitize", function( html ) { return( html ); } );

Notice that the call to the $http service is basically unchanged. The only difference, from a normal post, is that we are explicitly passing-in the “transformRequestAsFormPost” function as the “transformRequest” configuration option.

When we run the above code, we get the following page output:


As you can see, the outgoing request data was serialized for consumption as a regular form post.

NOTE: This does not use the “multipart/form-data” content type, which is primarily used for form posts that include binary file uploads.

In general, I like posting data as JSON. But, it does require some preprocessing on the server. Sometimes, it’s nice to just to deal with normal form data that the server can consume automatically. It’s nice that AngularJS is flexible enough to use both formats.

Angular $http POST request with request payload or form data

If you have RESTful API’s on your server side and are trying to use Angular’s $http service to consume the resource, you should be careful about how the request (for example, Http POST) is made, in particular how the data (perhaps in the format of form) is included in the request. As a JSON object or URL parameters? There is a difference between request payload and form data. The key word is “form data“.

Depending on how you design your RESTful API, if you probably read the data (http POST) from url params, you will need to transform your data from object not to JSON string, but to url params.

The Request Payload – or to be more precise: payload body of a HTTP Request – is the data normally send by a POST or PUT Request. It’s the part after the headers and the CRLF of a HTTP Request.

A request with Content-Type: application/json may look like this:

POST /some-path HTTP/1.1
Content-Type: application/json

{ "foo" : "bar", "name" : "John" }

If you submit this per AJAX the browser simply shows you what it is submitting as payload body. That’s all it can do because it has no idea where the data is coming from.

If you submit a HTML-Form with method="POST" and Content-Type: application/x-www-form-urlencoded or Content-Type: multipart/form-data your request may look like this:

POST /some-path HTTP/1.1
Content-Type: application/x-www-form-urlencoded


In this case the form-data is the request payload. Here the Browser knows more: it knows that bar is the value of the input-field foo of the submitted form. And that’s what it is showing to you.

So, they differ in the Content-Type but not in the way data is submitted. In both cases the data is in the message-body. And Chrome distinguishes how the data is presented to you in the Developer Tools.

By default, the $http service will transform the outgoing request by serializing the data as JSON and then posting it with the content- type, “application/json”. When we want to post the value as a FORM post, we need to change the serialization algorithm and post the data with the content-type, “application/x-www-form-urlencoded”.

    method: 'POST',
    url: url,
    headers: {'Content-Type': 'application/x-www-form-urlencoded'},
    transformRequest: function(obj) {
        var str = [];
        for(var p in obj)
        str.push(encodeURIComponent(p) + "=" + encodeURIComponent(obj[p]));
        return str.join("&");
    data: {username: $scope.userName, password: $scope.password}
}).success(function () {});

There is a good post on this

One quick personal note: you don’t need to write the format conversion yourself, JQuery has one for you already.

For example:

var params = { width:1680, height:1050 };
var str = jQuery.param( params );

str now contains width=1680&height=1050