Nokia’s First Two Windows Phones Are Here. And They’re Awesome.

Just a few minutes ago, Nokia CEO Stephen Elop wrapped up his keynote address at Nokia World 2011, where he unveiled Nokia’s first two Windows Phones, the Nokia Lumia 800 and the Nokia Lumia 710. Having seen (and touched) them both myself, I can tell you first hand that they’re amazing. And they were definitely worth waiting for.

The Nokia Lumia 800 is a stunning piece of industrial design that features a unique unibody polycarbonate chassis that’s available in 3 beautiful colors – black, magenta and cyan. Inside is a 1.4Ghz processor with a dedicated GPU, 16GB of storage, and a class-leading Carl Zeiss camera, all capped off with a 3.7” “ClearBlack” display that offers beautiful colors and razor sharp picture. It’s available for pre-order starting today on Nokia.com in select markets for approximately 420 Euros, and you’ll be able to buy locally from over 30 carriers and retailers in 6 European markets this fall, with carriers and retailers in Russia, India, Singapore, Taiwan and Hong Kong offering it for sale before the end of the year.

Here’s the official press shot:

And the photos I was able to take earlier today:

The Nokia Lumia 710 is a no-nonsense smartphone that’s designed to perform. It has the same processor and storage as the Nokia Lumia 800, and will be available in white and black with a number of different colored backs, including black, white, cyan, fuchsia and yellow. It’ll be available this year in Russia, Taiwan, India, Hong Kong and Singapore, with more markets coming in the first half of 2012. Retail price for the Nokia Lumia 710 is a very reasonable 270 Euros.

As with the Nokia Lumia 800, I have the official press shot and my personal hands-on photos:

These two new Lumia phones say loud and clear that Nokia is re-committing itself to building the best smartphones on the planet – and that they’re doing it with Windows Phone. That means that just like we built Windows Phone to put people first, they’re building hardware to do the same. Here’s what I mean:

• Our innovation is complementary: To make a product truly “wow-worthy”, you need to build software to work perfectly with hardware, and hardware to work perfectly with software. That’s happening today with Nokia and Windows Phones. Take photos, for example. We built Windows Phone to include a “pocket to picture to post” feature that lets people capture photos and share them through their social networks almost instantly. To complement that, Nokia is building phones with high-end optics from Carl Zeiss so your photos are just as good as those taken with a point-and-shoot. It’s a perfect blend of hardware and software innovation working together to put you and the people you care about first.
• Together, we’re bringing customers more of a good thing: Windows Phone has excellent built-in navigation with Bing Maps and powerful entertainment through Zune. Nokia’s making those even better by including Nokia Drive’s voice-activated free, turn-by-turn navigation and Nokia Music’s massive library of tracks and hundreds of channels from MixRadio. That’s more of a good thing, and it means that you can customize your experience exactly how you’d like it.
• A beautiful OS deserves a beautiful phone: My first mobile phone was a Nokia, and from the moment I picked it up, I knew it was something special. The new Nokia Lumia family feels the same way – well built, sleek, fast, and flat out beautiful. And with Windows Phone onboard, they have an OS that matches that exceptional industrial design every step of the way. You’ll know exactly what I mean when you pick one up for the first time.
• We’re making the ecosystem broader, deeper and stronger: We’re working together to build the Windows Phone ecosystem at every level – empowering developers to build compelling apps that take advantage of new and unique software and hardware features, partnering with component manufacturers to build even more amazing hardware, working with carriers to get Windows Phones into the hands of customers worldwide, and more. The short version of this is…we’re just getting started!

Six months ago, the Nokia/Microsoft partnership was just ink on paper. Today it’s two of the most impressive phones on the market and a roadmap for many more. We’re really proud of Nokia for fully committing to our partnership and for all of the hard work that their entire team is putting in to making the best smartphones in the world.

I’ll be at Nokia World all of today and tomorrow, blogging about the great stuff I find on the show floor, interviewing interesting people from both Nokia and Microsoft, and sharing as much as I can find about what the future holds for Nokia and Windows Phone. Keep an eye on the blog for new posts and follow me on Twitter for more sharable stuff from Nokia World!

And remember that you can keep up on all the latest stuff from Windows Phone through the Windows Phone Facebook Page and @WindowsPhone Twitter handle.

@ Courtesy - 

