I'm a bit curious as to why there is no official site for JQMobi. As of now, it seems like the only place where I can download JQMobi is through github. And every time I search for JQMobi on Google, Intel's APP Framework shows up.
Is there some kind of connection between JQMobi and Intel's APP Framework? Are they the same or is JQMobi not supported anymore?
jqMobi was renamed to Intel App Framework.
Intel acquired AppMobi in 2013, the company that was maintaining jqMobi framework, it is now called Intel App Framework.
Related
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'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 :)
Intel XDK is a really promising tool for X-platform development.
Is Firefox OS considered as a supported platform for it?
Firefox OS is not currently supported by the Intel XDK. Could it be supported? Yes. Will it be supported? Not sure. As of this writing, our primary targets are those that support the Cordova API and the recently introduced Crosswalk runtime for Android. (The new Crosswalk target includes a Cordova 3.0 implementation.)
There are a lot of questions that need to be answered in order to support Firefox OS, mostly having to do with how do we support the Firefox OS API AND make your test/debug experience meaningful within the XDK. At the moment the only device APIs we can help you test and debug in a meaningful way are the Cordova and Intel XDK device APIs.
Check out our forum periodically for updates and improvements to the product.
Microsoft's AntiXSS library has been broken for 6 months and it looks abandoned (that may or may not officially be the case). Due to a security issue with previous versions, it is not safe to rollback to an earlier release. Are there any good actively developed alternatives for AntiXSS and web security in general when working with the Microsoft (specifically MVC) stack?
There's a new xss sanitizer shipping with the June 2012 release of the ajax control toolkit. The toolkit was originally using the microsoft anti xss library as well, so they experienced the same problems. The new sanitizer is based off the HtmlAgilityPack
See http://stephenwalther.com/archive/2012/06/25/announcing-the-june-2012-release-of-the-ajax-control-toolkit.aspx
I have the same issue and I've been looking high and low for a solution but haven't found anything else out there.
Basically, I think the only option moving forward is to use some flavour of WMD (like they do here on Stackoverflow)... send it back to the server as WMD markup then save it in the database as HTML and then convert it html when spitting it out on the page on the server.
This could be a good start: http://code.google.com/p/pagedown/
There is a unofficial port of WPL called AntiXSS.NetStandard that support AntiXSS in .NET Standard 2.0 (.NET Core 2.0+, .NET Framework 4.6.1).
Background: This is for a university managed lab environment. Upper management wants to know how often users are using the various software we purchase for the labs. I've already implemented a solution for our Windows machines which consists of a client that tracks user process invocation and sends the results to a web service.
Now I need to create an equivalent Mac client but I have zero experience developing for the Mac platform and its various APIs. Our Macs are currently running 10.4, but will eventually be moving to 10.6 within the next year. I think I've got a handle on consuming the web service using something like gSOAP or even Mono. For the process tracking, I was looking at the Carbon Event Manager. But I've been reading that the Carbon APIs are on the road to being deprecated and I'd rather find something that will be supported moving forward.
Should I just use the Carbon stuff for as long as it works? Or is there some equivalent library I could be using that won't be phased out anytime soon?
Carbon APIs are not being deprecated, Carbon applications are. Feel free to use the event manager.
See The myth of Carbon’s 64-bit unavailability