Page 1

THE DZONE GUIDE TO

MOBILE APPLICATION DEVELOPMENT VOLU ME III

BROUGHT TO YOU IN PARTNERSHIP WITH

1


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

dear reader, Mobile development is a frustrating mix of opportunity and constraint. Processors keep speeding up and consuming less power, but battery tech isn’t growing as quickly (opportunity)—so you can’t push onboard computation as far as it can physically go (constraint). 4G connections are getting cheaper and mobile devices are getting smarter about blending cellular and wifi (opportunity)—but partition-Free mobile networks will always remain a moving target (constraint). Hardware manufacturers are producing more form-factors (opportunity)—but this makes simplifying assumptions about viewport size no longer useful (constraint).

TABLE OF CONTE NTS 3

EXECUTIVE SUMMARY

4

KEY RESEARCH FINDINGS

8

IN MODERN APPDEV, NATIVE APPS EMERGE SUPERIOR BY ROB LAUER

10 REAL-TIME AND STREAMING IN THE MOBILE WORLD BY CEDRIC TRAN-XUAN AND ERIC HORESNYI 14 WIRELESS COMMUNICATIONS IN MODERN MOBILE TECHNOLOGIES BY LANCE GLEASON 16 INFOGRAPHIC: THE EMOJIS OF MOBILE DEVELOPMENT 18 NATIVE CROSS-PLATFORM MOBILE ARCHITECTURE BY PAUL ZABELIN

And so on.

22 THE CHANGING MOBILE OS LANDSCAPE IN THE ENTERPRISE BY MARK KIRSTEIN

But mobile development tools and techniques are

24 DIVING DEEPER INTO MOBILE APPLICATION DEVELOPMENT

both maturing rapidly. The continuing growth of cross-platform development tools—measured by adoption rate, feature set, and release schedule— somewhat softens the headaches caused by target platform fragmentation (still the largest pain point for mobile developers). Widespread recognition that Native UX is still superior to WebView or in-browser mobile Web UX, and the increasing expectation

25 CHECKLIST: ESSENTIAL ANDROID & IOS LIBRARIES BY JAMES SUGRUE 26 EXECUTIVE INSIGHTS ON MOBILE APPLICATION DEVELOPMENT BY TOM SMITH 28 MOBILE SOLUTIONS DIRECTORY 32 GLOSSARY

among users (caused partly by hardware advances) for hyper-responsive user interface, keeps mobile developers coming back to Java, Objective-C, and (now open-source) Swift 2. But modern cross-platform

EDITORIAL

BUSINESS

PRODUCTION

frameworks, code translators, and UI prototyping

CAITLIN CANDELMO

RICK ROSS

CHRIS SMITH

MATT WERNER

MATT SCHMIDT

MICHAEL THARRINGTON

JESSE DAVIS

CONTENT + COMMUNITY MANAGER

EVP & COO

NICOLE WOLFE

KELLET ATKINSON

CONTENT COORDINATOR

DIRECTOR OF MARKETING

MIKE GATES

MATT O’BRIAN

tools are cutting far deeper than Native-wrapperaround-JS-code. More shared code is just plain good, and mobile developers’ expanding knowledge-base of Hybrid applications is making it easier to see which optimizations really must be done via platformspecific tweaks. To give you a snapshot of the current state of mobile application development; to suggest which areas of technical expertise are worth investing time to build; and to give you a sense of the future of mobile development technologies, we’re publishing our third

DIRECTOR OF CONTENT + COMMUNITY

CONTENT + COMMUNITY MANAGER

CEO

PRESIDENT & CTO

CONTENT COORDINATOR

SALES@DZONE.COM

INDUSTRY + VENDOR RELATIONS

ALEX CRAFTS

JOHN ESPOSITO

JIM HOWARD

SENIOR RESEARCH ANALYST

TOM SMITH

RESEARCH ANALYST

DIRECTOR OF BUSINESS DEVELOPMENT

DIRECTOR OF MAJOR ACCOUNTS

DIRECTOR OF PRODUCTION

ANDRE POWELL

SENIOR PRODUCTION COORDINATOR

G. RYAN SPAIN

PRODUCTION PUBLICATIONS EDITOR

ART ASHLEY SLATE DESIGN DIRECTOR

SPECIAL THANKS to our topic experts, Zone Leaders, trusted DZone Most Valuable

SR ACCOUNT EXECUTIVE

Bloggers, and dedicated users

CHRIS BRUMFIELD

for all their help and feedback in

ACCOUNT MANAGER

making this report a great success.

annual Guide to Mobile Development, with emphasis on Native platforms. Read the Guide, write some code, release some apps—and as always, let us know how

WANT YOUR SOLUTION TO BE FEATURED IN COMING GUIDES?

we can serve you better.

Please contact research@dzone.com for submission information.

BY JOHN ESPOSITO SENIOR RESEARCH ANALYST, DZONE RESEARCH@DZONE.COM

2

LIKE TO CONTRIBUTE CONTENT TO COMING GUIDES? Please contact research@dzone.com for consideration.

INTERESTED IN BECOMING A DZONE RESEARCH PARTNER? Please contact sales@dzone.com for information.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

Executive Summary Network-connected computers are always movable— as long as one topology (telecom) maps variably onto another (physical geography). What makes an application “mobile” or “mobile-first” is more than spatial mobility. For developers, constraints specific to mobile include iffiness of wireless networking and the sloppiness of inter-cell handover (high partition probability); portable and proliferating form-factors (smaller displays lead to more stringent UX requirements; more viewport sizes leads to more complex UX requirements); dependence on expensive and heavy batteries (power constraints); relatively low network bandwidth (latency); the appcentrism popularized by the iPhone and embraced by Android (more specialized individual apps leads to faster expected release cycles and a more liquid market); split-second human-computer interactions (required by mobility); the relative immaturity of major mobile platforms (which remain fragmented, although the situation is improving)... the list goes on. To help you know how mobile application teams are actually solving these problems, we surveyed more than 400 developers, uncovering their thoughts and feelings on the present and future of mobile development, the platforms they prefer and why, the pain-points encountered while building mobile apps, and more. NATIVE APP DEVELOPMENT CONTINUES TO DOMINATE, BUT HYBRID APPS WILL BECOME MORE COMMON IN THE FUTURE DATA Mobile developers are more likely to develop primarily Native apps (45%) vs. Web (31%) and Hybrid (24%). But more respondents expect Hybrid app development to increase over the next couple of years (45%) than expect Web (28%) or Native (26%) apps to increase. IMPLICATIONS The weaknesses of pure-mobile app development are now well-understood and the superior UX offered by Native apps is clear. But as greater cross-platform app development experience reveals more clearly exactly which shared Web code does or does not degrade performance, and as Hybrid frameworks offer more and easier access to Native device features, betterfocused Hybrid development efforts will optimize codebase/UX trade-offs more effectively. RECOMMENDATIONS Build polyglot development teams with both Native and mobile Web expertise. Learn mobile-specific JavaScript and CSS. Brush up on Hybrid app development tools.

3

DEVELOPERS STILL PREFER ANDROID, BUT SWIFT IS MAKING iOS MORE INTERESTING DATA Respondents are currently both more likely to develop for Android (76% develop for Android, vs. 45% for iOS and 56% for mobile Web) and also more likely to prefer Android as a development platform (49% prefer Android vs. 18% for iOS and 28% for mobile Web). But out of the respondents who plan to adopt a new technology in the next six months, 18% plan to adopt either Swift (10%) or iOS (8% answer without specifying Swift).

Android is still a better target for mobile developers, but iOS is likely to become more attractive to developers in the future, thanks especially to Swift (now opensource and in version 2).

IMPLICATIONS

For near-term projects, continue to focus on Android. For projects 6+ months out, learn Swift and become more familiar with iOS development communities.

RECOMMENDATIONS

CROSS-PLATFORM DEVELOPMENT WILL CONTINUE TO GAIN MOMENTUM AS TOOLING IMPROVES DATA Out of respondents who plan to adopt a new technology in the next six months, 38% plan to adopt some kind of crossplatform solution.

Cross-platform development will get easier as tools mature, partly for the reasons related to the projected increase in Hybrid app development: the cross-platform tools are getting better as developers understand the overlap among platforms themselves more fully (including effects of shared codebase on performance).

IMPLICATIONS

Consider using currently-mature crossplatform tools (PhoneGap/Cordova, Ionic, Xamarin). Look into more aggressive cross-platform frameworks and tools (React Native, NativeScript, Intel XDK).

RECOMMENDATIONS

DEVELOPER EXPERIENCE IS THE STRONGEST INFLUENCE ON PLATFORM PREFERENCE

DATA 75% of responses to the question “Why do you prefer a particular platform?” pertain to developer experience (familiarity, ease of use, tools, WORA, community, flexibility, etc.). 25 distinct reasons were given. IMPLICATIONS While popularity among end-users presumably influences choice of target mobile platform (although our survey data do not independently confirm this), popularity has much less impact on developer preference (12%) than developer experience. Further, reasons to prefer a platform are many and vary significantly by individual and by platform (for details see Key Findings). RECOMMENDATIONS Find what makes a platform preferable for each developer on your team. Decide how to relate considerations that relate to mobile end-users (including platform adoption rates, but also UX and hardware quality) with considerations that relate to mobile developers’ whole development experience and may not be determined completely by intrinsic technical features of the platform.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

ANDROID DOMINATES EVERYWHERE

Key Research Findings

As among users, so also among developers: Android is far more popular than iOS worldwide. Further, preference for Android excludes iOS development more strongly than preference for iOS excludes Android development. Among developers who prefer Android, 36% also use iOS; while among developers who prefer iOS, 69% also use Android. This is probably at least partly a function of Android’s dominance among users: the market exerts more pressure to develop for Android (preferred or not) than to develop for iOS (preferred or not).

BUT DEGREE OF ANDROID DOMINANCE VARIES SIGNIFICANTLY BY SEGMENT

400+ IT Professionals responded to DZone’s 2016 Mobile Application Development Survey. Here are the demographics of this survey:

• Developers/Engineers (45%) and Development Leads (25%) were the most common roles. • 47% of respondents come from large organizations (100 or more employees) and 51% come from small organizations (under 100 employees). • The majority of respondents are headquartered in Europe (37%) or the US (33%). • Over half of the respondents (62%) have over 10 years of experience as IT professionals. • The most popular language ecosystems used include Java (79%), Universal JavaScript (49%), C# (35%), and PHP (35%). 01 WHAT PLATFORMS DO YOU DEVELOP MOBILE APPS FOR?

Developers at small companies (<100 employees) are likely to target Android vs. iOS more strongly than developers at larger companies. This can be understood as a function of (a) the reasons developers prefer a particular mobile platform, (b) the popularity of Java across the developer world (magnified by the language preferences of the survey population), and (c) the more limited scope of expertise available in smaller companies. Toward (a): the most frequently cited reason to prefer a mobile platform is “familiarity” (see discussion below). Toward (b): the most frequently used programming language is Java. Toward (c): in sufficiently small companies, familiarity may be more likely to influence platform choice because fewer developers are available and because hiring for lessfamiliar expertise is more difficult (as it is easier to 02 ANDROID:iOS PLATFORM TARGET RATIO BY COMPANY SIZE 83

78

75

77

77

72

74 64

60

WEB

56%

56 iOS

40

45% 19%

37

50 37

42

43

20

WINDOWS

4

ANDROID IS MORE LIKELY TO DOMINATE iOS IN COMPANY SIZES 1-4 AND 20-99

80

ANDROID

76%

Android dominance among developers varies by four demographics: company size; continent (in ways that seem to follow device purchasing data, with some lag); primary platform target; and years of experience.

OTHER

1.2%

1-4

5-9

10-19

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

20-99

100499

5009,999

10,000+


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

evaluate applicants for jobs focused on technologies more familiar to the person hiring).

