My application is compiling against Windows Creators Update (15063), but is supposed to run on a minimum version of 10586; however, some colour resources we used seem to be missing on old versions.
The exact whereabouts of failing resources are unknown (as the incompatible resources are), so temporarily, I want to give a global fallback value to eliminate crashes on old SDKs.
Is there any programmatic C# or automatic XAML way I can do it?
You could check whether certain features are available at runtime. There are many ways how to achieve that. You can read more about how to write version adaptive code for example here and here.
Related
I have looked into at least 6 different SQL Lua extensions, and they all seem to have their latest version compatible with up to version 5.1 of Lua. I have had zero success in implementing any of them into my current project which uses Lua 5.2, with the best case scenario ending in either silent program crashes or attempt to call global 'module' (a nil value).
I am not the original project owner, so I am trying not to be forced into changing the source code for it (though more recently, I have even gone down that road now).
And often times, it is unclear if these crashes are related to the way the project itself operates, the way the project implements Lua (as a static library), the way that Lua tries to implement it's extensions, the way the extensions implement their dependencies, a versioning conflict, or some sort of crazy combination of each. It's practically impossible to debug a silent crash in this manner, because the source of evil could literally be anything.
As the answer states in this question, I have even tried supporting the module function (which most lua sql extensions utilize, but was deprecated in 5.2), but the program still crashes or just complains about a seemingly infinite amount of missing dependencies. And after spending hours of tracking down (what would seem to be) all of the dependencies it would complain about, it still crashes.
Changing the project's source code to use the Lua 5.1 source appears to break the functionality of the project, resulting in various compiler errors regarding missing 5.2-related functions. Linking the MySQL C/C++ connector to the project results in rather vague runtime errors, which seem to conflict with the way the project implements Lua 5.2.
Are there ANY sqlite/MySQL extensions out there which actually work with Lua 5.2 on a 32-bit Windows machine? Preferably, "out-of-the-box" precompiled binaries with Lua source/ffi bindings?
OR alternatively, are there any clear instructions on how to get this set up properly, without having to scavenge through separate instructions across the web for each required assembly?
My C# app uses a C++ WinRT component I've written to get a list of system fonts using Direct X.
This is based on this example:
http://msdn.microsoft.com/en-us/library/dd756582(v=VS.85).aspx
My app is published in the store, but my latest update failed to pass the store review process on point 3.10 complaining about my use of Direct 3D and how this might not run on ARM tablets. As far as I know I'm not using Direct 3D and the only Direct X feature I'm using is GetSystemFontCollection.
How can I make sure I don't fail this requirement and do I need to remove some rogue reference in my component to Direct3D?
Also, why am I failing this now, when it passed before?
Did you target all three platforms or choose any cpu in your release?
Does this page help:
http://msdn.microsoft.com/en-gb/library/windows/apps/hh994923.aspx
It looks like you may have inadvertently requested a higher level.
I submitted again and included a note to the tester explaining that my app didn't use any Direct 3D features, and I told them the exact DirectX function I did use.
I still failed, but the Direct3D reason was no longer one of the reasons.
Apparently my app is crashing, which was another failure reason the first time round, but I thought this must be related to the Direct3D problem. I can't reproduce the crash, but at least I now know that I can stop looking at my use of DirectX. This was a red herring.
I am building my app using iOS 5.0 as base SDK and iOS 3.0 as deployment target.
I know I need to check for existence of methods and classes when I work with features that are not available in the earlier iOS versions, but lately I've lost a few hours on a problem just to discover I was calling a method not available in some iOS versions. I simply did not notice it was a new method and did no check before to call it. The app of course compiled with 0 errors and 0 warnings.
This is a big problem because if I forgot some other check somewhere in the app, I will not know it until I or, worst, some user will activate that specific part of code.
Maybe I am missing something, is there some compiler option I can set to detect the calls I make to methods not available in the iOS deployment target? How do you deal with such a problem?
This link might point you in the right direction. Supporting mutiple ios Versions in your apps. It explains how to deal with taking advantage of the newer ios features while maintaining backwards compatibility. Hope that helps.
The only way to check for compatibility with a prior version of iOS, currently, it to test the app on an old non-updated device running that version of the OS.
If you can't find a device that old, even just to borrow for short time, then there may not be a good buiness reason to set the Deployment target that low.
I just released my app but I am only able to make it compatible from 4.3 and up.
When I try to go any lower than 4.3 (xcode), it says I need to add code to make this work.
Does anyone know how to do this or has any suggestions? I would like my app to be compatible with 3.0 and onwards.
Thank you very much
You have to reach the least common code, what I mean by this is that you must find all the methods that are all incompatible within all of these versions of the OS. After that you will have to find each and every of it's functional equivalents. Then you can use conditional statements to check for every version and see what fits better or you can use the respondsToSelector method inherited from the NSObject class. In the end you have to test it on each device you are targeting :P
You can run this checkup list that I have always liked.
Edit:
I think I misunderstood your question though it has already been mentioned, be sure to check your deployment target in your build settings.
Checklist:
In your project's build settings…
Did you set the "iOS Deployment Target" to iOS 3?
Did you include the armv6 architecture in both, the built and the valid architectures?
In general:
Do you link to any framework that is not supported on iOS 3?
Do you use any methods, classes or other features that have been added later?
I want to update/upgrade the standard Leopard install of Sqlite3 to >3.5 to use the new sqlite_xxx_v2 methods from a Cocoa project.
I can't seem to find any information on how to do this. Does anyone have any tips or a site that outlines the update procedure.
Also is 3.5+ supported on the iPhone. I understand it's embedded so shouldn't be an issue...
What you want to do is grab the amalgamation sources from http://sqlite.org/download.html . Then just compile that into / add it to your project. You don't want to replace the system sqlite- that'll have unintended consequences in other applications. Plus, I'm pretty sure the system sqlite isn't a stock sqlite... Apple has probably made their own modifications to it that core data relies on.
You can read up on the amalgamation stuff here: http://sqlite.org/amalgamation.html , but in short: '''The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3 and RTREE extensions'''
I'd also suggest not using the sqlite calls directly, they weren't designed to be used that way (says the author of sqlite). Instead, there are a number of cocoa wrappers out there, including fmdb: http://code.google.com/p/flycode/source/browse/trunk/fmdb/ (which I wrote) :)
-gus
You don't really want to upgrade the system version of SQLite on Mac OS X. The reason is that all Mac OS X software is qualified against the versions of the packages that it includes, as built by Apple's build process. Installing a different version of a package, or even building the same version yourself but doing so slightly differently than Apple does, may result in a system that behaves unexpectedly.
Finally, if you embed a newer version of SQLite — or any Open Source library or framework included with Mac OS X — into your own application, you should be sure to integrate the Darwin changes for it from Apple's public source site. That way you can be sure you'll get as close to the same behavior as possible from the library you've built yourself as the version Apple ships, which is especially important when it comes to functionality like file locking in databases.
I don't believe i've updated my version, but it's currently at 3.4.2, and i'm able to use the new methods with the current version.
And i'm running 10.5.5 with the latest (public) iPhone SDK.
It would likely be easier to just drop the library into your project and link it in from there.