There have been a lot of popular new devices introduced in the last year, so it’s a good time to refresh the device simulator with some new skins.  The following skins are now available in the Vase API project:

BlackBerry 10 Simulators

NOTE: The initial support for BlackBerry 10 in Codename One will be using the Android 2.3 Runtime.  For this reason, the following BlackBerry skins will be detected as Android devices, and use the Android gingerbread theme and fonts.

The BlackBerry 10 devices are completely gesture driven, there are no physical/virtual navigation buttons as seen on all other platforms.  To open the menu on BlackBerry, you would normally swipe down from the top bezel – in the simulator, touching the top bezel will open the menu.  When the menu is open in the physical Android runtime, an Android-specific ‘back button’ appears in the bottom left of the screen – in the Simulator, touching the bottom left bezel will trigger a Back event.

BlackBerry Z10

BlackBerry’s latest full-touch smartphone running the new BlackBerry 10 OS, 1280 x 768 resolution, 356ppi pixel density, 4.2″ diagonal, dual core 1.5Ghz TI OMAP 4470, 2G RAM.

[Download BlackBerry Z10 skin]

BlackBerry Q10

BlackBerry’s latest classic QWERTY smartphone (less the trackpad) running the new BlackBerry 10 OS, 720 x 720 resolution, 330ppi pixel density, 3.1″ diagonal, dual core 1.5Ghz TI OMAP 4470, 2G RAM.

[Download BlackBerry Q10 skin]

BlackBerry PlayBook

BlackBerry’s first tablet, the Playbook, running BlackBerry Tablet OS 2.1 at the time of this writing, but soon to be running BlackBerry 10.  1024 x 600 resolution, 170ppi pixel density, 7″ diagonal, dual core 1.0Ghz (WiFi version) or 1.5Ghz (LTE version) Cortex-A9 TI OMAP 4430, 1G RAM.  (I recently picked up a 32G playbook for $100)

[Download BlackBerry Playbook skin]

Android JellyBean Simulators

The HTC One simulator will be the first Ultra HD smartphone skin available for Codename One. I’ll have to update these images shortly, a couple bugs in Codename One related to this high resolution have been recently fixed.

HTC’s latest flagship device, the HTC One, Android JellyBean 4.2, 1080 x 1920 resolution, 468ppi, 4.7″ LCD, 2G RAM, 1.7Ghz Quad Core Snapdragon 600.

[Download HTC One skin]

Google/ASUS Nexus 7

Google’s ultra popular Nexus 7 tablet by ASUS, Android JellyBean 4.2, 7” 1280×800 resolution, 216ppi pixel density, 1G RAM, 1.3Ghz NVidia Tegra 3 quad core processor.

[Download Google Nexus 7 skin]

Nokia S40 Simulators

Nokia recently announced their 2012Q4 numbers, and it included a staggering 80 million S40 devices, including 9.3 million full-touch Asha devices shipped in that quarter alone, versus only 4.4 million Lumia devices, in the quarter the Lumia was first released.  The same report also shows that S40 popularity does not reflect true in North America.  The Asha’s popularity can be attributed to the smartphone-like features at an affordable price point without carrier subsidies/lock-in.

Nokia Asha 311, one model in Nokia’s popular Asha 300 series of S40 devices, this simulator is suitable for testing the Asha 305 through 311, all of which have identical display characteristics.  Nokia OS S40 Developer Platform 2.0, 240×400 resolution, 155ppi pixel density, 3.0″ full-touch screen, 1Ghz ARM11 processor (a couple models use a 800 Mhz processor).

[Download Nokia Asha 311 skin]

Nokia C3-01 is one of Nokia’s “Type and touch” models, it features both a numeric keypad and resistive touch screen. A couple surprising bonus features – it has WLAN B/G/N and a 1Ghz (model RM-776) or 680Mhz (model RM-640) processor .  Nokia S40 OS 6th edition, feature pack 1, 320×240 resolution, 167ppi pixel density, 2.4″ resistive touch screen, 128M/64M RAM (I recently picked up the RM-640 model for $25).

[Download Nokia C3-01 skin]

Apple IOS Simulators

Apple’s first 7″ tablet, the IPad Mini, IOS 6, 1024×768 resolution, 163 ppi pixel density, 7.9″ diagonal, Dual-core 1 GHz Cortex-A9 processor, 512M RAM

[Download Apple IPad Mini skin]

