Archive

Posts Tagged ‘Silverlight’

Nuestras Charlas en Codecamp 2009

September 29th, 2009

Reading time: 2 - 3 minutes

Muy buenas tardes a todos!! Queremos hacerles llegar las presentaciones que sirvieron de soporte para las charlas que dimos en el último Codecamp en Buenos Aires.

Cocinando una Aplicación Silverlight en 1 Hora

Por: Federico Lois y Daniel Iglesias (Huddle Group)
También pueden acceder a más material sobre la presentación que dieron los chicos en: http://bit.ly/41254y



Microsoft Surface

Por: Mauro Castagnasso y Nicolas Padula

  • Share/Bookmark

Academics , , , , , ,

New version of beWeeVee and some announcements

August 21st, 2009

Reading time: 2 - 4 minutes

Today we are releasing a new improved version of the technical preview of beWeeVee’s Silverlight technology that can be accessed from: http://www.beweevee.com/notepad. [*]

Since the last time we did a public update we have added a couple of features, like revisions, colored users and faster response. From the beginning releasing the technical preview was aimed into acquiring hard-data on the behavior of the underlying technology in what we called an “on-the-wild” scenario. Thanks to early users feedback we were able to pinpoint performance issues, understand the features required to make the user experience more humane, and even suggestions on how to better improve the API (some of which didn’t get it into this release).

Serious improvements have been done at the technology level, just to name a few:

- The operational transformation is 68% faster.
- Revisions have been added allowing the users to save snapshots of their work at anytime.
- The bandwidth required to sustain proper operations have been reduced considerably.
- We have fixed some defects involving losing connection with the server after prolonged idle time.

We want to announce too that next week we are going to release a CTP of the core components of the Software Development Kit (SDK) for people that wants to experiment with the API. We definitely want to know what you are doing with it :). Another interesting development is that we have finished the proof of concept stage of beWeeVee for Visual Studio and starting on full development in 2 weeks.

You can see the concept work here:

We are extending our thanks also to the development teams at Huddle Group that used beWeeVee first preview when doing real work, the attention to detail of Dayanna pointing out defects and early feedback and Daniel Iglesias for suggestions in improving the API usability. Stay tuned for a pretty interesting demo he is preparing using beWeeVee API and Silverlight 3.0 (yes, beWeeVee is Silverlight 3.0 compliant).

Hope you will enjoy it as we do,
Federico  

[*] You can still access your old documents from http://www.beweevee.com/incrediwrite

  • Share/Bookmark

Business, Technology , ,

Avoiding the infamous locked .xap file when building Silverlight projects in TFS

May 22nd, 2009

Reading time: < 1 minute

Building Silverlight projects on the Team Foundation Server Build Agent can get messy when you have .xap files around. We stumbled across this issues with a colleague from work (Dani you know, that was you :D) when automating the build agent for a client.

The solution is quite simple, even if not intuitive. What we need to do is to deny the build agent read access to the file avoiding to download it in the first place. So as the download process do not fail, we can perform the build without trying to overwrite a locked file.

Hope this helps.

  • Share/Bookmark

Technology , ,

Refactoring Friendly INotifyPropertyChanged Properties

May 18th, 2009

Reading time: 9 - 15 minutes

If you have been working on Windows Presentation Foundation or Silverlight 2.0/3.0 you may already be aware of a pretty interesting design pattern called MVVM (Model-View-ViewModel).

MVVM relies on the quite simple but important interface INotifyPropertyChanged in the System.ComponentModel namespace. Its role in MVVM is to allow you to notify when changes have occurred in your ViewModel so that your UI is able to respond to those changes.

// Summary:
//     Notifies clients that a property value has changed.
public interface INotifyPropertyChanged
{
   
// Summary:
    //     Occurs when a property value changes.
    event PropertyChangedEventHandler PropertyChanged;
}

 

As you can see the interface is quite simple, it just ask us to implement the property changed event. The usual way to use it is the following:

private int myIntProperty;

public int MyIntProperty
{
   
get { return myIntProperty; }
   
set
   
{
       
if (myIntProperty != value)
       
{
           
myIntProperty = value;
           
OnPropertyChanged(“MyIntProperty”);
       
}
   
}
} 

 

The “MyIntProperty” string is used to signal that the property that has changed is MyIntProperty so that our bindings gets notified of the value changed.

This approach has a slight problem, this string is not very refactoring friendly because it is binded to the property name, but it is not a “compiler verifiable entity”. In the case of the property it may look simple, just going ahead and change it. But, what happens when we are actually handling that property somewhere? Again we have to know that changing it will cause changes everywhere in our code base when that property change is handled.

If we do automatic refactoring, some tools may be able to know that they should change the property name too when refactoring and all strings. But that is a long shot if you have different classes with similar named properties, because the rename may change some strings that shouldn’t be renamed on the first place. Luckily there are workarounds to this problem.

What we would like to do is have something similar to this:

private int myIntProperty;

public int MyIntProperty
{
   
get { return myIntProperty; }
   
set
   
{
       
if (myIntProperty != value)
       
{
           
myIntProperty = value;
           
OnPropertyChanged(MyIntProperty);
       
}
   
}
} 

 

The current version of the C# language do not support passing Properties as a delegate so we cannot create a runtime entity that may allow us to find out in the OnPropertyChanged event handler who is calling.

But we do have something that behaves in a similar fashion, we have Lambda Expressions and Expression Trees. So what if we can do the following?

private int myIntProperty;

public int MyIntProperty
{
   
get { return myIntProperty; }
   
set
   
{
       
if (myIntProperty != value)
       
{
           
myIntProperty = value;
           
OnPropertyChanged(() => MyIntProperty);
       
}
   
}
}

 

It turns out that this may work, as the compiler is creating an expression tree out of that delegate, so we may be able to extract the property name out of it.

public static string GetPropertyName<T>(Expression<Func<T>> expression)
{
   
MemberExpression body = (MemberExpression)expression.Body;
   
return body.Member.Name;
}

 

After we solved that we are able to implement our PropertyChanged handler pretty easily like this:

/// <summary>
/// Raises this object’s PropertyChanged event.
/// </summary>
protected virtual void OnPropertyChanged(string propertyName)
{
   
this.VerifyPropertyName(propertyName);    if (this.PropertyChanged != null)
       
this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}       

 

protected void OnPropertyChanged<X>(Expression<Func<X>> expression)
{
   
string propertyName = GetPropertyName(expression);
   
OnPropertyChanged(propertyName);
}

Now the only thing that we require is to implement a base class for our ViewModel and some helper class to encapsulate the GetPropertyName functionality and we are ready to have refactoring friendly INotifyPropertyChanged properties.

You can also download a complete implementation from here and 2 visual studio snippets, one for ViewModel classes that implement the INotifyPropertyChanged interface and another one for properties that notify they had been changed. 

You can get it from: http://www.corvalius.com/blog/?attachment_id=26

  • Share/Bookmark

Technology , ,