Category: Tools

Top 5 Tools for Augmented Reality in Mobile Apps

Post author By Katerina Roukounaki
Post date March 16, 2015
No Comments on Top 5 Tools for Augmented Reality in Mobile Apps

Augmented Reality (AR) is about overlaying pieces of a virtual world over the real world (in contrast to Virtual Reality (VR) that is about replacing the real world with a virtual one). On mobile devices, this simply means enhancing what you can see through the device’s camera with multimedia content (e.g. you can point your camera at a movie poster and watch its trailer, or you can point it at a star in the sky and learn its name). So, basically [tweetable]AR comes down to the following three fundamental questions: where to display what and how[/tweetable].

But first: which are YOUR favourite tools? Take the Developer Economics Survey and you could win new, amazing gear.

The where might involve areas like 2-D image matching and tracking, 3-D object matching and tracking, face detection and tracking, SLAM tracking, and location tracking (using GPS, accelerometer, compass, gyroscope). Sometimes the where is nothing more than some predefined point locations, often referred to as Points of Interest (POIs).

On the other hand, the what and the how might leverage 3-D model rendering, animations and gesture detection. In general, the what can be any piece of digital information (e.g. text, image, video) that the user might also have the ability to interact with (e.g. rotate or move it).

Top 5 Tools for Augmented Reality

Let us now present five of the numerous AR tools that exist at the moment and that can be used to develop apps for smart-phones, tablets or even smart-glasses. The following table contains information about the license(s), under which each one of these tools is distributed, and the platforms that it supports.

Product	Company	License	Supported Platforms
ARPA SDKs	Arpa Solutions	Commercial*	Android, iOS (ARPA SDKs), Google Glass (ARPA GLASS SDK), Android, iOS, Windows PC (ARPA Unity Plugin)
ARLab SDKs	ARLab	Commercial	Android, iOS
DroidAR	–	Free and Commercial	Android
Metaio SDK	Metaio	Free and Commercial	Android, iOS, Windows PC, Google Glass, Epson Moverio BT-200, Vuzix M-100, Unity
Vuforia SDK	Qualcomm	Free and Commercial	Android, iOS, Unity
Wikitude SDK	Wikitude GmbH	Commercial*	Android, iOS, Google Glass, Epson Moverio, Vuzix M-100, Optinvent ORA1, PhoneGap, Titanium, Xamarin

* There is also a free trial available.

ARPA SDKs

Image (multi-)detection and (multi-)tracking, 3-D object rendering in real time, as well as user interaction with 3-D objects (e.g. selection, rotation, scaling) are some of the features that ARPA SDK offers for building AR apps on iOS and Android. ARPA GPS SDK complements ARPA SDK with geolocation-based AR functionality: it allows you to define your own POIs that, when detected, the user can select them and get more information about them or even perform actions on them (e.g. the “take-me-there” action that displays a map with directions to the selected POI). ARPA GLASS SDK and ARPA Unity Plugin offer similar functionality with ARPA SDK for Google Glass and the Unity game engine, respectively. It is worth noting that Arpa Solutions, the company behind these SDKs, have over the years developed their own AR platform, some of the features of which (e.g. face recognition and virtual buttons) might at some point be transferred also to the SDKs.

Update Oct 7, 2015: ARPA website has gone offline – their domain name, i.e. arpa-solutions.net seems to have expired.

ARLab SDKs

With AR Browser SDK you can add and remove POIs independently from the scene in real time, interact with them (e.g. touch them or point the camera to them) and perform actions on them (e.g. send SMS or share on Facebook). Image Matching SDK allows you to create your own local matching pool with thousands of images (loaded both from local resources and remote URLs), and use it to match any image without any connection to the internet, while it also supports QR code and barcode recognition. Except for these two SDKs, ARLab will soon launch Object Tracking, Image Tracking and Virtual Button SDKs. All SDKs are available for both Android and iOS.

DroidAR

DroidAR is an open-source framework that adds location-based AR functionality to Android apps. Gesture (e.g. full turn) detection, support for static and animated 3-D objects (using the model loaders from the libGDX game development framework) that the user can interact with (e.g. click on them), and marker detection are part of the functionality that DroidAR offers and that is only shaded by the poor documentation that exists for the project. There is a section on the project README file on GitHub that gives an overview of a closed-source version of DroidAR, DroidAR 2, which seems to have some interesting enhancements compared to its open-source counterpart (e.g. SLAM tracking and a jMonkeyEngine plugin).

Metaio SDK

Metaio SDK supports among others 2-D image, 3-D object, face, SLAM and location tracking, barcode and QR code scanning, continuous visual search (both offline and online through Metaio CVS), and gesture detection. Metaio has also designed their own AR scripting language, AREL (Augmented Reality Experience Language) that allows you to develop your AR apps using common web technologies (HTML5, XML, Javascript) and deploy them everywhere. Metaio SDK can be used to develop AR apps for Android, iOS, Windows PC, Google Glass, Epson Moverio BT-200 and Vuzix M-100 or using Unity.

Vuforia

Multi-target detection, target tracking, virtual buttons, Smart Terrain^TM, and Extended Tracking are some of the features of Vuforia SDK. Vuforia supports the detection of several kinds of targets (e.g. objects, images, English text). Especially for image recognition purposes Vuforia allows apps to use databases that are either local on the device or in the Cloud, The platform is available for Android, iOS and Unity. There is also a version of the SDK for smart glasses (namely Epson Moverio BT-200, Samsung GearVR, and ODG R-6 and R-7) that is currently moving to its beta phase and is open for early access applications from qualified developers.

Wikitude AR SDK

Wikitude AR SDK supports image recognition and tracking, 3-D model rendering and animations (supports only the Wikitude 3-D format), video overlays, location-based tracking and image, text, button, video and HTML augmentations. Wikitude AR SDK is available for Android, iOS, Google Glass, Epson Moverio, Vuzix M-100 and Optinvent ORA1, and as a plugin for PhoneGap, a module for Titanium and a component for Xamarin.

To sum up

There are apps that allow a museum exhibit to tell its own story, that help you decide which furniture looks better in your living room, that bring an elephant you just drew on a piece of paper into life, or that warn you about all the signs you ignored while you were driving. These are examples of already available apps that provide some sort of AR functionality. So, pick one of the AR tools we described above (or one we didn’t, e.g. AndAR, ARmedia SDK, BeyondAR, mixare) and use it to integrate AR in your own apps.

Read more about the differences between AR and VR!

What do you like or hate about these tools? Take the Developer Economics Survey and win new, amazing gear.

Tags 3-D model rendering, augmented reality, mobile apps, SDK

Tools

Comparison of 4 popular JavaScript MV* frameworks (part 2)

Post author By Tobi Borlinghaus
Post date March 5, 2015
No Comments on Comparison of 4 popular JavaScript MV* frameworks (part 2)

In the first part of our JavaScript MV* framework comparison we introduced AngularJS, Ember, Backbone.js and the newcomer React, we showed some code examples and discussed their strengths and weaknesses. In this second part we are going to have a look at their market share, community support and estimated growth to help you make the right decision for your SPA.

Market Study

The following table lists the 4 frameworks alongside the year they were introduced, their origin or enduring dependency, their main contributors and an overview of popular sites using them. It’s worth noting that every single one of these frameworks is run by (or mainly used by) one of the big players of the web:

Ember is used by Yahoo!
Angular powered by Google
Backbone is used to realise WordPress.com and is a part time project of Jeremy Ashkenas, currently employed by the New York Times
React is introduced and powered by Facebook

While the bare listing clearly illustrates project maturity it does not give any indication about general popularity. Stats generated by web crawlers are usually not very accurate when it comes to back-end frameworks, but in our case – where frameworks are client-side and, needless to say, detected by every web client – those stats can be pretty sound.

