EmberFire 1.5.0

Tim Stirrat

Frontend Developer

Today's EmberFire release includes new features that will make it even easier for Ember developers to connect their apps to Firebase. The EmberFire 1.5.0 release brings Ember Data 1.13.0 compatibility, integration with Firebase Authentication, and some updates for embedded records.

What is EmberFire?

EmberFire is an adapter for using Firebase with Ember Data. It is packaged as an Ember CLI addon, which makes it incredibly easy to add Firebase as the backend for your Ember app. Using EmberFire, all of your models stored in Ember Data will be automatically synchronized with our remote Firebase database. Simply calling save() on a record will save it to the store and persist that data in your Firebase database.

New Features in EmberFire 1.5.0

Ember Data 1.13.0 Compatibility

Ember Data has made it out of beta, which means we can count on a stable API. This is great news for EmberFire. In addition to 1.13.0 compatibility, we're working on staying up to date with the latest releases, and our tests are also passing for 2.0 canary!

Torii Authentication

You can now authenticate users in your EmberFire app with Facebook, Twitter, GitHub, and Google using our Torii adapter. Get started by enabling the authentication provider you’d like to use in your Firebase Dashboard, installing the Torii addon, and following the authentication section in our guide. Once you've set it up, you can authenticate a user inside your route or controller with the following snippet:

this.get("session").open("firebase", { provider: "twitter"})
  .then(function(data) {
    console.log(data.currentUser);
  });

This snippet of code will authenticate a user with Twitter and log the returned user object to the console.

Many thanks to Matt Sumner for his work on this.

Embedded Record Changes

This release also changes the way embedded records are declared. If you have an embedded hasMany / belongsTo relationship in your EmberFire app, you should now follow the Ember Data conventions by configuring embedded record settings in a serializer. Visit the relationships section of our guide for details. Just be sure to use Ember Data 1.13.6+ for embedded records compatibility.

Getting Started

If you're new to EmberFire, using it with your Ember CLI app is as simple as installing our addon:

ember install emberfire

Then, update your Firebase URL in config/environment.js and you're ready to persist your Ember Data records in your Firebase database. Check out our guide for a detailed walkthrough on all things EmberFire.

We'd love to hear what you think of the latest release. Post any feedback in our Ember Google Group, or open an issue on GitHub. Contributions to EmberFire are always welcome, so feel free to submit a pull request if there's something you'd like to see added.

We're excited to see what you build with Firebase and Ember!

Read More

ReactFire 0.5.0

Jacob Wenger

Core Developer

React and Firebase were made for each other. And with the introduction of ReactFireback in May 2014, we provided a simpler way to build apps using both technologies. Today we're announcing ReactFire 0.5.0 - the biggest update since that initial release. The update brings improved performance, a handful of bug fixes, and some extra features to simplify development.

What is ReactFire?

For those who aren't familiar, ReactFire is a React mixin. The ReactFireMixin makes it dead simple to bind data stored in Firebase to a component's state. It handles both array-like and object-like data via the bindAsArray() and bindAsObject() methods, respectively.

For example, say you have a list of messages stored in your Firebase database that looks like this:

{
  "messages": {
    "-JqpIO567aKezufthrn8": {
      "uid": "barney",
      "text": "Welcome to Bedrock City!"
    },
    "-JqpIP5tIy-gMbdTmIg7": {
      "uid": "fred",
      "text": "Yabba dabba doo!"
    }
  }
}

You can bind the message data to your component's state by calling bindToArray() in your componentWillMount() method:

var ExampleComponent = React.createClass({
  mixins: [ReactFireMixin],

  getInitialState: function() {
    return {
      messages: []
    };
  },

  componentWillMount: function() {
    var ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com/messages");
    this.bindAsArray(ref, "messages");
  },

  render: function() {
    // ...
  }
});

The message data is now bound to this.state.messages. Whenever messages are added, removed, updated, or moved in Firebase, those changes are reflected automatically in this.state.messages

• no calls to this.setState() required! The bound data can be used as normal in your component's render() method:

render: function() {
  var messages = this.state.messages.map(function(message) {
    return (
<li key={ message['.key'] }>{ message.uid } says { message.text } </li>
);
  });
  return <ul>{ messages }</ul>
;
}

