I see that Google Play no longer allows uploading updates to an app if it does not target API level 31 or higher.
But on my Eclipse+ADT setup, SDK Manager only offers up to API level 29:
Is it still possible to get API level 31 to Eclipse, or must I upgrade to Android Studio in order to meet this requirement?
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.
The February 2017 update of the Tango Core seem to break apps built with older versions of the SDK. Specifically, TangoSupport_updatePointCloud() seem to fail on our app built with Dec 2016 Biyelgee C SDK.
We're wondering if anyone else is getting similar issue and whether is this a legitimate Tango Core issue?
EDIT:
Confirmed that rolling back to previous version Tango Core get us back to working state.
If using the JAVA API: Yes there is a breaking change, it is referenced here on the release notes for eisa.
That link gives you the steps to migrate to Eisa and fix the problem.
Warning: This change requires existing Java applications using depth
to recompile against the E-release SDK to continue working properly. ...
If your app is using the Java APIs with depth, you must recompile your app with the latest Tango SDK and push an update to Play Store. Recompiling may require some code changes, given the Java callback changes (see below) and earlier deprecation of XYZij in favor of XYZC.
I am making windows 8 application using c++/cx but i am not able to get how to include azure feature in my app,every where tutorials is given in c# but nowhere i can find tutorial in c++/cx.
As most of the samples written in managed code to access Windows Azure Mobile Services, It is trues that there are no samples available in C++/C. However it does not mean you could not do it. Keep in mind you would need to do extra work to get it done.
As Windows Azure Mobile Services use RESTful interface so you can access them from any language as long as you can call REST api from there. Here is the documentation for Windows Azure Mobile Services REST Api.
With C++/C you just need to search and find an appropriate framework to call REST api and once you have that working just call Windows Azure Mobile TEST Api to achieve your objective.
This blog post has some examples of how to perform various Azure Mobile Services tasks using C++ for Windows 8.1 Store apps. The IDE tooling mentioned in that post is not available for Windows 8 apps.
I'm planning on developing Android Apps. I downloaded the SDK and AVD manager, and about to download the SDK platforms.
My question is, I want to develop apps for 2.x platform. Do I need to download API 7-10? Which one to target?
Also, if you have tips regarding this, please mention them. Thank you.
It is not necessary to download all the platforms, just download the latest SDK and make your application compatible with other SDK.
For that you just need to define android:minSDKVersion and android:maxSDKVersion, android:targetSDKVersion.
<uses-sdk android:maxSdkVersion="12"
android:minSdkVersion="8">
</uses-sdk>
Here is a detailed article on "Compatibility" in "Best Practices" section at Android Developer site.
In short
For 2.1 you have to download API level 7
For 2.2 you have to download API level 8
For 2.3 you have following choices to download API levels
2.3 - 2.3.2 -- API level 9
2.3.3 - 2.3.7 -- API level 10
For seeing API levels and Android OS versions you must see :API Levels
I recommend you to go through Platform Versions atleast once before you start building any android application.
I am developing (yet another) password manager add-on for Firefox. My add-on needs to:
Add two context menu items to each password field.
Open a dialog box or floating panel when the menu item is selected.
Access a specific method of a specific XPCOM component.
Fill the password field.
Include a preferences window.
Be compatible with Firefox 4.0.
Preferably, also:
Run on Firefox 3.5 and 3.6.
Some users don't update to the latest version.
Firefox 4.0 won't run on a PowerPC Mac.
Install without a restart on Firefox 4.0.
Allow for localization.
I have tried the Add-on SDK (formerly known as Jetpack), and it makes it very easy to start developing. However, I find that HTML cannot easily create "native looking" dialog boxes and that the SDK is rather heavyweight. (It takes many kilobytes to build a simple extension; that includes an XPCOM component!)
What are the advantages and disadvantages of using the Add-on SDK to develop my Firefox extension? Is it ready for "serious" extension development?
Advantages:
Jetpack API exposes high level APIs for most of the things you mentioned:
Add two context menu items
floating panel
API for password manager
Jetpack based add-ons are restart-less.
Jetpack based add-ons are future proof in a sense that high level APIs will remain unchanged
for the coming versions of FF.
You may be able to use some community developed modules for APIs that are not exposed by SDK.
If this is not the last extension you're planning to build there is a potential for code reuse,
by building third party modules as ones mentioned in 4 (see docs for details)
Support for mobile FF is coming in post 1.0 version of Addon-SDK which may mean that your
extension can be made compatible with mobile version of FF with minimal to zero effort.
Jetpack comes with build-in unit testing framework.
Has a better security model, which will ease add-on review process.
Jetpack support commonjs modules / packages that which means that some of the code can be borrowed
from other projects like nodejs for example.
Disadvantages:
Jetpack no longer supports FF<4.
Does not yet have support for localization.
Has no API for building preference panels, but can be developed as third party module and shared
with rest of the community.
Add-on will contain code with layers of abstractions, that will increase size of add-on (there is
ongoing work that will reduce xpi size by excluding files that are not used by add-on).