In honor of Ionic 1.0’s release, the publishers of several Ionic and Ionic-related books are offering special, limited-time promotions. Get ‘em while they’re hot!
Use code if50 and get 50% off Ionic in Action by Jeremy Wilken, Apache Cordova in Action by Raymond Camden, & AngularJS in Depth by David L. Aden and Jason L. Aden (all formats) through March 26.
Now that we’ve released Ionic 1.0, we want to share more about our favorite new Ionic features. Last week, Adam wrote about his favorite new feature in Ionic 1.0, Swipe to Go Back. Personally, I’m most excited about our new animated SVG spinners, and I thought I’d explain why we decided to changes the spinners and what the new SVG spinners can do for your app.
Why would we need new spinners? After all, Ionicons already come with animated font icons that get the job done. Well, the older animated font icons were subjected to the browser’s font rendering, which differs between iOS and Android and among all the different versions of Android. Normally, this wouldn’t make a difference, since all fonts get rendered out as static content, but the animated font icons weren’t static. Depending on which browser you were using, they would rotate, and users would see the icon wobble. We had to face the facts: Animated Font Icons Were Not An Ideal Solution.
Since animated icons were not a perfect solution, we decided to move to full SVG icons, in order to create icons that weren’t subjected to the browser's font rendering. An added benefit was that since we use Angular, we could encapsulate a bunch of different icons inside a directive, and developers wouldn’t have to deal with the SVG markup.
Did we lose the ability to style the icons? Nope; you’ll still get to customize the icons to the colors of your choice and even use the built-in Ionic colors. To top it off, since the icons are a directive, we can switch them out at run time for Platform Continuity, and iOS and Android will each get the correct icons. This is also configurable, so you have the option of passing in one icon for both platforms.
Be sure to check out the documentation for the spinners and try them out in your own app!
Cheers!
Think about how it feels when you open up a particularly well designed iOS or Android app. The entire experience is predictable and clear; everything functions according to your expectations.
To achieve a user experience this seamless and comfortable, you'll need to design your app according to the style guidelines of each major mobile platform. Users expect apps to look familiar on their mobile platform of choice: a centered header on iOS, a left-aligned header on Android; tabs on the bottom on iOS, and on the top on Android; rounded icons in iOS, etc. Until now, accomplishing this was time-consuming, expensive, and downright difficult.
From a functionality standpoint, the “write once and run anywhere” mantra still applies, but from a design standpoint, it’s more akin to “write once; check the platform style guidelines; write some more; check again; deploy anywhere.” That’s pretty overwhelming when you’re trying to write an app for two or more platforms.
Ionic helps to solve this problem out of the box. Design is a critically important part of an app; it’s what makes an app attractive and enjoyable to use. Ionic helps developers build beautiful apps more quickly, and by incorporating Platform Continuity into Ionic, we provide developers with the tools to create clearly structured apps whose design elements and functionality meet users’ expectations, no matter which platform they’re using.
Ionic allows you to customize settings, such as headers, tabs, transitions, toggles, action sheets, back-buttons, checkboxes, nav-buttons, and fonts, for each major platform. For example, now Ionic checkboxes automatically look like iOS checkboxes on iOS and Android checkboxes on Android. Our action sheet below looks significantly different on iOS than on Android. All of this happens automatically and is customizable.
Going forward, our criteria for acceptance into the Ionic Showcase will emphasize platform continuity, in addition to beautiful design and unique functionality. We look forward to seeing what you build!
Hear more about platform continuity in Adam’s talk at ng-conf:
One of the biggest requests for Ionic View and ionic.io is to be able to invite co-workers, friends, and customers to preview and test your app. This would make the Ionic View app a great beta-testing experience that is quite a bit easier to use than TestFlight, etc.
Now, you can invite anyone to view and test your app with a new feature of the Ionic CLI. Just run:
$ ionic share EMAIL
to share the current app with the person at that email address.
To use this new feature, make sure to update to the newest version of Ionic CLI and upload your app to ionic.io:
$ ionic login
$ ionic upload
$ ionic share EMAIL
Also, soon you'll be able to share right from Ionic View and ionic.io. Enjoy!
Last week at ng-conf, we announced Ionic RC0, which includes several new features about which we’re really excited.
The first one, a feature near and dear to my heart, is Swipe to Go Back. Ionic now uses interactive transitions, rather than just static animations. Swipe to Go Back works the same way the back button does, animating the nav bar title and back buttons. You can swipe from the left of a page to go back to the previous page. Letting go at certain points of the transition will cause the view to either snap back or complete the navigation.
This feature, which is common in native iOS apps, is only offered for iOS, because Android doesn’t do this. It’s only in Cordova, because standard mobile browsers provide their own swipe to go back capabilities. The URL still changes and is no different than any other navigation with the same lifecycle events.
Watch the video of my presentation where I talk about Swipe to Go Back:
For more on the Ionic community's response to Swipe to Go Back and RCO, check out Sani Yusuf's post on Medium.com.
Hey Ions,
After a hugely successful ngConf last week, the Ionic office is abuzz with Angular 2, and what it means for Ionic. The number one response from ngConf is that Angular is here to stay, and will only continue to dominate in the future. We are all investing in the right framework.
With that in mind, I want to quickly address the questions we've gotten about Angular 2, and what it means for Ionic.
First of all, we will absolutely be supporting Angular 2, and we will release full Angular 2 support in Ionic v2. In fact, we are already working on it! I don't have a timeline for that (yet!), but chances are it will come earlier than v1 did :)
Next week we are doing an "Angular/Ionic 2 Summit." The Ionic core team will be locking themselves in a room (and we are flying in some remotes!) to go through all the lessons learned over the last year and half. Everything we did right (and wrong!) with Ionic v1, and what we will fix in v2. Yes, there will be coding!
We are going to become experts in Angular 2, and we are working in parallel with the Angular team to make sure Angular 2 is an incredible frontend framework on mobile, and that Ionic can build the best mobile framework on top.
With Angular 2, we want to make Ionic faster, easier to use, and more powerful. The new component model makes building components and extending Ionic much easier. Angular 2 apps are easier to write and interact with your data in a more expected way. The framework naturally interacts with web standards instead of creating new ones. Learning Angular 2 will be easier, and more developers will be able to work on the code base. A win-win-win-win*N.
So, yes, Angular 2 support is a 100% for sure. We will have more info when we are ready to release it!
Onward!
We are excited to be sponsoring a $500 cash prize for the best Ionic post submitted to AirPair’s $100K developer writing competition!
AirPair has released cool features that allow authors and readers to collaborate on posts, just like normal code, via forks and pull requests. Over the next 12 weeks, you can win your share of $100,000 in prize money for the best tutorials, opinion pieces, and stories about using Ionic in production.
Have you used Ionic in a way that you are proud of? Have you learned something you feel others would benefit from? How have you combined it with other APIs to get the job done? The average post published on AirPair in January was read 15,000 times, so this is a great way to share the cool things you’ve made with fellow developers.
Submit your posts here.
Collection repeat is Ionic's buttery-smooth solution for scrolling huge lists. Inspired by iOS's UITableView, we switch out elements as the user scrolls, so that only the minimum necessary elements are rendered. We released our first version of collection repeat last year and have been improving it since then. Recently, we identified some huge potential performance increases and decided a complete refactor was necessary.
Before we dive into the details, let’s talk about how collection repeat works at the most basic level.
Say there are four items on the screen, matching items 1-4 in the user's array of data: As the user scrolls down, item 1 will move up and out of view. Once it's fully out of view, its element will move to the bottom of the screen to the space where item 5 should be, as item 5 moves up and into view.
Additionally, we take the Angular scope that just represented item 1, assign item 5's data to it, and trigger a digest on that scope to make the element represent item 5.
To follow the above strategy and position every element properly, we need every item's exact width and height.
In our first iteration of collection-repeat, we required developers to provide dimension stats for every item, because we assumed that every item might have a unique width and height:
<ion-list>
<ion-item collection-repeat="item in items"
collection-item-height="75"
collection-item-width="'100%'">
</ion-item>
</ion-list>
With the new syntax, height and width are optional:
<ion-list>
<ion-item collection-repeat="item in items">
</ion-item>
</ion-list>
As you can see, in the common case where every item is the same size, you don't have to provide dimensions at all. Collection repeat now shines as a drop-in replacement for ngRepeat.
See the documentation for more information.
The old collection repeat assumed that, in every case, any item in the list could be uniquely sized. This assumption required us to recalculate every single item's width and height whenever the scroll view resized. This expensive operation caused unacceptable lag when loading or rotating the phone.
When we took another look at UITableView, we hit upon a better solution. UITableView accepts an 'estimatedHeight' for every element in the list and uses that to estimate the size of the scrollView. Then, while the user scrolls down, each item's dimensions are calculated on demand, and the size of the scrollView adjusts to reflect the actual dimensions.
We realized how much this could help performance and went into refactor mode.
Instead of requiring the user to input estimatedHeight, we compute the dimensions of the first element in the list with getComputedStyle() and use that for the estimatedHeight and estimatedWidth.
This lets us calculate dimensions lazily. We estimate that scrollView.height === estimatedHeight * items.length at the start, and as the user scrolls, we calculate the actual height of every element.
We also made some optimizations in the rendering of items. For example, we now batch DOM operations on items by setting cssText. We also now digest items entering items one frame after positioning them.
But the biggest optimization is in the calculation of dimensions. The new collection repeat has four possible 'modes' it enters, the first being the most performant, and the last being the least performant:
Static List Mode: This mode is entered when the height is given as a constant or not given at all, and the width is 100%. Here, we assume the height of every element is equal to the estimatedHeight. The math for this mode is simple and easy because every item has the same dimensions.
Static Grid Mode: Similar to static list mode, except there are multiple items per row. This is still simple because every item has the same dimensions.
Dynamic List Mode: This mode is entered when height is given as a dynamic expression, but width is still 100%. In this mode, every item potentially has a unique height. We get the computed height of the first item and use that to calculate the estimated size of the scrollView. Then, as the user scrolls, we lazily calculate the dimensions of the next items that should be shown.
Dynamic Grid Mode: This is the most complicated mode and is entered when both height and width are dynamic expressions. It's the same as dynamic list mode, except we also have to account for a potentially unique number of items appearing in each row.
Finally, each of the four modes can be entered in either vertical or horizontal scrolling.
The problem with the old repeater was that it was always in Dynamic Grid Mode and calculated all dimensions up front. This led to worse performance while scrolling, loading, and resizing.
Now, even in the worst case of dynamic grid mode, collection repeat is more performant than ever.
The biggest remaining opportunity for more performance gain is in the iOS browser’s rendering of images.
Whenever you set the src of an img on iOS to a non-cached value, there is a freeze of anywhere from 50-150ms--even on an iPhone 6. In our tests, an Android 4.1 device with images in collection repeat outperforms an iPhone 6.
Images are very commonly used with collection repeat, and we change the src of those images often as the user scrolls.
We tried creating a web worker that fetches the image, converts it, and sends its base64 representation back to the UI thread. The image is then set to this base64 representation as a data-uri. This fixes half of the problem. If you set an img src to a data-uri that has been set before, it instantly gets the rendered image from the cache and shows it without lag. However, the first time a unique data-uri is set, there is a similar delay to that of a a normal src.
This is still an improvement from normal src, which just doesn't cache well at all.
We're experimenting with a few more tricks to improve iOS performance, and plan to release them as a simple-to-use solution soon. We welcome your ideas.
The new collection repeat is better than ever, and easier to use than ever. Give it a try!
View the documentation at http://ift.tt/1K9suB2.
Enjoy!
If you've used ionic serve or ionic run with live reload and accessing external API endpoints, chances are you've run into some CORS issues. They usually look something like this:
XMLHttpRequest cannot load http://ift.tt/1w8vMc7.
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://localhost:8100' is therefore not allowed access.
So what is CORS, and why is it a problem?
CORS = Cross origin resource sharing.
The origin is the host you are currently viewing. Since you're at http://ift.tt/1w8vMsn, the origin is ionicframework.com.
Say we send an AJAX request to http://cors.api.com/api, your host origin will be specified by the Origin header that is automatically included for CORS requests by the browser. Since ionicframework.com does not match the host of api.com, our request from ionicframework.com must ask the server for approval before we can access the resource, in the form of an HTTP OPTIONS request header.
If we get the error above, then we may not access the resource from the server.
Let’s take a look what your origin will be when you're running your app via ionic serve, ionic run, or ionic run -l.
What happens when you run ionic serve?
This starts you off looking at your app loaded in a browser on your computer with the address http://localhost:8100 (if you chose localhost).
Your origin will be localhost:8100.
Any AJAX request sent out to a host other than localhost:8100 will have localhost:8100 as its origin and thus will require a CORS preflight request to see if it can access the resource.
What happens when you run ionic run?
file://some/path/www/index.html.Your origin will not exist, since you are running off of a file:// URI; therefore, any request outwards will not require a CORS request.
What happens when you run ionic run -l?
http://192.168.1.1:8100 (or whatever your local IP address is).Your origin will be 192.168.1.1:8100.
Any AJAX request sent out to a host other than 192.168.1.1:8100 will require a CORS preflight request to see if it can access the resource.
CORS is only an issue when we are running or testing our app when running ionic serve or ionic run -l.
There are two ways to solve the issue: The first, and easier, solution is to just allow all origins from your API endpoint. However, we can't always control the endpoint we are accessing. What we need, then, is a request that does not specify an origin.
We can do this by using a proxy server. Let's look how the Ionic CLI provides an easily configurable proxy server.
A quick definition about proxies:
In computer networks, a proxy server is a server (a computer system or an application) that acts as an intermediary for requests from clients seeking resources from other servers.
What we'd need to do to get around these CORS issues is have a proxy server that will take our requests, issue a new request to the API endpoint, receive the response, and forward it back to our app so we can get around CORS issues.
The Ionic CLI introduced the ability to have a proxy server issue requests for you to get around any CORS issues you may have.
Since the server is sending a fresh request to your destination, there will be no origin and therefore, no CORS needed. It is important to note that the browser adds in the Origin header.
Please note, these are only needed for ionic serve and ionic run -l.
First we will need to set up the proxies in our ionic.project file. This will tell our Ionic server to listen to those paths and forward those requests on to the destination url.
In our app, we will need to replace our endpoint URLS to be set to the proxy server address for when we are running serve or run -l.
We can make this a bit easier by using some gulp tasks using the replace module to swap out the URLs.
The suggested method is to set up an Angular Constant to point at the API we're trying to proxy out.
This is the approach we will take below. We will also set up an Angular Service to use that API Endpoint to get data.
Let's say we want to access http://cors.api.com/api, which is not allowing our origin from localhost.
The proxies settings contain two things: the path you use to access them on your local Ionic server, and the proxyUrl you'd ultimately like to reach from the API call.
Set up your ionic.project file to be something like:
{
"name": "proxy-example",
"app_id": "",
"proxies": [
{
"path": "/api",
"proxyUrl": "http://ift.tt/1FUfrjL;
}
]
}
Run your server with ionic serve.
As we specified above, when you access the ionic server at the path http://localhost:8100/api, it will proxy requests out to http://cors.api.com/api on your behalf.
Thus, no CORS is required.
It's quite easy to set up your API endpoints as Angular Constants.
Below, we've specified the ApiEndpoint to be our proxied URL right now.
Later, we can use our production url as a constant.
angular.module('starter', ['ionic', 'starter.controllers', 'starter.services'])
.constant('ApiEndpoint', {
url: 'http://localhost:8100/api'
})
// For the real endpoint, we'd use this
// .constant('ApiEndpoint', {
// url: 'http://ift.tt/1w8vP7x;
// })
Once this is done, you can use the constant anywhere in your app, by including ApiEndpoint as a dependency, as shown below in the service.
angular.module('starter.services', [])
//NOTE: We are including the constant `ApiEndpoint` to be used here.
.factory('Api', function($http, ApiEndpoint) {
console.log('ApiEndpoint', ApiEndpoint)
var getApiData = function() {
return $http.get(ApiEndpoint.url + '/tasks')
.then(function(data) {
console.log('Got some data: ', data);
return data;
});
};
return {
getApiData: getApiData
};
})
For this process, we'll need to modify our gulpfile.js to add in two tasks to add our proxy url or remove our proxy url.
Start by first installing the replace module - npm install --save replace.
// `npm install --save replace`
var replace = require('replace');
var replaceFiles = ['./www/js/app.js'];
gulp.task('add-proxy', function() {
return replace({
regex: "http://ift.tt/1FUfrjL;,
replacement: "http://localhost:8100/api",
paths: replaceFiles,
recursive: false,
silent: false,
});
})
gulp.task('remove-proxy', function() {
return replace({
regex: "http://localhost:8100/api",
replacement: "http://ift.tt/1FUfrjL;,
paths: replaceFiles,
recursive: false,
silent: false,
});
})
This tutorial showed you one way to handle your CORS issues when running ionic serve or ionic run -l.
We know that it can be a hassle to swap out your API url endpoints when switching between ionic serve and ionic run -l. One thing that could be suggested is to have a gulp startup process.
The easiest way to handle the CORS problem is to ultimately ask your API provider to allow all hosts. However, this isn't always an option.
Using the Angular constant and the replace module will give us a happy medium, in which we can work around CORS.
If you need a solid example, take a look at this sample project.
This is everything you'd need to access an API server that restricts CORS.
If you have any questions, issues, or ideas, please leave a comment below or contact us on twitter or github.
Jeremy Wilken’s book Ionic in Action is being published by Manning and will be released late this spring.
Even though the book is not yet in print, you can get the early access version today (Save 42% with code ionic42) and give Jeremy direct feedback in the author forum, where he will respond to your posts himself.
We talked with Jeremy about his background, his use of Ionic, and the process of writing the book.
Can you tell us a little about yourself as a developer and writer?
Like many developers, I have always had an interest in tinkering and understanding the moving parts. I’ve been building websites since I was in junior high, and I gradually grew my skills to the point where I spent many years freelancing. More recently, I’ve joined larger scale projects and now work primarily as a front end engineer. I love working on usability and user experience. Becoming a developer and writer wasn’t my plan during my formal education (I’ve got a degree in the arts), but that is pretty common in our field.
As far as being a writer, that part is somewhat new to me. Most of my writing was done in college, and while I did write quite a few papers then, the style is very different from the writing done for a technical book. I’ve worked pretty hard to improve my skills, and I am fairly proud of what I have written so far.
When did you start using Ionic, and what about it was compelling enough to you to write a book about it?
I started with Ionic in early 2014, after it had been available for only a few months. My position at the time was investigating the feasibility of building a mobile app for internal employee use only, and, because our toolkit was primarily Node/AngularJS apps, Ionic fit into our skill set very well. I was able to build a prototype in a few hours and deploy it to a mobile device, which surprised me, compared to working with native development tools. (Granted, native development can be rapid, too, but you need to learn different skills.)
I have always had a passion for helping others learn, whether by speaking at events or teaching in my work role, so writing a book was a natural interest of mine. The benefits and power of Ionic opened doors for me to build mobile apps with my current skill set, and I wanted to empower others the do the same.
Can you talk about the process of writing this book?
Writing a book is like a marathon. There’s a lot of ground to cover, and it takes a good cadence to reach the goal. The good thing is that while I’m the author, I have several editors who are able to help me articulate ideas, plan out concepts and examples, and review my work.
The general process starts with nailing an outline and working with a publisher to get the details ironed out. Then it’s a matter of meeting deadlines for chapters, getting them reviewed by editors, revising, getting more feedback, and so forth. The hardest part is getting the inspiration to write when I have the time blocked off. Writing is a form of art, and it takes the right mindset to get quality work done.
Manning is the publisher for Ionic in Action, and I have to say everyone I have worked with there has been extremely helpful and professional. They have helped to make the book a high-quality work.
You built three Ionic apps during the writing process! Which UI elements did you use, and can you tell us more about the development process?
I used nearly every Ionic component in the three apps I built for the book, so the book provides a good reference for using the components in an integrated manner. The first is an app that a resort might use to provide value for their guests. It has the slide box, lists, cards, content containers, basic navigation, and other smaller elements.
Demo: http://ift.tt/1EosiZG
Source: http://ift.tt/1LwmFca
The second is a bitcoin market app, which provides real-time currency rates for bitcoin. Some of the components it uses are pull to refresh, popovers, tabs, charts, advanced lists, and nested views.
Demo: http://ift.tt/1EosiZU
Source: http://ift.tt/1LwmFcc
The third is a weather app, with the ability to find locations and see the weather forecast. It leverages modals, custom scroll area (paginated scrolling), loading external data, side menus, a search view, and some other smaller elements.
Demo: http://ift.tt/1EosiZW
Source: http://ift.tt/1LwmFcg
The demos were developed very carefully and actually took more time than writing the text did. I almost wish I could also have written about the process of building these apps, because while they look very straightforward to develop, for the book, it was a journey of writing and refactoring. I wanted to make sure the examples were not contrived or boring, but also not too complex. They needed to illustrate the key features I wanted to teach, so I would make the first prototype and then remove half of the code to simplify. I really hope they resonate with readers, and even if you don’t buy the book, you can still tinker with the samples.
Can you talk more about the functionality and technical aspects of the apps that you feel are unique, interesting, important, etc.?
I think each app is unique and very quite robust. I’d say they are 80% ready to be deployed to an App Store, with some of the obvious missing pieces listed at the end of the chapter, as a challenge for readers to implement themselves. Considering the actual amount of code and the number of features, it should be pretty clear how much Ionic bolsters app development.
AngularJS is a primary part of Ionic apps, and I’ve gone to great strides to provide an Angular primer, tips about Angular, and to structure the examples in a way that scales. There are too many bad and outdated examples of Angular code out there, and while it might be helpful for learning, it is a disservice to readers.
Could you talk about how you went about differentiating the app for different platforms? What did you do to align with the iOS platform, for example, vs. Android?
Since the examples leverage Ionic’s components almost exclusively, there isn’t much that I needed to do to support each platform in the examples. The beauty of Ionic components, such as the tabs component, is that Ionic will identify the platform and adapt the style appropriately.
That said, this topic is extremely important and is covered in the advanced topics chapter. When you start to design your own interface elements or modify the default ones, it is critical to preview your app in multiple platforms. The book covers techniques to allow you to target a platform, such as you want to use the action sheet in iOS and the popover in Android. Developers should spend time familiarizing themselves with the interface guidelines for both platforms and make decisions about what to use, because it ultimately helps users.
What will Ionic users learn from this book?
People already using Ionic will be able to learn more about the entire ecosystem that surrounds Ionic, such as how to leverage Cordova and plugins; some of Ionic's platform services, such as Ionic View; and how to level up Ionic development with advanced techniques and testing. I can't stress enough how important tests are, but it is probably the most overlooked skill in software development. The book provides examples and insight into how to setup and write your own tests.
Buy the early access version today (Save 42% with code ionic42)!
Viceversa is a social decision-making app that lets anyone in the world help you make choices. Questions as simple as, "Where should we go for dinner?" or as complex as, "What should I say to resolve this situation?" can be crowd-sourced. Close friends and family members can share their opinions privately.
The ViceVersa team is comprised of CEO Jonathan Widawski, the project leader, designer, and web developer; COO Alexis Schechter, an iOs developer and marketing director; and CTO Thomas Mary, a backend developer and technical director. The team chose to build their iOS app using native code and their Android app with Ionic.
“Ionic allowed us to create our app in no time, compared to our native iOS app,” says Widawski. “Since Thomas and I are huge Angular fans, the learning curve for Ionic was really smooth, and we got started quickly. Design-wise, we used almost everything Ionic provided, from CSS to JS utils, and tweaked most of them to respect the new material design guidelines and our own design.”
At the time Widawski and Mary were developing the Android version of Viceversa, they were also building their website. “Ionic was the game changer in our development process,” says Widawski. “It gave us the opportunity to create a beautiful, AngularJS-based Android app using the resources we had: web development. Ionic allowed us to re-use what’s been done for our web app and simply copy and paste a lot of our previously completed work. It was delightful.”
Widawski notes that Ionic’s recent updates demonstrate an effort to catch up with previous performance issues on Android. “Every recent update was a pleasant surprise in Android performance,” he says. “Design-wise, we decided to follow, as best as we could, the Material Design guidelines provided by Google. If you have the occasion to try both apps, you will see that they are very different: Every process was built with the platform in mind.”
The Viceversa team is passionate about split testing, and leveraged it with the app. “We tried two radically different designs and interfaces because we want to know what works best,” says Widawski. “We plan to create tutorials on how to make most of the animation within our app and on how to improve performance on Android globally.”
Widawski, a frontend developer who also has experience with PHP and the Laravel framework, adds, “There is an Ionic way of doing things. You don’t get lost; it is very well documented and up-to-date; and if you have any questions, the forum has one of the most active and helpful communities I’ve seen.”
Mary found Ionic to be straightforward and well-integrated with AngularJS. “There’s really little to no room for hesitation when coding,” he says. “That’s what we love about Angular, and that’s what we love about Ionic.”
Get the Android version of Viceversa (built with Ionic).
Get the iOS version of Viceversa.
We took a small break after our last show, but we’ve all been working really hard for the last couple months and have a lot of exciting things to share. Most importantly, we want to give our community a huge shout-out for all your amazing support, hard work, and beautiful apps that have surpassed all of our expectations.
The Ionic community has blown us away with everything we have been able to create in such a short period of time! It is because of the community that we have grown to one of the top 50 most popular open source projects in the world, with over 340,000 apps created across the globe and thousands more being created daily. In fact, we already have more groups around the world than we mentioned at the end of the show!
Here is a quick breakdown of the show:
We love you all! Let’s keep killin’ it, together.
See you next time!
This is a guest post by Andrew McGivery, an application developer with a strong background in Android, AngularJS, Ionic, C#, SQL, and front end development. Andrew writes often about Ionic and how to build great hybrid apps. Read more on Andrew's personal blog
With the rise of social networks, the "feed" has become a popular design pattern, especially in mobile apps. The idea is to load in new items to the top of a feed by pulling down from the top of the list until you see a loading indicator, letting go, and watching as new items magically (not really) add themselves in.
Ionic has an awesome directive that has undergone a redo fairly recently to accomplish exactly this. In this post, we'll break down a basic example of using this directive, a list, and the Random User API to see how to use the directive with example data (feel free to follow along on CodePen).
The Ionic directive we are going to use is the ion-refresher (Official Documentation). The most basic usage is as follows:
<ion-refresher on-refresh="doRefresh()"></ion-refresher>
on-refresh should point to a $scope function that gets the new data, updates a list, and then lets the refresher know it is done. This refresher should be above some kind of list.
For our example, we'll be using the following view markup:
<ion-refresher on-refresh="doRefresh()"></ion-refresher>
<ion-list>
<ion-item class="item-avatar" ng-repeat="item in items">
<img src=" " />
##
<p> </p>
</ion-item>
</ion-list>
which looks something like this, once rendered:
Remember that this list iterates over the $scope.items array.
ng-repeat="item in items"
In our example, we're going to be making a call to the Random User API to get some data to play with. To do this, we'll create a factory that makes these API calls. This factory will have two methods: GetFeed and GetNewUser. GetFeed will be called when our app loads to get the initial data, and the GetNewUser will be called each time we do a pull to refresh.
.factory('PersonService', function($http){
var BASE_URL = "http://ift.tt/15UKtsZ;;
var items = [];
return {
GetFeed: function(){
return $http.get(BASE_URL+'?results=10').then(function(response){
items = response.data.results;
return items;
});
},
GetNewUser: function(){
return $http.get(BASE_URL).then(function(response){
items = response.data.results;
return items;
});
}
}
})
Our GetFeed call returns 10 results, and each call to GetNewUser returns 1 result.
Our controller needs to do 2 things:
First, to fill our feed, we'll want to make a call to the PersonService and assign the result to the $scope.items array:
.controller('MyCtrl', function($scope, $timeout, PersonService) {
$scope.items = [];
PersonService.GetFeed().then(function(items){
$scope.items = items;
});
});
Next, we need to handle the pull to refresh. Recall we configured our directive to call a doRefresh function. We'll need to define this function:
$scope.doRefresh = function() {
}
In this function, we should call the GetNewUser function and add these items to the beginning of the array.
$scope.doRefresh = function() {
PersonService.GetNewUser().then(function(items){
$scope.items = items.concat($scope.items);
});
};
You'll notice we are using the array.concat function to add the items in. This is because items is an array, so we need to add the two arrays together.
We still need to do one final thing. We need to let the scroller know that we're done loading in the new items, so it can hide the loading indicator. To do this, we need to broadcast the scroll.refreshComplete event.
$scope.doRefresh = function() {
PersonService.GetNewUser().then(function(items){
$scope.items = items.concat($scope.items);
//Stop the ion-refresher from spinning
$scope.$broadcast('scroll.refreshComplete');
});
};
In its entirety, our controller looks like this:
.controller('MyCtrl', function($scope, $timeout, PersonService) {
$scope.items = [];
PersonService.GetFeed().then(function(items){
$scope.items = items;
});
$scope.doRefresh = function() {
PersonService.GetNewUser().then(function(items){
$scope.items = items.concat($scope.items);
//Stop the ion-refresher from spinning
$scope.$broadcast('scroll.refreshComplete');
});
};
});
Using the code above (full code on CodePen), you can accomplish this common pull to refresh patten in your Ionic Apps. Questions? Feel free to comment below!
Pacifica, an app for stress, anxiety and worry, is built around quick, iterative activities that individuals can perform privately in order to cope, understand, and better control their emotions.
Developer Dale Beermann and designer Chris Goettel based the application on the well-known technique of Cognitive Behavioral Therapy (CBT), in which therapists and their clients discuss emotions and tools with which to manage and overcome challenging feelings of stress, anxiety, and depression. Beermann and Goettel wanted to find a way for individuals to practice these techniques between therapy appointments or, in many cases, on their own, using their mobile devices.
“We found that the current implementations are simple mappings from typical workbook-based pen and paper exercises to a mobile device,” says Beermann. “However, workbooks themselves don’t fit into our normal routines. We knew we could do better.”
Beermann and Goettel devised an app that would guide users through relaxation, thinking, wellness, and behavioral exercises, based on the tools of CBT. Users can open the app and practice these techniques anytime, anywhere, as often as they like.
“These are proven tools. I’ve personally dealt with anxiety most of my life, and CBT was the way out of the woods for me. The challenge then for me as a designer was distilling these tools into an engaging and empathetic app. I know first hand how debilitating and isolating anxiety can be. Pacifica is an extended hand to anyone suffering,” says Goettel.
Before moving to California, Beermann was an active member of the entrepreneurial community in Madison, where Drifty, Ionic’s parent company, is based. Beermann has known Drifty co-founder Max Lynch for years, so when he started his most recent company, “Ionic was a natural choice,” he says.
Beermann and Goettel, who both have backgrounds in web development, chose to build an HTML5 app because they wanted to be cross-platform from day one. “Building an HTML5 app gets you 95% of the way there,” says Beermann. “Choosing Ionic meant that we were productive immediately; there was no time wasted learning a new language or UI paradigm. We had working prototypes the first week we started programming.”
Beermann and Goettel used most of the basic building blocks in Ionic to build their app: lists, modals, popups, drawers, overlays, and the Ionicons library. “You can’t quite tell, as we’ve customized most of the UI around it,” says Beerman, “but that was a lot of code that we didn’t have to write.”
“We believe that tools like Ionic or Bootstrap are incredibly important in the prototyping process,” adds Goettel. “They allow rapid proof-of-concept implementations that can be adapted for production quite easily. While these tools provide CSS layers over a broader framework, the CSS can be customized to your liking, giving you the benefit of a robust framework with the customizability a designer needs.”
Goettel chose a style that would work across platforms and wasn’t tied to the native UI of any single one, while incorporating design elements that fit correctly where appropriate.
“There are a couple things that we had to handle on the technology side to make a truly cross-platform application (Android sorely needs the HTML5 AudioContext), but we really wanted to stick with the same general look and feel everywhere,” says Beerman.
“We don’t feel that we could ever be close to where we are today if there weren’t tools like Ionic available,” adds Beerman. “At best, we might have had a single platform ready for release if we were native, but with Ionic, we’re set to launch iOS and Android simultaneously.”
Find Pacifica in the Google Play and iOS stores today!
Now that Apple’s new iPhone 6 and 6 Plus are on the scene, developers must consider new screen resolutions when building iOS apps. Ionic’s styles are fully responsive out of the box, so there’s no issue there. However, when testing an app on a shiny new iPhone 6, your app will look slightly blurry by default, displaying at the resolution of the iPhone 5 series and anti-aliasing the difference. That’s wasted pixels! There are two things you must do for your app to display full resolution on the iPhone 6 family of phones.
First, you may need to update the version of Cordova your project uses. The Ionic CLI makes this process a breeze. Simply run the following commands in a terminal window. Note that the first command may require sudo.
npm update -g ionic cordova
cd ~/Development/myProjectDirectory
ionic platform update ios
The next step is to add the appropriate splash screen. XCode will decide whether your app can take advantage of the full iPhone 6 and 6 Plus resolutions, based on whether appropriately sized splash screens have been added to your project. The Cordova update you just installed also includes the ability to specify splash screens via the confix.xml file, like this:
<platform name="ios">
<splash src="pathToImage/Default-568h@2x~iphone.png" width="640" height="1136"/>
<splash src="pathToImage/Default-667h.png" width="750" height="1334"/>
<splash src="pathToImage/Default-736h.png" width="1242" height="2208"/>
…
The Ionic CLI makes that even simpler. As described in greater detail by Mike Hartington in Automating Icons and Splash Screens, the new resources command makes it easy to create a splash screen. Simply put an image titled “splash” in your project’s resources directory (you may need to create one), and run:
ionic resources
This will automatically create iPhone 6 or 6 Plus-sized splash screens and update your config.xml. If you have images already prepared, just make sure you link to an image titled Default-667h.png, with the dimensions 750px by 1334px for the iPhone 6, and Default-736h.png, with the dimensions 1242px by 2208px for the iPhone 6+, and that they’ve been added to your project’s config.xml.
That’s it! Next time you run ionic prepare, ionic run, or ionic build, the splash screens will be applied to your project, and your app can take full advantage of the new screen real estate offered to the new iPhone 6 series phones.