Wednesday, October 19, 2016

Developing Garmin SmartWatch Apps with ConnectIQ Platform-Part 2

This is part 2 of blog series that covers a tutorial on developing Wearables App for Garmin SmartWatches. In this part of the tutorial we will write the logic to display Meeting Alerts in the watch widget that we created in part-1 of this tutorial.

Lets create a Monkey-C class called in the CalendarAlerts ConnectIQ Eclipse Project. MeetingAlert class will represent a single MeetingAlert record that we will receive from the Android Device over BLE.

using Toybox.System as Sys;
class MeetingAlert {

  //mTime - meeting time
  //mDate - meeting date
  //mSubject - meeting subject
  //mLocation -meeting location
 hidden var mTime, mDate, mSubject, mLocation;

 function getMeetingTime() {
  return mTime;
 function getMeetingDate() {
  return mDate;
 function getMeetingSubject() {
  return mSubject;
 function getMeetingLocation() {
  return mLocation;

We can assume that the calendar event details are received from Android Device whenever the watch synchronizes with phone over bluetooth. As mentioned in part-1 of this blog we will use comma separated string values to exchange data. Hence we are assuming that the Android Device will send us the calendar events in the following CSV format

           mTime, mSubject, mLocation, mDate

    mTime - is the meeting time
    mDate - is the meeting date
    mSubject - is the meeting subject
    mLocation - is the meeting location

When we receive a message containing the above mentioned CSV string we will parse it and create a MeetingAlert Object. So to parse it we will add a method called initialize() in MeetingAlerts which will accept a CSV string of meeting record and populate the mTime, mDate, mSubject and mLoaction variables in the MeetingAlert Class.

function initialize(eventData) {
     var i=eventData.find(",");
      mTime = eventData.substring(0, i);
      var leftOver = eventData.substring(i+1, eventData.length());
      mSubject =leftOver.substring(0, i);
      leftOver = leftOver.substring(i+1, leftOver.length());
      mLocation =leftOver.substring(0, i);
      leftOver = leftOver.substring(i+1, leftOver.length());
      mDate =leftOver;
      Sys.println("mTime" + mTime +" mDate "+ mDate + " mSubject "+ mSubject+" mLocation "+mLocation);

In the above method we are trying to parse the comma separated calendar event record String (eventData) and assign the comma separated first value to mTime, second value to mSubject, third value to mLocation and fourth value to mDate variable.

Now lets expand the folder named "resources" in our CalendarAlerts project. You can see that it has an "images" folder and a "layouts" folder. The images folder is the place where you keep all your
 the images that you would like to use in your app. and the layouts folder has a file called layout.xml which defines the layout of the UI components that you will use in your app. The project structure at this point would look as in the screenshot on the left.
Now if you open the layouts.xml you can see a bitmap tag which has a file name as shown below.

bitmap filename="../images/monkey.png

This bitmap tag is responsible to render the image of monkey in the center of the default view that you see when the app is launched(check by launching in simulator). Since we don't need it for our app we can remove it. 
Now open the class. This is our main application class which extends Toybox::Application::AppBase and is the entry point of our application. Notice that ToyBox.Application is aliased as App in the first statement using Toybox.Application as App; This is very similar to import statements that you use to import Classes/Packages in other languages like Java. See class definition below.

using Toybox.Application as App;

class CalendarAlertsApp extends App.AppBase {

    //! onStart() is called on application start up
    function onStart() {

    //! onStop() is called when your application is exiting
    function onStop() {

    //! Return the initial view of your application here
    function getInitialView() {
        return [ new CalendarAlertsView() ];


As mentioned in the code comments you can do operation that you want to do on startup of the app in the onStart() method. If you want to perform an operation on exiting the application, that needs to be written in the onStop() method.  The function getInitialView returns the first view to be shown to the app user, in our case it is the CalendarAlertsView.

Now lets create CalendarAlertsView and add something to it. The basic structure of will look like this
using Toybox.WatchUi as Ui;
using Toybox.WatchUi as Ui;
using Toybox.Graphics as Gfx;
using Toybox.System as Sys;
using Toybox.Communications as Comm;
using Toybox.Attention as Attention;
using Toybox.Timer as Timer;
using Toybox.Lang as Lan;
using Toybox.Application as App;
using Toybox.Time as Time;
using Toybox.Time.Gregorian as Calendar;
class CalendarAlertsView extends Ui.View {
     //a string message to be shown on the screen
       var displayString ="None in next 15 mins";
   //! Load your resources here
    function onLayout(dc) {
    //! Called when this View is brought to the foreground. Restore
    //! the state of this View and prepare it to be shown. This includes
    //! loading resources into memory.
    function onShow() {
    //! Update the view
    function onUpdate(dc) {
        // Call the parent onUpdate function to redraw the layout
         //Set the foreground and background color of graphics    
              dc.setColor( Gfx.COLOR_WHITE, Gfx.COLOR_TRANSPARENT );
         //Set text that we want to draw at a given top,left location on the screen
  dc.drawText(10, 20,  Gfx.FONT_MEDIUM, "Upcoming Meetings:", Gfx.TEXT_JUSTIFY_LEFT);
dc.drawText(10, 50,  Gfx.FONT_MEDIUM, displayString, Gfx.TEXT_JUSTIFY_LEFT);
         //Refresh the UI with changes that we did above
    //! Called when this View is removed from the screen. Save the
    //! state of this View here. This includes freeing resources from
    //! memory.
    function onHide() {

This should display an output like as shown in the image below.
I am assuming that the comments in the source code are self explanatory. As you can see that in the onUpdate() method we are trying to draw texts on the UI using dc.drawText(). Here the object dc represent the Device Context of the wearable device and is an object of Class: Toybox::Graphics::Dc. This class has few more methods to draw different kind of graphical shapes or text. In the end of this method we requested a UI update by calling UI.requestUpdate() which indirectly request the UI update from the current View by calling onUpdate(). At this point we are left with receiving the calendar data from mobile and displaying it 15 mins prior to the meeting time in our watch. Now lets set up the infrastructure to receive messages from the mobile app and setting up a timer which checks for a meeting occurrence at regular intervals. If you refer to the documentation of Class: Toybox::WatchUi::View there is a method called initialize() which acts as a constructor. Which means we can add a method called initialize in CalendarAlertsView class which can initialize the basic stuff like setting up the communication infrastructure and initializing the timer to scan upcoming meetings. So lets add this initialize() method to
       var count=0;
       var meetingsArray= new [100] ;
       var timer;
       var app;

   function initialize() {
              // when a message is received over Bluetooth LE it would be received by the onMail method described below
              Comm.setMailboxListener( method(:onMail) );
              //this method is described below
              timer = new Timer.Timer();
              //the method checkForUpcomingMeetings will be called at an interval of every 30 seconds
              timer.start( method(:checkForUpcomingMeetings), 1000*30, true );

  function checkForUpcomingMeetings() {
          Sys.println("Checking for meetings");

  function onMail(mailIter)
         var  mail =;
        while( mail != null )
           //the variable 'mail' would contain a comma separated information about each meeting, create a MeetingAlert object out of it
            var meetingAlert = new MeetingAlert(mail);
           // store the meeting alerts for next 3 days stored in an in-memory array of MeetingAlerts
            mail =;
        return true;
The method initialize() registers onMail() method as a mail box listener by calling Comm.setMailBoxListener. Mail box is a virtual place where messages sent over Bluetooth LE will arrive and on receipt of the same it invokes the listener method - in our case the onMail() method. Then we create a Timer which executes a method checkForUpcomingMeetings at a regular interval of 30 seconds. The Timer works in a similar way as setInterval method in Javascript or a TimerTask in Java. Right now the method checkForUpcomingMeetings just prints a single statement "Checking for meetings" on the console. However if you try to run this, your app wont start because you need to grant the necessary permission to the app for communicating over Bluetooth LE which can be done by adding following lines in your manifest.xml file.
If you run your application now it should show the watch app with a message "Upcoming Meetings - None in next 15 mins" and should print "Checking for upcoming meetings" every 30 seconds.
In next part of this tutorial we will setup our Android app to pass on the meeting information over Bluetooth LE to our watch widget.

Thursday, June 30, 2016

Developing Garmin SmartWatch Apps with ConnectIQ Platform-Part 1

Recently I was involved in developing apps for Gramin Wearables. Being new to the wearables world I found it relatively easier to develop apps for Garmin Wearables then what I had thought earlier. Hence I would like to share my experience via this blog series. I will take you through the step by step process of developing a simple watch widget that synchronizes with an Android phone's Google Calendar to send out meeting alerts and reminders on your Garmin Watch.

Apps for Garmin Wearables are developed using the Garmin ConnectIQ SDK  and are programmed using Monkey C language . You are already familiar with Monkey C if you are familiar with languages like Java or Objective C. Introduction to Monkey C language  highlights the basic difference between other languages and Monkey C. Its a short and precise tutorial, I would suggest to give a quick read in case you are planning to develop apps for Garmin.

The Problem Statement
Lets say you own an Android Phone and you have configured your Google Calendar to show meetings,events or reminders from your Google Account or may be MS Outlook using exchange services. The watch widget that we will develop will be responsible to send out alerts for these calendar events 15 minutes prior the event time, on your Garmin Watch.

The Basics
Before we proceed further, you need to know a few things that are applicable to the Wearables world.

  1. Most of the wearables does not have direct access to internet. Especially those which don't come with a SIM card slot. Same is applicable to Garmin Wearables.
  2. Communication with a web service over internet is only possible if a communication channel is established with a SmartPhone (Android or iOS) over Bluetooth LE protocol.
  3. Garmin comes with Android and iOS Mobile SDK's that helps you communicate with your mobile device easily.  These SDK's can be used to exchange data over Bluetooth Low Energy(BLE) with your phone easily and watch vice-versa.  The Android SDK is just a  JAR file to be included as part of your Android Project, which contains a bunch of Classes that helps you send and receive data over BLE.
  4. If you are capturing activity data using wearables then you need to store it into a temporary store until the user sync's the wearable device with a smartphone that can establish an internet communication to upload data over to web service. The storage space on wearable device is limited so you need to take care that the format of stored data is as precise as possible. Storing in XML is not a preferred way as the format is too verbose. JSON is still okay only if required. I would prefer comma separated string values or enums. 
  5. Same concept applies while transferring data from a Mobile phone to a watch. Bluetooth Low Energy is relatively slower, the amount of time taken to transfer a bigger chunk of data will take long. I would prefer comma separated strings over other formats here as well.
  6. Using Garmin SDK you can create different type of apps viz. a watch widget, a watch face, a data field or a watch app. Watch faces are the ones which are responsible to show time, you can choose to develop a customized watch face which is more graphically attractive however a watch face doesn't have access to communication API's to communicate over BLE or to access sensor data recorded by inbuilt sensors of a watch. A watch widget is like a card that resides on your main watch carousel it has ability to communicate over BLE with your smartphone and process data in background, it also has access to sensor data. Watch Apps are accessed on request basis and have much wider permissions as compared to a watch face and a widget, it can read data from ANT+ sensors. Data fields are basically apps that present captured activity data of a user in a creative way.
 As part of this blog series I am gonna create a watch widget to show calendar alerts which beeps and flashes the meeting/event details 15 minutes prior to the event time.
Setting up the environment
I am using Eclipse IDE with the ConnectIQ Plugin to develop the Garmin Watch App/Widget and Android Studio for developing the corresponding Android App. The ConnectIQ Eclipse plugin can be installed using the Eclipse update site For more details see

Jumping Right In
 Assuming that you are done setting up the environment. 
  1. Create a new ConnectIQ Project in Eclipse as shown in the screenshot below and lets name it CalendarAlerts.

  2. Choose the Project type as "Widget" and select appropriate target platforms.
  3. Select the default project template and click next.
  4. Select the supported languages for your app/widget.
  5. Click Finish to see the project created in the project explorer in Eclipse.
  6. To verify, run the project by Right Click->Run As-> Connect IQ App
  7. Choose Appropriate Device to Simulate
  8. You should see a widget displaying image of a monkey in the ConnectIQ Device Simulator.
At this point you should be done setting up everything that is required to start working on the actual app. In the next part of this blog series, we will modify this app that we just created to do what we described in the problem statement above.

Monday, May 2, 2016

Building Secure RESTful Webservices

Recently I delivered a webinar on "Building Secure RESTFul Webservices" on Techgig which received a very good feedback based on the Techgig survey. The webinar column was published on Gizmodo India as well.

Here is a list of key takeaways from the webinar

  • How HTTPS work in detail and how to implement HTTP BASIC Authentication.
  • What is Mutual SSL Authentication and how to implement it.
  • What kind of damage can be done with security attacks like Man in the Middle and Replay Attack. 
  • Authenticating user without passing credentials over the wire
  • Preventing Man in the Middle attacks using Signature verification
  • Preventing Replay Attacks using timestamp and cryptographic nonce
  • What are OAuth 1a and OAuth 2

The code samples (written in Java) related to this webinar can be found at 

I am embedding the webinar recording for quick access below.

Building Secure RESTful Web Services from Techgig on Vimeo.

Saturday, November 1, 2014

Web Service Security and Native Mobile App User Authentication

In this article I am going to throw some light around web service security,  user Authentication  for native mobile applications and how both the topics are connected. Me along with my cool team members at Zycus were working on the same off lately. The idea is to highlight the fact that it is ideal to implement web service security by being agnostic to the type of web service clients (like mobile apps) but these decisions may impact the mobile app user authentication process.

If you are working on a mobile application that requires user authentication and fetching data from a server side application then it is highly likely that you are exposing certain functionality of your server side application via web services that can be accessed over the web by your mobile application.

While developing such applications you will usually encounter following challenges.
  1.  How to secure the web service endpoints?
  2.  How to authenticate users from the mobile app in secure way?
  3.  How to ensure that mobile app does not bundle or store any sensitive information which can result into illegal access to server side data by compromising access to web services.
How to secure the web service endpoints?

If I have to forget about the Mobile Application for a second and just answer this question from web services security perspective, then I would answer it in following way. Discussing each security method in detail is out of the scope of this article hence I have provided hyperlinks to references that I used while taking such decisions..

Public-ally hosted Web Services, if not properly secured, are mostly vulnerable to Man in the Middle, DoS, and Replay Attacks.

As data passing over HTTP is not encrypted and can be sniffed and modified by someone in middle, plain HTTP based web services are vulnerable to Man in the Middle attacks. To tackle this, you need to make sure that web services are exposed only over HTTPS and they are not accessible via HTTP.

To harden the endpoints further you can choose to implement Mutual SSL Authentication. Mutual SSL Authentication ensures that the web service client knows that server is trusted and the server knows that the client is trusted by verifying each others certificates during the SSL Handshake.

Tackling DoS or Distributed DoS is not that easy as well. If you are using a web server like Apache then you can enable Mod_Security and Mod_Evasive rules to deal with DoS and DDoS or implement your IT infrastructure monitoring using Nagios.

Simplest way to tackle Replay attacks is by asking for a timestamp and a cryptographic nonce value as part of the HTTP request header. For simplicity timestamp can be enforced to be passed in UTC timezone. Server can verify the timestamp and check whether the request was initiated by the client not before a threshold value of say 5 minutes. Server can also verify a given nonce value and store it for certain amount of time so that any given request with same nonce should not be served again and should be discarded by the server.

How to authenticate users from the mobile app in secure way?

There are multiple solutions available and documented on the web. Each of them are best in their own way. I have seen many applications use the following approaches.
  1. OAuth2: Authorization Code Flow
  2. OAuth2: The Resource Owner Password Flow 
  3. Custom Implementation
OAuth2: Authorization Code Flow  

This could be one of the best ways out there but I am not so much in favor of using this approach. The reason is simple, it requires your app to do the OAuth Dance. Which will require opening up an embedded browser like WebView or UIWebView and take the user to the actual web application where the user can key in the credentials and is returned back with an access token once he authorizes the mobile application on his behalf to access the resource via web service calls. Mobile App can use the access token till the time it expires and carry on with accessing the user's data on behalf of the user. This model fits in well when the Mobile Application is using services provided by a third party web application., like you creating your own mobile Twitter App. In that case the end user using your version of Twitter App should authorize your App by indicating Twitter to allow your App to access resources on user's behalf.

If you our your company are the owners of both the web application and the official mobile application then this approach does not fit well.

OAuth2: The Resource Owner Password Flow 

This approach fits in well in a scenario where you or your company are the owner of the web application (or the API's exposed) and you or your company is planning to implement an official Mobile App for the corresponding web based application.

Actually OAuth was primarily created for a different purpose. Let me point out that "OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner". Hence it is not a way to secure your web services but rather a way to authorize 3rd party web service clients like
  1. a mobile app developed by someone else (not by you or your company)  but using your web services
  2. or a 3rd party developed Web 2.0 widget embedded in a 3rd party web application accessing resource provided by your application.
  3. or a 3rd party web application accessing resources provided by your application
The Resource Owner Password Flow  of OAuth was just specifically created to provide a solution to handle this scenario.

It is advisable to go with this approach if you have enough time to implement an OAuth Provider which adheres to the specification.

Custom Implementations
I was actually searching on internet for quite some time to find out an easily understandable and well documented open source library which could help us implement an OAuth Provider which adheres to resource manager password flow specification. Although there are many libraries out there but either proper documentation was lacking or it was getting a bit difficult to understand.

I found a very good resource here which mentions about doing a custom implementation some what similar to OAuth resource manager password flow specification and it helped me to get started.

All right, so here I am going to explain the approach that we decided to go with.

So first of all, lets break down the problem statement into smaller problems.

We need to take care of following things
1) Secure the Web Services from Man in the Middle, Replay attacks and DoS attacks
2) Provide a secure way to authenticate users for my mobile app

Securing the Web Services from Man in the Middle attacks, Replay attacks and DoS attacks

To prevent man in middle attacks we decided to expose the RESTful web services over HTTPS so that the data transferred is encrypted.

However we wanted to harden the  web service endpoints further. The option we had was to use Mutual SSL Authentication. But wait, Mutual SSL Authentication requires Client Certificates (including the private keys) to be shipped along with the web service clients like mobile app.

Here is the mantra "any private keys you store in your mobile app is accessible to an attacker. " Each web service client (like a mobile app) should have it's own certificate and key pair, to prevent security being compromised.

Your server should also enforce protections, ensuring a compromised client can't just request anything. I am sure that there will be mobile applications which stores private keys and the corresponding server invalidates the compromised keys.

We didn't wanted to get into the certificate distribution problem and then decided to go with the digital signature verification. So here is how the digital signature verification works.

Tackling Man in the Middle attacks
  1. The client sends a request to the server over HTTPS
  2. In the request a custom HTTP header is passed with header name as x-signature
  3. The x-signature header value is a message digest of a concatenated string prepared by concatenating the request URL+HTTP Method+alphabetically sorted request headers and their values in lower case+Data within the message body
  4. We used HMAC SHA1 algorithm to create this message digest
  5. Once the request is received by the server the server generates another HMAC SHA1 signature based on message digest of the concatenated string prepared by concatenating the request URL+HTTP Method+alphabetically sorted request headers  and their values in lower case+Data within the message body
  6. Server then verifies the generated signature with the one passed by the web service client
  7. If both the signatures are equal then it means that request was not modified by anyone in the middle.
Tackling Replay Attacks
  1.  We introduced 2 additional headers custom headers x-nonce and x-timestamp which are to be passed by any web service client
  2.  x-nonce request header needs to have unique value generated by the web service client preferably a  secure random, server would then store this secure random for a limited time for a month or so and choose not to serve any other request having the same nonce value.
  3. x-timestamp request header contains value of a UTC time stamp of the time when the web service client initiated the request. The server cross checks passed time stamp with the server time and determines whether the request was not initiated by the web service client prior to a threshold value of 5 minutes. If the request was initiated prior to 5 minutes from the current server time then server would discard the request.
  4. Server can optionally choose to block those IP's from which replay requests are detected.
Tackling the DoS Attacks
Our web servers were fronted by Apache web server and we already had the Mod_Security and Mod_Evasive rules implemented along with infrastructure monitoring using Nagios in place. Hence we were not much worried about this.

So by this point we had a straight forward web application acting as an REST API Resource server with services secured using the above mentioned approaches. However we were left with mobile user authentication.

Mobile User Authentication

First of all we decided to maintain a registry of the web service clients who are authorized to consume the web services. If customers of our product are willing to consume our REST API's then they are required to register their web service clients with us which is possible only if they are licensed to use our products. On completion of registration form an application id is issued to user which can be used as part of the authentication process.

We decided to setup a new web application which will act as a REST API Authentication Server for authenticating the users willing to consume the REST API Resources from the Resource Server.

We decided to implement the authentication process in such a way that the consumer of the REST Resources from the Resource Server is supposed to obtain an access token from the Authentication Server prior to accessing any resources from the resource server. This access token should be passed in the x-access_token request header while issuing any calls to the Resource server. The validity of  access token issued by the Authentication server is for next 8 hours, which on expiry should be obtained again by going through the authentication process again. Here is how the user authentication was implemented.

  1. The web service client needs to pass the Application id (issued after application registration) in the x-application_id header with user id in the x-userId header along with x-signature, x-nonce and x-timestamp headers.
  2.  Auth Server validates the Application id and the User id with the user management module of our application. It checks whether the user is active and it exists in our database at this point. If the user exists and is active then a challenge is generated by the Auth Server and the value of this challenge is sent back as part of the x-challenge response header. The challenge generation process is mentioned below.
    1. First of all generate a secure random  (which will be the answer of our challenge).
    2. The generated secure random should then be AES Encrypted using the user's password as a key
    3. The encrypted value of the secure random is our challenge which the client needs to decrypt using the user's password and send back for verification.
  3. Client receives the challenge as part of the x-challenge response header and is supposed to AES decrypt it using the user's password.
  4. After decrypting it the client is supposed to issue another request to Auth Server with x-challenge_answer that contains the challenge answer (the actual secure random value) along with x-application_id, x-signature, x-nonce and x-timestamp.
  5. The server then verifies whether the answer of that challenge matches with the original secure random value or not. If yes then an access token is returned as part of the x-access_token response header.
  6. After receiving the x-access_token response header the web service client can use the token value along with x-signature, x-nonce, x-timestamp and x-application_id to access the resources for next 8 hours.
  7. On expiry of the access token the web service client is required to issue another call to Auth server

Hence the Mobile App User Authentication would look as depicted in the diagram below.

Also it is good Implement Certificate Pinning in your mobile application that accesses the web services.  This ensures that your mobile app trusts only the server that it is supposed to connect to by using the hard coded server certificate and ignoring the device's default trust store.

Hope this article would help others trying to do similar kind of implementation. Your comments and suggestions are welcome.

Recently I delivered a webinar on Building Secure RESTful WebServices on Techgig. The Webinar recording can be found here. It also has link to code samples of the custom implementation of securing web services described above.

Wednesday, May 26, 2010

Yet another JavaFX App !

This application has won the RIA Exemplar Challenge Award organized by Java Champion Jim Weaver, Stephen Chin and Jasper Potts check the winner announcement here and here

Being a Java EE developer,I am always attracted towards the "grass on the other side" :P . I have been working on a JavaFX app, which tries to solve a typical engineering problem of loading cargo containers to a BeechCraft 1900C cargo airplane. Although the aircraft data and equations are taken from the authentic FAA weight and balance handbook (see Chapter 7 , page 60) , this application is not intended to be used for realtime cargo loading as it is just for JavaFX demo purposes and does not guarantee the accuracy of data and calculations. I must say again, being a newbie to the language its fun to learn JavaFX. Although I still regret not visiting Amy Fowlers blog post during the early stages of this app . Shown below is the screen-shot of the work done till date. Shown on the upper left side of the screen-shot are cargo containers which are supposed to be loaded on the horizontal cross section of Beechcraft main deck shown on the center-top. The parallel red blocks denotes left and right position of sections where cargo containers can be placed. Just below the red blocks is a scale which shows the section names and their distance in inches from a reference point referred as 'Datum' which in our case is aircraft's nose. So starting from Nose at 0 inches from datum , the tail of the aircraft is at 533 inches. The cargo containers are of different weights which can be seen by a mouse-hover tool-tip. User can drag these containers and place it on the aircraft's deck , which recalculates the center of gravity of the aircraft. The line chart on the lower right is Weight vs CG chart.It is actually combination or 3 overlapped line charts, One is in which the polygons are drawn, 2nd is with no data , but with X and Y axis on opposite sides, and the 3rd one contains just one yellow dot. The polygons drawn inside these charts are operational center of gravity limits defined by aircraft manufacturer. The yellow dot in the chart denotes the current center of gravity of the aircraft which gets updated when you place a container on the deck, The yellow dot(CG) should fall within these polygons (operational limits), otherwise the aircraft is either nose heavy or tail heavy. The data grid in the center is the XTableView control from JFXtras library (they have some nice controls and utilities for JavaFX). Parameters in this table are dynamically updated when the container is placed on the deck . The pie-chart on the lower left shows the total traffic weight of an aircraft by showing weight covered by each section of the deck. You can also click on these charts to get a larger view. Double click the dropped container to revert it back from the deck to the container panel. Just below the Main Deck is a JavaFx Toolbar component which contains normal and toogle buttons styled using an external CSS file. A user can revert back all the placed containers by clicking on the "Reset Containers" button. The animation on drag-drop can be toggled using the "Disable Animation" button on the toolbar. By default weight of each cargo containers can bee seen on the tool-tip displayed by the mouse-hover, optionally one can choose to quick view/hide weights on the containers by toggling the "View Weights" . Do check out the help and about buttons for more information about the application.

I am improving this application when ever I get free time and I will be updating the source code to JFxtras repository to ensure its compatibility with future releases of JavaFx Please let me know your valuable feedback.

Thursday, February 18, 2010

My first experience with JavaFx Charts

In one of my previous projects I was involved in developing a 2D line chart which shows the center of gravity of large cargo aircrafts like Airbus A380 and Boeing 747 etc .We used Java2D with more than a thousand lines of code and Richfaces paint2D to draw it as an image on a JSF web page .Being a newbie to the language, I was just wondering how much effort can it take to develop such a chart in JavaFx . I finally managed some time to try it out. So this chart is a Weight vs. Index chart where weight of the aircraft is on the y-axis and change in center of gravity index is on the x-axis. The polygons drawn inside the chart reflect the structural limits of an aircraft. If your current (index,weight) point falls outside these polygons in a certain condition, than the aircraft cannot fly because it is either nose-heavy or tail-heavy so it will crash.

I was able to create the chart shown in the image above with almost 105 lines of code excluding the data inputs,in almost 3 hours. JavaFX charting takes care of drawing axis and tickmarks, tickmark gaps, axis and axis-label gaps, scaling factors, title, legend attributes and many more things like anti-aliasing and drop shadows. You just need to bother about configuring it and providing the chart data.

Launch it here. Launch Image

Download source code

Sunday, November 22, 2009

Bye Bye Zembly :(

This is in the memory of my favourite social programming platform Zembly which was an interesting attempt of Sun Microsystems making easy writing the applications for social platforms such as Facebook, Orkut, Meebo, OpenSocial and the iPhone by sharing services and widgets with the developer community. One of my blog post posted earlier this year, has a JavaFX Piano widget hosted on Zembly , and one of the JQuery games which I couldnt manage to finish :( . So far I dont know clearly why its being shut down, below is an excerpt from the mail which I received from Sun.

"We regret to inform you that on November 30th, 2009 we will be suspending this service.

More than three years ago, we started this project with the goal of making it easy to create next-generation Web apps. Our original tagline was "Build the web, using the web," and the ideas we were incubating around platform-mediated Web applications, Web API mashups, and social programming were brand new.

We learned a lot along the way. Your confidence and enthusiasm helped us improve the project and do amazing things that we never imagined when we began this journey.

Thank you to everyone who's been with us through the ups and downs. It's heartening to see that many of the best ideas pioneered in zembly have started to appear elsewhere. With your support, we're proud to have contributed to the DNA of the Web. "

All I want to say to the Zembly team is that,hats off to you people, you guys built an incredible social programming platform. I had learned a lot by cloning widgets contributed by you guys.