Windows Phone 8 Simulators

Nokia Lumia 920, their current flagship Windows 8 phone, 768×1280 resolution, 332ppi pixel density, 4.5″ diagonal, dual core 1.5Ghz Snapdragon S4 CPU, 1G RAM.

[Download Nokia Lumia 920 skin]

Other custom skins

Check out the earlier two posts for previously released skins here and here.  The full list of skin downloads can be found here.

Like this post?

If you like this blog posting, please don’t forget to click the Like buttons. Also, you can send comments to the Codename One Discussion Forums, I check there fairly regularly.

New Device Simulator skins

Nokia finally announced the death of Symbian today… my last smartphone was a Symbian S60 based Nokia E71.  I was very fond of it, and still use it for development today.  A few things that surprised me from today’s articles (such as this one):

1. Symbian wasn’t already dead
2. S40 is not a Symbian-based OS (Symbian S60 caused this confusion for me).
3. The last Symbian device released (808 PureView) had a whopping 41 megapixel camera
4. Nokia shipped 80 million (!!) S40-based devices in Q4 of 2012
5. Nokia shipped 9.3 million Asha S40 devices in Q4 of 2012, which is twice as many Lumia devices shipped in the same quarter (4.4 million).

R.I.P. Symbian – 1998 – 2013

In the previous post, the sample KML document was one I edited by hand.  I could have saved some time by using Google Maps to generate the KML for me.  Here’s a quick guide on how to use Google Maps to generate a KML document very similar to the one in the previous demo.

1. Point your browser to http://maps.google.com, and search for some location.  Below, I searched for the city hall in London, Ontario.  Click the marker on the left hand side, google maps will open a ‘bubble’ above the location on the map.  Click the Save to Map link, then click the Save button.
   
   
2. Next, click the Search Nearby link, and search for restaurants near the city hall.  As in step 1, repeat the steps of clicking some markers in the left, then save the markers to your map.  Do the same for nearby hotels.
   
3. Once you have a list of markers saved to your map, click the My Places button on the left of the screen, then click the Maps button below it, and finally click the My Saved Places link (assuming you kept the default map name).
   
4. You should see the list of markers you selected in steps 1 and 2 above.  Click on the KML link to save the markers to KML format.  A dialog will appear to save to the local filesystem.
   

Want more?

If you poke around the Google Maps interface, you’ll notice that you can share your maps publicly.  The share button will pop up a dialog giving a link to your public map.  If you append ‘&output=kml‘ to that URL, the map will be returned as a KML.  You could use this URL as an hosted map for the KMLPointsLayer, rather than downloading the KML to file.

In a future post, I’ll explore dynamically generating KML map data on demand using the Google Map APIs to feed the KMLPointsLayer component.

Like this post?

If you like this blog posting, please don’t forget to click the Like buttons. Also, you can send comments to the Codename One Discussion Forums, I check there fairly regularly.

Create KML documents using Google Maps

I’ve added an implementation of a Codename One mapping points layer to the Vase API for populating a map using data from a Keyhole Markup Language (KML) file. Currently only basic KML support is implemented, but I will add better support over time.  Play the video below to see some of the supported features in action.

Using the KMLPointsLayer is quite simple:

MapComponent map = new MapComponent();
// input can be an inputstream or a local file path
PointsLayer kml = new KMLPointsLayer(input);
map.addLayer(kml);
map.zoomToLayers();

The map in the video was created using this KML document.

Like this post?

If you like this blog posting, please don’t forget to click the Like buttons. Also, you can send comments to the Codename One Discussion Forums, I check there fairly regularly.

Further Reading

The following is a decent reference guide for the KML format. (Disclosure, this is an affiliate link, I do own a copy of this book).

Mobile Mapping with Keyhole Markup Language (KML)

I recently installed some free GPS apps on my Android device, because I wanted offline maps when I’m out of the country.  The roaming data charges from my mobile service provider are killer!.  Namely, the apps I installed are NavFree world, and NavFree USA edition (I don’t understand the separation).  The software is quite impressive, and very professional.  My main complaint with NavFree is all the teaser features – where you click a button and it says ‘that’s coming in the next release’. If they were to remove those, the app would appear very feature complete.

OpenStreetmaps

