Visual Studio 2005 ile birlikte sistemimize Mobil Uygulama Geliştiricilerin hayatını kolaylaştırabilecek bazı “küçük” uygulamalar yüklenmektedir. Bu uygulamalar tamamen izole ve birbirlerinden farklı amaçlar üzerine geliştirilmiş ; Emülatörler ve Fiziksel cihazlar üzerinde çalışabilmektedirler.

Genel hatlarıyla ;

Remote File Viewer

Remote Heap Walker

Remote Process Viewer

Remote Registry Editor

Remote Spy

Remote Zoom In

Şeklinde sıralanabilecek bu küçük uygulamalar normal şartlarda 3rd party uygulamalar kullanılarak yada mobil cihazımızın sınırlı ekranı üzerinden zahmetli bir şekilde gerçekleştirilebilerek yapılan işlemlerde kullanıcılara masaüstü rahatlığı sağlamaktadır. Bu makale serimizde ise liste üzerinde sıraladığımız uygulamalar ile ilgili kısa açıklamalarda bulunacağız.

Şimdiki durağımız Remote Zoom In. RZI genel hatlarıyla uzaktaki bir cihazın ekran görüntüsü almaya – bu görüntüyü yazdırmaya ve kaydetmeye yarayan yardımcı bir uygulama olarak özetlenebilir. Uygulamanın hangi noktalarda kullanılabileceğine gelinirse ; makalelerde, proje sunumlarında, kitap yazarken v.b. gibi süreçlerde mobil cihazımızın anlık ekran görüntüsüne ihtiyaç duyduğumuzda kullanılabilir. Küçük bir örnekle uygulamayı tanımaya başlayalım.

Uygulamamızı Başlat – Programlar – Microsoft Visual Studio 2005 – Visual Studio Remote Tools – Remote Zoom In seçenekleri üzerinden başlatıyoruz. Karşımıza diğer Remote Tools uygulamalarında olduğu gibi hangi mobil cihaz üzerinden bağlantı kurulacağını soran bir seçenek penceresi çıkmaktadır. Bu pencereden daha öncekilerde olduğu gibi aktif bağlı olan Cihaz / Emülatörü seçerek devam ediyoruz.

OK’ e tıkladığımızda uygulama o an aktif bağlantısı olan Cihaz / Emülatörün ekran görüntüsünü almak üzere bir Progress Bar çıkarmaktadır.

İşlem tamamlandığında :

Şekildeki gibi ekran görüntüsünü uygulamamız sistemimize yüklemektedir.Bundan sonra yapılabilecekler menü üzerinden New Bitmap seçeği üzerinden görüntüyü tazelemek olacaktır.

Emülatör üzerinde değişiklik yapıldıktan sonra New Bitmap seçildiğinde Yeni ekran görüntüsü sistemimize kopyalanmaktadır. Kullanıcılar bu görüntüyü File – Print seçenekleri üzerinden Yazdırabilmektedirler.

Ayrıca Save As seçeneği üzerinden görüntüyü sistemleri üzerine kaydedebilmektedirler.

Bir makalemizin daha sonuna geldik. Bir başka makalede daha görüşmek üzere.

Genel hatlarıyla makalemizin konusunun başlığına bundan yaklaşık 3-4 sene önce bakılsaydı birçok uygulama geliştirici için böyle bir sistemi gerçekleştirmek ütopik ; belkide, imkansız olarak düşünülebilirdi. Mobil Cihazlar’ dan öte standart Windows işletim sistemimiz üzerinde Socket’ ler üzerinden haberleşip birbirleri arasında veri transferi gerçekleştiren uygulamalar geliştirebilemek için bile bundan kısa bir süre öncesine kadar yüksek bir programlama bilgisi gerektirmekte ; herşeyden öte işletim sistemimiz üzerindeki API (Application Programming Interface) Fonksiyonlarını bilmemizi gerektirmekdeydi.

Olaya bu açıdan bakıldığında Socket programlama her zaman uygulama geliştiriciler için bir problem ; en azından bir önceki paragrafta belirtildiği üzere yüksek programlama bilgisi gerektiren bir kavram olmuştur.

2000 yılında .Net Framework “dünyası” ile tanıştığımızda ise neredeyse tüm sıkıntılarımız sona ermiş, yepyeni bir platform ile karşı karşıya kalmıştık. Az önce üzerinde konuştuğumuz yüksek porgramlama bilgisi gerektiren birçok kavramı .Net Framework üzerinde çok daha kolay bir şekilde gerçekleştirmenin verdiği rahatlık ve esneklik ile çok daha büyük ölçekli ve hatasız projeler günümüzde birçok platform üzerinde geliştirilmektedir.

Konuyu bu noktada toparlamak gerekirse birçok noktasında olduğu gibi .Net Framework üzerinde Socket uygulamaları geliştirmekte eskiye nazaran çok daha az efor sarfedilerek gerçekleştirilebilmektedir. System.Net.Sockets NameSpace’ i içerisindeki sınıfları doğru yer ve doğru kombinasyonlar üzerinden kullanarak uygulama geliştiriciler .Net Framework üzerinde çok optimize ve sağlam Socket uygulamaları geliştirebilmektedirler.

Peki .Net Framework üzerindeki bu esnek yapıya .Net Compact Framework üzerinde hangi oranda sahip olabilmekteyiz ? Mobil Cihazlar üzerinde Socket uygulamaları geliştirmek günümüzde hala bir ütopyamıdır ?

İşin biraz derinine inildiğinde özellikle 2.0 sürümü ile birlikte .Net Compact Framework kendisine hayranlık bırakabilecek seviyede başarılı ; konumuz ile ilişkilendirdiğimizde ise hayli sağlam bir grafik çizmektedir.

Socket uygulamaların geliştirilmesi bakımından neredeyse .Net Framework ile başabaş giden .Net Compact Framework , .Net Framework üzerinde olduğu gibi işletim sistemi üzerinde tanımlı olan API Fonksiyonlarını kullanan managed metotları uygulama geliştiricilerin kullanımına sunmaktadır.

Bu makalemizde ise sayfalar dolusu teori ile konuyu anlatmak yerine, Masaüstü Bilgisayarımız üzerinde çalışacak olan bir sunucu uygulaması  ile Mobil Cihaz üzerinde çalışacak olan bir istemci uygulamasını baz alan ; Socket’ ler üzerinden birbirleriyle haberleşen bir mobil chat uygulaması geliştireceğiz.

Bu noktada üzerinde çalışacak olduğumuz kavramlardan bahsetmeden herşeyin “neredeyse .Net Framework ile birebir aynı” olduğunu belirtmek daha doğru olacaktır.

Ayrıca uygulamanın geliştirilme aşamasında standart seviyede Socket kavramlarını biliyor olduğunuzu kabul edeceğiz.

