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 7 years ago.
Improve this question
I am about to start android application development.
From What is NDK? documentation I was not able to extract the following information:
Does using NDK actually introduce new features comparing to SDK?
I am interested in this because using NDK greatly increases application complexity, so if I am not interested in performance increase, are there other reasons to go for NDK?
What I mean is for example:
-restart phone
(I know neither SDK nor NDK allows this, I just use it as an example of what I mean) let's say java SDK does not allow this, but some native libraries do - then the answer to my question would be yes, NDK does add some functionality
Thanks in advance for any helpful answers.
You really should use SDK, unless you have a good reason to use NDK. Good reasons may vary, but for example, you could use NDK:
If you want to use OpenGL ES 2.0 for Android 2.1 (Eclair), it is only avaiable through NDK. The SDK support for OpenGL ES 2.0 began with the Froyo version.
If you want to use Renderscript
If you have a great portion of your app's logic written in C/C++
The NDK is much more limited in terms of functionality.
What you do get from the NDK is the ability to write your app in C++ and compile it to native ARM code. If you like C++ better than Java, if you have an existing C++ app that you want to port to Android, or if you just need the extra performance that only native code can offer, then by all means you should use the NDK.
I haven't done this myself, but another alternative is to write hybrid app, where the app is written mostly in Java, with selected functions written in C++ that are called from the Java code.
The only reasons to use the NDK as far as I know is to squeeze extra performance out of your application and get closer to the bare metal. If you don't need to do either of these things, you should probably stay away from the NDK.
Also note that the Dalvik VM already has some pretty awesome performance and comparatively simpler.
For me, I think it’s important to know the NDK which is a powerful tool in the development of mobile applications. Especially if you want to develop a multiplatform application, the NDK is unbeatable in this domain. Since the same code written in C + + for Android can be easily ported and run the same way on the iOS, Windows or any other platform without changing the original code. Which actually save a lot of time in the development of applications which are developed for being run on multiple platforms; as games and other classic applications. Thing you cannot do with the SDK.
Native methods are platform-specific code. They are usually written in languages such as C or C++ and contained in libraries(dll's). It is possible to create a hybrid Java application that benefits from such libraries.
Reasons for Using Native Methods
Gaining access to special capabilities of your device or or Android
OS
Gaining extra speed
Gaining access to a large body of existing legacy code
Typically, good use cases for the NDK are CPU-intensive applications such as game engines, signal processing, and physics simulation
The major disadvantage of native methods is that you won't have cross-platform capability.
Now if you don't know what native code is, then probably you don't need to use native code. Android NDK documentation explains this well:
..., you should understand that the NDK will not benefit most apps. As
a developer, you need to balance its benefits against its drawbacks.
Notably, using native code on Android generally does not result in a
noticable 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++. When
examining whether or not you should develop in native code, think
about your requirements and see if the Android framework APIs provide
the functionality that you need.
Related
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
Doing some investigation on the feasibility of using QT/QML for an upcoming project. Client wants it initially on Windows and Mac desktops, with the possibility of iOS and Android down the road. They would like to know that what we build will move relatively easily. I'm not much of a desktop programmer, but what I see is that QML is designed to work with C++. As a result, it should be relatively easy to build an app that runs on Mac and Windows, and iOS will accept C++, so I can't see a lot of roadblocks there. But I'm confused about Android. I see folks talking about building an Android app using QML, but they seem to still be using java; I gather it uses the NDK in the background.
But if you write an application that has QML for the front and, and C++ for any guts not covered by QML, can it work on Android? Or do you need to rewrite the C++ piece in java? The app is not a simple one, so we are going to have to provide some logic outside of QML, at least, it sure looks that way. While we might save time and $$$ by using QT to not have to go native on the desktops and iOS, I see a problem with Android down the road.
But if you write an application that has QML for the front and, and C++ for any guts not covered by QML, can it work on Android? Or do you need to rewrite the C++ piece in java?
It really depends. You may need to go through the Java interface where the Android platform does not provide direct and public API for certain functionality. One example is low-level IO operations, like writing the serial port for usb-serial devices, but there is more to it.
In general, what Qt modules and third-party software based on Qt do is to use the QAndroidExtras add-on module introduced in Qt 5.2. This will allow easy backend integration into your C++ logic.
With that in mind, you could hide the Java implementation details in the background while you still maintain the C++ interface to QML. Therefore, it should just work that way.
Please see the following documentation to get the grasp of it:
Qt Android Extras
Here you can find one of those nice examples:
Qt Notifier - Demonstrates calling Java code from an Android application.
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 9 years ago.
Improve this question
I'm planning the development of a mobile SDK in the gaming field, that should be cross platform (iOS and Android to begin with)
I know that many game engines embed lua as a scripting language, to expose certain functionality easily to the developer, however i've never since it being used as the core language that SDKs are written in.
What are the pros/cons for using lua specifically for achieving a cross-platform mobile SDK?
Pros:
Portable: builds on any platform with an ANSI C compiler.
Lua is comparably as easy as Python in terms of learning how to write code.
Embedded and extensible language that provides a straightforward interface to/from C/C++/Objective-C. It has a very clean C API.
Sufficiently fast: performs well comparing to other languages and has a JIT compiler that noticeably improves performance on many tasks.
Well documented: reference manual, book, wiki, 6-page short reference and more.
Friendly and enthusiastic community.
Clean and simple syntax suitable for beginners and accessible to non-programmers.
Integrated interpreter: just run lua from the command line.
Native support for coroutines to implement iterators and non-preemptive multi-threading.
Incremental garbage collector that has low latency, no additional memory cost, little - implementation complexity, and support for weak tables.
Simple yet powerful debug library.
Free
Cons:
Lua does not focus on 100% backward compatibility. Many newer releases of Lua break programs written in previous versions.
Limited error handling support.
Global scoping by default.
No Unicode support.
Lua supports only a few data structures, including arrays, lists and hash tables.
Limited pattern-matching support.
No POSIX functions built-in..
No class/object finalizers.
Packaging on Windows. It requires a fair amount of experience with Windows application packaging to produce an installer that provides everything your end user needs in a way that makes your use of Lua as the core language irrelevant to them.
Based on:
Lua - Good, Different, Bad and Ugly parts.
Look at Lua
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 9 years ago.
Improve this question
:) When you write a iOS App, in order to use the UI like buttons. you have to write it in Objective-C. (Java on Android). I was wondering if anyone had any thoughts on the technical reasoning behind this. Why they might of done this. As you can write apps in C++ on iOS so I've never fully worked out why they didn't expose a way of making the UI in that. (Ignoring the fact that this is how they did it on the Mac).
Note: I know you can write apps in c++ for Android but the question is more why is the main UI i.e buttons etc forced to be written in a dynamic language for these platforms, why not expose access to it thorough C++ without having to write a crude wrapper or binding layer yourself.
I'm guessing that when the original framework engineers were working on their respective operating systems, cross-platform desires like UI support in a different language like C++ was at the bottom of their concerns. You'll have to realize that when deadlines loom, all of the features are prioritized only what is considered most important is made to work. Everything else is a consequence of that.
In the case of iOS, Objective-C is the language of choice for the OS that Apple uses. All of the MacOS app developers were writing in Objective-C so their developer based was in familiar territory.
In the case of Android, Java was already a popular language, with existing open source tooling and libraries (Eclipse IDE, Apache Harmony), so presumably they decided to use Java as the first class language for app development with apps running in a VM as a consequence. Alternatively the decision may have been VM first for the sandboxing of apps and Java was picked as the language for app developers. Or some other reason.
In either case any attempt to add in additional languages now that both are in the hands of customers means design decisions and trade offs along with a host of other questions like: how to add it in without breaking existing APIs, how to support it along with new features, how to test, etc. etc.
As you see more and more software, you'll realize that lots of stuff is just arbitrary or made sense at the moment of when it was designed.
iOS does expose a C API for drawing UI components; it's called Core Graphics.
Because the view itself is written in Objective-C, or Java, respectively. When in Rome, do as the Romans do.
I recently know that we can use Android NDK (use C++ language) to program. But, I'm afraid that, can we use Android NDK to do most of work in Android ? (because people just say that NDK just helps increasing performance of an android program)
I see that ADT plugin for eclipse is powerful, but It's for java. So, if I want to develop on Android NDK, does it has a plugin same with that.
thanks :)
Java is well-supported on Android: there are books, tutorials, Google results and a lot of similar documentation and resources. Developing with the NDK has less stuff available.
Although you can in principle write your full application in C++ using the NativeActivity, I believe that you will have less resources at your disposal for that, compared to Java. If you really want to make your Java program faster, you should profile it, to find which part needs this performance gain and write only that part in C++ using JNI.
you could, but it is not recommend. For one c++ and java performance for multiple aspects are equivalent, then every jni call has its overhead that you have to take in account. Take a look to this link
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
we made a quit big iOS application with 2000+ objective c classes. I am wondering there is a best practice guide to port it to Android ? Currently I am looking at Visual Paradigm (UML) which reverse engineers objective c files to UML. Like Enterprise Architect it also allows me to generate code(headers + declaration) for another popular language like java or c++. Are there any other approaches yet ? Also, as our app is heavily using the UINavigation and UIView controllers, I am wondering there is similar model and implementation on Android.
Thanks so far, guenter
In all honesty, I think that what you are planing is just going to make for crappy code that will be insanely hard to maintain. I realize it sounds like a lot of work, but its gonna be easier in the long run, I would just "port" the concept of the app to android and write it from the ground up.
The Apportable SDK
It cross-compiles Objective-C applications to Android, without extensive changes to the original codebase. Instead of translating the code to Java, Apportable cross-compiles your code to run directly on the Android device’s processor, bypassing the Java runtime, resulting in speed and performance that rivals the iOS version.
The platform has been tested on Apportable’s library of over 150 devices and in the wild, where Apportable-powered apps have received 5-star reviews on thousands of devices.
check out the sdk here
AFAIK there is no automatic tool to convert Objective-C to Java. There is java2objc that does the reverse.
Here are some official tips for porting Objective-C to Java: http://www.nextcomputers.org/NeXTfiles/Software/WebObjects/Guides/PortingObjectiveCtoJava.pdf
I'm not an iOS expert, but AFAIK iOS does not have layout managers - it uses XIB/NIB to do layout (or dynamically in code, which is not recommended). On Android there are layout classes which are primarily used to support different resolutions. Also, layout is declared via XML files.
So it seems there is a lot of hand-coding in front of you. Since a project is quite large, I'd get a help of an expert that knows both Android and iPhone.
For going from C or C++ to Android you are probably best of using the NDK. The problem is that I don't think this is possible (at least, not directly?) for Objective C.
I think it might be best to try and go to C, and then use the NDK to make it into an app for Android. Going from your code, trough UML to JAVA sounds like a much harder option.
just to let you know how the story did end up, I kept using Sparx Enterprise Architect and have my design, architecture and documentation well under control, for all platforms finally except for JavaScript. Its a bit tedious when integrating new features but in an enterprise environment it saved me a lot of time. We are working on iOS, Desktop(Web2.0/HTML5), Android, Blackberry, Symbian and some router systems. To get rid of platform specific things, I introduced always an additional layer. Seems to work for our products so far.
Thanks to all again, g.
MyAppConverter service helps to convert native iOS mobile apps instantly to native Android app, it's not focused mainly on the look and feel, and UI interaction of your app. That means it don't replicate your application as it is. Instead, MyAppConverter make all changes to make a project suitable for the development of an Android application.
MyAppConverter currently support only iOS to Android conversion and objective-c to swift.