Top Mobile Framework for App Development

In this article we will talk about one of our favorite device the smart phone. The very device that we can’t like it up. For many including me our entire lives are summed up in to this little device from birthday to contacts and even exercise regimes and online banking every things is sorted neatly on this little device and i for one can’t imagine losing my phone.

The best part about smart phone is that whatever that is not already on the phone can easily be found in the ios or the google app store.

This is why need app developer is currently on the rise and they are some of the most paid developers on the market app development has become a serious business with companies dedicating time and money for simply building their app. We will introduce different framework to help you boost your mobile development skills. So that gets started.

1.Ionic

Over the last couple of years ionic has established it self as a leader in hybrid mobile development communities. In addition to being fairly easy to use and learn. It also offers a library of optimized HTML ,CSS and JavaScript. CSS components gestures and tools and work with the predefined components.

The best part about ionic is that it provides all the functionality which can be found in native mobile development SDKs. Which means that when users build their app on ionic they can access all native function of the device including camera,contacts etc.

Additionally by using angular ionic provides custom components and method for iterating with them.

For more information about icon and for the solution of your question why ionic? You can refer my this article https://medium.com/fuzzycloud/why-ionic-443ebff1d2fd.

In this we are focus on ionic v4. which is latest one.

Ionic Framework V4 is a major advance in the underlying technology and capabilities of the project, with a focus on performance, compatibility, and overall extensibility. Although V4 still integrates deeply with Angular through the @ionic/angular package, it is now also framework-agnostic, meaning it can work with any other JavaScript framework (Vue, React, Preact, etc), or with no framework at all.

By moving to web standards, V4 allows the core of Ionic to rely on the standard component model supported in modern browsers, rather than a framework-specific model. This can mean faster load time, better performance, and less overall code.

For installation and creating first app in ionic follow this https://beta.ionicframework.com/docs. This is latest version of ionic. Ionic v4.

Ionic Framework is a library of UI Components, which are reusable elements that serve as the building blocks for an application. Ionic Components are built with web standards using HTML, CSS, and JavaScript. Though the components are pre-built, they’re designed from the ground up to be highly customizable so apps can make each component their own, allowing each app to have its own look and feel. More specifically, Ionic components can be easily themed to globally change appearance across an entire app.

Using ionic UI Component we can create UI of whole application within some week.

You can find github link here. It is Proof Of Concept; we did few days back to check out Ionic 4. I must say We are very impressed with results, we did create quite a good amount of screens covering every aspect of application. Requirement was to create application that can compare flight prices and hotel prices with single app. And within 2–3 weeks we are almost ready with UI part of it.

I am adding some screen shot of that application which is working on both android and ios.

2. Flutter

Flutter is Google’s mobile app SDK for crafting high-quality native interfaces on iOS and Android in record time. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source.

Why use Flutter?

What are some advantages of Flutter? It helps you:

Be highly productive

Develop for iOS and Android from a single codebase

Do more with less code, even on a single OS, with a modern, expressive language and a declarative approach

Prototype and iterate easily

Experiment by changing code and reloading as your app runs (with hot reload)

Fix crashes and continue debugging from where the app left off

Create beautiful, highly-customized user experiences

Benefit from a rich set of Material Design and Cupertino (iOS-flavor) widgets built using Flutter’s own framework

Realize custom, beautiful, brand-driven designs, without the limitations of OEM widget sets

Core principles

Flutter includes a modern react-style framework, a 2D rendering engine, ready-made widgets, and development tools. These components work together to help you design, build, test, and debug apps. Everything is organized around a few core principles.

Everything’s a Widget

Widgets are the basic building blocks of a Flutter app’s user interface. Each widget is an immutable declaration of part of the user interface. Unlike other frameworks that separate views, view controllers, layouts, and other properties, Flutter has a consistent, unified object model: the widget.

A widget can define:

a structural element (like a button or menu)

a stylistic element (like a font or color scheme)

an aspect of layout (like padding)

and so on…

Widgets form a hierarchy based on composition. Each widget nests inside, and inherits properties from, its parent. There is no separate “application” object. Instead, the root widget serves this role.

You can respond to events, like user interaction, by telling the framework to replace a widget in the hierarchy with another widget. The framework then compares the new and old widgets and efficiently updates the user interface.

