Showing posts with label android. Show all posts
Showing posts with label android. Show all posts

Wednesday, June 7, 2017

Enable TLS 1.2 & 1.1 Xamarin.Android JellyBean & KitKat



  TLS or Transport Layer Security is a cryptographic protocol that provides communication security over a computer network. If you develop for both iOS and Android you probably know that on iOS by default enforces TLS v1.2 for any application (that, for the moment, you can disable).
  When developing for iOS and Android using Xamarin you will probably end up using the HttpClient class. The default implementation of HttpClient on Mono only has built-in support for TLS v1.0. This is why, in order to use the newer versions of TLS, you would had to implement a class derived from HttpClientHandler that under the hood uses the native classes included in the platform that already support  newer TLS versions . The first choice, for a while, was the ModerHttpClient that NSUrlSession class on iOS and OkHttp on Android.
   Recently Xamarin added its own native HttpClientHandler in both iOS and Android. You can are free to switch from the fully managed one or the native one (which imho is recommended). To set the default implementation you will have to go in the project's settings dialog.

    There a small detail for the Android native implementation.  The Xamarin TLS document tells you that v1.2 is only supported for Android >= 5.0 . On the other side if you go to Wikipidia TLS Document you will see that TLS v.1.1 & v1.2 are supported by Android >= 4.1 but they are not enabled by default until Android 5.0.
  If you try to use TLS v1.1& 1.2 on an Android device version >4.0 & <5.0, as these protocols are not enabled by default you will get an "Connection closed by peer" exception.
     There is actually a simple solution for this problem: in order to enable TLS v1.1 & 1.2 in Android JellyBean & KitKat you will have to implement a class derived from SSLSocketFactory and enable the protocols and than change the factory that AndroidClientHandler uses by default. This can easily be achieved by using a implementing a class derived from  AndroidClientHandler where you will override the method SetupRequest and change the SSLSocketFactory with our own implementation that enables TLS v1.1 & 1.2 on the SSLSocket it creates:


  public class AndroidCustomClientHandler:AndroidClientHandler
    {
        CustomTlsSSLSocketFactory _customTlsSSLSocketFactory=new CustomTlsSSLSocketFactory();
        protected override System.Threading.Tasks.Task SetupRequest(System.Net.Http.HttpRequestMessage request, Java.Net.HttpURLConnection conn)
        {
            if (conn is HttpsURLConnection)
            {
                if (Android.OS.Build.VERSION.SdkInt < Android.OS.BuildVersionCodes.Lollipop)
                    //Enable support for TLS v1.2
                    ((HttpsURLConnection)conn).SSLSocketFactory = _customTlsSSLSocketFactory;
            }
            return base.SetupRequest(request, conn);
        } 
    }


where CustomTlsSSLSocketFactory is this:


public class CustomTlsSSLSocketFactory : SSLSocketFactory
 {
  readonly SSLSocketFactory factory = (SSLSocketFactory)Default;

  public override string[] GetDefaultCipherSuites()
  {
   return factory.GetDefaultCipherSuites();
  }

  public override string[] GetSupportedCipherSuites()
  {
   return factory.GetSupportedCipherSuites();
  }
  public override Java.Net.Socket CreateSocket(Java.Net.InetAddress address, int port, Java.Net.InetAddress localAddress, int localPort)
  {
   SSLSocket socket = (SSLSocket)factory.CreateSocket(address, port, localAddress, localPort);
   socket.SetEnabledProtocols(socket.GetSupportedProtocols());

   return socket;
  }

  public override Java.Net.Socket CreateSocket(Java.Net.InetAddress host, int port)
  {
   SSLSocket socket = (SSLSocket)factory.CreateSocket(host, port);
   socket.SetEnabledProtocols(socket.GetSupportedProtocols());

   return socket;
  }

  public override Java.Net.Socket CreateSocket(string host, int port, Java.Net.InetAddress localHost, int localPort)
  {
   SSLSocket socket = (SSLSocket)factory.CreateSocket(host, port, localHost, localPort);
   socket.SetEnabledProtocols(socket.GetSupportedProtocols());

   return socket;
  }

  public override Java.Net.Socket CreateSocket(string host, int port)
  {
   SSLSocket socket = (SSLSocket)factory.CreateSocket(host, port);
   socket.SetEnabledProtocols(socket.GetSupportedProtocols());

   return socket;
  }

  public override Java.Net.Socket CreateSocket(Java.Net.Socket s, string host, int port, bool autoClose)
  {
   SSLSocket socket = (SSLSocket)factory.CreateSocket(s, host, port, autoClose);
   socket.SetEnabledProtocols(socket.GetSupportedProtocols());

   return socket;
  }

  protected override void Dispose(bool disposing)
  {
   factory.Dispose();
   base.Dispose(disposing);
  }

  public override Java.Net.Socket CreateSocket()
  {
   SSLSocket socket = (SSLSocket)factory.CreateSocket();
   socket.SetEnabledProtocols(socket.GetSupportedProtocols());

   return socket;
  }
 }


