I'm working with the code from google drive in visual studio 2012 (C#). I managed with hours of fiddling around with nuget reference the necessary libraries.
I compiled the test application and got the following warnings:
'Google.Apis.Authentication.OAuth2.DotNetOpenAuth.NativeApplicationClient' is obsolete: 'NativeApplicationClient is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for WindowsStore apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Authentication.OAuth2.GoogleAuthenticationServer' is obsolete: 'GoogleAuthenticationServer is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for Windows Store apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Drive.v2.DriveService.Scopes' is obsolete: 'Use DriveService.Scope instead. This enum is going to be removed in version 1.7.0-beta.'
I did not modify the code other than adding in the client_ID and client_secret. Other than that, it appears to run...
I'll also mention that I am using the nuget Google.Apis.Auth package.
The code behind the DriveService.Scopes warning is using DriveService.Scopes not Google.Apis.DriveService.Scopes (look at the code on the link; mine is the same).
With the google admin api being deprecated and google breaking the old api almost every other week it seems, I'm anxious to get on the new API. However, with what I'm seeing here I'm wondering if that's a good idea or not. I could be trading the frying pan for the fire. With that said, what are we supposed to be using if your current example is already obsolete?
First of all you should use the latest version of the library, that's the version that we maintain, provide fixes, new features and so on. You can get it using NuGet.
The sample code in the page you mentioned wasn't updated lately. Take a look in our samples repository (and specifically in the Drive API sample).
Google.Apis.Auth is the right package to use. The reason the old package (Google.Apis.Authentication) is obsolete is based on the fact the we wanted to support different Windows platforms like WP, Windows 8 applications, ASP.NET MVC. We also simplified the OAuth2 "dance" which was so complicated before.
Last thing - If we make any incompatible changes in the library we document them in our announcement blog, so our users will be able to make the right adjustments . I recommend you subscribing to this blog to get updates about our library.
Hope everything is clear now :)
Related
As the https://developer.dji.com/windows-sdk/ is now available, I thought I might have a go.
However, so far I have not gotten anything in VisualStudio using C# that references either the DJIWindowsSDK.dll, DJIWindowsWrapper.dll or DJIWindowsWrapper.winmd to work.
I have tried console applications on the .NET Framework and .NETCore, but so far all I get when just trying to either get at var droneManager = DJISDKManager.Instance; or trying to set any callback on DJIWindowsWrappedInterfaces are compile errors about mismatched platform settings (MSIL vs x32 or x64) or System.BadImageFormatException on first access to any SDK code.
Anyone have any idea on what type of projects these assemblies are actually meant to be usable? Documentation only describes classes and methods and such (which seem clear enough, in general), not basic nitty gritty stuff like the type of projects and platform settings supported.
And I have so far not gotten the SampleCode to work. It's nice that the sample code seems (if I look at source code) to be a sort of complete set of code showing SDK functions at work, but it only seems to work with the latest version of Windows 10, the Windows 10 SDK, and VisualStudio. And possibly a ton of other prerequisites, which do not seem all to clearly spelled out at all.
I would like to get a most simple kind of Hello World! style example (from some kind of Console app) working (first), but so far I'm not succeeding..
Have you checked the DJI Windows SDK Github Readme? I think the Get Started Immediately part can help you run the sample code. It lists the prerequisites, and necessary steps to run it.
BTW, I just found this documentation, you can take a look and see if it helps: https://github.com/dji-sdk/Windows-SDK-Doc/blob/master/source/application-development-workflow/workflow-integrate.md
Recently i got a project which was build on Xamarin on Mac.Now, when i try to open this project on visual studio for MAC (As you all know Xamarin is now visual studio for MAC) it shows some errors regarding Monotouch.
The question is : Do i really need to convert app to unified API ? i know there is tutorial on official Xamarin doc to change app to unified API, but if there is any other way to open app without migrating to unified api.And what will be advantages and disadvantages of migration?
There are quite a few reasons why you might consider updating, but I will highlight some of the more important ones. Firstly consider that Apple as a manufacturer of hardware and software have always striven to keep their devices upto date, as such lagging behind as an iOS app developer can absolutely effect the demand for your app.
Firstly it already became a push or jump situation, as Xamarin stopped updating or supporting feature additions to their 'classic api' (As of writing we are on iOS 10.3).
The complete removal of classic support is scheduled for next fall
with the release of Xamarin.iOS 10.0.
Secondly the unified API is required to meet apples desire to support 64bit architecture:
The new Unified APIs are required to support 64 bit device
architectures from a Xamarin.iOS mobile application. As of February
1st, 2015 Apple requires that all new app submissions to the iTunes
App Store support 64 bit architectures.
As to your concern regarding the dissadvantages, I will simply say that the migration can either go smoothly, or not so smoothly. It's worth bearing in mind that the 'unified api' uses different native data types which may require some work arounds depending on the current structure of your original code.
The biggest point is what I mentioned earlier, in Apples App Store if you linger behind in terms of keeping your app up to date with the latest SDK, API, or anything else Apple decide to upgrade, then it is akin to giving up on that application.
I've put together some links below that may aid you in the migration process:
Native Types - Describes the new native data types that you will need to use in a Unified API app.
32/64 bit Platform Considerations - Considerations in choosing 32-bit and 64-bit modes for your application.
Updating Existing iOS Apps - Follow these steps to update an existing Xamarin.iOS app to use the Unified API.
Binding Objective-C Libraries - This document describes the process used to create C# bindings of Objective-C APIs and how the idioms in Objective-C are mapped to the idioms used in .NET.If you are binding just C APIs, you should use the standard .NET mechanism for this, the P/Invoke framework.
Binding Definition Reference Guide - This is the reference guide that describes all of the attributes available to binding authors to drive the binding generation process.
Updating UI Components - This is a guide to the process for updating UI componenets to the latest versions within the unified api.
I've currently built a service layer and API which I'm consuming from an ASP.NET website, Windows Phone app, and a Windows 8 metro app - the key to all of them being a project containing model classes which is a portable class library project, and is shared as a reference between all of them. This architecture works fine and without any issues.
However, I've recently started experimenting with Xamarin - specifically the iOS functionality (with a view to moving onto Android later). My initial assumption was that I would be able to utilise this model library as I do with the other projects - however, I've since realised this this isn't the case.
When I first added a reference to my model class library to my Xamarin.iOS project (in Visual Studio), I was greeted by the error:
'The current project does not support references to Portable Library projects'.
Strange - as I thought this would be a scenario that would be supported. I found a post here which suggested a fix that forced Visual Studio to detec the Monotouch (Xamarin) framework as supporting Portable Library Projects. Seemed to be exactly what I needed - but no. When I added the reference again, I was greeted by a different error:
'The current project's target framework is not compatible with that of the Portable Library project'.
And it suggests I change the target framework in the project properties. Except I can't, as the Xamarin iOS project needs to support Monotouch (and I can't change it to anything else from the GUI anyway). So I tried to change the model library's properties instead - maybe I can do something there. And it looked like I could. I can check Monotouch (Xamarin) as a supported platform here (where Windows phone, Windows store, etc are already checked), but it won't let me save. It just shows the message:
'There is no additional functionality that is supported by the target frameworks you have selected'
After some research, I discovered that the only way Xamarin suggest to share code is to use separate projects with linked code files (so in effect, a pseudo-single code base. Which I have tried and works - but it seems a hack. See here:
http://docs.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/sharing_code_options
So is this the only option? Or is there any way to have a true single class (model) library across all platforms, including Microsoft and Xamarin?
It is currently possible to use Portable Library Projects - e.g. profile 104 - across all of .Net4.5, WP, WinRT, Xamarin.Android and Xamarin.iOS
It is also currently possible to use the output binary assemblies across .Net4.5, WP, WinRT and Xamarin.Android - but not current against Xamarin.iOS.
This situation is changing 'very soon' now with Xamarin adopting full PCL support - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html and listen to http://hanselminutes.com/362/ios-and-android-apps-with-xamarin-studio-20-and-miguel-de-icaza
I personally deliver MvvmCross (and a lot of apps that use MvvmCross) using PCLs - and have done for the last 6 months - but there is some setup pain involved in this currently. For some info see my blog:
http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
http://slodge.blogspot.co.uk/2013/03/xamarinios-with-mvvmcross-in-vs2012.html
I do hope to provide an update on this in the very near future - it should work 'out of the box' soon.
The future is bright on Xamarin side, as it is going to support .NET 4.5 profile on all its platforms,
http://blog.xamarin.com/brave-new-async-mobile-world/
The only problem as far as I can see comes from Microsoft side, who refuses to unify its own platforms to a common profile (Windows 8 and Windows Phone 8 are still messy tailored versions no better than CF or Silverlight in my own situation).
Portable class libraries are out there, but as a library author (#SNMP) I rather build separate project files for my own projects as Xamarin suggests.
I'm a developer, with years of experience in C# as well as Java.
I have developed a few ADT projects for my Nexus One Android 2.23 phone.
I am considering further mobile development and I heard of Mono for Android/iOS and Xamarin. At first I thought Mono would recode to Java, but now I understand that it compiles to native C code and runs over mono libs.
So I was wondering how much bloat does this add to apps, as I believe size of download is directly linked to number of downloads (I myself sometimes don't download something due to it being > 1MB)
If there is someone here who uses Mono I would love to hear from your experiences.
I understand there is a Visual Studio 2010 Plugin for Mono. Do you recommend it?
So I was wondering how much bloat does this add to apps, as I believe size of download is directly linked to number of downloads (I myself sometimes don't download something due to it being >1MB .... )
Monodroid apps are usually somewhat around 5 Megabytes (if Linked) because the runtime is embedded in the app.
If there is someone here who uses Mono I would love to hear from your experiences.
All in all i'm pretty happy with Monodroid. Java tutorials on Android are easy to translate or if too big you can create Bindings. I've only done one project on Mono so my experiences are limited but thus far i've expected nothing that would make me regret my choice. On the other hand, if you're familiar with Java (and like coding in Java) their is no reason to switch over except for Cross Plattform apps (see Monocross).
The VisualStudio plugin is necessary to develop in VisualStudio. The new version comes with a Layout Designer like the Android Eclipse plugin. I'd recommend you download the trail version from Xamarin and try it (the trail has no expiration date, it lets you only deploy to an emulator)
Can I write and compile code for this on XP? We have utilities for our apps that use activesync and now will be adding Vista/WMDC - and I was hoping I don't have to have another development OS (Vista) to develop and compile on.
I have not seen much documentation for the API for WMDC - can someone point me to some useful references for it?
hummm... ActiveSync, so Windows Mobile am I right?
all you need is the SDK and Visual Studio (well, this last you don't need cause you can compile everything using the command line, but, very nice to have for such applications)
there are plenty of SDKs for what you need, for example PocketPC, Windows Mobile, etc...
the sdk contains everything you need to build, compile and deploy an application, works fine on windows XP (what I currently use) and with ActiveSync, you can even debug the application in the device ;)
added:
unfortunatelly there is no SDK for the WMDC. The only thing you have are the 4 libraries in the %WinDir%\Windows Mobile. It contains 4 libraries named as "Microsoft.WindowsMobile.*.dll". Additionally you don't get any documentation on the libraries themselves which makes it hard to use.
As you use the RAPI (I think by using the OpenNETCF library) most of the applications shall still run under WMDC as the included RAPI seems to be backward compatible. The included RAPI itself is in a new version.
taken from MSDN forum
I hope this helps for the moment.