What else can squeeze out of J2ME?
Recently, all the attention of developers and journalists focused on smartphones and interest in ordinary phones completely disappeared.
However, the share of sales of ordinary handsets (where it is possible to run only J2ME applications) is very high. You can see the statistics from the report of the agency Gartner over the past year - more than 400 million handsets were sold, of which only 80 million smartphones. By simple calculations we get the following picture:
As you can see, smartphones sold 4 times less than the usual cheap handsets. And only inside these 19 percent, iOS fights Android for first place.
It is clear why to make applications for owners of nesmartphones (because there are a lot of them), but what programs can you do for cheap handsets? First of all, you need to take into account the inconvenient keyboard, lack of touchscreen and a small screen. Probably it should be applications where you can quickly select something from the menu and not waste time on complex navigation. For example, the J2ME version of the GMail mail client is convenient, but it is almost impossible to use it for writing letters.
')
Why make applications on J2ME if you can make a mobile version of the site? Applications have several advantages over websites:
- mobile Internet is soooooooo slow, if the application has more than 10 pages, then users will probably never go beyond the tenth
- in applications, you can organize feedback through sending SMS (which is very convenient because SMS is automatically tied to the subscriber number and its virtual account with the provider)
A good example of such applications is the Alfa Bank mobile client :
in it you can perform standard operations for the transfer of money and checking the balance.
Most of the restrictions associated with the requirement to work on any, even very weak devices. For example, the phone can easily play full-length movies from a memory card but refuses to launch a J2ME application larger than 500kb in size. It is impossible to overcome the limitations without losing compatibility with the whole variety of models produced. But they can be circumvented. It is necessary to change the very ideology of the application:
- use only standard GUI elements. It will not look very nice and different on different models, but it will work everywhere and always.
- instead of loading data from an external source, store it in the .jar file itself. A typical MIDP implementation simply does not have memory access functions, and the resource compressed into .jar is perfectly readable by the standard this.getClass (). GetResourceAsStream (name) .
- instead of updating the application data, make a new version with new data. Usually the handsets already have a built-in function in the menu for downloading new versions of applications, in the .jad descriptor it is enough to increase the counter in the MIDlet-Version field.
- for each user you need to make a personal application with its own data. A midlet is a simple zip-archive, it is enough to place new data in it without recompiling the code itself (of course, you also need to change the size in the MIDlet-Jar-Size field of the .jad-descriptor).
An example of a service using the described principles can be found on the MRF page. You can enter your data in the web form:
and get something like this app:
You can test examples of ready midlets from the gallery - even the oldest pipes easily open directories for 5-10 thousand lines (for example, the English-Russian dictionary or the schedule of suburban electric trains). Ready midlets are no different from those received in the usual way and can be placed, say, in a Nokia store .
In interactive applications such as the client software of the bank or the pizza ordering catalog, feedback is needed with the application. In the application, you can insert buttons to send SMS with the product code and these messages must somehow be taken.
There are several solutions for receiving SMS.
Solution “on the knee” - you can buy a GPRS modem from MTS or Beeline. If you dig into the modem software, it turns out that all SMS messages sent to the modem number are stored in the usual MS Access database:
In the case of an MTS modem, the base file is C: \ Program Files \ Connect Manager \ db.dat. You can connect to the database (say, through ODBC) directly while the modem is running, it is checked.
A more serious decision is to buy an SMS service from a cellular provider, for example, Beeline, the description of such services looks like this . In addition, you can immediately work through the aggregator (for example AvisoSMS ). This will allow organizing sales of services / goods through midlets without concluding separate agreements with each mobile operator.
Perhaps in some years non-smartphones will no longer be produced, but so far ordinary handsets are sold many times more than iPhones. And for them it is possible and necessary to make applications.
However, the share of sales of ordinary handsets (where it is possible to run only J2ME applications) is very high. You can see the statistics from the report of the agency Gartner over the past year - more than 400 million handsets were sold, of which only 80 million smartphones. By simple calculations we get the following picture:
As you can see, smartphones sold 4 times less than the usual cheap handsets. And only inside these 19 percent, iOS fights Android for first place.
It is clear why to make applications for owners of nesmartphones (because there are a lot of them), but what programs can you do for cheap handsets? First of all, you need to take into account the inconvenient keyboard, lack of touchscreen and a small screen. Probably it should be applications where you can quickly select something from the menu and not waste time on complex navigation. For example, the J2ME version of the GMail mail client is convenient, but it is almost impossible to use it for writing letters.
')
Why make applications on J2ME if you can make a mobile version of the site? Applications have several advantages over websites:
- mobile Internet is soooooooo slow, if the application has more than 10 pages, then users will probably never go beyond the tenth
- in applications, you can organize feedback through sending SMS (which is very convenient because SMS is automatically tied to the subscriber number and its virtual account with the provider)
A good example of such applications is the Alfa Bank mobile client :
in it you can perform standard operations for the transfer of money and checking the balance.
J2ME platform restrictions bypass
Most of the restrictions associated with the requirement to work on any, even very weak devices. For example, the phone can easily play full-length movies from a memory card but refuses to launch a J2ME application larger than 500kb in size. It is impossible to overcome the limitations without losing compatibility with the whole variety of models produced. But they can be circumvented. It is necessary to change the very ideology of the application:
- use only standard GUI elements. It will not look very nice and different on different models, but it will work everywhere and always.
- instead of loading data from an external source, store it in the .jar file itself. A typical MIDP implementation simply does not have memory access functions, and the resource compressed into .jar is perfectly readable by the standard this.getClass (). GetResourceAsStream (name) .
- instead of updating the application data, make a new version with new data. Usually the handsets already have a built-in function in the menu for downloading new versions of applications, in the .jad descriptor it is enough to increase the counter in the MIDlet-Version field.
- for each user you need to make a personal application with its own data. A midlet is a simple zip-archive, it is enough to place new data in it without recompiling the code itself (of course, you also need to change the size in the MIDlet-Jar-Size field of the .jad-descriptor).
An example of a service using the described principles can be found on the MRF page. You can enter your data in the web form:
and get something like this app:
You can test examples of ready midlets from the gallery - even the oldest pipes easily open directories for 5-10 thousand lines (for example, the English-Russian dictionary or the schedule of suburban electric trains). Ready midlets are no different from those received in the usual way and can be placed, say, in a Nokia store .
Feedback organization
In interactive applications such as the client software of the bank or the pizza ordering catalog, feedback is needed with the application. In the application, you can insert buttons to send SMS with the product code and these messages must somehow be taken.
There are several solutions for receiving SMS.
Solution “on the knee” - you can buy a GPRS modem from MTS or Beeline. If you dig into the modem software, it turns out that all SMS messages sent to the modem number are stored in the usual MS Access database:
In the case of an MTS modem, the base file is C: \ Program Files \ Connect Manager \ db.dat. You can connect to the database (say, through ODBC) directly while the modem is running, it is checked.
A more serious decision is to buy an SMS service from a cellular provider, for example, Beeline, the description of such services looks like this . In addition, you can immediately work through the aggregator (for example AvisoSMS ). This will allow organizing sales of services / goods through midlets without concluding separate agreements with each mobile operator.
Total
Perhaps in some years non-smartphones will no longer be produced, but so far ordinary handsets are sold many times more than iPhones. And for them it is possible and necessary to make applications.
Source: https://habr.com/ru/post/128984/
All Articles