MvxSqliteConnectionFactory.GetConnection("dbName") is throwing an exception on iOS 6 / 7

[Ryan-Palmer]

When trying to get a connection on iOS 6 / iPhone 3GS the new sqlite implementation throws an exception
sqlite error.txt

[Cheesebaron]

This plugin simply wraps https://github.com/praeclarum/sqlite-net. I suggest you try opening an issue there. I can't test on iOS 6 since I don't have any devices running that old and deprecated operating system.

[Ryan-Palmer]

Sure, understood. I have fought tooth and nail to not have to support it, believe me. I'll try opening an issue there, cheers dude :)

[Cheesebaron]

It is strange that anyone wants to support less than 3% of total iOS distribution share. It is not worth the time...

[Ryan-Palmer]

Yeah, I know. They are probably one of the biggest telecoms providers in the UK and a small percentage of their user base is still a significant number of customers apparently. We are also supporting back to Android 2.3 and were doing Windows Phone 8 until Mvx dropped PCL support for Silverlight. All the fun.

[Ryan-Palmer]

I know this isn't relevant for you guys per-se but I think it might be because apparently sqlite3_close_v2 was only added in sqlite 3.7.14 and iOS 6 runs 3.7.13

ref:
http://stackoverflow.com/questions/14288128/what-version-of-sqlite-does-ios-provide
dotnet/efcore#3870

[ericsink]

BTW...

I just noticed you guys are now taking a dep on sqlite-net-pcl.

That package takes a dep on SQLitePCL.bundle_green, which I maintain as part of SQLitePCL.raw, and which is simply a meta-package that implements a policy for "which instance of the SQLite library should be used".

And the particular policy of bundle_green is "use the SQLite provide by iOS, but on every other platform, use a SQLite library provided by the SQLitePCL.raw project".

This is the policy that I believe @praeclarum prefers. But users of sqlite-net-pcl should be aware of this, and of the fact that other possibilities are available.

That said, I cannot imagine that iOS 6 compatibility would be the sort of thing that would motivate any sort of change in this area.

So this comment is just an FYI.

[Ryan-Palmer]

Hey guys - Just for your info, I got my hands on an iPhone 4 today running iOS 7 and i'm getting the same problem :/ I will try a separate test project to check it's nothing else causing it, but it is fine on iOS 8 and 9. Very strange. I am guessing that you would consider iOS 7 support still kind of relevant? (genuine question). I have put this on the sqlite-net issue too, but I thought I would update this as it affects your users as well.

[Cheesebaron]

Personally I don't consider iOS 7 super relevant. Just like iOS 6 it only holds a ~4% share, which I find very insignificant and not worth supporting.

[Ryan-Palmer]

Understood. I completely get that you have to focus the limited community efforts where they are most useful and you guys do an amazing job (and you in particular have helped me personally on a number of occasions). It does kind of make it difficult to move forwards with MvvmCross in our enterprise projects where the clients require us to support their customer base (which in this case does not reflect the world-wide stats as they are a particular demographic which are more likely to have older devices, especially hand-me down iPhone 3gs / 4 models). Just from a business perspective when there are support contracts involved etc it makes it difficult to make that decision. I guess it's an age old problem, not something that is particular to this project. Maybe (and I know you have enough on your hands) it might be good to maintain an official support schedule or listing (i.e. we support X versions of each OS now, and will be dropping support on Y date) so that it is clear up-front and can be included in contract discussions etc. Just my thoughts, and thanks again for the quick response :) Cheers dude!

[ericsink]

@RyanBuzzInteractive So you have a broad issue here about MvvmCross and its support for iOS 6/7.

However, the specific issue in play is about part of the SQLite wrapper library.

Let us suppose for the moment that the specific issue is the only instance of the broad issue. :-)

In that case, I would see no reason to throw out all of MvvmCross. Compared to the overall effort of writing an app, working around the SQLite issue is quite simple.

Especially because the specific issue is in the SQLite plugin, which you don't even have to use. There are lots of ways to use SQLite in an MvvmCross app, and the provided plugin is just one of them. I myself am working on a fairly large MvvmCross app, and I am not using the SQLite plugin.

[Cheesebaron]

Well in this particular case we are not really in control of what happens in the external NuGet package which we simply wrap around. So we can't do much about that. Just as @ericsink says.

As for other parts of the code that potentially does not run on iOS version X, I think the case is very limited in case of MvvmCross, I don't think we have actively done anything to break that support. Obviously there could binding descriptions for views that are not present in iOS version X. However, if you simply don't use them you won't run into trouble.

I do see where you come from with Enterprise X want something that is stable and run on old device Y, because they have customer Z which happens to use that old device and won't upgrade. We've had others ask about Long Term Support builds which will receive only bug fixes but no new features etc. Many of these things are just too time consuming and I would rather focus on fixing things for new releases. I think I expressed this very clearly in the 5.0 thread here: MvvmCross/MvvmCross#1415

[Ryan-Palmer]

Oh completely, I wasn't criticising at all and there are things that can be done of course. I just found myself in a position where we tried out the whole system on all platforms before we started, have built the entire core and basically finished the Android version, and then came back to iOS and found that the most recent update has stopped it running on 6 and also 7 it seems. I can't hold back on keeping the core up to date with Mvx as it is required for new OS versions and bug fixes, and since there has been extensive testing by our client on the current core (this is an app which will have 100s of thousands of users in its first few weeks...) I am not really in a position to start changing it in a fundamental way or writing custom implementations that I have to maintain. Deadlines etc mean we are supposed to be delivering iOS and Windows in the next few weeks....

None of this is any of you guy's problem or concern of course. I really appreciate the support you all give (for free!). I guess I was just thinking that if a framework is to be 'relied on' in any way then a timetabled official support schedule would be useful, even if it is dropping off old OSes regularly, so that we can plan and implement things before the change hits. If you use it on older platforms after that date, you do so at your own risk etc, but within that period you can be reasonably sure that it has been tested on the supported platforms. Who would do it and how is another question as there are so many factors at play.

I love MvvmCross and it has been instrumental in helping me understand a solid MVVM pattern, I don't want to sound ungrateful at all :) I am sure we will work out a way to get this all up and running. Thanks again for the help and feedback, Cheers!

[ericsink]

BTW, I just realized there is a simple way to deal with the specific SQLite/sqlite-net issue. Silly of me not to think of it sooner. It should require no code changes in any of the involved libraries. It's just a matter of how things get initialized. I'll spare you the details for now.

But it'll only work after @praeclarum and I get sqlite-net switched over to the 1.0 release of SQLitePCLRaw, which I figure will happen next week.