I need to run an activity and remove all the other activities for my application to save memory. I have seen in the sdk that the flag FLAG_ACTIVITY_CLEAR_TASK does exactly this but I can't find it in the ActivityFlags enum in monodroid.
Is this possible to be done with monodroid?
ActivityFlags.ClearTask is available in Mono for Android. However, Android didn't introduce this flag until API version 11, so I'm guessing that you're targeting a previous version. In order to use this flag, you'll need to update the minimum version of Android you target to 3.1, which is configurable in the project's properties page.
Edit: This question has some other approaches you can take to do this on previous versions of Android.
Related
Is there a way to have Xcode tell me when I'm calling a method that isn't available in the SDK of the minimum supported target?
For example, the method [NSURLConnection sendAsynchronousRequest:queue:completionHandler:]. This method is available on iOS5 and up. But my application's minimum target is iOS4.
If I use that method (sendAsync), I'd like Xcode to tell me that that method isn't available for the minimum target I'm trying to support.
I've tried putting __IPHONE_OS_VERSION_MAX_ALLOWED=40000 in the preprocessor settings, but that just triggers a bunch of Apple SDK errors that aren't helpful. (Probably because my active SDK is iOS5.1)
Is the only solution to get ahold of old SDKs and install them in Xcode?
Are there any easier solutions?
There is unfortunately no standard way of doing this. By setting the target OS to a lower number than the base SDK, Xcode will weakly link the libraries and frameworks. When doing that Xcode will not warn you for using methods that may not be available on the target OS.
You could temporarily set the base SDK lower, but that might not always work. Since you want to ignore most of the errors and warnings produced (because they are only called conditionally in your code path), and many warnings and errors are dependant on other error that you may need to resolve before the compiler will give any meaningful output.
I do not think there exist any static analysis tools for this, neither from Apple nor third party.
After doing some research, reading the Apple Doc about it, and trying a number of things. The solution is downloading an old Xcode DMG from Apple, grab the .pkg file for the same SDK as your deployment target and install it in your version of Xcode. Here's how:
Download older Xcode.dmg from Apple
Open the DMG
In Terminal, go into packages: "cd /Volumes/[DMG]/Packages; open ."
Find the SDK you want, something like iPhoneSDK_4.0.pkg
Install that package, but change the install directory to /Applications/Xcode/Contents/Developer
Restart Xcode if it was open.
Now that you have the same SDK as your deployment target, set your BaseSDK to the same. When you build you'll get warnings about missing methods. Your project may or may not successfully build with an older BaseSDK in a new version of Xcode, but that doesn't matter - you've just found the method calls you need to wrap in a feature check with respondsToSelector:.
As of Xcode 7.3, the compiler can now generate these warnings for you. All you need to do is set the -Wpartial-availability warning flag in the Build Settings, as described in this answer.
Some background info: Syntax color/highlighting and auto-suggest stopped working correctly. I read a lot of questions about how to fix this but none of them helped me as they were related to Derived Data.
I'm learning Swift from some online tutorials, and noticed my syntax highlighting was different to that of the course teacher's. Then I noticed that when I create an instance of my struct, and use the dot syntax after the instance, Xcode didn't auto-suggest the struct's functions and variables, whereas it does in the downloaded version of the project. After some investigation I noticed that a key difference between my project and the teacher's is that my project has a Deployment Target of 8.1, whereas the teacher's has 8.0. I changed mine to 8.0 and immediately the syntax highlighting was restored and I could access the struct instance's functions and variables.
I'm guessing this may be a bug in Xcode, but perhaps I have something misconfigured in Xcode? I'd be grateful if anyone could explain how/why this bug occurred and what is best practice when choosing the Deployment Target.
The setting is located at Project > General > Deployment Info
I hope the above info may help others who encounter this issue.
Deployment Target is the iOS version that your app is intended for. This does not mean it is incompatible with other versions, simply that it is designed to work best on that version. Generally, using the app on a device with a newer version of the OS is much safer and less likely than using the app on a device with an older version of the OS. There's actually a lot of restrictions around installing an app with a deployment target higher than the OS version on the phone.
The most common deployment target right now is going to be 7.x, as most apps were updated when iOS 7 first came out (there was a pretty big change in UI standards and SDK functionality from 6 to 7), and iOS 8 isn't too terribly different from 7, so there's no need to restrict it and/or write new versions of the app for the new SDK. By having a deployment target of 7.x, you should ensure that the app works well on 7.x and all higher versions, including 8.x. You should also have the lowest deployment target you can that's reasonable - so, a purely iOS 8 app should ideally be targeting iOS 8.0. You'll save yourself a lot of PR and invalid bug reports from users who don't understand versioning.
In your scenario, it sounds like there may be a bug in Xcode when using the iOS 8.1 deployment target. You might want to check and see if your docs are downloaded. Go to Xcode -> Preferences -> Downloads and ensure everything is downloaded. I'm not sure if these are actually used in syntax highlighting and completion code, but it's possible. I would also do clean the build folder (Product -> Hold Alt -> Clean Build Folder). Again, I'm not sure, but I think there's just some small thing that's not clicking here. I'm assuming you cleared Derived Data based on your first paragraph - if not, do that (Window -> Organizer -> Select Project -> Delete).
We have a static library in Xcode which we need to assign a version number to, just like in an app.
This is useful for many reasons, but mainly because if we could assign a version number we could easily build the library to a specific output folder:
Library-1.0.0
Library-1.0.1
Library-1.0.2
Library-1.1.0
Library-2.0.0
If you see what I mean.
It might also be useful for our clients to manage dependencies and such in their apps.
Is there a way that we can add a version number to the build?
Thanks for your help.
This has everything you need to know: Framework Versioning
Essentially it boils down to a few settings within the framework's Build Settings. There are Major versions and Minor versions. Major version is found in the build setting "Framework Version". It starts off with a value of "A" by default. Minor versions are set with the setting "Current Library Version".
Major versions indicate incompatiblity with previous frameworks. Minor versions indicate compatible updates to the current version.
CorePlot looks like the best library going for the iPad apps I'm looking into, but I've been fighting all day just to get it to compile in an OS 6.1 project set to use Core Date, ARC, and unit tests.
I want to use those specs, but I'm starting fresh, with no other code that needs salvaged, so it occurred to me that rather than fight through the tutorials that don't address installation in ARC; and through the fixes for ARC that never seem to get me all the way to compile-able; that I could easily take any bare-bones project with those basic specs and start bringing in the simpler additions I've already figured out.
Anything like that out there?
All of the CPTTestApp example apps for both Mac and iOS have been converted to use ARC. This was done after the 1.1 release, so at the moment you'll need to pull the latest code with Mercurial to see the changes.
Since the 1.0 release, no changes to the Core Plot project is required to use it in an app that uses ARC. The Core Plot header files will compile under all supported SDKs with and without ARC. Include the Core Plot static library in your app, either the pre-compiled version or one built as a dependent project, and it will link and run just fine.
Core Plot does not use ARC internally because it still supports older systems that cannot use it. It will be updated when the minimum supported system is increased to one that supports ARC on both Mac and iOS.
I have made a project in xcode4.2 and when i opened it with xcode4.5 ,iOS 6 SDK it gives error 255 and the reason seems to be absence of libxml2.2.7.3.dylib.
What are my options is there any other substitute provided?
thanks
Xcode 4.5, or more precisely the iOS6 SDK (because the libraries available are dependent of the SDK, not the Xcode version) still has libxml2.2.dylib.
It is just probably not the version 2.2.7.3 but a newer, up-to-date 2.2.x.y version that is embedded in the SDK now.
You should generally not link your application with a specific version of libraries like that, but better with a generic version like libxml2.dylib or libxml2.2.dylib.
Generally libraries respect the semantic versionning, meaning that:
their major version change only when the API is not backward compatible with the previous major version,
the minor version change only when new methods are introduced in the API, but are still compatible with the previous API,
patch version means that some bug fixes have been made, but the API hasn't changed.
So if libxml respect this semantic versioning (and I guess is does, like quite every standard library), every version 2.2.x.y of libxml is API-compatible with any other 2.2.x.y version and will continue to work with your program. A hypothetic new version libxml2.2.x.z will simply fix bugs, but won't introduce any change in its API. And when a version of libxml2.3.x.y will arise, it will still be backward compatible with 2.1 and 2.2 too (just adding new features but not dropping the existing ones).
Thus, you can safely link your application with the generic library version libxml2.dylib, which will automatically point to the latest 2.x.y.z version available in the current SDK. Or link with libxml2.2.dylib which will point to the latest 2.2.x.y version (these are symbolic links to the latest versions, as all UNIX-like OSes use to do)
I think SDK for iOS6 just contains different version of libxml