Fakat her ne olursa olsun uygulamamızın parçalarını geliştirmeye başlamadan önce her iki platform üzerinde de ; .Net Framework ve .Net Compact Framework üzerinde de neredeyse birebir aynı çalışma mekanizmasına sahip Socket sınıfını ve metotlarını yüzeysel olarak incelemek bu noktada daha doğru olacaktır.

Sizlerinde bildiği üzere Socket ; bir uygulamanın dış dünya ile iletişim kurabileceği bir kapı olarak kafamızda rahatlıkla canlandırılabilir. Bu noktada kapının bir adresinin ; tipinin ve o kapıdan nelerin geçebileceğinin bilgisinin belirlenmiş olması kapının dış dünya üzerinde çalıştırılabilmesi açısından yeterli parametreler olabilmektedir.

Uygulama geliştiriciler Socket’ ler yardımıyla onlarca protokolün onlarca tipi üzerinden farklı uygulamalar ile haberleşebilir ; veri transferleri gerçekleştirebilirler. Bugün işletim sistemimiz üzerinde kullanıyor olduğumuz birçok “internet” bazlı uygulama işletim sistemimiz üzerinde tanımlı olan WinSock Fonksiyonları üzerinden socket kullanımını gerçekleştirmekte ; bizleri dış dünyaya bağlamaktadırlar.

Olaya bu açıdan bakıldığında Socket programlamanın hiçbir zaman kolay olmadığından ;ileri bir programcılık bilgisi ve araştırma gerektiğinden yazımızın başında bahsetmiştik.

Fakat .Net Framework’ e bakıldığında ise bu işin Managed sınıflar üzerinden ne kadar kolay gerçekleştirilebildiğinden yazımızın başında bahsetmiştik.

.Net Framework içerisinde bulunan System.Net.Sockets NameSpace’ i içerisinde bulunan Socket sınıfı bu noktada gerekli tüm altyapıyı biz Managed uygulama geliştiricilere sunmaktadır. Yapılması gereken tek şey gerekli parametreleri belirledikten sonra bu sınıfın üretilen instance’ ı üzerinden ilgili metotları çağırmak ve veri transferlerini gerçekleştirmek olacaktır.

Şu an ki amacımız bu sınıfı .Net Framework üzerinde kısaca tanıttıktan sonra senaryomuzun ilk parçasını ; masaüstü sunucu uygulamamızı geliştirmek ve hemen akabinde herşeyin ama herşeyin %95 oranında .Net Compact Framework üzerinde de aynı olduğunu ifade ederek makalemizin ilk bölümünü tamamlayacağız.

Socket sınıfı ile ilgili Teorik amaçlı anlatıma geçmeden önce bu noktada örnek uygulamamızın ilk adımını gerçekleştirmeye başlamak daha doğru olacaktır.

Amacımız Mobil Cihaz üzerinden bağlanabileceğimiz ; TCP Protokolü kullanılarak oluşturulmuş bir Windows Masaüstü Sunucu uygulaması geliştirmek olacaktır.

Bu amaca uygun olarak Standart bir C# Windows Application projesi açarak işe başlıyoruz.

Bir sonraki adımda şekildeki Windows Formunu tasarlıyoruz.

Amacımız basit bir arayüz üzerinden “Start Server” button’ u üzerinden dinleme durumuna geçen sunucu uygulaması ile Mobil Cihaz uygulamamızı haberleştirebilmek. Bunun için basit bir kaç kontrolü form üzerine ekliyoruz. Orda noktadaki kontrol bir ListBox kontrolüdür.

Sıra geldi kodlar üzerinde çalışacağımız noktaya. 

İlk olarak belirtmemiz gereken nokta şu olmalıdır ki  uygulamamız asenkron mimari üzerinden geliştirilmelidir. Aksi takdirde bağlantı gerçekleştirilmesi safhasından itibaren her mesaj beklendiği süreçte uygulama ekranı kitli kalacak ; uygulama herhangi bir işe yaramayacaktır.

Bu noktada Socket sınıfı üzerinden hazır gelen bazı asenkron metotları kullanarak bu mimariyi oturtacağız.

Hızlı bir şekilde kaldığımız yerden devam edelim. Kod tarafına geçtiğimizde temel olarak basit birkaç “Callback” metodu ve birkaç delege yardımı ile Socket nesnemizi oluşturup ; sunucu üzerinden “Listen” moduna geçireceğiz. Bundan sonraki adımlarda yapılacak olan tek şey mobil cihaz üzerinden bağlantıyı kurup mesajlaşmaya başlamak olacaktır.

İlk olarak bazı nesne referanslarını global scope alanı içerisinde tanımlıyoruz.

Dikkat edilecek olursa listenin en tepesine System.Net.Sockets NameSpace’ i içerisinde bulunan Socket sınıfının bir referansı tanımlanmış ; bir altına bağlantı kurulduğu noktada karşı istemciyi temsil edecek olan Socket’ in referansı ; onun altına ise Socket sınıfının asenkron metotları çalışmayı tamamladıklarında gidip haber verecekleri metotların adresini barındırabilecek bir signature’ a sahip ; AsyncCallBack delegesinin bir referansı tanımlanmıştır.

En alta ise karşı istemciden mesaj geldiğinde mesajın içerisine yükleneceği 1MB’ lık bir alan teşkil eden bir Byte[] tanımladık.

Kaldığımız yerden devam edelim.

Uygulama tasarımımız asenkron mimari üzerine geliştirileceğinden belirli eylemler “asenkron” olarak gerçekleştirildiğinde işlemlerin sonucu işleyebilmek ve uygulamanın yaşam sürecine devam edebilmesi adına bazı görevleri yerine getirebilmek için iki adet CallBack metodu tanımlıyoruz.

Hiç vakit kaybetmeden şekildeki kod bloğu ile ilgili gerekli açıklamaları ifade edelim.

Kolayca anlaşılabileceği üzere CallBack metotlarının kod sayfası içerisinde yerleştirilebilmesi için tanımlanmış Callback Methods isimli Region içerisine iki adet metot tanımlanmıştır. Bu metotlardan kırmızı kutu ile ifade edilen AcceptedCallBack metodu sunucuya Mobil Cihazımız üzerinden herhangi bir bağlantı başarılı bir şekilde gerçekleştirildiğinde çalıştırılmakta ; Socket objesinin EndAccept isimli Asenkron “sonlandırma” metodu üzerinden karşı socket’ i refere eden socket objesi alınmaktadır. Bir sonraki adımda ise RemoteSocket ismiyle alınan bu socket objesinin Asenkron mimari üzerinden BeginAccept metodu çağırılmakta ; kısaca karşı Mobil Cihaz üzerinden mesajlar “uygulamayı kitlemeden” beklenmeye başlamaktadır.

Bir alttaki, turuncu kutu ile ifade edilen metotta ise BeginReceive ile başlatılan bekleme süreci sonlandığında ; yani Mobil Cihazımız üzerinden bir mesaj geldiğinde çalıştırılacak olan kod blokları geliştirilmiştir.

İlk olarak dikkat edilecek olan satır gelen mesajın nasıl liste kutusu içerisine eklendiğidir.

