Working with XCode IDE, I had always felt the need for a top-level entity that could support and organize my multiple XCode projects.  It wasn’t easy to access the files of one project from another in XCode 3.2, even if you had cross project references between them. Code sharing was always an issue if two or more projects used the same libraries and we had to copy them into each project folder separately.

Introduction of “Workspaces” brings in one of the new bits of “magic” that XCode 4 does for you: Multiple-Project Support. A workspace is basically a container meta-file that groups together multiple projects and other documents. It also provides implicit and explicit relationships among the included projects and their respective targets.

 Concept of workspace also allows us to create and use third party libraries in iOS projects in a much simpler way. However, the procedure is still more complex than it needs to be. Apple documentation suggests that it should automatically detect dependencies and other index classes across workspace.

 There are few key behaviors of workspace on how to share code across different projects in XCode:

• All the projects in a workspace are built in the same directory, referred to as the workspace build directory.
• XCode inspects the files in the build directory to discover implicit dependencies between them.

• Each project in a workspace continues to have its own independent distinctiveness.

 Steps that worked for me:

1. Create a new workspace and add the shared library project.
2.  Add the application project that would use the above shared library.  
3. Open Build Phase of shared library and make sure when copying headers it is grouped to public .
4. Open Build settings of application and in the Header Search Paths type in “BUILD_PRODUCTS_DIR”\usr\local\include .
5. And in Build Phase of target, include a link to static library (shared library) .
6. Now, clean and build and everything should build successfully.

 Incase you are having linking errors while setting up the workspace in XCode, you can refer this article whats-the-correct-way-to-configure-xcode-4-workspaces-to-build-dependencies

 All said and done, this worked like a charm for me. The workspace concept benefited me by sharing the code and build folders across multiple projects. Now, with the use of XCode 4 workspace we don’t have to copy the library files in every project and this saves lot of development time and effort.

 How is it better than eclipse workspace?

There are two main aspects in which I found XCode workspace to be better than Eclipse workspace:

1. In XCode 4.0, file indexing is done across the whole workspace so, code completion and refactoring operations act across all the content of the workspace. You can refactor the API in a framework project and in several application projects that use that framework all in one operation. This feature is missing in the current version of Eclipse.
2. All the XCode projects in a workspace are built in the same directory, which is referred to as the “workspace build directory”. As all of the files in all of the projects in a workspace are in the same build directory, all of these files are visible to each project. Hence, if two or more projects use the same libraries, you don’t need to include them into each project folder separately.

 How it improved my development process?

This article might give you an impression that setting up the workspace is a lot of work; but fortunately it’s not, especially if you do it more than once (considering that the aim here is to share code across multiple projects). I have been using this workspace approach for about four months with several projects and it’s definitely saved me a lot of time especially when the application projects used the same static libraries again and again.

 Instead of copying the source code from the “shared libraries” into every project (which used to take me an hour or so for every project), I just keep the shared library code in a separate XCode project and use it to build static libraries along with the application project. It is just a 5-minutes job now!

Coded UI Test (CUIT) is a new feature introduced by Microsoft for UI Automation. The automated tests created by CUIT are used for the functionality testing of an application.

To know about this tool, we started exploring its ‘Record and Playback’ feature. A very simple test case that we initiated this effort with had the following steps:

1. Launch Internet Explorer
2. Navigate to www.google.com
3. Search for “Code UI Test”
4. Validate if the result returned “How to: Create a Coded UI Test” link (an MSDN article on the topic)

Though it generated huge code for such a simple test case, the overall Record and Playback process highlighted the strengths of this tool. The well structured code and powerful element identification mechanism really caught our attention.

Besides that, the CUIT playback engine is also powerful. Playback engine performs duties such as searching for a control and ensuring that the control is visible and ready to be acted upon. Once the control is ready the engine performs actions such as ‘Click’, ‘Select’, ‘Set a Value’, etc. on it.

Recording feature alone is of course, not sufficient for building a full-fledged automation suite. However, CUIT’s recording feature certainly helps you if you decide to write your own scripts. It primarily helps in getting proper hierarchy of controls on the page (such as browser – iframe – div – control) and a set of properties that can be used to identify a particular control uniquely.

We also developed a UI Automation Framework using CUIT. While developing this framework, we experienced that CUIT has got several strengths. Its Recording feature really helped us save development time to a good extent.

Overall, if you decide to go with CUIT, here are some pros and cons of using it for your product:

Pros

1. The element identification mechanism is powerful
2. Uses C#, the compiled language, which comes with its own advantages over the scripting languages
3. Works well with Web as well as Desktop applications
4. Strong support for Synchronization. The Playback Engine allows settings such as “WaitForReadyLevel”, which can be either “UIThreadOnly” or “AllThreads”. It makes the Test Execution stop until either UI Threads or All threads are ready.

Other supported settings are– “Stop on Error”, “Match exact hierarchy”, “Search in minimized window”, etc.

1. It supports AJAX
2. The tests can be run on Remote Machines with the help of Tests Agents

Cons