Comparing wappalyzer.com with similartech.com and builtwith.com we received significantly different results. To display the results in a more convenient way we recalculated the total numbers to relative percentages. According to builtwith.com, React is used 74 times in the TOP 1 million websites while wappalyzer.com detected 18.582 usages in the entire web for the same framework as of this date. Still, it is possible to get a general idea of the market penetration of these Frameworks. All sources show Angular and Backbone being by far the most used frameworks – similartech.com does not even list the other two since their marketshare is too small to bother. Interesting to note that Backbone.js is used more in the Top 1K sites than in the Top 1M sites according to builtwith.com.

For you as a developer it might be more interesting to have a look at the community built around each Framework as it might reflect the amount and speed of support you will find for your upcoming projects. Therefore it is always a good idea to have a brief look at the few occasions where the community activity is shown. Since every project here is listed on GitHub a brief extraction of their stats should be helpful.

Angular was the winner of our part-1 comparison. It’s no surprise to see Angular again as one of the two most popular frameworks. While it almost reaches Backbone’s popularity it surpasses all competitors from the developer community site: Most stars, most contributors, most watchers, most issues (judge yourself if that’s good news), and a large amount of commits. When it comes to this kind of stats the number of git commits since the initial deployment plays a huge role: Ember, for instance, has the most commits. Impressive! But keep in mind: Ember had six more years to collect these commits compared to React. Taking things into perspective, React has more stars (already) than Ember although it is barely out of its childhood compared to the other almost ancient players.

Despite not being visualised here Stackoverflow.com displays Angular in the best possible light as it counts more than the double amount of posts than Backbone and Ember together and over 65 times more than React!

We do realise this is a snapshot in time and might well be outdated by the time you read this post. Which leads to the following question: Which of those frameworks is worth investing in the (near) future? The question is especially relevant for React as its popular contributor Facebook is well-known for the ability to establish new technologies, be it software (Hadoop) or hardware (open compute). Are we close to witness a new star rising on the MV* Framework horizon?

Google Trends has always been a faithful companion to get an idea of how popular a topic is and, by looking at the development over time, how popular it might be in the future. While different search terms around the same topic might bring different results, you can still get a general idea for each framework. The fact that these terms appear around the same time the frameworks were introduced proves our point as being representative, at least to some extent.

What this graph for sure does is manifesting Angular as the most popular Framework. Moreover, fascinating to note, Backbone’s popularity seems to be stabilized or even decreasing over time. Same can be said by looking at Ember. Are they already over their peak and now losing momentum? While Backbone’s market penetration might already be too deep to just disappear from the market, fate seems uncertain for Ember.

No doubt, the most astonishing trend is React’s. While writing this blogpost, we had to rewrite this section three times in two months:

December 2014: Backbone and Ember are closely followed by React. =>Respect!
January 2015: React catching up and passing by its competitors. => Impressive!
February 2015 (partial data!): React’s popularity outruns Backbone and Ember by far and is the runner-up to Angular. => Speechless!

According to Google Trends, React has risen from zero to a fourth of Angulars popularity within 1.5 years without showing any kind of flattening of their popularity curve. If React keeps up its progress we might see a new rival of the popular Angular at least as far as the View component of the MV* frameworks is concerned.

Tags angular, backbone, ember, javascript, react

Tools

21 tools behind the success of King and Halfbrick Studios

Post author By Dimitris Michalakos
Post date February 25, 2015
No Comments on 21 tools behind the success of King and Halfbrick Studios

King and Halfbrick Studios are some of the most successful mobile game developers. Their best-selling games, i.e. Candy Crash Saga (King) and Fruit Ninja (Halfbrick), rate in the 100M – 500M download tier on Google Play and rank among the Top 100 on iTunes. Did you ever wonder which tools they use and how they compare? Do they use the same SDKs available to the rest of us mortal developers and what can we learn from their tooling choices?

We analysed 39 apps (iOS and Android) from King.com and Halfbrick Studios to determine which SDKs they are using and what tools makes them tick. We ‘ve broken down the results by tool sector for easier comparison. Note our analysis technology is still in beta, so let us know how we can improve it.

	Halfbrick Studios	King
Ad networks and exchanges	Google Ads Apple iAd InMobi Native Ads Platform Millennial Media MoPub Vungle	Google Ads Apple iAd
Game development	Apple GameKit Amazon Game Circle Google Play Games Services	Apple GameKit Google Play Games Services
MV* frameworks	Angular
Crash analytics and bug tracking	ACRA	ACRA Crittercism
User analytics	Google Analytics Kontagent
App monetization	Amazon In-App Purchasing Google Play In-app Billing Google Wallet	Amazon In-App Purchasing Google Play In-app Billing Google Wallet
Social Tools	Facebook Google+ Twitter4J	Facebook Google+ KakaoTalk

Let’s consider these tooling choices one sector at a time.

1. Ad networks and exchanges

Starting with Ad Networks, you can tell HalfBrick Studios employs a handful of tools, while King uses only the major networks of each platform, i.e. Google Ads (Android) and Apple iAd (iOS). This is indicative of the reliance of the two companies on ad revenues. King has long abandoned advertising as a revenue source with a clearer focus on in-app purchases.

Bear in mind it is quite common for app developers to use multiple ad networks. If demand is not met by the first network’s supply, you move to the next network and so forth until you find a medium to display. That is why Halfbrick Studios uses multiple ad networks, and indeed they have chosen high performance networks.

2. MV* frameworks

Halfbrick Studios using AngularJS, a popular JavaScript MV* framework, might strike as a surprise. What does JavaScript have to do with Fruit Ninja and Jetpack Joyride? Digging a bit deeper we discover Halfbrick is using web technologies to implement BrickNet – a service that allows transfer of scores and saves across multiple devices. The BrickNet service is bundled with all the company games we examined.

This strikes another chord: there has been a lot of talking on how web technologies are not suitable for mobile apps due to mainly performance reasons. Well, this case is a testament that technologies are not good or bad per se – it all depends on the use case.

3. User analytics

Regarding user analytics, we were unable to detect any SDKs on King’s games. They could be using a custom in-house solution, or an unknown-to-us tool.

Halfbrick Studio uses the notorious Google Analytics in combination with Kontagent (rebranded as Upsight), which is better positioned for mobile games. The takeaway here is that the most popular tool of the category, i.e. Google Analytics, works perfectly for top as well as indie developers. [tweetable]The difference is in not in which tool you use, but how you use that tool[/tweetable], i.e. how do you interpret the analytics data and use it to grow your company.

4. Social tools

While Halfbrick Studios uses all the popular western social networks, King is more picky. They don’t seem to like Twitter, at least on the apps we found in the US stores. They do however use KakaoTalk on the iOS version.

Anything we missed?

So, this wraps it up. What did you learn from the tooling choices of King and Halfbrick studios? Is there anything we missed? Want to see more of these tooling deep dives? Leave a comment below and let us know.

Tags app business, Business models, developer tools

Languages Platforms Tools

Comparison of 4 popular JavaScript MV* frameworks (part 1)

Post author By Tobi Borlinghaus
Post date January 29, 2015
No Comments on Comparison of 4 popular JavaScript MV* frameworks (part 1)

Finding a comprehensive comparison between any kind of JavaScript Frameworks, Libraries or Extensions is not hard these days. Especially when it comes to JavaScript MV* Frameworks, which are used to develop single-page applications (SPAs), and their notorious representatives, i.e. AngularJS, Ember, Backbone.js and newcomer React. A simple Google Search offers a plethora of technical comparisons to choose from.