What's new in ReactFire 0.5.0?

The 0.5.0 release is the first major upgrade to the ReactFireMixin since its initial release. The API is still just as minimal, but a lot has changed under the hood.

The initial implementation of bindAsArray() was quite simplistic. It had poor performance and did not properly handle complex Firebase queries. The new implementation provides improved performance (especially on large data sets) and works well with all Firebase queries. Best of all, no changes to your code are required to enable these improvements.

Another major change with 0.5.0 is the addition of the .key attribute. ReactFire now adds the .key attribute to every record it creates via the bindAsArray() and bindAsObject() methods. In previous versions, it was impossible to retrieve key names for bound items. The 0.5.0 release fixes this by including the key name by adding a .key attribute to each bound item.

As an example, let's look again at the messages array from above. The resulting bound array stored in this.state.messages will be:

[
  {
    ".key": "-JqpIO567aKezufthrn8",  // New in version 0.5.0!
    "uid": "barney",
    "text": "Welcome to Bedrock City!"
  },
  {
    ".key": "-JqpIP5tIy-gMbdTmIg7",  // New in version 0.5.0!
    "uid": "fred",
    "text": "Yabba dabba doo!"
  }
]

The inclusion of .key makes it possible to easily write data back to Firebase to update, remove, or move a record in the array. All objects synced via bindAsObject() now include the .key attribute as well.

Finally, version 0.5.0 changes how primitive values (strings, numbers, booleans) are handled. As an example, say you have the following data in your Firebase database:

{
  "foo": "bar"
}

If you call bindAsObject() on the /foo/ path, previous versions bound the value as a string "bar". As of today's 0.5.0 release, the bound object now looks like this:

{
  ".key": "foo",
  ".value": "bar"
}

You have access to the key that was bound to (.key) as well as the bound value (.value). Primitive values bound via bindAsArray() behave in the same way with the primitive value being stored in .value. Non-primitive values (that is, regular JavaScript objects) have not changed and behave in the same in all versions, except for the addition of .key.

Looking Forward

There is a lot of excitement in the React community about ES6+, Relay, GraphQL, and ReactNative. Discussions about these topics are even ongoing in the ReactFire GitHub repo. We are following the new announcements and technologies closely. Since we use React in production at Firebase, we want the two technologies to work as well as possible together.

We've found that using the vanilla React and Firebase libraries together works great and somewhat replaces the need for an application architecture like Flux. Things like ReactFire simplify development further by providing a shorthand for a lot of common use cases. And community contributions like the recently released re-baselibrary show how well Firebase can fit into new technologies like Relay. The future of a React + Firebase application tech stack is exciting and promising. The two technologies make it that much easier to build scalable apps in a fraction of the time they traditionally have taken. You can expect ReactFire to evolve alongside React over the course of the comings months.

Getting Started with ReactFire

The best place to get started with ReactFire is by heading over to the docs. We have a five minute quickstart, a guide which walks you through making an example app, and a full API reference with more examples of binding data via bindAsArray() and bindAsObject().

If you run across any bugs or have feature suggestions, please file them on GitHub. If you have questions about the API or how to build apps with ReactFire, post them on the Firebase Google Group.

We are excited to see what you create!

Read More

6 Tools to Make Your Design Business More Efficient

Whether you run a design agency or operate as a freelancer, you quickly learn the value of efficiency. The slower you and your team members are, the more time wasted on badly-designed processes, the less work you get done - and the less money you make. You want to make sure your dirty work is quick and easy, in order to clear more time for what actually matters. The good news are that you’ve got plenty of tools to help you do that. Here are six you’ll surely find useful.

Read more »

Read More

Announcing Mobile Offline Support

Jonny Dimond

Core Developer

Have you ever had an app suddenly stop working when you lost your internet connection? Or perhaps you've opened an app you were using just minutes prior, only to find you have to re-download all of your data?

As a developer, you've likely tried to solve these pain points in your own apps, only to find the work required to be daunting. Wouldn't it be great if your database could just handle this for you automatically?

Firebase Offline to the Rescue

Today we're announcing a set of features for our iOS and Android SDKs that will allow you to build apps that work smoothly offline!

Our new SDKs support persisting your synchronized data to disk, so it's available immediately when your app starts. You can enable disk persistence with one line of code:

