Is there any reliable way to support back-light in J2ME on multitude of models, other then pre-processing?
Is there any library available that may handle the back-light for various phones out there?
Regards.
This is not a direct control as in Nokia UI API, but there is a method in MIDP that controls backlight, it is Display.flashBacklight(int duration). Unfortunately, phones are not obliged to obey this method. But this method is at least part of MIDP, not some proprietary API.
Native backlight management on phones ranges from the completely natural to the obviously insane.
It's also nowhere in the MIDP specifications.
The Nokia UI API allows to work around some issues and is actually present on non-Nokia phones.
Related
I'm developing an application that needs to synchronize the time on a server with the time on the device.
Blackberry devices have the net.rim.device.api.system.Device.setDateTime(long dateTimeMillis) method for this. I'm looking for something similar in Java ME devices.
I can live with manufacturer specific APIs - specialy nokia, sony ericsson and motorola ones, and most JSRs.
Does anyone know if there is any way to do this?
Most manufacturers, such as Nokia, don't have that functionality in Java. You may need to take a look into Symbian C++ and other platform specific development tools.
You can't do with Java-me for some security reasons. So you can't change the internal time of system. You can possible to get the current time only.
I have very easy question, but I simply have any idea of the answer.
I have developed a small mobile-application using java, for my nokia.
The problem is that when installed on my samsung the application simply crashed.
Then I tried on my other nokia but different model, and I didn't got the normal behavior.
So my question is, does anyone have any idea how companies that develop mobiles applications/games test their software.
Does they have to have all models for all mobiles phones??
Companies that target many phones in many countries usually only let you install the application on your phone if they recognise your handset User Agent in the HTTP headers of the request to download the .jad or .jar file.
There are multiple ways to test an application on many handsets for many mobile network operators.
From simply buying the phones, to establishing commercial parternships with handset manufacturers and mobile network operators, to having a Device Anywhere account.
I don't know if you need all models of all phones. But you will definitely need separate test (and probably different builds) for different phones regarding:
MIDP version
Screen Size
Input Devices
Speed & Memory
Java, in this case is, WOTA (Write Once Test Anywhere) instead of WORA (Write Once Run Anywhere). :-)
Phone specs and Java implementations vary a lot, but within each manufacturers range there will be groups of phones that share the same specs and implementation.
I used to work at a company making J2ME games, what we did there was test on every handset we released the game on, but we had 2 types of test - Complete and Compatability.
We would adapt a version of the game for a specific phone, eg Sony Erricson K800i, and have it thoroughly tested according to the Complete Test spec.
Once that had passed, we then used that build on phone known to have similar specs and good previous compatability with other games (we kept a database of specs and compatability records), eg Sony Erricson W910i, and submit it for a compatability test, which was a bit less thorough and a bit quicker.
Once you've been doing it a while you get to know the capabilities of phones and which phones you could use the same build on, but there is often a bit of guesswork involved :) Sometimes you get matches you wouldn't expect, and sometimes a match you would expect to work doesn't.
Edit: I was going to post this as a comment, but I can't (because i'm an SO noob :), out of interest, what phones are your Nokia's and Samsung?
I can't remember many specific handset names, but here is a quick rundown of compatability across manufacturers:
Sony Erricsons are generally excellent - if it works on one, it will likely work on all SE handsets with the same resolution.
Nokia's are generally good within a certain smaller group eg N95 builds work well on most nokias with the same res that were released after the N95, but some handsets are a bit of a pain.
Samsungs are pretty bad - the J2ME implementation on most is flawed (Hide/Show Notify methods not being called is an example), and the memory and speed are typicly a bit crap.
Motorola phones are not great, but are generally quite compatable with oneanother. Same goes for LG, although their more recent models are much better.
Testing is one of the most labour intensive part of mobile phone development. Typically a company might simply buy a lot of different phones to test on for real, or target a particular subset such only as Series 40 Nokia phones.
But alternatives exist out there where you can remotely deploy your app to phones, such as Nokia's Remote Device Access Services.
One way that might limit the problems is to target J2ME MSA (Mobile Service Architecture) compliant phones, where MSA attempts to reduce variations in vendor implementations of J2ME.
I've been tasked with using WURFUL to determine whether or not a mobile browser is capable of downloading a J2ME app developed by my company.
I first thought I could use the "device_os" tag and filter by that, however, I'm unsure what the complete list of J2ME OS's are... any ideas?
I've been told there are no MIDP requirements, and that the application will run on any J2ME-supported handset (with two specific resolutions, which I already know how to query)
Thanks in advance.
There is no way to know all the OSes that support J2ME. Mainly because most feature handset comes with a proprietary OS which probably you have never seen before. It is a better idea try to identify the handset model and decide if it supports J2ME or not.
Another thing is, you may want to know which JSRs are supported by a specific handset. I do not know your application but probably you are using some optional JSRs that are not supported by some handsets although they have basic J2ME support.
Java ME SDK 3.0 includes a database of supported devices. Also there are other web sites that provides these kind of information. One example to those would be this J2ME Handsets web site.
If you are fine with just covering a large range of phones, you should include Symbian S60, S40, Windows Mobile, Blackberry and Android.
Symbian
Win Mob
Android
Almost every Sonyericsson phones
IMHO you don't have to worry about how many handsets support j2me because majority of the phones support it.
At least Symbian and Android.
I'm trying to register a midlet for push registration, in order to wake up from a bluetooth connection.
The requested behavior is that the application will wake up when a car's kit (hands free) will be in the range of the device.
Is it possible at all?
If yes, how should it be done?
Thanks in advance,
I can confirm that it is possible to wakeup a MIDlet in Nokia Devices trough a registered service in the push-registry.
The registration can be defined in the JAD (static registration) or dynamically in the code.
Nokia phones S60 3ed and up and S40 3ed should support this functionality, on other phones (sony,samsung,motorola etc..) I didn't find this feature working.
Google this JAD attribute: MIDlet-Push-1
Good luck!
I don't think it's possible to start up a midlet when it comes into range of a device, even with Bluetooth push registry compatibility (were you to find a handset supporting it).
Your best bet might be to have a midlet running in the background, constantly checking which devices are in the vicinity. When it discovers your hands-free kit, you could bring it to the foreground (if the handset supports it; this is usually achieved by Display.setCurrent(null) for background, and Display.setCurrent(<Displayable instance>) for foreground).
JSR 82 provides the functionality you need.
Beware though, this constant Bluetooth polling will drain the device's battery!
This is advanced stuff. Nice.
While this can be available on mobile phones according to the JSR-118 and JSR-82 specifications, I suspect not many handset manufacturers have actually implemented it.
Symbian provided a TCK-compliant reference implementation for Java BlueTooth Push to its licensees but testing it is a nightmare and I don't know whether either Nokia, Motorola or Sony-Ericsson actually included the functionality in a phone.
My best guess of Symbian phones to try this on: Nokia N95, Sony-Ericsson P990 or W960, Motorola Z8. I would also advise trying on as recent a Bluetooth-enabled non Symbian Sony-Ericsson phone as you can find.
If you find a handset specification that actually says it supports J2ME BT Push, you then need to check whether that is supposed to work using RFComm, L2CAP or both. I don't know what your car kit uses.
As far as writing Java code to use Bt push, you can start by reading the example code in the 2 JSRs and the J2ME SDK from Sun Ltd.
Recently I started developing a J2ME app prototype. I noticed how difficult it is to develop a good looking UI. Consider developing an app in J2ME for booking flights interacting with webservice.
A website to book flights will be easy to develop with nice ui and can be accessed by browser on a handset. I understand not all handsets have browser but all the new and upcoming ones have browser and have big screen as well.
Is it a good idea to develop such a application in j2me which need to talk to webservice for it to work? Or j2me is only suitable for standalone apps?
Advantages of J2ME:
Can access phone resources, like file system, phone book and GPS. The last is very important in map applications.
You can build richer User Interfaces. It may be difficult as you say, but there are many GUI libraries that could assist you. On the contrary the UI for a mobile browser (you can't rely on CSS and javascript working) would be very poor.
Greater flexibility on the communication logic. You can encrypt/decrypt data, compress them, use SOAP web services. With the browser, your best bet would be to develop REST services.
Disadvantages of J2ME:
Midlets need to be signed. This has some cost and there are situations that even a signed app won't run properly in specific phones.
Developing a midlet to run in all types of phones is a nightmare. On the contrary, a well designed mobile web application would be displayed properly in all recent phones.
You need to have a channel for distributing your application. People would need to download it and get charged for the required bandwidth. You would need to care for angry customers having problems with the application. Things are easier with a web site.
J2ME apps are inevitably compared with native applications (iPhone, Windows Mobile, Symbian). Compared to these, they are very poor and many would find that paying for them or even using them isn't justified.
My conclusion: Nowadays real smart phones are becoming more popular and win an ever growing market share. Under these circumstances, the advantages of J2ME can't really overcome its restrictions. The only exception I could think of, is if to have to develop a GPS application. For all other cases, a mobile web site is a better idea.
There are a lot of misunderstanding and plain wrong statements in the previous answers.
I advice you to just do your research yourself. Nowadays you CAN develop really good looking apps with J2ME without writing your own GUI framework. Take a look at LWUIT really. For example they have a virtual keyboard as one of their touch screen functionalities and this you have on devices like the N97 which itself does not have a Virtual keyboard. BTW using LWUIT you have a Blackberry and Android port included if anyone cares.
Also Apps nowadays become the center stage on many platforms not just the iPhone. Look at the recent developments in this area like OVI, RIM, Samsung, SE, Orange World they all start with app shops.
"Getting people to use a website on their mobile phone is easier than getting them to download an application." this is just a claim without proof. you cannot say that like this. It depends on a lot of other factors. - Why should users type in your mobile url into the rather small screen again?
Anyway, this answer is probably too late so I'm not gonna write much more. The mobile industry is changing fast right now but there is not yet a alternative to J2ME for crossplatform development. Maybe in the future with better browsers and widget technolgies.
Just a short note, applications like google maps or gmail mobile probably don't use WebServices to talk to their server part. A WebService has a lot of overhead, especially when considering that mobile users are usually rated by the amount of data they transmit. The best way to perform communication between your client app and its server part is to use binary data over a socket connection.
I personally think it's really hard to make a consistent and reliable J2ME application that will run across a large set of mobile phones. Based on my experience, I would only develop a J2ME application (instead of a Web application) if it's a strict requirement - for example, to be able to view your bookings without being connected to the network. There are other costs associated with J2ME applications - the applications must be downloaded, the user will be asked if the application is allowed to connect to the network when it attempts to (there are exceptions for this case but I believe the application has to be signed by 3rd party company - more $$$ involved), you will have to maintain different versions of the application running on a variety of mobile phones (more complexity to the application), and so on...
Think about it this way - if you were developing a similar thing for a computer, would you build a desktop application or a web application? With the cellphones of today (many of which can access full-html sites with javascript - which means ajax), the proposition of the question is valid.
I thing a good rule of thumb should be: If what you're trying to achieve can be done with a mobile website - go for the website.
IMHO, apps should only be used to if they cant take advantage of the mobile hardware - like location, sound, video, 3d, pictures etc...
Even if the dev costs for the app were insignificant (they usually aren't), you'd have to offer some really amazing capabilities to make the users go through the trouble of downloading it.
(All of this is essentially true for J2ME/BREW. The iPhone is a little different as apps take the center stage)
One thing worth highlighting: the only standard way of deploying a MIDlet is via OTA download so you wouldn't expect a J2ME-capable phone to not have a web browser.
Mobile web browser like Webkit and Opera are getting better faster than J2ME (at least until MIDP3.0 starts shipping, if ever).
No matter which platform you choose, you will need to test your service on many devices. I don't think switching from J2ME to webapp makes a huge difference in that regard, because phone manufacturers keep changing the binaries that go into the phones firmwares.
Getting people to use a website on their mobile phone is easier than getting them to download an application. unless that application is already installed when they buy the phone, that is.
You might want to look at LWUIT for better and easier J2ME GUI.
One thing that J2ME will accomplish for a flight booking service is save battery life by not requiring constant network data transfer, thanks to the local storage mechanisms.
there are many great j2me apps that (need to) talk to webservices. just think of the google apps, like gmail mobile and maps for mobile. they are faster and easier to use than using the services via cell phone browser. so if you can design a good app, it's definitely worth it.
EDIT: also, a j2me app makes possible features that can't be provided by a web application: integration with phone features (address book, calendar), "call this number", location api, etc.
I think for business apps, or more text/data oriented things, a mobile web/wap site might be easier to maintain, since you won't have to deal with pushing client updates out to handsets.
For UI-intensive apps (maps, games, etc.), client apps are probably the way to go, so you can handle the more of the processing and rendering on the client side.
Both options are difficult though, since there are so many compatibility issues with phones. You might be best served by narrowing down what types of phones you want to support for your app. If you think most of your customers will be iPhone or Android phones, you can target those platforms (with either client apps or web apps) and avoid old-school j2me completely.
I hate WebApps on phones. They are slow and they don't work in a semi-connected environment.
J2ME apps can do local backups, bluetooth backups, bluetooth data sharing between 2 phones and better responsive UI. However that requires money,skill,time etc.
My main gripes with MIDP though is pushing software updates and wav real time mixing. Technically those are possible within the scope of MIDP but the goons at wheel are not very creative.