Bir önceki metotta belirtildiği üzere gelen byte dizisi MessageBuffer isimli byte dizisi içerisinde tutulacaktır. Bu noktada System.Text.Encoding.GetEncoding(1254).Getstring metodu üzerinden faydalanarak gelen byte dizisini “türkçe karakter setine uygun olarak” metne dönüştürüp liste kutusu içerisine ekliyoruz.

Bu satırdan sonra yazdığımız satırda ise MessageBuffer dizisini “yeni gelecek olan” mesajlar için temizliyoruz ; ve uygulamamızı “mesajların gelebilmesi” adına tekrar “mesaj bekleme” moduna geçiriyoruz.

İşte en önemli kısımları halletmiş olduk. Sıra geldi uygulamamızı çalıştıracak olan Socket tanımlama ve mesaj gönderme işlemlerinin gerçekleştirildiği kod bloklarını geliştirmeye.

Amacımız sistemimiz üzerinde 15423 numaralı TCP portu üzerinden dinlemeye ve mesaj göndermeye yarayan bir socket tanımlamak olacaktır. Hiç vakit kaybetmeden şekilde kod bloklarını geliştiriyoruz.

Kod bloğunu ayrıntılı olarak incelediğimizde uygulamamız açıldığında sistem üzerinde TCP protokolü 15423 numaralı porttan dinleyecek ve Stream ; yani akış işlemlerinin gerçekleştirilebileceği bir Socket objesi tanımlanmaktadır. Bir sonraki satırda ise bu socket objesi sistemimiz üzerindeki fiziksel bir port ile ilişkilendirilmektetir. Ayrıca uygulama ekranı yüklendiğinde delegemizin objesi tanımlanmakta ; son olarak ise Asenkron işlemlerde daha önceki makalelerimizde bahsettiğimiz “bir objeye o’ nun oluşturulduğu thread dışında farklı bir thread üzerinden erişmeye çalıştığımızda yaşanan CrossThreadOperationException hatasına karşı” Control.CheckForIllegalCrossThreadCalls static değişkenine “sorun çıkarmaması adına” false değerini veriyoruz.

Button1 isimli Start Server button’ una bastığımızda ise tanımlanan socket objemizi Listen metodumuz üzerinden dinleme moduna geçiriyoruz. Ve BeginAccept metodu üzerinden asenkron mimariyi kullanarak uzaktan gelecek olan bağlantıları kabul edebilecek şekilde yapılandırıyoruz.

Son olarak btnSEND isimli button’ umuza tıkladığımızda ise yazılan metin System.Text.Encoding.GetEncoding(1254).GetBytes metodu üzerinden byte dizisine çevirmekte ve “eğer bağlı bir socket var ise” yani RemoteSocket referansı “null” değil ise karşı noktaya yani mobil cihazımıza göndermektedir.

İşte bu kadar !

Makalemizin ilk bölümünün sonuna geldik. Bir sonraki makalemizde bu makalede geliştirdiğimiz sunucu ile haberleşecek bir mobil cihaz uygulaması geliştireceğiz.

Dağıtık uygulama senaryolarına baktığımızda muhtemelen karşılaşabileceğimiz en büyük problem ortam içerisindeki cihazların birbirleriyle haberleşme esnasında kullanacakları platformdur. Kullanılacak olan altyapının maliyeti yükseltmesi ; ticari bir ortamda pekte hoş karşılanmayacaktır. Bu noktada esnek, geliştirilebilir, güvenli ve “maliyeti düşük” bir platforma ihtiyaç duyulmaktadır.

Olaya bu perspektif üzerinden baktığımızda XML Web Servislerinin bu ihtiyacı fazlasıyla karşıladığını ; dağıtık uygulama senaryolarında “lokasyon’ dan bağımsız” sistemleri birbirlerine maliyeti yükseltmeden bağlayabildiğini rahatlıkla söyleyebiliriz. Belirli güvenlik seçenekleri çerçevesinde XML Web Servisleri yeni jenerasyon uygulama geliştiricilerin dağıtık uygulama senaryolarında tercih olarak seçebilecekleri başarılı seçeneklerin başında gelmektedir.

Bu makalemizde ise dağıtık uygulama senaryolarında en sık karşılaşılabilecek bir senaryoyu ; Mobil Cihazlar üzerinde XML Web Servislerinin kullanımına değineceğiz.

Bu noktada konunun daha rahat anlaşılabilmesi açısından makalenin devamında örnek bir uygulama geliştirilecektir.

Hiç vakit kaybetmeden makalemizin ilk bölümünde Mobil Cihazlar üzerinden çağırılabilecek bir Xml Web Servisi geliştirelim. İkinci aşamada ise bu Web Servisi ile Mobil Cihaz uygulamamız arasındaki bağlantıları gerçekleştirip makalemizi bitireceğiz.

Web Servisimiz girişi yapılan ürün numarası üzerinden kullanıcının Mobil Cihaz üzerindeki uygulamasına gerekli ürün bilgilerini gönderecektir. Bu noktada uygulama güvenliği kullanıcıdan alınan Müşteri kodu olacaktır.

Uygulamamıza başlamadan önce örneğimizde kullanacak olduğumuz veritabanının Northwind veritabanı olduğunu bu noktada belirtmek doğru olacaktır.

Hiç vakit kaybetmeden XML Web Servisimizi geliştirmeye başlayalım. XML Web servisimiz içerisinde iki adet metot olacaktır. Metotlardan ilki kullanıcıdan Müşteri Kod bilgisini isteyecek ve eğer bu bilgiyi Customers tablosu üzerinden doğrulayabilirse uygulamanın ikinci ; Ana ekranını ekrana getirecektir. Bir diğer metot ise Kullanıcı bilgilerinin doğrulanmasından sonra Kullanıcıdan ürün numarasını isteyecek ; sorgulama sonucunda ise eğer bilgi doğrulanabilirse ilgili ürün bilgisini ekrana getirecektir.

İlk olarak Yeni bir Asp.NET Web Servis projesi oluşturarak işe başlayalım.

Proje başarıyla oluşturulduğunda ilk adımda Müşteri Kod bilgisini kontrol eden metodu yazarak örneğimize devam edelim.

Metodu ayrıntılı bir şekilde incelediğimizde yapının çokta karmaşık olmadığını rahatlıkla anlayabiliriz. Metot kullanıcıdan string tipinde Müşteri Kod bilgisini istemekte ve bu bilgiyi doğrulaması sonucunda kullanıcıya sonuç ile ilgili bool tipinde bir değer döndürmektedir. Metodumuzu Internet Tarayıcımız üzerinden denediğimizde ;

Müşteri adı olarak “ALFKI” değerini giriyoruz ve metodumuzu tarayıcımız üzerinden Invoke ediyoruz.