You can see that I've chosen to enable all the supported protocols, but a better approach would be to enable just the ones that you actually use.

Hope you will find it useful!

I almost forgot the most important part: When you initialize your HttpClient you will have to pass an instance of your AndroidCustomClientHandler class:


 HttpClient _client = new HttpClient(new AndroidCustomClientHandler()) { BaseAddress = _baseAddr };

Wednesday, June 10, 2015

Manually install Google Apps on Hyper-V Android emulator

    One of the "hot" new features of Visual Studio 2015 is the new Android Hyper-V emulator. It is an awesome feature as you have a highly performant Android emulator running on the same virtualization engine as the Windows Phone emulator. 
   It is an x86 virtual machine and similar to other Android Virtual machines like Genymotion, Xamarin Android Player the Google applications and services are not installed by default.
     For the other engines they usually support installing Google applications by drag-drop. You just have to download the Google Apps specific for the version of Android your emulator is running (you can download it from here ) and drop the package on the emulator running. For the moment this feature is not supported in the Hyper-V version (might still coming) but you can do it manually with a simple sequence of instructions. 
    
    This is what you need to do:

1. Download the GApps packages specific for the Android version your emulator is running
2. Unzip the file
3. Open an adb command prompt (if you have the Xamarin Tools installed in Visual Studio 2015 open the menu Tools->Android->Android Adb Command Prompt) and navigate where you have unzipped your files and go to the system folder from the archive.
4. Execute this set of commands:
  • adb remount
  • adb shell chmod 777 /system
  • adb push . /system

What this commands do is remount the system partition of the emulator to be writable and pushes the contents of the system folder from the unzipped package to the system folder on the emulator. This is the only things that you have to do. Just wait a little bit and you will see that the emultator starts to install everything needed. You might need to soft reset the Hyper-V emulator to make everything work (you should be actually prompted to login with your Google account). Before pushing the System folder content you can also delete the packages that you are not using.

Let me know if you have problems or if i works via email or twitter (disabled the comments on the blog because of all the SPAM I am getting)

P.S. If the links to the google apps package are not working just copy the package name and paste it in a search engine of you choice and you will easily find a mirror for the package.

Thursday, January 1, 2015

