WSHLST app Error in Android - xamarin.android

I have downloaded WSHLST from GitHub and followed the project setup in Azure mobile services. It's worked with Windows Phone, but when i build against Android throws the below error page.
Note: The errors are something related to 'Android.Content.Context' error.
For the below code it shows the error. Kindly find below the image for your reference. Kindly help me to execute the solution in android.
var picker = new MediaPicker(activity.Activity);

I think WshLst and the assemblies in that repo were built before the Xamarin 2.0 launch. During that launch, Xamarin changed their strong name signing key - so that is probably the problem you are hitting.
If you want to use that code, then you'll need to update several assemblies/dependencies to get that working - see some info on threads like:
http://forums.xamarin.com/discussion/1476/changes-to-assembly-strongnames-in-xamarin-android-4-6-0
http://forums.xamarin.com/discussion/1475/changes-to-assembly-strongnames-in-xamarin-ios-6-2-0
That code is almost a year old now - and given the fast pace of development of all 3 of Xamarin, Azure Mobile Services and MvvmCross, then I expect you'll need to update quite a lot to make this codebase live again - but doing so could be very useful for others who follow you.

Related

Getting suddenly 403(.14) HTTP error after deplyoment ASP.NET MVC application over TeamCity

A few days ago I had to update our .NET Framework 4.8 web application. First it could not be builded because of some TeamCity error on the newest version, link here. After that it could be builded but since then it showed us a custom errorpage after deployment -> 403 - Forbidden. I just changed a string ("exec X" to "exec Y") so we can access a better and faster SQL procedure.
Removing the tiny piece of argument it suddenly succeded in building anyways but the HTTP error still was there.
Neither IIS, Server, Framework Version etc. was updated, only TeamCity and that small code and argument change.
Reverting the changes to the version which had been working fine did nothing.
After a while I found out that it is a 403.14 error and static files can be accessed, but Microsofts help page didn't help a bit, it just showed the directory -> look here.
After that, I decided to shutdown and backup TeamCity and install an older version of it -> Nope.
Searching google and stackoverflow for similiar problems I stumbled upon to this post especially where I tried every single answer. Before I answer further questions on about what I had tried, please read it.
Since nothing helped so far I decided to try something "dumb" and publish the project to the folder and copy the data manually to the server and voi la! It worked! But I don't know why
and also TeamCity still can't do it anymore.
No changes were done to AppPool or other settings, please keep that in mind.
Here are my build settings from teamcity:
Please don't mind missing build steps, since those are either uninteresting or disalbed because some of them I had created to test the failing deployment on our test system.
And also, when running it locally or copying published project works fine..
Problem was with the antivirus blocking some processes, so some Asax_global.dll was missing.

Problem when publishing an application on the App Store [Non-public API usage]