Ve sonuç ! Metodumuz başarılı bir şekilde müşteri kod bilgisini veritabanı üzerinden sorgulayabilmektedir. Sıra geldi ikinci metodumuza. Bu noktada kullanıcımız başarılı bir şekilde giriş yapabilmiş ise ürün numarasını ikinci metodumuza parametre değeri olarak gönderecek ; ürün numarası tablo içerisinde bulunabilmiş ise ilgili ürünün bilgileri kullanıcıya ArrayList içerisinde döndürülecektir.

Metodu ayrıntılı bir şekilde incelediğimizde DataReader üzerinden dönen tek bir satır olduğunu ; bu satırı satırın içerisindeki kolon sayısı kadar dönen bir döngü içerisinde okuduğumuzu rahatlıkla anlayabiliriz. Satır içerisindeki her bir kolon “Kolon Adı : Kolon Değeri” şeklinde ArrayList içerisine eleman olarak eklenmektedir.

Uygulamanın ikinci metodunu tarayıcımız üzerinde test ettiğimizde :

Metodu çalıştırmak istediğimizde :

1 değerini metin kutusu içerisine giriyoruz ve Invoke button’ una tıklıyoruz.

Ve sonuc ! Mükemmel ! Sıra geldi mobil uygulamamıza. Mobil uygulamamız içerisinde iki adet form bulunacaktır. Formlardan ilki kullanıcıyı karşılayacak ; Müşteri kod bilgisini kullanıcıdan isteyecektir. Kullanıcının bu bilgisi Web Servisi üzerinden doğrulandığında uygulamamızın ikinci formu ekrana gelecek ve gerekli bilgiler kullanıcıdan istecenecektir. Bu noktada Mobil Cihaz uygulamamızı geliştirmeye geçmeden önce Web Servisimizi Lokal Web sunuzumuz üzerinden Publish etmemiz gerekmektedir. Bu şekilde Web Servisimiz Lokal Makinemiz üzerinden dış dünyaya sunulmuş olacaktır.Projemizin üzerine sağ tıklıyoruz ve Publish Web Site seçeneğini seçiyoruz.

Gerekli değerleri belirleyip OK’ e tıklıyoruz.

Tek yapmamız gereken uygulamamızın bulunduğu klasörü Internet Information Services üzerinde bir Application Folder (Uygulama Klasörü) olarak tanımlamış olmak.

Seçeğe tıkladığımızda ise :

OK’ e tıklayarak uygulamamızı IIS üzerinde tanımlamış oluyoruz.

Artık web servisimize http://MakinemizinAdi/UygulamaAdi/Service.asmx adresi üzerinden erişilebilmektedir.

Vakit kaybetmeden makalemizin ikinci bölümüne devam edelim. İlk olarak işe yeni bir C# - Smart Device – Device Application uygulaması açarak başlıyoruz.

Bir sonraki adımda ise proje içerisinde standart olarak gelen Windows Form’una ek olarak yeni bir Windows Form ekliyoruz. Form’ un isim değerine frmMAIN değerini atıyoruz.

Ve uygulamamızı geliştirmeye başlıyoruz. İlk form yani frmLOGIN içerisinde şekildeki tasarımı gerçekleştiriyoruz.

Web Servisi entegrasyonu kısmına geçmeden önce ikinci yani Ana Formumuzu’ da geliştirelim.

Ve sonuç ! Form üzerine bir metin kutusu, bir button ve bir Liste kutusu ekledikten sonra sıra geldi Web Servis entegrasyonuna. Bu noktada olayın ne kadar kolay olduğunu ifade edebilmek amacıyla sadece şunu söylemek yeterli olacaktır ; .NET Framework üzerinde bu iş nasıl gerçekleştiriliyorsa .NET Compact Framework üzerinde de o şekilde ! Projenin References sekmesi üzerine sağ tıklanıp Add Web Reference seçeneği üzerinden uygulama geliştiriciler Mobil Cihaz projeleri üzerinde Web Servislerini kullanabilirler.

Add Web Reference seçeneği üzerinden Web Servisimizi Mobil Cihaz uygulamamız ile ilişkilendiriyoruz.

Ve Web Servisimizin lokasyonumuzu yazıyoruz. Bu noktada dikkat etmemiz gereken yapı Web Servisimizin Lokaldeki makinamız üzerinde bulunmasından ötürü adresi “localhost” şeklinde belirtmiş olabiliriz. Bu adres modeli Mobil Cihaz üzerinde bulunamayacak ; haliyle Web Servisimiz ile Mobil Cihazımız haberleşemeyecektir. Doğru adres değeri ise Web Servisinin bulunduğu makinenin ismini ; yani makinemizin ismini yada IP adresimizi değer olarak belirleyerek soruna çözüm bulmuş olabiliriz.

Ne kadar basit değilmi ? Standart .NET Framework masaüstü uygulamalarında olduğu gibi tek yapmamız gereken Web Servisimize erişebilecek “Proxy” sınıfının otomatik olarak oluşturulabilmesi için “Add Reference” button’ una tıklamak olacaktır.

Web Reference Name değerine NorthwindWS değerini belirleyip “Add Reference” seçeneğine tıklıyoruz.

Ve sonuç ! Sıra geldi uygulamamızın giriş ekranı üzerindeki kod bloğunu hazırlamaya. Tek yapmamız gereken uygulama açıldığında Servis Proxy sınıfımızın bir kopyasını almak ve Kullanıcı bilgilerini kontrol eden metodu bu kopya üzerinden çalıştırmak olacaktır.

Kodları şekildeki gibi belirledikten sonra uygulamamızı Fiziksel Cihaz / Emülatör üzerinde çalıştırıyoruz.

Değer olarak ilk adımda yanlış bir Müşteri Kod bilgisi giriyoruz. İkinci adımda ise doğru bir değer girdikten sonra ana ekran görünümünün ekrana geldiğini görmemiz gerekmektedir.

Doğru bir Müşteri Kod bilgisi girdiğimizde ise :

Uygulamanın ana ekranı ekrana gelmektedir. Tek yapmamız gereken ana ekran üzerinde çalışacak olan kodları yazmaktır. Gerçekleştirilecek tek eylem girilen ürün numarası bilgisini Web Servisimiz üzerindeki ilgili metoda göndermek ve gelen object[] içerisindeki metinleri liste kutusu içerisine eklemektir.

Uygulamayı Fiziksel Cihaz / Emülatör üzerinde çalıştırdığımız ve Müşteri Kod bilgisi ekranını başarılı bir şekilde geçtikten sonra :

Ve sonuç !

Ürün numarası Web Servisi üzerinden veritabanımızda sorgulanıp gerekli ürün bilgisi ekrana getirilmiştir !

Bu makalemizde örnek bir Web Servisi uygulamasının Mobil Cihazlar üzerinde kullanımına değindik, başka bir makalede daha görüşmek üzere.