1. Generates huge code for even a small UI operation, and hence hampers maintainability to some extent
2. Code Reusability is limited; it regenerates code even if it was already generated for a particular action
3. It uses almost all the Property – Value pairs to identify and locate the UI Controls which at times seems to affect the performance of the script

Guidelines for Automation using Code UI Test

1. Test creation is certainly a time consuming task, but it is worth going for it if the application under test is pretty stable and has got a large number of tests to be executed repetitively
2. Having said the above, it is not worth putting efforts in generating Test Scripts for an application which has frequently changing functionality
3. It can be used for Web as well as Windows applications. It supports,
   1. AJAX
   2. Silverlight

With such advantages and the reliability of the scripts, CUIT appears to be a promising tool for the UI Automation. There are other areas to explore. For example, we have not yet tried it with application containing Flash controls. That might be a topic for a future blog post, but in meanwhile, have you tried it with Flash? Write to us in comments and share your views.

Last month, I attended a RIA conference by Adobe at Pune. If I have to choose the most interesting part, I would go with the demo on use of Flash Builder 4.5 for Mobile application development with Flex 4.5.

Adobe is trying to answer one of the most sought-after questions – is it possible to develop an iPhone application without using Xcode? Is it possible to develop an application for Android that will run on iPhone as well?

Adobe wants to use Flex as a mechanism to answer the above questions. If you know Flex, you can build apps for Android, BlackBerry Playbook, iPhone and iPad.

Key features of this approach in creating applications for multiple mobile platforms are:

• In-built component library for UI
  • List, Busy Cursor, Scroller, ItemRenderer, different buttons and navigators etc.
• Auto scaling based on device pixel density
• Support for mobile themes including default
• Performance optimization
• Multi-resolution bitmap support

Here is a nice step-by-step overview on how to develop a mobile application using Flex 4.5 SDK. I must agree that this is really a huge step forward to enable developers concentrate on business needs rather than different platforms when it comes to mobile development. If we look at the rich feature list and support mentioned, there is no doubt about bringing down the cost of developing and improving the time to market for developers.

So, is Flex something that everyone should consider when building a multi-platform mobile app? I think the following questions and considerations will help one decide.

1. Do you have an existing app developed for either iPhone or Android.
   If you plan to extend support for additional platform, it would be 50-50 decision as development efforts involved will be same. Using Flex 4.5 could really make a difference if in the future, you plan to add more features to an existing app.
2. Which mobile platforms are you planning your app for?
   If your focus is mainly on platforms supported by Adobe, it’s worth evaluating.
3. Complexity of the app and features to be supported.
   I am yet to evaluate complete feature list, but overall it looks promising for simple data driven apps. It will take a while to evaluate and comment on its ability to support complex business requirements without compromising performance.
4. Is there any platform specific feature in your application?
   One of the challenges with respect to developing cross platform app is always the diverse set of platform specific feature list. For example, on Android, almost every device has back button to exit app whereas Apple apps are largely unaware of existence of back button or app exit functionality. Although you have a common code-base with Flex, it is purely based on similarities across multiple mobile platforms, which makes things difficult.

As mobile platforms are continuously evolving, Adobe’s attempt is commendable. What I am looking forward to now is how Adobe is going to incorporate support for future versions of these mobile platforms – essentially, how fast Adobe can add support for newer versions of operating systems in the future, to position its Flex platform over the individual Android/iPhone/Blackberry platforms.

Since we all started using Google & Facebook there is always a mentioning about performance these portals have provided. There are many articles/blogs/stories published on the same and all in all it stops at NoSQL. Early this year, when Netflix migrated to use NoSQL successfully, now almost everyone wants to evaluate this technique further. As first major NoSQL Now Conference started in August (August 23 – 25) this post is to give quick introduction of NoSQL and touch base pointers that will help in evaluating its use in existing or future projects.

NoSQL commonly expanded to ‘Not Only SQL’. In my observations, mostly it’s been considered as an alternative to RDMS as we are used to ‘SQL’ means RDBMS because of its popularity. In fact it’s not an alternative; it’s a different database model with set of different objectives. One more point to be noted here is, NoSQL is not a single system/solution rather it’s a class of database management systems that differ from classic RDBMS.

Recently I was working on solving a performance issue in one of the project. It involved intensive File IO and huge set of DB operations. Due to complexity of queries and size of data, module was lacking with respect to desired performance. Ultimate solution for the problem was to de-normalize existing DB schema, add batch processing and on top of it distribute batch processing across multiple nodes to further enhance it. I don’t see much difference between this solution and NoSQL at concept level, NoSQL takes this concept to a broader level. I would say NoSQL engines rely on a distributed storage systems and parallel processing across different nodes.

NoSQL implementations are generally categorized as below:

• Document Store – Apache CouchDB, MongoDB, SimpleDB etc.
• Graph – AllegroGraph, OrientDB etc.
• Key-value Stores – Apache Cassandra, BigTable, Apache Hadoop etc.

So why or when I will use NoSQL?