Composition > inheritance

Widgets are themselves often composed of many small, single-purpose widgets that combine to produce powerful effects. For example, Container, a commonly-used widget, is made up of several widgets responsible for layout, painting, positioning, and sizing. Specifically, Container is made up of LimitedBox, ConstrainedBox, Align, Padding, DecoratedBox, and Transform widgets. Rather than subclassing Container to produce a customized effect, you can compose these, and other, simple widgets in novel ways.

The class hierarchy is shallow and broad to maximize the possible number of combinations.

You can also control the layout of a widget by composing it with other widgets. For example, to center a widget, you wrap it in a Center widget. There are widgets for padding, alignment, row, columns, and grids. These layout widgets do not have a visual representation of their own. Instead, their sole purpose is to control some aspect of another widget’s layout. To understand why a widget renders in a certain way, it’s often helpful to inspect the neighboring widgets.

Layer cakes are delicious

The Flutter framework is organized into a series of layers, with each layer building upon the previous layer.

The diagram shows the upper layers of the framework, which are used more frequently than the lower layers. For the complete set of libraries that make up the Flutter’s layered framework, see API documentation.

The goal of this design is to help you do more with less code. For example, the Material layer is built by composing basic widgets from the widgets layer, and the widgets layer itself is built by orchestrating lower-level objects from the rendering layer.

The layers offer many options for building apps. Choose a customized approach to unlock the full expressive power of the framework, or use building blocks from the widgets layer, or mix and match. You can compose the ready-made widgets Flutter provides, or create your own custom widgets using the same tools and techniques that the Flutter team used to build the framework.

Nothing is hidden from you. You reap the productivity benefits of a high-level, unified widget concept, without sacrificing the ability to dive as deeply as you wish into the lower layers.

Building widgets

You define the unique characteristics of a widget by implementing a build function that returns a tree (or hierarchy) of widgets. This tree represents the widget’s part of the user interface in more concrete terms. For example, a toolbar widget might have a build function that returns a horizontal layout of some text and various buttons. The framework then recursively asks each of these widgets to build until the process bottoms out in fully concrete widgets, which the framework then stitches together into a tree.

A widget’s build function should be free of side effects. Whenever it is asked to build, the widget should return a new tree of widgets regardless of what the widget previously returned. The framework does the heavily lifting of comparing the previous build with the current build and determining what modifications need to be made to the user interface.

This automated comparison is quite effective, enabling high-performance, interactive apps. And the design of the build function simplifies your code by focusing on declaring what a widget is made of, rather than the complexities of updating the user interface from one state to another.

Handling user interaction

If the unique characteristics of a widget need to change based on user interaction or other factors, that widget is stateful. For example, if a widget has a counter that increments whenever the user taps a button, the value of the counter is the state for that widget. When that value changes, the widget needs to be rebuilt to update the UI.

These widgets subclass StatefulWidget (rather than StatelessWidget) and store their mutable state in a subclass of State.

Whenever you mutate a State object (e.g., increment the counter), you must call setState() to signal the framework to update the user interface by calling the State’s build method again. For an example of managing state, see the MyApp template that’s created with each new Flutter project.

Having separate state and widget objects lets other widgets treat stateless and stateful widgets in the same way, without being concerned about losing state. Rather than needing to hold on to a child to preserve its state, the parent is free to create a new instance of the child without losing the child’s persistent state. The framework does all the work of finding and reusing existing state objects when appropriate.

Try it!

Now that you’re familiar with the basic structure and principles of the Flutter framework, along with how to build apps and make them interactive, you’re ready to start developing and iterating. Follow the Flutter Getting Started guide.

3.Native script

We are now building applications with java Script. But now we are able to use like angular and typescript to build native application. So why would you use native script over something like ionic. Well there is a few reasons why you may want to consider that.

I am not saying any of these things that are the best a choice for you that depends on your team and that’s something I am gonna say a lot throughout this article is that as honestly depends a lot about where the skills are inside of your team and what the business requirements of your application.

Now there are always to build at the same native script application out with an angular code base. For the web and for native that is possible. I am working on the same native script with angular.

So , reason why you may want to use native script is that you just literally need that native performance for whatever reason.

