Learning with teams

Editor’s note: This is a cross-post from Udacity‘s Dhruv Parthasarathy. Dhruv shares how, with the collaboration with Layer, they were able to successfully implement their classroom chatroom feature, Teams.

Despite all the advancements made to date, online education still has one glaring shortcoming — it is lonely. Learning online today is largely done on your own, at your computer, cut off from those around you. In essence, we’ve lost the human element of education that brings so much joy and richness to the experience. Here at Udacity, our goal is to create an educational experience that is better than any other, online or offline, and so long as our experience lacks this human element, we know we will continue to fall short of our goal.

Seeing this, we’ve been focused on bringing real, human relationships to the core of our product. The manifestation of these efforts is Teams: a new experience in Udacity where you join 10 other fellow students from around the world in a small, tight-knit community focused on learning. Students on teams answer each others questions, collaborate on projects, and help each other achieve their goals. Beyond that, they also get to participate in a real community with students who share similar career and learning goals. In order to create such a community, we knew that we would need to provide a simple way for teams to communicate with one another as without communication, there can’t be community! As such, at the very core of Teams are Rooms — persistent, Slack-like, chat rooms where students can communicate with one another. The first iteration of Teams and Rooms shipped in June 2015, a through the rest of this post, we’ll explore the engineering and product decisions we made in creating this product and how we’ve seen it improve the learning experience for students.

Teams — A Technical Perspective

One of the key elements of Teams is the web client where students log in to chat with one another. You can see what it looks like below.

In developing the web client for Team Rooms, we had a few specific engineering goals:

  1. The application had to be reactive. The view had to be able to update itself without a refresh in response to new events that occurred during the session (new messages, changes in status, new members joining etc).
  2. The application had to be simple to work on and extend as there would only be one to two engineers working on it (both frontend and backend).

Regarding our first goal, current practices in an MVC frontend (we use AngularJS), make creating a reactive application difficult. Let’s take a look at why this is the case. In a reactive application, controllers need to have a way of discovering when the model changes so that they can update the view. In the current paradigm, you have two main ways of achieving this:

1. Eventing + Callbacks

The first way you could approach this is by using a combination of eventing and callbacks to send out an event to controllers whenever you update the model and have the controllers run some callback in response. In practice, this is difficult to implement. A fine-grained eventing system requires a different event type for every property. Assuming you remember to emit those events on every change, the number of listeners also increases dramatically. In essence, the number of events and the number of listeners scales linearly with the number of model properties.

2. Watching Models

Alternatively, you could instead have your controllers check your model directly for changes by diffing the new from the old. But in practice, looking through a large nested object for changes is extremely slow and as more controllers attempt to do it, performance degrades significantly. If you have an object with let’s say a constant branching factor of m at each depth, and a depth of n, you will be watching m^n different properties which quickly becomes infeasible.

Our Solution: Store models in Immutable datastructures

Unsatisfied with the options we saw, we looked to solve this in a different way. Our goal was to create a system where controllers would just be able to say “I care about this part of the model only!”, and the model would update the controllers when it changed in a simple, performant manner.

Of course, checking if a standard Javascript object has changed is extremely expensive. But what if the object were immutable? Then, whenever the object changed, it would be trivial to know: you just see if oldObject === newObject and you’re done! In seeing this, we decided to store our state in an Immutable object, and we did so by using Facebook’s wonderful Immutable.js library. Now, we had a simple way of checking when the model changed — we just check the reference to the underlying immutable object! We then needed a way to communicate updates between the model and the controllers. Instead of using an eventing system, we chose to use Netflix’s ReactiveX library for javascript (RxJS). With Rxjs, we treat our model as a stream of states rather than a single, unchanging, state. Whenever we update the chat state model, we added a new value on a stream.
To understand this better, let’s walk through how a controller might subscribe to model changes. Let’s say we’re interested in showing a list of users in the chat room and want that list to update whenever the list of users changes. Let’s also say our users model has the following schema:

       userId: //user object,