• For certain use cases so admired ACID nature of RDBMS takes its toll on application performance and eventually availability of the application. Some of the applications may not need relationship between data stored along with it.
• One of the most talked aspects is SCALABLITY. With classic RDBMS approach scalability is achieved with architecting the database properly. On the other hand, NoSQL datastructures have no predefined schemas. It focuses on only those datastrctures that can scale and restricting use of these datastructres ensures significantly higher horizontal scalability.
• High Availability is another important dimension of NoSQL which comes at relative cheaper cost than RDBMS. With synchronous replication of data, it ensures high availability.

As its still evolving, migration from RDBMS to NoSQL is not simple step; approach followed by Netflix is a very good example to consider here.

Though throughout this post I have compared NoSQL with RDBMS, it’s mainly to highlight features and explore use of NoSQL to solve problems faced with RDBMS. RDBMS is not going anywhere. In evaluating few of NoSQL engines; I have observed complexity as compared to RDBMS. Being this said, I think NoSQL implementations on Cloud will definitely be a next step forward.

In this post, we’ll take a look at some usability evaluation methods most commonly used in software design today. These can be applied at different stages in User Centered Design process. These methods can be broadly categorized into 3 categories – Inquiry, Inspection and Testing.

• Contextual Inquiry (Inquiry)
  When – Early stages of development, the information collected through this techniques is quite subjective
  Why –  When it is important to see how different users work in different environments/domains
  How – It is sort of an interview method where you need to go to the user’s workplace, ask them few standard questions based on your purpose and observe them while they work

• Focus Groups (Inquiry)
  When – Early stages of project/product planning
  Why – To obtain various reactions/opinion about a particular concept. It’s also useful for gathering different insights & preferences.
  How – This is a group interaction activity where a selected range of people gather to discuss a particular topic and give their reactions, opinions, insights etc. This discussion usually happens under the guidance of a moderator who follows a discussion plan.
• Heuristic Evaluation (Inspection)
  When – At any stage of design phase
  Why – To determine the usability problems in the design
  How – Usability experts (mostly one to three) judge the compliance of various user interface elements with established usability guidelines.

• Card Sorting (Inspection)
  When– Early design phase of the project
  Why – To design the Information Architecture and know how users would categorize and label the information
  How – Test users are given a unsorted collection of items and asked to organize them into categories, determining associations, grouping and finally label them.

• Usability Testing (Testing)
  When – Wireframe stage & also the later stage
  Why – To test the user friendliness of the application/product in terms of speed of use, ease of use, overall efficiency etc.
  How – This is a testing method in which the test user is observed using the product. Thinking Aloud protocol is a popular technique used here in which the users are requested to vocalize their thoughts while exploring the product or performing a particular task. The observation can be either obtrusive or non-obtrusive.

Above methods are followed by careful and systematic analysis through proper interpretation sessions which include evaluation of the most important usability problems and studying affinities.

At Harbinger, we use these methods regularly based on the needs of our clients. Do you use of any of these during your product design? Or are there any other techniques that make your product go from good to great?

Microsoft recently released .Net 4.0. It is to the credit of Microsoft, which has made constant improvements in their .Net versions, shown below. Here is a small infographic that shows their progress from version 2.0 through 4.0.

.Net Framework Stack

I do not see 4.0 as a package that is full of new features, but what I do see is that there are important improvements in performance, and a stress on doing more parallel processing and multi tasking. This is in contrast to version 3.0 release, which was outstanding with new features like Windows Presentation Framework, Windows Communication Foundation and Workflow. Regardless, it is interesting to see the overall developments, and what all we got from 2.0 to 4.0 as a whole.

Recently, we migrated one of our applications from .Net version 2.0 to .Net 4.0. We were very excited to be able to use all the latest features, and making the application more secure, user friendly, faster and scalable for our client. Visual Studio does take care of many things, and .Net itself provides high level of backward compatibility, which helps.

Out of the many available enhancements, the very first things we wanted to offer our client was Windows Communication Foundation, and to dump their conventional Web services approach. Among the features they wanted to have but could not due to technology limitations were:

• Support for transport protocols like TCP,  HTTP, Named pipes and Message queuing (MSMQ)
• Customizable services to their different clients (With .NET 4.0, you can provide different versions of your application to different customers just with different end point. Standard endpoint is an another good feature which is pre-defined endpoint where one or more of their properties (address, binding, contract) fixed.
• Same service can be exposed with different contracts for different types of Clients/Users in more secure way

These features have made life much easier for developers to build great applications for clients. According to me, the highlights of .NET 4.0 are:

• Dynamic lookup – This allows a unified approach to invoking things dynamically. We no longer need to worry about the type of an object when assigning values returned from methods or expressions; the runtime performs the necessary binding for us according to the returned value’s type
• Garbage collection – .NET 4.0 provides background garbage collection.
• ADO.Net entity framework features – Making life easier for creating a data access application more in terms of an application-centric conceptual model.
• Performance and Diagnostics – .NET Framework 4.0 provides improvements in startup time, working set sizes, and faster performance for multi-threaded applications.
• Profiling – In .NET 4.0, you can attach profilers to a running process at any point, perform the requested profiling tasks, and then detach.
• Reflection – The .NET Framework 4.0 provides the capability to monitor the performance of your application domains using Application Domain resource monitoring.
• Improvement in Microsoft AJAX Library – Script loader, JQuery integration, Client data access etc.