A long time without blogging but it was a really full period. I would love to have more time for writing and testing, but I have some "stressing" deadlines.
As you probably know Microsoft released the new version of the Windows Phone 7 Development tools and there is a new version of the emulator. The old "unlock method" still works and there is already an unlocked version on XDA Developers and you can download the image here. The new version of the bin doesn't work on the old XDE emulator because there seem to be some changes in XDE hardware emulation. The unlocked image pretty snappy and there are also some new programs.
The best thing is that the unlocked emulator image works for debbuging in VS 2010 on my newly installed Windows 7 x64 on myApple macbook (I've reinstalled 3 times the macbook last week cause I configured more partitions for windows and I finally managed to replace my old Asus notebook). One of the things I've noticed is that an "empty" application uses 12 MBytes of RAM which seems a lot for an app that does nothing.
Hope I will have more time for testing! Have fun with the new tools
Friday, April 30, 2010
Thursday, April 15, 2010
WP7 IsolatedStorage Backup/Restore
One of the drawbacks of the WP7 Emulator is that it doesn't save the state between sessions and also it is difficult to deploy a file with your project and then use it. This means that every time you start a new session of the emulator you loose all the data on the IsolatedStorage.
I've developed a small solution (there is room for improvement) for backing-up and restoring the files (folder structure included) of the IsolatedStorage. It is using an WCF service that stores/sends file content from/to the IsolatedStorage in/from a folder named Backup located in the WCF project folder. For optimizing the communication the service uses binaryMessageEncoding. It also splits the files in 100Kbytes parts (you can modify this size from the source code if you want bigger parts- it will be faster) .
The solution is easy to use even if it took me a lot of time to make it work (especially the readerQuotas, maxBufferSize, maxStringContentLength). In fact I was having "fun" with it at 3 o'clock in the morning. If you want to backup your IsolatedStorage just hit backup and it will write the content of IsolateStorage in the Backup folder of the pc. If you want to restore/copy files to the IsolatedStorage copy the files/folders you want to the Backup folder of the PC and then hit Restore and it will copy all the data to the IsolatedStorage.
Hope you'll like it! Don't forget to modify the ServiceReferences.ClientConfig before you run the project
I've developed a small solution (there is room for improvement) for backing-up and restoring the files (folder structure included) of the IsolatedStorage. It is using an WCF service that stores/sends file content from/to the IsolatedStorage in/from a folder named Backup located in the WCF project folder. For optimizing the communication the service uses binaryMessageEncoding. It also splits the files in 100Kbytes parts (you can modify this size from the source code if you want bigger parts- it will be faster) .
The solution is easy to use even if it took me a lot of time to make it work (especially the readerQuotas, maxBufferSize, maxStringContentLength). In fact I was having "fun" with it at 3 o'clock in the morning. If you want to backup your IsolatedStorage just hit backup and it will write the content of IsolateStorage in the Backup folder of the pc. If you want to restore/copy files to the IsolatedStorage copy the files/folders you want to the Backup folder of the PC and then hit Restore and it will copy all the data to the IsolatedStorage.
Hope you'll like it! Don't forget to modify the ServiceReferences.ClientConfig before you run the project


As usual you can download the Source code
Etichette:
Backup,
IsolatedStorage,
Restore,
WP7
Monday, April 12, 2010
WP7 IsolatedStorage Speed
I was wondering if it makes any sense fully implementing SQLite on IsolatedStorage as the "quality" of the db support will depend a lot on the speed of of the storage. I read on some posts that the speed of IsolatedStorage was a problem, but I've wanted to compare it with the speed of the Filestream. The problem is that you cannot compare the two directly so I had the idea to compare both of them with another "item" that is available on both systems. I've chosen a MemoryStream test as a constant. I am not making the same test between MemoryStream and IsolatedStorage or between MemoryStream and FileStream as I am not interested on how much faster is MemoryStream (that's why on the real device FileStream seems faster then MemoryStream but it's not true as it is not the same amount of data). I run the test for 10 times and then make an average (to have a more precise result)


Dividing IsolatedStorage/MemoryStreamSpeed=8.5991/1.2251=7.019 and FileStream/MemoryStream= 0.7/12.7=0.05511. To get an idea about the speed differences we devide the two results and we get 127.3634 which means that the IsolatedStorage is 127 times slower than FileStream. Of course this is not an exact result, but should reflect the speed difference. I might have some "glitches" in the tests but I cannot figure them out. If this result is at least near to the real one it doesn't make any sense to implement db engine on IsolatedStorage.
Another thing that I've noticed is that the x86 implementation of WP7 Emulator is much faster then the ARM emulation of 6.5 Emulator (at least MemoryStream implementation).
You can download the projects here
Another thing that I've noticed is that the x86 implementation of WP7 Emulator is much faster then the ARM emulation of 6.5 Emulator (at least MemoryStream implementation).
You can download the projects here
Etichette:
IsolatedStorage,
Speed,
WP7
Wednesday, April 7, 2010
iPhone Printing using MonoTouch - Proof of concept
Printing from the iPhone (also iPad I presume) it's not an impossible task (as it is in WP7 for the moment). It can be done using a network printer connected to the device using wireless radio (infrastructure or Ad hoc mode). As there is no internal driver for printing developers will have to write an interface to the printer. The "task" is pretty big as there are many programming languages for printers: HP PCL5, Epson ESC/P, PostScript, Zebra Programming Language, ASCII printers and many more. Using socket programing available in MonoTouch it is possible to communicate/print to any network printer, but it would be easier to have a "unified" interface like the ones available on WinCE (PrinterCE, PrintCE), libraries that can be
ported to the iPhone.
The attached sample it's not simple line printing but implements a small part of the PCL5 interface. It will print two boxes and some text on any PCL5 compatible network printer (if you have such a printer you can try it). The only two parameters required are the IP of the printer and the port used for communication (usually 9100).
Let's hope that soon we will see PrinterTouch or PrintTouch library :). If you need more details or find this post useful please let me know.
I will continue my "quest" for developing a small S.F.A. application on the iPhone and/or iPad using MonoTouch.
SocketPrint
ported to the iPhone.
The attached sample it's not simple line printing but implements a small part of the PCL5 interface. It will print two boxes and some text on any PCL5 compatible network printer (if you have such a printer you can try it). The only two parameters required are the IP of the printer and the port used for communication (usually 9100).
Let's hope that soon we will see PrinterTouch or PrintTouch library :). If you need more details or find this post useful please let me know.
I will continue my "quest" for developing a small S.F.A. application on the iPhone and/or iPad using MonoTouch.
SocketPrint
Thursday, April 1, 2010
WP7 CTP SDK or HOW TO GET THE DEVELOPERS FRUSTRATED
Initially this post was about WP7 Printing. Two days ago I thought that it would be nice to write about printing from WP 7 and iPhone and the only "compatible" that I could think of was using a WiFi printer (on the iPhone the bluetooth stack doesn't have implemented the SPP and you have to hack it ). It's something I've already did years ago in Compact Framework when I wasn't using PrinterCE or PrintCe and wanted to share it cause it is a new beginning and at some point in a small business application you will need to print something. (it was a proof of concept).
I got everything prepared and started writing the WP7 app when I saw that in the System.Net there is no socket support. I've started digging up, again, in the emulators files wanting to see if the System.Net file is the same on the emulator with the one in the SDK ("\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone"). What I've found out using Reflector is that there is no System.Net in the emulator image, but all the functionality is implemented in mscorlib.dll and there is also the Socket class fully implemented. What Microsoft did is to "cripple" the assemblies in the OS for the SDK. They made the version to be 2.0.5 (for some of the files) which will make compiled programs run just fine on 3.7 which is the the version on the emulator. mscorlib for example in the development tools is 428kb and on the emulator is 1,18MB. Almost every assembly in the SDK is "crippled". If you want to compare the sizes just download this zip.
I wanted to see if I can pass this restriction but the answer is no because the classes that are not available in the SDK assemblies on the emulator are compiled with the tag [FrameworkVisibilitySilverlightInternal, SecuritySafeCritical] (there is more than one tag) which results in a MethodAccessException if you try to use it.
Printing just turned out into frustration. Sockets are there, database support it's there, Microsoft can use it but developers cannot. It's not that it is not implemented (like copy/paste), but somebody decided that it's not safe to use them. On WP7 forum somebody said that this functionality could compromise the user experience and it is not ready for prime time. It is strange cause we have being using sockets and database in NETCF programs for years and never influenced the user experience or seemed not ready.
WP7 is a nice platform but developers don't have what they need, and some of this it's because Microsoft decided that they don't need it. WebIS don't have what they need, Resco also, Mozilla stops development on WM and one week later they have an Android beta version, Skype don't have a WM version anymore should be enough reasons to change attitude.
Microsoft needs developers
I got everything prepared and started writing the WP7 app when I saw that in the System.Net there is no socket support. I've started digging up, again, in the emulators files wanting to see if the System.Net file is the same on the emulator with the one in the SDK ("\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone"). What I've found out using Reflector is that there is no System.Net in the emulator image, but all the functionality is implemented in mscorlib.dll and there is also the Socket class fully implemented. What Microsoft did is to "cripple" the assemblies in the OS for the SDK. They made the version to be 2.0.5 (for some of the files) which will make compiled programs run just fine on 3.7 which is the the version on the emulator. mscorlib for example in the development tools is 428kb and on the emulator is 1,18MB. Almost every assembly in the SDK is "crippled". If you want to compare the sizes just download this zip.
I wanted to see if I can pass this restriction but the answer is no because the classes that are not available in the SDK assemblies on the emulator are compiled with the tag [FrameworkVisibilitySilverlightInternal, SecuritySafeCritical] (there is more than one tag) which results in a MethodAccessException if you try to use it.
Printing just turned out into frustration. Sockets are there, database support it's there, Microsoft can use it but developers cannot. It's not that it is not implemented (like copy/paste), but somebody decided that it's not safe to use them. On WP7 forum somebody said that this functionality could compromise the user experience and it is not ready for prime time. It is strange cause we have being using sockets and database in NETCF programs for years and never influenced the user experience or seemed not ready.
WP7 is a nice platform but developers don't have what they need, and some of this it's because Microsoft decided that they don't need it. WebIS don't have what they need, Resco also, Mozilla stops development on WM and one week later they have an Android beta version, Skype don't have a WM version anymore should be enough reasons to change attitude.
Microsoft needs developers
Monday, March 29, 2010
MacBook, Windows 7 & MonoTouch
Last Friday I got myself a MacBook (it is my first one) and I gotta say that I am pretty impressed with the performance. I made the investment after seeing that it's not good to "invest" everything in just one mobile platform (in a dynamic market it's important to adapt). The first two things that I've done was to install MonoTouch trial (for iPhone development) and Windows 7 (for WP7 and Silverlight development). In W7 with all the drivers installed I have a 5.2 rating which is far better than my 2 year old laptop that I've paid 1.200 Euro (the MacBook was 899 Euro). The iPhone will still have to wait till I finish porting our S.F.A. application. I like this phone but I consider it too expensive (paying 600 Euros for an iPhone and 899 Euro for a Macbook is not balanced)
With Monotouch writing the "classical" Hello World application was really simple and you can also watch this YouTube movie. There is a lot inside the MonoTouch WiKi : database, webservices, WCF, GPS, and much more.
I really like MonoTouch and they are also working on MonoDroid.
Thursday, March 25, 2010
Good strategy Microsoft
The more I think about it the more I am convinced that Microsoft intentionally let the "trace" in the registry so someone could easily restore the functionality (they are creating the links and then delete them but they could have just released the registry without any link inside). Imagine if Microsoft would have released the emulator with everything enabled the first instinct would have been to say that around 60% of the functionality is not implemented so bad publicity. Instead they lightly "obfuscate" the ROM and leave the key in a file that can be easily accessed. This way when the modified ROM is released everybody is so pleased to have more than 2 programs that will blog/talk only about the parts that work and also have feedback (let's not forget that we hear talking about Windows Phone 7 for more than two years in which they could have achieved much more - personal opinion). They say a lot that this is the first version but what happened to the teams that developed the other versions? When Apple or Google released their mobile OS's they had the right to say that is the first version, but Microsoft has 10 years of experience in the mobile world (Pocket PC 2000 was launched in April 2000) and a lot of feedback from the users so they cannot say it's the first version like an excuse (better just say we are working on the missing features). I agree it's a revolution in user experience and development and I like it.
I am quite sure that we will see some of the most requested features in the summer Beta (native SDK, copy/paste, database support) and everybody will be happy. Microsoft is on the right track, but there is still a lot to be done.
P.S. Do I watch too much Lost :) ?
Subscribe to:
Posts (Atom)