The component that you develop with native script application are entirely native. So when we are building a level in side of our native script apps. It is a literal level for ios and android. It is not simply a hedge one or a label tag in HTML. We are also able to integrate things like griddle and cocoapods plugins relatively easy with little stress.

We have thing like typescript to help us with that. so we are able to interface with this all native environment within our java script and type script very very easy. Again you take advantage of the skills that you already know. So you can get started with typescript and angular and you can basically reuse your skills from ionic native script very simply. I think just worth trying everything if you try all native script and you find that you like it more than ionic then the growth native script.

I am big fan of ionic but right now I am working on native script with angular in my project. So in this we can create web and mobile app in same project. So now I realize that both platforms and both frameworks allows you to have different sort of strengths and weeknesses in different scenarios. If I am building an app for the web at that time I will just run straight to ionic to get things prototyped really quickly.

If I really want to go for big release and potentially there’s some ios and android SDKs that I want to interface with on native device. But I can’t find a cordova plug-ins. For native script offers me a little bit of easier sort of way of interfacing with those SDKs. So in all circumstances I am defiantly go with native script but like I said it depends what you want and what you project needs. I definitely put native script is most likely one of the best sort of mobile application framework when it comes to developing things with angular.

NativeScript now integrates directly with the Angular CLI, and allows you to build web and mobile apps from a single codebase.

One of the big challenges that NativeScript is designed to solve is the code sharing between iOS and Android projects. Meaning you can build mobile apps with JavaScript/TypeScript or Angular, which use the same code for both platforms. However the marriage of Angular with NativeScript allows us to take it a step further, which is the code sharing of the NativeScript and Web applications.

A code-sharing project is one where we keep the code for the web and mobile apps in one place. Here’s a quick diagram to show you what that looks like at a high level.

The objective is to share as much code as possible, and split the platform-specific code into separate files.

This usually means that we can share the code for:

• Routes for navigation,
• Services for common business logic,
• and Component Class definition for common behaviour of a component

While, splitting the code for:

• UI Layer (CSS and HTML) — as you need to use different user interface components in web and NativeScript-built native apps,
• and NgModules — so that you can import platform-specific modules, without creating conflicts (e.g. Angular Material Design — which is web only) between web and mobile.

Creating a New Project

Creating a code-sharing project is a straightforward process. You can use Angular CLI and NativeScript schematics to generate a brand new project with a code-sharing setup.

Prerequisite

You need to use the following versions of npm modules:

• Angular CLI — v6.1.0 or newer
• npm i -g @angular/cli
• The latest version of NativeScript Schematics
• npm i -g @nativescript/schematics

To create a new code-sharing project, we need to use the Angular CLI’s ng new command, with @nativescript/schematics as the source collection and the — shared flag.

Build Process

The code-sharing project comes with a build process that is capable of using the shared files together with the platform-specific ones, and providing a web or mobile app as a result. Here’s what that looks like at a high level.

Web Build

To build a web app, it is business as usual — just use the Angular CLI to do the job. When you call ng serve or ng build, the Angular CLI will ignore all NativeScript-specific files, as none of the web files directly reference any .tns files.

Mobile Build

In order to build an iOS or an Android app with NativeScript, you need to use the NativeScript CLI with the nativescript-dev-webpack plugin.

To build a mobile app from a code-sharing project run:

for ios : tns run ios --bundle

for android : tns run android --bundle

Code Splitting

When building a code-sharing app, you will share a big part of your code across all platforms. However, you will encounter situations where you need to provide different code for the web app and for the mobile app. The most common scenario is with Angular components, where you need to define different markup for your web and mobile apps.

There is a simple naming convention that allows you to provide two versions of the same file. All you need to do is create two files and add a .tns before the file extension to one of them, i.e.

• name.component.html — web-specific file
• name.component.tns.html — NativeScript-specific file

The file with the .tns part, is designated as a NativeScript-specific file, while the file without .tns is designated to be a web-only file.

It’s important to understand code splitting in the context of an Angular Component.

The most common scenario is a component with the following file structure:

• name.component.ts — web + NativeScript shared file
• name.component.html — web UI file
• name.component.tns.html — NativeScript UI file
• name.component.css — web stylesheet
• name.component.tns.css- NativeScript stylesheet

For more information about native script follow this link https://docs.nativescript.org/