2017년 4월 26일 수요일

Which Mobile App Development Option is Better?

Different alternatives to native code development have their own advantages and philosophy behind. No one tool or approach can be clearly marked as a winner since it all depends on multiple factors.
The mods prominent factors in choosing a specific app development platform or approach depends on t he below key factors

  • Skill set of individual or development team
  • Unique requirements of the app
  • Targeted user segment
  • Long term strategic vision of the individual or an organization
If you are making apps for one specific platform only, the going native(swift, objective c for iOS and java for android) is the preferred choice. simply because you get the best performance and the latest APIs and features to work with.

Alternatives to native development


Cordova Based Mobile App Development
Hybrid app development using plain JavaScript, HTML5 and CSS is one of the easiest and most popular options and this is where old time web developers are at an advantage.
There are tons of frameworks that let you do mobile app development with ease by using age old plain JavaScript and CSS; some of these frameworks include Ionic,kendo UI and JQuery Mobile.

Cordova brings in unified JavaScript API, using which you can access device functions like Camera and accelerometer of almost all platform including Android, iOS and Windows.
Once your app is ready, you compile your app with Cordova and Cordova wraps your app app specific JavaScript, CSS and HTML into platform specific containers(webview). This container acts as a bridge between your application and hardware components via unified JavasScript API.

The biggest advantage you get here is the single code base to develop and maintain, and that too, without learning any new technology, if you are already a web develper.
Application runs in the webview, and not natively on the hardware, which makes it less performance than the native Android or native iOS applications. But then, all apps are not required to be super performance.

Cordova is free and open source under Apache license and is distributed by the Apache Software foundation

Mobile App Development Using React Native
React native is relatively new but an excellent option ofr rapid mobile applications development, and you cant target both iOS and Android. React native is the open source framework from t he house of Facebook and is used for developing native iOS and android apps.
Event though React native is a new entrant in the market but many developers and organizations across the globe have started.

React native too is JavaScript based but just plain JavaScript, HTML5 and CSS. React Native is the extension of React itself and users the same development philosophy.

Apart from React framework, you need to understand JSX, JSX is the XML like syntax extension of ECMAScript.

React Native vs Cordova or PhoneGap
The UI in Cordova hybrid apps is developed using HTML and JavaScript components and runs in the webview of Android and iOS platforms.
In React Native also, the UI is written in JavaScript react components(JSX extension), but each React native UI component corresponds to the native UI component of iOS and Android. So, you write components in JavaScript but those are converted to native components. Net net, you have JavaScript code interfacing to the native components of the underlying platform.

Code reuse between Android and iOS apps in react native is not purely 100% but can easily be targeted anything from 85% - 100%, depends on what you are developing.

The biggest advantage here is that you work only with JavaScript for your iOS as well as Android version of the app. The philosophy is - "Learn once, write everywhere and achieve maximum code resusability".

Mobile App Development Using Xamarin
Xamarin is another animal in the wild of building native mobile apps and it is one of  the most used platform for app building. With Xamarin, you can build native android, iOS, windows and Mac apps in C# language.

Development philosophy is more or less the same as React native but the skill set requirements change drastically since you need to work with C# and Microsoft tools instead of JavaScript. The code reuse again is not 100% but 80% can easily be targeted.

Xamarin is not the easiest to work with but gives you the performant mobile applications. You develop code in C# and Xamarins compilers compile the code into native packages of respective platforms, may it be iOS, Android or Windows Phone.


from : http://noeticforce.com/mobile-app-development-cordova-vs-react-native-vs-xamarin


2017년 1월 17일 화요일

Binary Messaging formats emerging

The widespread use of ASCII encoding formats like JSON and rest may be killing server performance. A wide variety of emerging binary formats offer significantly improved performance for processing messages. This could be particularly important for I/O intensive applications like transaction processing, data analytics, and financial services.
The server-side recently spoke with Martin Thompson, founder of software consultancy Real Logic about the merits of binary encoding formats for message processing. He said, “I've seen many applications that spend significantly more CPU time parsing and transforming XML and JSON than executing business logic.”

Message parsing gains

This in particularly important in the finance industry, where applications need to be able to process market feeds that can peak at over 10 million messages per second, and are continuing to grow. The financial industry ratified the SBE binary messaging for processing financial data and transactions designed to dramatically reduce the latency compared with alternatives.

Thompson worked with a team to develop a reference implementation of SBE in Java, C++, and C# that was able to process about to process about 34,000 messages per second, or about 16-25 times faster than Google Protocol Buffers (GPB ) on the same hardware. This in turn was over a thousand times quicker then what can be achieved with JSON.

Achieving this level of efficiency is not for the faint of heart. Thompson said that the resulting application had to be debugged using the Wireshark protocol analyzer, rather than the built-in debugging tools in Java IDEs. This of course begs the question of whether more efficient binary formats that reduce CPU and networking bandwidth are worth the trade-off of increased developer bandwidth and a longer software development lifecycle.

Many binary messaging formats emerging

A number of different binary messaging formats have emerged over the last couple of years including the finance industry’s Fast Protocol, Google Protocol Buffers, Apache Avro, Facebook’s Thrift, and Microsoft Bond. All of these different formats promise increased efficiency compared with ASCII encoding formats like JSON and XML.

Adopting them can improve the throughput of almost any application involved in message processing. They also promise to reduce the power requirements in IoT devices, said Thompson. These messaging formats also show promise ingesting data from the rising tide of IoT devices now being deployed.

What holding back binary messaging?