Firebase.getDefaultConfig().setPersistenceEnabled(true);

[Firebase defaultConfig].persistenceEnabled = YES;

Firebase.defaultConfig().persistenceEnabled = true

Our new SDKs now also let you specify data to be prefetched and kept up to date so that it will be available offline later if you need it. This keepSynced feature can be enabled on a per-path basis with one line of code:

ref.keepSynced(true);

[ref keepSynced:YES];

ref.keepSynced(true)

Built from the Beginning for Offline

The Firebase database uses synchronization rather than request / response to move data between client and server. All read and write operations happen against a local, on-device version of your database first. Then, data is pushed and pulled from our servers behind the scenes. This design has allowed the Firebase database to compensate for network latency -- local write operations are reflected by local reads before being acknowledged by the server.

It turns out, though, that this design is also essential to a high quality offline experience. By sending all reads and writes through a local version of the database, the Firebase SDK maintains the freedom to serve that data from the best source available -- whether that’s from the network or local disk. Later, when a network connection becomes available, our SDK automatically commits local operations to the server and pulls in the latest remote updates.

We designed Firebase for offline support from the very beginning, and we've been working on it for years. Citrix has been beta testing our offline support for its iOS app Talkboard since 2013. When you draw on a canvas in Talkboard, any updates you make while offline will be saved to disk and synchronized later when you reopen the app.

Getting Started

We've been working on these features for a long time, and we couldn't be more excited to see what you build with them! Getting started is easy -- just check out the offline section of our guides for iOS or Android. We also have offline drawing examples for iOS and Android that can help you get started quickly.

As you're coding, we'd love to hear what you think! Please share your feedback in our Google Group or mention @Firebase on Twitter.

Read More

Firebase now works with React Native!

Joey Yang

Frontend Developer

If you're like me, you're really excited about React Native, a new way to build (native!) mobile applications with JavaScript. Today, I'm happy to announce that thanks to the efforts of our developer community, Firebase and React Native now work together.

Hold up, what is React?

React is a view library created and maintained by Facebook. I love React for its declarative API, which makes managing changes in your views dead simple.

When you build your application's views with React, it automatically updates the UI of your application when it observes state changes in your data model. Conveniently, Firebase databases deliver a stream of realtime updates to your data model. With Firebase and React, it's effortless to create components that automatically update in realtime. The two pair beautifully together.

If you're not familiar with React — and for more details on using it with Firebase — our very own Jacob Wenger wrote this excellent introduction to Firebase and React, which explains the basics of React in more detail.

What is React Native?

React Native is a new framework that helps you build applications for native platforms primarily with JavaScript and React. React Native for iOS was released earlier this year. The React Native components in your iOS app render directly to real, native UIKit components — it's not a web app running on a mobile device.

Here's an example of some JavaScript you might write to create a simple view, from the React Native homepage. If you're familiar with React, you'll notice how instead of declaring HTML DOM elements like <div>s and <p>s, you declare components that map directly to standard iOS platform components.

    var React = require('react-native');
    var { TabBarIOS, NavigatorIOS } = React;

    var App = React.createClass({
      render: function() {
        return (
          <TabBarIOS>
            <TabBarIOS.Item title="React Native" selected={true}>
              <NavigatorIOS initialRoute={{ title: 'React Native' }} />
            </TabBarIOS.Item>
          </TabBarIOS>
        );
      },
    });

Did I mention this is just JavaScript? React Native also has support for ES6 syntax (shown above), and you can write your app with Flow, Facebook's static type checker for JavaScript.

Other bonuses of React Native include support for npm modules, debugging in Chrome Developer Tools, and instant reload in XCode (as in, hit Cmd-R and your app reloads in a few seconds instead of having to do full XCode rebuilds). It's a wonderful development experience.

Although React Native is still in beta, it's currently being used in production in some of Facebook's apps, including its Groups app.

In short, I'm excited about React Native because it lets me write native mobile apps with the technologies I use every day as a web developer.

Sounds great! How do I get started?

If you'd like to start getting your hands dirty with React Native, the official tutorial is an excellent place to start.

Once you've created your React Native app, just head to your nearest terminal and enter these magic characters to install Firebase via npm:

    npm install firebase --save

