Develop Reference

How far back do you support Android Apps? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Just curious as to standard practice for writing a new app.
Do you write your code to support all the way back to API 15 (Android 4) and try to support basically all Android platforms out there? Or is it mostly "code for the most recent and if someone complains, add back support"?
I'm using the java.time lib and am finding it's only available in Java API 26 (Android 8). Should I just use this directly? Or include code to check the phones version and add in code for those older versions?
Thanks!

I think Android 4 already supports a lot. I'm currently working on a Launcher application and I've had 0 issues supporting everything from API version 14 and up.
When you really need a higher API version for a specific function / library, I'd recommend to pick 5 or 6, they also support a pretty large percentage of devices (see link for source).
But I think as many developers as possible should support older devices. For most purposes older Android phones are already fast enough. If more developers would support older phones (and devices), they wouldn't be dumped in drawers so fast (that's just a waste). In my experience nothing more than software is responsible for this behaviour (isn't Windows Phone a good example of what lack of software can do to a - in my opinion - very good operating system?).
Android 4.0 is my minimum though, going lower would require me much more time.
For a good overview of the users divided by Api versions, you can visit:
https://developer.android.com/about/dashboards

As far back as it's convenient to support.
If I can support an earlier version by avoiding the use of some minor convenience added in later versions, I'll typically support the old versions without a second thought. A practical way to approach this is to set your minimum SDK version to something even lower than you think you might want to support, and gradually raise it as you encounter reasons to do so. I need a compelling reason to support older versions if doing so requires a significant amount of extra work.
Know your target audience.
The developer dashboard is useful, but it's not everything. I'm working on an app right now that I expect to be used on old, retired phones that people have dedicated to a specific hobby. That's an example of a compelling reason to support old Android versions. I've also worked on an app that needed to support Android 2.1 (when 6.0 was current) because the customers using it had a large investment in old hardware.

If you are going to make an app for Android 8 and newer versions, you are going to cover only about 30% of Android devices at the moment.
You can check the developer dashboard for the distribution of devices: Developer dashboard
At first you can focus on developing the app for newer devices and write fallback code for older devices later.
It also depends on who your target users are.

Is it safe to compile againts later JDK? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have some big projects running on Java 6. But I plan to start building them in Java 8 since a lot of build tools have moved away from Java 6.
Is it safe for me to simply compile them with Java 8 and then deploy them in a web container running Java 8? If not, what are the considerations?
FYI, they don't have a proper automated test suite in place.

The problems can be related to:
deprecated methods that are removed in java 8 and you used in the old java 6 code
different behaviour for some methods:
There are aspects of the platform's behavior that are intentionally unspecified and the underlying implementation may change in a platform release.
configuration of web container that can be different from a version supporting java 6 and the version supporting java 8
external libraries that changed during the passage from java 6 to java 8 removing old methods so that your code can't compile
So yes it is possible that the passage from java 6 to java 8 can broke your code.
But if the code compile it is quite sure that the behaviour of the code is the same, because generally (but not always) a retro compatibility is granted. You can be sure of that only running a complete set of unit tests both on java 6 and java 8 versions.
Here some example of not compatibility between java 6 and java 7:
JDK-6527962 : Retire the non-standard package com.sun.image.codec.jpeg. If your code use this package the it doesn't compile on java 8
JDK-6563734 : Path2D.Float and Path2D.Double should have final getPathIterator methods If your code ovewrite the methods declared final the code will not compile passing to java 8
Here a complete official list of incompatibilities between java 6 and java 7
Here a complete official list of incompatibilities between java 7 and java 8

It usually should be, since most of the features are backward compatible. However, there are no guarantees. Please do follow the proper process and do testing before rolling out to production.
For web container , with jdk, version would also have changed. This may cause some problems depending upon the software vendor and what all services you are using from the container ( JNDI, connection pooling etc).I once had a problem in migrating application to higher version of JDK. We also upgraded Websphere. We were using JSF, and higher version of WAS had JSF jars included, which was clashing with our application jars.
Your apps may be using a lot of 3rd party library which may be impacted. Again, mostly you should be Ok, but there can be small issues. Without knowing your applications, I can only suggest migrate and test to confirm.

You need to test things very thoroughly. If there are bugs, then it is imperative to find them and fix them before you move on to the next version. If you have a sunny day scenario and do not have bugs coming from the upgrade, then at least you know that for sure after the testing.
However, you need to know what to focus on. You need to read about changes applied on version 7 and on version 8.

Development cost regarding android API support [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Im relatively new to Android, and I am considering the possibility of developing an application supported by devices with API 1.6 and up, but I am unsure of what this will mean in actual code. I want to have some extra information that could be helpful in order for me to decide...
I understand there is supportv7 and supportv4 native API libraries, that aparently give support for older android versions (from 1.6 I believe) to more modern functionality.
But will this mean extensive code for the same functionality?
Will this mean having separate code snippets for same functionality for every API level?
Better yet,
What major differences can I find between targeting, for instance, API 4.0 onwards by default or 1.6 onwards by default, if any?
Thanks for reading, hope I made myself clear.

When deciding on API level to target this website gives really good information about the breakdown of the current market.
https://developer.android.com/about/dashboards/index.html
As you can see API < 10 accounts for very little of the current breakdown.
I can tell you from experience that upgrading API levels is a pain. If I were creating a new app I would go no lower than API 14 as the minimum. Anything lower than that will be become further and further obsolete in a few months. You will not be losing too much business and will have access to a lot of the newer calls without having to use the support libraries.

It really depends. Typically speaking, you will need additional code to support older API levels, but it isn't different code for every level. The deciding factor to whether you need segments of code to support the API levels is whether or not you use the functionality that was introduced in the newer APIs. A quick example of this is the HOLO theme. This is a pretty common theme used to give android apps a similar feel, however it wasn't introduced until API level 11 (3.0 I believe). If you want to implement this theme and support pre3.0 devices, you need special code to handle that. If however you choose not to use this, there is no need for special code.
All that being said, some of the newer features are very convenient and make a programmer's job much easier. I think the last app I wrote I stuck with API 16+ as there were some tasks that would have been a nightmare to support pre API 16. I guess my thought would be to start coding with the minSDKVersion = 4 (android 1.6). The compiler will let you know if you have features that need special support for older versions. You will find out pretty quickly how much extra work supporting all the way back to 1.6 will take. Then you can properly evaluate whether you find it worth it to include the extra support or would rather adjust how far back you support.

Why shouldn't an Android app be written in C/C++ because you "simply prefer to program in C/C++"? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Updated(for clarity and to reduce ambiguity):
I'm going to start tinkering around with android apps. I was planning on writing the in C++ using the NDK (since I have more experience in C++ and prefer it to Java) but came across the following on the Android NDK page:
you should only use the NDK if it is essential to your
app—never because you simply prefer to program in C/C++.
I was under the impression that you should use the language that you prefer, as long as it fits the job. Could somebody explain why it is so heavily advised not to use C/C++ for android development?
Original:
I'm going to start tinkering around with mobile apps, specifically android which is the OS of my current phone, and I was wondering if writing the app in C++ (or at least the core, then wrapping in Java) was an acceptable option.
Some background, I'm a computer science major who has taken 3 C++ courses(intro, intermediate, OOP, and am taking an STL course in the spring) and only 1 Java course(intermediate). Because of this, I am more comfortable with C++ and prefer it to Java. I came across the following on the Android NDK page:
Using native code on Android generally does not result in a noticeable
performance improvement, but it always increases your app complexity.
In general, you should only use the NDK if it is essential to your
app—never because you simply prefer to program in C/C++.
I was under the impression that you should use the language the fits
the job as well as one you're familiar with
I may want to port the application to another mobile platform, such
as iOS, that supports C++ but not java
While Java is a high level language and thus should make development
faster, I feel like development would be slower because I would have
to relearn almost everything (since I have only taken one class on
the language)
Any advice would be much appreciate.
ps: many of the answers on this subject are from years ago and there are very few follow up answers that mention the NDK allowing the development of full native apps on android 2.3 and newer.

Think of it this way. You have the ability using the Java SDK to build a full working application that takes advantage of 100% of the APIs available to developers. There is nothing you can do with the NDK that cannot be done with the SDK (from an API perspective), the NDK just provides higher performance.
Now look at it in reverse. If you choose to write an application 100% in the NDK, you can still write a fully functional application, but you are limited in the number of framework APIs you can access. Not all of the Android framework can be accessed at the native layer; most APIs are Java only. That's not to say that all the APIs YOU may need aren't available in the NDK, but nowhere near ALL the APIs are exposed.
Beyond this, the NDK introduces platform-specific code which expands the size of your distribution. For every device architecture you intend to support, your native code must be built into .so files (one for armv5, armv7 and x86) all packaged up into the same APK. This duplication of executable code makes your app 3x the size (i.e. a "fat binary") unless you take on the task of building separate APKs for each architecture when you distribute the application. So the deployment process becomes a bit more work if you don't want your APK to grow in size significantly.
Again, while none of this is prohibits you from doing what you choose, it points out why Google describes Java as the "preferred" method for the majority of your code and the path of least resistance. I hope it sheds some light on why the documentation is worded the way it is.

If you're only going to develop one app in your life, use the NDK.
If you're aiming at learning Android development with the intention of developing more than one application during your lifetime - and want to be able to properly support them all - you're very likely to do better in the long run if you learn Java and use Android's Java SDK instead.

The programmers at King use C++ for their game logic. And they seem to be doing fine judging by their turnover.
In my experience, C++ is for problem solvers and Java is for problem avoiders. I love either language, but C++ is quite rewarding when you write good code. However, it may just take several moments of wizardry to get there.
You could recommend C++ for Data scientists as well, who would normally get their job done by, say, Python or R. C++ can do the same with as good or not better performance, but it just takes being a genius in the language. That is why I'd never not recommend C++ to the one that wants to do it - I'd just give a heads up to the treat that they're in for.

I found this interesting article from:
http://betanews.com/2014/07/22/why-c-is-the-perfect-choice-for-modern-app-development/
C++ was built specifically for platform independence and as such is found on every single operating system in existence. Your typical mobile user may know that Android apps are written Java and iOS apps in Objective-C, but what many don’t know is that there is more C/C++ code in memory on your devices than anything else. C/C++ drives much of the technology of small devices (like the kernel, which interacts with the hardware, as well as typical run time libraries) and the telecommunications networks that enable these devices. More importantly for a development team, is that there are C/C++ interfaces and libraries for anything you need to do on any device and platform. The Android NDK toolset is a great example of full C/C++ support that was added originally for game development teams to enable them to get the best possible performance out of the device by avoiding Java and the Android Java runtime Dalvik, the virtual machine on which Android Java code is executed on. It has been regularly improved to enable every Android service.

I would say use java for main app. But if you have some c++ code you need to port or some library you need that is efficiently implemented in c++, then use ndk for those bits

I don't see any reason to not use C++ for normal android development , If you have extensive experience in working in C++ and with complex OS like windows or any other such, then you can grasp android quickly and is not as much complicated as the other OS are. while learning java or working without learning it would be more frustrating and complex !

The most important consideration is that the compiled Java code will run on all android devices unchanged, whereas the native code will need to be compiled for all target platforms.
The general intent for both Java and Android is that you write the majority if not all your app in Java and use native things only when there is no other option... so everything about writing the app will lend itself to doing so in Java.
You'll spare yourself a lot of aggravation in bridging between the native and Java worlds by writing in Java.
As well, you will do yourself a big favor if you take the plunge and learn Java. Not only will your Android app be the better for it, but you will expose yourself to a significantly different approach to OO and you will be a better programmer for it.
Add to that the fact that you will side-step a whole bunch of security risks by writing in Java.
In my mind, this is a no-brainer - use Java.

Desktop application options related to Java [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
These days I got an offer related to a desktop application that I should create.
I'm a Java programmer. I had worked with Swing API about 4 years ago, so I can say that I have some experience with it. I also had worked with Flex 4 about one year ago, but I think it is not a good option for what I need. In my opinion it is not stable enough (present some strange behavior) and I think it is no longer maintained for Linux platform. - (if you think I'm wrong here, tell me).
So, I search for a good Desktop UI API that I should use with Java.
What are the actual desktop UI "trends", taking in account that questions on that issue are relatively old on SO?
N.B. When it comes to talk about platform independence and SWT, I think there are some issues. That's why I would not opt for it.

I would personally use JavaFX for any new UI development work in Java - it's now a 100% Java API and Oracle appear to be pushing it quite strongly:
JavaFX has become more tightly integrated with Java SE, and will soon become a standard component of the platform. Starting with JavaFX 2.0.2 / Java SE 7u2, the JavaFX SDK has become part of the Java SE 7 JDK, avoiding a separate download for developers. The next step in this integration is to include the JavaFX runtime libraries as part of the JRE, which will be achieved through the Java SE 7u6 / JavaFX 2.2 releases in summer 2012. This will ensure widespread adoption of JavaFX on Java-enabled computers, while leveraging synchronized updates and security fixes.
Having used it myself, in my opinion it's also far nicer than Swing in its API (more like SWT in that respect), looks far nicer by default, and far more flexible in what it allows you to do.