At the same time these formats have not been widely adopted by the developer community outside of finance. One part of the challenge might be that JSON fits in well with the Java development paradigm. These other encoding formats require developers to stretch their thinking around application development. They may also make it harder to document an API in a way that is accessible to third-party developers. This could be a deal breaker for enterprises that work with a larger developer community that integrate the API into their applications.

Another factor holding back adoption may be that the performance gains are just not significant enough compared to other components of an application’s performance. If a particular application is more constrained by compute or memory limitations, a more efficient messaging protocol will not be as important. Enterprises would also have to consider how to shift their development tooling and train developers to get the most from these new protocols.

In some ways, it’s surprising that enterprises are starting to adopt less performance development languages like JavaScript and Python. But this makes a lot of sense when developer attention becomes a scarcer resource. Futurist George Gilder once opined that the best business models waste the eras cheapest resources in order to conserve the era’s most expensive resources. As the cost of cloud services goes the cost of an efficient application development lifecycle becomes more important. Thus, some start to finish. Businesses may want to wait until these binary messaging alternatives become cheaper to integrate into modern applications.

from The Serverside.com

Simple Binary Encoding (SBE)

SBE is an OSI layer 6 presentation for encoding/decoding messages in binary format to support low-latency applications. The SBE project on GitHub is the reference implementation for the FIX SBE standard for the encoding of financial messages.

SBE provides a compiler for taking a message schema and generating stubs for messaging parsing in multiple languages. Currently Java, C++, and C# (courtesy of Adaptive) are supported. SBE allows allows for the on-the-fly decoding of messages from a compiler generated meta description. Details for using SBE can be found on the Wiki.

Performance is a key requirement for SBE. Performance with consideration to throughput and latency of encoding/decoding binary messages exchanged via a local area network (LAN) of servers which typically have x86 processors. For example, the transmission of financial orders and market data in a co-located environment.

The design follows a number of principles and makes no compromise by adding features that violate these principles. You may find that alternative codecs, such as Protocol Buffers, offer more features. Features such as allowing strings at any location in a message. SBE only allows variable length fields to come at the end of a repeating group or message. SBE makes some restrictions in return for more than an order of magnitude increase in throughput at very low, and importantly, predictable latency.

To get started with with SBE please read the Wiki and then get the latest at:
  • Java: Maven Central
  • C++: building from source

source: https://github.com/real-logic/simple-binary-encoding

Google protocol buffers


Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format.

Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:

  • are simpler
  • are 3 to 10 times smaller
  • are 20 to 100 times faster
  • are less ambiguous

generate data access classes that are easier to use programmatically

When this message is encoded to the protocol buffer binary format (the text format above is just a convenient human-readable representation for debugging and editing), it would probably be 28 bytes long and take around 100-200 nanoseconds to parse. The XML version is at least 69 bytes if you remove whitespace, and would take around 5,000-10,000 nanoseconds to parse.


Introducing proto3
Protocol Buffers language version 3 (aka proto3), as well as some new features in our existing language version (aka proto2). Proto3 simplifies the protocol buffer language, both for ease of use and to make it available in a wider range of programming languages: our current release lets you generate protocol buffer code in Java, C++, Python, Java Lite, Ruby, JavaScript, Objective-C, and C#. In addition you can generate proto3 code for Go using the latest Go protoc plugin, available from the golang/protobuf Github repository. More languages are in the pipeline.

-- from developers.google.com

2017년 1월 16일 월요일

Java Microservice

The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
- martinfowler.com


Java microservices advantages
The main advantage of microservices architecture is simpler application design and administration. Because microservices break a complex set of operations down into discrete parts, they make it easy for developers and admins to make changes to one part of the application without affecting other parts or requiring the entire application to be restarted.

Java microservices can also provide some security benefits. When the different parts of an application are isolated from one another, an attacker who is able to gain control of one service does not gain control of the entire application.

This security isolation can be especially useful in use cases like the Web application described above. In that case, the data storage system would remain safe in the event that an attacker compromises the public-facing application front-end.


Why use Java microservices?
So, what’s making microservices popular all of a sudden now, and how are microservices different than SOA? To answer those questions, let’s first examine the advantages of microservices, then take a look at how two other current trends, DevOps and Docker, make microservices more advantageous than SOA.


Java microservices versus SOA
To Java developers who were around about ten ago, the microservices approach to application design probably sounds familiar. In many ways, the Java microservices paradigm is similar to Service-Oriented Architecture, or SOA. SOA, which was popular in the 2000s, also emphasized the division of complex applications into discrete services. That communicate via APIs.

SOA enjoyed some popularity, but it never revolutionized the way applications were designed. The SOA fad faded after a few years, and monolithic applications remained common.


Java microservices, DevOps and Docker
Microservices complements some other trends that are changing the way developers write and deploy software. In particular, the DevOps trend that began in the late 2000s is driving renewed interest in microservices, which help to make software delivery more modular and efficient.

In addition, the introduction several years ago of Docker containers gave developers a new, easier way of building microservices. With Docker, you can run each service inside a container, and combine those containers to compose a complex application.

Docker makes it easier to create and manage a microservices application than the old SOA paradigm allowed. With Docker, once your services have been Dockerized so that they can run in containers, you can deploy those containers to any server with Docker installed. You can also move them around between hosts for portability. And you can use container orchestration tools for automatic provisioning.

- from the serverside.com

Which Mobile App Development Option is Better?

Different alternatives to native code development have their own advantages and philosophy behind. No one tool or approach can be clearly ma...