Nokia SDK 2.0 for Java (beta) released - a prize for your feedback sir?

[hamishwillee]

Nokia SDK 2.0 for Java (beta) has been released, which allows you to target your Java apps at Series 40 full touch phones and take advantage of the Nokia IDE for Java.

Because we need your help to create the very best tools possible, we would appreciate it if you could provide feedback on the new SDK and working with the new platform as responses to this thread.

The most useful feedback we get here (for example a a suggestion for improvement or a defect report) will be awarded a Nokia Asha 311 as part of (and at the end of) the Asha Touch Competition 2012Q3.

We're looking forward to your suggestions and other feedback. Please see the competition page for more information.

[Noel.Anonas]

That's great. I'm compiling my comments now to the new SDK to give feedback here.

[hamishwillee]

That's great. I'm compiling my comments now to the new SDK to give feedback here.

Great - the earlier the better so we have a chance to get them into the final candidate!

[Noel.Anonas]

Great - the earlier the better so we have a chance to get them into the final candidate!

Okay I'll try if this is a valid feedback

Feedback - Using PC keyboard to the SDK 2.0 Emulator

When entering a text to the TextField Component or TextBox component using the SDK 1.1, though I could use the keypad in the emulator,
I could use my keyboard from my laptop.
Sample app using SDK 1.1 Emulator

But for SDK 2.0, I could no longer use my keyboard from my laptop when entering text to the text field but instead I forced to use the virtual keyboard in the SDK 2.0 emulator.
Sample app using SDK 2.0 Emulator

I preferred to use the laptop keyboard when typing because it is much faster to type and edit a text rather than pressing the character one by one using the virtual keyboard from the SDK 2.0 emulator. I hope the PC keyboard will still be used for entering the text to the Text component using emulator in the future release for full touch SDK.

----------------------------------

[hamishwillee]

Hi Noel

Feedback from the SDK team is:

Thanks for your valuable feedback – much appreciated. We’re trying to introduce input from PC keyboard but this is proving to be difficult and we’re not sure whether we’ll achieve it for the candidate SDK. Even though we were aware of this problem, your feedback will of course be "counted" for the competition. Keep the ideas coming - next time you may well find something we don't know about!

Regards
H

[internetlabor]

I think the biggest improvement should be better help for us developers when something goes wrong.

1) If some developers can not run the emulator, all the excelent work is useless for them.
From the release notes I see that the newest java sdk ist not compatible with emulator.
I also experience problems with RMI-Port. Now you can have several java versions installed.
Please add information how to control which java virtual machine is used.

(Work arround for me is to use WindowsXP Mode in Windows 7 Professional. But it don't like that I need to do this.)

2) When an app with something invalid is loaded, for example with a bad jar/jad file descriptors, you only get a message "invalid app. delete?"
That is OK for the end user phone, because the end user can not do anything about it,
but it is not enough for a developer tool. We developers don't want to waste our time with guessing.
It should at least write it to some log file what was the problem, which entry triggered the error.
I see you can trace a lot thing. I tried "verifer", but it does not help, the error happens before it logs anything.

[Noel.Anonas]

Hi Noel

Feedback from the SDK team is:


Regards
H

Yes! Sure. I'll post other comments/suggestions all the things that I'll discover using the SDK 2.0.

Thanks for the updates.

[Nirmal K Veetil]

I think the biggest improvement should be better help for us developers when something goes wrong....

Hello internetlabor,

Thank You for your feedback. They help us understand what developers are looking for and where they need improvements. Find our response to your questions below

1. We agree that this was a huge limitation. However, we've cracked the issue and JDK 7 will be compatible with the Nokia SDK in the candidate buils. Please detail the RMI-Port issues that you seem to be facing.

2. Diagnostics is one area where we're trying to improve a lot and this concern that you've highlighted is something that we want to address. However, we already have a mechanism to view traces. Have you tried enabling traces for information that would matter to you from Tools -> Preferences -> MIDP monitor? Try enabling this and you should be able to view traces on the 'Diagnostics' window. Let us know if that worked.

It feels great to know that your feedback and our target product are heading in the same direction. This is great feedback and would be interested to see more of them coming.

Regards,
nKv

[internetlabor]

Hallo nKv,

good that something is happen again with the java tools.

So let's dig a little deeper.

About Emulator-Diagnostics and Trace:

Yes, I know the about Emulator settings in Tools -> Preferences -> MIDP monitor. (But I think many don't know about it)
It looks like this:

midp-monitor-nokia-sdk2.png

So what are these checkboxes?
Some of them are obvious, others not. For example, what might "frames" or "monitors" mean in this context?

Some of the options generate only output when my app is running. But some of the options generate lot of output all the time, even when the emuator is on the home screen and nothing is happen. For example the "monitors". These options are probably useful for the developers of the emulator itself, but not for app developers.

Checking the "exception" checkbox is useful during normal testing of the app. When something goes wrong, you get some feedback even without the debugger. Also network tracing is sometimes useful. Something like tracing methods-calls is not so useful, because luckily we also have debuggers.

But what seem to be missing is something that give outputs in the time before the app is started, when the jar-manifest is parsed. (It tried the "verfiy" checkbox, but it only generates output after an app has successfully started.)

Regards

Karsten Meier

2. Diagnostics is one area where we're trying to improve a lot and this concern that you've highlighted is something that we want to address. However, we already have a mechanism to view traces. Have you tried enabling traces for information that would matter to you from Tools -> Preferences -> MIDP monitor? Try enabling this and you should be able to view traces on the 'Diagnostics' window. Let us know if that worked.

[Nirmal K Veetil]

Some of the options generate only output when my app is running. But some of the options generate lot of output all the time, even when the emuator is on the home screen and nothing is happen. For example the "monitors". These options are probably useful for the developers of the emulator itself, but not for app developers.

Checking the "exception" checkbox is useful during normal testing of the app. When something goes wrong, you get some feedback even without the debugger. Also network tracing is sometimes useful. Something like tracing methods-calls is not so useful, because luckily we also have debuggers.

Hi Karsten,

Thank You the details. We agree that certain traces are more from the platform than the MIDlet. We're working to have more relevant traces available for developers as we discuss. We're hopeful of bettering it

But what seem to be missing is something that give outputs in the time before the app is started, when the jar-manifest is parsed. (It tried the "verfiy" checkbox, but it only generates output after an app has successfully started.)

We're working on a validation/verification mechanism that can catch some common errors. Watch out for these changes to be available in 1 of our updates

These are great comments. Thank You for sending them out. We hope to hear more from you.

Regards,
nirmal

[internetlabor]

I just attended the Nokia Netbeans Webinar, and used the Gui-Builder to create an UI. For a long time, the high-level UI Components (LCDUI) were falling behind the rest of the phone-UI.
Now I see you can start using them again. That is good because you can easily develop productivity-style apps with them.

There is one thing that bites you soon when you develop with LCDUI: handling of text when text length is longer than one line.
Attached I have an example of a quiz.

nokia-s40sdk2-linebreak.png

The StringItem has line-breaks, so the problem is solvable

The RadioButtons cut the text off. This is a real problem. There is typically a reason why the text is so long. Not only for quiz applications, but also when you have some settings to choose from.
You even see this problem in Nokia-Apps itself, when some options are translated, but the translation no longer fits. The translator abbreviates the text in a way that it is sometimes not comprehensible any more.

Old phones sometimes used ticker text for the active element. This was never nice, but at least the user has a chance to read the complete text. But on touch screens there is no active element, so this hack does no longer work. So If I were Nokia I would try to change this as fast as possible.

The Actionbutton-text is also cut off. I know this is hard to correct, because of the styling of the button. Luckily this is not so often a problem, buttons can typically be named with some shorter text. Never the less sometimes you need multi-line buttons.

Regards

Karsten Meier

[shaii]

Ok well here is my feedback after playing around with the new sdk:

1. The emulator heap size does not match the real phones.
while the emulator limit the heap size to values between 500k-2Mb the new Asha full touch phones come with 4Mb heap.
(this limitation can be found in the preferences menu)
2. cannot invoke System.GC via the emulator menu options, while this is a feature available even on the old WTK.
3. caputure still images is taken from a pre-rendered animation (i would expect it to be able to select an image from pc like the blackberry emulators do)
4. the System.getProperty("fileconn.dir.photos") does not point to the phone real photos gallery as should be according to the midp2.0 official specs (also the phone im afraid works the same, looks like a fault in the implementation.
5. This might also happen on the real phone platform as well but there is somewhat low number of audio players that can be prefetch at the same time (i think around 6)

Shai

[UnPlan2ned]

Hi,
I used the online installer and installed everything but the language pack.
After the installation was completed there was no desktop shortcut for the Nokia IDE - only for the emulator.
Not a big problem, though, but I thought I'd report it.
~ Andreas

[hamishwillee]

Thank you all very much. I've forwarded to the SDK team.

[Nirmal K Veetil]

Hi UnPlan2ned,

I must admit, this is a good observation However, this (not displaying the shortcut for the Nokia IDE) was done on purpose irrespective of whether few or all components were installed. We could however consider letting the user decide the shortcut(s) that he would like to see.

Thank You for sharing this. We're waiting for more of your feedback.

Regards,
nKv