iOS DEVELOPMENT SIGNIFICANTLY MORE COMMON IN AMERICA THAN EUROPE Developers’ targeting of Native platforms varies by continent by the same rank order as smartphone purchases, but to a more intense degree. By the end of 2015, iOS’ relative market share reached 39% in the USA and 27% in Europe. Among our respondents in America, 56% target iOS (in addition to other platforms) vs. only 37% among respondents in Europe. Because most users own only one smartphone, while most mobile developers target more than one mobile platform (including Web), developer targeting by platform should always measure higher than phone ownership by platform. But whereas the USA–Europe difference among consumers is only 12%, the difference among developers is 19%. (note: Some of this difference can be accounted for by statistical effects caused by target platform overlap: developers who target iOS are much more likely to target Android in addition (85%) than developers who target Android are likely to target iOS in addition (51%) simply because the number of respondents who target Android is larger, so the effect of a targetoverlapping developer on overall targeting percentage per platform is greater for iOS than for Android.)

PRIMARILY-NATIVE AND PRIMARILY-HYBRID DEVELOPERS BOTH MOST PREFER ANDROID Android is preferred both by developers who primarily create Native apps and also by developers who primarily create Hybrid apps. The preference is stronger among Native app developers (63% vs. 23%) than among Hybrid app developers (55% vs. 20%). Since the level of preference for iOS remained relatively constant between Native and Hybrid developers (22% vs. 20%), the difference between Native-primary and Hybrid-primary development

03 DEVELOPERS TARGETING iOS IN USA VS. EUROPE

USA EUROPE

5

56% 37%

seems more likely to affect Android developers than iOS developers; but until we investigate target platform transitions in particular, it is difficult to conclude Anything about the overlap between experience of Android and Hybrid app development, on the one hand, and the overlap between experience of iOS and Hybrid app development, on the other. General developer mobile preferences may offer a clue as to the relatively small effect of platform target type on preference for iOS: two of the top three reasons respondents prefer a mobile platform (familiarity and popularity) apply more to both Android and Web development than to iOS, so preferences for both Android and Web among Hybrid developers are more likely to ‘cannibalize’ one another than to decrease preferences for iOS. note: these results are probably skewed by the primary programming language distribution of the survey population. Although Java remains the most popular programming language in the world, Java’s dominance in our survey population (57%, several times more than any other primary language) is almost certainly stronger than in the general world of software development. Further, even among developers who primarily build mobile Web apps, Android enjoys a high level of preference. It is striking that 24% of Webprimary mobile developers prefer Android as a target platform, while only 7% of Native-primary mobile developers prefer the Web.

ANDROID PREFERENCE DOMINANCE DECREASES AS YEARS OF EXPERIENCE INCREASE Developers at all levels of professional experience prefer to develop for Android, but at lower rates as experience level increases. In fact, Android preference dominance decreases in every increasing experience-level bucket, from 64% (respondents

04 PRIMARY PLATFORM TYPE TARGET BY TEAM SIZE

20

23

57

TEAM SIZE: 1

29

39

32 TEAM SIZE: 2-5

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

17

33

50

TEAM SIZE: 6-10


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

with 1-2 years experience as an IT professional) to 41% (15+ years experience). iOS preference grows correspondingly, with one exception: respondents with 10-14 years of experience are less likely to prefer iOS than respondents with 6-9 years of experience (14% vs. 18%) (preference for the Web picks up the balance). The general trend may be explained by (a) familiarity, (b) ecosystem, and (c) popularity. Toward (a): younger developers are likely to be familiar with fewer technologies than more experienced developers, so Java is more likely to occupy a larger relative portion of younger developers’ familiarity space. Toward (b): younger developers are more likely than older developers to rely on existing tools, libraries, and communities, so the breadth of the Android ecosystem is likely to attract younger developers more than older developers. Toward (c): younger developers are more likely to be coupled more loosely to a particular mobile platform, so the popularity of Android among end-users makes younger developers’ Freer choice of development target more attractive. One hypothesis may be offered, very tentatively, regarding the 6-9 year exception in the corresponding iOS preference trend. Since the first iPhone SDK was released in 2008 (just under eight years before this survey was taken), it is possible that developers who began as IT professionals 6-9 years ago were more likely than developers at other (2016) experience levels to adopt a relatively immature technology at a relatively low level of general IT experience. This development experience may not have been as pleasant as early iOS development experiences for significantly more and less experienced developers. But further research is 05 PLATFORM PREFERENCE BY DEVELOPER TYPE

OTHER WEB WINDOWS

necessary on both this specific hypothesis and on the general assumptions (regarding the combination of new technology with new developers).

NATIVE APPS MORE COMMON THAN OTHER TYPES; SOLE DEVELOPERS AND LARGER TEAMS MORE LIKELY TO TARGET NATIVE PLATFORMS More developer respondents primarily create Native (45%) than Web (31%) or Hybrid (24%) apps. Native platforms remain by far the primary development target for developers in teams consisting of 10 individuals or fewer (which comprise 87% of respondents). Segmenting further: sole developers and teams with 6-10 individuals both most frequently Native platforms (57% and 50% respectively); but teams with 2-5 individuals distribute platform targets more evently (39% Native, 32% Web, 29% Hybrid). Further research is needed to validate these findings and discover why teams of size 2-5 prefer Native less strongly than smaller and slightly larger teams.

REASONS DEVELOPERS PREFER A PARTICULAR PLATFORM We asked developers an open-ended question: “Why do you prefer a particular platform?” Applying a simple inductive methodology (based on grounded theory), we found 26 distinct reasons. Results can be interpreted in two ways: in aggregate, which tells us something about what makes developers choose any platform; and by platform, which tells us something about what developers like about the platform they prefer. In the aggregate, developers’ reasons to prefer a particular platform focus mostly on the developer experience. Of the top ten reasons to prefer a platform (familiarity, ease of use, popularity, tools, ecosystem, write-once-run-Anywhere [WORA], cross-platform, open-source, and community), only one (popularity) includes the perspective of non-developer users. (WORA and cross-platform are closely related, of course, but reasons we classified as ‘WORA’ focused especially on the act of writing code, while reasons designated ‘cross-platform’ show broader interest in availability to end-users.)

iOS ANDROID

NATIVE

6

HYBRID

WEB

PAIN POINTS ENCOUNTERED WHILE DEVELOPING MOBILE APPS Software development is about pain as much as preference. Mobile developers face many constraints that desktop and pure-Web developers don’t, but the biggest mobile development pain points reported by our respondents pertain not to generic issues like

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

network partitioning, power usage, or limited CPU power, but rather to target variety. The two biggest pain points reported were ‘building Native apps for multiple platforms’ (33%) and ‘testing efficiently on many different types of hardware’ (24%)—making general target variety a significant majority. Pain points vary by platform preference. Two notable variations have clear explanations: (1) for developers who prefer Android, testing on different types of hardware causes significantly more pain (30% vs. 21% for iOS)—to be expected because Android device count is three orders of magnitude greater than iOS device count (and rising); and (2) gathering user flow data is significantly more likely to be the primary pain point for developers who prefer to target mobile Web (11%) than for developers who prefer Android or iOS (both 6%)—presumably because browser sandboxing lowers user flow observation bandwidth. One variation seems surprising: maintaining performance is more likely to be primary the pain point for iOS developers (16%) than for Android developers (11%). Many plausible cause s for this difference might be conjectured (Android’s larger toolset, Java’s maturity and familiarity, relative openness of the Android platform) but deeper insight into iOS performance pain must await further research.

NEW TECHNOLOGIES TO ADOPT IN NEXT 6 MONTHS Mobile technologies change more quickly than desktop or server technologies. Mobile developers are therefore very likely to be planning to adopt 06 PLATFORM PREFERENCE BY YEARS OF EXPERIENCE 70 60 50 40 30 20 10 1-2 YRS OTHER

3-5 YRS WEB

6-9 YRS WINDOWS

LINEAR (ANDROID)

7

10-14 YRS iOS

15+ YRS ANDROID

LINEAR (IOS)

new mobile technologies in the near future. The data bears out this hypothesis: one third of our respondents are planning to adopt a new mobile technology in the next six months. The distribution of technologies these respondents plan to adopt has a long tail (over seventy distinct languages and frameworks), but four emerged distinctly more frequently than the rest (in descending order): React Native, Swift, iOS, and Xamarin. These results are consistent with (a) increasing preference for Native mobile development and (b) Apple’s renewed focus on mobile developers, as evidenced by the recent open-sourcing of Swift. Toward (a): two of these top four are cross-platform (React Native and Xamarin), both designed to produce Native apps (not simply WebView wrappers). Further, while 11% said they were planning to adopt React Native, only 7% are currently using React Native; the difference is small, but suggests that React Native will be more popular in the future (as Google trends also indicate). Toward (b): apart from the near-absence of Android from the list of new mobile technologies that developers are planning to adopt in the next six months (only six responses), it seems plausible that some of the developers who plan to adopt iOS in the next six months are influenced by Swift’s advanced features and ease of use.

CROSS-PLATFORM TOOLS Finally, we asked developers which cross-platform tools they are currently using. 65% reported that they were using some cross-platform tool. Within this group, the technology tail was again fairly long, but three tools emerged significantly above the rest: PhoneGap/Cordova, Ionic, and Xamarin. Three observations may be made from these results. First, the conjunction of PhoneGap’s dominance at present with its absence from future plans, along with the strength of React Native in future plans and its absence from current use, suggests that out-of-browser JavaScript on mobile will grow less important as developers embrace Native platforms (even if their core codebase remains JavaScript), presumably in response to users’ increasing demands for smoother UX. Second, Ionic may have peaked— another strike against mobile HTML5. Third, the high location of Xamarin in both current and future lists bodes well for C# developers and possibly less well for the Universal Windows Platform (since a popular, mature Xamarin platform makes UWP less necessary for C# developers to achieve WORA).

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

QUICK VIEW

IN MODERN APPDEV,

Native Apps Emerge Superior

01

For mobile apps, stickiness equals survival—the ultimate goal for apps.

02

New breeds of crossplatform tools and frameworks are becoming more widely available to make developing “sticky” Native apps easier.

03

JavaScript frameworks are taking Native application development to the next stage of their evolution.

BY ROB LAUER PRODUCT MANAGER AT PROGRESS

The evolution of application development is tied to the constantly changing selection of devices used today, from phones to tablets to the growing wearable market. Apps face constant scrutiny, as consumers are pickier and more sophisticated than ever when it comes to their mobile experiences. Today, and unquestionably more so in the future, apps need to run flawlessly regardless of the platform they’re used on, the tools that were used to build them, or the language in which they were initially written. This presents a myriad of challenges for developers, and it leads to an important vetting process as they determine what kind of app to build and which the best framework to use is. Native apps are emerging as the top choice for developers. UI is hugely consequential to an app’s survival, so naturally the UI must be flawless. The lifespan of an app is a delicate thing, as without any perceived value to the consumer, the app will be uninstalled and permanently dropped from use. While Hybrid and mobile Web apps are still valid choices for many, Native is steadily becoming the go-to choice to ensure that apps have a better chance of sticking. Stickiness equals survival—the ultimate goal for apps—so apps need to perform both without disappointing users while continually demonstrating value.

8

Though it’s difficult to highlight major differences between various types of app development, Native applications unquestionably deliver the best performance. Ideally, their user interfaces react immediately with all interactions and widgets, performing without lag. And, like the AppDev industry as a whole, Native application development is evolving to offer developers new breeds of frameworks. Just a few years ago, AppDev was a different and less mature art, and the choice of app type was less definitive—there wasn’t a true one-size-fits-all solution or a clear frontrunner. As they are now, considerations of budget and time-scale were pertinent, and most mobile devices used one of two dominant operating systems: Google’s Android or Apple’s iOS. Today, while there are respective advantages and disadvantages to consider for any type of app, Native is becoming the easier decision to make. Hybrid and Web apps are still viable options for developers, depending on what app is being built and what their budget considerations are. They both have their upsides, and making any app—Native included—that runs flawlessly across different platforms and devices doesn’t come without challenges. One of the biggest challenges frequently encountered when designing an app is the developer’s need to learn a new programming language depending on the specific platform they’re using; developers are often required to rewrite code from scratch for each platform, which consumes valuable time and resources. Each platform requires a specific language and tooling (for instance, a developer making an Android app is probably using an Android-specific program, like Android Studio), and a major fallout resulting from this is that the full AppDev cycle isn’t properly addressed. In many

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