Then, in your JavaScript code just softly whisper var Firebase = require('firebase'); and all the power of the Firebase JavaScript SDK and React Native will be yours!

If you have any questions, bug reports, general commentary, or if you just want to say hi, you can find me on Twitter at @KanYang.

A special shoutout

Thanks to Harrison Harnisch, a developer in our community, for helping to get support for WebSockets merged into React Native!

Read More

Angular 1.4.0 - jaracimrman-existence

Angular 1.4.0 has arrived! This is a truly community driven release.

This release brings many feature enhancements and performance improvements, while at the same time introducing as few breaking changes as possible. For apps following best practices, we expect the migration from Angular 1.3 to 1.4 to be smooth and the list of breaking changes is documented in the migration doc.

We started work on 1.4 in November last year. The features and issues we concentrated on were guided by an analysis of feedback from developers using the framework in real projects. The planning was done in public, see the planning spreadsheet and video of the planning meeting. The weekly meeting minutes are available online.

New Features

In over 400 commits, we have continually improved the docs, fixed more than 100 bugs, and added over 30 features. Here is a rundown of the new things you can benefit from in this release.

Animation

Matias completely refactored animations, giving it more powerful features and squashing tons of edge-case bugs at the same time. This code overhaul is backwards compatible, except for a small number of documented api changes. This refactoring makes it possible to imperatively control CSS-based transitions/keyframes via a new service called $animateCss. We can now also animate elements across pages via animation anchoring.

• Complete refactor of internal animation code (c8700f04)
• CSS-driven Javascript animations (see docs)
• Better support for animation callback events (see docs)
• Move elements between views with animation anchoring (see docs)
• Provide support for animations on elements outside of $rootElement via $animate.pin() (e41faaa2)

$http

Pawel did some great work fixing outstanding issues in the $http service and also implemented a mechanism for providing custom URL parameter serialization, so now it is easy to connect to end-points that expect parameters to follow the jQuery-style parameter serialization.

