FeedHenry

By Evan Shortiss, Intern, FeedHenry Ltd

Recently Google has released it’s new Android Design Guidelines. Apple also provides similar guidelines for iOS developers. These updated guidelines from Google show a strong move to emulate Apple’s success with User Interface (UI) design. It also places a new constraint on developers to ensure their app can appear as native as possible to the device it is running on. Achieving a native UI appearance is important to ensure a positive user experience and ensure that using all apps feels natural and familiar.

Developing an App that is cross platform whilst bearing these design principles in mind can be very time consuming for the developer. It can be time consuming due to differences in both the code base for the different platforms and the challenge of adhering to differing design guidelines. As well as enabling developers to overcome the challenge of differing code bases between mobile devices, the FeedHenry platform also simplifies the task of styling apps for their target platform through the use of packages. Packages are an extremely powerful and simple feature of the FeedHenry Studio and require very little time to understand and more importantly, implement.

So what are packages? Simply put a package is a folder within which a developer can store files to override default functionality or styles. As an intern of less than two weeks here at FeedHenry I’ve had the opportunity to help develop our template that demonstrates the use of packages. Getting a handle on the use of packages is made simple by exploring the Template App, “App Anatomy” in the FeedHenry Studio. By simply changing a single line of text within the Configuration section of the FeedHenry Studio it is possible to totally change the appearance of your app. The screenshot below shows the App Anatomy side by side with different packages applied to determine what style is used.

For more information on using app Anatomy take a look at the tutorial, or to get started, clone this template on GitHub.

By Damian Beresford, Senior Software Engineer, FeedHenry Ltd.

Node.js is an exciting technology that is showing rapid growth and adoption amongst developers since it’s launch in 2009. As the first JavaScript environment specifically designed for server-side execution, Node offers FeedHenry a high degree of efficiency and performance on the AppCloud server-side environment of our Mobile Application Platform. Possibly the most obvious benefit is the design of asynchronous input/output, where code can process other tasks whilst waiting for an operation to complete, rather than being blocked awaiting completion.  This creates a highly efficient and responsive server-side when it comes to building sophisticated mobile apps that require integration with backend systems. For a company like FeedHenry that targets enterprise clients with a complete mobile application solution, Node is the right fit in achieving the level of flexibility and scalability required by enterprise apps.

Equally important is the active Node.js developer community looking to integrate Node to all forms of external environments Node offers a great open source framework for any form of web-based application development and, as such, appeals to sophisticated developers looking for better tools to create real-time high-performance apps.

FeedHenry has had client-side and server-side scripting since it launched its cloud-based Mobile Application Platform in 2008.  The client-side is a HTML5, JavaScript, CSS development environment supporting cross-platform deployment by means of wrapping native mobile device functionality while we use Node.js to support integrated mobile apps for our corporate customer base.