Which are your favorite and worst frameworks? Take the survey, let us know and you can win awesome prizes and gear.

What they don’t usually mention, though, is the overall features those frameworks provide and how they compete for different use cases. Moreover, it is sometimes difficult, if not impossible, to find information on the origins of those Frameworks, i.e. how they have developed in time and, most importantly, how they will develop in the future.

This article is part 1 in a 2-part series, and will focus on comparing key features from some of the leading JavaScript MV*frameworks. In part 2, we’ll give you some insight on market-related qualities, followed by a conclusion.

Features Comparison

To get our comparison started, we will focus on the heavy-weight and most promising features you, as a developer, expect from a JavaScript MV* Framework.

Dynamic UI Binding

Dynamic UI Binding is not just passing data to our View or template at page load. You want to automatically have the View update when the data of the underlying Model changes. That being said, you may want to have a look at the following jsfiddle examples to get an idea of the huge improvement provided by dynamic UI binding over traditional server-side static data binding.

Ember.js:

Ember uses Handlebars as the default templating engine. To update a value, which is bound to the UI, you have to use a specific setter method on your Model while Handlebars takes care of rendering your page. Additionally, Ember offers much more binding options, such as its capability to have your Model in either a one or a two-way binding mode between a View or even another Model.

Angular.js:

In contrast with Ember’s approach, Angular.js allows you to use UI binding at plain object or even property level. At the end of every code execution, $scope.$apply() is run to check whether the value has changed and calls $scope.digest() to update your bindings. This may seem like a possible performance issue at first glance, but bear in mind that it allows you to update more than one binding simultaneously without requiring time-consuming DOM updates after each setter call. So the DOM rendering is triggered only once after you updated as many of the Model’s properties as you wish rather than being triggered after every single value change, like in Ember’s setter approach. Having all the magic happen in $scope.$digest() you don’t need to call your UI-Binding-Buddy yourself and even the $scope.apply() call is handled by Angular automatically (e.g. after events, controller init, http callback, etc).

React:

One of React’s rich UI Features is the straightforward linking of states directly to the UI. Since the UI is thought of as the representation of different states of a React Component, you just have to manage your states with the magical #setState(state, callback) method. The state parameter is passed as an object and will be merged into the internal state reference of your React Component. Meanwhile, React takes care of all the updating and re-rendering of your interface using the render method. The callback parameter from setState is optional and can be registered so you are informed after the UI update.

Reusable Components

While all frameworks provide out-of-the-box functionality, you will inevitably end up with a lot of custom code. Assuming you are developing more than one applications, you would like to be able to reuse that code, right?

Ember.js:
Ember is making use of a widget-based approach called Ember Components. It enables you to write your own ‘application-specific HTML tags’ using a Handlebars layout and the power of Ember’s backend infrastructure. Your custom element can be used in any Handlebars template you want. Keep in mind, though, that this is only possible at View level, while Controller level reuse is not supported by the Framework.

Angular.js:
Similar to Ember, Angular.js provides the ability to create custom HTML tags. Reusable components in Angular are called “directives” and are significantly more powerful than Ember Components. In fact, you will be able to create your own semantic and reusable HTML syntax using those directives. On the other hand, you may also make use of Angular’s extend or mixin system like in Backbone.js and React.

Backbone.js and React:
The way Backbone.js and React solve reusable components is not new, yet it is very reliable. They both use the mixin system for code reuse. You may know this feature already from the dojo toolkit and might remember how powerful mixins can be. Both Backbone and React let you use mixins at view or even controller level, so that your components are not forced to be UI-related and may contain just some utilities or even complex program logic.

Routing

The simplest routing infrastructure a MV* JavaScript Framework can offer is mapping functions to URLs, similar to their server-side relatives (e.g. Grails, Spring, ASP.NET, CodeIgniter). For Single Page Applications (SPAs) a URL is whatever follows the hashtag (or might even be full path assuming HTML5 push-state is enabled). This routing functionality is essential for any self-respecting SPA.

Ember.js:

The routing in Ember.js is quite intuitive, since you do not even need to provide a path for your route, as long as you follow the naming convention. You just provide the View and an optional Model to the route and there is no need for any kind of controller (as exhibited in the Fiddle above), unless you are planning to do some advanced stuff in your application.

Angular.js:

In contrast to Ember’s convention-over-configuration routing mechanism, Angular.js requires a template and even a controller to its router configuration. You have to manage your template and controller manually – but you can do that almost without restrictions.

Backbone.js:

Similar to Angular.js you provide a View with a Template for your route. The actual replacement of the DOM is done manually by instantiating the View and updating the DOM in your container node with the rendered view template. At the end of your routing configuration you just have to tell Backbone to listen for URL changes with the command Backbone.history.start().

Pit Stop – Concluding the Feature Comparison

It is quite unfair to compare React with the likes of Ember, Backbone and Angular. First and foremost, React is new, while the latter are already established frameworks in the MV* universe. Secondly, React is not a framework, but rather a View engine – even though it competes extremely well in terms of features. In fact Facebook explains it better: “React is mostly used as the V in MVC”.

Let’s look again at our JavaScript MV* candidates.

Backbone doesn’t provide UI binding and does a really good job at reusable, components but loses some of its fanciness when it comes to Routing. Ember offers a slick routing mechanism, keeping things clean and simple by introducing naming conventions. Its UI Binding concept and use of Handlebars, which provides you with very nice benefits, is flawless. The only thing Ember lacks is the reuse of components at Controller level.

To conclude, Angular is our winner – so far. The approach of extending HTML with custom syntax, the easy-to-use data binding features combined with the power of mixins or extends and a clear routing mechanism makes Angular more than just a swiss JS-Knife. With its high abstraction level and a bunch of features it may be the choice for a full featured CRUD application – client sided.

Stay tuned to find out more about how our rivals compete in market penetration, community support, their estimated future usage and, of course, our final conclusion to help you back the right horse for your SPA.

In the meantime, tell us more about what you love or hate for each framework and you might win cool gear. Take the Developer Economics Survey.

Tags angular, backbone, ember, javascript, react

Tools

Go ahead and add that extra ad library, but be careful about which one you add

Post author By Meiyappan Nagappan
Post date January 20, 2015
No Comments on Go ahead and add that extra ad library, but be careful about which one you add

In our case study we started with a set of 236,245 free to download Android apps from the Google Play store mined in 2011. Overall we found that the apps connected to 72 different ad networks through the respective libraries. In all there were three key findings in our study:

Finding 1: Developers integrated more than one ad library quite frequently.

Fig 1. Number of apps (y-axis) that have a particular number of ad libraries (x-axis).

We find that most apps have only one ad library in them. However, at least 42,206 of the apps with ad libraries in them have two or more ad libraries. Fig. 1 shows a breakdown of the number of apps based on the number of ad libraries integrated in the apps. We even find eight apps with as much as 28 ad libraries!!

Finding 2: We found no evidence of a relationship between the number of ad libraries and the user rating of an app.

Fig 2. Bean plot of apps with a specific number of ad libraries and their user rating. The long dotted line and the line across each beanplot represent the median rating of all the apps and the median rating of the apps that integrate a particular number of ad libraries, respectively.

In Fig. 2 we break down the data and show more details by means of a bean plot of the rating of apps grouped by the number of integrated ad libraries. Bean plots show both the median value for the rating (indicated by the solid horizontal line), and the actual distribution (the width of the curve at any point in each bean plot indicates the number of apps with a particular rating). Since app ratings can be biased by a few raters, in the above Figure and the rest of the study, we filtered out apps with less than 10 raters and fewer than 2 releases in an entire year (unmaintained apps), which resulted in a set of 13,983 versions distributed across 5,937 different apps.