cases, developers don’t have the capacity to monitor the full lifecycle, through designing, coding, testing, debugging, distributing, and managing. This is mitigated somewhat in Hybrid apps (which normally rely on Apache Cordova and HTML5), as developers reuse code when writing a new app, which makes projects easier to ramp up. Hybrid app development is simple in that developers need only write code for an app once, or even more simply swap code to build an application that can be used for multiple platforms. This means one set of code for any device, resulting in time and money saved. However, Hybrid apps can find themselves stuck in this “nearly Native” quandry where they should feel truly Native, but respond more like a mobile Website. Mature frameworks like Kendo UI and Ionic help to mitigate this, but so far there is no silver bullet. By far the least expensive option, mobile Web apps are quick and relatively simple to create, and there aren’t any restrictions on browsers. Their development is fairly straightforward, as coders don’t have to learn many (if Any) new skills—they simply need to scale the code down to make the site accessible on any device. However, that doesn’t mean that Web apps are always the top choice for developers. Web apps are less intuitive, limited in what they can do in regard to features, and they’ll likely always require an Internet connection to function unless Google’s “Progressive Web Apps” initiative is more widely embraced. What’s more, consumers don’t install Web apps when they use them, so there’s no stickiness in terms of getting a new app on a mobile device permanently. Mobile apps are a fine choice to meet certain demands, but they’re not pushing the innovation envelope.

Web apps are less intuitive, limited in what they can do in regard to features, and they’ll likely always require an Internet connection to function. Ask someone to think of an app they use every day and they’ll probably think of a Native app: one that’s downloaded from Google Play or the App Store that then lives in a device’s app library, launched with the touch of an icon. Native apps have terrific UI, and actually look like they belong on the platform being utilized. They provide users

there’s no uncanny valley with Native, which arguably makes Native worth the time and cost. Because of the advantages of Native apps, new breeds of cross-platform tools and frameworks are becoming more widely available, including those that satisfy a “write once, deliver to many” criteria. With these, solutions are crosscompiled so that developers write code in the language of their choice, which then is compiled for them into Native code. These enable truly Native code and a truly Native app. However, “write once” frameworks won’t be ideal for some coders, as they require developers to wait on a company to make updates to match the latest platform before they can have access. In this situation, there will always be dependence on others, and some developers might not want to face any potential delays during the app creation process.

Today, and unquestionably more so in the future, apps need to run flawlessly regardless of the platform they’re used on, the tools that were used to build them, or the language in which they were initially written. For these developers, new Native JavaScript frameworks (such as NativeScript) offer immediate compilation and eliminate this lag, allowing developers to write code without having to rely on Anyone else to access the latest iteration. Native JavaScript frameworks also enable developers to write in JavaScript rather than writing code in Native languages, like Objective C or Java. So when a user opens up the app, the framework is able to leverage the JavaScript engine on the device being used. Therefore, when the app runs, it relies on that JavaScript engine to interpret and execute the code, accessing the Native component. While they’re still quite young in terms of their scale of use, Native JavaScript frameworks are taking Native application development to the next stage of their evolution, bringing modern Web techniques to modern coders. At the end of the day—and considerations of cost aside—these Native frameworks make Native the emerging preferred choice for high-caliber apps. As to be expected, each new framework will present a learning curve. For the new Native frameworks, developers will still be using Native concepts in their methodology, so the learning curve won’t be too steep. That said, the growing prevalence of Native apps is a trend to watch in the coming year and beyond, as they stick around for the long-term— bolstered by innovative frameworks and superior UIs.

with superior performance along with reliability and responsiveness, which boosts the user experience as a whole. As Native apps have to be developed separately for each platform, they’re the most expensive to make. Still,

9

ROB LAUER is a Senior Manager of Product Management at Progress and has a passion for mobile app development and the open Web.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

Real-time and Streaming in the Mobile World BY CÉDRIC TRAN-XUAN AND

ERIC HORESNYI

QUICK VIEW 01

Data animation exposes the end-user to changes in app data.

02

Polling is inefficient, so you need a technology that can push data frequently.

03

WebSockets and ServerSent Events (SSE) are good choices, and MQTT is also a good one from the IoT world.

LEAD DEVELOPER AT STREAMDATA.IO

CEO AT STREAMDATA.IO

New design patterns have enhanced UX by bringing animated UI components. Material Design is one good example: when a user clicks on a button, he/she can see a slight animation which indicates that the action has been performed. Ditto with other UI components like inputs. That’s nice: the user has a visual feedback when he/she interacts with a UI: something actually happens. But can we do better? What if instead of animating UI, we also animate the data?

POLLING IS INEFFICIENT. Poll too fast, and you will get repeated data, useless calls between the client and the server that can overload the server depending on the polling frequency and the number of clients. Poll too slow, and you may lose data. You run behind. Poll at the wrong moment, and you may be blocked because the server is busy. What you really need is a technology that can push data frequently. Fortunately, solutions have existed for quite a long time now. WebSockets and Server-Sent Events (SSE) are some well placed candidates. MQTT is also a good one in the IoT world. Let’s start with WebSockets.

WEBSOCKETS WHAT DO YOU MEAN BY ANIMATING DATA? Animating data is the idea of exposing to the end-user the change of data, provided the data is changing quite a lot.

WHY SHOULD I CARE ABOUT ANIMATING DATA? Well, to borrow a well known motto: “animated data will eat the world.” Indeed, our world seems to be consuming more and more real-time data; news, multi-player games, social networks, e-commerce, sharing economy, collaborative apps, dashboards, and—last but not least—IoT. While real-time data was once reserved to FinTech apps ten years ago, it’s not the case Anymore. Just think about Twitter. Looking at tweets in real-time is just expected. So, to paraphrase a colleague of mine: “The more others invest in amazing UI, the more yours seems lousy.”

OK. SO, WHAT DO I NEED TO ANIMATE DATA? One might think that frequent polling could do the job. But frankly, that’s a bad idea. What’s wrong with polling?

10

WebSockets is a low-level protocol that enables a full duplex TCP connection. This means you can communicate in both ways: from the client to the server and from the server to the client. The initialization of the connection starts with an HTTP request. This request performs an upgrade handshake, which enables the client and the server to switch to a lower protocol level. Once you’ve got your socket, you’re Free to send whatever you want in it. In both directions. In binary or text. GET /chat HTTP/1.1 Host: example.com:8000 Upgrade: Websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13

As you are Free to send Anything, you usually come to implement some kind of messaging protocol between the client and the server. The WebSocket protocol offers a subprotocol feature to ensure the client and the server speak the same language. When the WebSocket is initiated, a subprotocol can be sent in the headers during the handshake

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

phase. If the server can speak the sub-protocol, then the connection can be established. If not, the client has to close the connection.

tells the client after how long it can try a reconnection. This saves useless reconnection attempts. Once again, you may find the implementation of this feature in the client library.

Some sub-protocol already exist in the WebSockets land. WAMP (Web Application Messaging Protocol) is one of them. This sub-protocol offers both RPC (Remote Procedure Call) and Publish-Subscribe. RPC offers a way to trigger actions to the server while Publish-Subscribe more naturally fits with notifications to the client.

You can also define an event property to define the type of the event. Defining a type for an event allows the client to filter the events received according to their type. This eases the way to handle several events in one SSE connection.

DDP is another protocol based on top of WebSockets. It also offers RPC and some subscription mechanism. In this latter case, the client can be notified of JSON documents changes. Originally, DDP was developed for the JavaScript platform Meteor, which is the official server-side implementation. nonetheless, client implementations for Native mobile apps exist for both Android and iOS.

SERVER-SENT EVENTS Server-Sent Events (a.k.a. SSE) is also a push technology. Unfortunately, SSE is less well known than WebSockets. Like WebSockets, it has a W3C specification and was born a little bit earlier (2006 vs 2008). Server-Sent Events is half-duplex: data can be sent from the server to the client. This is, honestly, the only requirement to animate data. With SSE, only text can be sent. Unlike WebSockets, SSE relies on HTTP/1.1, which, from an OPs point of view, is a bit simpler. Indeed, load-balancers and proxies were made to support HTTP. So de facto, SSE should be transparent for them. All you need is a server that supports SSE and an HTTP connection. To connect to a SSE server, you need to initiate an HTTP connection (with a GET) by sending an

MQTT is one of the lightweight message protocol used in IoT. It’s a publish–subscribe protocol over a TCP connection. An MQTT broker is used to dispatch the messages sent by a publisher to subscribers. MQTT offers three levels of message delivery (also called QoS for Quality of Service): 0, 1, and 2. Level 0 is a fire-and-forget mode, which delivers only once. There is no acknowledgement from the subscriber. Level 1 guarantees the message is delivered at least once. But this means the message can be delivered more than once too. Level 2 makes sure the message is delivered exactly once. In case of a loss of connection and a reconnection attempt, a subscriber can get the missed messages (if the QoS is Level 1 or 2) and is not forced to re-subscribe to all the topics it has subscribed. This MQTT mode is called Persistent Session. It’s not the default mode, but it is easily configurable. When a client subscribes to a topic, it may also wait for a while before the publisher publishes a new message. In some cases, it’s not convenient for the client: it may be desirable to get the last message in order to display some data on the UI. MQTT supports this kind of feature: it’s called Retained Message. This is configurable by a flag sent with the message. To be more accurate, it’s not the last message published but the last message sent with the retained flag. Last Will and Testament is also an interesting MQTT feature that enables the detection of a disconnection of a client and implements some strategies like notifying the other subscribers that the client has been disconnected.

GET /stream HTTP/1.1 Host: example.com Accept: text/event-stream

accept header with text/event-stream. But as for WebSockets, you may not really care since the implementations of SSE usually hide all this plumbing stuff. For iOS, you can use TRVSEventSource. And in the Android world, several Java libraries do the job: here and there. Further, SSE comes with a nice feature: its reconnection ability. In case of a loss connection (wifi loss, etc.), the specification allows the client to reconnect to the server and get the missed events. This can be done if the server sends events structured as follows: id: 37 event: news data: New DZone article is out! retry: 3000

The ID of the event received can be registered in the client side. If the client loses the signal, it can reconnect to the server with the ID of the last event received (via a Last-Event-ID HTTP header). The server can then use this ID to send the missed events. This Last-Event-ID mechanism is implemented in the browsers. Depending on the library you use, it may do the same for Native clients. In the event sent, the server can also send a retry property, which is a delay for a reconnection. In this case, the client loses the connection, when the client should try to reconnect. retry

11

MQTT

WHICH TO USE Depending on your application, you may ask whether you should use WebSockets, Server-Sent Events, or MQTT. WebSockets is a bidirectional protocol while the two others aren’t. In the case of WebSockets vs. Server-Sent Events, I would wonder first whether the client needs to communicate as often as the server. If communication is mostly from server to client, you might consider using a REST call for transactional calls, along with SSE for server-client data. If the server API does not offer SSE, you can consume it via an SSE proxy (editor’s comment: this is what streamdata.io offers). This may be a quick and scalable win compared to re-implementing a message protocol in WebSockets. MQTT can also be a nice technology to be considered. But it has impact on the infrastructure: a TCP MQTT broker needs to be installed and configured. CÉDRIC TRAN-XUAN is lead developer for Streamdata.io. He has 12 years experience in coding and enjoys geek meetups, conferences, and talks! He is trekking and cross-country skiing. He write blog posts, co-organizes snowcamp.io, and give talks at developer conferences. ERIC HORESNYI was a founding team member at Internet Way (French B2B ISP, sold to UUnet) then Radianz (Global Finance Cloud, sold to BT). He is a High Frequency Trading infrastructure expert, sharing during conferences his passion about FinTech and the Web. Eric looks after 3 bozons and has worked in San Francisco, NYC, Mexico and now Paris with Streamdata.io.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


