Altabel Group's Blog

Posts Tagged ‘API

Recently Immo Landwerth post about .NET Standard 2.0 appeared in the web. Briefly, it is the unification of three major.NET Framework branches: .NET Framework, .NET Core and Xamarin. Simply saying, it is an API set which will be implemented by all platforms. This will join up the .NET platforms and stave off future fragmentation. This means that developers don’t need to master three different base class libraries to write code that runs across all of them. As long as industry is rapidly changing new .NET features will be designed by Microsoft or someone else.

A significant change is that .NET Standard will replace Portable Class Libraries (PCLs) in order to build multi-platform .NET libraries. Although the gist will be the same for developers, but implementation will be different.

The .NET Standard will include two types of APIs, the ones which are absolutely necessary to be implemented by all platforms, and optional APIs, which are not obligatory to be implemented. The last will be available as individual NuGet packages.

The APIs that can not be implemented on all platforms can be divided into two groups: specific APIs for each runtime and specific APIs for each OS. There are three ways to deal with unrealizable API. The first one is to make API unavailable. Secondly, you can make API available, but throw PlatformNotSupportedException on the platforms where there is no implementation. And also you can simulate API (as Mono does, partially simulating the registry as .ini files).

.NET Standard uses all of these variations and their combination, depending on the situation. Technologies that are available only on certain platforms will be implemented as NuGet packages. If it is unreal to make a stand-alone package, then there are options: throw an exception or simulate API.

There are many versions of .NET Standard, which are compatible with different platforms:
 

In this table the arrows are showing the platform ability to support a higher version of .NET Standard. For example, .NET Core 1.0 supports the .NET Standard version 1.6, which is the reason why arrows point to the right for the lower versions 1.0 – 1.5.

As you can see, the 4.6.1 framework version meets twice. With this version exactly .NET Standard 2.0 will be compatible, as well as future versions of Xamarin and .NET Core. There was a roll back of changes that were included in versions 1.5 and 1.6. This was done in order to support backward compatibility. Newer versions of .NET Standard should contain previous and new features. During the analysis of NuGet.org only 6 packages with .NET Standard 1.5/1.6 target platform were found, the author of which is not Microsoft, so it was decided to take 4.6.1 as a basis, and to offer the authors of these 6-packs to update them.

PCL is replaced by .NET Standard, but you are still able to work with it. You can make a reference from one .NET Standard library to another, or to PCL library.

Graphically, this looks as follows:

 

 

In addition, it is possible to make a reference to a conventional .NET library using the compatibility shim.

 

 

But it will only work in case all APIs in this .NET library are supported by .NET Standard. In this case it will be much easier to apply the references to existing libraries.

The following image shows the main APIs of .NET Standard 2.0

 

 
Opportunities which are likely to appear in .NET Core are quite predictable as long as this brunch has less possibilities than others.
As for Xamarin, many of these APIs have been included in the release of Cycle 8 / Mono 4.6.0

Source: .Net Blog.

What do you think about these new features? Please feel free to share your thoughts with us. Thank you in advance!

 

Darya Bertosh

Darya Bertosh

Business Development Manager

E-mail: darya.bertosh@altabel.com
Skype: darya.bertosh
LI Profile: Darya Bertosh

 

altabel

Altabel Group

Professional Software Development

E-mail: contact@altabel.com
www.altabel.com

As the Internet of Things begins to revolutionize businesses, economies and our society, IoT platforms are coming up being the core basis in the overall IoT infrastructure. IoT platforms, in simple words, are just about connecting the sensors to data networks and integrating with back-end applications to provide insight into huge volumes of data.

However developing for the Internet of Things is a complicated undertaking, and almost nobody chooses to do it from scratch. IoT data platforms provide a starting point by integrating many of the tools needed to operate a deployment from device control to data prediction and grasp into one service. Ready-built IoT platforms can meet the needs of any company and smoothly accommodate constant growth and change. In the light of the possibilities offered by IoT, many high tech companies started taking advantage of it. For the time being there are more than 300 hundred various IoT platforms on the market and the number is continuing to grow. So, let’s see what features of IoT platforms take into consideration while choosing one for your business.

Before selecting an appropriate solution which may be suitable for your organization, you must determine:

1. Three different types of IoT platforms. Here they are listed from most complex to least complex:

  • Application enablement and development (AEP/ADP): This encompasses platforms that offer modules, widget-based frameworks or templates for producing (with minimal or no coding) actual end-user applications. These platforms are capable of turning data into either intelligence or action very quickly. The vivid examples of such platforms are Oracle, ThingWorx and etc.
  • Network/Data, and subscriber management (NM): In the wireless carrier and mobile virtual network operator (MVNO) space, this kind of platforms try to streamline connecting cellular M2M data, so you don’t have to build much of the data infrastructure behind it. For instance Cisco and Aeris do network management as well as device management, while Jasper and Wyless do more sheer network management.
  • Device management (DM): These platforms are more about monitoring device statuses, troubleshooting issues, configuring embedded device settings and administrating the provisioning and health of the endpoints. Usually in the IoT space this fairly elementary software is provided by hardware vendors. Like both Digi and Intel provide pure device cloud management.

While these platforms can be found as distinct standalone products, it is becoming increasingly common to find vendors that combine two or all three types in a single offering.

2. Implementation, integration support and device management. Device management is one of the most significant features expected from any IoT software platform. The IoT platform should maintain a number of devices connected to it and track their proper operation status; it should be able to handle configuration, firmware (or any other software) updates and provide device level error reporting and error handling. Ultimately, users of the devices should be able to get individual device level statistics.

To make implementation smooth, the provider should possess convincing manuals, blogs and feasibly lively developer-community around the IoT platform.

Support for integration is another vital feature expected from an IoT software platform. The API should provide the access to the important operations and data that needs to be disclosed from the IoT platform. It’s typical to use REST APIs to achieve this aim.

3. Comprehensive Information Security. There are four main technological building blocks of IoT: hardware, communication, software backend and applications. It’s essential that for all these blocks security is a must-have element. To prevent the vulnerabilities on all levels, the IoT infrastructure has to be holistically designed. On the whole, the network connection between the IoT devices and the IoT software platform would need to be encrypted and protected with a strong encryption mechanism to avoid potential attacks. By means of separation of IoT traffic into private networks, strong information security at the cloud application level, requiring regular password updates and supporting updateable firmware by way of authentication, signed software updates and so on can be pursued to enhance the level of security present in an IoT software platform. Nonetheless while security ought to be scalable, it is unfortunately usually a trade-off with convenience, quick workflows and project cost.

4. Flexible Database. There are four major “V” for databases in IoT space:

  • Volume (the database should be able to store massive amount of generated data)
  • Variety (the database should be able to handle different kind of data produced by various devices and sensors)
  • Velocity (the database should be able to make instant decisions while analyzing streaming data)
  • Veracity ( the database should be able to deal with ambiguous data in some cases produced by sensors)

Therefore an IoT platform usually comes with a cloud-based database solution, which is distributed across various sensor nodes.

5. Data analytics.

A lot of IoT cases go beyond just action management and require complicated analytics in order to get the most out of the IoT data-stream. There are four types of analytics which can be conducted on IoT data:

  • Real-time analytics (on the fly analysis of data),
  • Batch analytics (runs operations on an accumulated set of data),
  • Predictive analytics (makes predictions based on different statistical and machine learning technologies)
  • Interactive analytics (runs numerous exploratory analysis on either streaming or batch data)

While choosing the right IoT platform, it’s better to keep in mind that the analytics engine should comprise all dynamic calculations of sensor data, starting from basic data clustering to complex machine learning.

6. Pricing and the budget. The IoT platform market features a diversity of pricing methodologies underlying various business strategies. And sometimes providers’ costs aren’t always transparent. Thus it’s very important to check out all the nuances of your provider’s pricing pattern, so you are not plainly bought into introductory teaser rates or into the prices for the base model.

Further you should bear in mind that you licensing cost for the chosen platform is just the beginning. The major expense can turn out to be the integration itself, as well as hiring consultants (if you are not able to do it on your own) to support the system.

Therefore, it’s extremely vital to brainstorm what your entire IoT system will look like at scale and choose which features are most critical to you chiefly — and only afterwards decide what sort of platform you need.

A lot of companies do this backward. They get the IoT platform and believe they’re getting the complete necessary solution—then realize the mistake half a year into development. Thus it’s critical to be aware of this before you get started.