The Spearman rank correlation (correlation among the relative ranks rather than the actual values) between the number of ad libraries integrated in an app and the rating of the app is 0.016. Such a weak correlation illustrates that there is no relationship between the number of ad libraries in an app and the rating of the app.

Finding 3: Apps that integrated certain specific ad libraries had a noticeably lower ratings.

Fig 3. Bean plot of apps that integrate a specific ad library and their user rating. The long dotted line and the line across each beanplot represent the median rating of all the apps and the median rating of the apps that integrate a particular ad library, respectively.

We observe that ad libraries with a highly intrusive behaviour result in complaints from app users, and in some occasions ruin the users’ perceived quality of the app. We find comments such as: “Good game, bad ads. I was loving the game until I noticed it put a new shortcut called ‘Apps’ on my launcher. Sorry, but if your idea of advertising is putting sh*t in launcher pages or notifications then I’m not interested. Keep ads INSIDE the app.”. At the time of our study, apps that included Wooboo, Leadbolt and Airpush all had lower ratings. We found that these ad libraries had an intrusive behaviour (as explained in more detail in our paper). Recently, Google Play updated its policies to encourage the app developers to be more conscious with ad libraries that have highly intrusive behaviour. They also updated their ad policy in mobile apps which has forced ad libraries to either change or risk not being included.

Recommendation

Given a certain real estate space that the ads will occupy on the screen of a device (control variable), app developers can add as many ad libraries as needed to increase the fill rate (ratio of number of ads received to the number of ads requested) without impacting their ratings. However, developers need to be careful and selective about the specific ad libraries that they integrate.

You can find more details about the case study in our paper published in the Nov-Dec 2014 issue of IEEE Software. (Preprint)

Tags ad networks, app ratings

Tools

Are prototyping tools becoming essential?

Post author By Mark Wilcox
Post date January 13, 2015
No Comments on Are prototyping tools becoming essential?

How do you design the UI for a new app or feature? Good old fashioned pencil and paper? Photoshop or Sketch? Perhaps a wireframing tool like Balsamiq? Maybe you build clickable mockups or fully interactive prototypes? However you go about it, using prototyping tools to get some feedback on a design before it’s fully coded is a great way to save time and effort.

When building an app for a client, they’re usually a lot happier if they can see and touch what they’ll be getting before it’s built. For your own apps, being able to rapidly iterate on the design with prototypes can get you to market with a quality product much faster. There’s been a lot of activity in the prototyping tools space over the last year or two, providing a variety of ways to build brilliant prototypes. In this post we’ll look at some of the most interesting and promising ones.

Animation era

In iOS 7 Apple made a major change to their UI design. The old realistic textures and skeuomorphic design elements were out and flatter, cleaner look was in. Many of the hints at what interface elements were for, or affordances in designer-speak, are now gone – replaced by animations that make it clear what’s happening as you start to interact with the interface. This arguably makes it harder for complete beginners to discover functionality but also makes it easier to understand what’s happening and how apps work. Well designed animations can delight and surprise, making the whole experience more engaging. The danger here is that developers building custom UIs in a similar style can mimic the look of the new UI without adding the animations. This effectively takes away almost everything that helps a user learn how to interact with the app. [tweetable]Animation became essential to a good UI design[/tweetable]. At the time there were almost no tools for designers to help them create or communicate this aspect of the user experience – developers largely had to add these animations in code and tweak parameters across many slow and painful iterations to get them right.

In the Android 5.0 update last year, Google has also adopted a much more minimalist UI style – they’ve called it Material Design. Here also, animation is a core part of the user experience; this is made very explicit in their design guide. Fortunately we’re now in a much better place in terms of tooling to design and prototype these animations. Which tools you’ll want to use is likely to depend on your current process, what sort of app you’re building and what level of fidelity you want to achieve in the prototype.

Exploring ideas

If you primarily want to create a prototype to explore an app idea or communicate about one, then it’s hard to beat the efficiency of pencil sketch on paper. That’s fine for showing a basic app layout but what if you want to explore interactions. Prott lets you capture your sketches and turn them into interactive prototypes that are fully tappable, along with custom gestures and transition animations. The tool also has collaboration functionality built in.

For those who prefer to start sketching out their ideas in a digital form but want a low-cost and low-effort way to add some basic interaction and animation, Apple gave us a peek at part of their prototyping process in one of the talks at WWDC (video requires developer login and Safari). They use Keynote! Creating slides with the dimensions of a device screen and animating from one to the next (particularly the “Magic Move” animation) allows for a surprising amount of sophistication. Since there’s a Keynote app for iOS devices too, you can actually preview the designs on the device. The major restriction here is that you can’t tap different areas to cause different actions – tapping anywhere transitions to the next slide, so you have to prototype individual flows through the app rather than the whole thing.

If you’re only designing for iOS and only want to use standard UI elements and screen transitions, then a fun alternative for exploring new ideas on the go is AppCooker. This is an iPad app for designing iPhone and iPad apps. It’s necessarily limited compared to many desktop tools but still very capable. There’s no custom animation support here though and while you can import images, it’s not really suited to designing a custom UI.

High fidelity prototypes without code

The majority of designers have limited coding skills. Being able to create a basic page layout and style it with HTML and CSS is an excellent start but it doesn’t get you to a place where you can easily build screen transitions or custom animations. Professional animators have almost always had tools that didn’t require coding but there was nothing for app designers. Facebook started using Apple’s Quartz Composer, a motion graphics tool, for prototyping. They built a toolkit on top of it for prototyping apps and released it for free as Origami. This is a highly capable toolset but since it wasn’t originally built for for designing apps it’s somewhat complex and difficult to learn and use. Quartz Composer itself is also not very actively maintained or stable.

For anyone that wants a similar tool to Origami that’s easier to use there are a couple of excellent new options. If a complete freedom is what you want then Form is an excellent option. It was released by RelativeWave as a paid tool but then rapidly acquired by Google and made free. They initially launched for iOS only with plans announced to also support Android. With the tool in Google’s hands we can assume that Android support will come quickly. Like Origami, Form provides a node and graph based visual programming environment. They also have a viewer app so you can preview the design on as many devices as you like and it updates automatically as you make changes.

If you want to build prototypes that look and feel just like native apps using the built-in OS frameworks then Pixate is definitely worth checking out. It lets you build iOS and Android prototypes that use the native UI components directly. You can add your own custom styling and animations in a visual programming environment. The Pixate team are currently working on direct import functionality from Photoshop and Sketch, so it can be added seamlessly to existing static design workflows. They’re also planning to add native code export, so that when a design is complete, the native code generated for it can be used as the basis for the final app UI. Generated code doesn’t have a great history of being maintainable but if they can pull it off it would be a killer feature.

EDIT: Just after this was published, Pixate added a free tier that lets you use all of their features for 1 app.

HTML5-based solutions

There are lot of prototyping solutions on the market that involve building app UIs with HTML5. Some of them are for custom designs and others provide libraries of native component clones. Some do both but very few provide a good level of support for custom animation. A couple of interesting exceptions are Proto.io and Framer.

Proto.io is another non-coding solution which also has collaboration features, allowing you to get feedback from your team or a client. Unlike most of the tools on the market, it has a library of Windows Phone components as well as those for iOS and Android. You can test on real devices and export the final HTML5, which could be useful as the basis for a hybrid app, or just as a guide for the developers. It is a fairly expensive subscription solution compared to most of the others but would clearly produce an excellent impression in a consulting and contract development environment.

