Recently I have to develop on mobile phones using Java and I am planning to do the development on the following brands:
Nokia
Samsung
SonyEricsson
Motorola
LG
I've browsed the "developer site" of each company and looks like they all have provided their own SDKs for J2ME development.
I am really new to this field and I have a few questions:
Since they all support Java platform, why do we need additional Java SDKs?
What can I benefit from the SDKs?
What determines whether I should use the SDKs or not?
It all depends on how complex the application your want to develop will be.
Developing a basic application to run on that many different handsets is doable but complexity will increase exponentially with each advanced feature you add, especially if you want to target existing, old and upcoming devices.
What you also need to consider is that each manufacturer can support several operating systems and platforms.
Nokia has Series40 (3rd and 5th editions), Series60 (2nd, 3rd and 5th editions), Series80.
Samsung has at least 2 major versions of their own platform and the last 2 editions of Series60
SonyEricsson has 3 major versions of their JP8 platform (and JP7 too), Series60 5th edition, UIQ 2.x and UIQ 3.x
Series80, Series60, UIQ 2.x and UIQ 3.x are based on the Symbian operating system. Different versions of Symbian OS have used different JVMs and several companies have contributed JSR implementations.
Motorola has at least 2 major versions of their own platform and a couple UIQ devices
1 - Since they all support Java platform, why do we need additional Java SDKs?
The major problem of J2ME is fragmentation. For a variety of reasons (both good and bad, both technical and commercial), the Java promise of "Write Once, Run Anywhere" is largely considered utterly unfulfilled in the mobile industry.
Many functionalities need to be coded in a platform-specific way if you want the same code to work on many platforms at once.
Many J2ME platforms also add non-standard APIs, properties, configurations, "bugs"...
Most importantly, manufacturer SDKs are supposed to allow things like on-device debugging or MIDlet deployment over USB. They provide basic or extended tools that help on-device testing because that is an area where a generic WTK should typically be lacking.
2 - What can I benefit from the SDKs?
Very probably, yes.
Ok, so, most of them will only run on a Windows desktop computer but the SDKs themselves should be free.
3 - What determines whether I should use the SDKs or not?
Start with the WTK. When you realize you're trying to do something that is specific to the handset manufacturer, get the corresponding SDK.
One example: The WTK PDAPDemo sample application contains a rudimentary filesystem browser. It displays widely different results on different platforms.
As suggested by Pavel Alexeev, DeviceAnywhere is a great tool, assuming you have a proper test budget. Nokia also offers something similar but that is obviously limited to Nokia handsets.
Benefit from vendor-specific SDKs is only if you want to use vendor-specific APIs. In most cases Sun WTK would be enough.
As for testing purposes, I would not suggest to rely on emulators. You better try on-device testing. Nokia and Samsung provide remove device access for recent devices. And you can also try deviceanywhere.
I would do most of my development with the regular old Sun..err...Oracle Java WTK, and then if you need to do some testing, get the emulators/SDK's from those companies. Other than that I'd mostly avoid them though.
Built in camera functionality typically differs between different brands of phone and the API's provided can be very helpful when trying to do anything more advanced than take a simple snapshot. SonyEricsson phones for example will allow you to display a camera feed through a VideoCamera directly to a canvas which is very fast but does not not allow you to control how frequently the feed is drawn to the screen. In order to draw graphics on top of the video feed without excessive flickering you need to add the OVERLAY flag (1<<8) to the VideoCamera's initDisplayMode() call, not all brands support the additional flag.
For .NET guys - there is a Ubiq Mobile framework. Ubiq Mobile apps work on Android, iOS, Windows Phone and Java-based phones and tablets. This is rapid cross-platform development with .NET with cloud-based architecture. Getting started article: How to create simple UbiqMobile application with video.
My opinion is "QuickRecipesOnSymbianOS" is correct. It is very easy, simple and technical answer.
Related
I am writing an Android app which needs to be run on BlackBerry Z10, too. Someone mentioned that Android apps can be wrapped for BB. However I am not sure of the version. If I use 4.x specific features, e.g. swipeable tabs, will they be supported on BB, or should I use some older API, e.g. Eclair (2.1) to be on the safe side?
I just want to program once, and not twice.
Today, you should build your Android apps to OS version 2.3.3 (API level 10). So, you should produce a version of your app that doesn't use features in newer API levels.
Here is the official BlackBerry page that mentions this:
You can use the BlackBerry Runtime for Android apps to run Android
2.3.3 platform applications on the BlackBerry Tablet OS and BlackBerry 10. To use the runtime, you must first repackage your Android applications to BAR file format, which is the compatible file format
required for an application to run on the BlackBerry Tablet OS and
BlackBerry 10.
Update: it appears that BlackBerry has a status page here, detailing their roadmap for Jelly Bean support. Of course, every device won't support it the day it comes out, and BlackBerry has missed deadlines before. But, it's probably good to keep all those things in mind when planning your project.
The right decision for you will depend on how long you expect your development to take (2 weeks, 3 months?), how important the features are that depend on 4.x APIs, how much you're willing to assume BlackBerry meets their schedule, and how important a strong launch is to you. If only a small number of devices are actually upgraded to support Jelly Bean when you release, it may hurt your sales.
Anyway, the point is that it depends on a lot of factors. Hopefully, I've described most of the important ones.
I would suggest 4.2. This is because in June, next month, the platform will be updated to support 4.2 from 2.3.3. By the time you get round to publishing you shall be all set.
Question: When can I say cross platform tools can handle this type of development..?
Below are NOT questions to answer. These are just guides why I raise the question to avoid too long description.
For game development :
Are tools (i.e phoneGap, widgetPad etc...) alike (given these terms...openGL, xna, 2d, 3d and others..) sufficient enough for game development?
For Applications development :
Like in native android, can the cross platform tools would still be able to do the same as native java does? i.e. Accessing notifications, contacts etc..
I would say at the current time, it is not ready for 1 and will really not be anytime soon (without undo trouble to the developer that in the end is a setback).
As for 2, it can and is ready for your question immediately. Sure, you have to still call the native Java or Obj-C for some truly native features, but this can all be done from within the Javascript/HTML interacting into the Java domain. This, they call plugins, and albeit a nightmare to upgrade at some times(pre 1.9.0, but anything developed after 2.0.0 won't have those issues to deal with (mostly))
Check out ADF Mobile just released on Monday (Oct 22, 2012) for business software. It provides Android and iOS solution and it is Java based. The info can be found here:
http://www.oracle.com/technetwork/developer-tools/adf/overview/adf-mobile-096323.html
With the platform and device diversity reining the mobile landscape, cross-platform app development has emerged as a commercially viable option. Here are the the Top 10 Cross Platform Mobile App Development Tools
https://www.rootinfosol.com/top-10-cross-platform-mobile-app-development-tools
Android class libraries are written in C/C++ but java is the preferred language for developing applications.Why not C/C++ instead of java ?
If you prefer to develop via C/C++ you may use the NDK. The Android platform is run on the Dalvik Virtual Machine, what you code in java is actually compiled to Dalvik bytecode and run on the VM.
They spent a lot of time developing the facilities to make it fairly painless to make an Android application using a managed language. Some people would consider this an advantage.
There are many reasons to choose Java as the platform, but my guess as to the biggest reason why would be to not expose application developers to a slew of porting issues that arise from the sheer number of devices that Android powers. There would be far fewer apps available if every developer had to research every platform nuance for every phone and tablet out there.
Obviously, there are drawbacks, and that's why the Native Development Kit (NDK) exists. The NDK primarily addresses performance issues, but recent additions have included the ability to write an entire app completely in native code.
Java it's used in many application for mobile devices, it is a standard because it is more manageble, even the new languages that are appearing now it's based in java. It is a open language and you can learn it without going to class. Javame is used for mobile devices which incorporates some features of J2EE and adds new classes for the small devices.
Apple's guidelines for their new Mac App Store say that you cannot use deprecated libraries such as Apple's Java framework. But will Apple allow apps which come with a third-party Java runtime, such as SoyLatte?
Yes, provided everything needed to run your app is part of the app bundle and your UI looks and behaves completely natively. You are barred from relying on users to have already installed optional or deprecated technologies (libraries, runtimes, or what have you).
Specifically, the rules most likely to be relevant state (PDF):
2. Functionality
2.22 Apps must contain all language support in a single app bundle (single binary multiple language)
2.24 Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
6. User Interface
6.3 Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple Macintosh Human Interface Guidelines will be rejected
6.5 Apps that change the native user interface elements or behaviors of Mac OS X will be rejected
Taken together, the two functionality rules quoted seem to indicate that you are free to use a third-party Java runtime provided everything needed to run your app is contained in your app bundle.
The user interface rules would bar any but the most flawless emulations of all the native UI widgets. Realistically, you would need some way to use native UI widgets from your Java application. Eclipse's Standard Widget Toolkit might meet the UI requirements, for example.
It seems ALL java apps will be banned:
http://www.theregister.co.uk/2010/10/21/apple_threatens_to_kill_java_on_the_mac/
No, they will not.
Consider these rules:
2.5 Apps that use non-public APIs will be rejected
2.7 Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them
2.15 Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
2.20 Apps that present a license screen at launch will be rejected
2.21 Apps may not use update mechanisms outside of the App Store
2.24 Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
5.5 Use of protected 3rd party material (trademarks, copyrights, trade secrets, otherwise proprietary content) requires a documented rights check which must be provided upon request
6.1 Apps must comply with all terms and conditions explained in the Apple Macintosh Human
Interface Guidelines
6.3 Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple Macintosh Human Interface Guidelines will be rejected
Using private or "deprecated" technologies are forbidden by the rules (2.5, 2.24) as well as code which depends on things not installed by default on Mac OS X (2.15).
2.15 would force you to bundle the whole JRE with your app. But that would violate (2.5) because the JRE will use non-public APIs to integrate with the Apple Look-and-Feel and probably 2.20 too.
Without that integration you would be in breach of 6.1 and 6.3.
Additionally that would make it your job to update the app every time Java gets a security update, because Oracle's updater for Java won't be allowed to work (2.21).
Eventually getting some letter from Oracle's lawyers (required by 5.5) might take some months, so you will be very late to the market and your app might be rejected by rule 2.7.
This has nothing to do with technology. It's a political decision just like what happened with Flash and if people try to sneak around it Apple just won't approve it. They have tons of rules on which they can base their rejection of your app.
Basically Apple doesn't want developers to write cross-platform applications and pushes them to develop Apple-"exclusive" applications in a language Apple controls.
I am developing mobile apps for some time in .NET and I was always wondering if the grass is greener on the other side (Java).
Thus, I would like to ask your opinion about which one you prefer for your mobile apps and why is that so.
The main advantage of using Java is the broader installed base. If you use Java, you are going to reach orders of magnitude more phones than if you use .NET.
As far as I know, .NET works exclusively with Windows Mobile phones.
On the other hand, Mobile .NET is easier than Java (IMHO), and that's partly because of Visual Studio IDE which makes life so much simpler than any other development environment on the Java World. For example, doing Form Based applications in .NET mobile is really straightforward and simple.
So, the answer will basically depend on what you are trying to accomplish:
Trying to reach to the biggest number of mobile devices: go with Java
Trying to develop an application for Windows Mobile devices: go with .NET
Trying to develop an application that will run only on a controlled environment (A single business) where you get to decide the devices it will run on: decide which device you are going to use and then pick development environment.
Keep in mind that if you are talking about Java for Android or Blackberry development, you will face the same issue of not reaching to a huge installed base that you will with .NET. If you want the huge installed base, go with plain Java Mobile Edition.
I can only speak for windows mobile development stay with .net.
Sun don't even release a JVM for windows mobile devices I have developed for windows devices using java and using http://www2s.biglobe.ne.jp/~dat/java/project/jvm/index_en.html as my JVM which was very good the author even responded to a feature request I made.
It is true that if you're going to develop for WindowsMobile, J2ME is not a very good option. More than likely your device of choice will not come with a JVM and if it does, it'll be buggy and slow. Also, forget about trying to integrate with with OS at more than a basic level.
Just to add to what others have said, Sun has made phoneME available and if you want to go that route and deploy your MIDlet and VM together that is certainly a possibility. It's just a lot of work at this point.
For .NET guys - there is a Ubiq Mobile framework. Ubiq Mobile apps work on Android, iOS, Windows Phone and Java-based phones and tablets. This is rapid cross-platform development with .NET with cloud-based architecture. Getting started article: How to create simple UbiqMobile application with video.