So, I'm current trying to learn and become a programmer. I've recently worked with C# but I really want to get into mobile apps, since most small projects really tend to fit better as mobile apps, rather than desktop apps.
The easiest, for me, seems to be the Android platform, but I'm having a problem... I don't own an android phone, but I could possibly purchase an old model. Naturally these will have an older version of Android, so here is my question...
How compatible are these different versions? Like, are there major differences when moving from Icecream Sandwich to Jelly Bean, or from KitKat to Lollipop?
How do app developers deal with this array of Android versions?
When you develop an app for an old version of Android, it will run without errors on all newer version of Android, unless you do something involving low-level stuff like direct kernel calls, but you will never encounter such issues if you only use Java.
Worst issue you'll see is your app visual style looking outdated on newer devices.
If you target API level 23 / Android 6.0 Marshmallow, you will still need to run your app on Android 6.0 emulator, to be sure that it won't crash when using new Android permission dialogs to ask for SD card access etc.
Related
We have an iOS html5-based app. One of the questions that's coming up a lot is if and when we are going to port to Android.
Because it's mostly html5, a port should be relatively easy. However, the HTML looks different on my Moto G than it does on iOS, even though Chrome on my mac does render it correctly. Now, I have some experience with cross-browser html development from back in the netscape/ie6 days, so I can probably figure out what's going on.
What worries me more though, is the fragmentation. If I get it to render correctly on my Android device, how do I know it works correctly devices with an older version of the OS too? On iOS, we simply require iOS6, as most iPhone users upgrade their OS. On Android, this is a lot more difficult, as users don't tend to update (or the manufacturers don't even provide updates).
Do I need to get my hands on a ton of different devices to test on? Any easier ways to test this? I'm new to Android development, so any advice would be greatly appreciated!
This is a common issue across Android Development. Device Fragmentation... our nemesis. What will make it even more difficult, as I have experienced, is that Android ditched the old WebView in favor of a Chromium based WebView in KitKat. So even the APIs are no longer the same from your Moto G to previous devices.
That said, there are a fair amount of resources available in helping assist with creating a Web App that will work with your site and the native device. Quite a few examples too.
I would begin here: https://developer.android.com/guide/webapps/index.html which includes a subsection devoted entirely to the Chromium changes incorporated in KitKat (https://developer.android.com/guide/webapps/migrating.html)
Additionally, there is this Pixel Perfect information site as well: https://developer.chrome.com/multidevice/webview/pixelperfect
Now you can set your minimum accepted and targeted API levels on Android, just as you would on iOS. For instance, if the minimum is 15 and it is targeted for 19, then you are specifying that your app will work for KitKat (4.4) devices, but support as old as Ice Cream Sandwich (4.0.3). There's really no reason to target an API lower than 15 anymore, unless something is very specific business reason to target a device that low. By specific, I mean more distinct than "we want to reach as many as possible."
Finally, there are emulators that you can create through the AVD (Android Virtual Device) manager that can replicate various OS levels and hardware configurations. A very popular emulator company called Genymotion (http://www.genymotion.com/) is also frequently used, however it is not free for commercial use.
I am a beginner on android programming. I am at the first at all. I wanna learn some important point.
Now, I am installing the programs and platforms which I need to develop Android Apps. On the SDK Manager there are few options to download Android API.
Which one should I prefer? I want to that, my app will run on all android roms and versions like ICS or JellyBean.
Thanks!
In order to support as many users as you can, you should opt for the lowest version API, since apps written for an older version of Android will work for future versions as well (although they may not be optimal). Once you need a feature in a later version, you can increment your minimum SDK version.
I would look through the different SDK versions (e.g. 2.1) and see which features (and/or permissions) you need for your app.
Keep in mind that older phones may not have certain capabilities, and you may not be able to support them. Therefore you should weigh if what you're adding is worth alienating the users you will no longer be able to support. Android provides a table of market share per version.
You mention that you want to support ICS (4.0) and Jellybean (4.1 and 4.2), which together control a little less than 50% of the Android market. It is worth looking into supporting Gingerbread (2.3) as well for another 45%.
Another option of course is to branch your code depending on the user's OS version, but this requires a little more maintenance work. However, if you are supporting pre- and post-Holo-themed versions (ie for the action bar), it may not add that much overhead.
It really depends on your target market, purpose, and familiarity with Android.
Android maintains forward-compatibility which means an app designed for 2.1 for example will work on later versions (in most cases). However there are some features added in later versions which are only supported starting with a certain SDK version.
This page may be helpful for you
I've developed my first app and it worked fine on my phone (Android 2.2). When I tested in a Xoom (Android 3.2), it had lots of bugs, though. I need this app to run in many different versions of Android. How can I develop it and make sure it will, having only an Android 2.2 in hands for tests?
Developing with the last version targeted in the manifest while keeping a close eye to back compatibility is how you achieve this with the best efficiency.
Many libraries (ActionBar Sherlock, NotificationCompat2, ....) will help you in making your app back compatible without issues.
I strongly recommend making the app for the last version of Android so it is ready when this version gets some steam instead of targeting whatever version is the most popular right now. It is a bit more work at the beginning, but it will save you many headaches later on.
The emulator will help you test this, the best configuration is to have a terminal with the last version of android at your disposal (this is why the nexus are a very good choice for a dev) and different configurations on the emulator to test back compatibility or other form factors.
I'm starting to broad my developer skills also to the Android development.
I installed all the tools and configurations and every thing seem great, As a default settings I install the 3.2 SDK, but there is not too much docs on that one, mode of what is out there is on the 2.x SDKs.
Is it like IOS, does android have a good backward computability? Can I stay with the 3.x and count on it (with the features that are in the 2.x SDKs) to work on 2.x phones? What are the common version in the Android devices this days? I have lots of newbie develop questions like that, as i want to start from a good starting point and there are lots of materials and tutorials over the web that are not up to date.
Also, does any one know about a good site for this kind of Q&A?
Thank you,
Erez
As of July 5th the version with the largest market share (59.4%) is 2.2 (API Level 8) as shown here
http://developer.android.com/resources/dashboard/platform-versions.html so Consequently I would recommend using that as a starting point unless you are solely focusing on the new honeycomb tablets (<1% market share).
As for backward compatibility, android is completely backward compatible for the most part. Unless of course you use a new feature that is only available starting with a certain API level. Google's Android market is good about only allowing apps that will run on a certain API being visible to that phones user. This is enforced by the API level as recorded in the manifest file that is created with every Android app and set by the developer.
To help you with the API level, the SDK docs show what API a feature/object started with in the upper left hand corner. You can also view the specific changes in each platform and it's corresponding API level at http://developer.android.com/sdk/index.html.
As for a good website to get started I would recommend the developer site at developer.android.com and this website of course. Also the book Android Wireless Application Development by Shane Conder and Lauren Darcey (2 ed) Is very good. (I am not connected with the book just currently reading it). Make sure you get the latest edition.
Hope this helps,
George
Above is good info, but it would be advisable to develop for 2.1 and up at the moment, considering as of this answer's writing, 2.1 makes up 17.5% of the market and 2.2 makes up 59.4% of the market.
http://developer.android.com/resources/dashboard/platform-versions.html
OP should also be advised that version 3.x is specifically for tablets, so that may not be the best choice for a starting developer. My advice is to go with 2.1. Most of the documentation is up to date with that, and you won't have access to things you don't need yet (fragments, tablet-specific things)
Hope this helps!
You can read about application forward and backward compatibility in the docs.
Generally apps are forwards compatible but not backward compatible - new APIs introduced in one version are not available in an older version.
This pie chart shows distribution of devices accessing the Android Market and based on this I would try to target devices using 2.1 or newer to cover most of your users.
Your decision should be based on whether you need a feature introduced in a specific version. For example, if you want to add NFC to your app, you'll need Android 2.3.3 or newer, but otherwise there's no reason to exclude older devices.
I recommend learning about Fragments and using the compatibility package to use them on targets below 3.0. This will make it easier to reuse view elements on both tablet and phone devices. Note that if you only intend to develop for phones, 2.3.4 is the latest phone version of Android at the time of writing. Later this year, 3.0 for tablets will merge with the phone version to provide a unified OS version as with iOS.
Android 3.2 is just released publicly on friday, July 15th. You can start-off with Android 2.3.3 and 3.2 installation and development.
Android applications are mostly forward compatible. (But not always)
The best place to find all your answers is developer.android.com
For testing purposes I need to buy an android device. Can I get a tablet device with android 3.1 honeycomb and use this to test apps developed on older android versions? Are new android versions backward compatible with older apps?
Not entirely. In many cases yes, but there are exceptions:
There have been some api changes, and more importantly, there are a lot of apps out there which did things that weren't entirely proper, but worked on the devices they were developed for.
Some older apps were written to use input devices not present on recent phones or tablets - hardware trackballs or dpads, buttons, etc.
Also no small number of older apps will display in a phone-sized area leaving the rest of the tablet screen blank.
Unfortunately, the flip side of the vendor customizability of android is that if you really want to do comprehensive testing you need access to a variety of devices, even for a single api version.
Can I get a tablet device with android 3.1 honeycomb and use this to test apps developed on older android versions?
Yes.
Are new android verions backward compatible with older apps?
Yes.
Back version is compatible with android 3.1 but only simple application means without any animation (Like Games) and some special features etc.