I need some operations that are to be performed on large long[]s to be very fast. The only option I can see is to use the Android NDK. Can anyone give a summary on what using the NDK does to my app in terms of which devices can use the app and what the implications are to maintaining my app?
I saw that you need to specify which architecture you want to compile your C code for, like ARM and Intel. What happens when new architectures for Android appear? Will I have to update my app every time a new architecture appears?
Can anyone give a summary on what using the NDK does to my app in terms of which devices can use the app
Only devices running on a CPU for which you have an NDK .so will be able to run your app.
and what the implications are to maintaining my app?
Testing on multiple CPU architectures may require hardware for each architecture. I say "may" because...
What happens when new architectures for Android appear?
...we really have no idea. Other than adding ARM7 support, the NDK has not changed its targets.
Right now, there are two major non-ARM platforms for Android that I can think of:
Intel Atom, being used by Google TV devices. At the time of this writing, the NDK does not support this. However, you can't ship apps for Google TV yet, either. So, it may be that the NDK will be updated by the time we get to write Google TV apps.
MIPS. At the time of this writing, the NDK does not support this. I have no idea what the plans might be in this area.
It is conceivable that emulators will appear to emulate those CPUs. After all, the existing Android emulator emulates ARM5. However, unless and until this happens, you will need test hardware for every architecture you intend to support.
Will I have to update my app every time a new architecture appears?
Only if you want to support the new architecture. Until there is a critical mass of devices for it that can access your app, any new architecture is not going to be terribly important. "Critical mass" could be from general device sales, or it could be because you strike an OEM deal to have your app bundled on somebody's device.
The code is simple though and will work on all archs.
Watch your endian-ness.
Related
The reason why most people would ever make their android project in javafx would be to have the same codebase across different platforms (such as ios, desktop, android, maybe even web using Bck2Brwsr/teavm/doppio)
But my question is, is there any advantage in javafx ui framework itself when compared to android ui framework?
I have never ever written even a hello world application for android, but I intend to do it now. So I am wondering if having the code in javafx is worth the effort when I can develop directly on android apart from the benifit of portability.
This type of question might result in a subjective/opinionated answer but I think it is a good question so I will provide my assessment.
Having the same codebase across all those platforms is huge. Do not dismiss this. I'm using Gluon Mobile to port aspects of the Deep Space Trajectory Explorer (DSTE) to Android and iOS. As you can see from the video its extremely complex application. There's no way I would rewrite that in native Android... it would be a no-go from a cost perspective.
Starting development from JavaFX makes it easier to make complex visuals. I don't just mean traditional 2D GUI forms. Again looking at the DSTE you will see we use Canvas to do dense renderings and JavaFX 3D along with the FXyz library to do 3D renders. These things are easy in JavaFX and again using Gluon simply "just work" on Android/iOS. In fact it only took about a day to get those aspects of the DSTE code base to work on a Pixel C tablet, most of which was getting the Gradle build setup properly. Now imagine having to port 3D code from JavaFX to a Native framework? I'm a 3D guy and I still wouldn't try it.
Testing is so much easier on the desktop than a mobile device. This doesn't mean the testing is 100% on desktop. Sometimes something that works on desktop "doesn't work" on the mobile platform and you have to tweak accordingly. However you can save a LOT of time standing up the application using JavaFX knowing that 90% of it will work the same on your mobile device.
Word of advice though... remember that a desktop application is NOT a mobile application. You will be tempted to just "port" your desktop app to your device. I was my first time. You can get into other issues where the interfaces and layouts you design for a desktop "work" on the mobile device but are not appropriate and so the usability goes down. Start slow when you port. Think of what aspects of your desktop workflow should be mobilized. Only port the things you absolutely belong in a mobile workflow. Save yourself some headaches.
Today I was speaking with PM. He said that the best way to solve problem "The same app working on iOS and Android" is to write object-c code for iOS and then use the same code in Android app (https://developer.android.com/tools/sdk/ndk/index.html). That approach (in his opinion) will give us DRY effect (have one code to maintain).
I was so shocked that I almost didn't say anything to it. But after some time I think about it and found some problems:
C++ != Object-C. It is possible to add o-c code as c++ code in Android?
(Let say that #1 is possible) How can I do layouts, activities, ect. in c++ for Android?
Also when we should / should not use Android NDK?
The short answer is no it's not possible. However http://www.apportable.com
Claims to enable you to compile your iOS app for Android - thus enabling you to use all of the code in your iPhone app.
However it doesn't work with everyframe work but does have hooks in to the Android SDK so you can still access those components. Worth looking at, and having a play with. I have but only half-heartly and you'd have to build the iOS app from the outset with the plan to use http://www.apportable.com as like I said it doesn't currently support all ios sdks and you'd need to work around that.
But that should answer your question.
As of 2016 app portable is no longer an option more info it appears Google killed the dream.
Objective C code will not compile with the NDK. But check out http://www.apportable.com/ it's a library that allows you to write code for Android in Objective-C. That could be what your boss was talking about.
C++ < Objective-c. Objective-c is built on top of a C compiler ... Just name the files with *.mm and write c/c++ code. Basically what you could do is write functions that you want to share across platforms in c++ and use them in an Android project via JNI wrappers.
You can not share code which uses ios system Frameworks (UIKit, CFNetwork, ...) directly.
If you want to write code for whole apps once, you could give it a shot with apportable.com, like others have pointed out.
You can use the GNUstep Android toolchain to use model code based on Foundation and CoreFoundation in an Android app, and then write a new UI layer that interacts with the Objective C model via native NDK calls on top of that (e.g. in Android Studio).
I heard that we can use Adobe Flash Builder to develop apps for android. But I have a doubt, can we create any type of application? are there any limitations to adobe flash applications?
I know flash is good for games and internet applications.
I am confused, which is better for android app creation? Java or Flash?
Advantages of using Flash:
One code base, many (iOS, Android, Blackberry) platforms
Easy navigation between view (as iOS does not have a hardware back button)
Good for apps which serve as a front end for RESTful web services
Supports gestures, camera, vibration, contacts
Disadvantages of using Flash
Performance takes a hit when you try to do image processing and other heavy stuff
Cannot access front camera
Doesn't give you as much control as Java
Advantages of using Java
Can exploit Android OS to its fullest
Performance is better in case of complex apps
Disadvantages of using Java
Cannot use the code-base to target other platforms
IMHO, it depends on the use-case of your app.
Major disadvantage: Adobe has announced that they will stop
developing/supporting Flash on Android
It'll be a long time before desktop will follow, considering that most users are IE users (Google analytics supported) and remember that IE9 still has VERY limited support for HTML5 where as Flash has 99% global cover on PCs.
So until such time as all browsers have much more HTML5 support, Flash will still be here for a while - whether it's here for good, perhaps not - but Adobe are already creating their new Flash Development tool to output HTML5 as well as SWF files. But like all file types, they will eventually have their day - but it's not yet that time.
java with android sdk is 100% and Flash with adobe air is 70%(approx).becase adobe provide same functionality like android sdk useing "Native code" but some functionality that cant allow by flash.
another thin is that version problem.you can continue with 2.2 or higher.
some Broadcasting functionality are not there
Advantage::
flash game building are easy and just 2 to 3 step to convert it into apk or iphone formate.
Major disadvantage: Adobe has announced that they will stop developing/supporting Flash on Android. Desktop flash will soon follow. So if you are starting a new project, unless its expected lifetime is fairly short, forget about Flash.
I am developing a Java ME application which uses the camera to take a snapshot and then decodes it (using ZXing library). The target is Nokia phones.
I need to use the focus to have a clear image, if not, it is difficult to decode the image.
Since the Series 40, the control "videocontrol" and "SnapShopControl" are available. I thought that for the "FocusControl" it was the same, but it isn't.
I discovered that it is almost non-existent, not only for the Series 40 (only some phones), but (more surprisingly) for the Series 60 and Symbian 3.
You can see that in Java ME API support on Nokia devices.
These mobile phones support JSR-234 but for audio and music, not for camera.
As you can imagine, this is very deceiving, Nokia is not doing their work well.
Did you find any solution? Perhaps another "made-by-hand" control? I am afraid I have to start programming in C++ because I haven't got much time.
The solution has been to use Nokia's APIBridge (an extensible mechanism to access device features in WRT, Flash Lite, and Java applications). You can access the software is installed in the phone for the camera and if it is able to use the autofocus, you can use it, and it returns the image you take.
See Tool details for APIBridge for further details.
The implementation is easy (you install the SIS file for the APIBridge in the device, and you can package your application and this SIS file together).
You use the following code:
APIBridge bridge = APIBridge.getInstance();
bridge.Initialize(midlet);
NewFileService service = (NewFileService) bridge.createService("service.newfileservice");
Hashtable filter = new Hashtable();
filter.put("NewFileType", "Image");
BridgeResult res= service.TakePhoto(filter);
Many phones' hardware just don't support focus. Some Sony Ericsson phones (e.g. G502) support FocusControl, but they don't allow to do anything because the hardware does not support it.
I'm afraid to say that you can do probably nothing with this problem in Java ME.
If the phones support focus control, but it is not availble in Java ME, there are probably two ways how to solve it:
Let user to use the builtin camera and load it (preferably the last photo) from Camera album.
Try to use camera focus from a S60 API.
Note that I'm not a S60 developer.
i want to program a simple java game, what should i consider to make it maximal portable? i'm pretty new to java, which grafik and rendering libraries should i use to make it easyly portable to mobile java (for mobile phones)?
i can't develop it directly for mobile java, because i also need a pc version.
or should i jast develop strait forward for pc and do a completele new mobile version later?
I'd say do the PC version first (portable across Mac, Linux, Windows if that is a priority for you), and develop a (or even several) completely new version for mobile handsets.
There may be some code (and art work) that you can re-use, but not too much, as a (good) game will have to be very different for a mobile phone than for a PC, not just screen sizes and input methods, but the major changes in game play that those differences probably result in to make it still fun to play.
The code that you can reuse will likely need to be adapted for J2ME or Android, but better to worry about that later than trying to be overly cross-platform from the beginning (which would place limitations on functionality on the PC version, and eat up a lot of time, without being sure if it ever pays off).
Again, if anything, worry about portability within the several desktop environments, and within several handsets, but not too much about portability between the two.
Of course, if your game has a server-side component, it would be ideal to have only one version of the server code that can talk to clients on all platforms.
I think it's feasible to create a game that is portable across a wide range of platforms. While a desktop version of a J2ME game may look primitive, it does enable your users to preview the game before installing it. Check out my project JGame, which enables writing a game that works without changes on J2ME, Android, and PC. I believe the Slick project also has a working Android version.