1. J2ME to Android FAQ

    1. Business Q&A
    2. 1. How mature is the service? What is quality level of your service?
    3. 2. What is your pricing model?
    4. 3. What is your support model?
    5. 4. I am interested in using your services. What is the process for conversion of an app from J2ME to Android?


    6. Technical Q&A
    7. 1. Do you read jad properties, is the MIDlet.getAppProperty() supported?
    8. 2. Do you support mapping to standard buttons in Android, I’m thinking of back, menu, home and search? Is that possible?
    9. 3. My main concern is that my applications use complex mutli-threading, set up Bluetooth piconets (up to 6 nodes), detect hardware sound     Scapabilities, manage keypad/keyboard/touch-screen, etc. Occasionally, I run into problems that revolve around complex timing issues,     etc. It’s hard enough to work through bugs when I know the problem must lie in my own code, or the phone the code is running on. I’m     afraid that if I add additional layers (your translation algorithms and library modules) then I’ll never get to the bottom of bugs that arise.     I’ve built a rather comprehensive Java ME framework of nearly 200 classes, reusable solutions to many recurring problems. At present,     it’s quite reliable, and when something does go wrong I can climb in and fix it. I’m concerned that I’ll get "stuck" when bugs in your layers     arise.
    10. 4. What are the benefits of using UpOnTek’s service vs writing the app from scratch?
    11. 5. How do you handle background processes? Does your automated tool enable background services so, for example, the location is sent     from the device to our servers in the defined interval, even when moving from one screen to another?
    12. 6. How do you handle JavaME API permissions?
    13. 7. Will you support JSR 257 (NFC) ?





    1. Business Q&A
    2. 1. How mature is the service? What is quality level of your service?
    3.     UpOnTek has put an emphasis on quality of the conversion. Our service has been widely used, by banks, enterprises, mobile operators,     and game developers. Some of our converted apps have been pre-installed on an Android device.
    4.     Back

    5. 2. What is your pricing model?
    6.     Business model is based on a one time payment for conversion of app from J2ME to Android. Discounts are available for conversion of     10 apps and more. Price depends on model chosen, and app complexity. UpOnTek offers Standard, Silver and Gold models. The details     of each model are explained at our services. The silver model is recommended for most application developers.
    7.     Back

    8. 3. What is your support model?
    9.     Support for 90 days is included in the original price. Support beyond 90 days can be purchased separately.
    10.     Back

    11. 4. I am interested in using your services. What is the process for conversion of an app from J2ME to Android?
    12. ● Customer sends app
      ● UpOnTek does initial analysis
      ● Customer chooses payment method - paypal or direct deposit.
      ● UpOnTek sends invoice
      ● Customer secures payment
      ● Customer signs license agreement.
      ● UpOnTek sends the converted app, an eclipse project and recommendations for app improvement (if exist).
    13.      Back


    14. Technical Q&A

    15. 1. Do you read jad properties, is the MIDlet.getAppProperty() supported?
    16.     Yes, we support jad properties. In the android project we have a file assets/db.jad that contains all your JAD properties and in runtime     calls to getAppProperty return properties from this file. We also have an API that you can supply your own JAD properties from other     sources, that will be accessible to the MIDlet at runtime.
    17.     Back

    18. 2. Do you support mapping to standard buttons in Android, I'm thinking of back, menu, home and search? Is that possible?
    19.     Yes, Our conversion services enables to map these keys to any MIDP key code, at your request, and the conversion service can also     make it a configuration option so you can control it from the android project.
    20.     Back

    21. 3. My main concern is that my applications use complex mutli-threading, set up Bluetooth piconets (up to 6 nodes), detect     hardware sound capabilities, manage keypad/keyboard/touch-screen, etc. Occasionally, I run into problems that revolve     around complex timing issues, etc. It's hard enough to work through bugs when I know the problem must lie in my own     code, or the phone the code is running on. I'm afraid that if I add additional layers (your translation algorithms and library     modules) then I'll never get to the bottom of bugs that arise. I've built a rather comprehensive Java ME framework of     nearly 200 classes, reusable solutions to many recurring problems. At present, it's quite reliable, and when something does     go wrong I can climb in and fix it. I'm concerned that I'll get "stuck" when bugs in your layers arise.
    22.     Your concerns are valid, however you should look at it another way. When you use our tool and convert your games from J2ME to     android, basically is like you run on another J2ME platform, let's call it "android+our engine". You probably already have workarounds for     the dozens of J2ME platforms out there, so this is one more, but with 2 significant improvements:
      ● We strive for maximum compatibility, so if you have a problem in the game and it works well on other J2ME platform,
      we always treat is as our bug. We can define a reference platform (we used Nokia 5800 as reference with one of our last projects,
      but it can be other platforms as well) and if it works ok there we guarantee it will work ok on our engine.
      ● We are more responsive when reporting a bug in the J2ME implementation, compared to the large phone OEMs.
    23.     Back

    24. 4. What are the benefits of using UpOnTek’s service vs writing the app from scratch?
    25.     Writing the app from scratch has a number of drawbacks:
      ● Learn and Development: You need to learn a new platform and invest considerable resources in rewriting the code, which.
      can be expensive.
      ● Maintenance: If you make changes or improvements to your game, you now need to maintain 2 completely different
      platforms, so it also makes it more expensive. Our solution allows you to achieve much faster time to market at a much
      reduced cost, and your games can still look great on the android platform.
    26.     Back

    27. 5. How do you handle background processes? Does your automated tool enable background services so, for example, the     location is sent from the device to our servers in the defined interval, even when moving from one screen to another?
    28.     We have a mechanism for automatically running the MIDlet in the background as a service. It can work without any modifications in the     MIDlet though we have several tips for correctly implementing the MIDlet to work better in such mode (mostly small changes that can be     done quickly).
    29.     Back

    30. 6. How do you handle JavaME API permissions?
    31.     Regarding permissions: when we convert the J2ME app to android application (APK) we put the relevant permissions in the Android     manifest so the application will have all the needed permissions. We find the needed permissions by analyzing the APIs the app uses as     well as the permissions it requests in the JAD. For example if the app uses location(JSR179) we will add the needed android permissions     for accessing the GPS
    32.     Back

    33. 7. Will you support JSR 257 (NFC)?
    34.     Android 2.3 includes a number of new APIs. One of the major additions is Near Field Communication technology(NFC), JSR257. We     expect to add NFC support to our conversion service in Q1 2011.
    35.     Back