A brief history of web and mobile app testing.

BEFORE SAUCE LABS Devices. Delays. Despair.

AFTER SAUCE LABS Automated. Accelerated. Awesome.

Find out how Sauce Labs can accelerate your testing to the speed of awesome. For a demo, please visit saucelabs.com/demo Email sales@saucelabs.com or call (855) 677-0011 to learn more.


SPONSORED OPINION

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

Automated Mobile Testing Requires Both Real Devices and Emulators Organizations committed to delivering high quality mobile apps are faced with making some important choices regarding application testing. Most are forced to ask themselves: • Do we run tests locally, or utilize a cloud service? • Should we use emulators and simulators, real devices, or a combination of both?

Mobile testing cloud services allow organizations to send test scripts to either real devices or emulators and simulators in the cloud. Cloud vendors maintain a wide variety of real devices and simulators and emulators in

their data centers, and using cloud services for mobile testing is often easier and less expensive than maintaining your own infrastructure. Some organizations use emulators and simulators for much of their testing, but use real devices depending on the nature of their apps. Emulators and simulators may provide sufficient coverage for many Web and Hybrid mobile applications. Emulators and simulators are also more affordable than real devices and can support very high parallel testing. On the other hand, many Native apps have hardware dependencies that require real devices to test thoroughly. Any organization that competes in the mobile marketplace needs to carefully think through their testing requirements and determine whether emulators and simulators, real devices, or a combination of both provide the best solution in terms of cost and coverage. The ideal QA strategy often employs a mix of emulators and simulators, and real devices. This addresses the scalability and cost inefficiencies that come with emulators and simulators, while retaining the ability to test under real usage conditions with real devices. WRITTEN BY LUBOS PAROBEK VP OF PRODUCTS, SAUCE L ABS

PARTNER SPOTLIGHT

Mobile Testing Platform

By Sauce Labs

Sauce Labs accelerates the software development process by providing the world’s largest automated testing cloud for mobile and Web applications. PRODUCT Automated Testing Platform

NEW RELEASES

PRODUCT CATEGORY

OPEN SOURCE

Daily

Testing Platform

Yes

• Complete mobile testing platform: emulators, simulators, and real devices

• Automated and manual testing support for Native,

CASE STUDY Dollar Shave Club is a fast-growing e-commerce company that delivers razors and other personal grooming products to millions of members every month. One of the challenges they face is supporting the diverse set of devices and browsers on which people view their Website. They also need to provide feedback to developers as quickly as possible, given that they deploy code more than 15 times per day. Because Sauce Labs integrates with Dollar Shave Club’s Jenkins Continuous Integration (CI) server, the company can test code automatically with each commit, getting results back within 10 minutes of each check-in. Because they are running tests in parallel, the company is saving hundreds of thousands of dollars per year due to the reduction in testing time and in the time it saves their developers. Dollar Shave Club has since expanded to use Sauce Labs for testing its Native mobile applications, running their mobile tests at the same scale as their Web testing.

BLOG saucelabs.com/blog

13

STRENGTHS

Hybrid and mobile Web

• Optimized for CI/CD workflows, testing frameworks, tools, and services

• From the lead contributors to Appium, the de facto open source standard in mobile testing

NOTABLE CUSTOMERS • American Express

• Dropbox

TWITTER @saucelabs

• Intuit

• VISA

• PayPal

• Yahoo!

• Salesforce

• Yelp

WEBSITE saucelabs.com

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

Wireless Communications in Modern Mobile Technologies BY LANCE GLEASON FOUNDER AT POLYGLOT PROGRAMMING LLC.

Today, technology users and consumers are interacting with more devices than ever. Using a smartphone, you can sync a smartwatch, make point-of-sale purchases, control your home’s alarm system, or even fly a drone. Depending on the application, you could be using Bluetooth, Wi-Fi, NFC, or mobile data networks to connect to these devices. As a developer, you may want to create applications for a specific device, or perhaps even develop your own connected device that can be controlled with a smartphone. Before you break out your IDE and start tinkering with hardware, let’s take a quick tour of Bluetooth, Wi-Fi, NFC and mobile data to learn how these technologies work, and which applications each one is best suited for.

NFC Near Field Communication (NFC) describes a set of protocols that enable two devices in close proximity (up to 10 cm apart) to communicate with each other. Like many other proximity card technologies, it employs electromagnetic induction when two devices exchange information in the 13.56MHz range. One device can be an unpowered NFC tag in a label or poster, which means that the reader would simultaneously initiate data reads and provide power to the tag. Data rates typically range between 106-424 kbit/s. NFC supports three different modes:

14

QUICK VIEW 01

Depending on your app, you may want to use Bluetooth, Wi-Fi, NFC, or mobile data to connect devices.

02

NFC is best suited for applications that require very close proximity between devices.

03

Bluetooth requires close proximity, but has a longer range than NFC; Bluetooth LE uses incredibly little power.

04

If your app needs to maintain a constant network connection, let the OS decide whether to use Wi-Fi when available, or to switch to cellular coverage.

• Card Emulation allows a device to act like a smart card. (This is, in fact, the mechanism used for Apple Pay and Android Pay.) • Reader/Writer Mode enables a device to read and write data to NFC tags. • Peer-to-Peer Mode facilitates information exchange between devices in ad-hoc fashion. NFC has a wide range of applications, but of late, mobile payment solutions have been the main drivers for adoption on Android and iOS devices. Generally speaking, NFC is best suited for applications that require very close proximity between a phone and tag or device and secure data exchange. At present, only a limited set of devices support NFC. Compatible iOS devices are iPhone 6/6S/6+/6S+ and Apple Watch models. Apple has not yet opened development access to these sensors via API, so they can only be used for Apple Pay. Android, on the other hand, does offer a development API, but, again, not many Android phones on the market include NFC support, especially not at lower price points.

BLUETOOTH Bluetooth was conceived as a protocol for exchanging data over short distances. It uses the same frequency range as 2.4 GHz Wi-Fi but with 79 channels (for versions below 4.0), and 40 channels for 4.0 and above. However, unlike most Wi-Fi implementations, it uses a technology called frequency-hopping spread spectrum which regularly

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

changes the channel in order to avoid congestion caused by competing networks. Data throughput rates are also a lot higher, ranging from 1 Mbit/s for Bluetooth 1.2 to 24 Mbit/s for 4.0 and above. All iOS and most Android devices support Bluetooth. Some applications of standard Bluetooth include wireless headsets and data tethering.

BLUETOOTH LE Bluetooth LE (Low Energy) is a subset of the Bluetooth 4.0 specification designed for low energy applications. It has a maximum data throughput rate of 0.27 Mbit/s and a power consumption that can be as low as 0.01 W, up to a maximum of 0.5 W (about half of what a standard Bluetooth device consumes.) To put this in perspective: Most smartphone batteries have capacities that range from 14003000 mAh (milliampere hours) but struggle to get more than a day or two of battery life, yet it is not uncommon for a Bluetooth LE-based fitness tracking device with a 100mAh battery to last up to a week or longer. Applications that use Bluetooth LE include fitness trackers, smartwatches, and many medical devices. The LE stack also has a number of predefined generic attribute (GATT) profiles that specify communication mechanisms for various types of devices such as heart rate monitors, blood pressure gauges, or proximity sensors. This means that if a company implements a device to follow the specification, it wouldn’t require proprietary software to retrieve data from it. While not quite as ubiquitous as standard Bluetooth support, device support for Bluetooth LE is, nonetheless, very good. All iPhone models upward of 4S support it, along with iPad 3rd generation or newer. On the Android side, things are a bit more complicated, since the support implementation that first appeared in Android 4.3 was somewhat buggy and limited to central mode (meaning that interaction is restricted to other peripheral Bluetooth LE devices) but the phone cannot act like a peripheral. Android 4.4 provided more stable functionality, and Android 5.0 added support for peripheral advertising. By default, any device that supports Bluetooth 4.0 also supports Bluetooth LE, including older flagship phones such as the Galaxy Nexus and other more recent releases in the Nexus range, as well as tablets like the Nexus 7 2013 and newer models. These days, even inexpensive Android phones such as the LG Lucky, which retails for approximate $10, also offers Bluetooth 4.0 support.

WI-FI AND CELLULAR TECHNOLOGY Most people have used, and are familiar, with these technologies. Cellular networks use radio signals served by fixed-location transceivers (cell base towers) to transmit voice and data and connect mobile devices to the public Internet at speeds that range from the slow 2G to lightningfast LTE. A cellular connection is, generally speaking, more expensive from a cost per Mb perspective, but is more readily available when you’re on the move. All Android and

15

iOS phones and select models of iPad and Android tablets support some form of cellular network connectivity. Wi-Fi is defined as a wireless local area network connection, which may, or may not, connect to resources like the Internet. These networks usually offer faster transmission than cellular connections and are much less expensive per Mb, or even Free. Virtually all iOS and Android devices support Wi-Fi.

For applications that consume lots of data or need to communicate with devices local to a network, Wi-Fi is the recommended solution. As such, it is the typical mechanism used for home automation and video casting. SO, WHAT SHOULD I USE? NFC has compelling use cases, but unless you’re creating an application that needs to scan NFC tags, or allows you to control the hardware and have rigorous security requirements, you may not want to use it in your project. It is obviously the perfect technology for mobile payment applications, but until Apple opens their APIs to application developers, you’ll only reach a limited audience. Bluetooth is a great solution when you need to communicate with a device in close proximity to a phone. A smart device, such as a printer, might use Bluetooth to configure its Wi-Fi settings in order to connect to a network or wireless headphones. When you have a small device with a limited battery capacity that doesn’t need to transfer lots of data, such as a wearable fitness monitor or smartwatch, Bluetooth LE would be ideal. For applications that consume lots of data or need to communicate with devices local to a network, Wi-Fi is the recommended solution. As such, it is the typical mechanism used for home automation and video casting. Some applications may be configured to only download data when connected to a Wi-Fi network, but when an application doesn’t consume a lot of data or, alterNatively, needs to maintain a constant network connection, it’s usually best to let the operating system decide whether to use Wi-Fi when available, or to switch to cellular coverage. L A N C E G L E AS ON obtained his undergrad degree in computer science and mathematics and master’s degree in software engineering. He has done Java development for a diverse range of companies like Kodak, Lockheed, McKesson, CNN, and GE. These days, he practices clean Ruby living as the founder and lead software engineer of Polyglot Programming. In addition, he is a regular speaker at conferences around the world. He is known to practice interspecies pair (“purr”) programming with his orange tabby, Allie, and when he’s not writing code, you will find him diving with sharks, trekking through Chernobyl, or sampling wine.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


Everybody’s all excited about good mobile UX. But the failure of UWP reminds us that developer adoption of an app-driven platform is essential too. Okay: what about mobile D[eveloper]X? How do developers feel about mobile development? We asked 400 mobile developers (a) which pain points do you encounter while developing apps for the following three mobile platforms? and (b) why do you prefer to develop for a particular mobile platform? Their answers are summarized – and emojified – below.

WHAT CAUSES YOU PAIN WHILE DEVELOPING APPS FOR THESE PLATFORMS?

WHY DO YOU PREFER TO DEVELOP FOR A PARTICULAR MOBILE PLATFORM?

(FROM MOST FREQUENT TO LEAST FREQUENT)

1. BUILDING NATIVE APPS FOR MULTIPLE PLATFORMS

WEB

01. FAMILIARITY 3

02. EASE OF USE

1

ANDROID

iOS

2

05. ECOSYSTEM

2. MAINTAINING GOOD PERFORMANCE ON MOBILE HARDWARE

03. POPULARITY

1

iOS

04. TOOLS

3 07. CROSS-PLATFORM

android

06. WORA

WEB

3. LACK OF SKILLED MOBILE DEVELOPERS 09. COMMUNITY

10. COST

ANDROID

1