SQL to LINQ

                             It is difficult to write queries in LINQ (Language Integrate Natural query) in the first attempt but relating it with the language you used for writing queries will make your task reduce by 50% as you only now  need to know the syntax; and learning it wont be difficult.
                            There are number of advantages you can take it by writing your queries in LINQ,, they are as follows:

1. Makes it easier to transform data into objects. I'm sure you've heard the term "Impedence Mismatch" being used quite often, meaning that LINQ reduces the amount of work you must do to translate between object-oriented code and data paradigms such as hierarchical, flat-file, messages, relational, and more.  It doesn't eliminate the "Impedence Mismatch" because you must still reason about your data in its native form, but the bridge from here to there is (IMO) much shorter.


2. A common syntax for all data. Once you learn query syntax, you can use it with any LINQ provider. I think this is a much better development paradigm than the Tower of Babel that has grown over the years with data access technologies. Of course, each LINQ provider has unique nuances that are necessary, but the basic approach and query syntax is the same.


3. Strongly typed code.  The C# (or VB.NET) query syntax is part of the language and you code with C# types, which are translated into something a provider understands. This means that you gain the productivity of having your compiler find errors earlier in the development lifecycle than elsewhere. Granted, many errors in stored proc syntax will generate errors when you save, but LINQ is more general than SQL Server. You have to think of all the other types of data sources that generate runtime errors because their queries are formed with strings or some other loosely typed mechanism.


4. Provider integration. Pulling together data sources is very easy. For example, you can use LINQ to Objects, LINQ to SQL, and LINQ to XML together for some very sophisticated scenarios. I think it's very elegant.


5. Reduction in work.  Before LINQ, I spent a lot of time building DALs, but now my DataContext is the DAL.  I've used OPFs too, but now I have LINQ that ships with multiple providers in the box and many other 3rd party providers, giving me the benefits from my previous points.  I can set up a LINQ to SQL DataContext in a minute (as fast as my computer and IDE can keep up).

6. Performance in the general case doesn't become an issue. SQL Server optimizes queries quite well these days, just like stored procs.  Of course, there are still cases where stored procs are necessary for performance reasons.  For example, I've found it smarter to use a stored proc when I had multiple interactions between tables with additional logic inside of a transaction. The communications overhead of trying to do the same task in code, in addition to getting the DTC involved in a distributed transaction made the choice for a stored proc more compelling. However, for a query that executes in a single statement, LINQ is my preferred choice because even if there was a small performance gain from a stored proc, the benefits in previous points (IMO) carry more weight.

7. Built-in security. One reason I preferred stored procs before LINQ was that they forced the use of parameters, helping to reduce SQL injection attacks. LINQ to SQL already parameterizes input, which is just as secure.

8. LINQ is declarative.  A lot of attention is paid to working with LINQ to XML or LINQ to SQL, but LINQ to Objects is incredibly powerful.  A typical example of LINQ to Objects is reading items from a string[].  However, that's just a small example.  If you think about all of the IEnumerable collections (you can also query IEnumerable) that you work with every day, the opportunities are plentiful.  i.e. Searching an ASP.NET ListBox control for selected items, performing set operations (such as Union) on two collections, or iterating through a List and running a lambda in a ForEach of each item.  Once you begin to think in LINQ, which is declarative in nature, you can find many of your tasks to be simpler and more intuitive than the imperative techniques you use today.

Too much theory lets now jump into writing queries in SQL and equivalent query in LINQ:

1. SELECT Queries:

a. SQL : 

              SELECT *  

              FROM TableName;

b. LINQ : 

               FROM AliasName in ConnectionStringObjectName.TableName

               SELECT new { AliasName };

2. SELECT Specific Columns Queries: 

a. SQL :

             SELECT Column1], [Column2], [Column3] 

             FROM TableName;

b. LINQ :

              FROM AliasName in ConnectionStringObjectName.TableName

             SELECT new { AliasName.Column1, AliasName,Column2, AliasName.Column3};

3. Using WHERE Clause:

a. SQL : 

             SELECT *

             FROM TableName

             WHERE [ColumnName] = Value;

b. LINQ : 

                FROM AliasName in ConnectionStringObjectName.TableName

                WHERE AliasName.ColumnName=Value

                SELECT new {AliasName};

4. Count Queries:

a. SQL :

              SELECT COUNT(*) AS AliasName

              FROM TableName;

b. LINQ :

               (FROM AliasName in ConnectionStringObjectName.TableName

               SELECT AliasName).COUNT();