Masaüstü ya da Mobil Cihaz Form uygulamalarında yaşanan en büyük problemlerden birisi döngülerin çalıştırıldığı süreç esnasında uygulama ekranı üzerinde yaşanan kilitlenmelerdir. Bu konuyla ilgili daha önce http://www.yazgelistir.com/Makaleler/1000001208.ygpx adresinde Asenkron Mimarinin uygulanması ; başka bir deyişle işlemlerin farklı bir thread içerisinden yürütülerek halledilebileceğinden bahsetmiştik. Bu makalemizde ise işlemlerin çalıştırılma süreci içerisinde yaşanan bu beklemelerin temel sebebinden bahsedip ; buna farklı bir perspektiften ; Application.DoEvents() metodu üzerinden çözüm arayacağız.

Asıl konumuza geçmeden önce işletim sistemimiz üzerinde bir uygulama başladığı andan itibaren yaşanan süreçten bahsedelim. Bilindiği üzere Windows CE ya da herhangi bir Windows tabanlı işletim sistemi üzerinde herhangi bir kaynak üzerinde gerçekleşen bir olay ile ilgili işletim sisteminin gösterdiği tepkilere bildiğimiz “Olay (Event)” ismi yerine “Mesaj (Message)” ismi verilmektedir. Bu noktada işletim sistemi üzerinde gerçekleştirilen herhangi bir eylem uygulama geliştiriciye Mesaj olarak gönderilmektedir. Zaten Buton üzerinde tıkladığımızda ilgili buton’ un tıklatıldığını işletim sistemimiz donanımsal seviyeden yakalayıp .Net Framework’ e iletmekte ; Olay (Event) olarak tanımladığımız tetikleyiciler uygulamalarımızda fırlatılmaktadır.

Üzerinde konuştuğumuz bu süreç ana uygulama herhangi bir sebepten kapatılmadığı ya da sonlandırılmadığı süre boyunca istisnasız devam etmekte ; gerçekleştirdiğimiz her eylemin karşılığında işletim sistemimiz üzerinden mesajlar fırlatılmakta ve bu mesajlar .Net Framework tarafından yakalanıp işletilmektedir.

Konuyu biraz daha ayrıntılı incelediğimizde istisnasız devam eden bu süreç içerisinde incelenmesi gereken –ki sorunun temel kaynağı olarak ifade edilebilecek- önemli bir başlık daha bulunmaktadır.

Bir önceki örneğimizde uygulama ekranımız üzerine yerleştirilen standart bir button’ un üzerinde gerçekleştirilebilecek en standart eylemden ; üzerine tıklamaktan bahsettik. Bu noktada mantık çerçevesinde düşünüldüğünde ekran üzerinde aynı anda iki butona tıklayamayacığımız açık ve net bir sonuçtur.

Olaya bu açıdan baktığımızda standart yaklaşımla gerçekleştirdiğimiz eylemlere karşılık olarak gönderilen mesajlar işletim sistemimiz üzerinde belirli bir sırayla gönderilip işletilmektedir. Özel, spesifik bir durum dışında bir eylem sonucunda belirli bir iş gerçekleştirildiğinde işletim sistemi üzerinden gönderilen diğer mesajlar uygulama tarafında bekletilmekte ; bir önceki mesajın sonucu başlatılan iş tamamlanana kadar işletilmemektedirler. Peki bu noktada yaşanan nasıl bir problem olabilir ; biraz bu konuya değinelim.

Örnek bir senaryo olarak makalemizin başında adresi verilen Asenkron Mimari ile ilgili makalemizde gerçekleştirilen bir senaryoyu ele alalım. Uygulama içerisinde belirli iki sayı arasında ; ya da belirli bir koşul gerçeklendiği zaman sürecinde onlarca belki yüzlerce kez çalışması gereken bir döngünün olduğunu düşünelim. Bu döngünün döndürüldüğü ; başka bir deyişle çalıştırıldığı süreç içerisinde ise görsel anlamda bazı görevleri yerine getirelim-ki örnek vermek gerekirse gelen her sayıyı bir liste kutusu içerisine eklemek olabilir.

Bir önceki paragrafta anlatıldığı üzere bu “iş” gerçeklenirken işletim sistemi üzerinden onlarca ; belki yüzlerce mesaj fırlatılmakta, fakat o süreç boyunca sistem “döngü” ‘ ye odaklandığı ve onunla ilgili mesajları işlediği için diğer mesajları kuyrukta bekletmektedirler.

Peki az önce üzerinde konuştuğumuz üzere ; özel & spesifik bir durumdan bahsediyorsak ; yani döngü dönerken liste kutusu içerisine eklenen rakamları canlı olarak görmek istiyorsak ; daha açık anlatmak gerekirse gelen rakamların liste kutusuna eklenmesi ile ilgili işletim sistemi üzerinden gelen mesajların döngü çalışırken işletilmesi için nasıl bir yapıyı uygulamamız gerekmektedir ?

İşte bu noktada makalemizin başlığını oluşturan bir metot ; Application sınıfı içerisinde bulunan DoEvents() metodu karşımıza çıkmaktadır.

Application.Run() metodu ile yaşam sürecine başlayan Windows Form uygulamamız içerisinde kuyrukta bekletilen mesajların işlenmesi ile ilgili bir metot olan DoEvents() metodu makalemizinde konusunda ifade edildiği üzere bu tip bekletme durumlarında hayat kurtarmaktadır. Özellikle döngü, koşul bazlı süreçler ele alındığında kullanıcılar kuyrukta bekletilen mesajları işleterek sistemin “olması gerektiği gibi” çalışmasını sağlayabilmektedirler.

Bu noktada konunun daha rahat anlaşılabilmesi açısından örnek bir uygulama geliştirmek çok doğru olacaktır. Senaryomuza göre bir while döngüsü içerisinde koşul sağlandığı sürece o an aktif sayaç değeri liste kutusuna eklenecek ; bu ekleme işinin görsel sonucu canlı olarak ekranda gösterilecektir.

Bunun için ilk olarak bir Smart Device C# uygulaması açıyoruz.

Bir sonraki adımda form üzerine bir buton ve bir liste kutusu kontrolü yerleştiriyoruz.

Ve şekildeki kodları yazarak uygulamamıza devam ediyoruz :

Kodu incelediğimizde basit bir while döngüsünün hazırlandığını rahatlıkla farkedebiliriz. Gerçekleştirdiğimiz tek eylem ise Button’ a tıkladığımızda koşulun sağlanıp sağlanmadığını kontrol etmek ; koşul sağlandığı süre içerisinde de Sayac değerini liste kutusu içerisine eklemek olacaktır. Bu şekilde uygulamamızı çalıştırdığımızda ise :

Scrollbar’ ın küçüldüğünü ; yani sayıların eklenmesi ile ilgili mesajların geldiğini fakat bunların görsel anlamda işletilemediğini rahatlıkla görebiliriz. Bu noktada yaşanan problem ile ilgili yazının başında ayrıntılı bir açıklamada bulunmuştuk. Yapmamız gereken tek şey bekletilen mesajların kuyruktan çekilmesi ve işletilmesi olacaktır ; ki bu noktada Application.DoEvents() metodu karşımıza çıkmaktadır.