2

WEB

11. DEV. EXPERIENCE

SINGLE CODE-BASE 14.

2

4. TESTING EFFICIENTLY ON MANY DIFFERENT TYPES OF HARDWARE

13. UX

08. OPENSOURCE

iOS TIED!

15. STANDARDIZATION

1 2

iOS

ANDROID

3 12. FLEXIBILITY

© DZONE.COM, 2016

web

2


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

Native CrossPlatform Mobile Architecture

QUICK VIEW 01

Lessons learned from building mobile apps are shared to help shed light on some best practices to follow when building them.

02

Mobile development is a young, highly segmented area where developers have little experience and few tools.

03

Three key pieces of advice when building an app includes: a shared a testdriven approach, product design principles, and mobile friendly backend

BY PAUL ZABELIN LEAD iOS DEVELOPER AT AMIGO

Mobile apps are meant to be used on the go and up close. We want to have a fast and fluid experience that looks great and works well on handheld devices. At the same time, mobile devices—due to their size—have little memory, slow processors, and spotty network conditions. Mobile development is a young, highly segmented area where we as developers have little experience and few tools. Luckily, when going to market, our competitors are in the same position, and great apps take time to build to app stores. We took the approach of increasing quality through tests and automation and reducing complexity by design. Here I would like to share what I learned from building my first iOS app, immediately followed by an Android app, all while building a Mobile Web app.

METHODOLOGY The first thing we shared across teams and phases were Agile processes and test-driven Development. Both of our Native projects delivered on-time, high-quality apps that got noticed by users and featured in app stores. Things change fast in the mobile world with so much innovation going on around frameworks, developer tools, libraries, and technologies. What helped us to stay on top of the changes were Agile processes and automation. It might sound big, but actually our process was quite light and consisted of:

• • • •

Iterations (weekly or bi-weekly) Retrospective meeting Planning meeting Daily standup

• Continuous integration • Test-driven development • Pair programming

HOW THINGS HAVE GROWN THE “PLANTING SEEDS” PHASE We inherited a legacy backend and mobile Website that had functioned well for a long time, but needed an update. We also wanted to develop a Native experience on a new platform. We started with a hack-week-prototype Native iOS app with no design and a hacked connection to the legacy backend. The iOS

LOOKING BACK

app demonstrated a beautiful image scroll of user content and

We have naturally grown as a team to build great mobile products. Looking back, it is easier to see now what the key factors of successful development of Native apps were: 1) Agile processes and test-driven development; 2) Design and guidelines; and 3) Mobile Backend. Without those three pillars, even with a very talented team, development fails sooner or later. Process gives stability, predictability, and measurable velocity. Test-driven development gives safety to make changes fast—higher velocity with fewer defects. Design makes users happy and reduces complexity. And a mobile backend cuts the complexity of the system, allows apps to scale, supports multiple test and development environments, and allows for mobile networking.

18

embedded Web views. It was well received and understood by people in power, and we got the green light to start building the app for real. For this project, we got one developer, one product manager, and one designer. The developer and designer had to pair a lot on designing the navigation flow and layout of the Native iOS interface. Test driving the iOS code was an investment that paid back well within the first year as the product was changing a lot. The designer and product manager worked together to narrow scope and focus on what was important for the mobile app out of many legacy features of the broader product. The developer put together continuous integration that built and ran tests and also installs

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

the app for everyone to download and try out the latest build. The product manager organized regular iterations with both kickoff and retrospective meetings. We had daily standups to keep everyone up to date and resolve upcoming issues quickly. The team was already familiar with Agile, and everyone understood the benefits of a consistent pace and stable delivery. Often we worked in pairs: developer–designer, developer–product manager, designer–product manager. At this phase we had tamed the backend to run stable on staging, and we had every instance of the mobile client connecting to publicly visible endpoints.

PRODUCT DESIGN PROCESS

GROWTH PHASE

Both teams built a single mobile friendly API incrementing upon each other’s work. The same API got back-ported to the mobile Web app, and now has been opened to third parties, parents, and integrators.

As soon as we got another intern developer, we began pair programming. It helped a lot to onboard developers, share knowledge of code, and stay the course without getting sidetracked and stuck in problem solving. We continued pairing with our designer, who was eager to learn Xcode storyboards and did a great deal of research on what other apps were doing and what we could borrow from opensource and commercial libraries. To enable designer participation, we also included a styling library and tools where the app could be styled using common stylesheets. Having the designer actively participating in storyboards, stylesheets, and research saved developers a lot of time in the long run. The Agile process helped us to be honest to ourselves and stakeholders on what could deliver and on what schedule we could deliver it. We reached a measurable, fairly consistent velocity of delivering features and had a low rate of defects. Within a few months we launched the first version into the App Store and rolled it out in the US using Canada as a first territory.

CLONING AND SCALING PHASE Once we had a tangible success on the iOS platform, naturally we wanted to repeat it on Android. Our product manager was able to pick up Android and learn how to be a user on it. We already knew that we wanted Android developers that could write tests. We had one iOS developer crossing the divide and learning to be an Android developer, bringing with him lessons learned from launching the first app. At the same time, the iOS team released support for four more languages with localized and internationalized versions. At this phase we realized that a mobile backend needs a responsible owner. We got a dedicated backend engineer who was able to build an authentication service API, backend tests based on shared sample data, continuous integration, a versioned API, and scripts that allowed the backend to run on staging, development, and production environments. At this phase we dropped the shared staging server and migrated our Native tests to run against the backend running on localhost. The server team worked on making the local instance able to be configurable to run in development mode with local databases and local services. This enabled us to run tests concurrently without stepping on a lot of toes. While the Android team had a successful launch of their first app, the iOS team had launched Apple Pay integration ahead of the competition.

DESIGN GUIDELINES We worked with embedded designers who shared visual style guide, while we built for our Native apps very different user interfaces. The designers, developers, and managers learned to speak a common, domain-specific language. We all grew in our understanding of common business goals and built very similar implementations. We shared a set of high-level automated acceptance tests written in different languages. The designers shared user-centric design principles and adopted them to each of the three platforms.

19

Here is what I’ve noticed helped us to design a product and reduce the complexity of the solution:

• Pairing developer and designer • Design research • Stylesheet-based appearance customization

• Minimal Viable Product • User Testing

• • • • •

Direct feedback from apps Customer Surveys Responding to user reviews App Store promotion Backend

The central component here was our sample data, which helped our understanding of the business logic, test cases, and core relations. We shared lots of test infrastructure and built solutions suitable for remote and local testing. We did struggle with API ownership, as it was not immediately recognized to be part of the product and was thus shared across multiple teams. We evolved to have dedicated API team that shared code with the rest of server team and priorities with the mobile team.

MOBILE BACKEND Our mobile backed has grown to include:

• • • • • •

Public API Private extension API API versioning scheme OAuth v2 service Sample data visible on mobile Web Local instances

• Special end point to reset and load state

• Staging, production, and development deployments

• API acceptance tests

The OAuth service was a long-term investment that took time to build, but it gave us Freedom to scale while staying secure. We started by having a single staging server where all apps connected and shared data. Our mobile acceptance tests run against that server and reset its state once before the test run. With our team growing, we split to have a couple of staging servers: one for developers, another for accepting user stories. Staging and local instances had additional endpoints to allow us remotely reset server data to a known state. Our development velocity benefited from having multiple local instances of the backend on each developer box. This resolved the issue of concurrent test executions and allowed developers to have independent instances. Continuous integration runs mobile acceptance tests against local instance of server. That local instance had trimmed third-party dependencies with stubs and fakes, for simplicity and performance reasons.

LESSONS LEARNED There were three key areas we can share and reuse across multiple platforms. We shared a test-driven approach, product design principles, and mobile friendly backend. This allowed us to deliver on time without burning people up. Build a great team of people, build close connections with your customers, and have fun doing what we love to do.

PAUL Z A BE L I N is the Lead iOS Developer at AMIGO. With over 20 years of experience in software development, he is a team builder, open source contributor, Test Driven Development Coach, and Agile Mentor. He has built, released, and supported over 60 apps in the AppStore, including over a dozen of his own apps.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


IBM API Connect API Connect integrates IBM StrongLoop and IBM API Management with a built-in gateway, allowing you to create, run, manage, and secure APIs and Microservices.

Unparalleled, integrated user experience.

ibm.biz/apiconnect


SPONSORED OPINION

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

Isomorphic JavaScript Mobile Apps

easier to implement. You have a number of choices of template systems that you can seamlessly share between the client and the server, and you are also able to share business logic written in JavaScript on both the server and client. It’s looking like we have a holy grail: JavaScript everywhere! A number of frameworks support Isomorphic JavaScript (aka “universal JavaScript”), and you can use view frameworks such as on both the server and client. The primary benefits of Isomorphic JavaScript include:

The method of delivering content to a browser has continued to evolve over the years. In the early days, every page was a full payload. With the advent of AJAX--Asynchronous JavaScript and XML--web pages started to become more interactive without full page loads. It didn’t take long for “web apps” to emerge that took the AJAX approach to the next level where every aspect of the app was “AJAX-ified” (these later became known as Single Page Applications--SPAs). Next, content delivery became a hybrid approach. The initial page load was fully formed HTML that the browser could receive and display. Part two of this hybrid process was to backfill the interactivity that we had grown used to. The page would be loaded and functional, and then all of the AJAX interactioSns would be added to enhance the UX.

• SEO: Pages are searchable when they first load. • Perceived performance: Pages load fast, and interactivity is available immediately.

• Actual performance: Initial page load is typically lighter; additional requests are only made to enhance the experience.

• Accessibility: Serving a fully formed HTML page initially better meets accessibility needs; it can be run without JavaScript.

• Better developer experience: Single language codebase with better maintainability and less context switching; shared code; shared tooling. All of this adds up to being the best of all worlds. Read the full article here.

As node.js has become the go-to choice for the backend for web apps, this hybrid approach has become highly favorable and

WRITTEN BY JOE CRANE-MESSINA LEAD STRONGLOOP & NODE.JS DEVELOPER EVANGELIST, IBM

PARTNER SPOTLIGHT

API Connect

By StrongLoop and IBM

IBM API Connect is a complete solution that addresses all aspects of the API lifecycle Create Run, Manage, Secure - for both on-premises and cloud environments. PRODUCT CATEGORY

NEW RELEASES

OPEN SOURCE

STRENGTHS

As needed

no

• Simplify discovery of enterprise systems of record for

API Management

automated API creation

• Provide self-service access for internal and third-party

API LIFECYCLE

developers through a market-leading gateway

IBM API Connect offers features to manage the API lifecycle, including:

• Ensure security and governance across the API lifecycle

Create—create high-quality, scalable and secure APIs for application servers, databases, enterprise service buses (ESB) and mainframes in minutes.

• Unify management of node.js and Java microservice

Run—take advantage of integrated tooling to build, debug and deploy APIs and microservices using the node.js or Java.

• Increase flexibility with hybrid cloud deployment

Manage—create and manage portals that allow developers to quickly discover and consume APIs and securely access enterprise data, and monitor APIs to improve performance.

FEATURES

Secure—Administrators can manage security and governance over APIs and the microservices. IT can set and enforce API policies to secure back-end information assets and comply with governance and regulatory mandates. BLOG developer.ibm.com/answers/topics/apim

21

TWITTER @ibmapiconnect

applications

• Quickly run APIs and microservices

• Manage API’s with ease

• Readily secure APIs and microservices

• Create API’s in minutes

• Unified Console

WEBSITE ibm.com/software/products/en/api-connect

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

The Changing Mobile OS Landscape IN THE ENTERPRISE BY MARK KIRSTEIN SR. DIRECTOR PRODUCT MANAGEMENT AT ZEBRA TECHNOLOGIES

