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.
Related
I started using Xamarin.UITest for cross-platform testing (IOS & Android).
With Android it worked instantly without any problem and it keeps forking even after any SDK update or JDK.. name it!
But for iOS there was so many issue encountered with the device agent that didn't want to start, the wrong Xcode commande one, the wrong Xcode. Some time it worked, but out of no where it crashes.. then you must clean, rebuild, retry, cross your fingers it doesn't crash or at least that it will launch..
But now April 19 2019, I had an iOS update, combine with an Xcode update and sadly, it doesn't work anymore. I made a lot of research and attempt to recover my test case:
Downgrade Xcode to 10.1
Downgrade Xcode commande line tool to 10.1
downgraded the OS!
To finally rethink it. It's not a good solid testing tool if it breaks at every updates.
On the AppCenter it still works for both platform. But to create your test, you have to run them locally.. You can't anymore with iOS and if you find how to make it work, let me tell you : "See you for the next update!"
So the question is:
What are the alternative to do some automated UI test for iOS & Android using Xamarin?
Xamarin.UITest Xcode 10.2 support
Sorry to hear about your difficulty with the Xcode update.
Unfortunately Xcode minor updates for the last several releases have tended to break local iOS simulator testing, and occasionally device testing. I've seen this be an issue since at least as early as Xcode 9.x versions.
For context, Xcode 10.2 support was added in this package: https://www.nuget.org/packages/Xamarin.UITest/2.2.7.2002-dev
If you or future readers of this discussion still do end up using Xamarin.UITest, I recommend checking the release notes when new minor versions of Xcode come out to see if that support has been confirmed. Typically the support has been added in the 1st Xamarin.UITest package released after a new minor version of Xcode has been released.
(I generally haven't seen this issue with patch versions though, for example Xcode 10.2.1 didn't seem to cause any issues when it came out if it was run against a test suite that was working for Xcode 10.2)
Other testing frameworks
As for other testing frameworks, if you're using App Center itself; then Appium (JUnit) or Calabash are both able to be used with App Center Test and can be used cross-platform to run against your IPA/APK, generally regardless of what was used to write the apps in the first place, like Xamarin.UITest. (Though each framework has slightly different set up requirements and limitations.)
Outside of App Center Test, there may be other testing frameworks you can use; but that gets more into individual developer opinion which strictly speaking is out-of-scope for Stack Overflow answers.
Appium Studio which holds all the pros of native Appium. It also supports parallel execution with built-in test reporting mechanism. They also provide cloud devices with which you can check whether it is feasible for your project. Check out their documentation for more features.
i'm getting the Warning when i upload my application through xcode 8.x.
Xcode for future app deliveries." WARNING ITMS-90725: "SDK Version
Issue. In July 2018, iOS app updates submitted to the App Store will
need to be built with the iOS '11.0' SDK or later, included in Xcode
[9.0] or later. Make sure to update Xcode for future app deliveries."
My project was developed in old swift 2.X language and some of the module in objective-c..
should i convert whole project to the latest swift 4.x and update all sdks?
Starting in July, all app updates and all new apps submitted to the App Store must be created with a Base SDK of iOS 11.0 or later. This requires Xcode 9.0 or later. This means your app must be in Swift 4 or later. You may still support earlier versions of iOS (either 8 or 9) in your app.
Swift 2 has been obsolete for a few years already.
So yes, you need to convert to Swift 4 and update any libraries you may be using accordingly. Use Xcode 8 to first convert your Swift 2 code to Swift 3 (huge change). Then use Xcode 9 to convert the Swift 3 code to Swift 4 (minor changes).
Apple wants you using the latest tools. You need to keep up. It's best to avoid waiting until cutoffs like this, it just makes updating your app that much harder.
Yes you update your code to swift 4.
First, they said April, and how that deadline absolutely positively included updates. Then the general lever wasn't actually pulled until right after May 1. Now they say July for updates...
Seems to be a moving target. That, and how the left hand is out walking the dog while the right hand is texting about the new red phone.
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 :)
We're building an iPad app and don't plan to use any APIs that are not available in iOS 3.2. Our deployment target is already set to 3.2, but I would like to set our base SDK to 3.2 so that we get compiler warnings/errors if we accidentally invoke APIs not available in 3.2, rather than runtime failures.
Is this a good idea? If so, is the 3.2 sdk still available for download, and will older sdks work with newer XCode versions, like 4? Thanks.
There's no guarantee Xcode will support older SDK versions but as an example the current install of Xcode 4 goes all the way back to 3.0. I would drop 3.2 if I were you (few iPad users are on that; most iOS apps enforce 4.X in the App Store so I'd bet most people have upgraded) but if you are going to support it perhaps you should consider using conditional code for different OS' versions.
I've downloaded the latest SDK from developer.apple.com and can only pick 3.2 or 4.1 from Project > Properties > Base SDK.
My iPhone is 4.1
My client have iPhone 3.x
You feel the problem...
How can I debug for iOS 3.x in xcode with the 4.1 SDK installed?
Actually that's a very frequent question (was lazy, only linked one).
Short version: you need to set your Base SDK to the highest SDK version you've got and your project's Deployment Target to the lowest version you like to support, e.g. 3.0. This means, the Deployment Target specifies the oldest version your app should be able to run on. But beware, this setting does not prevent you from accidentially calling, say, methods available since 4.0 on an 3.0 iPhone and thus causing a method missing exception.
This isn't possible have I come to understand.
You have to buy a old iPhone 3.x.
If you want my opinion on this, then I think this is horrible, frustrating and completely not understandable.