For designers that know their way around JavaScript (or CoffeeScript), developers with some design skills or those rare unicorns – true designer/developer hybrids – Framer is one of the most interesting options out there. Framer already has direct imports from Photoshop and Sketch and focuses on rapid iteration, including live device previews. If you do a lot of design work and iterating quickly is a key goal then Framer might be the tool to beat. The underlying prototyping framework, framer.js, is open source and could be used independently but a lot of the productivity boosting features are in the paid Framer Studio tool.

What about functional prototypes?

What if your prototype needs to do more than just look and feel like the final app? Some app concepts can only really be understood and tested with live data or working features like using the device camera. Depending on the level of complexity it may even be possible to prototype these too. One option would be to hook up the output of an HTML5 prototyping tool to some real device functionality in a hybrid app. Another option is to build a fully functional prototype in a rapid application development tool like LiveCode. Although there may be areas where performance or functionality are lacking compared to building a native app, LiveCode has a visual UI design environment and good animation capabilities. It also makes it very quick and easy to add a database of real data or mobile specific features. When you get to this level of prototyping complexity, it starts to get time consuming and costly to build the prototype. It may make sense to only prototype parts of an application in this way, where it’s critical to get the design right before a very lengthy and expensive coding phase.

Consider prototyping your next app in more detail

[tweetable]The most common problem in software projects is not the technical execution[/tweetable], although that often takes longer than expected. By far the most common reason for app projects to fail is building the wrong thing. Although on the surface building a prototype only to throw it away might seem like wasted effort, it can massively reduce the risk of much more effort going to waste building something either the client doesn’t want or insufficient customers are willing to pay for. Prototyping the UI and putting it in the hands of clients or potential customers in a real device is one of the best possible ways of getting concrete, actionable feedback. Pick one of these tools, or find another that suits you better and give it a try with your next app. If you’re already a prototyping convert and we haven’t listed your favourite tool here then let us know in the comments.

Tags animated prototype, animation, prototype, prototyping tools

Tools

Popular ICEs for mobile hybrid app development

Post author By Katerina Roukounaki
Post date November 24, 2014
No Comments on Popular ICEs for mobile hybrid app development

If you want to target multiple mobile platforms without having to maintain a separate code base for each one of them, mobile hybrid apps is one way to go. What mobile hybrid apps won’t do, though, is relieve you of the need to manage and use multiple tools, e.g. building your app for a specific mobile platform requires installing the platform’s native SDK on your machine.

ICEs are here to take this headache away. ICE stands for Integrated Cloud Environment and it’s essentially an IDE that does some of its work in the Cloud. A typical ICE for mobile hybrid app development provides you with tools to design, write, test, debug and profile your app. It also allows you to configure the build settings of your app, manage its signing keys and compile it for various platforms.

[tweetable]One of the most popular features of ICEs is building your app in the Cloud[/tweetable] – they grab your code, upload it to the Cloud, build it and come back with the produced app bundle(s). Since the build process no longer takes place on your machine, there is no need for you to install any native SDKs. Apart from building, ICEs may also use the Cloud for storing your app or for pushing it to a device for testing purposes.

A mobile hybrid app development ICE traditionally comes with a companion mobile app that can be downloaded for free from all major app stores. This companion app acts as a container for your own app (your app runs inside it, so you not need to install the former on the device) and also provides some extra functionality (e.g. checking for new builds of your app).

So, here are four of the most popular ICEs for mobile hybrid app development (PhoneGap Build is not really an ICE as we’ll explain later on). But before diving into the details, the following tables provide a handy overview of these tools.

Tool	Owner	Free?	Type
AppBuilder	Telerik	No	Desktop-based (Microsoft Windows), Browser-based
Intel XDK	Intel Corporation	Yes	Desktop-based (Microsoft Windows, Ubuntu Linux, Apple OS X)
Monaca	Asial Corporation	Yes *	Browser-based
PhoneGap Build	Adobe	Yes *	Browser-based

* A free subscription plan is offered (among others).

	AppBuilder	Intel XDK	Monaca	PhoneGap Build
Code editor	✔	✔	✔	✘
Drag-and-drop tool(s)	✔	✔	✔	✘
Source version control	✔	✘	✘	✔
Collaboration	✔	✘	✔	✔
Device simulator	✔	✔	✘	✘
On-device debugging	✔	✔	✔	✔
On-device profiling	✘	✔	✘	✘
Builds	✔	✔	✔	✔
Companion app	✔	✔	✔	✘

AppBuilder

With AppBuilder (previously known as Icenium) you can develop your app in collaboration with other members of your team, using both a code editor and a drag-and-drop tool (experimental and limited to apps that use Kendo UI).

AppBuilder allows you to test your app on a built-in device simulator, on native emulators installed on your machine, as well as on real devices (both connected and remote). In the case of real devices, you can either install your app or run it inside the AppBuilder companion app.

While your app runs on the simulator or on a connected device, you can debug it using the bundled debugger that’s based on Web Inspector. AppBuilder also allows you to automatically reload your app as you make any changes to its source code.

❢ AppBuilder offers Cloud-based storage and version control for your apps.

Intel XDK

Intel XDK contains a bundle of tools: a code editor that is based on Brackets, two drag-and-drop tools that help you design your user interface (one supports App Framework, Bootstrap, jQuery Mobile and Topcoat, while the other is limited to App Framework), and a device simulator that is based on Apache Ripple.

In addition, Intel XDK allows you to test your app on real devices that are connected to your machine or are in the same wireless network as your machine. In both cases, you need to have App Preview (Intel XDK’s companion app) installed on your device. Similarly to Telerik’s AppBuilder, Intel XDK automatically reloads your app (if you’re using an Android handset) as soon as you make changes to the source code.

With Intel XDK you can also debug and profile a running app. On the device simulator you can use a debugger that is based on Chrome Developer Tools (CDT). On a real connected Android device (with both App Preview and App Preview Crosswalk installed on it), you can use weinre (WEb INspector REmote) and a built-in profiler that helps you identify hot-spots in your Javascript code.

❢ Intel XDK supports live layout editing. While your app is running on a connected Android or iOS device, you can preview the result of the changes you make to your HTML and CSS files as soon as you hit save.

Monaca

Monaca allows you to collaborate with other testers and developers on developing your app. You can chat with them as you write code, and share your thoughts, as well as screenshots of your running app, while debugging it on a real device.

With Monaca, you can preview your app in a browser (with different device screen sizes and orientations) or run it on real devices inside Monaca Debugger (the companion app of Monaca). In both cases your app gets automatically reloaded every time you make changes to the code and save them.

You can debug your application in preview mode, using the debugger that comes with your browser. Alternatively you can debug on a real device, using Monaca Debug Panel, a tool based on Web Inspector. Some debugging features are also available on the real device; for example, you can view the source of the current page or inspect the application log.

❢ Monaca stores your code in the Cloud, and you can access it at any time and from any place using WebDAV.

PhoneGap Build

PhoneGap Build is not really an ICE, but rather a build service that works in the Cloud. It pulls the source code of your app from either a .zip file or a (private or public) Git repository, and then allows you select the platforms you want to build your app on. Throughout the building and testing process, PhoneGap Build enables you to collaborate with testers and developers from your team.

PhoneGap Build allows you to build debug-enabled and/or “hydrated” versions of your app. With debug-enabled builds you can remotely debug your app using weinre, whereas new hydrated builds can be automatically pushed to the devices and replace older ones.

❢ PhoneGap Build does not store the passwords for your signing keys for more than one hour since the last time you used them.

To sum up

Mobile hybrid apps allow you to target multiple mobile platforms with less code, in less time, and with fewer programming languages. ICEs for mobile hybrid app development move parts of the development process in the Cloud (e.g. they build your app there), thereby adding one more benefit to the above list: fewer tools.

