Tag Archives: Windows Phone

Put Some Azure Active Directory in Xamarin.Forms

via Put Some Azure Active Directory in Xamarin.Forms | Xamarin Blog.

he Azure Active Directory Authentication Library (aka ADAL) makes authentication with Azure Active Directory a breeze. We’ve already covered usage of ADAL in various posts on authenticating with Active Directory, adding storage, and adding collaboration (SharePoint) to your mobile apps.
ADAL is available for various platforms and supports Xamarin.Android, Xamarin.iOS, and Windows Phone. It’s easy to integrate ADAL into these projects by adding a NuGet package. Although ADAL hasn’t released a specific Package for Xamarin.Forms, there have been many questions in the Xamarin forums and on StackOverflow about how to use ADAL in a Xamarin.Forms app.

Recently, Vittorio Bertocci, Principal Program Manager at Microsoft, posted ablog about integrating ADAL into Xamarin.Forms apps using a PageRenderer. In this post, I’ll be sharing another way to integrate ADAL into Xamarin.Forms apps using Dependency Service, which is available in Xamarin.Forms.

Guide to Add Windows Phone to Xamarin.Forms 1.3+ Projects

via MotzCod.es by James Montemagno — Guide to Add Windows Phone to Xamarin.Forms 1.3+….

I am a huge fan of Xamarin Studio and live inside of it around 50% of my development time. When I need to do library or Windows development though I head over to my good friend Visual Studio. Luckily the same exact project and solutions open in either IDE so it makes syncing with GitHub extremely easy. When I start up a Xamarin.Forms project I usually do it from Visual Studio so it spins up an iOS, Android, and Windows Phone Project. However, there are times that I am in XS, which doesn’t create the Windows Phone project so I need to add it after. Rob Gibbens wrote a great guide on adding Windows Phone projects to Xamarin.Forms in this case, but it is for the older Xamarin.Forms model pre 1.3. It is still a great guide and my guide follows this closely but updated with the new Application class requirements. Additionally, since Rob’s post we did release support for Windows Phone/Store RT apps and that process was documented as well, however Silverlight was left out, so let’s do it!

An Introduction to Windows Phone 8.1 Development

via An Introduction to Windows Phone 8.1 Development.

Before we get started there are a few things I would like you to know about developing apps for Windows Phone 8.1. You are going to need Visual Studio Professional 2013 Update 4 IDE as a programming environment and a basic understanding of Object Oriented Programming languages. The programming language is C#, which is similar to Java if you find that more familiar. You also need to have Windows 8.1 installed. Today, I’m going to show you how to build your first Windows Phone app step by step starting from the installation of the IDE. So let’s get our hands dirty!

Building a tabbed app using Xamarin.Forms

via Building a tabbed app using Xamarin.Forms | Daniel Hindrikes.

Xamarin.Forms is one of the biggest news with Xamarin 3. With Xamarin.Forms you can build UI for 3 platforms (Windows Phone, iOS and Android) with one shared codebase. What is unique for Xamarin.Forms is that the UI code you are writing with Xamarin.Forms will render native UI controls. That means that the UI will look like a Windows Phone app when running the code on a Windows Phone and it will look like a iPhone app when running the code on an iPhone and the same on Android.

Xamarin Plugins: Cross-platform NuGet Packages

via Xamarin Plugins | Kloud Blog.

Xamarin Plugins are a special kind of NuGet package that let you easily add cross-platform functionality to your apps. Using NuGet to distribute Plugins means that anyone can create them, and of course consume them. The platforms supported by Plugins include Android, iOS, iOS Unified (64bit), Windows Phone 8, Windows Phone 8.1 RT and Windows Store.

Open Source framework for building cross-platform truly native iOS, Android and Windows mobile apps using JavaScript.

via NativeScript/NativeScript · GitHub.

What is NativeScript

With NativeScript you can use your JavaScript and CSS skills to write native mobile applications for iOS,Android and (very soon) Windows Phone. There is no WebView involved in rendering the app, as the UI is rendered by the native platform’s rendering engine. Because of that, the app’s entire UX is native.

NativeScript enables you to use a complete stack of cross-platform APIs to write your application code or, if you need to, you can directly access all platform-specific native APIs using JavaScript only. That’s right—you can access all native APIs, not only the ones we thought would be useful!

We did not want to create just yet another ecosystem around a native cross-platform framework. We wanted to integrate and play well with all existing JavaScript and native iOS/Android/Windows ecosystems. That is why we also support using existing JavaScript libraries, as well as existing native Objective-C, Java and .NET libraries. We want to stress that you don’t need to know Objective-C, Java or .NET in order to reuse these libraries—their entire APIs are available in JavaScript with no changes.

Because of the features listed above you get some important functionality right out of the box. The first is that NativeScript applications support the same accessibility models as native apps. This is important for anyone creating apps that need to meet certain accessibility standards before going live. This is also very useful when you start implementing functional or unit tests for your app. Several existing cross-platform tools like Appium already work directly with NativeScript and provide accessibility automation.

The second major feature you get out of the box is 0-day support for new native platforms. Because NativeScript exposes unmodified native APIs and UI components, you can use the latest native APIs and new UI components when Apple, Google or Microsoft updates their mobile platforms.

So let’s summarize what NativeScript enables you as of today:

  • Build 100% native cross-platform apps, with a declarative UI, and the ability to implement platform-specific UIs.
  • Share 100% of your code or use platform-specific APIs, depending on the app you’re building.
  • Code in standards-based ECMAScript 5 JavaScript. ES6 support is coming soon.
  • Use standards-based CSS syntax for styling.
  • Use rich data binding and existing UI patterns to easily build complex user interfaces.
  • Reuse any native library available in Objective-C, Java or .NET.
  • Reuse any JavaScript library that is not browser-dependent.
  • Reuse the QA tools for accessibility automation to write tests.
  • Use the latest native platform features to create an amazing native user experience.
  • Code in any IDE of your choice to implement your applications’ code using the NativeScript CLI.
  • Use the Telerik Platform, AppBuilder and the full Visual Studio integration to get a rich development experience. Paid support is also available.

We hope this gives you a good idea about what you can expect from NativeScript.

To learn more about NativeScript, you can check the following resources:

Rebuilding HipChat with ReactJS

via Rebuilding HipChat with React.js – Atlassian Developers.

The long and the short of it: we rebuilt the HipChat web client from the ground up with React.js, Flux, and a variety of other libraries and it is awesome! Why don’t you give it a try?

When HipChat joined Atlassian, it had four clients: web, Adobe Air (Windows, OS X, and Linux), iOS, and an Android app. One of the first goals for the HipChat team was to replace the Air client with a native desktop client for OS X, Windows, and Linux. This kept our small team (at the time) very busy. Because of this focus on delivering first-class app experiences, our web client didn’t receive the benefit of updates we were making elsewhere. That sucks, and we’re fixing it.

I’ve long tried to make a case for improving the web client and possibly even rewriting it. It’s not an easy sell or decision to rewrite anything, but the HipChat web client sorely needed to be improved all around. There should be few reasons to ask our users to download a native desktop client if we deliver a web client that performs on par or better.