Also it should be mentioned that some companies don’t use IoT platforms—they’re developing their own platforms in-house. Yet, depending on how you want to go to market, it may be clever to research pre-built options. Depending on your situation, you may save a lot of time and money by partnering with one of these platforms.

Have you ever faced the difficulties of choosing the IoT platform for your business? If yes, can you please let me know what kind of difficulties? And what do you think is it better to use a ready-built IoT platform or develop your own from the scratch? Looking forward to getting your ideas and comments.

 

Anastasiya Zakharchuk

Anastasiya Zakharchuk

Business Development Manager

E-mail: anastasiya.presnetsova@altabel.com
Skype: azakharchuk1
LI Profile: Anastasiya Zakharchuk

 

altabel

Altabel Group

Professional Software Development

E-mail: contact@altabel.com
www.altabel.com

jsframework

Whether you’re building apps for the browser, mobile or desktop, Aurelia can enable you to not only create amazing UI, but do it in a way that is maintainable, testable and extensible.

Retrospective and today

Aurelia is a project of Rob Eisenberg, the author of a very popular MV * – framework for Caliburn.Micro XAML-platforms, Durandal. Understanding all the disadvantages of Durandal, Eisenberg engaged in the development of so-called NextGen framework. In 2014 he began to work in Angular team on the second version of the framework. However, several months later, Rob decided to leave the Angular team since the direction of Angular 2, in his opinion, had changed a lot. He gathered a large team and returned to work on the framework of his dreams. And Aurelia is the result of that work.

JavaScript of tomorrow?

By using modern tooling Aurelia was written from the ground up in ECMAScript 2016. This means you have native modules, classes, decorators and more at disposal.
Aurelia is written in modern and future JavaScript, it takes a nowadays approach to architecture. It’s built as a series of collaborating libraries, which form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia’s libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS.
Aurelia’s code is open sourced under the MIT License, a very permissive license used by many popular web projects today. The starter kits are available under the Creative Commons 0 license. There is also a Contributor for those who wish to join the team in working on Aurelia. Ultimately, this means that you can use Aurelia without fear of legal repercussions and it can be build in the same confidence.

Benefits of Aurelia

Clean and Unobtrusive – Aurelia is the only framework that lets you build components with plain JavaScript. It stays out of your way so your code remains clean and easy to evolve over time.

Convention over Configuration – Simple conventions help developers follow solid patterns and reduce the amount of code they have to write and maintain. It also means less fiddling with framework APIs and more focus on their app.

Simple, But Not Simplistic – Because of the simple design developers are able to learn a very small set of patterns and APIs that unlock limitless possibilities.

Promotes the “-ilities” – Testability, maintainability, extensibility, learnability, etc.- Aurelia’s design helps developers to naturally write code that exhibits these desirable characteristics.

Amazingly Extensible – Aurelia is highly modular and designed to be customized easily, so developers will never hit a roadblock or have to “hack” the framework to succeed.

Web Standards Focused – Focused on next generation JavaScript and Web Components, and avoiding unnecessary abstractions that obscure the underlying web, Aurelia is the cleanest and most standards-compliant framework today.

Integrates Well with Others – Easily integrated with any 3rd party library or framework: for instance, with jQuery, React, Polymer, Bootstrap, MaterializeCSS and much more.

TypeScript Support – Each Aurelia library is released with its own d.ts files. There are also official TypeScript beginner kits and production quality starter kits.

An Official Product with Commercial Support – Being an official product of Durandal Inc., it has commercial and enterprise support available, so you can use Aurelia for building core technology for your business.

Thriving Community and Ecosystem – Having one of the largest developer gitter channels in the JavaScript world, oodles of contributors and a huge core team, Aurelia has been used to build just about every type of application and is used by large, well-known multi-national companies and enterprises.
 
Aurelia, Angular and React.js – what’s common and what’s different?
 

Aurelia vs. Angular