There are several reasons for trying out an ICE – the choices differ according to what you’re trying to achieve. If you enjoy writing code on the Web, you can use Monaca, while if you want to spend less time on writing code, AppBuilder’s and Intel XDK’s drag-and-drop tools might make your life easier. Keep in mind that using an ICE does not require abandoning your current editor or IDE – you can use any editor or IDE you like and then import your code into an ICE to test, debug or build your project. Finally, there are some cool features in this post that might have caught your eye – e.g. Intel XDK’s remote profiler or Monaca’s collaboration tools. So, get started with an ICE – and let us know what you think!

Update Dec 15, 2014: Monaca kindly informed us they also provide full debugging functionality via USB, using Chrome on Android and Safari on iOS devices.

Tags hybrid apps, integrated cloud environment, mobile platform

Tools

Why Developers Should Embrace User Analytics

Post author By Mark Wilcox
Post date September 23, 2014
No Comments on Why Developers Should Embrace User Analytics

In our latest Developer Economics survey we were really surprised to see a dramatic fall in the level of adoption of User Analytics tools. A year ago they were the most popular category of third party tool with 38% of mobile developers telling us they used them. This time, only 21% of developers said the same thing. Why has there been such a significant drop? Are the hordes of new developers flocking to mobile just unaware of what’s available? Is all analytics being tainted by the spying scandals? Why does it matter?

The new mobile developer tsunami

At WWDC this June, Apple said that they’d gained almost 50% more developers in the last year. The vast majority of those will be iOS developers (rather than OS X and Safari). Android has been growing even faster in terms of new apps, so it’s likely there was even greater growth in the mobile developer population there. Windows Phone also saw significant growth in developer adoption. With so many new developers getting started building mobile apps we’d expect that they’re not all aware of the tools available to help. However, the reduction in user analytics adoption was greater than for other tools, indeed some tools categories saw increased adoption. So, although lack of awareness is clearly a contributing factor it’s not the whole story.

Tracking behaviours, not people

Information on government spying activities leaked by Edward Snowden has turned sentiment amongst many of the technically aware against digital surveillance. Perhaps some developers feel they shouldn’t be spying on their users’ actions? [tweetable]Does adding analytics to your app violate user privacy? Not usually.[/tweetable] User analytics tools are primarily for examining correlations between user behaviours and changes in the product or its marketing. If you make changes to a sign-up screen you need to see if it improves the fraction of users who sign up. If you’re trying to convert free users into paying users, it’s vital to analyse which changes in design or pricing result in greater revenues. Even to improve a paid up front or entirely free app, understanding what users do when they’re using it is incredibly valuable. As long as you’re not collecting personally identifying data and associating it with activity then it’s hard to see this as spying. Even segmenting users for behavioural targeting of functionality or advertising seems harmless as long as they’re anonymous. When analytics providers aggregate data across apps to build up user profiles for advertising, that may cross the creepy line for some. If this bothers you then choose an analytics provider appropriately, or collect your own data. If it doesn’t then having a privacy policy that clearly states who sees what data and what it’s used for is the responsible thing to do.

Coding blind

[tweetable]Updating and iterating on apps without analytics is apparently incredibly common[/tweetable]. It’s unlikely that all of these developers are regularly running user testing panels to get detailed feedback. Is everyone coding blind? To avoid constant app updates which would annoy users (and not even be possible with the review cycle on iOS) developers need to include multiple changes in every new version. If user sign-ups or revenue goes down after an update, how can you tell what went wrong? If things improve, which changes helped? Which parts of your app do people use the most? Are you working on improving features that no-one is using anyway? Without some kind of analytics, how do you find the answers to these questions? Might you be wasting a lot of effort?

Just integrating a third party analytics tool isn’t enough to answer these questions either. Apps need to be instrumented to log analytics events for every major action in the application and how long users spend on various activities. Beyond that, to really understand the effects of changes, users need to be analysed as cohorts – groups that started using the app around the same time. The value of an app to its users may increase or decrease over time and users who have got used to a UI are more likely to be unhappy with any changes. For an app that’s just starting to grow a user base, a change that causes it to lose 10% of existing users might still be positive if it increases revenues from new users. To know the real effects of some changes, it’s necessary to analyse specific sets of events as funnels. For example, in a registration or purchase process, increasing the number of people that start the process is no good if the number that end up completing it is reduced because they feel misled.

Tool choices

Developers that decide to embrace analytics have a lot of choices, however, the market is quite polarised. By far the most popular tools are Google Analytics and Flurry. These are (mostly) free. Google Analytics has the advantage with Android developers because it is integrated with Google Play, allowing direct tracking through the acquisition and download process into usage. It does have a (very high) limit on usage. If your app gets incredibly successful you’ll have to use the premium tier, which has a flat annual fee of $150k. Flurry on the other hand is free at every scale, although not as advanced as Google Analytics in terms of segmentation, funnels and visualisation of data. Both services are collecting data across apps, effectively to sell to advertisers.

There’s also a premium-only market with better support for cohort analysis, funnels, segmentation and visualisation. Paid offerings also link the analytics direct to actions, allowing automated real-time messaging to users, or the sending of push notifications to specific groups. Mixpanel and Localytics are two examples of tools in this space. These premium tools are also designed to be a lot more usable by non-technical staff, allowing a marketing team to analyse and react to analytics without always needing help from the development team. These tools have a fairly low user or datapoint count for a free tier and then start charging hundreds of dollars per month for successful apps. However, this means that they don’t sell the data from your app to anyone else.

A third option is the relatively little known Amazon Mobile Analytics solution. So far it’s relatively basic on the analysis front and doesn’t have the prettiest interface. However, you can collect 100 million events per month for free and beyond the free tier it’s just $1 per million events. By contrast, Mixpanel charge $2,000 per month for 20 million events. Amazon don’t share your data with anyone or report on it (no word on whether they use it internally for their own purposes).

Give it a try

Thinking about your apps as places to experiment and measure how the users react takes a change of mindset. If you’re not just building apps for fun then this shift can make a massive difference to your success.

If you’ve had a major change in results because of something you discovered using analytics, share your story with us in the comments.

Tags A/B Testing, Analytics, performance

Tools

Top Game Development Tools: Pros and Cons

Post author By Mark Wilcox
Post date September 16, 2014
No Comments on Top Game Development Tools: Pros and Cons

According to our survey, a surprisingly high [tweetable]29% of games developers are primarily building their apps without a third party engine[/tweetable]*. They have either written their own engines, or are building everything from scratch. Large games studios very often build their own engines and tools, or customise open source solutions to suit their own internal processes and workflow. However, two of the most popular developer segments going for this option are Hobbyists and Explorers. It doesn’t make much sense for part-time game developers, or even small studios, to spend a lot of time working on their own tools rather than building games. In this post I’ll take a look at some of the most popular tools they could be using instead.

Which are your favourite tools for games development? Let us know in our new Developer Economics Survey and you might win an Occulus Rift Pro and other hot prizes.

Unity – the people’s champion!

As developer tools go, Unity is incredibly successful. A massive [tweetable]47% of developers in our survey use Unity for some of their projects and 29% use it as their primary development tool[/tweetable]. This is not just Hobbyists taking advantage of the free licensing options, Unity is more popular with professionals in general and most popular with the Hunters (53% of them) who are trying to earn their living from the app stores.

Unity supports both 2D & 3D game development, which is quite unusual for a game engine. That said, Unity was really designed for 3D games with 2D support bolted on afterwards; the 2D features were initially just for building menus and other 2D screens needed in a 3D game, to avoid the need for an external tool. The features were quite generic and developers started building games with them; probably due to the broad cross-platform support. To their credit, Unity have supported this and continue to invest in the area.

