Telerik blogs
In our final look at the RadControls for ASP.NET running on an iPhone, we'll look at RadSplitter, RadTabStrip, RadToolBar, RadTreeView, RadUpload, and RadWindow. In the first two installments of this series we looked at the other 12 RadControls running on the phone and found most of them to be usable or semi-usable. So far, only RadEditor has earned an unusable rating on the iPhone's mobile Safari. Today we'll pass judgment on the remaining RadControls and then create a quick summary chart that you can reference during your future iPhone development.

So without further delay, here's how the final six controls fared:

  1. RadSplitter: Semi-usable
    RadSplitter on an iPhone produces some pretty varied results. Depending on how the the Splitter is configured, it can work almost perfectly or it can become practically unusable. The basic features of RadSplitter work in most cases, with simple content correctly displayed in nested splitter panels and expand/collapse buttons working as expected. Dragging to resize splitter areas is obviously out of the question on the iPhone, and (like other controls) scrollbars fail to render when content exceeds the size of a panel area. But unlike other controls, when content length exceeds a splitter panel area it is not simply hidden out of view. Rather, the "extra" content spills out of the RadSplitter control and is visibly rendered on the page. The behavior makes it impossible to load external content correctly and is one of the major failures of the RadSplitter on an iPhone.

    That said, if you use simple RadSplitter implementations, it can work on the iPhone. For that, RadSplitter earns a semi-usable rating, though the emphasis here is definitely on the semi.
  2. RadTabStrip: Usable
    RadTabStrip works exceptionally well on an iPhone. It's very responsive, easy to use with the touch interface, and renders single- and multi-row tabs without error. The only noticeable problem with RadTabStrip on the iPhone is vertically aligned tabs. For some reason, this alignment does not render properly in mobile Safari. Other than that, it's a very safe control to use in your iPhone targeted applications.
  3. RadToolBar: Usable
    Not to sound repetitious, but RadToolBar also performed very well on the iPhone. Aside from some small rendering problems on image + text buttons, the control looks good and is easy to use. RadToolBar is not a particularly complicated control, though, so this result should come as no surprise. As with all things designed for the iPhone, good implementations of RadToolBar should use larger buttons than would normally be used in a web application to make it easy for people to "click" without zooming.
  4. RadTreeView: Semi-usable
    Your success with RadTreeView on the iPhone will depend on how you want to use the control. As a read-only UI control, the TreeView works fine. You can easily expand/collapse nodes and click on nodes to navigate to new URLs (if being used as navigation). If you dig a little deeper, you can also perform tasks like checking nodes, but it can be challenging to do with the touch interface. For more advanced operations, though, like editing nodes or dragging-and-dropping nodes, the iPhone interface breaks down. Dragging and dropping is clearly a limit of the phone's interface, but the problem with editing a node is less clear. You can get a node to transition into edit mode, but it immediately reverts to read-only mode after you complete the click-to-edit.

    Given the poor optimization for the iPhone and the inability to use many of the TreeView's more advanced features, RadTreeView earns a semi-usable rating. But unlike RadSplitter, the emphasis is on usable.
  5. RadUpload: Unusable
    You probably saw this one coming. As you may know, the iPhone does not allow you to access its filesystem unless you've joined the thriving iPhone hacking community. Based on that restriction, mobile Safari seems to automatically disable the browser's file selection objects- the core of the RadUpload control. So aside from the basic functionality of RadUpload being disabled by the browser, the control does still render properly. Visitors to a page with a RadUpload control on an iPhone will be presented with a good looking, functionless control.
  6. RadWindow: Semi-usable
    We've mentioned RadWindow several times throughout this three part review since there are several other RadControls to use RadWindow to present dialogs. Therefore, you already know that RadWindow does work at a basic level on the iPhone. It can be loaded on the page, minimized, restored, closed, and refreshed. It can display most content types, including external sites, but the scrollbar limitations still exist with this control. If the content is too large for a RadWindow, it will automatically (and uncontrollably) expand vertically to display the content. Content that is too wide for the RadWindow will simply be inaccessible. The modal RadWindow dialogs partially work, but for some reason the text on the modal dialog buttons does not display on the phone.

    Regardless of these results, RadWindow is not a control that is designed for easy use on a device like the iPhone. It is unlikely that you'll want to include this control in iPhone targeted applications if you can avoid it.

Summary Wrap-up
So there we have it: all 18 RadControls running on the Apple iPhone. Overall the results are pretty good, and compared to any other cell phone-based browser they're incredible. Mobile Safari on the iPhone is definitely not the exact same Safari that runs on Windows and OS X, but for the most part it renders HTML and process JavaScript identically (though the JavaScript processing is much slower). It's the iPhone's unique input mechanism- and the related limits it imposes- that cause most of the "problems".

For quick reference, here are how all of the RadControls performed on iPhone 1.0:



Happy RadControl coding on the iPhone!

View the final RadControls on iPhone image gallery


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.