Application.DoEvents() metodu her çağırıldığında kuyrukta bekletilen mesajlar otomatik olarak işlem görmektedir. Bu noktada döngü her döndüğünde bu mesaj sayısı yükselmekte ; haliyle kimi zaman tıkanmalara sebep olabilmektedir. Bizim bu noktada yapabileceğimiz tek şey döngü her döndüğünde Application.DoEvents() metodunu çağırmak ve anlık olarak sırada bekletilen mesajı ; yani sayının liste kutusuna eklenmesi ile ilgili işlemi gerçekleştirmemiz olacaktır. Kodu şekildeki gibi tekrar düzenleyip çalıştırıyoruz :

Uygulamayı çalıştırdığımızda ise :

Ve sonuç mükemmel ! İşlem devam ediyor olmasına karşın sayılar ekran üzerinde başarıyla görüntülenmektedir.

Bu makalemizde Application.DoEvents() metodu ile kuyrukta bekletilen işletim sistemi mesajlarını kuyruktan çekmeyi mercek altına aldık. Başka bir makalede daha görüşmek üzere.

Sql Server 2005 Compact Edition uygulama geliştiricilerin beğenisine sunulduğunda birçok yenilikle sahneye çıkmıştı. Bunlardan en önemlisi Sql Server 2005 Compact Edition artık Mobil Cihaz’ lardan sonra Masaüstü uygulamalarında da kullanılabilecekti.

Performans, optimizasyon, birlikte çalışılabilirlik gibi özelliklerini incelediğimizde Basit ve Lokal Veri Depolama senaryolarında Sql Server 2005 Compact Edition çok doğru bir seçenek olacaktır. Bu noktada geliştirilen uygulamaların Sql Server 2005 Compact Edition (bu noktadan sonra Sql CE olarak anılacaktır)veri depolama altyapısı üzerinden programlanabilmesi için managed kod uygulama geliştiriciler sistemlerine Sql CE yükleme paketini kurmaları gerekmektedir. Bu kurulum ile birlikte sistemimize managed Windows Masaüstü ve Mobil Cihaz uygulamalarında kullanabileceğimiz System.Data.SqlServerCe ismi ile kullanabileceğimiz bir referans yüklenmektedir.

Bu referans üzerinden uygulama geliştiriciler tam Sql Server 2005 Compact Edition entegre çalışan uygulama geliştirebilir ; üzerinde aktif olarak çalışıyor oldukları veritabanı üzerinde veri bazlı ve yönetimsel seviyede işlemler gerçekleştirilebilirler. Bu makalemizde bu referans üzerinden uygulama geliştiricilerin kullanımına sunulan ; Sql Server 2005 Compact Edition uygulama geliştirme senaryolarında en temel sınıf olarak kabul edilen bir sınıfı ; SqlCeEngine sınıfını mercek altına alacağız.

SqlCeEngine sınıfı temel anlamda adından da anlaşılabileceği üzere bir Sql Server 2005 Compact Edition motorunu ifade etmektedir. Buradaki motor kelimesinden çıkarmamız gereken anlam temel yönetimsel işlemler gerçekleştirebilecek bir sınıf olarak ifade edilebilir. Genel hatlarıyla sınıfın elemanlarına bakacak olursak ;

listenin çokta karmaşık olmadığını rahatlıkla farkedebiliriz. Metotların ne işe yaradığını teorik olarak anlatmaktansa mobil bir cihaz üzerinde geliştireceğimiz küçük bir örnek bu noktada daha yararlı olacaktır. Örnek .NET Compact Framework 2.0 yüklü Windows Mobile 5.0 işletim sistemine sahip bir Pocket PC cihazı hedef alınarak geliştirilecektir. Bunun için sisteminizde Windows Mobile 5.0 SDK’ nın kurulu olması gerekmektedir.

İlk olarak işe yeni bir Mobil Windows Projesi açarak başlıyoruz.

Bir sonraki adımda makalemizin temel konusu olan sınıfımızın bulunduğu referansı ; System.Data.SqlServerCe referansınızı projemize referans olarak ekliyoruz.

Referansı projemize ekledikten bir sonraki adımda uygulamamızı geliştirmeye hızlı bir şekilde devam edelim. Bu noktadaki amacımız yukarıda ifade ettiğimiz üzere bu referans içerisinde bulunan SqlCeEngine sınıfının metotlarını ve temel amacını mercek altına almak olacaktır.

Hızlı bir şekilde örneğimize devam edelim. Genel hatlarıyla sınıfımızı incelediğimizde yapının nasıl çalıştığını Constructer’ ı üzerinden rahatlıkla anlayabiliriz. Sınıfın Instance’ ını almak istediğimiz zaman karşımıza 2 farklı overloaded constructer çıkmaktadır.

Bunlardan ilki kullanıcıdan herhangi bir parametre istemez iken ikincisi kullanıcıdan mobil cihazınız üzerinde fiziksel olarak bulunan ya da bulunacak olan veritabanına bağlantı kurulacağı noktada kullanılacak olan bir bağlantı cümleciği istemektedir. Bağlantı cümleciği içerisinde kullanabileceğimiz tüm parametrelerin listesini http://msdn2.microsoft.com/en-us/library/system.data.sqlserverce.sqlceconnection.connectionstring.aspx adresinden ayrıntılı bir şekilde inceleyebilirsiniz. Örneğimiz üzerinde Mobil Cihazımızın kök klasörü içerisinde bulunan Yazilim.sdf isimli veritabanına bağlantı kuracağız. Bu noktada bu veritabanının fiziksel olarak olmadığını ; sınıfımız içerisinde belirttiğimiz bağlantı cümleciği yardımı ile oluşturulacağını birlikte uygulayacağız. Yapıcı metot içerisine Bağlantı Cümlesi parametresini şekildeki gibi göndererek bir SqlCeEngine objesi oluşturuyoruz.

Şekilde görüldüğü üzere herhangi bir Kullanıcı Adı / Şifre kombinasyonu belirtilmemiştir ki bu noktada veritabanımızın güvenliği çokta yüksek değildir.

Mantık çerçevesinde baktığımızda bu sınıfı kullanarak gerçekleştireceğimiz yönetimsel işlemleri gerçekleştirebilmemiz için ilk aşamada veritabanımızın fiziksel olarak oluşturulmuş olması gerekmektedir. Bu noktada ilk olarak SqlCeEngine sınıfı içerisinde karşımıza çıkan CreateDatabase() metodu üzerinde örneğimizi uygulamaya devam edelim.

Metot adından da anlaşılabileceği üzere SqlCeEngine objesi içerisinde belirtilmiş olan bağlantı cümleciği içerisindeki patikadaki veritabanını fiziksel olarak oluşturmaya yaramaktadır. Uygulamamızı hiç vakit kaybetmeden çalıştırıyoruz :

Uygulama ekranı açıldığında boş bir form görüyor olmamız gerekmektedir. Fakat uygulamamızı kapatıp mobil cihaz üzerinde belirtilen patika içerisine baktığımızda :