Supported languages

Three development languages are officially supported: C#, UnityScript (basically JavaScript with type annotations) and Boo. The last of these, Boo is not widely used and probably best avoided. Given its name, you’d be forgiven for thinking that UnityScript is the main development language, it’s not. The Unity community has widely adopted C# and you’ll find the majority of plugins and examples use it. If you prefer JavaScript and only have a very simple project in mind then UnityScript is a good option. Once you start using plugins written in C# that potentially need to call back into your UnityScript you’ll find issues with compilation order and wish you’d gone with C# from the beginning.

Pros

Unity has a lot of great features:

Unity has a very strong community of asset and plugin creators – there’s lots of free and reasonable priced content available.
Unity’s visual editing tools are excellent and the editor can be extended with plugins.
It supports a wide range of asset formats and converts automatically to optimal formats for the target platform.
It supports a very wide range of platforms, mobile, desktop, web and console.
Deployment to multiple platforms is very easy to manage.
The 3D engine produces high quality results without any complex configuration (I’ve personally written a licensed game with Unity that Apple has featured in lots of countries).
There is a free license that covers the majority of features.
Paid licenses are very affordable for most professional developers, available on subscription for $75 per platform currently (some platforms are free).

Cons

There are a few issues which are worth considering before choosing to go with Unity:

Collaboration is difficult. Unity has an expensive asset server product to help teams collaborate. If you don’t use it, sharing code and assets between team members can be painful. The best option is to enable and use external source control but there are several binary files (which don’t need to be) that can’t be merged and updating assets often causes them to break things in scenes, losing connections to scripts and other objects.
Performance is not great – until very recently Unity ran almost entirely in a single thread and made almost no use of the extra cores in most mobile devices – this is improving in Unity 5. The compilers are not at all well optimised for the ARM processors in almost all mobile devices – Unity have decided to transpile to C++ and use LLVM to get a more optimised build rather than solve this problem directly in future releases.
The engine source code is not available. Even paying users don’t get to see the Unity source code, which means if you come across a bug in the engine you have to wait for them to fix it or work around it. It’s always going to be more critical for you than it is for them. This also limits the ways in which you can extend or customise the engine.

Overall, Unity is a great choice, particularly for solo developers who aren’t trying to push the limits of what the platforms can do.

Cocos2d – perfect for casual games

Cocos2d is, as the name suggests, a 2D games engine. It originated around the same time as the iPhone SDK and quickly switched to Objective-C, growing in popularity as the best free and open source option for mobile games. However, Apple released their own highly performance optimised 2D engine for Objective-C developers called SpriteKit. That, along with the rise of Android, has caused the focus of Cocos2d development to shift towards the cross-platform Cocos2d-x branch written in C++. The Cocos2d family of engines is the most popular open source option in the world, used by 19% of game developers in our survey and by 8% as their primary tool.

Supported languages

There are different versions of Cocos2d available in Objective-C, C++, C#, Java, JavaScript and Ruby. As mentioned above, the C++ version is the most actively maintained, it also has the widest range of supported platforms. There are also scripting language bindings to the C++ version in both Lua and JavaScript, enabling developers to write in their preferred scripting language but get the full native performance of the underlying engine.

Pros

As with most thriving open source products, there’s a lot to like about Cocos2d:

Broad range of supported platforms, particularly mobile ones.
Free and open source (MIT license).
Wide range of extensions, tools and open source code available.
Lots of community created examples and learning resources.
Large peer support community.
Hardware accelerated graphics and good performance.
Audio support (in most versions).

Cons

Nothing’s perfect, here are a few issues with Cocos2d:

There’s no large commercial entity providing support and bug fixes. It’s great that you can fix it yourself, or hire someone who knows how. The community might even fix your issue for free but sometimes when a big project hits a bug or performance issue close to a deadline you just want to be able to pay someone to make it go away.
The APIs are somewhat unorthodox. The history of the project is such that it started in Python and moved to Objective-C very early. The Objective-C wasn’t exactly following standard practices and then that got ported to C++, retaining the Objective-C idioms.
It doesn’t do much to encourage good structure. Some developers like frameworks that don’t impose a style on their apps but Cocos2d goes a bit far. It’s possible to write code that’s hard to maintain in any system but it’s easy to find examples of Cocos2d games with really long functions and a lot of global state.

OK, the cons are nit-picking and more warnings that really negative points. After all, poorly structured code and unusual APIs are not exactly barriers to success. I’ve ported a game from iOS that was written with Cocos2d (the Objective-C version, before the C++ variant existed) and almost one giant method with tens of global variables. At one time it was the number 1 paid download on iOS in several countries. Cocos2d-x is an excellent choice for a 2D game.

Adobe AIR – what remains of Flash

In 2007 Adobe seemed to be winning the casual games runtime battle, with Flash having become the defacto standard for games on the web and Flash Lite almost ubiquitous on more advanced mobile devices. Then the iPhone came along and Steve Jobs said it wasn’t going to support Flash. This knife wound wasn’t immediately fatal but Flash has been slowly bleeding to death ever since. By 2011 Adobe eventually produced a version of AIR that compiled Flash to native iOS apps but by then the damage was done. Android initially supported Flash, poorly, in the browser but Adobe eventually gave in and stopped developing the browser plugin to focus on AIR. There are still a lot of Flash developers in the world, 15% of mobile game developers use it and 6% of them as their primary tool. It’s also still, just about, the only way to target rich gaming experiences to the majority of the world’s desktop web browsers. Adobe is now focussing on tools for HTML5 developers and Flash/AIR has not really evolved in a long time. Given this background, I won’t focus on detailed technical pros and cons as with the other tools.

Supported languages

Adobe AIR applications are developed in Flash, coded using ActionScript. There’s an integrated web view which can be targeted with HTML, CSS and JavaScript. It’s also possible to build native extensions for AIR apps, individually for each targeted platform.

Pros

Flash is still a capable environment for simple 2D games. If you already know Flash it’s one of the fastest ways to build a mobile game.

Cons

The platform is a dead end. I couldn’t recommend anyone who doesn’t already know Flash to learn it. Those who are fans of ActionScript but don’t like HTML5 should probably look at Haxe.

Unreal Engine 4 – the AAA king goes mass market

The Unreal Engine has a long history as one of the top 3D games engines for PC and console platforms. The 3rd generation of the engine supported mobile platforms but it was really only for hobbyist developers tinkering with their limited UDK or the multi-million dollar licensees of the engine for console games porting their titles to mobile devices. In March this year, Epic Games released the Unreal Engine 4 to anyone for $19/month plus 5% revenue share. This offering includes full access to the engine source code and their suite of tools. This change was not long enough before our survey was launched to see significant adoption by developers but 13% were using it with only 3% as their primary tool.

Supported languages

The Unreal Engine is written in C++ and that’s the only supported development language. However, it’s possible to do a lot of development without writing any code using Blueprints – a visual programming environment where nodes are connected with lines.

Pros

The Unreal Engine is AAA game quality:

Incredible performance. The Unreal Engine was demoed using Apple’s new Metal graphics interface at WWDC. It can produce the most realistic graphics ever seen on an iOS device. The same will be true for (high end) Android devices.
They have state of the art tools for all aspects of game development.
Full source access enables extension, customisation and engine bug fixing.
The pricing model is an excellent match for the high risks of failure on the App Store.

Cons

The Unreal Engine is designed for professionals:

Development is in C++, not a beginner friendly language.
The learning curve for the tools and engine is significant, greater than Unity.
The engine has limited support for older devices.
The pricing model is very expensive for a successful title, unless you expect significant success and use the engine under a different licensing model.

