Tag Archives: Mobile Application

Create a Mobile Application Using WordPress, Ionic, and AngularJS


Create a Mobile Application Using WordPress, Ionic, and AngularJS
// Front-End Tutorials Blog

Introduction In this tutorial, I will explain you step by step how to create a mobile application (iOS and Android) of your WordPress website using the latest technologies. We’ll be using Ionic Framework, ECMAScript 6, npm, webpack, and Apache Cordova. At the end of this tutorial you will get the following application. It has only three modules, a Home module that displays your latest

Couchbase LIVE New York: Couchbase Mobile 102 – How to Add Secure Sync to your Mobile Applications


Couchbase LIVE New York: Couchbase Mobile 102 – How to Add Secure Sync to your Mobile Applications
// CouchBase Blogs

Adding Google Sign-In with NodeJS to a Couchbase Mobile application


Adding Google Sign-In with Node.js to a Couchbase Mobile application
// CouchBase Blogs

How to Run NodeJS with Express on Mobile Devices


How to Run Node.js with Express on Mobile Devices
// Kogonuso

sshot-9502.png
We released a JXcore plugin for Apache Cordova recently and in this article I will show how to run a Node express application with Cordova.

At the time of writing the jxcore-cordova project on github has two samples prepared for running the express module.
1438579587samples_list.png
The project contains an install_and_run script (documented here), which simplifies creating a Cordova application and running the samples. I’m going to use the script in this article.
[autho_more]

Express on Android

The script assumes that Apache Cordova and the Android SDK is installed on your system. If they are not, please refer to individual documentation on how to do this.
Plug an android device into a USB socket (with USB Debugging enabled), unless you want to run the application on the Android Emulator.
Download the script and save it into an empty folder. Run it with a sample folder name as an argument, for example “express sample”:

$ ./install_and_run.sh "express sample"

Shortly, you should see the following screen:
1438579563android_launched.png
The application displays the IP addresses that the device is using and which port the express server is running on (3000 in our case). Take that URL and use it in your browser, i.e.:

http://10.0.2.15:3000

1438579569browser.png
We can see that the browser was able to connect to our Express server running on the device and receive the proper answer for the request.
A note for emulator users: As you might have noticed on the screen above, I did not use the IP and port mentioned before, but http://localhost:8080 instead. This is because I was running the sample on an AVD (Android Virtual Device), and the IP is not reachable outside the emulator’s internal router (see Emulator Networking for more details). Thus my solution was to establish a simple port redirection:

telnet localhost 5558
redir add tcp:8080:3000

Which redirects all http requests from my localhost:8080 into the emulator’s 3000 port. The 5558 number is the port on which my AVD was running (visible at AVD’s title bar).

Express on iOS

We can run the same sample on iOS devices. The install_and_run.sh script can handle it, but the iOS support is currently commented out, run those commands:

# or run on ios
$ cordova platforms add ios
$ cordova run ios

1438579580ios_launched.png
This time accessing the Express server from the browser is more straightforward, for example, http://192.168.1.11:3000.

Looking at the code

Looking at the app.js file located in the www/jxcore folder of the express sample, the Express server is implemented in the same way as a regular Node.js application:

var express = require('express');
var app = express();
app.get('/', function (req, res) {
res.send('Hello World! (' + Date.now() + ")");
});
var server = app.listen(3000, function () {
clog("Express server is started. (port: 3000)");
});

Express server running on another thread

Let’s look at the other example:

$ ./install_and_run.sh "express performance sample"

This example performs similarly, but there is one major difference. It runs the express server in a separate thread unblocking the main thread. This is easy with JXcore as it offers multitasking, before it even arrived on mobile platforms.
This is the code:

jxcore.tasks.addTask(function() {
var clog = require('./utilities').log;
var express = require('express');
var app = express();
app.get('/', function (req, res) {
res.send('Hello World! (' + Date.now() + ")");
});
var server = app.listen(3000, function () {
clog("Express server is started. (port: 3000)");
});
});

Note: The code is similar to the previous example. But is wrapped in a jxcore.tasks.addTask() invocation which handles the logic related to running the block in a separate instance.

Conclusion

The Express web framework is one of the most popular and important modules in the Node.JS ecosystem. With JXcore it is possible to make it run on mobile devices and it brings a range of features (including multithreading/multitasking and packaging) that can be used in the mobile world.

Krzysztof is a computer engineer and/or a geek who believes that, some day, he’s going to hack the encrypted secret of the existence. Since the day one, programming was one of he’s favorite hobbies. Currently he is a member of JXcore development team at Nubisa Inc.

Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile


via Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile.

This document, “Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile” describes how the Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] and its principles, guidelines, and success criteria can be applied to mobile web content, mobile web apps, native apps, and hybrid apps using web components inside native apps. It provides informative guidance, but does not set requirements. It also highlights the relevance of the User Agent Accessibility Guidelines 2.0 [UAAG20] in the mobile context.

This document is intended to become a Working Group Note and is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI).

Continuous Delivery Testing Pathway


This pathway is a tool to help guide your self development in continuous delivery testing. It includes a variety of steps that you may approach linearly or by hopping about to those that interest you most.

Each step includes:

  • links to a few resources as a starting point, but you are likely to need to do your own additional research as you explore each topic.
  • a suggested exercise or two, which focus on reflection, practical application and discussion, as a tool to connect the resources with your reality.

Take your time. Dig deep into areas that interest you. Apply what you learn as you go.

STEP – Removing release testing

Why does this pathway exist? Understand the key reasons to significantly shorten a release process, the arguments against release testing and why organisations aim to avoid batched releases in agile environments:

EXERCISE
[2 hours] Research your existing release process and talk to people within your organisation to find out whether there are any current initiatives to improve it.

STEP – Introduction to continuous delivery

What is the end goal? Discover the basics of continuous delivery and the theory of how it can be implemented in organisations.

EXERCISE
[1 hour] Based on what you’ve read, try to explain the theory of continuous delivery in your own words to someone in your team. Describe what appeals to you about continuous delivery, what you disagree with, and things that you think will be difficult to implement in your organisation. Afterwards, if you have any remaining questions, raise these with a technical lead or coach for further discussion.

STEP – Experiences in continuous delivery

How are other organisations doing continuous delivery? There is a lot of variance in implementation and differing opinions about how to approach the theory. Understand the realities of the people, processes and tools of teams doing continuous delivery:

EXERCISE
[2 hours] Compare the experiences shared in the links above and the theory of continuous delivery. Identify common themes, and areas where ideas or implementation details differ. Discuss your analysis with a technical lead or coach.

STEP – Starting with continuous integration

What is the first step? Understand the concept of continuous integration:

EXERCISE
[3 hours] At the start of this talk transcript, Jez Humble points out that most people aren’t doing continuous integration. How does the approach to continuous integration in your team differ to the theory? Talk to a developer to confirm your understanding of your branching strategy, the way you use source control management tools, and how you manage merging to master. If you use a continuous integration tool, create a list of the jobs that are used by your team during development, and be sure that you understand what each one does. Reflect on how quickly your team respond to build failures in these jobs, and who takes ownership for resolving these. Discuss this exercise with a technical lead or coach to collaboratively identify opportunities for improvement, then raise these ideas at your next team retrospective.

STEP – Theory of test automation

Continuous delivery puts a lot of focus on test automation. In order to support development of an effective pipeline it’s important to understand common strategies for automation, and the distinction between checking and testing:

EXERCISE
[1 hour] Read through the automation strategy for your product. How well does your existing strategy for automation support your delivery pipeline? What opportunities exist to improve this strategy? Discuss your thoughts with a technical lead or coach.

STEP – A delivery pipeline

Understand how to construct delivery pipeline and the role of automation:

EXERCISE
[3 hours] Create a visual representation of the current delivery pipeline for your product. Use a timeline format that shows the build jobs in your continuous integration tool at every stage from development through to production deploy, any test jobs that execute automated suites, and points where the tester is hands-on, exploring the product. Compare your pipeline to the simplified images by Yassal Sundman forcontinuous delivery and continuous deployment, then reflect on the following questions:

  1. How would your approach to testing change, or not, if we were able to deploy to production 10 times a day? How about 100 times a day?
  2. Does the coverage provided by your automation give you a degree of comfort or confidence? If not, what needs to change?
  3. Does your automation execute fast enough? How fast do you think it should be? How can you achieve this?
  4. Where in the pipeline would you want to retain hands-on testing? How would you justify this?

Discuss your ideas with a technical lead or coach. Work together to identify actions from your thinking and determine how to proceed in implementing change.

STEP – Non-functional testing in continuous delivery

Learn more about integrating security, performance, and other non-functional testing in a continuous delivery pipeline:

EXERCISE
[2 hours] Does your organisation have a non-functional testing “sandwich”? Having read more about organisations who integrate these activities earlier in the process, what opportunities do you see to improve the way that you work? What would the first steps be? Talk to a technical lead or coach about what you’d like to see change.

STEP – Cross-browser testing

For continuous delivery of a web application, it’s important to include cross-browser testing in the delivery pipeline. Discover strategies for cross-browser testing and the tools available to support it:

EXERCISE
[8 hours] Learn more about the common cross-browser tools that are available, understand the advantages and disadvantages of each option, then select a tool to trial. Create a prototype to execute existing browser-based automation for your product across multiple browsers. If successful on your local environment, attempt to create a prototype job in your continuous integration tool to verify that your chosen solution works as part of your continuous integration. Discuss what you learned about the tool and the results of your experiment with a technical lead or coach.

STEP – Test data & databases

Discover the additional considerations around test data in continuous delivery:

EXERCISES
[1 hour] Data is a constant headache for testers. Consider the limitations of the test data in use by your automation. How could you improve the data within your delivery pipelines? How could you improve the way that you locate data for testing? Talk through your ideas with a technical lead or coach.

STEP – Configuration management & environments

An effective delivery pipeline is supported by multiple test environments. Learn more about configuration management, environments and infrastructure services in continuous delivery:

EXERCISES
[1 hour] Talk to your operations or support team about how they provide test environments for continuous integration, the infrastructure required to support a delivery pipeline, and what their plans are for future changes in this space.

STEP – Testing in production

Understand A/B testing and feature toggles:

EXERCISE
[1 hour] Talk to people in your organisation to find out how you currently use feature toggles and how you make decisions about what to keep based on user analytics. Could your approach be more responsive through targeted use of a monitoring tool like splunk? Share your thoughts with a technical lead or coach.

Announcing NodeJS support for Azure Mobile Apps


via Announcing Node.js support for Azure Mobile Apps | Microsoft Azure Blog.

Last month, we announced significant update to the Mobile Apps feature of Azure App Service, that enabled developers to quickly build mobile backend APIs in .NET, add mobile features to their existing ASP.NET web apps, as well as add web pages to their .NET mobile backends. Today we are releasing a Node SDK for Azure Mobile Apps, extending similar experience to Node.js apps. This enables you to build and run mobile backends using Node.js on App Service, as well as add push notifications, mobile auth, offline sync and other mobile features and backend APIs to any Node.js app running on App Service. This SDK is released as Open Source under the MIT license and we welcome contributions from our community.