The docs on the ABS website seem slightly inconsistent.
On http://actionbarsherlock.com/usage.html it says
"Due to its use of the native action bar and its related classes on Ice Cream Sandwich, the library requires that both it and your project are compiled with Android 4.0 or newer."
This implies to me that it is okay to build both project and library with API 16.
However, on http://actionbarsherlock.com/faq.html it says "The library itself must be built against Android 4.0 (API level 14). Your project should be built using the latest version of the SDK as possible as long as it is 4.0 or newer."
This implies to me that API 16 is okay for the project, but the library should be built with API 14.
So, then, my question is, 16 or 14 for the library?
Thanks in advance, and thanks to Jake for writing and supporting ABS.
George
ActionBarSherlock is designed to make a decision on launch time:
Use the system's built-in ActionBar, etc. widgets and classes
Use ABS's compatibility ActionBar, etc. widgets and classes
It uses your build target to make that decision. If you target 4.0, then devices with 4.0 will use their built-in widgets and classes in your app. Devices with 4.1 and higher will do the same. Devices with any version below 4.0 (so, 3.2 and below) will use the compatibility ABS stuff.
Changing the target to 4.1 will make 4.0 use the compatibility ABS stuff, which is kind of unnecessary but not really harmful. But it's almost always better to just use what's on the device. So I'd recommend keeping it at 4.0.
Side note: 3.0 - 3.2 also have an ActionBar class, but it's missing a lot of features added in 4.0, so it's best to use ABS for those versions.
Related
I have a android library with com.android.support:appcompat-v7:23.0.1 dependency in the gradle.
Say any applicaion with different version com.android.support:appcompat-v7:23.3.0is in the build.gradle of that application uses my library.
Below are the list of questions I have doubt.
which version does the android take? Lower one or Higher one? How do i see it?
Won't there be any conflict if i use different version like 24 or 25 and above or same?
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
which version does the android take? Lower one or Higher one? How do i see it?
Gradle uses the higher one.
You can use the command gradlew dependencies to check the dependencies tree.
Won't there be any conflict if i use different version like 24 or 25 and above or same?
How do i make sure there is no conflict of v7 appcompat when any app uses my library?
In general the best way to maintain a library and to avoid the conflicts is to update the library always with the latest support libraries.
What if the compiledSDK of application is 23 with appcompat-v7:23.3.0 and and that of the library is 24 with appcompat-v7:24+. Which all support libraries does the android take?
If your library uses support libraries v24, the library and the app will require to be compiled with the same level = 24.
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 got an application developed with Monotouch 4.0.7. This app is running on iPads with iOS 4.3.
Now, I want to migrate to the latest Monotouch version is 5.0. Will I be able to deploy my app on iPads with iOS 4.3? Or Monotouch 5.0 only for iOS 5.0?
Yes, it is possible to develop for iOS 4.3 (or even earlier iOS versions) with MonoTouch 5.0.
To set the minimum iOS version your app needs, go to the project's options, and in the iPhone Application page set Deployment Target to the minimum version.
Have in mind that MonoTouch will not tell you if you use iOS 5.0 API in your app. You can add iOS 5.0 features to your app, but you must not try to use those features on a lower version (here you can see how to accomplish this).
You can upgrade to Monotouch 5.x without any problems. In Monodevelop, change your SDK to 5.x
Just make sure your deployment target remains 4.3, if you still want to target that platform.
You will have to pay attention to not calling any methods that don't exist in 4.3.
If you want to have different/extended behavior on iOS 5 devices, you can check the OS version and use a different code branch.
Another small thing to be prepared for: iOS5 behaves differently in some situations. For instance if you are having hierarchical UIViewControllers, iOS5 will automatically call all UI events like ViewWillAppear(), even if you don't use the new UIViewControllery hierachy API.
What I want to say: test your app thoroughly on both iOS versions.
I wanted to convert a small test application from Windows .NET 4 to MonoTouch but I am missing System.IO.MemoryMappedFiles.
Then I tried it with a plain Mono console app and the namespace isn't there either.
I tried Mono 2.10 in combination with MonoDevelop 2.4.
Is it supposed to be there or not? I'm kind of confused, as .NET4 compatibility was announced with Mono, as far as I know.
Mono 2.10 has some support for memory mapped file. However it is not 100% complete (and Windows-specific things like security are not likely to be ever included) so YMMV.
You can browser what's available from the GIT repository:
https://github.com/mono/mono/tree/mono-2-10/mcs/class/System.Core/System.IO.MemoryMappedFiles
Since this is a .NET 4.0 feature you'll need to use the 'dmcs' compiler to get your code to compile (and also reference System.Core.dll where the types resides).
As for MonoTouch it provides a subset of Mono (originally based on the 2.1 profile from Silverlight and extra, even some 4.0, features). Currently (for MonoTouch 4.x) this does not include any type from System.IO.MemoryMappedFile.* namespace. Future versions will offer more .NET 4.0 features (if they are available from iOS).
To continue in my post-XCode 4 upgrade confusion, i came across this....
My Build Settings has Base SDK as iOS 4.3.
Now back in XCode 3.x days I remember 2 things:
The Base SDK was always set to iOS 4.0.
The target device was set to iphone 3.0 (to ensure greatest iphone audience).
What consequence is there for this Base SDK?
I mean, if SDK 4.0 provides support for features that only iOS4/iPhone4) provides, then why are these two separate build settings?
You can choose iOS 4.0 as your base SDK, but as long as you do not use APi's that are 4.0 and up your code should run on 3.x unless you used apis that were only in 3.2 and so on =)
Always a good thing to check the availability of methods when you look in the class reference.
I recommend using 4.x stuff.. because the people that use 3.0 are not worth supporting ( Only the really old devices are still running that, iPhone 1 -- most users have upgraded by now to an iPhone 3Gs or 4 ), the features you get in 4.x, including GCD are awesome.