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.
Related
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 5 years ago.
Improve this question
The target environments of my code use older Java versions (Java 7, Java 8). I use JDK 7 for development.
Will there be advantages if I use the most up-to-date JDK for my development, which is JDK 9 (and specify source=1.7 and target=1.7)?
I am aware that my code must not use any API which is not availabke on the target platform.
For the can I? Yes. Since backwards compatibility is important in Java, there's no technical reason why you couldn't do it. Sometimes company policies mandate a specific JDK version for development though.
In general the main advantage of using a later version of the JDK than what you're developing for is getting familiar with the later version. This may also increase your interest to migrate the software itself to a later version, if you notice it to be useful: for example you notice you love lambdas, so you migrate from Java 7 to Java 8.
Since the resulting bytecode is the same (not that it really matters) and the tools you use usually don't depend on the JDK, it has very little other effect. You can (usually) run code safely on newer JREs, so there's no difference with that either.
For the should I?
Whether you should start using JDK 9 now is primarily a matter of opinion. As Oleg pointed out it's not actively pushed everywhere, so at least you're not late and have time to consider moving forward for a while still (maybe toy around with it first before considering it for work use). Due to the large architectural differences between Java 8 and Java 9, I'd expect there to be a lot bigger gap in acceptance than between older versions.
However it's not all gloomy. There's a pretty good wrap-up of the features here and even if you are sticking to Java 7/8 projects for the time being, I see no reason not to do that on JDK 9 when you feel you're ready to have a look at it (and there is no hurry). I haven't installed it yet, although I've read about the decisions (good choice they didn't remove Unsafe).
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.
I couldn't find this question asked, so I gotta ask: how closely does Android tie it's OS updates to Java's updates? I am currently developing on the latest version of Java (sometimes I'll work out the Java side and then stick it into Android) and I don't want to worry about Android's JVM.
The Android SDK requires Java 6 JDK. That alone should say that it doesn't use 7 (yet). http://developer.android.com/sdk/index.html
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.
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
I want to start making cellphone apps with Android as first choice but not the only one. I have 10 years of experience with Java, C#, C++ in commercial applications and I know that many things and practices for this applications are not valid for cellphones. Where do I start reading? How do I adapt my way of thinking to this new environment as quickly as posible? I plan to make some money with it sometime in the future as an extra income or a career change maybe, who know. Any resource or advice you could recommend will be very welcome. Thanks in advance.
Just start with Android Developer site http://developer.android.com/index.html.
It contains all you need for the beginning. Also take a look onto Commonsware android books,
those are really great both for beginners and experienced programmers - http://commonsware.com/books.html.
You could start with two great books listed as reference [1] (Ableson F. et al., Unlocking Android, 2009. Manning Publications Co., ISBN 978-1-933988-67-2) and [4] (Conder S. and Darcey L., Android Wireless Application Development, 2009. Addison-Wesley, ISBN 978-0-321-62709-4) in my degree thesis. Both have an extensive walk-through of Android, which you as a developer should know. You'll get all you need from "Hello World" to deploy an actual application in the Android Market.
Android is the place to start, since you already know Java and C# and C++. You can even use native classes in Java written in C or C++ if you have some useful standard classes in your library. More on Natives you'll find in the reference book [9] (Silva V., Pro Android Games, 2009. Apress, ISBN 978-1-4302-2647-5).
The best of luck!
Only support the TOP os's which generate income. So at this moment IOS and Android.
Don't go down the path of Symbian and Java... it's dirty, and you won't like what you see down there.
What really got me going was the Hello, Views documentation. Will really get you up and running instantly.
I recently decided studying Android, and http://developer.android.com was a great resource. You should read the Application fundamentals doc first and User Interface documentations later.
There are some tutorials too.
I read the whole Application fundamentals, and that gave me a good idea of "how to program for Android" since it has its own architecture and environment. Get the idea of Activities, Services, Broadcast Receivers and Content Providers and try to adapt yourself to that structure. Then read about how Tasks work, and later go into UI.
As a subjective opinion, being Android so popular and growing, I don't think it's worth the effort to study Java ME or even C (I'd go for iPhone devel in any case with Objective-C). Android will probably give you more money and faster. Java FX might be interesting...
iPhone
Android
Samsung Bada
I would like to mention that iphone and Android communities are very much evolved and have a great developer community and resources. Samsung Bada doesnt have a good developer network nor does the SDK support many operating systems. I think it works only on Windows.
You need to first understand the mobile platform architecture, the different frameworks which the platform exposes to the programmers to develop applications.
There are emulators for you to test, however you have to have one of those devices to do a real time on-device testing.
With respect to programming, i think your experience is more than enough but one needs to come out of the frame of mind and think differently. A typical device has limited processing power, limited memory, limited screen space but the user demands beats expectations compared to desktop/enterprise software.
Lastly most important thing is the IDEA of the application. You may want to survey existing application on the stores and start thinking. You can also develop and application which would solve your problem with mobile devices and you know other users also may want such a application.