As Windows Mobile and Windows CE prepare to ride off into the sunset, the time is now for enterprise developers to begin accepting nominations for their mobile operating system (OS) of the future. Raising the stakes for this decision-making, enterprise app developers are finding it more critical than ever to correctly anticipate industry trends and execute plans based on accurate foresight. This is a necessity caused by the more expansive, globalized nature of industrial software deployments that leads to lengthier firmware lifecycles, less frequent upgrades, and greater time and resources required to develop, distribute, and support new mobile solutions. Windows Mobile (now called Windows Embedded Handheld) and Windows CE (both of which, to be clear, are unrelated to Windows Phone) remain supported until 2020, but this is a blink of an eye in the industrial software world. Given the impeding latency of delivering new solutions, enterprise developers need to select and execute their transition to their business’ next mobile operating system well ahead of the end of this decade.

SHOULD ENTERPRISES SIMPLY JUMP FROM ONE WINDOWS TO THE NEXT? More than 15 million enterprise devices are currently dependent on legacy Windows OSes for which support is due to expire. Developers, though, might be wise to redefine this crisis as an opportunity, using it as a reason to perform app redesigns that incorporate fresh features like multi-touch, gestures, the latest in user interface (UI) best practices, etc. Even for enterprises moving from a sunsetting Windows OS to Windows 10 (and obviously for those selecting Android or another OS

22

QUICK VIEW 01

Enterprise app developers have determined that it is very critical to correctly anticipate the industry trends to prepare for the future mobile operating systems.

02

As there are impeding latencies of delivering new solutions, enterprise developers need to select and execute their transition to their business’ next mobile operating system.

03

Windows 10, iOS, and Android can all help curtail enterprise OS fragmentation and provide a reliable longevity to enterprises seeking to invest in a new mobile OS that will go the distance.

entirely), the transition will require a complete software rebuild. Developers working on mobile apps for enterprise and industrial environments should find the Windows 10 OS well-equipped for their needs, with enterprise-grade security, identity and information protections, and simplified highlycapable management and deployment features.

ANDROID’S MOMENTUM Android, though, is really in the incredibly favorable position of capturing more attention of developers in search of their next mobile enterprise OS. According to IT research firm IDC, Android has now snapped up 84% of the overall device market globally, arguably placing it in the driver’s seat to capture a dominant position in the enterprise-specific mobile OS market as well. Android for enterprise is certainly already gaining the attention of developers. A report from Vision Mobile discovered that Android has become the OS that enterprise developers are now most commonly developing for, with 74% of developers targeting the platform.

FOR ANDROID, FIRST YOU WIN THE CONSUMER, THEN YOU WIN THE ENTERPRISE Android’s consumer popularity feeds several factors that set the stage for its success across enterprise dev environments. In fact, Android’s probably now poised for a long-term run as the top OS prospect for developers to build their enterprise apps upon. Developing for the dominant OS is good, and enterprises should understand the ways that the consumer marketplace will often precede and complement major shifts in enterprise technology adoption. Among the chief advantages when developing enterprise apps for a widely popular OS is that of simple familiarity. When workers already know the particulars of a device’s user

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

interface and can interact with a new enterprise app intuitively because they are accustomed to the same general user experience as the personal devices they have at home, the time and cost to train them in using the new app is vastly reduced. This is a big advantage for Android, since according to the IDC findings mentioned above, as many as four of every five workers may already have an Android device in their pockets (again, looking at a global population). Beyond just users, though, enterprise developers should consider the ecosystem surrounding a mobile OS. Success on the consumer side of the industry draws favorable attention from technology vendors, who recognize the long-term stability of the platform. They also invest in learning about and getting the most out of the technology, while making business planning decisions to provide deeper support. Additionally, an OS with wide popularity develops an ecosystem that provides more developed and accessible programmer resources, tools, and critical application support. And popular consumer OSes give rise to prosumer applications and services, which enterprises and developers can often utilize easily through app store delivery. It should also be noted that Java is used to develop Android apps, which just happens to be among the world’s most popular programming languages (popularity which has risen substantially between 2014 and 2015). Therefore, software vendors are incentivized to develop for Android not only because it’s the platform with the largest installed base, but also because the methods of development are familiar and comfortable to a higher percentage of developers. Vision Mobile finds that 38% of developers are utilizing Java, second only to HTML5 at 42%. The fact that Android is more or less open source software – and that it provides the inner-workings for the platforms used by Amazon devices (think Kindles) and Xiaomi (the world’s fourth largest smartphone maker) – should only boost its appeal to enterprise app developers.

AND ANDROID IS ADAPTING TO ENTERPRISE NEEDS We’re already seeing Android serving enterprises today much better than earlier, more consumer-centric versions. Prominent among the changes has been the shoring up of Android into a highly secure platform. Android’s reputation as a choice for enterprise was affected by early security issues, especially its allowance of malware apps to be distributed on Google Play (reminder to developers: a secure enterprise app shouldn’t have unfiltered access to Google Play Anyway). Android releases before October 2011 also lacked essential security features that have since been added, such as encrypted credential stores, full drive encryption, extensible VPN support and others. On the subject of Android adoption for embedded systems and M2M deployments, research firm VDC noted: “Engineers’ concerns about Android’s security are diminishing, and their willingness to use Android for an expanding range of applications is on the rise.” As it stands, Android now meets the regulatory security certifications in use across a number of industries, including government (FIPS 140-2), retail (PCI-DSS), and healthcare (HIPAA).

VIRTUALIZE TO MODERNIZE Enterprises may find virtualization to be a wise method of granting extra life to their existing apps, enabling them to run

23

on modern platforms. Technologies like iFactr can offer the faster, less expensive, and lower risk option of virtualizing apps – and adding modernized user experience aspects while leaving the user’s familiarity and the app’s functionality intact. In this way, enterprises needing to move to new devices because of sunsetting support can enjoy a simplified, more predictable migration.

LIVE LONG AND PROSPER Given the root cause of why most enterprises must search for a new OS to tie to their mobile needs in the first place – the end of support for their current OS, as is the case for Windows CE and Windows Mobile users – the longevity of a popular platform is one of the strongest arguments for why developers should adopt them. While certain versions may sunset, there can be no doubt that Android will be supported and available in some form as far into the future as the eye can see, representing a tangible value for enterprises in their long-term planning. History is littered with counterexamples of mobile OS choices forced to exit enterprise consideration because they stumbled in the consumer marketplace and ceased to be. Take a moment to remember Samsung’s Bada OS (a contender for two-and-a-half years), Windows Phone 7 (two years), and Microsoft Kin (just four months).

SO WHAT ABOUT iOS? Of the multiple other platforms out there for enterprise developers to consider, iOS controls nearly the entire consumer marketshare not held by Android – which, globally, is about 20% according to IDC. In the United States, of course, iOS’ popularity is higher. The Vision Mobile report also finds that, like Android, iOS is targeted by a majority of developers, who develop for about 1.75 platforms on average. It may make sense for enterprises to consider iOS as another mobile OS with similar popularity advantages to Android but on a smaller, less near-ubiquitous scope. Certain businesses possessing special circumstances for which iOS makes sense – a synergy or affinity for Apple products, for instance – should also be able to realize the benefits of leveraging a successful consumer OS as mentioned above.

IN CONCLUSION… Windows 10, iOS, and (especially) Android all potentially have what it takes to curtail enterprise OS fragmentation, leverage workers’ existing familiarity, and provide reliable longevity to enterprises seeking to invest in a new mobile OS that will go the distance and enjoy robust vendor support. (But certainly Android, with its global ubiquity and association with Java, can be seen as having the inside track to win even more of the enterprise mobile OS market.) Those enterprise developers seeing the sunset of their current OS and in need of a new platform should weigh this information along with their specific needs – but also begin as soon as possible to put their transition plan into action.

M A R K K I R ST E I N is the Senior Director of Product Management for Zebra Technologies. He has over 15 years of technical and architectural experience in inventing patentable enterprise-class software and a successful track record of building innovative technology.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

Diving Deeper I NTO M O B I LE A P P LI CATI O N D E V E LO P M E NT

TOP #MOBILE TWITTER FEEDS

TO FOLLOW RIGHT AWAY

@asymco

@AndroidDev

@rwenderlich

@appleinsider

@sugrue

@mashablemobile

@nraboy

@b1tr0t

@theMrMobile

@MobileLim

MOBILE ZONES

LEARN MORE & ENGAGE YOUR PEERS IN OUR MOBILE-RELATED TOPIC PORTALS

Mobile Zone

Web Dev Zone

IoT Zone

dzone.com/mobile

dzone.com/web-development

dzone.com/iot

The Mobile Zone features the most current content for mobile developers. Here you’ll find expert opinions on the latest mobile platforms, including Android, iOS, and Windows Phone. You can find in-depth code tutorials, editorials spotlighting the latest development trends, and insight on upcoming OS releases. The Mobile Zone delivers unparalleled information to developers using any framework or platform.

Web professionals make up one of the largest sections of IT audiences; we are collecting content that helps Web professionals navigate in a world of quickly changing language protocols, trending frameworks, and new standards for user experience. The Web Dev Zone is devoted to all things Web development—and that includes everything from front-end user experience to back-end optimization, JavaScript frameworks, and Web design. Popular Web technology news and releases will be covered alongside mainstay Web languages.

The Internet of Things (IoT) Zone features all aspects of this multifaceted technology movement. Here you’ll find information related to IoT, including Machine to Machine (M2M), real-time data, fog computing, haptics, open distributed computing, and other hot topics. The IoT Zone goes beyond home automation to include wearables, business-oriented technology, and more.

TOP MOBILE REFCARDZ

TOP MOBILE WEBSITES

TOP MOBILE NEWSLETTERS

Swift Essentials

TheVerge.com/Mobile

AndroidWeekly.net

dzone.com/refcardz/swift-essentials Explore the essentials of this open source, type-safe, object-oriented programming language.

The Verge/Mobile - Covers hot topics and tech trends for Mobile development.

Android Weekly - newlsetter that provides current happenings in the Android world.

HTML5 Mobile Development

Developer.Android.com/Develop

IoSDevWeekly.com

dzone.com/refcardz/html5-mobile-development Introduces Mahout, a library for scalable machine learning, and studies potential applications through two Mahout projects.

Android Developer Blog - provides resources to get you started developing and desiging for Android.

iOS Dev Weekly – provides current trends and topics in the iOS field.

Mobile Web Application Testing

Developer.Apple.com/News

MobileWebWeekly.co

iOS Developer Blog - that provides news and updates on all things iOS.

Mobile Web Weekly – a weekly round-up of articles, newsworthy events, and links that relate to the mobile-facing Web.

dzone.com/refcardz/mobile-Web-application-testing

Covers many tools that will help to simplify the complexities of the mobile testing process, saving you time and money.

24

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

Essential Android & iOS Libraries C H E C K L I S T BY JA M E S S U G R U E , C H I E F I N N OVAT I O N & I N F O R M AT I O N O F F I C E R , C A R M A

There’s been no better time to be a mobile app developer, with thousands of libraries available for almost any conceivable widget, task, or function. Instead of getting overwhelmed by choice, here is a list of what we consider to be the most essential libraries for each platform.

COMMON

THE FOLLOWING LIBRARIES ARE AVAILABLE FOR BOTH IOS AND ANDROID.

LIBRARY

CATEGORY

DESCRIPTION

FABRIC

Utilities

As well as including Crashlytics for crash reporting, it includes tools for analytics, monetization, and speech recognition.

STRIPE

Payment

Accept payments in apps with pre-built payment forms. Stripe handles storage of card details and processing subscriptions. Full Apple Pay integration on iOS.

iOS

FOR IOS WE ARE FOCUSED ONLY ON SWIFT LIBRARIES. WHILE THERE ARE STILL LOTS OF OBJECTIVE-C DEVELOPERS AND APPLICATIONS IN ACTION AT THE MOMENT, YOU’LL FIND THE MAJORITY OF NEW APPS ARE BEING STARTED WITH SWIFT.

ALAMOFIRE

Network

HTTP networking with features like chainable request/response methods, progress tracking, and TLS certificates.

SWIFTYJSON

Network

Makes it easier and less verbose to handle JSON data. It can be put together with Alamofire to process the results of JSON API calls.