The NavFree software uses map data from OpenStreetmap (OSM).  I hadn’t checked out OSM for a few years, and it’s come a long way.  Here in Ontario Canada, so far most areas I’ve checked out are covered.  I’ve also found several areas that are missing large chunks of data as well.  One thing that caught me by surprise though, is when I drove into a small private campground in the middle of nowhere with my GPS turned on, and to my surprise, the campground had all of it’s streets, along with streetnames and directions, on both the Navfree app and Google Maps!  I asked the campground owner about how that was done, and he looked at me both confused and delighted, he had no idea how it got there.

Contributing Map Data to online Map Service Providers

So, I did a quick search of the Android Play store, and found a number of ‘GPS Tracker’ tools for OpenStreetmaps,Google Maps, etc.  I installed one for OpenStreetmaps called OSMTracker.  It’s quite simple and works well.  You simply turn on GPS Tracking from the menu bar, drive/walk/bike/etc along the path where provider is missing map data, then turn off and save the tracking from the menu bar.  When you view the saved track, you can export it as a GPX file, and upload the file to OSM.  After uploading the trace file, you can edit the street names, the direction for one way streets, speed limits, etc. from the OSM site.  Once everything is committed, then other uses can navigate to the newly added streets.  For google maps, this would happen automatically because the navigation uses live data.  For OpenStreetmaps, the user will see your contributions next time they update their map data.

Google also provides tools for updating google maps.  The idea is similar, you would need a KML tracing tool that operates similar to OSMTracker above, then you paste the KML data into the Google Mapmaker tool.

Like this post?

If you like this blog posting, please don’t forget to click the Like buttons.

Open Navigation

The simulator skins tutorial was quite popular, 57 likes on the first day, wow!  I finished up the rest of the skins mentioned in that post, and they can be found in the Vase API SVN.  Here’s the current full list, and some screenshot samples:

BlackBerry Bold 9790

(I reviewed this physical device recently)

f

Touchscreen, QWERTY, 480x360, 2.45 inch display, ~245 ppi pixel density, BBOS 7.0, optical trackpad, physical back/menu buttons

Samsung Galaxy Nexus

(This is my current smartphone, love it, mostly (except the handsfree features))

Android 4.0 (Ice Cream Sandwich), 720x1280, 4.65 inch display, ~316 ppi pixel density, physical back/menu buttons

Nokia 2760 Featurephone

(What I used before my first smartphone)

Series 40 (S40), Numeric Keypad, non-touch, 128x160, 1.9 inch display, ~108 ppi pixel density, DPAD, 2 softkeys, 600kb heap

LG Viewty KU990

(My sister-in-law’s phone)

Symbian, Touchscreen, 240x400, 3 inch display, ~155 ppi pixel density, 1 softkey

Motorola Dext (aka Cliq in US)

(A friend’s son’s phone)

Android 1.5 (Cupcake)/2.3 (Gingerbread), touchscreen, QWERTY, 320x480, 3.1 inch display, ~186 ppi pixel density, physical menu/back/search buttons, DPAD

Nokia E71

(My previous smartphone, loved it)

Symbian S60, QWERTY, non-touch, 320x240, 2.36 inch display, ~169 ppi pixel density, DPAD, 2 softkeys

Coby MID7012 Tablet

(My tablet, I wish the touchscreen were capacitive and access to the full Android market, I’d use it more)

Android 2.3 (Gingerbread), 800x480, 7 inch display, ~133 ppi pixel density, Resistive Touchscreen (budget tablet), physical menu/back/search buttons

Samsung SGH-A747 Featurephone

(A friend’s old phone)

Symbian S40, 176 x 220, 2.2 inch display, ~128 ppi pixel density, non-touch, numeric keypad, DPAD, 2 softkeys

Samsung Nexus S

(Several friends have this phone, Google recently pushed Ice Cream Sandwich to it)

Android 2.3 (Gingerbread)/4.0 (Ice Cream Sandwich), 480x800, 4 inch display, ~233 ppi pixel density, physical back/menu/search buttons

BlackBerry Curve 8320

(I bought this solely for testing, this model has WiFi but not the GPS (8330))

BBOS 4.6, 320 x 240, 2.5" display, ~160 ppi pixel density, non-touch, QWERTY keyboard, trackball, physical menu/back buttons, no softkeys

Like this post?

If you like this blog posting, please don’t forget to click the Like buttons. Also, you can send comments to the Codename One Discussion Forums, I check there fairly regularly.

More Mobile Device Simulator Skins…

