Thursday, 18 May 2017

Visual Studio Mobile Center - Android, iOS, Windows & React Native

Visual Studio Mobile Center, a set of cloud services for building and managing your mobile apps. Mobile Center is designed for all apps targeting iOS, Android, Windows including apps written in Swift, Objective-C, Java, Xamarin, and React Native.


Delivering excellent mobile experiences requires going beyond frameworks and IDEs—developers also need services to continuously build, test, distribute, and monitor their apps so that they can quickly iterate and improve. Many teams cobble together a workflow using some of these services from different tools and products. But this is time-consuming and distracts you from your actual mission of delivering a great app.

This is why we built Mobile Center: a mission control for mobile apps that brings together all the cloud and life cycle services that help developers deliver high quality apps faster. You can build, test, distribute, and monitor your apps and easily add backend cloud services to scale your app to millions of users on demand.

There are many great features included in the Preview, with even more to come. Here’s what you can do today:

  1. Build your apps automatically with every pull request via connecting it to the Repositories like Github, Bitbucket etc.
  2. Test apps on thousands of real-world devices
  3. Distribute passing builds to beta testers or user groups or organisation
  4. Monitor apps for crashes and bugs 
  5. Learn about real world usage with mobile analytics
  6. Connect to a mobile backend for automatic scaling and to add important cloud services like offline data sync, tabular data storage, and end-user authentication services

Mobile Center is the next generation of our existing mobile developers services, including HockeyApp and Xamarin Test Cloud. Later next year, Mobile Center will show all of your new and existing HockeyApp and Test Cloud apps to ensure a seamless transition for those customers.

It’s easy to get started. Request an invitation and once approved, sign in with your existing HockeyApp credentials, GitHub account, or Microsoft Account. Then, connect your apps and kick off some builds. The preview is free, with some metering to ensure everyone has a chance to use the services and provide feedback.

Courtesy: #MobileCenter #Reference

Friday, 12 May 2017

Mac Machine not necessary anymore for Xamarin.iOS degub, run, test and deploy

If you’re an iOS developer, then Microsoft’s Xamarin already allowed you to develop your iOS applications in C# with the help of tools like Xamarin.iOS for Visual Studio. Until now, though, you still needed a Mac to build and test your apps. As the company announced today, that’s not necessary anymore. With the new Xamarin Live Player, you can deploy, run, test and debug iOS apps directly from a Windows PC that runs Visual Studio.

With this, Microsoft is closing the loop for most developers and is getting a step closer to its goal of positioning Windows 10 as the preferred operating system for cross-platform development.   To enable this new functionality, developers have to install the Xamarin Live Player app on their iOS device and then pair it to their PC by scanning a QR code on their screen. Because this is fully baked into Virtual Studio, you also get access to all of the usual functionality you would expect in your IDE. You can, for example, make live edits to your code while it is running and immediately see the result of a color change, for example, on your phone.



Microsoft tells us that it talked to Apple about this functionality and that it has its rival’s blessing and that the Live Player application complies with all of Apple’s usual rules.
Courtesy: techcrunch

Google’s new Mobile OS Fuchsia, gonna completely replace Android in sometimes


Google’s Android platform is the most widely used mobile operating system in the world. In fact, it’s so popular right now that it’s beyond difficult to imagine a future without Android. Of course, people at one point felt the same way about early smartphone platforms like Symbian and BlackBerry OS, which have been almost completely wiped from the face of the Earth at this point. Some day, iOS and Android will be distant memories as well.

If there’s one thing companies like Nokia and BlackBerry taught us, it’s that companies at the top can only stay at the top if they’re constantly preparing for the future. So, rather than rest on its laurels and sit pretty while Android continues to dominate the smartphone market, Google is already hard at work on a fresh new mobile platform called Fuchsia, which may some day completely replace Android.

Dig Through:

I decided to dig through open source to examine the state of Google’s upcoming Fuchsia OS. For anyone unfamiliar, Fuchsia seems to be the replacement for both Android and Chrome OS. Fuchsia is the actual name of the operating system, while Magenta is the name of the kernel, or more correctly, the microkernel. Many of the architectural design decisions appear to have unsurprisingly been focused on creating a highly scalable platform. Google is unsurprisingly bringing up Fuchsia on a number of platforms, including the humble Intel NUC. ARM, x86, and MIPS bring-up is exactly what you would expect for an Android successor, and it also seems clear that this platform will run on Intel laptops. More on this later.