Until three weeks ago, my application could upload it to the App Store without any problem. However, Apple has refused to upload the app with a new message about Non-public API usage.
The application is developed with Xamarin in Visual Studio for Mac and has updated all the libraries and packages. Can anybody help me? Because I can not find what the problem is, nor do I see any solution. It will be something new?
Thank you all.
Non-public API usage:
The app references non-public selectors in AppAytoSS.iOS:
addTemporaryAttribute:value:forCharacterRange:,
addTemporaryAttributes:forCharacterRange:, behaviorWithType:,
defaultBaselineOffsetForFont:, defaultLineHeightForFont:, finished,
greekingThreshold, horizontalCornerRadius,
initWithSource:convolutionState:weights:, initWithType:,
postSession:didAddPlayer:, postSession:didReceiveData:fromPlayer:,
postSession:didReceiveMessage:withData:fromPlayer:,
postSession:didRemovePlayer:,
postSession:player:didChangeConnectionState:,
postSession:player:didSaveData:, preferredMetalContext, removeData:,
removeTemporaryAttribute:forCharacterRange:, setGreekingThreshold:,
setHorizontalCornerRadius:, setIsPrimary:, setShouldAntiAlias:, setUUID:,
setVerticalCornerRadius:, shouldAntiAlias,
temporaryAttribute:atCharacterIndex:effectiveRange:,
temporaryAttribute:atCharacterIndex:longestEffectiveRange:inRange:,
temporaryAttributesAtCharacterIndex:effectiveRange:,
temporaryAttributesAtCharacterIndex:longestEffectiveRange:inRange:,
textContainerChangedTextView:, toolTip, usesBackgroundSession,
verticalCornerRadius
We had the (exactly) same problem with an Xamarin iOS Project and where able to fix it via Setting Build/iOS Build/Linker Behaviour: Link Framework SDKs only (before Don't link) - what Jack Hua link shows as solution.
We where not able, to figure out the problem behind though. Two different MacBooks where used, one with the most recent version of XCode, Visual Studio and Xamarin Libs, the other with slightly older versions. The latter was able to create an IPA without the above described error, the updated machine was not.
However the used NugGet Packages where the same, so I think this issue is not related to them.
After filling an internal issue with the Xamarin team, they advised doing the following
adding --linksdkonly to the Additional mtouch arguments on the iOS Build settings page
As it seems that Visual Studio ignores the settings in GUI
I have tested it and now get my build accepted by Apple without the above error
This is the issue filed on Xamarin
https://github.com/xamarin/xamarin-macios/issues/5913
I find a thread where people meet the same problem with you recently:build-status-has-changed-to-invalid-binary.
So, I guess some third part nuget packages you are using has updated and using these non-public selectors that Apple not allow.
I would suggest you to get you code three weeks ago and don't update any third part nuget packages. Then submit again to check if it is the problem.
You can also compare your reference with the references people listed in that thread and find something similar. And any nuget packages related to Player(As I can see some player selector in the non-public selectors list)?

Firebase-Unity Project: Exporting for iOS on Windows 10. Workaround?

Recently added Firebase Storage and Authentication to my Unity project. I work on Windows, have a single Unity Pro License, and want to export my App for iOS, as I have done many times before in this dev process.
However, since the addition of Firebase, I'm told I apparently can't export my Firebase-Enabled Unity project for iOS without swapping Unity to an OSX device (which I don't have in comparable quality).
I've noticed a singular thread here where a supposed workaround was discussed, but can't seem to pull it off myself:
"The plugin that comes with firebase depends on cocoapods to handle
transient dependencies. If you look at the Assets ->
PlayServicesResolver -> IOSResolver -> Settings
You can configure it to generate the podfile but not do the remaining
steps." - from user johnb003, March 18th 2017.
Can't seem to find the configuration settings described here. Scoured the forums/communities for solutions, but no results elsewhere.
So, that said, any other Firebase user have a workaround for this issue? I adore the collective Google has put together with their product, but I can't really afford to invest in another Unity Pro License just for the sake of working off of my sub-standard Macbook. Thoughts?
Looks like there's a Google Github project, Unity JAR resolver, describing how the Unity Play Services Resolver works for each target platform.
The documentation is pretty extensive, and solutions are use-case specific, so I can't give you much help on specific podfile settings, but hopefully you can sift through it yourself.

Two way communication in JIRA Mobile Connect for ios crashes the app due to sqlite locking

I am using the latest tag named "tip" and I am using JIRA on demand.
I just incorporated JIRA mobile connect into my ios app and it is behaving a bit oddly i.e. it is going into an infinite loop and hangs my app.
After turning the debug mode on and digging a bit deeper, I find the source of this problem is that the sqlite database table is locked.
The sequence of events is like follows:-
I launched my app for the first time
I created an issue successfully using JIRA mobile connect
I shut down my app
I updated the issue by adding comments in JIRA online via the web interface (to simulate a 2 way communication scenario)
I re-started my ios app
JMC gets the updates from JIRA rest api using https://xxxx.atlassian.net/rest/jconnect/1.0/issue/updates?sinceMillis=1408380024967&uuid=9371F70F-12CD-47EC-AB3E-4B0398FF453E&apikey=YYY&project=AAA- and it is able to find the updates that I had made in step 4
Since it finds changes, JMCIssueStore.m calls updateWithData method which has logic in it i.e.[self createSchema:YES] which attempts to drop the existing 2 tables and recreate the schema.
On the 1st table drop attempt i.e.[db executeUpdate:#"DROP table if exists ISSUE"],
the database table is found to be locked and JMC goes in an infinite loop retrying to execute this statement.
I am unable to find any answers for this on the Atlassian Q&A portal or otherwise on the web and I find it surprising as surely other people using this should be having the same issue or I have done something obviously wrong in trying to integrate it.
Has anyone encountered this or something similar? As this is one of the key features for which I am using JIRA Mobile Connect, i really need to figure out if it is worth debugging Jira mobile connect for this or just giving up and doing it from scratch.
The whole issue stemmed from a documentation error in the integration process of JIRA Mobile Connect specifically step 9 here where they asked to exclude all the JMC files from using ARC - which I had done. This is the root cause of the problem.
After going through the Angry Nerds Sample files and comparing it with my own, I realised they were exactly the same and still the Angry Nerds sample worked and mine didnt.
I retraced all my integration steps and on reaching step 9, it struck me that when I was going through the code, there were no sign of any manual release statements - which was odd if the code was indeed not using ARC.
I removed all my -fno-objc-arc flags from all the JMC files. And hey presto! the crashing issue isnt there anymore.

How can I use IDataErrorInfo with mvvmcross and monodroid

I am trying to build a cross platform application. Currently I am setting up a project using Xamarin MonoDroid 4.7 and MVVMCross. I would like to be able to use INotifyDataErrorInfo but I get the following compilation error:
The type 'System.ComponentModel.INotifyDataErrorInfo' exists in both 'c:\Program Files(x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\System.dll' and 'c:\Users\MvvmCross.PortableSupport.3.0.6\lib\MonoAndroid16\System.Windows.dll
Has anyone come across this/developed a workaround or solution?
Thanks
We think Mono for Android/Xamarin.Android has recently added this support - but the situation isn't clear - see https://bugzilla.xamarin.com/show_bug.cgi?id=5340
When we get this confirmed and work out which versions do/don't have this - which is hopefully in the coming week or two - then MvvmCross will hopefully be able to remove its version.
Also, I hope but I don't know that the MvvmCross versions of System.Windows, System.Net, etc can be removed in the near future - see https://bugzilla.xamarin.com/show_bug.cgi?id=8035
This is not at all clear at present, and it's likely to be a source of issues while PCL support from Xamarin moves through none->alpha->beta->stable
I'm afraid those 'NEW' bugzilla issues above represent all the information I have on this at present.
In the meantime... if you need to resolve the INotifyDataErrorInfo within your own project and environment, then one route forwards is to branch the MvvmCross source and to change the MvvmCross shim System.Windows.dll to type forward instead of replacing this type - the code is in https://github.com/slodge/MvvmCross/tree/v3/PortableSupport/System.Windows
I am sorry about these problems... and I'm very much looking forwards to having official PCL support from Xamarin so I no longer have to work around them.

Resources