How can I use SQLite C API’s on any device running Symbian OS 9.1 or above? While it appears that 9.4 comes with SQLite built in prior versions do not. Looking at http://sourceforge.net/projects/sqlites60/ it appears that sQLite has been ported to older Symbian releases. The only problem is this code assumes you want to use SQLite with .net when I want to compile it into a .sis file and call the C API’s. Ideally I’d compile a Symbian equivalent of amalgamation.c and call the sQLite functions directly but am not sure if this is possible.
The sqlite port you linked to seems usable using the C API - there's sqlite.dll exporting the C API and `System.Data.SQLiteClient.dll exposing the .net API. It's also based on sqlite 3.5.4 which is not the most recent version. Some functionality of more recent versions may not be available.
Symbian OS 9.4 SQLite only has a custom client-server interface (RSqlDatabase and such) and does not expose the native C API. The C API is available from Symbian OS 9.5 onwards.
Related
So I updated to swift 3.0 and now my projects with realm 1.0.2 all give me an error.
RealmSwift compiled with older version of Swift language (2.0) than previous files (3.0)
I also tried to build a net new project and still get the build error, so I know it is not a conversion issue on the Swift side.
I found several Swift 3.0 beta users and tried to run the script to update my version to 3.0 and several other options. The last few posts appeared to use Cocoa Pods - which I don't currently use. Is that the supported fix path?
Any help or direction would be greatly appreciated.
I haven't tried it yet, but here is what should work.
Essentially, the compiler gives you a description of what went wrong. The framework was compiled with Swift 2.0, while your project or other files were compiled with Swift version 3.0 (which means you made the switch after upgrading to the new version of Xcode.
To fix this, you need to use the Realm framework compiled with a Swift 3.0 compiler. Since the Realm team doesn't yet provide a precompiled version compiled with Swift 3.0, you have to do so yourself. To do that, go to their Github repository, and follow the instructions in the README under "Building Realm":
Prerequisites:
Building Realm requires Xcode 7.3.
Building Realm documentation requires jazzy
Once you have all the necessary prerequisites, building
Realm.framework just takes a single command: sh build.sh build.
You'll need an internet connection the first time you build Realm to
download the core binary.
This should generate the Realm framework with the current compiler version, which you then just have to use to replace your current Realm framework with. After that, everything should compile as it used to.
As stated before, I don't know if this actually works, as I haven't tried it yet. I don't exactly know if Swift 3.0 is supported by Realm yet or if there are any other issues you could run into. So please let me know how this works out!
Now that Swift 2.2 / iOS 9.3 / watchOS 2.2 is out, can I update an app using Xcode 7.3 and still work on a iOS 9.2 device?
For example, if I started using #selector(someFunc) instead of selector("someFunc"), will this crash on a iOS 9.2 device?
iOS SDK is maintained to be backward-compatible (though I don't know, how far back). You can take a look at page SDK Compatibility Guide, Base SDK and Deployment Target Settings to read about "Base SDK" and "Deployment Target" project settings.
The latest language version (either Swift or Objective-C) can also be used with older iOS versions, because, no matter what the language is, the compiler will generate effectively the same machine-code at the end. There could be nuances like lack of some OS features (e.g. ARC is fully supported starting from iOS 5, though it's pretty much compiler/language feature).
It may be also interesting to read Xcode 7.3 Release Notes to get the list of new features and changes. This document does not states that some older iOS versions are no more supported.
There are a lot of tutorials/details on writing ANE's for Java on Android, but not for Java on Windows. Is it possible to do this?
To package Java code in a native extension on Windows, you would need a C wrapper (using the JNI invocation API). You might need to distribute a full JVM (though depending on what you know about your target machines, you may be able to assume a JVM and JAVA_HOME defined).
I know there are a lot of places where I can find sqlite data types such as in this link or this other link.
Maybe this question sounds stupid when I mention version 4 because version 4 documentation is not out there on the internet or maybe I have not been able to find it. Why is it that the dll library that I downloaded from SQLite site has:
also when I downloaded that library from here (sqlite-netFx40-setup-bundle-x86-2010-1.0.79.0.exe) and install the visual studio plugins I am able to create sqlite databases in visual studio as:
Note that I have several data types!!
I am very confused on the versions of sqlite. Am I using sqlite version 3? What are the data types that I can use with the version that I downloaded from here? If I am using sqlite version 3, then why does the visual studio table designer for sqlite gives me different data types than the ones from the documentation?
Seeing as there's no such thing as SQLite 4.x (yet, anyway), you're definitely using SQLite 3.7.10. The v4.0.30319 almost certainly refers to the .NET runtime, not SQLite.
SQLite has only a few built-in types, but ADO.NET has an interface to conform to, so this adapter does its best to map the set of types you see to SQLite's (much smaller) set of native types.
I've been searching for this info with no luck. I'm using SDK1 with 4.7.0. Works fine but has some issues with Postres so I need to update. The thing is...
I go to download RC SDK1.1 and I see windows version is 1.5GB!!
The Linux version is about 700MB.
Why is Win version more than double?
SDK1 was about 320MB for windows and 400MB+ for Linux.
So Windows version was relatively smaller than Linux version considerably and sdk1 was drastically smaller than sdk1.1. I hear that 1.5GB unpacks to 5GB.
Of course, if you download the framework and creator separately than it is normal size (roughly equivalent to SDK1). This just adds to confusion. Isn't the SDK == Framework + creator ?
Something is wrong here... Any ideas what is going on? Should I wait till full release version?
I think thats because only Windows supports development for Symbian platform using Symbian SDK that can be installed (other platforms use remote compiler). Nokia with Qt SDK 1.1 announcement mentioned that they refactored Symbian toolchains so now you can use Symbian ^ 1 and Symbian ^ 3 native APIs. I think that what made the installer so huge. On the web site I noticed they have web installer, so I'd recommend to download the web installer which is just 15Mb and I suppose it should be a wizzard page that allows you to select which parts to install. Just don't install Symbian native SDK or anything else you don't need.
Hope that helps