veritabanı dosyamızın başarılı bir şekilde oluşturulduğunu rahatlıkla görebiliriz. Veritabanımıza mobil cihazımız üzerine yüklenen Query Analyzer uygulaması üzerinden bağlantı kurup basit bir tablo ve birkaç satır bilgi ekliyoruz.

Yeni bir tablo ve birkaç satır bilgi ekliyoruz.

Ve bilgiler ;

Run butonuna tıkladığımıza ekran 1 satırın eklendiğine dair mesaj görüntülenecektir. Bu noktadaki amacımız minimal düzeyde bile olsa veritabanımızın içerisinde bilgilerin bulunuyor olmasıdır.

Hızlı bir şekilde sınıfımızın içerisinde bulunan metotları incelemeye devam edelim. SqlCeEngine sınıfı içerisinde herhangi bir t zamanında veritabanının fiziksel dosyasının tutarlılığını inceleyebilmek amacı üzerine kullanabileceğimiz faydalı bir metot bulunmaktadır. Bu metot üzerinden veritabanı içerisindeki “sayfa” ların tutarlılığını belirleyebilir, bir sonraki başlık içerisinde inceleyeceğimiz Repair metodunun gereksinimini belirleyebilirsiniz. Şekildeki kod bloğu üzerinden makalemize devam ediyoruz.

Verify metodunu çalıştırarak fiziksel veritabanı dosyası içerisindeki tutarlığı denetliyoruz. Tutarsız bir durum ile karşı karşıya kalındığında ise Verify metodu uygulama geliştiriciye false değerini döndürmekte ve Repair metodunu kullanmasını gerektiğini söylemektedir. Uygulamayı çalıştırıyoruz :

Veritabanımızın fiziksel anlamda herhangi bir tutarsızlık sorununun olmadığını rahatlıkla anlayabiliriz. Peki ya bu metot sonucunda false boolean değerini elde etmiş olsaydık problemin önüne nasıl geçebilecektik ? Problemin çözümüne geçmeden önce değerin false gelmesinin sebepleri üzerinde kısaca değinmek daha faydalı olacaktır.

Konuyu kısaca ifade etmek gerekirse Verify metodunun false değerini kullanıcıya döndürmesi veritabanının fiziksel dosyası içerisinde hesaplanan Checksum değerlerinin tutarsız olduğunu ; haliyle veritabanı içerisindeki Datapage’ lerin herhangi bir tanesinde bir problem olabileceği anlamına gelmektedir. Sistemin bu şekilde çalışması riskini göze almayacak isek çözüme ulaşmamız için tek bir yöntem bulunmaktadır ; Repair() .

Repair metodu SqlCeEngine sınıfı içerisinde uygulama geliştiricilerin kullanımına gelen ; bu tip tutarsızlık senaryolarında fiziksel veritabanı dosyasını eski haline dönüştürmeye yarayan hayat kurtarıcı bir metot olarak kullanılmaktadır. Senaryomuzda hata olmamasına rağmen Repair metodunun kullanımını kısa bir örnekle açıklamak bu noktada daha doğru olacaktır.

Şekilden anlaşılacağı üzere Repair metodu kullanıcıdan iki adet parametre istemektedir. Bunlardan ilki ConnectionString. ConnectionString parametresinin istenmesinin sebebi “tamir edilmiş” veritabanının bozuk veritabanı dosyasından farklı bir lokasyonda olmasını isteyen uygulama geliştiriciler için metoda parametre olarak eklenmiştir. Eğer “tamir edilmiş” veritabanının aynı lokasyonda ; yani varolan veritabanının üzerine yazılmasını istiyorsak bu parametreye null değer vermek yeterli olacaktır. Bu noktada bir sonraki parametre değerine bakacak olursak RepairOption adını verdiğimiz bir enum değeri kullanıcıdan istenmektedir. Bu enum değerinin istenmesinin amacı ise “tamir edilme” işlemi esnasında bulunan bozuk bölgelere nasıl bir işlem gerçekleştirileceğidir.

Bu enum listesindeki değerler şekildeki gibi oluşturulmuştur ;

Enum listesi içerisinde bulunan değerleri bu noktada kısaca açıklamak faydalı olacaktır.

DeleteCorruptedRows enum değerini belirleyerek Repair() metodu çalıştırıldığında SqlCeEngine objesi “bozuk” veritabanı dosyası içerisinde bulduğu “sorunlu” DataPage’ leri düzeltmeye çalışmadan silecektir. Bir diğer seçenek olan RecoverCorruptedRows seçeneği ise ilk seçeneğin aksine bozuk bulduğu DataPage’ leri düzeltmeye çalışarak eski haline getirecektir. Biz ikinci seçeği seçecek şekilde metodumuzu çalıştırıyoruz.

Bu metot çalıştırıldığında dosyanın fiziksel olarak bulunduğu noktada aynı isimle “tamir edilmiş” versiyonu otomatik olarak oluşturulacaktır.

Makalemize ; SqlCeEngine sınıfının diğer metotlarını inceleyerek devam edelim. Şu ana kadar üzerinde çalıştığımız metotların neredeyse hepsi standart olarak “olmazsa olmaz” metotlar olarak ifade edilebilir. Sırada yine olmazsa olmaz olarak ifade edebileceğimiz ; masaüstü uygulamalarında Sql Server’ ın normal sürümlerini kullanan uygulama geliştiricilerin yakından tanıdığı bir kavramı yerine getiren bir metot ile devam edelim ; Shrink(). Shrink kavramı standart Sql Server sürümleri üzerinde “veritabanının kullanılmayan alanlarını makaslayarak yerden tasarruf” olarak ifade edilebilecek sık gerçekleştirilen bir eylemdir. Bellek miktarı açısından yetersiz olan Mobil Cihazlar üzerinde kullanılmasının ise bu noktada çok doğru olduğu açıktır. SqlCeEngine sınıfı içerisinde bulunan Shrink metodu üzerinden uygulama geliştiriciler veritabanının kullanılmayan alanlarını makaslatarak yerden tasarruf sağlayabilirler. Şekildeki kod satırını ekleyerek uygulamamıza devam ediyoruz :

Sırada SqlCeEngine sınıfı içerisinde “önemli” olarak incelenebilecek son bir metot daha var ; Compact(). Compact metodu yapısı gereği fiziksel veritabanı dosyamızın “adresi “ verilen noktada verilen “yeni” özellikleriyle “gereksiz boşlukları temizledikten sonra” tekrar oluşturulmasını sağlamaktadır. Bu noktada cümle içerisinde geçen “yeni özellikler” kavramını biraz açmak daha doğru olacaktır.

Birçok zaman fiziksel veritabanı dosyamızı (*.sdf) Şifre gibi bazı özellikleri belirlemeyerek oluşturmuş olabiliriz. Bu durum, bundan sonraki kullanımlarımızda veritabanımızın bu şekilde kullanılacağı anlamına gelmemektedir.