So, what about the cloud and hosting? As part of our Node.js strategy FeedHenry supports a range of Node.js hosting environments, one of which being Cloud Foundry.   We have tested the deployment of server-side Node.js code directly to the public CloudFoundry.com service, managed by VMware, and also to private installations of Cloud Foundry. Additionally we deployed to the Micro Cloud Foundry instance, a freely distributed virtual machine (VM) designed for development and testing purposes. FeedHenry contributed a Node.js library version of the CloudFoundry VMC gem (https://github.com/feedhenry/vmcjs) to make this type of integration task easier for others also using Node.js.  Cloud Foundry is positioning itself as one of the most comprehensive server-side hosting environments available, with a wide range of programming paradigms supported, including Java Spring, Node.js, Ruby both Rails and Sinatra, and other JVM languages/frameworks including Groovy, Grails and Scala. Cloud Foundry also offers MySQL, Redis, and MongoDB data services, as well as RabbitMQ messaging service.

Tapping into the recent trends in flexible virtualization, FeedHenry will also allow Enterprise customers to export their server side application as a Virtual Appliance using the industry standard OVF format (http://www.dmtf.org/standards/ovf). This allows customers to quickly deploy their server side code in any private/hybrid cloud that supports the OVF format, e.g. VMWare, Oracle VM, RedHat, VirtualBox. This should ease the administrative overhead for deployment of a private/public hybrid cloud, with the private part being a OVF image hosted inside an enterprise’s own firewall.  Choosing the open standard for virtualization enables maximum compatibility with enterprise VM environments.

Developing scalable and high performance integrated apps is not trivial but these are qualities increasingly sought after as enterprise apps become more sophisticated and integrate on a number of different levels. While Node.js may not be the solution for everyone, it is pivotal for a platform provider like FeedHenry, where we can vastly improve the efficiency, performance, and scalability of backend or server-side application integration. FeedHenry will soon launch the Node.js environment for all our customers in the three primary public cloud clusters – the North American enterprise cluster; the European enterprise cluster; and the European freemium developer cluster, where developers can sign up for a free account.

However beautiful the strategy, you should occasionally look at the results.

Winston Churchill

What is a mobile strategy and do I need one? With more mobile devices being shipped than any other type of computing platform, combined with the ubiquitous “anytime, anywhere” nature of mobile devices, mobile is fast becoming the biggest channel to market . But typically a company’s first shot at a mobile strategy begins and ends with “lets build an app”.  Would you equate an advertising strategy with just “making an advert”?

A sound mobile strategy must integrate with the company’s overall business strategy – sales, marketing, technology, HR, etc. How many mobile apps have no links to a company’s website? How many websites have no mention of the ability to download an app? How many apps are built without understanding the underlying app objectives and measuring results? Mobile is big but it’s still a sub-component of an overarching company strategy to enthuse and delight both your existing customers and your new prospects.

Within the mobile context you must understand the most compelling vectors for your customers and how to maximise your reach and impact. Your starting point should be the leading mobile smartphone vendors:

- Apple and iOS
- Google and Android
- RIM and BlackBerry OS

The Neilsen numbers speak for themselves:

Within these segments there are two device form factors to consider:

- Phone: Small screen. Touch input (primarily), ability to make phone calls, screen dimensions limited to a device that can be comfortably held in one hand.
- Tablet: Touch input, Larger screen size, no phone calls, typically held in two hands may often come with a hard keyboard.

The final facet of Mobile is the distribution mechanism:

- App Stores : Build and package services in an App for distribution via stores
- Mobile Web : Deliver services via the browser and a web connection

The Mobile web is the bridge linking your mobile strategy to your web strategy (and ultimately your overarching marketing strategy). Forrester tells us that app users are just as likely to use the mobile web as an app and that its not an either/or choice.  Apps should be viewed as a tactic or a tool to facilitate the overall strategy. A mix of weapons is required to win the war.

If we look at HTML5 as the substrate that weaves our strategy together then we can see that an App is just a small piece of that mix.

There is a mobile maturity hierarchy that companies must move through.

Each step up through the maturity curve  must support the levels below in order to succeed fully and on this progressive curve the only game in town for every step is HTML5. Apps are undoubtedly a key element of the strategy but they are only an element. The “best” solution is always a subjective choice. So while the native app purists bemoan the supposedly poor user experience and wax lyrical about “native look and feel” the rest of the world is racing towards a HTML5 user experience that can play both in the app and the browser world.

It’s impossible to ignore the growing adoption and acceptance of HTML5-based app development. Yankee Group just released their 2012 Mobility Predictions where they forecast “HTML5 will cross the Enterprise Tipping Point”, recognizing that “the rise of HTML5 in the enterprise spells the beginning of the end”.

FeedHenry embraced HTML5 in 2008 as the only way to support a comprehensive mobile strategy. While some customers needed convincing to accept HTML5 versus native app development we agree with Yankee that these days are passing. The more enterprises move along the app maturity curve, the more they will reap the rewards of employing HTML5 technologies. App development will be easier, faster, cheaper and more future-proof while maintaining the same user-experience as native apps. Also, we concur with Forrester that Apps + Mobile Web are two sides of the same coin and you need both to confidently deliver a compelling mobile strategy.

Our enterprise customers Aer Lingus, Diageo, O2, Independent News & Media, Health New England and many more support the HTML5 approach. Linkedin and the Financial Times have also embraced HTML5 and many more will follow suit as we prepare to ring in the New Year 2012.

Some boilerplate code for this video is hosted on github.

@cianclarke leads frontend development of mobile apps using Sencha technologies at Feedhenry. This blogpost was originally featured on Cian’s personal site at http://cianclarke.com/blog/?p=79

Traditionally, when creating a multilingual application, language files are bundled within the release of a mobile app. Often, the meaning and context of phrases can become lost in translation, leading to inaccurate information localised apps. To update the language definitions in a traditional app requires a whole new update release of the application to app stores.

Feedhenry resolves this problem. In our Multilingual App tutorial we show how through clever manipulation of the /cloud, /client and /shared directories a cloud connected multilingual app is now possible.

Through use of Feedhenry API functions such as on-device storage, we can have a store of language data on both the phone or tablet device and the cloud. The device polls the cloud for the latest language bundles, and loads these back to the device. It also updates the local storage with the most recent version from the cloud.

In the event that the device is offline, a local copy of the language data is used – always the most recent version from the cloud.

This is a refreshing break from the traditional approach to localization, and introduces a whole host of new options. Developers can stagger the localisation of their application, improve language coverage as adoption increases, and inaccuracies can be amended instantly. All this, without the need for a new release!

There’s plenty of room to expand this – pull the language data from elsewhere on the web, hash and cache the data – for inspiration, take a look at the API Documentation.

Try using the Feedhenry platform to build a multilingual app – fork the template app on github, or read the tutorial.