Telerik blogs
In part one of this three part series, we looked at RadAjax, RadCalendar, RadChart, RadCombobox, RadDock, and RadEditor running on the iPhone. We found most of those controls run relatively well on the iPhone with the exception of RadEditor. In this second installment, we'll look at another batch of RadControls and pass judgment on their usability. Each control will be deemed either usable, semi-usable, or unusable on the iPhone so that you can quickly tweak your applications (or build new ones) for iPhone users.

Today's lucky controls are RadGrid, RadInput, RadMenu, RadPanelbar, RadRotator, and RadSpell. During all of my tests with these controls, the iPhone's browser never crashed. That is great news and a testament to RadControl's ability to run on a "light" browser like mobile Safari without crashing it. Now, let's see how each of these controls performed on the amazing device we all know as "the iPhone".

  1. RadGrid: Usable
    That's right. The flagship grid component from Telerik works pretty well on the iPhone's mobile Safari. All of the "read-only" features work flawlessly and the Grid renders without any problems. More advanced features like paging, sorting, hierarchy, filtering, and even editing work, too. The only catch with the Grid on the iPhone is that some of the Grid's features are not well tuned for the "fat fingered" cursor. For example, it was very difficult to select page numbers precisely in paging demos and it took a few tries to get the filtering menu to display. The features work, they're just harder to use on the iPhone than on a regular computer. That said, many of these features could be tweaked with CSS settings and custom skins to adapt for the iPhone and improve the Grid's usability.

    Among the features that didn't work were obvious iPhone no-no's like drag to reorder columns, column resizing, double-click to edit, context menus, and static header scrolling. Many of these problems exist due to the nature of the iPhone's input device, but some are simple shortcomings of the browser. Either way, the broken features are peripheral to RadGrid's core operation and it earns an "usable" rating on iPhone 1.0.
  2. RadInput: Semi-usable
    RadInput produced mixed results on the iPhone. The core functions of the Input control work, but behavior can be erratic at times. For example, trying to type a credit card number into a masked text box accurately prevented non-numeric characters from being entered, but it also only allowed one number to be entered at a time (you had to manually move the cursor position). Clearly a bad problem. Meanwhile, the date input control performed more normally, accurately highlighting an invalid date entry. Due to the varying results of these tests, I'd suggest you use caution when including RadInput in an iPhone targeted page.
  3. RadMenu: Usable
    No problems here. RadMenu performed flawlessly on the iPhone and should be safe to use in any application that targets the device. All skins rendered correctly and it was very easy to use the iPhone's touch-based interface to navigate and select menu options. There is one caveat, though, and that is "mouse hover" behavior. If your menu depends on hovering to expand its options, those options will not be available on the iPhone since there is no way to "hover" your finger. Instead, design "click to expand" menus for iPhone targeted applications and you'll have no problems.
  4. RadPanelbar: Usable
    Like RadMenu, RadPanelbar performed almost flawlessly on the iPhone. There were no rendering problems and everything from hierarchial panels to sliding panels worked correctly. The only feature that failed (as it has across the board on the RadControls) is scrolling. No scrollbars were rendered in the control when panels had elements that were out of view, so that is something to avoid. Other than that, RadPanelbar is another safe tool to use in your iPhone development toolbox.
  5. RadRotator: Semi-usable
    RadRotator works, but it is plagued by the iPhone's slow processing of JavaScript animations. All RadControls with JavaScript animation run much slower on the iPhone than on a normal browser, but the effect is more detrimental in RadRotator. Due to the slow animations, the Rotator's timing is erratic, causing frames to animate before tickers have displayed all of their text. That said, the problems can be all but eliminated if animations are not used or if very simple text content is all that is being rotated. The control's basic features and client-side events all work and function correctly, but the iPhone's handling of animations limits the usefulness of RadRotator.
  6. RadSpell: Usable
    This result may surprise you. Even though we discovered that AjaxSpellCheck does not work on the iPhone, the normal RadWindow-based RadSpell does! And surprisingly well at that. If you look past the fact that RadSpell's interface is far from optimized for the iPhone, you'll discover that everything is working. You can easily spellcheck any element on your page and use the RadWindow dialog to accept spelling suggestions and correct your work. The spellcheck dialog cannot be moved, though, due to the iPhone's inability to handle drag and drop interactions. Users must move the dialog into view and work with it where it loads on the page. And while I definitely wouldn't recommend using RadSpell on an iPhone due to the poor UI optimization for a touch-based interface and low resolution screen, it does work. If you have an application that uses RadSpell, you can rest easy knowing it will work for your iPhone users, too.

All told, it was another successful outing for the RadControls on the iPhone. At this point, there are only a few controls to avoid on the iPhone (RadEditor, RadCombobox, and RadInput), making your RadControl toolbox for iPhone development quite large. Check out the full gallery of this round of testing to see all of controls in action and stay tuned for the final installment with the remaining RadControls later this week.


ToddAnglin_164
About the Author

Todd Anglin

Todd Anglin is Vice President of Product at Progress. Todd is responsible for leading the teams at Progress focused on NativeScript, a modern cross-platform solution for building native mobile apps with JavaScript. Todd is an author and frequent speaker on web and mobile app development. Follow Todd @toddanglin for his latest writings and industry insights.

Comments

Comments are disabled in preview mode.