Monday, May 31, 2010

Iphone - View Controllers

View controllers are one of the most fundamental building blocks of Iphone applications. How you implement the view controllers in you application determines how information is displayed to the user over multiple screens, or even within the limited space of one screen. They allow you to manage the showing and hiding of information within one screen as well as switching back and forth between screens. This article is a general overview of view controllers and has special focus on the Navigation View Controller.

There are three types of view controllers:
- Custom View Controller
- Container View Controller
- Modal View Controller

Custom View Controllers are controller objects that manage the content of one screen. Most applications will have several screens that display different information, each of these can have its own view controller that manages the presentation of data for that particular screen only.

A Container View Controller on the other hand controls other View Controllers. These are used to define navigation between several different views. A Navigation View Controller and Tab Bar View Controller are examples of Container View Controllers.

The diagram below shows an example interface with three different views that the user can navigate back and forth between, as well as a portion of the screen being used to navigate between four other views.
There are several ways the diagram's flow could be achieved in an application. Lets say we decide to go down the following scenario:

  • Each of the 7 views gets its own custom view controller.
  • Implement a main navigation controller using UINavigationController class provided by the system. This allows us to go back and forth between the three main views.
  • For the four views, that only change a potion of the screen, we have two different options: Implement a UITabBar class in the central view, that switches between the four views or display the Toolbar that is defined within the UINavigationController class. Note that we cannot use the UITabBarController class at this point since the programming guideline prohibits incorporating a UITabBarController into a UINavigationController. However, the guideline does allow having a UINavigationController within a UITabBarController.
The UINavigationViewController is an amazing class that maintains track of a navigation stack. It contains several views that help define a navigation interface: Navigation Bar, Navigation View, Custom Content and the hidden by default Navigation Toolbar. The content of the Navigation bar and Toolbar can be customized however these views do not change. The only view that changes is the Custom Content view. This view always shows the view of the view controller that is at the top of the navigation stack.

The Navigation Bar already has a default back button defined, which displays the name of the previous view's title. If the previous view has no title then the button displays "back" by default. The behavior for this button is already defined and clicking it changes the view to the previous view. Very convenient. Sadly, if the previous view had a title the button says the title of the page and you cannot simply change the text to say "back" or any other custom text. You actually have to define a custom UIBarButtonItem and assign it to the leftBarButtonItem property of the Navigation Bar. This also means that you have to define the behavior of the button as well. The middle of the Navigation Bar generally displays the view title. You can specify a custom title by setting the titleView Property of the Navigation Bar. The right side of the Navigation Bar by default displays nothing unless the rightBarButtonItem property has been set to a custom UIBarButtonItem. The rightBarButtonItem property is often used to specify a next button or a cancel button, all you have to do is put the next view on top of the navigation stack for the controller to know which view to load.

For navigating between the four sub views we used the UITabBar class. The UITabBar class allows you to define two or more tab items, clicking on which changes the selected view. The issue to note here is that placing a view within a view required a lot of fine tuning sizing wise. Even if the views properties for auto sizing are set they didn't always render correctly within each other and we had to specify size in code. Even though we were successful with this avenue, in the end it was easier and cleaner to repeat in each of the four sub views the content of the central view that was common to them and switch the whole of the central with one of these four when a Tab Bar Item was clicked.

I hope you found this introduction / summary helpful. Choosing the path that best suits your application is very important and can have many challenges: unavailable options, rules and regulations, time for fine tuning etc. This is a decision that could determine how much re-work or re-design you may have to do later on in the project.

References and recommended reading:

Thursday, May 20, 2010

Supporting navigation with the trackball

Let's talk about using the trackball in android applications.