Konu ile nasıl bir ilişki var diye araştırdığımızda Compact metodu içerisine aldığı ConnectionString parametresi ile aslında bir nevi “veritabanımızın tüm özellikleriyle” yeni halini oluşturmaktadır. Daha ayrıntılı açıklamak gerekirse Compact metodunun ilk parametresinde verdiğimiz ConnectionString değeri içerisinde Şifre bilgisi bulunıyor ise, veritabanımızın yeni hali bu özelliğe sahip bir şekilde oluşturulacaktır.

Kodu şekildeki gibi çalıştırdığımızda Kök Klasör içerisinde YazilimYeni.sdf ismiyle, sadece“eknozcckcLr” şifresi kullanılarak bağlantı kurulabilecek bir veritabanı oluşturulmuş olacaktır.

Şifre bilgisini belirtmeden bu veritabanına bağlantı kurmaya çalıştığımızda ise :

Çağırılan ilk metot üzerinden şekildeki hatayı alacağız.

Bu makalemizde SqlCeEngine sınıfına ayrıntılı bir şekilde değindik. Bir sonraki makalede görüşmek üzere.

Serialization kavramı bilindiği üzere nesnenin herhangi bir t zamanında belirtilen “formatter” kullanılarak bellek üzerinde depolanması ve yine herhangi bir t zamanında bellek üzerinde depolandığı yerden “serialize” edildiği zaman sürecindeki değerleriyle tekrardan oluşturulma işlemidir.

Olaya bu açıdan bakıldığında serialization işleminin .Net Framework üzerinde yüzlerce parametresi bulunmaktadır. XML, SOAP ve Binary Serialization olarak 3 farklı format üzerinde incelenebilecek olan bu kavram her birinde farklı avantajlar & dezavantajlar getirmektedir.

Temel hatlarıyla avantajları ve dezavantajlarına baktığımıza göze çarpan en büyük fark XML Serialization’ ın Shallow (Sığ) Serialization, SOAP ve Binary Serialization’ ın ise Deep (Derin) Serialization yapabiliyor olmasıdır. Shallow Serialization’ da Public Member’ lar serialize edilirken , Private Member’ lar serialize edilmemektedir. Deep Serialization’ da ise tüm Member’ lar serialize edilebilmektedir.

Bütün bunların yanında .Net Compact Framework’ e baktığımızda .Net Framework ile kıyaslandığında sadece XML Serialization’ ın gerçekleştirilebildiğini görmekteyiz. Bu makalemizde .Net Compact Framework 2.0 platformu üzerinde Mobil Cihazlarda XML Serialization kavramı üzerine basit bir örnek geliştireceğiz.

Konun daha rahat anlaşılabilmesi açısından bu noktada örnek üzerinden gitmek daha faydalı olacaktır.

Standart bir C# Mobile 5.0 Smart Device Application projesi açarak işe başlıyoruz.

Amacımız XmlSerialization kullanarak datalarını mobil cihaz belleği üzerinde depolayan bir telefon defteri geliştirmek olacaktır.

Şekildeki formu tasarlayarak uygulamamıza devam ediyoruz :

Form üzerine yeni telefon bilgisi ekleneceği noktada kullanılacak olan iki adet metin kutusu, 3 adet buton ve iki adet kolon barındıran bir ListView kontrolü ekliyoruz.

Senaryoya göre kullanıcı uygulamayı çalıştırdığında Yükle button’ una basacak ; “eğer var ise” XML Dökümanı üzerinden ArrayList Deserialize edilecek ve içerisindeki tüm TelefonBilgisi objeleri ListView kontrolü içerisine eklenecektir.

İlk olarak kod tarafında şekildeki sınıfı oluşturuyoruz.

Şekilde bakıldığı zaman ilginç gelebilme ihtimali olabilecek tek metot BilgilerimdenListeElemaniGetir metodu olabilir. Metodun amacı Telefon bilgilerini içerisinde barındıran ve iki SubListViewItem içeren bir ListViewItem döndürmek olacaktır. Dönen objeyi ListView.Items.Add metoduna direk gönderdiğimiz noktada işimiz bitmektedir.

Şekildeki kod bloğu üzerinden devam ediyoruz :

Şekilde görülebileceği üzere Form’ umuz yüklendiği noktada global’ de tanımlanan xSER isimli XmlSerializer referansını yeni bir instance’ a eşitliyoruz.

Bu noktada dikkat edilmesi gereken nokta XmlSerializer nesnesinin constructer’ ında nesnenin serialize edebileceği tipleri belirlememiz gerekmektedir. Dikkat edilecek olursa ilk parametrede ArrayList tipi gonderilir iken ikinci parametrede TelefonBilgi isimli tip gönderilmiştir. Tipler doğru gönderilmediği taktirde nesnemiz ne serialize ne de deserialize işlemi gerçekleştirebilecektir.

Yükle button’ una basıldığında ise Mobil Cihazımızın kök klasörü içerisindeki TelefonData.xml isimli döküman aranamakta ; var ise açılmakta yok ise oluşturulmaktadır. Bir sonraki adımda açılan xml dökümanının boyutu incelenmekte ; 0 byte’ tan büyük ise XmlSerializer nesnemiz kullanılarak ArrayList deserialize edilmekte ; değil ise içi boş bir ArrayList objesi oluşturulmaktadır.

Son olarak Kaydetme ve Ekleme işlemlerini gerçekleştiren kod satırlarını belirliyoruz :

Yeni bir telefon eklendiğinde TelefonBilgi sınıfının yeni bir kopyası oluşturulmakta ve gerekli değerler gönderilmektedir. Bir sonraki adımda bu obje ArrayList içerisine eklenmekte ve eş zamanlı olarak ListView içerisine eklenmektedir.

Kaydet button’ una tıklandığında ise çalışan tek satır global’ de tanımlanmış olan XmlSerializer nesnesinin Serialize metodudur.

Hiç vakit kaybetmeden uygulamayı çalıştırıyoruz.

Uygulama ana ekran’ ı üzerinde ilk olarak Yükle button’ una basarak ArrayList’ in oluşmasını sağlıyoruz. İlk noktada TelefonData.xml dökümanı olmadığı için herhangi bir telefon datası gelmemektedir.

Bir sonraki adımda birkaç telefon datası ekliyoruz :

Dataları ekledikten sonra Kaydet Button’ una tıklıyoruz :

Ve hemen gidip mobil cihazımızın kök klasöründeki TelefonData isimli XML Dökümanımıza bakıyoruz :

Dosya başarıyla oluşturulmuş ve 510Byte’ lık bir boyuta sahip. Dosyayı hemen mobil cihaz emülatörümüz üzerinde açıyoruz :

Ve sonuç ! XmlSerializer kullanılarak ArrayList içerisindeki tüm objelerimiz ArrayList halinde xml dökümanına serialize edilmiş durumdadır. Hepsi bu kadar.

Bu makalemizinde sonuna geldik. Başka bir makalede daha görüşmek üzere.