Similarities between Aurelia and Angular 2:

  • Aurelia offers ES6-support out of the box and supports all forms of alternative abstraction syntax such as TypeScript and CoffeeScript. Migration documentation about migrating from Angular 1 and 2 have been put on the roadmap.
  • The basis of both Angular 2 and Aurelia application comprise components associated with the corresponding template.
  • Differences in vision details and options range:

  • The syntax is much simpler and more explicit (i.e. self-explanatory) than Angular 2 and looks a lot like standard JS syntax. ES6 and JSPM are used by default and a gulp file with a custom-built system to transpile ES6 to ES5 using the Babel transpiler is included in the standard package.
  • Aurelia also uses conventions instead of its own syntax and boilerplate code. No special characters like the ones in Angular 2 (*, (), [] en #) here.
  • Aurelia is built in a modular way making it very pluggable. You can plug in internationalization, routing, virtualization, animation, … Besides that, third party plugins are available as well such as the aurelia-flux plugin adding the Flux dispatcher to Aurelia.
  • The presence of a root-component is necessary; it represents an application (app). The metadata may / should be attached to components by using decorators. Component initialization is performed by using dependency injection. In addition, each component has a declared lifecycle, which can be built by using the lifecycle hooks. The components may be formulated into a hierarchical structure.
  • Communication between the component and the template is performed by using data binding. The process of template rendering to the final HTML can be integrated by using pipes (Angular) or value converters + binding behaviours (Aurelia).
  • The main advantage of Aurelia in comparison to Angular is an advanced composition mechanism and template parts. Aurelia is designed with an emphasis on unobtrusive, the number of framework structures in the final code is minimal. Aurelia is more compact, while Angular sometimes simply forces to produce copy-paste.
  • Aurelia is new to the market while Angular has a big user base because it’s already been around for 6 years. On the other hand, Aurelia has great documentation available, it’s an official product of Durandal Inc, and the company has a long term vision for the product, something the Angular team doesn’t seem to have and is blamed for a lot.

Aurelia vs. React.js

  • While on the surface it might not seem fair to compare Aurelia to React.js, they’re both being used for the same things. Despite the fact that React.js is a fully-fledged and functionally released product without the early preview alpha tag and Aurelia is not, at current stage they are both pretty at the same level. You can achieve the same tasks within both, just in different ways.
  • As for React components and Aurelia’s ViewModel’s, they are both quite similar in that you’re essentially using a class to define properties and methods bound to a particular view. The primary difference between them is React doesn’t separate the logic from the view, meaning in React the View and ViewModel are both within the same file.
  • However, that’s not to say that Aurelia doesn’t allow you to achieve the same thing by rendering the View from within the ViewModel as well and forgoing a traditional View.
  • The original intent behind React.js was not to be a competitor to the likes of Angular or Aurelia, but rather be the library that everyone uses with their SPA framework like Angular to improve performance.
  • Therefore, this means you can easily use React.js within Aurelia. Aurelia and React.js can be used together and in doing so, it provides you with a level of power other frameworks cannot without subsequent complexity and strict convention like EmberJS.

Aurelia vs. Angular and React

  • Two-way binding is provided out of the box and the framework does so very precisely. By default, 1-way databinding is used except for form controls, a clear plus when compared to React. Do keep in mind that two-way data binding can only be done through explicit syntax, as is the case in Angular 2.
  • The learning curve for Aurelia is comparable to that of Angular 2 and thus a lot steeper than React’s. Luckily, the extensive documentation makes up for that a great deal.
  • Angular 2 and Aurelia Architecture is very similar. Aurelia looks a lot like Angular 2 in the sense that it’s a complete framework that relies on the web standards. It’s as pluggable as React is and as Angular 2 will be.
  • While Angular was created by Google and React by Facebook, they don’t provide commercial or enterprise support, something that Aurelia will do.

 
Conclusion

It goes without saying why these three frameworks are so popular. They all have a lot of strong advantages. Eventually, I’m favoring Aurelia: there’s solid documentation available and the overall philosophy is the same with Angular 2, but Aurelia is a better choice from the syntax and execution point of view. The architecture and syntax vision of Aurelia team seems to be more clear than the vision of the Angular team. The company and enterprise support of Aurelia is also a big pro.
What is your personal experience with these frameworks? Which one would you choose for your projects and why? What’s your prediction “who” will win the crown in the nearest future? Please feel free to share your thoughts with us.

Thank you in advance!

 

Darya Bertosh

Darya Bertosh

Business Development Manager

E-mail: darya.bertosh@altabel.com
Skype: darya.bertosh
LI Profile: Darya Bertosh

 

altabel

Altabel Group

Professional Software Development

E-mail: contact@altabel.com
www.altabel.com


%d bloggers like this: