Wednesday, January 28, 2015

Understanding Pull to Refresh

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).


ionRefresher (Pull to Refresh Directive)


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.


View


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:


rendered list


Remember that this list iterates over the $scope.items array.




ng-repeat="item in items"


Factory


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.


Controller


Our controller needs to do 2 things:



  1. Fill the feed with the initial items

  2. Handle the pull to refresh


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');
});
};

});


Conclusion


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!




by via Ionic Framework

OAuth Integration Using Hapi

Securing web resources is often a difficult and daunting task. So much so, that it is often left until the last phase of development and then it's rushed an not done properly. It's understandable though; security is a very specialized field in development and most people only give it a passing thought - "yeah this should probably be secured..." So then the developers quickly slap together an ad-hoc security method:


[js] if (password === "password1") { setCookie(); } else { send(401); } [/js]

and ship the product full of security holes. That snippet is, hopefully, a gross oversimplification, but the point is still valid.


Thankfully, there are developers out there who spend a lot of their time trying to secure websites and web resources and we can lean on their expertise to help us secure our own projects without having to reinvent the wheel.


In this article, we are going to walk through using OAuth tokens to authenticate users via their GitHub credentials. All of those words together probably sounds extremely difficult, but thanks to a few well documented modules, I think you'll be surprised how easy it really is.


Prerequisites


It is assumed that the reader: 1. has a functional understanding of working with the hapi server framework. 2. has built web resources in the past. 3. has basic understanding of cookies. 4. has a GitHub account. 5. has a rudimentary understanding of what Oath is and what it is used for (you could start by reading the Wikipedia Article about it).


If any of these assumptions are not true, you are strongly urged to get a handle on the listed prerequisites first, and them come back to learn about securing your webpage.


Getting Started