Here’s how the controller would do it:

  1. Get a stream of updates to the users model.
  2. // create a stream of user updates
    var userMaterializedView = chatState.createMaterializedView( // this is the main stream of updates the chat state chatState.chatStateUpdateObservable, // this is a function that returns the part of the chat state we care about function (newDB) { return chatState.getUsers(newDB); }
  3. Subscribe to the stream and update the view whenever a new value comes on the stream.
  4. userMaterializedView.subscribe(function (users) { $scope.users = users;

The diagram below visualizes what’s going on behind the scenes to help us create this stream.

The bottom stream of triangles, the ones that are all different from one another, is what the controller in this case gets. In this way, we created a simple API that allowed controllers to subscribe to updates on any transformation of the model they cared about.

The Backend: Powered By Layer

With a small team, we had the luxury to create this architecture on the frontend partly because we didn’t have to worry about the backend — Layer took care of most of that for us. As someone who’s configured and deployed a chat server from scratch before, using Ejabberd (an open source XMPP server), I can confidently say this saved us a lot of time. Managing an Ejabberd deployment on your own is challenging,and clustering the setup is quite difficult due to fairly opaque documentation that hasn’t been updated for a while. Additionally, Ejabberd isn’t particularly user friendly from a client perspective either. Being an XMPP server, it communicates over XML instead of JSON that your client can actually use. Moreover, it doesn’t support Websockets out of the box and you have to instead use the fairly ancient HTTP BOSH technology. As such, standard XMPP servers were not at all a great fit for our use case and came in the way of development.
On the other hand, Layer was a comparative joy. Layer gave us access to a simple Websocket API with extremely well documented json packets. This made communicating with the server very simple (see the documentation here). We didn’t have to worry about deployment, maintenance, or translating packets into something meaningful. What I personally loved most about Layer was that it was clearly designed to get development out of the way and allow you to focus on what’s most important — creating a wonderful experience for the user. My sentiments were shared by my colleagues working on the mobile clients — we were able to create a prototype android and iOS client in a matter of a weeks. I can’t think of another simple setup that would have provided us this kind of productivity. As a result, we were able to focus on our product and continuously iterate the user experience instead of debugging the server.

Improvements Since Launch

Since the basic product launched on July 6th, we’ve been able to improve it at a strong pace thanks to the productivity afforded us by Layer. Here are just a few of the enhancements we’ve made since launching less than two months ago.

Integration with Google Hangouts

While chat is good for communicating asynchronously, we found that nothing beats a live video chat for a realtime meeting. As such, we added in simple support for Google Hangouts which also gives our students the ability to screenshare with each other.

Udacity Guides

One of the most exciting things at Udacity is the growing community of intelligent, passionate alumni we have. We wanted to leverage this alumni network to help current students succeed even further. So we created the concept of guides — paid Udacity alumni who help teams learn, collaborate, and succeed.

We’ve been able to focus on improving the product in these ways largely thanks to the fact that we only had to worry about the client — Layer took care of the rest for us.

The Impact

As a result of this focus, we’ve seen metrics that lead us to believe that Teams are helping our students succeed in meaningful ways. For instance, the percent of students who submitted their first project, one of the key metrics of student engagement, increased by 25% — something we’ve never seen before. Not only this, we’ve seen groups connect, get to know one another, and create real bonds learning online. Layer’s tools and support have been an integral part of making this product happen and we are thrilled with our experience working with them. We are excited by the architecture we have put in place to create a truly reactive application for our students and know that the productivity afforded us by Layer was a key part in making this happen. We’ve still got a long way to go with Teams, but we’re confident that it can help us bring human connection to the forefront of online education.

Introducing the Layer Client API

Today we’re happy to announce the public availability of our new Client API—a REST and WebSocket API that lets anyone build browser-based messaging applications for web and desktop.

Its release comes at the end of several months of beta testing. Three hundred developers took part in our early access program, and a number of companies have already released applications that use the new API, most notably Udacity, who saw a 25% boost in goal achievement when they added group chat to their mobile and web applications.

Our Client API is available today, and documentation can be found here:

What is the Client API?

The Layer Client API is a set of APIs for building messaging clients on any web-enabled platform, including browsers and desktop applications. It bundles together a REST API for authentication and interacting with Conversations and Messages, and a bidirectional WebSocket API for real-time updates. These APIs serve as the underpinnings of the forthcoming JavaScript SDK.

What can be built with it?

The most straightforward use for our Client API is to create a complementary browser-based version of your mobile app, offering the same functionality but on a different platform (mirroring the experiences your users may have had with web versions of WhatsApp, Telegram, or Facebook Messenger). Some applications package this as a native desktop app wrapped around a web view.

Alternatively businesses may require a two-sided, asymmetrical application, where different users have different application experiences. Examples of these asymmetrical interfaces include:

  • Logistics — a dispatcher is given a large administrative dashboard, while mobile users (drivers and riders) have application experiences that are specific to their needs
  • Customer support — one agent has dozens of tickets, but a user may only have one support ticket
  • Concierge shopping — a personal shopper is paired with several individual users, who each have only one shopper
  • Coaching — connecting personal trainers to clients, where trainers have different options from clients

Layer for Web: Client API, SDK, UI Kit

Today’s release of our Client API is the first step towards what will eventually become Layer for Web—a complete toolkit for building messaging applications on the web. Steps two and three, a JavaScript SDK and accompanying Web UI Kit, will be open sourced and released in the same fashion as the Client API; a small early access program followed by a public beta.

If you’d like to help test our JavaScript SDK in the coming weeks, please fill out this quick 2 minute form, and let us know your plans for developing with it.

As for the Client API, we can’t wait to see what you build with it.

Announcing webhooks early access

At Layer, we are on a mission to make communications better in all the products people love and use daily. The platform we offer enables developers to create compelling user-to-user and application-to-user rich messaging experiences.

Our philosophy is to launch new products gradually, in tight collaboration with the active community of Layer developers. This lets us build scalable, secure, reliable infrastructure, while incorporating direct feedback from the community. Our iOS and Android SDKs, UI Kits, Platform API, and Client API (get early access) have all benefitted this approach.

Following this process, we are now opening the Layer webhook service for early access.

What are webhooks?

While the Layer Platform API is used to input data into conversations, webhooks serve as an output. As a developer, you define which events you want to be notified of and Layer will trigger a request to a URL you define, along with a JSON payload containing additional event information.

What can webhooks be used for?

Webhooks can be used to monitor events in conversations, process them, and act accordingly.

Example use cases:

  • interoperability with legacy messaging systems
  • interoperability with external systems like SMS or e-mail
  • monitoring messages for keywords and commands (e.g. /help)
  • monitoring of messages for specific content filtering (e.g. profanity)
  • monitoring activity (such as new participant added), to trigger alerts or automated messages (e.g. “Welcome to the conversation Jane…”)
  • integration with machine learning and text processing services

When combined with the Layer Platform API, integrations like external services and AI bots become possible. This enables:

  • conversational onboarding (a bot that gets to know you)
  • automated responses from in-app customer support
  • hyperlink expansion and embedded content cards with images and metadata
  • text-based reminders of upcoming calendar appointments
  • hailing a car service from an in-app message

Apply for early access

If you’d like to start developing with Layer webhooks, or if you want to offer a service to Layer developers, please fill out this short form. We expect to release webhooks in general availability later this fall.

Introducing the Layer Platform API: build rich application-to-user messaging

Every app is a communications app. Whether it’s connecting two people in a marketplace, an on-demand service, a shared interest community, or a dating app, user-to-user communications is an integral layer of functionality. Layer already provides this with client-side SDKs for mobile and web.

But sometimes as a developer, you need special control over the communications within an app. There comes a time when you need to add participants to a conversation (customer support), create a conversation on behalf of two users who do not know each other (dating app), or act in an administrative function to block certain users (shared interest community). You and your application need to be in control. That’s where the Platform API comes in. It unlocks all of the functionality you would expect to enable control from your backend application, and adds support for your backend to send application-to-user messages. This opens up entirely new possibilities to broadcast updates to your users and enables service integrations, injecting content feeds, or offering rich in-line content.

Announcements: a new way to notify your users


Fig 1. Surge pricing.

Application-to-user messaging comes in two flavors. The first is akin to a targeted notification. You may want to broadcast an update about surge pricing to select users in a geographic area, let someone know that they have a new follower, or that there’s a new deal based on their shopping preferences. You could use SMS for this, but you’d need the user’s phone number, the communication appears to the user to come from an anonymous source, and lands among the noise of a user’s already-busy text message inbox. Push notifications are better, but they are best-effort delivery and you don’t get in-depth analytics on receipt or open rate. With Announcements, you can send a persistent message to users that can be optionally accompanied by a push notification. It can also be silently synchronized among the user’s devices, to power an activity feed for example.

There are major benefits to message persistence, searchability, and receipt analytics. Announcements will work even when users have disabled notifications, or if they have uninstalled the app. You can tell what the exact delivery status is (e.g. sent, delivered, read), and which people have read the message. When your users log back in, you can display a stream of updates, or let them know how many activity items they missed since their last visit.

These capabilities provide you complete control to create the exact experience you want for your users. Bring the conversation into your app and re-engage your users with Announcements in ways that SMS or plain push notifications just can’t provide.

Send system messages into conversations


Fig 2. Score update in group chat.

The second form of application-to-user messaging is a scenario many of us are familiar with: integrated services that interact right in the flow of conversation. Anyone who uses Slack or HipChat has probably set up a number of 3rd party integrations with services such as Twitter, Github, or Trello. When changes occur in these services, they broadcast updates directly into the appropriate channels in your messaging interface. With System Messages, anyone is able to build this rich functionality. Your backend application can relay 3rd party service updates, usually from a third-party Webhook, directly into the relevant conversational UI of your users.

For logistics and on-demand applications, where there are many different parties involved and frequent status updates about an order, all of the application-originated messages can be injected into a single in-app conversation across mobile devices and browsers. When the user has been matched with a shopper, or they need to change an order, or the order is out for delivery, all of this can be tracked in a single message thread. Accompany it with optional push notifications to keep everyone informed about the updates of the progress of the transaction. This means maps, order cards, chat, questions, and receipts can all be integrated together, and accompanied by notifications. All of the conversation flowing through the app also removes privacy concerns around personal identity and phone numbers. SMS quickly becomes second class to a consolidated, media-rich, in-app conversation.

This context is ultimately what makes a communications experience rich. Imagine a set of basketball fans discussing the NBA finals. One person in the chat may be watching at home with friends, another at the bar, and yet another is on the subway without access to a video stream. The three of them may already have a group chat going as their play-by-play commentary about what’s happening. However this conversation is missing one key thing: shared context. Now with System Messages, the basketball application can inject the score updates and notable events directly into the stream of conversation. For the member on the subway, she now has access to what’s going on without having to follow multiple sources of information at once; it’s all there in the conversation. The content and communications are integrated into a single place, and the experience for each person is made all the more relevant.

Create and edit conversations from your backend


Fig 3. Start a new chat between matched users.

Let’s say you’re building a dating app, and a match was just made between two of your users. These two don’t know each other, and need to be connected in a conversation so the magic can happen. Using the Platform API, your backend application can create a conversation and invite the two of them to join. This allows you to set your own metadata on the conversation, and determine when to begin the conversation (e.g. optional time delay). On top of all this, with a System Message you could include an ice breaker question or prompt into the newly created conversation to trigger immediate engagement. In the future, this will also allow you to delete the conversation (e.g. a 24 hour window of opportunity). Application-controlled conversation creation also allows you to build invite mechanisms, automatic removal of inactive users, or automatically adding new users to a conversation upon sign-up.

Your backend is in control of Layer


Fig 4. Block users based on community feedback.

The last important piece of functionality the Platform API opens up is control over your application, and eventually your Layer account, via REST. A common implementation of this might involve allowing users to flag each other as inappropriate, and when enough flags are accumulated on a user, to invoke a block policy on Layer. We’re expanding this area over the coming weeks and months to provide more granular control over your applications, and eventually over administrative function of your Layer account.

What’s next

At Layer, our aim is to provide easy-to-use, flexible, powerful APIs and SDKs for developers to build rich communications experiences. This means exposing controls where needed, and simplifying complexity where possible. We view the Platform API as a whole product, one that gives you more leverage and control over your application and the communication experiences within. We’ll be releasing administrative controls over your Layer account, enhanced control over user and notification policies, insights into all of your messaging activity, and all of the functions you are currently able to perform at a user-level.


What we learned building a Layer messaging app for Apple Watch

Push notifications are at the core of the Layer messaging service. Where some platforms provide push as a complementary offering, push is a fundamental pillar of our system. Every message that’s delivered to a device via Layer is optionally accompanied by a push notification, and this works across platforms and devices. Our fondness for the notification interface is one of the many reasons we’re so bullish on wearable devices and the possibilities they open up for application developers.

As we’ve written in the past, the Apple Watch provides a simple, convenient and discreet medium for delivering notifications. At Layer, our mission is to help developers build the very best messaging experiences, and we believe those experiences will undoubtedly involve Apple Watch applications. To learn more about what it’s like to build for this new medium, we started with a fully working iOS app and set out to make it work on the Apple Watch. Here’s what we learned.


This was the first time our iOS team had the opportunity to develop for Apple Watch, and we naturally experienced a small learning curve while getting started with the new platform. Here are a few areas that stood out.

Running and debugging

When developing for a new technology platform it can take a bit of time to become familiar with the tooling and workflow. Working with the WatchKitsimulator was no exception and produced a few unexpected surprises.

  1. Displaying the Apple Watch Simulator – We expected to have the Watch simulator pop up when running our app extension target for the first time. As we quickly found out, a bit of setup was required to enable this behavior.
    1. Navigate to Hardware > External Displays.
    2. Select either the 38mm or 42mm simulator.
  2. Debugging extension and app simultaneously – App extensions can make calls to their parent application via the openParentApplication:reply: API. This method calls the app delegate’s application:handleWatchKitExtensionRequest:reply: method. We expected to be able to add a breakpoint into our implementation of this method while running the extension in the simulator, but the break point was simply not tripped. In order to debug applications on the iPhone and Watch simulators simultaneously, perform the following:
    1. Launch the WatchKit app target in the simulator.
    2. Open on the corresponding parent application in the iPhone simulator.
    3. In Xcode, navigate to Debug > Attach to Process and select your iPhone application’s process.


Cocoa developers who have distributed iOS applications have undoubtedly run into issues that can arise from Provisioning Profiles and Signing Certificates. We weren’t surprised to encounter these issues when attempting to build our WatchKit app on an actual device for the first time.

The WatchKit Extension and Notification target both require their own unique Provisioning Profiles that must match their Bundle Identifiers. These will need to be generated in the Apple developer portal before building for an actual device.


We’re admittedly not the biggest Storyboard fans at Layer (and while the reasons for this are numerous, they’re probably best discussed in another blog post). Needless to say, we were somewhat disappointed to learn that Storyboards are mandatory for Apple Watch Apps and that layout shouldn’t be performed programmatically. This is a bit of a departure from the development philosophy of Atlas for iOS, where we try to perform as much layout as possible in code.

Push in the simulator

Lastly, one very pleasant surprise we encountered was the ability to simulate the delivery of a push notification to Apple Watch. Developers can define a push notification JSON payload in a .apns file and have it “Delivered” to the WatchKitNotification target. This provides very efficient notification debugging, especially when implementing push notification actions for the extension. Our hope is that Apple extends this functionality to the parent application targets in the near future!

The future with watchOS 2

We were excited to see Apple’s announcement yesterday of native application development for Apple Watch, and the new features in WatchKit. Apple made a number of improvements that benefit messaging applications, especially with regard to interactive notifications and new APIs for Siri and the microphone. We’re looking at experimenting with the following functionality in LayerKit and Atlas:

  • Reply directly from a Notification on Apple Watch using voice or text, not just from the Watch Extension.
  • Use Siri in the Layer-powered Watch app to reply directly to messages.
  • Reply to a message using the microphone to send an audio message.
  • View videos and GIF within message cells, adding to the current photo and map functionality.
  • Display the last message or message count as a Complication, with new high-priority push, to keep a running history of replies on Apple Watch.
  • Use custom Taptic vibrations depending on the sender of the message, or differentiated by 1:1 or group conversations.

We can’t wait to see what you’ll build for Apple Watch with Layer and Atlas. If you’re interested in getting early access, don’t hesitate to get in touch!

Helpful links

  1. WatchKit Programming Guide
  2. App Extension Programming Guide
  3. LayerKit
  4. Atlas

Building blocks for logistics: maps and notifications

Editor’s note: This is a cross-post from Mapbox‘s Peter Liu. It’s a sneak peek of a larger collaboration between Mapbox, the building block for maps, and Layer, the building block for communications. More to come!

Technology is reinventing on-demand services to include everything from shipping to laundry, and the central innovation is realtime logistics. Delivery-on-demand services like Postmates or Shyp work at the intersection of location, time, and economics. Assigning the right jobs to the right people – within seconds – is the challenge.

The dispatcher of the future is a stack built with Layer for communications and Mapbox for geo. Customers request a delivery at an address, which Mapbox’s geocoding API transforms into a latitude, longitude point. Turf.js assigns the nearest and oldest outstanding order to each available courier, sending them an instant push notification with Layer. When the courier accepts a task, Smart Directions generates a route specifically for their mode of transportation.

This is a full-featured logistical system in the browser (check out a preview).

  • Layer: realtime messaging layer that connects couriers to assignments.
  • Geocoding: converts addresses into geographical locations.
  • Turf: geospatial analysis fast enough to provide understanding of spatial relationships on the fly, as the foundation for more complex scheduling algorithms.
  • Smart Directions: instant routing from couriers to drop points.

Layer connects people with push notifications, text messages, and alerts – getting customers, couriers, and dispatchers on the same page, in realtime. Mapbox’s geographic technology provides analysis, visualization, and data. Mapbox and Layer are building modular components and APIs for developers, and it’s exciting to see that they can be assembled into real-world applications.

1 – Customer places order

Customer shares their location with the courier.

2 – Courier receives notice of new order

The customer’s location is visible on courier’s device.

3 – Courier plans route and begins trip

Given their two locations, courier is guided to the customer’s location.

4 – Customer is updated of courier’s progress

Trip updates can be sent automatically, so couriers can focus on getting to the destination.

5 – Customer is notified that their order has arrived

With Mapbox and Layer, we can build a great customer experience for any application. Real-time push notifications let customers and couriers stay on the same page without having to actually jump on a call.

The art of powering the Internet’s next messaging system

Last week hundreds of developers gathered in downtown San Francisco to attend Erlang Factory SF Bay, a two day tech conference focused on the Erlang programming language. The conference “brings together the rapidly growing community that uses Erlang in order to showcase the language and its various application to today’s distributed environments.”

Joining them were two of Layer’s senior software engineers, Juan Puig Martinez and Mubarak Seyed. Juan and Mubarak have designed and built much of Layer’s back-end messaging systems. Prior to joining Layer Juan built Erlang/OTP based solutions for Erlang Solutions and Linden Lab. Mubarak specialized in distributed systems (most recently at Apple where he built the Siri platform, and is a committer to Apache Flume).

Building Large Scale Messaging Systems

A question we sometimes get from developers is: What’s so hard about building communications? We usually respond:

In the talk below Juan and Mubarak share some insights into why we chose to power our backend with Erlang and the key components of our backend architecture. They also talk about some of the challenges we faced to maintain performance, how we addressed them, and of course, lessons learned.

Embedded iFrame

Building a powerful communications platform is hard – but for most developers, it doesn’t have to be. Layer provides a full-stack communications building block for developers, including UI components with Atlas.

We can’t wait to see what you build!

Kicking off monthly #OpenLayerHQ developer office hours

Since we opened up the Layer platform and announced Atlas, our customizable UI toolkit, for general availability at the end of February, we’ve been amazed at the variety of applications and experiences that developers are building on Layer. From connecting communities around common interests like sports or career development, to shareable to-do lists, the possibilities are endless.

To that end, we’d love to meet more of the developers that are working with Layer, and see if we can help you create the right messaging and chat experiences in your apps. We’d also love to accelerate your integrations, troubleshoot any issues, and just learn more about what you are doing!

Join us for #OpenLayerHQ office hours next Thursday, April 16th, from 4-7pm at our office in the Mission. We’ll have the Layer engineers behind Atlas and our entire developer support team around to answer questions and work side-by-side with you on integrations. Our designers will also be on hand if you’re looking for feedback on the right UI/UX around messaging. And of course we’ll also have drinks, snacks and Layer swag for anyone that comes in. Give us a heads up by tweeting us @layer or emailing us at hello@layer.com if you plan to stop by. We look forward to meeting you soon!

When: 4-7pm, April 16th
Layer HQ: 470 Alabama Street

Abir Majumdar & Neil Mehta
Partner Engineers

Getting started with Layer and Parse

Layer is a complete building block for communications. Parse is a great backend-as-a-service solution. A good portion of the developers building with Layer also use Parse. We want to make it even easier to get started when using the services jointly.

The Layer Parse iOS Example lets app creators more efficiently create a fully-featured messaging app that’s based on Layer and Parse.

Parse Users and ParseUI

As the building block for messaging, Layer requires usage with a developer’s own identity manager. Parse has a built-in notion of User identity, with convenient sign up and login methods to register a User into its data model.

Combining ParseUI with Atlas leverages the UI components of Parse and Layer respectively to simplify the development process and help developers focus on what truly matters: their core application experience.

Layer Parse iOS Example

The Layer Parse iOS Example is a fully-featured messaging application including a signup and login flow, a list of conversations and a conversation view with support for rich-messages with text, photos, GIFs and more. Additionally, the example takes advantage of standard Atlas and Layer features like support for groups, typing indicators, delivery and read receipts.

Layer Parse iOS Example is available on GitHub, fully open sourced. For more information on integrating Parse, Layer and Atlas into your project, follow our guide.

We would love to help you get started and hear your feedback. Send any questions or suggestions to support@layer.com.

We can’t wait to see what you build!

Special thanks to Abir Majumdar for his contributions to this project and post.

Introducing Atlas: Open Source Messaging UI Components for Layer

Let’s face it: modern application development is hard. Savvy consumers demand the world from developers: applications that are elegantly designed, buttery smooth, and well integrated with the services and content they love. At Layer, we believe the future is a world of more intimate, connected, digital experiences where applications are woven together with the most human of fabrics: communication.

When an app is empowered with communications it becomes immediately more useful, personal, and engaging. But these benefits come with a steep price tag.

Developers are asked to take on a whole new set of problems around real-time communications. At the same time, advanced consumer messaging applications such as iMessage, Facebook Messenger, and WhatsApp have raised the bar on what can be considered table stakes functionality. Consumers demand not just fast and reliable messaging, but features such as delivery & read receipts, the transmission of photo and video content, and robust offline experiences.

Over the last year thousands of developers have worked with the Layer platform and integrated our native SDKs into their applications, gaining access to simple, elegant APIs that provide world-class messaging primitives with all of the features their users expect and demand. With Layer integrated, developers were freed from the minutiae of networking, persistence, security, and state management and could focus on the core value of their user experience.

But then something funny, and in retrospect, not all that surpising started happening: Developers began pinging us to see if we had any UI code laying around that they could use to bootstrap their integration and accelerate their time to market. For quite awhile we had envisioned creating a set of UI components to complement our SDKs and the iOS and Android teams were already maintaining sample applications for internal dog-fooding. Why not prioritize, polish, and Open Source this work so that all our developers can benefit?

Six months and nearly 3000 Git commits later we are ready to unveil the fruits of this labor and proudly introduce Atlas, a set of native user interface components for Layer-enabled applications.

Atlas is a powerful new tool in the app developer’s kit, extending the leverage offered by Layer beyond infrastructure and core messaging services up through the UI, enabling developers to rapidly add rich messaging to new or existing applications.

Prior to Layer, developers were required to make significant up-front investments in infrastructure, application architecture, and networking to add communications to their apps. With Layer, the infrastructure and architectural requirements are minimized, shifting the development focus to the user interface. Here developers encounter a set of second order bootstrapping problems: an initial user interface must be designed, developed, and integrated with the underlying messaging functionality before the real work of product iteration can begin.

Atlas closes this gap by providing developers with ready made UI components that are well engineered and tightly integrated with the underlying messaging capabilities provided by the Layer SDK’s, enabling product teams to access the collaborative, iterative phase of development in hours rather than days or weeks.

Layer + Atlas Development Cycle

Introducing Atlas

Atlas is a library of user interface components that provide familiar messaging experiences on top of LayerKit, the iOS SDK for Layer. Atlas is composed of a number of fully-integrated user interface experiences as well as the individual views from which the components are constructed. Since the entire communications stack and UI components were built by Layer, these components are are fully functional out of the box and provide an Apple-esque developer experience.

Although this is an initial release, Atlas is packed full of features including:

  • A searchable, selectable address input bar like found in the most popular messaging apps.
  • A Conversation List that displays all the Conversations in which the user is participating. Changes in the latest message or the unread state of the Conversation are automatically updated in the UI.
  • A scrollable, auto-paginating message display experience that manages unread state, optionally displays delivery & read receipts, and overlays a typing indicator as others are typing.
  • A flexible, auto-sizing message input bar that handles text, images, and location updates.
  • A detail view for managing conversations by adding, removing, or blocking participants and deleting or resigning from a conversation.
  • A library of accessory views such as incoming and outgoing bubble cells and a dynamically rendered placeholder image that displays user initials.

Atlas is available immediately as source code from Github or you can experience Atlas now by creating your own Atlas enabled app via Layer.

API Design & Customization

In designing the Atlas API, we focused on achieving three primary objectives:

  1. Provide good looking, high quality implementations of familiar messaging experiences out of the box. By default Atlas is styled to look much like iMessage, the most familiar messaging experience to iOS users.
  2. Enable quick and easy branding of the user experience via integration with UIAppearance and Interface Builder. All fonts, colors, etc. can be customized via an extensive set of UIAppearance selectors. This enables developers to quickly add messaging to an existing application and match the components with the existing style.
  3. Support full customization of the user interface by enabling developers to plug in their own views in any of the experiences. Developers should be able to implement any design while continuing to leverage the scaffolding that is driving the messaging UIs.

Atlas is designed to be both very easy to get started using and scale with the demands of your application as you work to implement your design. If you choose to do so you can register custom cells and views for all of the visual elements, while continuing to leverage the Atlas scaffolding to retrieve and vend appropriate messaging objects to the user interface for rendering.

Getting Started

Atlas provides a whole new level of engineering leverage to developers and we can’t wait to get it into your hands. To make it easier to see Layer and Atlas in action, we are also releasing a fully featured Atlas example application on Github and have created the Experience Atlas Now flow to streamline build and configuration.

Concurrent with the release of Atlas we are pleased to announce that Layer is now generally available and ready to power native communications in your app.

We are eternally thankful to the apps and passionate developers who participated in our early access program, which officially wraps today as we open up the Layer platform. Many of these apps are live in production, today providing excellent communications experiences to their users around the world.

You can get started with Atlas and Layer immediately by visiting the Experience Atlas Now page. And if you’re local to San Francisco, join us for a Meetup at Layer this Monday, March 2 to learn more.

We can’t wait to see what you build.