Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Tue, 22 Mar 2011 13:20:39 -0700 Retrieving all the Methods in a Service http://vijaykrishna.posterous.com/retrieving-all-the-methods-in-a-service http://vijaykrishna.posterous.com/retrieving-all-the-methods-in-a-service Well, today i was in a real fix. I was asked to work out a manner by which i show all the methods of a service in a combo-box. Now, people told me to ideally have a look at the proxy and type out the method names as they were and then create a static list of strings which i could then bind to the combo-box. WOW!! So simple ain't it?!? "And what if the list of methods were to change", i asked. The reply came, well, you can guess what the reply was. Someone then suggested a method involving WSDL. I do not know what that meant, as the idea was instantly trashed and i was never explained the details. Either way i smelled unnecessary  labor there as well. So i put up a brave face and googled it. I refused to believe that the method list of a given class could not be retrieved. After all that was the crux of my project. So after a little bit of googling and a little asking around from a trusted colleague, i found a way: Type. [sourcecode language="csharp"] public List<string> GetMethodNames(){ Type type = client.GetType(); var methods = type.GetMethods(); List<string> methodNames = new List<string>(); methodNames = methods.select(x=>x.Name).ToList<string>(); return methodNames; } [/sourcecode] So i can actually send in the type of service client (for which the method name list is required) to the GetMethodNames function and get different lists for different services. Thus, allowing me to dynamically get the method lists, which will take care of cases when the service changes the methods in terms of names and numbers. Ofcourse, in case of a Silverlight project, we will have to take care of things like the "Async" prefix. So we just have to remove that. Simple enough. So that is that!! :D

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Mon, 28 Feb 2011 17:54:33 -0800 Pages, Views and Popups - Data Flows http://vijaykrishna.posterous.com/pages-views-and-popups-data-flows http://vijaykrishna.posterous.com/pages-views-and-popups-data-flows I think i have written a few posts on popups and the issues with layer development before. Today, I was encountered with another classical situation involving Pages, views and pop-ups. And for a change i was invited to be a part of the debate. The scenario was as follows: We had a page, which was in all essence a master page dealing with the background service. This page fundamentally had a tab control with every tab's container having its own control. Now each of these controls led out to one or more popups (again effectively more controls). The issue was to treat the controls as controls and try to relinquish them of all Svc calls. Mind you at this stage no calls were being made from any of the controls but we just wanted to come up with a solution where in we could once and for all decide a standard protocol by which we could completely avert situations involving svc calls being made from the controls. After a good length of discussion we got to the following structure: Svc <> Page <> View Mode control <> Edit Mode Popup The idea was to manage data flows in this simple scheme of things. After some more nut cracking we came down to the following 2 alternatives: A) Svc <> Page <> View Mode control <> Edit Mode Popup This basically suggests that the data coming in to the page from the Svc should be passed on to the page as it is, the page to the View Mode, and the View Mode to the Edit mode and similarly all the way back. Fundamentally, each entity will interact only with the one in front of it and the one behind it. That is, the page will never interact with the Edit pop up directly, the View mode will never interact with the Svc, ie make Svc calls. B) Svc <> Page <> {View Mode control, Edit Mode Popup} In this arrangement, the Page can now interact directly with the View and Edit controls. That is the only difference between this and the previous arrangement. Now for anyone to understand the implications of either arrangements, i need to highlight the interactions between a control and the page. The control will have all the buttons to actually perform operations by the user. But they will not be any Svc calls emerging directly from the control itself. On a button click, the control will raise a Button_click event which will be handled in the page by the required Svc call. It may seem complex, but if you have read my previous posts, which i mentioned earlier in this post, then you will realise that with such an arrangement you have actually decoupled a UI fragment from the data processing unit (the page) and data supplier (the svc). With that, you can actually use the same control in a similar context with a different svc and processing unit, giving similar data. Similar interactions will exist between any two controls as well. Now with that out of our way, let me get to the point. In arrangement A, the work is distributed across the entities. There isn't a lot of control resting in one place. A fair amount of modularity will be introduced with that approach. And hence the over all code will be neat and clean. But if a change is required it will have to be done at multiple locations. While in arrangement B, with the page interacting with both the View and Edit controls, the Page will end up managing a lot of Events that will get raised by double the number of controls as compared to that in A (assuming that each View Control has an Edit control). This will localize the code, resulting in the reciprocal of arrangement A. The code will be difficult to manage with so much happening in one place, and hence the code can get ugly. Mind you with effective code management this can be resolved. But at the same time, if there is an error or change in the way the data is processed, there will only be one place where all the changes will have to be made. Which will anyone pick is a matter of great debate and discussion. The correct answer depends entirely on the situation at hand. I picked one of them based on the existing code structure, so that is an important parameter while making such decisions. And for those who will suggest that should merge the View and Edit modes: solve the problem, don't change the requirements.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Wed, 12 Jan 2011 17:58:10 -0800 Trivial Error http://vijaykrishna.posterous.com/trivial-error http://vijaykrishna.posterous.com/trivial-error Well, this is a post about how i made a real silly mistake when i could have easily avoided it. I want to share this experience so that others can gain something from it. So here is the Scenario: A classical integration of the services with the Silverlight UI. All calls are Asynchronous and hence all, of them have a get completed event handler. So, here is a page where i have to make 2 service calls and thus two event handlers. Service Call 1 (SvC1) was to get the data for the UI. Service Call 2 (SvC2) was to get a certain key value pair which would dictate the number and content of a set of check boxes in the UI. So in essence, i was using SvC2 to dynamically set up controls (i was using an items control). Mind you, SvC2 was never returning the controls it self, it was simply giving me the data, i.e the Label/Content property of the check boxes and their tooltip/description property. And yes, the UI has a standard New and Open scenarios. Here is what i did: I made the call to SvC1 first and set up the data context as required, ie the data context would not be set in case of a New Item creation. So, whether or not i was going to bind the data, i would be making the call. Then, irrespective of that, i make the SvC2 to get the data for the check box controls and then with the data-context (if given), and the data from SvC2, i create the controls. Now, why i say "if given" in the previous statement is because some of the check boxes would be clicked if the data context were given, else all of them would be false or not clicked. There is another issue, once i have created the check box controls, it will be very difficult to access them (they are inside the ItemsControl). I would rather make the controls, and assign the data to them in one go. I would not like to split these two tasks, for the sake of simplicity of code and its understandability. Here is what i should have done: I should have made the call to SvC2 first, which would have returned the list of data to be shown in the controls i.e  the check boxes. Then i should have called SvC1 on the Completed (event or on completion) of SvC2, and set the data context, i.e. bound the data with the controls. While doing this i should have set the items source for the check boxes, or, in simple words, i should have created the check boxes dynamically using the information i got in SvC2. This way, a) I would have gotten the data for the controls before hand, b) I would have made the check on the data-context requirement on the completion of SvC2 and before calling SvC1, and end up saving one SvC if required. Otherwise, i was making the SvC1 no matter what and then probably not end up using it and then call SvC2 anyway because it was being called on the get completed event handler of SvC1. c) And finally, i would still be able to create the controls and bind the data to them in one go. You may not be cutting trees by making an extra service call, but you sure are troubling some million electrons for it. :D So take care, use the Service wisely.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Sat, 01 Jan 2011 16:58:41 -0800 Elements of Interface Design 2 http://vijaykrishna.posterous.com/elements-of-interface-design-2 http://vijaykrishna.posterous.com/elements-of-interface-design-2 The prequel of this post was termed Elements of Design. It was really a feeble attempt at trying to explore the various factors of Usability in any User Interface.  I am going to continue in those lines. I am going to talk about the relation between the back-end or the service layer of any system and the system's final User Interface. In particular i am going to explore the the interdependencies between the two. It is a common notion to design the architecture/databases of your system according to what you feel you want to show. This is often taken to the point where developers develop the architecture from the UI perspective. It is a sad misconception that many young, budding software engineers have, i know i did. It is sadder still that many go about building systems the other way round. That is, building UIs from the service perspective. "Everything in the Service or the database will be shown in the UI" Now, i think that it is a wrong way of doing things. Frankly, both the UI and the service should be independent of each other, with a very minimal and flexible points of interfacing. While, it is a natural notion to show all the data being supplied to you, you really do not have to. Good, interfaces are those which do not allow its users to search for results. Remember, Information above Data. Blind dumping of data, that being received from a service or database, implies one of the two things: a) Your service architecture is so good that it only returns all the relevant results, thereby automatically doing half the job for you in terms of making a good interface. b) Or, makes your UI designing job all the more difficult and tedious for a plethora of reasons i can think of right now: Too much data; Too little data; Irrelevant Data being returned by the service. Hence, by following the above stated approach (the line in quotes and italics), we have the following results: Good Service/Back-end, returning relevant data => Good UI, Service/Back-end, returning less data => UI with less information hence less value, Service/Back-end, returning more than required data => Cluttered UI, etc. All in all, the development, maintaining and purpose of the UI is too dependent on the Service/Back-end. This also leads to one other major problem: The UI will have to be changed as and when the service changes. And if that happens too often, then a ever changing UI might not be the best thing for a user, who will have to keep figuring out where the "Save" button is which was there till tomorrow. I am not suggesting an absolute decoupling. That is being crazy. I am however hinting at maintaining freedom at both levels. Let me ask you something: Does any Google API ask  you before hand the kind of tool/widget you want to develop? It just gives this brilliant set of calls and methods which can generate a whole gamut ideas in your head about the kind of tools you want to make the features that they will have. An artist comes out with the best piece of art, given a greater choice of colours and equipment. He may not use all the colours and equipment. At times he will use all the seven colors of a rainbow with an array of brushes to create a masterpiece. And at times he will just use a simple pencil to create a greater work of art in the form of a beautiful sketch. The point is that the artist needs the freedom of thought to play with things and to make his own choice. Similarly, the UI designer needs an architecture and a data pool, which he can play with. He needs that freedom. In essence, the system and architecture designer should not keep in mind the UI or how the data can be shown to the world. No! His job is to provide all the data and functionality in the world, which he can possibly think of, in a very distributed and atomic manner. His job in short is to think of everything in that domain of business or work, for which the software is being built. He has to go beyond the myopia of what is required upfront. He has to preempt and build a system that will last a decade's worth of requirements from the moment he declares it complete. When the service or back-end has such depth and power, the UI developer/designer will have all the freedom in the world to work. He will then be in a position to create something seemingly simple and brilliant.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu