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.
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 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.
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.
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 2 years ago.
Improve this question
I have to create an application which automates Outlook and Word and I want to use Java for that task. (The only allowed alternative would be VB6, so...)
After a quick Google survey I found several libraries, but I'm not sure which one to use:
J-Interop
SWT
JACOB
COM4J
jacoZoom
...
I have no idea how to compare these libraries and make an informed decision. It seems that COM4J is a little bit outdated, JACOB leaks memory (allegedly) and jacoZoom is commercial. Each and every one seems to require a lot of boilerplate code to perform a simple method call. (Which might be unavoidable given the design of COM)
Besides that I have no idea how to choose between one of them. Which one is the best?
We use Jacob in production environment and it works out pretty well. Nevertheless the projects seems to be not very active.
Speaking of which: Activity seems to be an advantage for J-Interop. We tried the project as well and it seems to work out pretty good with even better logging messages. I think we might choose J-Interop for new projects.
COM4J seems to be outdated, you're right.
As a developer seasoned in Java/Linux but ignorant in Windows, here was my experience (August 2015)...
Executive summary:
Go with com4j... with the caveat that:
You may need to build the latest (unreleased) code to get some important recent fixes.
Longer story:
At first, the propensity for code involving JNI to crash inexplicably made me look for a non-JNI solution. J-Interop seemed to fit the bill.
However, as I tried to get j-interop to work, all the Windows DCOM permissions and registry crap made it a total PITA. It's different for different versions of Windows, required changes must be made as Administrator, etc. I don't understand any of this Windows crap and it makes me want to puke anyway.
I then tried com4j and it worked like a champ. This project is very nicely designed. It auto-generates Java interfaces from the DLL's you are using. COM calling convention details are declared using Java annotations on the interface methods, allowing you to tweak these if necessary (no tweaks were necessary in my case).
There are several developers on github who have forked the project and contributed back fixes, which is a healthy sign.
The only caveat is that you may require some of the recent fixes which, as of August 2015, are merged into the project but not contained in the latest release (which is from March 2014).
So you may need to do a custom build yourself, which includes building DLL's in Visual Studio, etc. Even as a Windows hater/ignorant, I was able to do this.
COM4J still seems to be active - it has been moved to Github and has a new homepage:
http://com4j.kohsuke.org/tutorial.html
J-Integra by Intrinsyc Software http://j-integra.intrinsyc.com/ is your best option. It hides the complexity of having to know an unfamiliar programming language. It isn't dependent on JNI so you don't need to know JNI. J-Integra is also actively maintained and supported and Intrinsyc offers a pure 64-bit version for those people wanting to run in a pure 64-bit environment.
Intrinsyc offers free trials so you can test it out and see if it works before committing to any purchasing.
Companies like HP, IBM, SAP, and Oracle use it so you know its going to be fast, stable and well supported.
Appears bridj can do some COM interop as well: https://code.google.com/p/bridj/wiki/COM#Example
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
I just saw a comment of suggesting J#, and it made me wonder... is there a real, beneficial use of J# over Java? So, my feeling is that the only reason you would even consider using J# is that management has decreed that the company should jump on the Java bandwagon... and the .NET bandwagon. If you use J#, you are effectively losing the biggest benefit of picking Java... rich cross platform support. Sure there is Mono, but it's not as richly supported or as full featured right? I remember hearing Forms are not fully (perhaps at all) supported.
I'm not trying to bash .NET here, I'm just saying, if you are going to go the Microsoft route, why not just use C#? If you are going to go the Java route, why would J# enter the picture?
I'm hoping to find some real world cases here, so please especially respond if you've ACTUALLY used J# in a REAL project, and why.
J# is no longer included in VS2008. Unless you already have J# code, you should probably stay away.
From j# product page:
Since customers have told us that the
existing J# feature set largely meets
their needs and usage of J# is
declining, Microsoft is retiring the
Visual J# product and Java Language
Conversion Assistant tool to better
allocate resources for other customer
requirements. The J# language and JLCA
tool will not be available in future
versions of Visual Studio. To preserve
existing customer investments in J#,
Microsoft will continue to support the
J# and JLCA technology that shipped
with Visual Studio 2005 through to
2015 as per our product life-cycle
strategy. For more information, see
Expanded Microsoft Support Lifecycle
Policy for Business & Development
Products.
The whole purpose of J# is to ease the transition of Java developers to the .NET environment which didn't work so well (I guessing here) so Microsoft dropped J# from Visual Studio 2008.
For your question, "Is there a real benefit of using J#?"..
in a nutshell... No..
Instead of J#, I would rather prefer IKVM (http://www.ikvm.net/) to convert my JARs to .NET assemblies as well as access Java APIs in C#.
One of the killers I've found with J# in the past is that there is no built in support for referencing web services. That alone has been enough to deter me from it ever since.
C# syntax is so close to Java (and better in some ways) that you might as well learn C# instead of J#. And since C# is more widely used, you can easily find Java --> C# tutorials on google or check out http://www.asp.net/learn and watch some videos.
I don't think it's a matter of which language is better. In the .NET world there are some inconsistencies between the libraries different languages provide. There are certain functionality that is available in VB.NET that you might like to use from C# but can't. I remember I had to use J# to use some ZIP libraries that were not available in any other language in .NET.
I have used J# as an easy interim step to port a java library into C#. It made for a good way to port code I don't plan to maintain from Java to .Net. However, all new development is being done in C#.
Strongly agree that syntactically C# beats Java hands down, so there is really no reason to lament the demise of j#. Now trying to get c# compiling to Java bytecode might be an interesting move as Sun's hotspot jvm is great software.
Or, for a bit of fun with what might well become the next generation of Java, how about Scala on the CLR...