After installing the Android SDK, I noticed that I need to choose the platform, i.e. Android 1.3 all the way upto 4.1 individually.
My question is, does this mean if I create an app, I have to create it on each and every platform individually?
I am a total noobie to Android development...
It's basically recommended to choose lowest API you plan to support in your application (unless you know you got reasons to have it set differently). For example if your app is for Honeycomb and newer versions only, then select SDK 3.0 to get access to all the features newly introduced in HC which you may want to use. But if your application shall run also on older devices with older versions of Android like 2.0.1 (or even 1.6 if you really need) set this to lowest API desired. So, now that rule is sufficient for you and lets you ensure you accidentally won't use any API method not supported on all platforms you target to which would lead your application to crash.
If not sure what API you want I suggest go for 2.x and simply ignore any older Android versions as it is basically pointless, according to platform version breakdown statistics published by Google.
I recommend you read this SDK article on how to define minSdk and targetSdk elements to match your requirements.
Take a look here
Basically it means that your app is meant to be used with this android version (but you can support higher or lower version too).
I strongly encourage you to read the documentation to understand better how the all thing works.
A simple answer is no.
When you are developing an application you have the provision to specify which is the minimum platform that you are developing for. The newer SDk will have more features which might not be available in old ones so care must be taken to see that your app is available for a specific platform.
I would suggest that you bookmark the developer.android.com and stakoverflow.com websites, they will be very handy :)
No. You can specify a minimumsdkversion for your app in your Android Manifest, so that it will support all the platforms from this API Level up to the newest platform.
See here for more information.
Edit:Of course you can't use some newer API functions in older SDKs, without the support lib, or some third party libraries(e.g the actionbar, fragments, expandable notifications etc.)
Related
What is the difference between adding dependency 'com.android.support:appcompat-v7' and 'com.android.support:appcompat-v7:23.0.0' in android gradle.
Because am trying to use quinny898 persistentsearch library which is not supporting in 23.0.0 as ActionBarActivity is deprecated in new versions.
ActionBarActivity is deprecated. You should use AppCompatActivity.
Please read v7 Support Libraries .I hope it will helps you .
Android Support Library package contains several libraries that can
be included in your application. Each of these libraries supports a
specific range of Android platform versions and set of features.
The important features and version support
provided by the Support Libraries to help you decide which of them you
should include in your application. In general, we recommend including
the v7 support and v7 appcompat libraries, because they support a wide
range of Android versions and provide APIs for recommended user
interface patterns.
v7 Libraries
There are several libraries designed to be used with Android 2.1 (API
level 7) and higher. These libraries provide specific feature sets and
can be included in your application independently from each other.
v7 appcompat library
This library adds support for the Action Bar user interface design
pattern.
android:versionCode
An integer value that represents the version of the application code,
relative to other versions. The value is an integer so that other
applications can programmatically evaluate it.
Courtesy goes to Difference between android-support-v7-appcompat and android-support-v4
Does JRE 1.7 work with all api levels of android?
I want to make an app by this situation:
<uses-sdk
android:minSdkVersion = "7"
android:targetSdkVersion = "19" />
Is this ok with jre 1.7 ? or do I need to use jre 1.6.
How can I figure this out which API level with which JRE version is compatible ?
The core Java libraries are part of the Android runtime(see image below) layer, but from developer point of view it doesn't matter. What you can do and cannot do is tied to Android SDK level you use in your project.
Which android:minSdkVersion you should use?
You can check the Android documentation. For every instruction /
command / method / properties, at the top right you'll find the API
level at which you are able to access said property. Clicking on the
API level will take you to a page which contains a table that
translates API level to Android versions.
As a general principle set android:minSdkVersion as low as possible. You will get a compiler error when you use something not supported by that level. This way you can support as many users as you can. See this for details.
Here is a recommended reading on this subject.
Android API level is specific to which version you are using(as in ICS, Kitkat etc). What JRE you use is independent thing.
But is it better you use the most recent JRE i.e Java 7 irrespective of what your API level target is.
It may happen that the recent API levels may use some java functions introduced in recent java versions. So again irrespective of your target API level use Java 7.
See this SO answer for more info.
I am writing an Android app which needs to be run on BlackBerry Z10, too. Someone mentioned that Android apps can be wrapped for BB. However I am not sure of the version. If I use 4.x specific features, e.g. swipeable tabs, will they be supported on BB, or should I use some older API, e.g. Eclair (2.1) to be on the safe side?
I just want to program once, and not twice.
Today, you should build your Android apps to OS version 2.3.3 (API level 10). So, you should produce a version of your app that doesn't use features in newer API levels.
Here is the official BlackBerry page that mentions this:
You can use the BlackBerry Runtime for Android apps to run Android
2.3.3 platform applications on the BlackBerry Tablet OS and BlackBerry 10. To use the runtime, you must first repackage your Android applications to BAR file format, which is the compatible file format
required for an application to run on the BlackBerry Tablet OS and
BlackBerry 10.
Update: it appears that BlackBerry has a status page here, detailing their roadmap for Jelly Bean support. Of course, every device won't support it the day it comes out, and BlackBerry has missed deadlines before. But, it's probably good to keep all those things in mind when planning your project.
The right decision for you will depend on how long you expect your development to take (2 weeks, 3 months?), how important the features are that depend on 4.x APIs, how much you're willing to assume BlackBerry meets their schedule, and how important a strong launch is to you. If only a small number of devices are actually upgraded to support Jelly Bean when you release, it may hurt your sales.
Anyway, the point is that it depends on a lot of factors. Hopefully, I've described most of the important ones.
I would suggest 4.2. This is because in June, next month, the platform will be updated to support 4.2 from 2.3.3. By the time you get round to publishing you shall be all set.
Apple's guidelines for their new Mac App Store say that you cannot use deprecated libraries such as Apple's Java framework. But will Apple allow apps which come with a third-party Java runtime, such as SoyLatte?
Yes, provided everything needed to run your app is part of the app bundle and your UI looks and behaves completely natively. You are barred from relying on users to have already installed optional or deprecated technologies (libraries, runtimes, or what have you).
Specifically, the rules most likely to be relevant state (PDF):
2. Functionality
2.22 Apps must contain all language support in a single app bundle (single binary multiple language)
2.24 Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
6. User Interface
6.3 Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple Macintosh Human Interface Guidelines will be rejected
6.5 Apps that change the native user interface elements or behaviors of Mac OS X will be rejected
Taken together, the two functionality rules quoted seem to indicate that you are free to use a third-party Java runtime provided everything needed to run your app is contained in your app bundle.
The user interface rules would bar any but the most flawless emulations of all the native UI widgets. Realistically, you would need some way to use native UI widgets from your Java application. Eclipse's Standard Widget Toolkit might meet the UI requirements, for example.
It seems ALL java apps will be banned:
http://www.theregister.co.uk/2010/10/21/apple_threatens_to_kill_java_on_the_mac/
No, they will not.
Consider these rules:
2.5 Apps that use non-public APIs will be rejected
2.7 Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them
2.15 Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
2.20 Apps that present a license screen at launch will be rejected
2.21 Apps may not use update mechanisms outside of the App Store
2.24 Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
5.5 Use of protected 3rd party material (trademarks, copyrights, trade secrets, otherwise proprietary content) requires a documented rights check which must be provided upon request
6.1 Apps must comply with all terms and conditions explained in the Apple Macintosh Human
Interface Guidelines
6.3 Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple Macintosh Human Interface Guidelines will be rejected
Using private or "deprecated" technologies are forbidden by the rules (2.5, 2.24) as well as code which depends on things not installed by default on Mac OS X (2.15).
2.15 would force you to bundle the whole JRE with your app. But that would violate (2.5) because the JRE will use non-public APIs to integrate with the Apple Look-and-Feel and probably 2.20 too.
Without that integration you would be in breach of 6.1 and 6.3.
Additionally that would make it your job to update the app every time Java gets a security update, because Oracle's updater for Java won't be allowed to work (2.21).
Eventually getting some letter from Oracle's lawyers (required by 5.5) might take some months, so you will be very late to the market and your app might be rejected by rule 2.7.
This has nothing to do with technology. It's a political decision just like what happened with Flash and if people try to sneak around it Apple just won't approve it. They have tons of rules on which they can base their rejection of your app.
Basically Apple doesn't want developers to write cross-platform applications and pushes them to develop Apple-"exclusive" applications in a language Apple controls.
Recently I have to develop on mobile phones using Java and I am planning to do the development on the following brands:
Nokia
Samsung
SonyEricsson
Motorola
LG
I've browsed the "developer site" of each company and looks like they all have provided their own SDKs for J2ME development.
I am really new to this field and I have a few questions:
Since they all support Java platform, why do we need additional Java SDKs?
What can I benefit from the SDKs?
What determines whether I should use the SDKs or not?
It all depends on how complex the application your want to develop will be.
Developing a basic application to run on that many different handsets is doable but complexity will increase exponentially with each advanced feature you add, especially if you want to target existing, old and upcoming devices.
What you also need to consider is that each manufacturer can support several operating systems and platforms.
Nokia has Series40 (3rd and 5th editions), Series60 (2nd, 3rd and 5th editions), Series80.
Samsung has at least 2 major versions of their own platform and the last 2 editions of Series60
SonyEricsson has 3 major versions of their JP8 platform (and JP7 too), Series60 5th edition, UIQ 2.x and UIQ 3.x
Series80, Series60, UIQ 2.x and UIQ 3.x are based on the Symbian operating system. Different versions of Symbian OS have used different JVMs and several companies have contributed JSR implementations.
Motorola has at least 2 major versions of their own platform and a couple UIQ devices
1 - Since they all support Java platform, why do we need additional Java SDKs?
The major problem of J2ME is fragmentation. For a variety of reasons (both good and bad, both technical and commercial), the Java promise of "Write Once, Run Anywhere" is largely considered utterly unfulfilled in the mobile industry.
Many functionalities need to be coded in a platform-specific way if you want the same code to work on many platforms at once.
Many J2ME platforms also add non-standard APIs, properties, configurations, "bugs"...
Most importantly, manufacturer SDKs are supposed to allow things like on-device debugging or MIDlet deployment over USB. They provide basic or extended tools that help on-device testing because that is an area where a generic WTK should typically be lacking.
2 - What can I benefit from the SDKs?
Very probably, yes.
Ok, so, most of them will only run on a Windows desktop computer but the SDKs themselves should be free.
3 - What determines whether I should use the SDKs or not?
Start with the WTK. When you realize you're trying to do something that is specific to the handset manufacturer, get the corresponding SDK.
One example: The WTK PDAPDemo sample application contains a rudimentary filesystem browser. It displays widely different results on different platforms.
As suggested by Pavel Alexeev, DeviceAnywhere is a great tool, assuming you have a proper test budget. Nokia also offers something similar but that is obviously limited to Nokia handsets.
Benefit from vendor-specific SDKs is only if you want to use vendor-specific APIs. In most cases Sun WTK would be enough.
As for testing purposes, I would not suggest to rely on emulators. You better try on-device testing. Nokia and Samsung provide remove device access for recent devices. And you can also try deviceanywhere.
I would do most of my development with the regular old Sun..err...Oracle Java WTK, and then if you need to do some testing, get the emulators/SDK's from those companies. Other than that I'd mostly avoid them though.
Built in camera functionality typically differs between different brands of phone and the API's provided can be very helpful when trying to do anything more advanced than take a simple snapshot. SonyEricsson phones for example will allow you to display a camera feed through a VideoCamera directly to a canvas which is very fast but does not not allow you to control how frequently the feed is drawn to the screen. In order to draw graphics on top of the video feed without excessive flickering you need to add the OVERLAY flag (1<<8) to the VideoCamera's initDisplayMode() call, not all brands support the additional flag.
For .NET guys - there is a Ubiq Mobile framework. Ubiq Mobile apps work on Android, iOS, Windows Phone and Java-based phones and tablets. This is rapid cross-platform development with .NET with cloud-based architecture. Getting started article: How to create simple UbiqMobile application with video.
My opinion is "QuickRecipesOnSymbianOS" is correct. It is very easy, simple and technical answer.