QUICK

Testing

Behavior driven framework for Swift and Objective-C.

SWIFT FACEBOOK SDK

Social Network

The official SDK from Facebook for Swift, allowing you to integrate logins, sharing, app events, and the graph API into your applications. Currently in beta.

OBJECTMAPPER

Storage

Simple JSON-to-object mapping allowing you to convert model objects (classes and structs) to and from JSON.

EUREKA

User Interface

Elegant iOS form builder, making it easier to create forms by extending a FormViewController with a straightforward API.

REACTIVECOCOA

Coding

Cocoa framework inspired by Functional Reactive Programming where event streams send values over time.

RXSWIFT

Coding

A newer reactive programming framework, part of ReactiveX. If you’re familiar with RxJava, it can be easier to pick up.

KINGFISHER

Network

Lightweight and pure Swift-implemented library for downloading and caching images from the Web.

CHARTS

User Interface

Charting library allowing the creation of line, bar, pie, scatter, bubble, candlestick. and radar charts.

SPRING

User Interface

A library that simplifies animations. Behaviors can be applied to elements by adding a few properties.

CORESTORE

Storage

Unleashing the real power of Core Data with the elegance and safety of Swift. Ideal for people who don’t want to use Core Data directly.

SNAPKIT

User Interface

A Swift Auto Layout DSL. The API can be easier to work with than using Storyboards.

PROMISEKIT

Coding

An implementation of Promises for iOS developers, allowing asynchronous programming.

SURGE

Coding

Uses the Accelerate framework to provide high-performance functions for matrix math, digital signal processing, and image manipulation.

TYPHOON

Coding

The most established dependency injection library for Swift and Objective-C.

DAGGER

Coding

Dependency injection library for Android and Java applications from Square.

RXANDROID

Coding

Android-specific binding for the RxJava library, allowing you to create reactive components.

ROBOLECTRIC

Testing

Unit testing library for Android, where your tests run from inside your IDE.

RETROFIT

Networking

Type-safe HTTP client, turning your HTTP API into a Java interface.

EVENTBUS

Coding

A publish/subscribe event bus that simplifies communication between Activities, Fragments, Threads, and Services.

BUTTERKNIFE

Coding

Bind Android views and callbacks to fields and methods using annotations.

GUAVA

Coding

A set of Google core libraries used to deal with collections, caching, primitives, concurrency, annotations, string processing, and I/O.

MPANDROIDCHART

User Interface

A powerful Android chart view/graph view library, supporting line, bar, pie, radar, bubble, and candlestick charts as well as scaling, dragging, and animations.

LEAKCANARY

Utilities

A memory leak detection library for Android and Java that can be embedded directly into your app.

FRESCO

Network

Takes care of image loading and display so you don't have to. It will load images from the network, local storage, or local resources, and display a placeholder until the image has arrived.

ANDROIDVIEWANIMATIONS

User Interface

A library that allows a number of animation effects in your Android application.

ICEPICK

Coding

Eliminates the boilerplate of saving and restoring instance state.

ESPRESSO

Testing

Allows you to write concise and reliable Android UI tests.

ANDROIDANNOTATIONS

Coding

Reduce boilerplate and simplify code in your Android app with some simple annotations.

GLIDE

User interface

Image loading and caching focused on smooth scrolling.

ANDROID

25

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

QUICK VIEW

Executive Insights on Mobile Application Development

01

While expert developers may be able to provide an excellent UX with HTML5, Native apps are still the way to go to provide the ultimate UX on a specific device.

02

Because of the UX provided by Native mobile apps, user expectations about the acceptable performance of any app have grown and continue to drive the development of apps.

03

Mobile apps need to provide a seamless experience across devices and platforms; as such, think mobile first and then think about how the app runs across all other devices.

BY TOM SMITH RESEARCH ANALYST AT DZONE

We interviewed 17 executives across a wide-range of industries, all of whom have been involved with Native mobile app development for at least four years. Here’s who we spoke to: CARLA BORSOI, Software Product Manager and Marketing Lead, 6SensorLabs DAN BRICKLIN, CTO, Alpha Software ADAM FINGERMAN, Co-Founder and Chief Experience Officer, ArcTouch NISHANT PATEL, CTO and Kurt Collins, Director of Technology Evangelism, Built.io TYSON WHITTEN, API Management Product Marketing, CA Technologies RAJIV TAORI, VP Product Management Mobile Platforms Group, Citrix ZACH SLAYTON, VP Digital Technology Solutions, Collaborative Consulting BRAD BUSH, COO, Dialexa CRAIG LUREY, CTO and Co-Founder, Keeper Security JESSICA RUSIN, Senior Director of Development, MobileDay STEVEN JOVANELLY, Senior Director, Innovation Lab, PGi BRANDON SATROM, GM Developer Platforms and Tools, Progress Software EDDIE DE GUIA, Co-Founder and Managing Director, PubNative HANS ASHLOCK, Technical Marketing Manager, Qualisystems MARK KIRSTEIN, Senior Director of Enterprise Software, RhoMobile LUBOS PAROBEK, VP of Products, Sauce Labs JUSTIN BOUGHER, Vice President of Product, SiteSpect

KEY FINDINGS 01 The definition of Native mobile app development was

fairly consistent across our respondents, with the common elements being:

26

• Written to the SDK of the platform and the OS of the manufacturer. • Engineered specifically for the phone, device specific. • Running locally on the device. • Purpose build to provide the optimal mobile experience. While a couple of respondents felt you could achieve an acceptable user experience (UX) with a well-written app in HTML5, ultimately everyone agreed Native mobile apps are necessary to integrate a wide range of complex sensors, displays, and systems to create a highly intuitive, streamlined, immersive, and anthropomorphic experience. 02 The most important elements of Native mobile app development mentioned were a robust UX, the speed with which developers can develop and users use the app, and incorporating the new features of the operating system (OS) and the device.

Making the app so intuitive the user uses it without even thinking about it is a sign of success. The ideal Native mobile application is anthropomorphic, creating the perception the device it’s running on is an extension of the person using and interacting with it. The speed of building on the tools enables developers to get the app to market quicker while the speed of the UX will determine whether or not the app will continue to be used by the end user. The end user is much less likely to tolerate latency issues on a mobile app than a Web app. The ability to provide the end user with a holistic experience by using several of the tools their phone has built in (i.e. GPS, camera, accelerometer, calendaring) will result in an app that adds more value to the device while making the end user’s life easier. This enhances the use and recommendation of the app.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

03 There are three areas of problems solved by Native mobile apps:

• They enable users to get the most from their mobile devices with a seamless, smooth, and intuitive UX. • They give end users a dedicated space that allows them to accomplish a specific task, project, or goal helping them be more productive. • The speed at which the apps work is tremendously beneficial, as well as expected by end users. 04 Knowledge of the platform and the language was mentioned most frequently as the skill that makes someone good at developing Native mobile apps. Respondents noted that it was rare to find someone knowledgeable about more than one platform but if you were, you would be in great demand. Also important are UX and design skills and the empathy to understand user needs and wants. Rather than thinking “mobile first,” one respondent suggested that we need to think “mobile only” because if you can get an app to work on a mobile device, it’s easy to scale up in size to other devices, including the Web. 05 There was a diverse range of opinions on how Native mobile app development has evolved. A couple of consistent themes are how the operating systems have consolidated and driven developers to build and the platform to provide the ultimate UX. Apps have become more complex, more sophisticated, and more important driven by end-user needs and expectations as well as the respective App Stores. While there is some debate over whether or not we’re settling into a Native mobile app world, or a combination with Web-based HTML5 and Hybrid, there is agreement that Native mobile apps provide the optimal UX for a particular device. 06 The three primary obstacles to success are the: 1) multiple platforms, depth of knowledge required to work on them, and how frequently they evolve; 2) the lack of skilled developers that know the platforms and the languages; and, 3) client expectations around what can be done, when, and for what price. Clients need to be encouraged to prioritize needs versus wants and understand the limitations with regards to time, talent and budget given the dearth of skilled developers as quickly as mobile has grown and how fast the platforms are evolving.

While none of the respondents had any significant concerns with the state of Native mobile app development, several interesting considerations were raised:

• How do we ensure apps are accessible to everyone given that a significant number of people do not have smartphones? • We’ve trained customers to think apps are easy and cheap to develop and they’re not. • Security of apps is a huge issue, especially as users have more information on their mobile devices. • How do I fit the Apple Store approval process into my release cadence? 07 Respondents’ vision for the future were remarkably similar as they see the evolution of mobile across IoT, wearables, microdevices, cars, homes, Apple TV, Amazon

27

Echo, et al. The key will be to integrate all of the data these devices capture on the backend to improve end-users’ lives and to make field workers more productive thereby creating significant value through automation, analytics, and intelligence. 09 The three consistent pieces of advice we received when we asked “what do developers need to keep in mind with regards to Native mobile app development?” were:

• Don’t sit still, technology is changing quickly, and you need to stay abreast of new languages (e.g. Swift for iOS), evolutions of platforms, and improvements to hardware. • Pick a platform you are most passionate about and become an expert. Platforms are evolving so quickly you will do well to master one rather than just be adequate at two. • Be flexible and be sensitive to design. Make sure to design in a way that you’re able to iterate easily. Be open to user feedback and respond quickly. 10 At the conclusion of each interview, we ask respondents what we failed to talk about that they think is important with regard to Native mobile apps. Here’s what some of our executive respondents had to offer:

• Be friends with a good graphic designer. UX is going to become more important as the real estate become more diverse and smaller. • Think about what we’re doing with the data our apps generate and collect. • How do we balance the spectrum of options and get the experience(s) to fit together? Realize the end user may not know what’s possible. • Developers love open source. GitHub enables developers to become familiar with the technologies and collaborate via Websites, while hackathons provide access to APIs. • Think about how devices are interconnected and the underlying network infrastructure that facilitates these connections. • Cross-platform development tools may enable you to write once. A base level of functionality may be appropriate for some situations. • The mobile developers of today are the IoT developers of tomorrow. • Apps that are used globally need to consider network bandwidth. The bandwidth in South Korea, is superior to the U.S., which is superior to most other countries. The executives we spoke with are working on their own apps or designing them for clients. We’re interested in hearing from developers and other IT professionals to see if these insights offer real value. Is it helpful to see what other companies are working on from a senior industry-level perspective? Do their insights resonate with what you’re experiencing at your firm? We welcome your feedback at research@dzone.com. TOM S M I T H is a Research Analyst at DZone who excels at gathering insights from analytics—both quantitative and qualitative—to drive business results. His passion is sharing information of value to help people succeed. In his spare time, you can find him either eating at Chipotle or working out at the gym.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

Solutions Directory What’s better than great mobile platforms? Powerful end-to-end mobile development toolchains. We’ve gathered 78 solutions below, plus another 28 more focused libraries for Android and iOS on page 25. Check them out below and let us know what we've missed.

28

PRODUCT

COMPANY

TYPE

DEPLOY TO

FREE TRIAL

WEBSITE

Adobe Experience Manager for Mobile

Adobe

MADP

Native, Hybrid

Contact for more info

adobe.com/marketing-cloud/ enterprise-content-management. html

Alpha Anywhere

Alpha Software

Enterprise RMAD

Web, Hybrid

30 days

alphasoftware.com

Angular.js

Google

Web framework, app-centric

Web

Open-source

angularjs.org

AnyPresence

AnyPresence

mBaaS

Any

30 days

Anypresence.com/solutions/ mbaas

Apkudo

Apkudo

Mobile test automation

Any

Contact for more info

apkudo.com

App Cloud Mobile

Salesforce

MADP

Native, Web, Hybrid

Contact for more info

salesforce.com/platform/ solutions/mobile

Appcelerator Platform

Axway

Builder -> Native + mBaaS

Native, Web, Hybrid

Free until publish

appcelerator.com

Appery.io

Appery

Builder -> Hybrid + mBaaS

Web, Hybrid

Free tier available

appery.io