Using the Android Hyper-V Preview with Visual Studio 2013

   Happy New Year to you all! While I am anxiously waiting to know if I will be renewed today as an Microsoft MVP (btw being MVP is an awesome experience, the MVPSummit was a great experience even if I was expecting to see more new things so if you can get involved and try this experience). Still planning to do the post on BLE background agents but there are so many things to write that I have to find time to write it. Hopefully this will happen soon.
    So this small post is all about running the Android Hyper-V Preview Emulator that comes with the Visual Studio 2015 Preview as a stand-alone emulator and use it with your production machine running Visual Studio 2013 and the Xamarin tools. Even if the emulator is still in preview if you are doing Android and Windows Phone development on the same machine you won't have to reboot your machine without Hyper-V support in order to have a decent Android emulator. Strangely Microsoft decided for this preview that the emulator can install only if you have the preview of Visual Studio 2015. In theory you could run the preview along with Visual Studio 2013 but things are not always perfect so many of you will keep two different instances for VS 2013 and the Preview. In oreder to get the emulator work you will still have to install the preview of Visual Studio 2015 on some virtual machine or secondary machine and copy the needed files.
    The method is pretty simple. All you will need to do is to copy the folder "Microsoft Visual Studio Emulator for Android" that is located inside Program Files (x86) [ %PROGRAMFILES(X86)%] folder to the machine you want to run the emulator on. At this point you have everything you need. Copy the folder at the same location on the other machine. We still need to take two steps before launching the emulator for the first time. Inside the folder that you've just copied there are two files vsemu.vhd and sdcard.vhd that will be used to "generate" the two virtual machines (phone and tablet). Here are the two steps that you have to take:
  1.  Make sure that adb.exe is in your Path as it will be used by XDE.exe
  2. Create a new folder called Android inside the folder "%userprofile%\AppData\Local\Microsoft\XDE" and copy the two vhd each of them two times with the following names:
     vsemu.vhd copied as: vsemulator.phone.android.vhd and vsemulator.tablet.android.vhd
     sdcard.vhd copied as vsemulator.phone.android.sdcard.vhd and vsemulator.tablet.android.sdcard.vhd

     Now we are ready to start the emulator. You won't be able to start the emulator from Visual Studio 2013 the way VS 2015 Preview does but you can start it manually and once you've started it and the adb automatically connects to the emulator you will see it in Visual Studio as a deployable device. Let's not mention that you can actually use the accelerometer, the location, battery simulation and the screenshot (awesome).

     Here are the two commands that you need to run (make a batch on your desktop):

Phone Android Emulator:
"%PROGRAMFILES(X86)%\Microsoft Visual Studio Emulator for Android\1.0\XDE.exe" /name "VS Emulator Android - Phone" /vhd %userprofile%\AppData\Local\Microsoft\XDE\Android\vsemulator.phone.android.vhd /video "720x1280" /memsize 1024 /telemetrySession "14.0;eyJBcHBJZCI6MTAwMSwiRGVmYXVsdENvbnRleHRJZCI6ImJkNmMxNjk2LTQ5ZjUtNDI4My1iZTk2LWUzNGNjZWYwZTA4YSIsIkhvc3ROYW1lIjoiRGV2MTQiLCJJZCI6ImIyOWZlODMwLThhOWMtNDE1Yy04MWExLWFlNTFkNzFiYTUwNSIsIklzT3B0ZWRJbiI6dHJ1ZSwiUHJvY2Vzc1N0YXJ0VGltZSI6NjM1NTU2MTAxODUyMjI0MzA1fQ=="

Tablet Android Emulator:
"%PROGRAMFILES(X86)%\Microsoft Visual Studio Emulator for Android\1.0\XDE.exe" /name "VS Emulator Android - Tablet" /vhd %userprofile%\AppData\Local\Microsoft\XDE\Android\vsemulator.tablet.android.vhd /video "1080x1920" /memsize 2048 /telemetrySession "14.0;eyJBcHBJZCI6MTAwMSwiRGVmYXVsdENvbnRleHRJZCI6ImJkNmMxNjk2LTQ5ZjUtNDI4My1iZTk2LWUzNGNjZWYwZTA4YSIsIkhvc3ROYW1lIjoiRGV2MTQiLCJJZCI6ImIyOWZlODMwLThhOWMtNDE1Yy04MWExLWFlNTFkNzFiYTUwNSIsIklzT3B0ZWRJbiI6dHJ1ZSwiUHJvY2Vzc1N0YXJ0VGltZSI6NjM1NTU2MTAxODUyMjI0MzA1fQ==" /noStart

You won't probably need the /telemetrySession but this way you could give back some feedback (I guess). Also the first time you run the emulator it will ask permission to configure the Internet on the device and of course you will have to accept.

Also while digging to make this work I found out that the source code of the Android Preview Emulator is published here:  http://aka.ms/getsource . In the same place there is also the source code for the Microsoft Wireless Display Adapter. It looks like it is running on Linux kernel with a pretty decent CPU and we might get some new features other than a simple Miracast adapter.

Until my next blog post: NAMASTE and again HAVE A GREAT NEW YEAR!






Friday, October 24, 2014

