Version 6.5 of NetBeans IDE has been released! The 'mobility part' is now included into one standard Java bundle that also contains Java SE, Java EE, Java FX, web components and servers (GlassFish, Tomcat). The installation file is about 212MB (NetBeans 6.1 'mobility' was 72MB)! One may ask why there's no separate bundle - IMHO, the answer is simple - Java ME and Java EE complement one another in different environments and more IDE components are Java ME+EE enabled (like webservices or SIP). Of course, you can add or remove packs later using the IDE's Plugin Manager (Tools -> Plugins).

What's new for Java ME developers?

• new project wizard for adding custom components to the Visual Designer Palette
  
• new SVG UI components in the enhanced SVG Composer enable rich UI design
  
• new Data Binding Custom Components in the Visual Designer Palette
  
• upgraded obfuscation tool to ProGuard 4.2 and test framework to JMUnit 1.1.0

You'll find more (screenshots included) about described features at NetBeans IDE 6.5 New and Noteworthy page.

Bonus links:
NetBeans IDE 6.5 Features
NetBeans IDE 6.5 Tutorials and Documentation
Guided Video Tour of NetBeans IDE 6.5

When I first heard about S60 Platform Services enabled widgets I started to ask myself about security. The first thought was, "I'll have to sign new widgets with something similar to Java Verified or Symbian Signed". Such solution wouldn't be great for many reasons (killing great ideas for widgets, web developers coming from desktop environment wouldn't like it too, signing costs, etc.). Therefore there's no "widget signing" at all. But, is it safe for the end-user?

The first thing to note is that S60 widgets access the network through the Web Browser for S60. In this respect, widgets are as safe as running web pages in the browser. WRT widgets also implement a sandbox security model (it makes me think of Java ME here), and they only have limited access to the S60 Platform Services. Widgets are always considered untrusted by the device. This means that access to platform services (such as user data, location) is controlled and that mobile device users must grant permission before a widget can access network services.

From developer's point of view, WRT 1.1 utilizes a common component called Runtime Security Manager to enable access control to platform services - it registers a widget when it is installed; when running, the security manager performs runtime access control to platform services (prompts the user) according to the access policy; finally, it unregisters a widget when it is uninstalled. Access policy is defined by a set of capabilities (ReadUserData, WriteUserData, Location, NetworkServices) that are allowed automatically or granted to the user via prompts, and by duration of access (one time or session based).

It's a pity that access policy for WRT 1.1 is not customizable by the widget developer (OK, I agree here!) or the user (Why not? Because of security policies! Thus, S60 5th edition Application Manager doesn't show 'Suite settings' for widgets).

BTW, I know that it will not happen, but... wouldn't it be great to have all this goods based on WRT 1.1 running also on S60 3rd FP2 devices (via firmware upgrade)?

As you probably know, S60 5th Edition brings WRT 1.1 with support for S60 Platform Services through JavaScript Service APIs. Of course, the new Web Runtime environment is backward-compatible, so widgets created for WRT 1.0 run normally with WRT 1.1 (but you should take touch UI or different display sizes into consideration when running WRT 1.0 widgets on newer mobile devices). It follows logically that widgets created using the WRT 1.1 Service APIs do not work with WRT 1.0

What's new in widgets?

In addition to "old" widget, menu, MenuItem objects and Systeminfo Service API (sysinfo object) developers get new S60 Platform Services and Service APIs that allow to: 

• access and launch applications on a device using the AppManager Service API (e.g. retrieve a list of user/pre-installed applications; launch an application as embedded or stand-alone, based on an application ID or given document or MIME type),
  
• 
  
• access and manage calendar information using the Calendar Service API (e.g. access, create, and manage calendars and calendar entries stored on a device; import and export calendar entries),
  
• 
  
• access and manage information about contacts using the Contacts Service API (e.g. retrieve information about contacts, contact groups, and contacts databases; create, edit, and delete contacts and contact groups; import and export contacts; organize contacts into contact groups; also worth mentioning is that the information can reside in one or more contacts databases stored on a device or in the SIM card database, so you have all you need!),
  
• 
  
• access and manage information about landmarks using the Landmarks Service API (e.g. retrieve information about landmarks, landmark categories, and landmark databases; create, edit, and delete landmarks and landmark categories; import and export landmarks; organize landmarks into landmark categories),
  
• 
  
• access device location information and perform location-based calculations using the Location Service API (this API relies on the GPS capabilities of the device to provide location information),
  
• 
  
• access device logging events using the Logging Service API (e.g. access mobile device logging events such as call logs, messaging logs, and data logs),
  
• 
  
• access information about media files stored on a device using the Media Management Service API (widgets can retrieve metadata about the media files stored in the Media Gallery of an S60 device, so you can create widgets such as a custom photo viewer or audio player, that display or otherwise incorporate media),
  
• 
  
• send, retrieve, and manage messages such as SMS and MMS using the Messaging Service API (widgets can use the Messaging Center of an S60 device to send, retrieve, manage or notify the user when new messages arrive or even change the status of a message),
  
• 
  
• access data from the physical sensors of a device using the Sensors Service API (The data from a given sensor is mapped to one or more sensor channels, which the API can listen to. That is, you can search for sensor channels available on a device; listen for data provided by one or more sensor channels; retrieve information about and modify sensor channel properties; notify the user when a sensor channel property is changed; Of course, the available sensors depend on the device.),
  
• 
  
• access and modify system information on a device using the SystemInfo Service API of WRT 1.1 (as opposed to 'old' SystemInfo Service API of WRT 1.0, you can also modify system attribute values).
  

That's all for this time - next time I'm going to write about security of widgets, so stay tuned for some interesting facts...

Now, let's get widgetized!