My best guess is that Android as an API and runtime will live on as a legacy environment within Fuchsia. That’s not to say that all development of Android would immediately stop, which seems extremely unlikely. But Google can’t push two UI APIs as equal app frameworks over the long term: Mojo is clearly the future.  Ah, but what is Mojo? Well it’s the new API for writing Fuchsia apps, and it comes from Chromium. Mojo was originally created to “extract a common platform out of Chrome's renderer and plugin processes that can support multiple types of sandboxed content.” It seems to have enabled Android apps in Chrome OS, and now it will serve an even more extensive role as the developer API for Fuchsia.

Programming Languages in role!

Mojo in Fuchsia features intriguingly extensive language support. C/C++, Dart, Go, Java, Python, and Rust all have bindings to Mojo. I am guessing that C/C++ is for native development, Go is for networking, Java is for Android(?), Python is for scripting, and Rust is for writing portions of the kernel. (Or perhaps Rust's usage is minimal, suggests a commenter on Hacker News.) Mixing and matching languages aside, the main UI API is based on, yes, Dart.  Flutter is an existing Google widget framework for apps written in Dart, and it has been repurposed to become the UI framework for Andromeda. Flutter includes a series of Material Design widgets and was engineered to render apps up to 120fps.* I imagine Andromeda’s standard UI components will look similar if not identical to those of Android. A physically based renderer, Escher, is apparently being used to render, well, material elements and shadows in a high quality manner.

I have very strong reservations about Dart as the language of the primary platform API, but it’s best to wait for the fully revealed details before forming an opinion. The reason for Dart is obvious, however: to enable a cross-platform app framework. The pitch will clearly be that developers can write a Flutter app once and have it run on Fuchsia (Google's Flutter SDK), Android, and iOS with minimal extra work, in theory. (Flutter does not target the web.) Even if Fuchsia is its full replacement, Android will be a separate developer target for many years given its gigantic installed base.

Fuchsia's actual app run-time is called Modular, “a post-API programming model that allows applications to cooperate in a shared context without the need to call each other's APIs directly." To do this it uses Mojo inter-process communication (IPC) messages, which are exchanged via low-level primitives in the form of message pipes (small amounts of data), data pipes (large amounts of data), and shared buffers.

I'm may not technically correct to explain, how the various languages interface over these IPC calls, and what exactly that enables. The IDL used is the Fuchsia Interface Description Language (FIDL), “an encoding format used to describe [Mojo] interfaces to be used on top of Magenta message pipes. They are the standard way applications talk to each other in Fuchsia.” Right now at least, only C/C++, Dart, and Go have supported bindings. Dart is thus the main platform language. (My understanding is that Go is not exactly ideal for writing UI apps.)

Courtesy: techspecs, bgr, flutter

Friday, 5 May 2017

Code Practice: Library Vs Framework

Most of the tyro programmers are every time wants to impress their leads/superiors, also want to show-up their code practices among their teammates, they use few terminologies to explain about their codes, tells they wrote a generic code and some of the dev's tells they have did a code and it is kinda libraries, frameworks and reusable components etc...  but they are not sure about those terminologies.  

In reality, the code which they have written is really a good and consider to be copy and paste into the other projects, and reuse those in other projects, by sure it reduce efforts.  But it is not a library or frameworks. 

Then what is Library and Framework?  Both smells like a same nuts, but it is not right?  It is a nut but the shells were different.


The key difference between a library and a framework is "Inversion of Control". When you call a method from a library, you are in control. But with a framework, the control is inverted: the framework calls you.

Library:
A library is just a collection of class definitions. The reason behind is simply code reuse, i.e. get the code that has already been written by other developers. The classes and methods normally define specific operations in a domain specific area. For example, there are some libraries of mathematics which can let developer just call the function without redo the implementation of how an algorithm works.

Framework:
In framework, all the control flow is already there, and there's a bunch of predefined white spots that you should fill out with your code. A framework is normally more complex. It defines a skeleton where the application defines its own features to fill out the skeleton. In this way, your code will be called by the framework when appropriately. The benefit is that developers do not need to worry about if a design is good or not, but just about implementing domain specific functions.


Courtesy: Programcreek