I am converting the Java WebStart JIDE CellSpanTable based appointment scheduler to the iPad. It has a slightly different purpose on the iPad but needs to display the appointments in almost an identical way. The Java desktop application was recently converted from MigCalendar to JIDE CellSpanTable by me. I was pretty happy with the results but now I am thinking of refactoring it again.
Why bother? First there are some limitations to the CellSpanTable. I am using a JXLayer to get around some of them. That allows me to paint on top of the grid to show the current time line and for Drag and Drop support. Things are a little screwy when I attempt to scroll to a starting position in the grid. When I do that some of the paint offsets are incorrect. I have made all the adjustments in the code to handle this conflict between the JScrollPane and the CellSpanTable.
I also have issues with the time margin not fully painting in sync as you scroll the grid vertically. When you stop dragging the scroll bar everything lines up, just during the drag there is a stutter. This sort to thing always bothers me.
Since I am spanning cells based on appointment durations I can only pick one background color for the full cell span. This means if the appointment starts before normal business hours the spanned cells all get the "business is closed" background color which is not accurate. I also don't get the grid lines painting across any cell that has a spanning appointment.
I have to track extra information for cell spanning and the code is a bit difficult to grasp every time I look at it. I hate code like that. It is complex because it is not an easy process but it is hard to explain why I did what I did to make it work.
When I converted the code to the iPad I did not have a 3rd party grid control to help me out. The nice thing is I was able to concentrate on doing my own grid because I already knew how to do all the other appointment painting, time margin painting etc. I knew all the limitations of the JIDE grid that annoyed me. I was not overwhelmed with the full rewrite of something that I did not fully understand so I could initially concentrate on the grid. In fact I was forced to concentrate on how to get a grid to paint, there was no easy way out. I did some searches on the web just to make sure someone did not have a workable solution but I did not find anything to fit my needs.
I have written many a custom control so I was not afraid to tackle another one. I was able to use Quartz on the iPad to manually paint the grid and all the appointments. I solved numerous issues I had with the JIDE grid while coding the new control. I am fully in control of all the painting. I don't have any scrolling sync issues. I don't have to use an overlay painter - I paint things in the Z order I need. I am not using a grid data storage system that does not completely apply to what I am attempting to do. There are no scrolling coordinate offset issues.
This is not a generic cell spanning grid control for the iPad. This is a highly optimized grid for the purpose of painting an appointment schedule. Not that I couldn't take some time to make it more generic. My goal was to get something running that was super optimized for my painting needs. I want a very responsive UI for this application. I also will convert this to the Android platform in the near future. It should be a fairly straight forward port.
Based on the painting I did on the iPad I have already improved the look of the PC Java code. Taking a second look at things and being under less time pressure I was able to come up with a nicer look to the appointments with the start / end time in a darker color to visually highlight them to the user. I also drew a pointing ball in the margin to visually enforce the location of the current time line that can get a bit lost in the grid especially the current time falls on the hour. Just adds to the professional feel of the app.
I don't have the issue with grid lines not painting as I paint them first then overlay the appointments. The proper background color is painted for the cells too since that happens independent of the appointment paint.
The appointment memory storage is much cleaner because I am not taking what I need and forcing it into the memory layout of the grid so it can ask me to paint the appointments as it is painting each cell. Using Quartz I just paint my layers - verifying that what I am painting is visible on the screen based on paint offset and component size - avoiding all sorts of callbacks and other overhead.
On the PC your scroll with the scroll bars but on the iPad you scroll via touch. I really like the way touch scrolling works on the iPad and I miss it every time I run the PC app. I keep trying to click drag the PC app just like I do on the iPad simulator. Maybe I will have to implement that on the PC too!
Other than the auto-scrolling of the grid as you drag and drop an appointment I think the conversion will be pretty easy. The JIDE CellSpanGrid did the auto-scrolling for me. Not like this is some super secret magic bit of code, just need to write it up and make sure it feels right when it is done.
I am looking forward to tackling this on the PC then again on for Android devices. I am sure I will optimize it just a bit more on each one. The first time you write code it always stinks, you have too big of a picture in your head. On the rewrite you can concentrate on the minutia. You are basically doing a code review of your own work as you convert your logic to each language / platform.
There was a lot of learning around Quartz during this project. Sure I will learn more about Graphics2D under Java too. I have used it enough to have a pretty solid grasp there but something new pop-ups with each project.
No comments:
Post a Comment