• support custom params serializers (including a new jQuery-style serializer) (6c8464ad, #3740, #7429, #9224, #11461)
• provide a config object as an argument to header functions (d435464c, #7235, #10622)

Internationalization

Chirayu worked hard on improving i18n support for Angular apps. The first piece of this work was to provide a new ngMessageFormat module that supports the ICU MessageFormat interpolation syntax.

• extend interpolation with MessageFormat like syntax (1e58488a, #11152)
• Add FIRSTDAYOFWEEK and WEEKENDRANGE properties in the ngLocale data (3d149c7f)

Compiler related

To complement our push towards more use of `controller as` syntax in our component directives, Caitlin added support for binding a directive's element attributes straight onto the directive's controller.

• allow using bindToController as object, support both new/isolate scopes (35498d70, #10420, #10467)

Cookies

Shahar had stepped up to implement the much needed overhaul of the ngCookies module. The $cookieStore has been deprecated and its functionality moved over to the $cookies service, which now has a much cleaner interface. He also implemented the frequently requested feature to set cookie options for individual cookies as well as configuring the defaults via $cookiesProvider.

• $cookies:
• allow passing cookie options (92c366d2, #8324, #3988, #1786, #950)
• move logic into $cookies and deprecate $cookieStore (38fbe3ee, #6411, #7631)
• $cookiesProvider: provide path, domain, expires and secure options (53c66369)

Form Related

Matias was at it again, this time adding dynamic message support to the ngMessages directive, which makes it much easier to display messages requested at runtime from the server.

• ngMessages: provide support for dynamic message resolution (c9a4421f, #10036, #9338)

ngOptions was completely refactored to allow a number of annoying bugs to be fixed, it also now supports disabling an option using the `disabled when` syntax, thanks to Stephen Barker.

• ngOptions: add support for disabling an option (da9eac86, #638, #11017)

Shahar added improved support for specifying the timezone on date/time input elements that are using ngModel.

• ngModel: support conversion to timezone other than UTC (0413bee8, #11005)

jQuery related

Michel Boudreau worked with Michał to allow us to specify exactly which version of jQuery (if any) we want Angular to use. This option also allows developers to instruct Angular to always use jqLite even if jQuery is present on the page, which can significantly improve performance for applications that are doing a lot of DOM manipulation via Angular's templating engine.

• ng-jq: adds the ability to force jqLite or a specific jQuery version (09ee82d8)

Accessibility

Marcy Sutton continued to improve the accessibility of apps built with Angular with new features in the ngAria module:

• automatically add button role to ngClick (bb365070, #9254, #10318)
• automatically add roles to custom inputs (29cdaee2, #10012, #10318)

Filters

We tweaked and improved a number of the filters. Shahar did some nice work to bring better timezone support to the date/time filters; Tamer Aydın helped to add a start index to the limitTo filter; Georgios completely rebuilt the filter filter to be able to compare with deep objects; and Quentin improved the support for infinity in the number filter.

• number filter: display Infinity symbol when number is Infinity (51d67742, #10421)
• date/time filters: support conversion to timezone other than UTC (c6d8512a, #10858)
• limitTo filter:
• extend the filter to take a beginning index argument (aaae3cc4, #5355, #10899)
• ignore limit when invalid (a3c3bf33, #10510)
• filter filter:
• compare object with custom toString() to primitive (f8c42161, #10464, #10548)
• correctly handle deep expression objects (f7cf846045, #9597)
• allow array like objects to be filtered (1b0d0fd8, #11782, #11787)

Testing

• ngMock:
• $exceptionHandler: log errors when rethrowing (deb3cb4d, #10540, #10564)
• annotations: cleanup $inject annotations after each test (0baa17a3 & 6ec59460)
• $controller: allow mock $controller service to set up controller bindings (d02d0585, #9425, #11239)
• Travis:
• run unit tests on iOS 8 (2cdb2016, #11479)
• Benchmarks:
• add ngModel benchmarks to largetable-bp (b8dbdb0c, #11082)

Miscellaneous

Other features and improvements that are part of this release include:

• angular.merge:
• provide an alternative to angular.extend that merges 'deeply' (c0498d45, #10507, #10519)
• angular.Module:
• add decorator method for creating service decorators (e57138d7, #11305, #11300)
• $anchorScroll:
• allow scrolling to a specified element (731c8b5e, #4568, #9596)
• ngClass:
• add support for conditional map within an array (4588e627, #4807)
• $timeout:
• allow fn to be an optional parameter (5a603023, #9176)
• pass additional arguments to the callback (3a4b6b83, #10631)
• $interval: pass additional arguments to the callback (4f1f9cfd, #10632)
• $resource:
• include request context in error message (266bc652, #11363)
• Scope:
• remove history event handler when app is torn down (d996305b, #9897, #9905)
• CommonJS:
• The new optional CommonJS support makes using Angular modules in environments like npm and browserify easier.

Performance Improvements

Lucas proposed and implemented a complete rewrite of the Angular expression parser. The new parser is easier to maintain and up to 25% faster. On top of that change we have also speeded up scope watching, the compiler and ngOptions.

• $parse:
• new and more performant parser (0d42426)
• $compile:
• replace forEach(controller) with plain loops (5b522867, #11084)
• avoid .data when fetching required controllers (fa0aa839)
• ngOptions:
• only perform deep equality check on ngModel if using track by (171b9f7f, #11448, #11447)
• only watch labels if a display expression is specified (51faaffd)

What's next?

There were two features that were pulled out of the 1.4 release. The component helper (#10007) and the component oriented hierarchical router. The main reason for this decision was that both of these deliverables were not ready for the important task of simplifying the migration path from Angular 1 to Angular 2. Rather than delay the 1.4 release further, we decided to move these two deliverables into the 1.5 release.

The 1.5 planning is already underway, with the Component Router and component helper among the initial seeds. As before, the planning meeting will be published online. In this meeting the areas of focus and prioritization will be picked. At ng-conf we announced that the future focus of the 1.x releases will be migration path to Angular 2, so you can expect many of the deliverables to be in this area.

Thanks

This Angular version is the first to be run by a much broader community oriented team, including many people from outside of the Google Angular team such as Lucas, Martin, Shahar, Pawel, Michał, Georgios and Jason. These are people who are using Angular on a day-to-day basis in real, often large applications. They have worked tirelessly week after week to help get this release out. On top of these core team members, a number of other people from the community have contributed significant code to this release, or helped to review issues and pull requests. We'd like to thank them all.

Read More