Using Cordova/PhoneGap with Xamarin Android

    Since I haven't found a lot of informations on this matter searching with Google I've decided to share my solution and, maybe, save some time for some of you. The target of this post is to get the Cordova / Phonegap running inside an Xamarin Android project on an Android device.

    In order to use Cordova inside an Xamarin project you would first need to build the Cordova framework.  What I did was to clone the repository Cordova Android and then follow the Building without the Tooling instructions.

      Once you have the cordova*.jar we can start binding the library using Xamarin. Do to that you will have to create a new Project using Xamarin Studio (this does not work in Visual Studio) and select the Android Java Bindings project type:


       The structure of the project is pretty simple. Add the Jar to the Jars folder and ensure the Build action is set to EmbeddedJar and try to build the project.



  You will get some errors compiling but luckily these errors are on components we don't need to bind to. So what you have to to is to edit the Metadata.xml file inside the Transforms folder and add the these two internal packages that we want to ignore:

Doing that will enable to correctly build the binding project.

    Now that we have the binding we can test it. For this I have build a test Project and copied the test www container from the github repository.  It took some while to make it work but everything seems to run as expected. I didn't have time to implement all the activities from the sample but only some of them. It should be pretty easy to port also the others if needed. This sample also uses a custom plugin that launches activities when the button on the main screen get pressed so you should basically have all that you need to start using Cordova with Xamarin. When you launch the project you should see this screen on your device/emulator:



These are the items implemented in the Test project: Backgroundcolor, Basic Authentification, Full Screen, HTML not found, Iframe Lifecycle, Menus & Splashscreen

Here is the link to my Github repository that contains the Binding project and the Test project. This sample is using Cordova 3.7.0


Contact me if you need help

P.S. Still preparing the 3rd post on BLE and it will be the most interesting one as it will be on running in the background.

NAMASTE!





Monday, February 4, 2013

How to use Team Foundation Service with MonoDevelop

  As you probably know Team Foundation Service team announced a few days ago full support for Git protocol. This was AWESOME news for our small company that needed a FREE source control solution for our MonoTouch and Mono for Android projects. We were already using visualstudio.com for our Windows Phone and Windows 8 projects and previously to Git support in TFS we had an in-house svn server but I was not really happy with it. The thing it took me most was to understand what is the Git endpoint address than everything is standard.
  Here is a quick guide on how to create and then use a TFS Git repository with MonoDevelop:
  1. First you need to create a new Team Project with Git support 
     
     Once the project is created press the "Navigate to projec"t button. 

2. Go to Code explorer and you will be able to see the the Git endpoint address. It might not show the git endpoint the first time but if you navigate away and try again you will see it.


3. Use the Git endpoint address to register a new Repository in MonoDevelop



4. Then just publish your solution using the registered repository. You can see all your files in Code Explorer and also all the commits:




Tip: If you want to use a more simple user name than you full live id you can enable your Alternate Credentials on the User Profile page 


The same Git endpoint can be also used to "Connect to a repository" in Xcode for your Obejctive C projects.

Thank you TFS TEAM for this great feature.


NAMASTE

Thursday, September 6, 2012

Phone Call screen in Windows Phone

   I've wanted to write this post for quite a while but I've always postponed it as it is a very subjective matter. In the end I decided to write my opinion. Windows Phone is really great but there are some aspects that could be improved and seem that have been designed in a hurry and never finished. One of this aspects, and it is not what this post is about, is the Application List. It is ugly and not very usable. How is it possible that Windows Mobile had before anyone else folders/groups but they are still missing in Windows Phone after more than 2 years? The application list really needs improvements/redesign.
    This post instead is about the Phone call screen. I've have always had problems with my windows phone devices starting with the Omnia 7 and ending with my Lumia 800 (I've actually tried 3 different Lumia 800 all of them gave me the same problem). The short story is that I am able to drop the call with my face by pressing the Endcall button, put the call on speaker, put it on mute or hold. I am not the only person that has these problems: my wife has the same problem with her new Lumia 710 and also heard from other people. It is a combination between the proximity sensor that activates the screen and the way I am holding the phone. So I've wondered if maybe there is a better location for the Endcall button.
    Lets start with a photo I've found on the web  (have no idea who she is) :
 