Uploading files from mobile devices to the cloud requires only a few lines when using Codename One.  I’ll demonstrate here by uploading to the webapp created using Spring Roo in the previous post.

The Mime-Types value seen on the webapp side are passed from the mobile app.  I’ve added a new MimeTypes utility the Vase API to handle this. It uses the public domain mime-type registry hosted by the Apache httpd project for mapping known file extensions to associated mime type ids.  For parsing the mime file, I also implemented a BufferedReader for the Vase API since it’s not available in J2ME.

Implementing multipart/form-data file uploads from mobile

There’s not much to the code for the mobile app in the video above.  Simply create a Codename One project using the Empty template, add the following code:

    protected void doFileUploadDemo() {
        // This is the URL of the webapp from the previous blogpost, running on
        // the local network
        final String endpoint = "http://192.168.2.18:8080/MediaUploadDemo/mediauploads";
        Form f = new Form("Choose a file");
        f.setLayout(new BorderLayout());
        FileTree.setFolderIcon(theme.getImage("arrow-right.png"));
        FileTree.setFolderOpenIcon(theme.getImage("arrow-down.png"));
        FileTree.setNodeIcon(theme.getImage("Add_Zone.png"));
        FileTree ft = new FileTree();
        ft.addLeafListener(new ActionListener() {
            public void actionPerformed(ActionEvent evt) {
                String filename = (String)evt.getSource();
                if (Dialog.show("Send file?", filename, "OK", "Cancel")) {
                    MultipartRequest req = new MultipartRequest();
                    req.setUrl(endpoint);
                    req.setPost(true);
                    InputStream is = null;
                    try {
                        is = FileSystemStorage.getInstance().openInputStream(filename);
                        req.addData("content", is, MimeTypes.getInstance().getMimeType(filename));
                        req.setFilename("content", filename);
                        NetworkManager.getInstance().addToQueue(req);
                    } catch (IOException ioe) {
                        ioe.printStackTrace();
                    }
                }
            }
        });
        f.addComponent(BorderLayout.CENTER, ft);
        f.show();
    }

Like this post?

If you like this blog posting, please don’t forget to click the Like buttons. Also, you can send comments to the Codename One Discussion Forums, I check there fairly regularly.

multipart/form-data: Uploading files from mobile devices to the cloud

Preamble

In a project I’m currently working on, I have a requirement for handling user-uploaded images.  The project uses Spring Roo for rapid development of the webapp, and the choice for cloud plaform service provider has been narrowed to either VMWare’s CloudFoundry, Amazon EC2, or Google App Engine.  The example in this post should run on CloudFoundry and EC2, but to run on AppEngine, there will be some tweaks required to prevent attempts to access the filesystem.  I may revisit this post later to discuss changes required for running on Google AppEngine in more detail.

Prequisites

In this post I will assume the reader is somewhat familiar with Spring Roo, so I won’t be explaining much about Roo itself.    To get up to speed, I suggest visiting the Spring Roo website.  If you’re already a Spring Roo user, please ensure you’re using the latest version, 1.2.1 at the time of this writing, because some of the features I discuss here where very recently added to Spring Roo.

Demo: Adding File Upload support using Spring Roo and Spring MVC

1. Create a new Spring Roo project.
   1. If you’re using the Spring Tool Suite (STS), use File, New, Spring Roo Project.  Give your project a name, and a top level package name, then click finish.  After the project is created, you will see the Spring Roo console open, from this point you will follow the console instructions, not including the line below.
   2. If you’re using the console, type

      project --topLevelPackage ca.coolman.demo --projectName MediaUploadDemo --java 6 --packaging JAR

   I will use the package ca.coolman.demo for this post.

2. We’ll start by setting up persistence to store metadata about the uploaded image, which we’ll do in the Roo Shell. For this demo, I will use a Hypersonic embedded database for ease of setup.  In the Roo Shell, type the following:

   jpa setup --database H2_IN_MEMORY --provider HIBERNATE

3. Now, to create our model, we’ll run the following command in the Roo Shell.

   entity jpa --class ~.model.MediaUpload
   field string --fieldName filepath --notNull true --sizeMax 128
   field number --type long --fieldName filesize --notNull true
   field string --fieldName contentType --notNull true

4. We need to modify the generated model code to add a transient content field. We’re making the field transient in the model only, the data is persisted to the filesystem within the controller, which passes the file path to the persistent filename field in the model.   With that said, edit the file src/main/java/ca/coolman/demo/model/MediaUpload.java, and add the following:

   @Transient
   private byte[] content;