First of all I was surprised when noticed that focus (orange background) is not visible on ListView's items. During testing application I noticed that ListView items gets focus in reality, because if we click with the trackball on item appropriate event would be handled. However, we can't see focus that is why I started investigation. Finally it was found out that it is because of background
of ListView's items. If we need to see focus we must have background color's alpha parameter 0(ex. Color.argb(0,255,255,255), hex colors). But in that case we wouldn't have real colors(colors would be darker, ex. white would be gray). That is why we have to remove background color and use default black background. And also I want to mention another limitation of ListView. It's not possible to define items which must be focusable, because ListView is doing that itself.

The second thing that shocked me was that we can't see focus on ImageView item. In our "Edit Profile" page we have a lot of elements and have a method to define sequence of focused items. The focus works correctly for all elements, but ImageView is an exception. Investigation shows that it is a known issue that is why I have to put ImageView in another view, implement selector for that view and give orange background to it when it is focused.

Third I want to speak about behavior of the trackball under tabs. Let's go through an example.We have one activity which is responsible for drawing TabHost. Under each tab we have another activity. We need to be able to reach and interact with all items on all tabs using just the trackball. With our implementation it means that we have to navigate through items in different activities which, in my point of view, is not possible.That is why for now with the trackball we can only move slider and go from one tab to another.For example we need to set a focus on tab. As soon as activity under tab is loaded focus automatically will go to appropriate element under tab.That is why if we need to navigate through tabs we must first of all go up with the trackball then change tab.

That's all for now about strange behavior of focus when using the trackball.

Monday, May 10, 2010

Managing Experimentation - Part 2

As a follow up to my first post about managing experimentation I would like to cover an interesting aspect of this project: progression tracking.

There are several ways to track progression, some subjectives and some objectives. The most pleasing one to me is a subjective one about having "working software" this is not part of the agile manifesto for nothing, in delivering quality software you need to focus on having working software at all time and sooner than later. In the case of the IPhone implementation we did have working software very early on, it was not doing much but it was working and we could see new code coming in daily. This is an important proof that the project is moving on and it makes it easy to observe if a team is heading in the right direction or not.

Another interesting objective aspect I have been watching for is new tasks creation. While this is a matter of worry (from an estimation and profitability stand point) it is a very positive sign that the team has taken ownership of their project. By constantly creating new tasks a team is showing that they are in control of the workload of the project and that they are taking actions towards ensuring that there are no loose ends.

See for yourself:

The red line is showing tasks creation while the green is showing tasks resolutions.

As you can clearly see the team has been creating as many tasks as they have been resolving since the initial task creation initiative. And this pretty much from day one. This is very positive.

Last but not least, from an objective stand point is the rate of code submission to the repository. Actually... to the code review board. Macadamian has been performing code reviews since its birth day, in doing so it is easy to track at what pace the code come in.

I have not looked at the evolution of the #KLOC but I can confirm that the team has submitted about a patch a day. While this is a little low for a team of 4, since many of us on this team were new to the IPhone programming environment this seems to be a quite decent rate.

Friday, May 7, 2010

Chart Control for Windows Phone 7

The experiences that we've gone through on Windows Phone 7 so far have been very astonishing. Loads of controls are absent from .NET Compact. You have to find a workaround for anything that's not there. This makes life bitter.
Here are a few limitations to outline. They are not encompassed with something general, just a list of what I faced so far:
  • no local database support (as already mentioned in this and this blogs)
  • no TabControl, no DatePicker (the complete list can be found on msdn)
  • no IComparer (the common IComparer is supported, but for templates it's not)
  • in usual WPF there is Button.Children, but here we don't have it
  • no ChartControl (about them we've talked on those two pages)
OK, enough of disappointments now. Here is the good part. Macadamian developed a Chart Control which you can pick up for free. The chart looks like the one in the screenshot below.

Don't pay specific attention to that outrageous pile of letters called "Parandzem". That's an Armenian name (by the way that's a female name) that I left to appear on the phone. The rest are the "Baby Weight Tracker" application left-offs, and the chart of course.

You can download the dll of the chart here.

In the coming days another control will be available to fetch - DatePicker. Stay tuned!