If you look at the way she is holding her phone (which I think is 90% of the cases) the upper part of the screen is in contact with the face. Let's presume that by a faulty behavior (bad driver, hardware fault, OS fault or the fact that the hardware and the software are not designed by the same company) the screen turns on while you talk. The highest probability to touch the screen with the face is in the upper half of the screen. Let's see what it means in Windows Phone:
So it is Endcall, Speaker, Hold, and Mute (exactly my case).

If you look again at the picture you can see that the less exposed part of the touchscreen(so the better choice for the buttons location)  is the lower part of the screen. The lower you go the smaller the probability is, so the best choice for the End call button is the lower part of the screen (this way you minimize the probability to press the button on faulty behavior). This is exactly (I don't know if this is the reason) what iPhone and Android did:
Both of them have chosen to put the End call button near the lower part of the touch screen. For Android (which also depends on the hardware implementation) Google concentrated all the buttons at the lower part of the screen. On the iPhone they kept the other buttons in the center region but they do have really good control over the hardware and putting a call on hold or mute is not as bad as dropping the call.
So it would be better to move the buttons in the lower part of the screen. The blank space could be filled with social information, last call, email, sms. 
Hope we will see some improvements in Phone Call screen in Windows Phone 8
NAMASTE

Sunday, January 1, 2012

The need for a different Marketplace

My grandmother always said that in the first day of a new year you should do what you would like to do the rest of the year. Even if the last year I didn't had a lot of time to blog I always wanted to so here I am wanting to start the year with my blog.
So what is wrong with the current version of the Marketplace? I could say nothing really, but there is so much that could be improved/changed. I am referring here to the marketplace of all major mobile platforms: Android, iOS and Windows Phone. They are more or less the same. Right now I have experience as a developer with Windows Phone marketplace and as a customer/consumer with all three of them. The marketplace was/is one of the greatest marketing/selling instrument in the software industry. In theory it gives the opportunity to everyone to sell their ideas/software all over the world. I say in theory because it enables developers to do that, but it doesn't make it easy.
One of the biggest problems I see for the moment is the number of applications. I am looking at the Microsoft "race" to catch up with the number of applications in the marketplace. In this race the number is the priority and the quality comes second. The result of this race is that the marketplace get filled with "junk". It is the same situation on all the three platforms, but today the analysts judge the success of a platform by the number of apps in the marketplace. Let's face it there are 500.000 application in the Apple marketplace and, maybe, not even 10% are quality apps. When I say junk I say applications that don't bring any innovation, written as fast as possible and thrown into the wild just to have an application out there. From my experience (I have a small application in the marketplace) in order to have a decent application there is a lot of work to be done in developing and maintaining it. Having so many applications in the marketplace "kills" the opportunity marketplace gives you if you have a quality app because it makes it almost invisible. If today you have a quality app and you publish it will be there with (I will take the Windows Phone marketplace numbers published by http://wp7applist.com/en-US/stats/ today 01.01.2012) other 451 applications published the same day. Does you application stand any chance? Some will say yes, I would say the more apps are in the marketplace the harder will be. You can only count on the people that are trying new applications. So inevitable a quality app will go down (maybe a little bit slower ) with the others and you have to find other methods to get it "visible". Another consequence of having a lot of applications published every day without a quality check is the degrade in the service offered to developers. I remember that when I wrote this post: http://sviluppomobile.blogspot.com/2011/01/windows-phone-marketplace-more.html the quality of certification the service was great. Things changed a little in the last two months (I think they had an increase in the number of applications to certify) the certification time jumped from two days to more than a week. More frustrating is seeing applications like this one published in "bulk":


So is it worth having thousands of applications without any quality filter (just rules on how to write your app)? I would prefer a quality marketplace, but maybe having both is better. It's like when you go to the market to shop: if you want products that cost less you go in one place, if you want quality products you go to another shop, if you just need one product you go in the first shop you find. The marketplace in the marketplace could improve a little bit on the quality part. It would need quality reviewers that would select the apps for the "quality" marketplace. It is easier than to go on all review websites and look for top applications on each platform. A place in the marketplace where you go when you don't know what you really want but you would like to try some quality applications. Apple, Google and Microsoft should not be the quality reviewers but continue to do what they do and then the best reviewers/websites on each platform should intersect their chosen applications (easy to say and hard to do). It is not a bullet proof mechanism.
Other suggestion regards the reviews specifically bad reviews. In this moment if you want to make a concurrent application go down you just go and slowly start to make bad reviews in all the marketplaces. (it is a situation I am dealing with). I would suggest that, if someone makes a bad review and give one or two stars, he should be "forced" to write a reason. This should help the developers understand the problem, and, if it's not true at least ask the review to be removed. Also the reviews should be disabled when the application is hidden. For the hidden applications the reviews don't make any sense.
Being able to publish a beta version of the application in the marketplace is an awesome feature, but in this moment, for me is almost useless. You have to find your beta testers, but it is a difficult task. So there should be an "open" beta option. This way anybody that wants to test the beta and has a link to it can do it with a limit of 100 users (more or less like the hidden apps but limited to a number of users).
In my opinion 2011 was a great year for Windows Phone even if the market shares don't reflect it . The 7.5 version is a great step forward and I hope that 2012 will bring us another big step. I still think that the application list is "ugly" and not really usable, we need some way to group applications (maybe an evolution of the "folder" concept).
I really hope Microsoft will make Apollo an EVOLUTION and not a REVOLUTION.

Happy New Year to all my readers! A better year to everyone.

NAMASTE

Tuesday, June 7, 2011

iOS 5 HTML5 Speed Reading

   It's hard to start a post when it passed so much time from the last one. So much things to say but when you want to write about them you realize that are not so important/innovative/interesting or at least worth reading about.
   I remember back in April at Mix Keynote when they presented the IE9 mobile edition that Apple was the worst performer in the tests. This is a small part of the Mix keynote where they show how the various devices perform:



          So ever since April I was curious how much time will it take Apple to get back on the track with Safari mobile browser. Luckily I am the "proud" owner of an iOS developer account with no application published on the App Store (I will blame time and now Novell as I had to change my Macbook on which I had activated the Monotouch license and now it's GONE as nobody answers of that part anymore. I can only hope that Miguel and his team will "cook" a new product as soon as possible. All the money we've spent on Monotouch and Monodroid are now a dead investment). But let's get back to the post.... So today I've downloaded the first beta of the iOS 5 and deployed it to my iPhone 4 and ... SURPRISE... after not even two months the Safari browser outperforms Android and Windows Phone 7 (the way they were two months ago). Here is a small video with the test I ran:


         I can hardly wait to be able to install Mango on my device and it seems that this could happen at the end of June for developers (keeping my fingers crossed). In that case Apple and Microsoft are definitely winning a small battle against Google. It is very important to give the tools developers need when they need them and this is not when the phones ship (being able to test on a real device it's a MUST). While for Apple it is an easy battle to win as they develop the hardware so they decide what to do, Microsoft on the other side has to convince the hardware OEMs and the mobile operators to let developers get early access to Mango and also find a way to make it "work" on all the Windows Phone 7 devices available today .
     iOS 5 brings a lot of interesting new features and I agree that some of them are similar/inspired/copied from Windows Phone 7, but if that makes the product better Microsoft should copy and improve some of the iOS features. Here are some things that I still don't like in WP7 :
  • the most annoying in this moment is the email client that doesn't go to the next email when I delete one but comes back to the inbox and make me lose a lot of  time (for the moment I have mobile internet only on my Omnia 7)
  • I still don't like the application list even if now you can use search or jump list
  • HATE the InCall experience with small buttons and the "half" window (I don't understand why)  that doesn't make sense as you usually will push with the face the outer area and the window will go to background or even more annoying instead of closing the call you will send it to the background 
NAMASTE

Thursday, December 16, 2010

A phone lifetime: an epic battle between Microsoft and OEM

     Looking back at my blog it seems pretty dead, but I intend to catch up as I am on vacation traveling to Brazil and Bolivia so I have some spare time for writing. It's more than a month since I finished the Dropbox client library (that I will soon post on Codeplex) and also Boxfiles for Dropbox which is the application I am trying to publish on the Marketplace. The whole publishing process was (still is as the app is not yet certified) quite an adventure and even with the support of Microsoft Italy, which I thank, it can take up to one month to have a "functional" AppHub account.
    Getting back to the title of the post. I don't know if there is/will be a battle between Microsoft and the hardware OEM, but I really hope so. I am referring to updating your windows phone 7 device. There are already rumors on the web about the "Mango" release and also about Windows Phone 8. From this point of view Apple has a winning strategy. Buying an iPhone gives the owner the certainty that his device will be up-to-date for at least 2 years (2 major releases- the one installed on the phone and the next one). On the other side there is Google and Android where the majority of the OEM choose not to update the phone OS version even if it's a minor release like 2.1 to 2.2 so in less than 6 months you will have an outdated OS. In this moment having an updated iPhone costs less in two years than having an updated Android phone. So what will be Microsoft position for the new Windows Phone? In the previous version of their mobile platform users were usually left behind between OS version updates (or to be more precise left at the OEM mercy), but the releases of updates/new versions were not so frequent which lead to the "death" of the platform on the consumer side and focus on the enterprise side were having and updated device is not so important.  I hope that Microsoft will battle to bring updates to the OEM devices for at least 2 years which is a logical choice as almost every phone operator will give you a device at an affordable price if you sign-up for at least 24 months. That would be a big plus in the battle with Android platform. 
        So who will win? Microsoft or the OEM? Will Microsoft be interested to update the devices for 24 months and loose some earning from OS licenses but give the users more confidence with the platform and compensate with Marketplace earnings?  My feeling is that the devices out now will be obsolete in one year and won't get any updates.  Maybe this is one of the reasons why the sales are not as good as everyone expected them to be: it is the first version, things are still missing and if I buy a phone now it will not be updated to the next version. Will see...


NAMASTE

Wednesday, March 17, 2010

WP7 Series - Phone Interface

Back in February I was really upset when they didn't show the phone interface of the new WP7. For me it is still the most important part of a Phone. Today, when I saw the videos published on Engadget I understood why... Not only that it looks unfinished, but it's like they didn't really start developing that part. Why did they invest a lot of work in the XBox Live hub (avatar movements with the accelerometer) and they didn't developed a decent CTP phone interface ? (it could be my impression but they focused too much on Zune aspects - Joe Belfiore was on the Zune team right? - I once said that it looks more like iPod Touch for the iPhone instead of the iPhone itself). Don't understand me wrong... I like a lot the new WP7 but it lacks so many things that it seems a step backward. I was disappointed when Microsoft launched WM 6.5 from a developer point of view (a year after the release of 6.1 there were not many new things added) but I always thought that they were investing everything on WM7. I think a lot of developers hoped for more as they are investing time and resources developing on Microsoft mobile platform (I don't think Microsoft can afford loosing developers on the mobile platform)

But let's go back to the phone interface. I always thought that Microsoft will learn from the mistakes he made and will get a decent phone interface. Let's start with Windows Mobile 6.1:


It is a really ugly phone interface (useless to say that it was released after WM 5 phone interface which was the same). Really small buttons that usually you will have to use the pen to dial a number, a lot of space used without being optimized, informations missing.
HTC understood that this interface was a real problem for selling massmarket devices so they rewrote the interface:

they used bigger buttons, better phone dial-pad, but still a lot of space was not optimized (also because of the OS that didn't let them to)
After they saw the "decent" phone interface developed by HTC Microsoft didn't learned too much and released in 6.5 a better interface than the standard in 6.1 but worse than the one created by HTC


Why don't they learn from the iPhone or even Android? In my opinion the phone interface of the iPhone is the most usable one.


Really nice big buttons that you can press easily, essential information (I can always see the clock cause I want to know if it's not too late when I am dialing someone, or if someone calls me), the battery power and also the power of my radio signal. Nice modern UI. Anyway I think both iPhone and Android interface could be improved.

Let's see a little the WP 7 Phone interface as it is today:

The button size is ridiculous, a lot of unused space, essentially information missing. The only thing that I like is the dial-pad buttons. Remember that your potential client is buying a phone and after that everything that comes with it. If it isn't a decent phone he won't buy it.

I hope someone from Microsoft will read this post and start treating the phone interface as one of the most important pieces of the device (especially now that the OEM will not be able to personalize it). You got the background right (with silverlight you can develop awesome UI), so don't ruin it. We, developers, need that you get WP7 right as some of our work depend on it.

P.S. Going home to watch episode 8 from Lost - The final season Simplified by Windows 7 :)