5. Now we’re ready to scaffold the CRUD views and controllers, by executing the following commands in the Roo Shell:

   web mvc setup
   web mvc all --package ~.web

6. We’ll override the CREATE method of the generated controller, so that we can persist the uploaded file contents to the filesystem.  I simply pulled the code below from the generated controller ITD, and added the required code for capturing and moving the uploaded file.  (I also removed the generated test for bindingResult.hasErrors() because it will complain about our empty filepath, size, and contentType fields, which are marked in the model as notNull). When we re-save the controller, Spring Roo will automatically update the controller ITD, removing the generated CREATE method.

   @RequestMapping(method = RequestMethod.POST, produces = "text/html")
   public String create(@Valid MediaUpload mediaUpload, BindingResult bindingResult, Model uiModel,
          @RequestParam("content") CommonsMultipartFile content,
          HttpServletRequest httpServletRequest) {
      File dest = new File("/tmp/" + content.getOriginalFilename());
      try {
         content.transferTo(dest);
         mediaUpload.setFilesize(content.getSize());
         mediaUpload.setFilepath(dest.getAbsolutePath());
         mediaUpload.setContentType(content.getContentType());
      } catch (Exception e) {
         e.printStackTrace();
         return "mediauploads/create";
      }
   
      uiModel.asMap().clear();
      mediaUpload.persist();
      return "redirect:/mediauploads/" + encodeUrlPathSegment(mediaUpload.getId().toString(),
         httpServletRequest);
   }

   In this demo, I’m sending all the files to the /tmp/ dir, you would normally define a location for uploaded files to be stored here.

7. Now, the CREATE view created by the scaffolding step will render editors for each of the fields of our model bean by default.  We don’t want to present these editors to the user, so, edit the file: src/main/webapp/WEB-INF/views/mediauploads/create.jspx and for each field under for form, add an attribute to the node: render=”false”.
8. To add an input for selecting the file from the local filesystem to upload, we have a few steps:
   1. First we need to add the following field within the form:

       <field:input field="content" id="c_ca_coolman_demo_model_MediaUpload_content" required="true" type="file" z="user-managed"/>

   2. Edit the file /MediaUploadDemo/src/main/webapp/WEB-INF/i18n/application.properties, add the line:

      label_ca_coolman_demo_model_mediaupload_content=Content

   3. Now, this part is a bit of a hack (I’m sure Spring Roo supports field of type=”file” out of the box, but I couldn’t find it), edit the tag file: src/main/webapp/WEB-INF/tags/form/fields/input.tagx, and look for the following:

      <c:when test="${type eq 'password'}">

      Right above this line, add the following code:

      <c:when test="${type eq 'file'}">
         <form:input type="file" id="_${sec_field}_id" path="${sec_field}" disabled="${disabled}" />
      </c:when>

9. Still in the CREATE view script, we need to set our form encoding to multipart/form-encoded.  We do this by adding the following attribute to the form node:  multipart=”true”
10. Finally, we’ll enable multipart filtering using tools included with Spring Framework. This will automagically take care of the binding work that we’d normally be required to do manually. In your IDE, open the file src/main/resources/META-INF/applicationContext.xml. Add the following after the last <bean> node in the file:

    <bean id="multipartFilter" class="org.springframework.web.multipart.support.MultipartFilter">
       <property name="multipartResolverBeanName" value="multipartResolver" />
    </bean>
    <bean id="multipartResolver"
       class="org.springframework.web.multipart.commons.CommonsMultipartResolver" />

11. The multipart filtering added above has a dependency on Apache Commons IO, so open the pom.xml file and add the following under the dependencies node (or use the Maven POM editor, dependencies tab):

    <dependency>
       <groupId>commons-io</groupId>
       <artifactId>commons-io</artifactId>
       <version>2.1</version>
    </dependency>

