Telerik blogs
With the Q3 2014 release, we introduced quite a lot of new functionality to our Android tools. Since then, we gathered some great feedback from developers that helped us better shape the product for the regular Service Pack.

The Q3 2014 Service Pack 1 comes with many Calendar and Chart optimizations. 

You will find this post useful, especially if you’re using or planning to use our Calendar component in your app. The calendar has gone through a major optimization process due to the new features in transitioning between screens and the animations system. 

Calendar

New Features and Optimizations: We revisited the structure of the calendar in depth. We decreased the creation of new elements to a minimum and replaced with caching and reusing of already present objects to minimize memory demand and avoid the garbage collection from occurring too often.
  
Scroll Modes: The Calendar now supports a range of different scroll modes and additional features for customizing them, including animation speed, snapping, flicking, panning and more.

Unable to display content. Adobe Flash is required.

Setting a different scroll mode happens by using the Calendar’s setScrollMode method.

The ScrollMode enumeration supports several effects.

Customization of Elements: Customizing the Calendar has been made easier through a wide spectrum of properties and settings for customizing of the calendar elements. These include but are not limited to:
  • Changing text positions for the cells
  • Adding bitmaps
  • Controlling the colors of all elements such as background color for enabled and disabled elements
  • Alpha levels
  • Custom elements and more


All this can be achieved by calling the calendar adapter.

We revisited all calculations and optimized them for better touch and feel in gestures and animations. We added date caching to the date change events and presented date virtualization to ensure top speed while covering an infinite collection of dates in both past and future points of time. We addressed and replaced all invalidations with internal caching to reduce redundant calculations. We also improved animations and transitions for all display modes.

New Light and Dark Themes: We have enhanced the Calendar with Holo Light and Holo Dark themes.





Calendar Structure and Mechanics: One of the more noticeable changes is that the Calendar is no longer a ViewGroup. Previously, the Calendar was holding tables full of cells, where every cell was a View instance. This approach proved to be working at first, however, the new transitions demanded a more lightweight architecture. This led to stripping the calendar down to being a single View, holding information about the current dates.

If you’re manipulating Calendar cells in your code, you need to cast them to CalendarElement, as opposed to View.

Customizations: All customizations are now stored inside a CalendarStyle instance that is managed by the calendar adapter. All customizations, such as using a custom class for the calendar cells, are performed using the calendar adapter.

Deprecated elements. One of the deprecated elements is the GestureAssistant class, which no longer fits the structure and the mechanics of the calendar. Its functionality is redirected to the new GestureManager class, which also contains all the gestures logic of the calendar.

We will support the assistant for a short period of time and its properties will still have effect on the behavior of the calendar gestures handling, but they will have a lower priority than the ones of the GestureManager.
API Changes
  • The calendar is a single View now, and all the elements inside are custom classes. 
  • The CalendarCell class no longer extends the TextView but rather the CalendarTextElement.
  • Scenarios that were using View’s setBackground(Drawable) for setting the background of a cell now have to call setBackgroundColor(int, int), where the first parameter holds the value of the background for the active state of the cell and the second parameter holds the color of the inactive state. We do not recommend this to be applied to the cells manually, but via the calendar adapter. It offers methods such as setDateCellBackgroundColor(int, int) that will add the settings to all date cells and store them in case of recreation of the calendar (such as when changing between display modes).
  • All calendar elements have the arrange(int, int, int, int) method, where they get their dimensions instead of the onLayout(Boolean, int, int, int, int). The rendering is done using the render(Canvas) and postRender(Canvas) methods, instead of the onDraw(Canvas). This is all called from the main calendar instance at the time of arrange and invalidation.
  • We've changed the visibility settings to an enumeration value. calendarCell.getVisibility() was returning an int before, but now returns ElementVisibility.Visible,  ElementVisibility.Invisible and ElementVisibility.Gone, which behave the same way as the default ones.
  • The CalendarCell no longer holds the events but they are moved to the CalendarDayCell. getEvents() will work the same, however you must cast the cell to CalendarDayCell if it is currently a CalendarCell.

Chart

We also improved the Telerik Chart for Android during the period after the Q3 release. We improved the performance of the DateTimeContinuousAxis. The CartesianChartGrid now has setters for vertical axis and horizontal axis, which allows it to be used in a chart with multiple axes.

 We also made some fixes that were causing points to disappear while panning and zooming. The issue where the Chart was blinking when refreshed frequently is also gone.

API changes:
  • RadRect, RadSize, RadPoint are now immutable types 

You can download the latest bits from your Telerik Account or the product's download page




About the Author

Kiril Stanoev

Hi, I'm Kiril and I'm the Product Manager of Telerik UI for Android, Windows Universal and Windows Phone. Feel free to ping me on +KirilStanoev or @KirilStanoev

Comments

Comments are disabled in preview mode.