The Unreal Engine is an excellent option for high quality 3D games on high end mobile devices but it won’t be for everyone. I expect to see increasing adoption across the next couple of years. If you’d like a free 3D engine with scripting language support it might be worth checking out Project Anarchy by Havok. It’s effectively subsidised by Intel (owners of Havok) for mobile devices. There’s a co-marketing option in the license and you have to build an x86 variant if you build for Android (or Tizen, if that ever happens), otherwise it’s completely free, only the PC version is paid.

* Apple’s SpriteKit on iOS is actually a fully functional 2D game engine but as it’s part of the platform, developers may legitimately have said they were only using native code. If this is popular then it may significantly reduce the 29% figure.

Which are the best and worst aspects of each tool? Here’s your chance to have your say. Take the survey.

Tags 2D engine, 3D engine, adobe air, boo, cocos2d, flash, game development, unity, unityscript, unreal engine

Tools

Five popular databases for mobile

Post author By Katerina Roukounaki
Post date September 10, 2014
No Comments on Five popular databases for mobile

More and more mobile applications need data to work, and databases have for quite a while been the most common way of storing and managing data. So, in a typical scenario, a mobile application uses a database that is hosted in the cloud, and connects remotely to it in order to access its data. This, of course, implies that, in order to be responsive, a mobile application needs an active and quite fast network connection.

Where is mobile development heading to? Take the Developer Economics Survey that is now live and shape the future of mobile development.

But what if you could move your database from the cloud onto the mobile device, thereby allowing your mobile application to satisfy its storage needs without having to rely on any back-end storage service? Or what if you could keep your database in the cloud, but at the same time maintain a local up-to-date replica of it that would allow your application to be fully functional even when no network connection is available and to sync with the remote database periodically or when going back on-line? And what if you could do all that by using the same or similar tools with the ones that you are using now?

Embeddable databases are lightweight, self-contained libraries with no server component, no need for administration, a small code footprint, and limited resource requirements. Mobile applications can be (statically or dynamically) linked to them, and then use them in order to create and manage their own – private or shared – databases locally on the device. Behind the hood a database-management-related action typically involves only a few function calls within the same process.

At the moment there are several embeddable databases out there that you can use in a mobile application. Let’s examine the most popular of them and highlight some of their characteristics that have contributed to their widespread use. The next table gives an overview of the type of the data that each one of these databases can store, the license under which it is distributed, and the platforms it supports.

Database	Type of data stored	License	Supported platforms
BerkeleyDB	relational, objects, key-value pairs, documents	AGPL 3.0	Android, iOS
Couchbase Lite	documents	Apache 2.0	Android, iOS
LevelDB	key-value pairs	New BSD	Android, iOS
SQLite	relational	Public Domain	Android, iOS, Windows Phone, Blackberry
UnQLite	key-value pairs, documents	BSD 2-Clause	Android, iOS, Windows Phone

Berkeley DB

Berkeley DB is a family of open-source libraries that allow you to manage your data either in the traditional relational way (using SQL) or as key-value pairs (where both keys and values are byte arrays) or as Java objects or as XML documents. Regardless of the API you choose, Berkeley DB promises indexing, caching, transactions, single-writer/multiple-reader access, full-text search (for the SQL interface), automatic failure recovery, replication, compression and encryption. It also supports both in-memory and on-disk databases.

Another intriguing feature of Berkeley DB is that the SQL API it provides is fully compatible with that of SQLite. As a result, you can make your SQLite applications use Berkeley DB as the underlying storage engine without having to re-write them. All you need to do is link them to a suitable version of the Berkeley DB library. This combination of SQLite and Berkeley DB has been reported to perform better in case of highly concurrent, write-intensive applications.

Berkeley DB provides API bindings for several programming languages, including C++ and Java, and has been compiled, run and tested on several operating systems, including Android and iOS. Nevertheless, you might be put off by its AGPL license, in case you want to use it in your application, but you do not want to distribute your own source code in exchange.

Note also that, mainly because of its effort to provide features that are expected in traditional client/server databases, Berkeley DB is considered as a relatively heavyweight solution. So, unless you absolutely want a feature that is only offered by Berkeley DB, then there are other more lightweight alternatives you can choose from.

Update: Even though Berkeley DB technically supports iOS, it can’t be used in App Store apps due to license incompatibility with App Store terms & conditions.

Couchbase Lite

Couchbase Lite is a document-oriented database: data is stored as JSON documents. Each document may have one or more attachments, which are essentially uninterpreted binary data that is stored and loaded separately from the document itself. Couchbase Lite supports persistent indices (called views), and uses map-reduce to manage and query them.

Couchbase Lite, together with Couchbase Sync Gateway and Couchbase Server, are the three components of the NoSQL JSON mobile database solution offered by Couchbase called Couchbase Mobile. One of the key features of Couchbase Mobile is built-in synchronization (through Couchbase Sync Gateway) between local databases (Couchbase Lite) and databases in the cloud (Couchbase Server), which relieves the developer from the burden of writing their own sync code. In order to support this feature, Couchbase Lite comes with a conflict resolution mechanism that is quite similar to the one used by Git.

Couchbase Lite provides a Native API for both Android and iOS, as well as plug-ins for two widely used cross-platform tools for mobile development: PhoneGap and Xamarin.

LevelDB

LevelDB is an open-source library (written at Google) that implements a key-value store, where keys and values are byte arrays, and data is stored ordered by key (based on some, probably custom, comparison function). LevelDB supports atomic batch updates, forward and backward iteration over the contents of the store, snapshots (i.e. consistent read-only views of the entire store), caching, data integrity (using checksums), and automatic data compression (using the Snappy compression library). An important limitation imposed by the library is that at any moment at most one process can have access to a specific database.

“LevelDB has good performance across a wide variety of workloads” state its authors, and here are the results of a benchmark they put together to prove their claim by comparing LevelDB with SQLite and Kyoto Cabinet (another key-value store implementation).

LevelDB is written in C++. iOS developers can use it directly in their applications or through one of the several Objective-C wrappers that are available for it. Android developers can use LevelDB via JNI and NDK.

SQLite

SQLite is an open-source C library for managing relational databases that can be stored both on disk and in memory. It supports dynamic typing (types are assigned to values, rather than to columns), transactions, full-text search, single-writer/multiple-reader access, efficient range queries (useful when storing geographical data), and shared caching (across connections opened by a single thread to the same database).

SQLite stores each database as a single disk file in a cross-platform format. This implies that you can create an SQLite database on one machine and then use it on another machine with an entirely different architecture by simply copying the corresponding file.

The authors of SQLite believe that it is “the most widely deployed SQL database”. Bindings for SQLite are available in most mainstream programming languages. SQLite is also included in both iPhone and Android operating systems.

UnQLite

There are a lot of people that incorrectly believe that UnQLite is the NoSQL counterpart of SQLite, although the two products are completely independent. UnQLite is an open-source database that exposes both a key-value and a document store interface. It supports both in-memory and on-disk databases, transactions, multiple concurrent readers, and cursors for linear traversal. Like SQLite, UnQLite uses a cross-platform file format, and stores each database in a single file on disk.

No matter which store interface you use, UnQLite’s storage engine works with key-value pairs. A distinctive feature of UnQLite is that you can change at run-time the storage engine that is used. At the moment, UnQLite comes with two built-in storage engines, one for on-disk and one for in-memory databases.

UnQLite is written in C, and can thus be used in both iOS and Android applications (in the latter, through JNI).

Our Developer Economics Survey is now live. Have your say, shape the future of mobile development and win amazing prizes and gear. Start now.

Tags BerkeleyDB, Couchbase Lite, database, embedded database, LevelDB, SQLite, UnQLite