12. Now open the file src/main/webapp/WEB-INF/web.xml, and add the following in the <filters>section of the file:

    <filter>
       <filter-name>multipartFilter</filter-name>
       <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
    <filter-mapping>
       <filter-name>multipartFilter</filter-name>
       <url-pattern>/*</url-pattern>
    </filter-mapping>

Try it out

Now, to fire up the app, drop to the terminal, go to the project root directory, and type: mvn jetty:run, then point your web browser to http://localhost:8080, click the context provided link, and you should see something that resembles the following:

Clicking on the content field will present the browse button to select a file.  When you click save, the file will be sent to your tmp/ directory, and you will be presented with the view of the file attributes.  I’ll leave the retrieval and display of the uploaded file contents as an exercise for the reader.

Like this post?

If you like this blog posting, please don’t forget to click the Like buttons.

Further Reading

As of this writing, a new Spring Roo book from Manning has just been released to the presses (April 2012), check it out:

Accepting File Uploads in your WebApp in 10 Minutes or Less

One of the Codename One guys, Shai Almog, recently posted a rebuttal to another posting on devzone, which he ended with the following:

A friend recently told me: “The only reason anyone ever does cross platform is to save money”.

Unfortunately that’s usually true, but my response was: “They shouldn’t. They should use cross platform to provide a distinct experience and more features.”.

Why do I use Codename One for cross-platform development?  In a roundabout way, my story follows…

The Facebook and Twitter effect

Well, it all started with Facebook, and Twitter… but not at all how you’re thinking.  I’m not much of a Facebook kinda guy.  I use it to connect with family and old friends, minimally, and that’s about it.

But, I use Twitter, because I’m a huge fan of the sport of mixed martial arts, and Twitter is the best way to keep up with the quickly moving world of MMA. All the athletes, promoters, trainers, journalists… everyone involved in the sport is on there, it’s a great way to interact with them.

On my old Nokia E71 phone, I used a fantastic piece of software called Snaptu, a cross-platform Java app that worked on any phone, for accessing Facebook, Twitter, LinkedIn, RSS feeds, and more.  It had an IPhone-like user interface, and they did some very intuitive things, for example, the actual app was extemely thin, and was updated on the fly from the server end (this plays a part later).  You never really updated the app. When it started (quickly at that), you had the latest features on the fly without really noticing it. This can be seen as a good user experience.. but also a very bad one (Facebook Timelines as an example).

Last year, Facebook bought Snaptu for $60-$70 million, and within a few months, they of course stripped all support for competing products such as Twitter and LinkedIn, thus rendering the software useless to me.   As mentioned earlier, this intuitive part of the software came back to bite me in the ass.

Anyways, I was intrigued by how well these guys were able to provide such a fine user experience on very limited devices, that in my eyes equaled the native offerings from Twitter and Facebook on the latest devices.  This heavily influenced my goal for mobile, to provide that consistent user experience, across the board.

I went on a hunt for what was available on the J2ME side, and stumbled on a list of about 30 rich UI frameworks, which I narrowed down to LWUIT, and J2MEPolish.  After a short evaluation, I realized LWUIT had the vision that aligned with mine, and here they are today as Codename One, much further than what I anticipated, supporting the broad range of the most constrained devices to the latest gadgets.  No looking back, I believe I made the right choice .

So that’s my story,  I have just one thing more to add.  My primary geographical targets for one particular project on the mobile side include, North America of course (I’m Canadian), but also Brazil and Japan,  The other day, I did a search for the current mobile trends in Brazil, and I stumbled on this article from August 2011, which really opened my eyes, and I found it interesting that they mentioned the success of Facebook’s J2ME strategy (they don’t mention Snaptu by name).  In a nutshell, it appears Brazil is a very connected country, using a very broad range of devices, and they want content on those devices.  Perfect!

I have to wonder, with Codename One and Snaptu both coming out of Tel-Aviv… what the heck are they putting in the water over there?  (It certainly isn’t snake oil!)

Like this post?

If you like this blog posting, please don’t forget to click the Like buttons. Also, you can send comments to the Codename One Discussion Forums, I check there fairly regularly.

Futher Reading

UPDATE: Here is the Startup Nation book Shai referred to in the comment section in response to my remark about the innovation coming from Israel:

You’ve probably noticed I’ve been doing a lot of Twitter development related articles on this blog, and now you probably have a better understanding of why.  I personally get most of my social development related information from the sites provided by each Twitter, Facebook, and LinkedIn, they’ve all done a great job (part of their success i’m sure).

Also, here’s a few books related to development of social media related apps that should be good.  I don’t own any of these books, but I’ve selected ones are of high relevance with a decent customer rating (full disclosure: these are affiliate links):

My story, and I’m sticking to it…

Codename One has made it super easy to create your own device simulator, and I’ll demonstrate here using Gimp, the popular Open Source image editing software.

Creating a Device Simulator Skin for a QWERTY Symbian Device

I’m going to assume readers are familiar with the basic functions of an image editor so I don’t have to explain too deeply. The key tools used in this demonstration are:

• Google Image Search to find the device to simulate
• The Gimp XCF file format for saving layers
• Image Layering
• Free select tool, and Rectangle select tool
• Flood fill
• Crop selection (to remove elements within device image)
• Crop-to-selection (to remove elements outside the device image)
• Image Rotate

With that information, you can probably figure out most of what you need to create your skin images.  Now I’ll quickly go through the complete steps.

1. First, in your IDE, create a generic project.  We don’t need a Java project here, as all the binary code is provided by Codename One.
2. Create a src/ folder, and create a plain text file within that folder named skin.properties.
3. Use Google Image Search to find an image of the device you want to simulate.  Pick the largest, front facing image you can find. Save the image in the src/ directory of your project.  For this demo, as seen in the video, I chose this image:
   
4. Open the image using Gimp, and use the Rectangle select tool to highlight just the device, then click Image, Crop To Selection to remove everything else outside the device.
5. You’ll want an image at least 400×600 or so in portrait mode (preferably even a bit larger) if you can find it.  To get the best representation of your app, the trick is, you want the viewport to be scaled to the resolution of the device screen. If your image is much smaller than that, use Image, Scale Image to bring it up to size (and hope it doesn’t get too pixelated).  Conversely, if the image is much larger, you’ll likely want to scale it down.  For example, the E71 viewport is 320×240 including the statusbar, The image above was approximately 500×500, and after cropping and rescaling, final skin image is 435×800.
6. Save your image as skin.xcf. Gimp will detect from the file extension that you want to preserve layers.
7. Open the layering window by hitting CTRL+L, or selecting Windows, Dockable Dialogs, Layers.
8. Click the Add Layer button, and make sure new layer is above the image of the device by using the Up or Downbuttons.  Make sure you have this new layer highlighted, this is the layer we want to draw on.   Also make sure you have a picture of an eyeball beside each layer – we want both layers visible at once.
   

   Highlighting (gray bar) the new layer

9. Back on the image window, for each physical button on the device image, use one of the Select tools to select the button, then use the Flood Fill tool to color each button a different color.  You don’t need to get too fancy here, just get the general area of the button, but make sure every button has its own unique color.  As you go along, make a note of the mapping between every color (take note of the hex value of the color when you are in the Color select dialog), and the button it maps to.
   
10. Now use the Rectangle select tool, and select the part of the device that will be the applications display canvas.  Flood Fill this area in black (hex#000000).  The black area in the E71 skin has a dimension of 320×240.  Here, we could optionally cut out the status bar, then place it in separate images  header.png and header_l.png.
    

    There's actually 51 different colors on this skin (shades of yellow and red)

11. Save your skin.xcf file (this is the last time you want to save the XCF file.  By keeping a copy at this state, it is easy to make adjustments to the skin, including image size, and re-save the 4 files below).

Now, we will use the XCF file to create 4 PNG files.

1. On the Layer screen opened in step 8, click the eyeball beside the layer that has your new color map.  It should disappear, and you should only see the device now.
2. Click the image window, then click File, Save A Copy), then name the file skin.png
3. Now back on the layer window, click the eyeball beside the color map again, then click the eyeball beside the device image.  You should now see only the color map.
4. Click the image window, then click File, Save A Copy, then name the file skin_map.png
5. Now, click Image, Transform, Rotate 90 degrees counter-clockwise
6. Click File, Save A Copy, then name the file skin_map_l.png
7. Finally, back in the layer window, click the eyeball beside the color map again, then click the eyeball beside the device image.  You should now see only the device image in landscape mode.
8. Click File, Save A Copy, then name the file skin_l.png

That’s it for the images, you can exit Gimp now.  Gimp will ask you if you want to save changes, choose to discard them, we want to preserve the XCF we saved in step 11 above.

Back in the IDE, open the skin.properties file, and edit it as appropriate for the device you are simulating.  For this demonstration I chose the Nokia E71 because Codename One does not include any simulators for any Symbian S60 or QWERTY devices at this time.

#-- skin.properties for Nokia E71
touch=false
smallFontSize=10
mediumFontSize=12
largeFontSize=14
systemFontFamily=Arial
proportionalFontFamily=SansSerif
monospaceFontFamily=Monospaced
# Valid values (from com.codename1.ui.Display)
# 0=UNKNOWN, 1=NUMERIC, 2=QWERTY, 3=VIRTUAL, 4=HALF_QWERTY
keyboardType=2
softbuttonCount=2
# This sets User-Agent (See com.codenameone.impl.javase.JavaSEPort)
# Valid values: and, ios, rim, me
platformName=me
overrideNames=me,phone,symbian,s60
nativeThemeAttribute=codename1.j2me.nativeTheme
# color table mapping to key codes, each color starts with the letter c (lower case!) followed by the "web color"
# for hex values for keycode start with the lower case x.

# Use the app from the previous post to help find keycodes for your device
# soft buttons, pickup, hangup
cff0000=-6
cff0001=-7
cff0002=-10
cff0003=-11

# home, calendar, addressbook, email
caa0000=-12
caa0001=-13
caa0002=-14
caa0003=-15

# dpad (north, east, south, west), gamefire
c770000=38
c770001=39
c770002=40
c770003=37
c770004=32

# Q W E R(1) T(2) Y(3) U(*) I(+) O P  
cffff00=113
cffff01=119
cffff02=101
cffff03=114
cffff04=116
cffff05=121
cffff06=117
cffff07=105
cffff08=111
cffff09=112

# A S D F(4) G(5) H(6) J(#) K(-) L BACKSPACE
cffff0a=97
cffff0b=115
cffff0c=100
cffff0d=102
cffff0e=103
cffff0f=104
cffff10=106
cffff11=107
cffff12=108
cffff13=-8

# Z X C V(7) B(8) N(9) M(0) ,(;) .(:) ENTER
cffff14=122
cffff15=120
cffff16=99
cffff17=118
cffff18=98
cffff19=110
cffff1a=109
cffff1b=44
cffff1c=46
cffff1d=10

# ALT SHIFT @(/) SPACE '(&) ?(!) CHR(CTRL)
cffff1e=112
cffff1f=-50
cffff20=64
cffff21=32
cffff22=39
cffff23=63
cffff24=00

Building a loadable skin file

A skin file is simply a zipfile with the extension of .skin.  The following is a simple Ant build file that will build the skin as the default target:

<?xml version="1.0" encoding="UTF-8"?>
<project name="Nokia-E71" basedir="." default="skin">
<target name="skin">
   <zip destfile="bin/${ant.project.name}.skin"
      basedir="src"
      includes="**/*.png,**/*.ttf,**/skin.properties,**/*.res" />
</target>
</project>

Using the new skin

Simply fire up the device simulator, click Skins, Add,and select your newly created skin.  The simulator will restart with your new skin loaded.

Conclusion

This demonstration includes about the bare minimum for a skin.  There are a few more files that can be included in a skin including a resource file, a header.png/header_l.png (the notification bar). and truetype font files.  To get a better idea of the properties available to the skin, see the com.codenameone.impl.javase.JavaSEPort file from the Subversion repository.  I hope to see some cool new device skins contributed to Codename One!

The Nokia E71 skin files from this demo can be found in the Vase API.

UPDATE: I’ve added a bunch of new skins to the Vase API.  The full list now includes:

• Nokia E71 (Symbian S60, non-touch, QWERTY, 320 x 240)
  
• Samsung Galaxy Nexus (Android ICS, 720 x 1280)
• Motorola Dext/Cliq (Android 1.5 QWERTY slider, 320 x 480)
• LG Viewty KU990 (Symbian, touch, 240 x 400)
• Nokia 2760 featurephone (Symbian, flip, 128 x 160)
• Blackberry Bold 9790 (BBOS7, touch, qwerty, 480 x 360) (not yet complete)
  
• Blackberry Curve 8320 (BBOS4, qwerty, 320 x 240) (not yet complete)
• Coby MID7012  (7″ android 2.3 tablet, 480×800) (not yet complete)
• Samsung Nexus S (Android 2.3/4.0, 480×800) (not yet complete)
• Samsung SGH-A747 featurephone (Symbian S40, flipphone, 172 x 220) (not yet complete)

Disclaimer

I am in no way affiliated with the Codename One project aside from being satisfied user.

Like this post?

If you like this blog posting, please don’t forget to click the Like buttons. Also, you can send comments to the Codename One Discussion Forums, I check there fairly regularly.

Futher Reading

Take your Gimp skills to the next level with the following products:

Create your own device simulator skin using Gimp