The first thing you'll need to do is create a GitHub application. This process will net you both ClientID and ClientSecret - both values you will need to set up OAuth on your web server.



  1. Log into your GitHub account and head over to the settings page (http://ift.tt/1b8Yxea)

  2. Click on "Applications"

  3. Push the "Generate new application" button and you will be navigated to a new screen that looks like this: Register a new OAuth application

  4. Application Name and Application Description can be anything you want. For Homepage URL and Authorization callback URL, let's set those to the local server we will be working with. In my example, I will be using port 9001, so set both values to "http://localhost:9001". My full setup looks like this: Completed application configuration

  5. After you push "Register application", you will be redirected to a new screen that will list both the ClientID and ClientSecret. Make note of these values for later.


Summary


This step was purely administrative. We created a new GitHub application that users will be asked about when they try to log in to your site. Rather than trust http://localhost:9001 with our GitHub credentials, we will trust the GitHub application to authenticate users, and then call back to our website when it's done.


Planning the Server


Before we start coding, lets come up with a rough outline of what we want our server to do. We will start with four routes for the sake of simplicity: a home route, an account information route, a login route, and a logout route.


In the home route, if the user has been authenticated, let's print their name, otherwise a generic message. Fo the account route, we will show all the information GitHub sends us. If the user requests the account page without being authenticated first, we will respond with the proper status code of 401. The login route will reach out to GitHub, ask the user for their permission to allow our GitHub application access to some of their account information, and then come back to our local web server. Finally, the logout route will log the user out of our website.


Server Skeleton


Let's get the boilerplate and routes configuration out of the way first.


Continue reading %OAuth Integration Using Hapi%




by Adam Bretz via SitePoint

A Beginners Guide to Mobile Development with Meteor

Out of the box, the Meteor JavaScript framework includes Cordova,



“a set of device APIs that allow a mobile app developer to access native device functions such as the camera or accelerometer from JavaScript”.



If you’re a web developer who wants to release their work on iOS and Android (while harnessing the features of those platforms), you don’t have to learn a new language or entirely new concepts. You just need a basic grasp of Meteor, and then a basic grasp of details specific to mobile development.


Continue reading %A Beginners Guide to Mobile Development with Meteor%




by David Turnbull via SitePoint

Interactive Config Guide for PhoneGap/Cordova

Screen Shot 2015-01-28 at 1.48.12 PM One of the challenges we face as hybrid app developers is determining which configuration settings to use for any given app due to variances in operating systems and browser rendering engines across platforms. The config.xml file located in the root of your PhoneGap/Cordova apps when you create an app can have a variety of content that can be confusing to developers. The documentation is often less than crystal clear as well. As a result, I’ve created a new interactive guide to document it and help people understand what each element/preference means, defaults and valid values for them as well as noting required fields and supported platforms. You can hover over the elements on the left side in the config.xml file and the details for it will display on the right. You can click the buttons to display the different preferences by platform. I’m continuing to test and add more details further as well.



This guide is specific to those properties available to you when building your app with the PhoneGap or Cordova CLI. If you are using PhoneGap Build, you will still be using this config.xml file as a configuration vehicle, however the names and support for different elements and preferences are completely different than when using the CLI’s and not to be confused. I also highly recommend the ConfiGAP tool or refer to the PhoneGap Build documentation Configuration section specifically for those details.


While on the subject of configuration, I also think it’s useful to explain a couple of things going on behind the scenes in terms of configuration content and your apps for at least iOS and Android in case there are some that want to dig in deeper.


iOS


If you look at the yourApp/platforms/ios/CordovaLib/ClassesCleaver folder in your project you’ll find classes where your config.xml file is used. It is parsed specifically in the CDVConfigParser.m class and those properties are then set as needed in the CDVViewController.m class. You should also be aware of the <projectName>.plist file that is used by your iOS apps. It’s located in the .../platforms/ios/MyProject/Resources/MyProject.plist path and has settings that will affect orientation and other settings you may feel the need to modify at some point.


Android


You will also find a CordovaLib folder in the project platform and the class used for parsing them on Android is ConfigXmlParser.java. The class that processes the settings once they’ve been parsed is CordovaActivity.java . You should also be aware of the <AndroidManifest.xml file that is used by your Android apps. It’s located in the .../platforms/android/MyProject/Resources/MyProject.plist path and has settings that will affect orientation and other settings you may feel the need to modify at some point.


Please feel free to provide any feedback on your own use with these preferences and settings if you have more information to contribute from your own experience.






by Holly Schinsky via Devgirl's Weblog

Microsoft Spartan and the Future for Internet Explorer

Following several months of rumors, Microsoft officially revealed Project Spartan -- their new web browser -- on January 21, 2015. Spartan is the reason the Internet Explorer team went quiet during the past fifteen months after IE11 was released. Spartan started life as a fork of IE's Trident engine but has evolved significantly. Baggage such as versioned document modes, VBScript and ActiveX have been removed, while new HTML5 features have been added to create a lighter, sleeker, more advanced browser. Spartan's engine, edgehtml.dll, is designed for interoperability and will be the default browser on Windows 10. Spartan browser IE11's engine, mshtml.dll, will remain on the OS for compatibility reasons. It will be hidden from most users but available to enterprises should they require it for legacy applications or websites requesting one of IE's many version modes or quirks rendering. Microsoft is unlikely to release Spartan for older versions of the OS, but Windows 10 will be a free upgrade for anyone using Windows 7, 8 or 8.1 during the first year of release. That should help it achieve critical mass relatively quickly.


Why Now?


Internet Explorer is the oldest surviving mainstream browser with a 20-year history. The early days were good and IE matured into the best, most standards-compliant application at the time. Then IE6 lay dormant for half a decade. IE7 was a rushed abomination. IE8 improved but failed to adopt the newest standards when other vendors had started to move to HTML5. By the end of last decade, Internet Explorer attracted derisory venom from even the most placid web developers. IE9 was released in 2011 and showed potential. By IE10, Microsoft had a fast, capable browser that improved further in IE11. IE could finally compete on a reasonably level playing ground.

Continue reading %Microsoft Spartan and the Future for Internet Explorer%




by Craig Buckler via SitePoint

Introducing CockpitCMS – a CMS for Developers

In this tutorial, we will see how to use Cockpit CMS to setup a CMS backend and to use the API interface provided by Cockpit to build a customized functional frontend.


Not quite like other “heavy weight”, or “fully fledged” CMS’, Cockpit is light weight and “bare”. It only provides a backend to manage meta-data and data entries, whilst the frontend is all in the developer’s hands.


Installation


A copy of Cockpit CMS can be downloaded here in zip form. After downloading, just unzip the archive to a directory on your web server that is accessible. In my case, it is mapped to: http://vagrant/cockpit.


Next, visit the installation page: http://vagrant/cockpit/install to start the installation process.


NOTE: Cockpit uses SQLite as its database engine by default. If you have not installed SQLite yet, please do so before the installation.


NOTE: Cockpit also requires that its /storage/data directory be writable. Please change the mode of that directory accordingly.


The installation is just one click. When the installation is complete, you will be greeted with this page:



Now we can log in with admin/admin and the backend administration dashboard page will be shown:



Well, we don’t have anything set up yet. Before we create our own content, let’s learn about a few key modules in Cockpit.


Modules in Cockpit


The two most important modules in Cockpit are: Collections and Galleries.


Continue reading %Introducing CockpitCMS – a CMS for Developers%




by Taylor Ren via SitePoint

How To Write a Product Feature Set