I am wondering what level of support the latest MonoTouch has for using SQLite. The closest information I can find is this article here which referes to limited support in v1.2 however it concedes that you may run into run time errors while using this.
This is what I found on the Xamarin website: http://docs.xamarin.com/ios/Guides/Advanced_Topics/System.Data
This really scares me. Is there any documentation out there indicating what current level of support Xamarin has for SQLite?
I can't speak about the changes in System.Data support past that article, but I think it's quite common for folks to use csharp-sqlite, or better yet sqlite-net instead. Csharp-sqlite is an independent port of SQLite. And sqlite-net is "better yet" in the sense that its a minimal library where you can drop a single file in your project and use it to support sqlite on the various mono platforms. Yet it has nice features still such as "strongly typed queries" due to reflection-based ORM. So if you don't need a full Sqlite driver its a good option.
Greg Shackles did a nice seminar on x-platform dev with Monotouch/droid back in April where he covers these and other libraries: http://blog.xamarin.com/2012/04/25/cross-platform-mobile-development-seminar/
This link is outdated, it's about MonoTouch 1.2 and the latest MonoTouch's version is 6.0.
I'm using Sqlite with Vici CoolStorage in two apps on App Store: easy and no problems at all. I've never see any runtime errors using Sqlite.
Related
I decided lately to move from Eclipse ADT to the latest AS version.
The first weird thing that I've noticed is that when I create a new project, it is always based on the Android support library even though I selected the minimum SDK to be level 19.
What is the reason for that?
Is there a way to configure it otherwise?
The reason for this is mainly backward compatibility. Right now, you may want to make your app for API19+, but later you may decide to lower it a bit down to support more devices, and you shouldn't be having problems with that, if you use support library.
There's also the thing that support library gets updated much more often than Android core library, therefore, if you base your project on it, it should be pretty much bug free.
One more thing, if you extend activity compat for example, the activity checks what version of Android you are currently having on your device and uses core features automatically if available, so it's good for you in many ways to use support library :)
I have seen that there are so wonderful ways in Xcode to design your CoreData models - is there a way to make use of this and CoreData in general in MonoTouch 5?
Any tutorials or examples?
Maybe is not the direct answer to your question but might be what you are looking for:
Sqlite-net is an open source, minimal library to allow .NET and Mono applications to store data in SQLite 3 databases. <- the one you are using but for future reference
Vici CoolStorage is a fully typed Object Relational Mapping library for .NET 3.5, Windows Phone, MonoTouch and Mono for Android
Catnap is a basic lightweight ORM for .NET. It uses the ADO.NET API. The project includes an adapter for Sqlite, and it is tested with System.Data.Sqlite and Mono.Data.Sqlite.
MonoTouch.SQLite An abstract UITableViewController to make displaying data from an SQLite table simpler.
Entify is entity framework for desktop and mobile applications. It aims to be stable and easy-to-use library that is effortless to deploy with any application. It has visual designer which allows developer to define application data model easily and quickly.
Just a side note on entify, it has not been updated since Apr 11, 2010 so idk if it still works
The only thing I could find about MonoTouch and CoreData was this blog post.
Hope this helps.
Alex
Here is the documentation for CoreData in Mono.
This blog post is almost two years old, but the only example I could find of using CoreData in Mono.
Most relevant to your question, however, this bug/request is for integrating Xcode's tools into Mono. It doesn't seem to even be under development yet.
Edit:
You can also use /Applications/Xcode.app/Contents/Developer/usr/bin/momc <source xcdatamodel> <absolute path to target> to generate the .momd. I'm still working on getting it integrated better - see this question.
Is it possible to use the iSQL SDK (www.mobilefoo.com) with MonoTouch considering that the iSQL SDK is a client library meant for use with XCODE and objective-c code?
Yes - not a complex task but a bit time-consuming. Although you should only have to do it once (until they extend their libraries.)
Instructions on how to bind to Objective C libraries and types are here: http://wiki.monotouch.net/HowTo/Interop/Consuming_3rd_Party_ObjC_Libraries
It might well be worth contacting mobilefoo about this too as I'd imagine they'd be interested and might even help.
I have a project built around Subsonic 3.0.0.3 and have run into the dreaded medium trust issue, can anyone tell me is there a way I can mod the code myself to get this working or what the expected timescale for 3.1 version is? Its looking increasingly like I will have to ditch subsonic to get my system running
Regards
Mike
No timeframe for SubSonic 3.1 (or 3.0.0.4), but here are the current plans: http://groups.google.com/group/subsonicproject/browse_thread/thread/caae09418ce4d975/
The SubSonic Google discussion group is the best place to find out about the current development happenings for SubSonic.
Short answer, as soon as possible.
Long answer, there's a number of things planned for 3.1 these include (but are not necessarily limited to):
Oracle support
MediumTrust support
Automatic mapping of collections in SimpleRepository
These are all in development right now but before they become the main focus we need to get version 3.0.0.4 out the door with fixes for a lot of the outstanding issues listed on github. There's also a lot of more boring work going on behind the scenes which should make regular and stable releases easier.
The current release schedule is:
Version 3.0.0.4 - 22nd March 2010
Version 3.1 - 22nd May 2010
When using 3rd party libraries/components in production projects, are you rigorous about using only released versions of said libraries?
When do you consider using a pre-release or beta version of a library (in dev? in production, under certain circumstances)?
If you come across a bug or shortcoming of the library and you're already committed to using it, do you apply a patch to the library or create a workaround in your code?
I am a big fan of not coding something when someone else has a version that I could not code in a reasonable amount of time or would require me to become an expert on something that wouldn't matter in the long run.
There are several open source components and libraries I have used in our production environment such as Quartz.NET, Log4Net, nLog, SharpFTPLibrary (heavily modified) and more. Quartz.NET was in beta when I first released an application using it into production. It was a very stable beta and I had the source code so I could debug an issue and there were a few. When I encountered a bug or an error I would fix it and post the issue to the bug tracker or author. I feel very comfortable using a beta product if the source is available for me to debug any issues or there is a strong following of developers hammering out any issues.
I've used beta libraries in commercial projects before but mostly during development and when the vendor is likely to release a final version before I finish the product.
For example, I developed a small desktop application using Visual Studio 2005 Beta 2 because I knew that the RTM version would be available before the final release of my app. Also I used a beta version of FirebirdSQL ADO.NET Driver during development of another project.
For bugs I try to post complete bug reports whenever there's a way to reproduce it but most of the time you have to find a workaround to release the application ASAP.
Yes. Unless there's a feature we really need in a beta version.
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
I'll use the patch. Why write code for something you've paid for?
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
Good point, I was also considering the scenario of evaluation of the pre-release version in dev, but I supposed that taints the dev -> test/qa -> prod path.
I'll use the patch. Why write code for something you've paid for?
What if it's not a commercial library, but an open source one? What if the patch to be applied is not from the releasing entity (e.g. your own patch)?
I use:
Infragistics (.NET WinForms controls)
LeadTools (video capture)
Xtreme ToolkitPro (MFC controls)
National Instruments Measurement Studio (computational libraries, plotting, and DAQ)
I've found significant bugs in every one of these, so I try to limit their use as much as possible. Infragisitcs is pretty good for what it is, and National Instruments is by far the best, although quite limited. I would avoid LeadTools at all cost.