AppGyver Compose

AppGyver

Enterprise RMAD, mBaaS

Web, Hybrid

no

appgyver.com

Appian

Axway

RMAD+BPM

Native, Web, Hybrid

Contact for more info

appian.com/bpm-software/ mobile-applicationdevelopment

Appium

Sauce Labs

Mobile test automation

Native, Web, Hybrid

Open-source

appium.io

AppMachine

AppMachine

RMAD+publishing

Cross-Platform Native

Free until publish

appmachine.com

AppMobi

AppMobi

Mobile security platform w/ Cordova focus

Native, Hybrid

Free Trial

appmobi.com

AppPulse

HP Enterprise

Mobile APM

Native, Web, Hybrid

Free tier available

www8.hp.com/us/en/softwaresolutions/apppulse-mobile-appapm-monitoring/developers.html

Apprenda

Apprenda

Private PaaS w/mBaaS (Java + .NET)

Any

Free trial available

apprenda.com/solutions/mobileapplications

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

29

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

PRODUCT

COMPANY

TYPE

DEPLOY TO

FREE TRIAL

WEBSITE

Apteligent

Apteligent

Mobile crash reporting and app intelligence

Any

Free tier available

apteligent.com

Backbase CXP

Backbase

MADP w/cross-platform widgets, mBaaS, CMS, portal

Native, Web, Hybrid

Contact for more info

backbase.com/products/cxp

Backendless Platform

Backendless

mBaaS w/API marketplace

Any

Free tiers available

backendless.com

Bootstrap

- (originally Twitter)

Web framework, contentcentric

Web

Open-source

getbootstrap.com

CA Mobile Device Management

CA Technologies

BYOD on-premise or SaaS

Any

Contact for more info

www3.ca.com/us/opscenter/ ca-mobile-device-managementmdm.aspx

Catavolt

Catavolt

RMAD+React Native

Native, Hybrid

Contact for more info

catavolt.com

Codename One

Codename One

Java -> multi-platform Native

Cross-Platform Native

Free tier available

codenameone.com

Cordova

- (originally Adobe)

JavaScript->Hybrid wrapper

Hybrid

Free

cordova.apache.org

Corona Labs

Corona Labs

Cross-platform graphicsintensive mobile SDK

Native (iOS, Android)

Free

coronalabs.com

Corona SDK

Corona Labs

Cross-platform mobile game platform

Cross-Platform Native

Free

coronalabs.com/corona-sdk

DevExtreme Mobile

Developer Express

Cross-platform component suite

Native, Web, Hybrid

60 days

devexpress.com

Dojo Toolkit

Dojo Foundation

Web framework, app-centric

Web

Open-source

dojotoolkit.org

DSI

Dispatching Solutions

MADP for supply chain

Native

Contact for more info

dsiglobal.com/platformtechnology/mobile-platform

Mobility and Workplace Solutions

HP Enterprise

Enterprise MDM, app store, gateway, device management & testing integrations

Any

Contact for more info

hpe.com/us/en/solutions/ mobility.html

Greenhouse CI

Greenhouse

CI for Android, iOS, Cordova, Ionic

Native, Web, Hybrid

Free tier available

greenhouseci.com

HockeyApp

Microsoft

Distribution, feedback, analytics

Any

Free for 2 apps

hockeyapp.net

IBM MobileFirst

IBM

MADP

Native, Hybrid

Free Trial

ibm.com/mobilefirst

iFactr

Zebra Technologies

MADP (.NET->cross-platform)

Native, Web, Hybrid

Contact for more info

ifactr.com/

Intel XDK

Intel

JavaScript->Hybrid

Hybrid, Web

Free

software.intel.com/en-us/ intel-xdk

Ionic

Drifty

Cross-platform mobile framework (HTML5->Native)

Web, Hybrid

Open-source

ionicframework.com

jQuery Mobile

jQuery Foundation

Web framework, contentcentric

Web

Open-source

jquerymobile.com

KendoUI

Telerik

Web framework, app-centric

Web

Open-source

telerik.com

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

30

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

PRODUCT

COMPANY

TYPE

DEPLOY TO

FREE TRIAL

WEBSITE

Kinvey

Kinvey

Enterprise mBaaS

Any

Free tier available

kinvey.com

Kony

Kony

MADP

Native, Web, Hybrid

90 days

kony.com

Kumulos

Kumulos

Growth platform + mBaaS

Any

Free trial available

kumulos.com

LiveCode

LiveCode

xTalk scripting -> Native&HTML5

Native, Web, Hybrid

Open-Source Version Available

livecode.com

Mendix App Platform

Mendix

MADP

Native, Web, Hybrid

Free tier available

mendix.com

Mobile Angular UI

-

Angular.JS + Bootstrap for mobile

Web

Open-source

mobileangularui.com

Mobile Labs

Mobile Labs

Mobile application testing

Any

Free trial available

mobilelabsinc.com

MobileFrame

MobileFrame

Enterprise MADP

Native, Web, Hybrid

Contact for more info

mobileframe.com/mobile-appdevelopment-platform

MobileSmith

MobileSmith

Enterprise RMAD

Native

Contact for more info

mobilesmith.com

MobileTogether

Altova

Enterprise RMAD + mBaaS

Web, Native

Front-end Free; Back-end 30 day trial

altova.com/mobiletogether.html

Modo Labs

Modo Labs

RMAD+vertical-specific middleware

Cross-Platform

Contact for more info

modolabs.com

NativeScript

Progress Software

Cross-platform mobile framework (HTML5->Native)

Cross-Platform Native

Open-source

nativescript.org

OnsenUI

Monaca

Web framework, contentcentric

Hybrid

Open-source

onsen.io

Oracle Mobile Platform

Oracle

Java|JavaScript->Hybrid + mBaaS

Hybrid

Contact for more info

oracle.com/us/technologies/ mobile/overview

OutSystems

OutSystems

RAD+HTML5+backend

Hybrid, Web

30 days

outsystems.com

Pega Mobility

Pegasystems

MADP w/BPM

Native, Web, Hybrid

Contact for more info

pega.com/products/pega-7platform/mobile

Perfecto

Perfecto Mobile

Mobile test automation, performance testing w/real devices

Any

Free Trial

perfectomobile.com

PhoneGap Build

Adobe

HTML5 -> Hybrid w/cloud build

Hybrid

Free tier available

build.phonegap.com

Pyze

Pyze

Mobile app user analytics & management

Any

Free tier available

pyze.com

RAD Studio

Embarcadero

Cross-Platform Native (desktop + mobile)

Native

30 days

embarcadero.com/products/ rad-studio

Rainforest QA

Rainforest

Mobile test platform (functional and regression)

Native, Web, Hybrid

Contact for more info

rainforestqa.com

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

31

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

PRODUCT

COMPANY

TYPE

DEPLOY TO

FREE TRIAL

WEBSITE

React.js

- (originally Facebook)

Web framework, contentcentric

Web

Open-source

facebook.github.io/react

React Native

- (originally Facebook)

JavaScript -> Native

Native

Open-source

facebook.github.io/react-native

Reappt

Push Technology

Real-time messaging

Any

Free tier available

reappt.io

Red Hat Mobile Application Platform

Red Hat

MADP

Native, Web, Hybrid

Contact for more info

redhat.com/en/technologies/ mobile/application-platform

RhoMobile

Zebra Technologies

JavaScript|Ruby->HTML5

Web

Open-source

developer.zebra.com/ community/rhomobile-suite

SAP Mobile Platform

SAP

MADP

Native, Hybrid

Free Trial

go.sap.com/product/ technology-platform/mobileapp-development-platform.html

SauceLabs Mobile

SauceLabs

Test Automation - Emulator, Simulators & Real Devices

Native, Web, Hybrid

14 days

saucelabs.com

Sencha Platform

Sencha

RMAD w/ ExtJS+testing(Jasmine); Java->JS

Web

30 days

sencha.com

Sencha Touch

Sencha

Web framework, app-centric

Web

Open-source

sencha.com

SmartClient

Isomorphic

Java->Ajax framework (GWT) + cross-browser UI components

Web

60 days

smartclient.com/product/ smartclient.jsp

Smartface

Smartface

HTML5 -> Native w/ cloud IDE+collaboration +build+distribute

Cross-Platform Native

Free tier available

smartface.io

Telerik Platform

Progress Software

MADP

Native, Hybrid, Web

30 days

telerik.com/platform#overview

Titanium

Appcelerator

HTML5 -> Native

Native, Web, Hybrid

Open-source

appcelerator.org

Vaadin TouchKit

Vaadin

Java EE -> cross-platform mobile UI

Web

Open-source

vaadin.com

Ubertesters

Ubertesters

Mobile app testing

cross-platform

Free tier available

ubertesters.com

Waygum

Waygum

Mobile apps + mBaaS for industrial IoT

Native (iOS, Android)

Contact for more info

waygum.io

Wijmo

GrapeCity

JavaScript UI controls & jQuery widgets

Web

no

wijmo.com

WSO2 Enterprise Mobility Manager

WSO2

Enterprise mobility management

Any

Contact for more info

wso2.com/products/enterprisemobility-manager

Xamarin

Microsoft

C# -> Android, iOS

Cross-Platform Native

Open-source

xamarin.com

XenMobile

Citrix

Enterprise mobility management

Cross-Platform

Contact for more info

citrix.com/products/xenmobile

Xojo

Xojo

RAD+BASIC dialect -> CrossPlatform Native

Native

no

xojo.com

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


DZONE.COM/GUIDES

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III

GLOSSARY BLUETOOTH A wireless technology networking protocol used to exchange data over short distances. Uses frequencyhopping spread spectrum technology, which regularly changes the channel in order to avoid congestion caused by competing networks.

DATA ANIMATION The idea of exposing to the end user the change of data, provided the data is changing quite a lot.

DEVICE API A mobile platform-specific API that lets applications access specific mobile hardware functionality. HYBRID APP A mobile application written in HTML, CSS, and JavaScript that uses a web-to-native abstraction layer, allowing the application to access mobile device APIs that pure web applications cannot access. MOBILE APP An application developed for the use on small, wireless devices such as tablets and smartphones. They can be webbased, native, or hybrid. MOBILE BACKEND AS A SERVICE (MBAAS) A service that connects

32

mobile applications to cloud databases while also providing user management, push notifications, and social integrations. MOBILE DATA Data that is transferred via mobile carrier from one smartphone to another. MOBILE OS An operating system designed specifically to run on mobile devices. MQTT A messaging protocol that is lightweight and provides network clients with a way to distribute information. NATIVE APPLICATION A mobile application that is written in a programming language that is directly compatible with the target platform. NEAR FIELD COMMUNICATION (NFC) A set of protocols that enable two devices in close proximity (up to 10 cm apart) to communicate with each other. Supports three different modes: Card Emulation, Reader/Writer, and Peer-to-Peer. REAL-TIME DATA Information that is delivered immediately after collecting it without any delay. SOFTWARE AS A SERVICE (SAAS) A service residing on a layer of abstraction about IaaS and PaaS with all of the software and features already built and

provided over the network. The main advantage of this model is that a customer does not need to install or maintain this software on-premises, or store any of its data. STICKINESS For mobile applications, this refers to anything that encourages the user to stay active in the app for a longer period of time.

TEST-DRIVEN DEVELOPMENT (TDD) A development process that works on a very short development cycle. It relies on the repetition of this short cycle to create test cases and pass them. USER INTERFACE (UI) A term to describe the ways in which the end user directly interacts with a device or application. USER EXPERIENCE (UX) A term to describe all aspects of the end user’s interaction with an application. WEB APPLICATION A mobile application developed using web standards and accessed through a browser. WI-FI A wireless local area network that allows smartphones, computers, and other devices connect to the internet. WRITE ONCE, RUN ANYWHERE (WORA) A description of a program’s ability to run on all operating systems.

DZONE’S 2016 GUIDE TO MOBILE APPLICATION DEVELOPMENT VOL III


Dzone mobile application development  
Dzone mobile application development  
Advertisement