Category Archives: Microsoft Azure

Güncel Televizyon Artık Open Source !

Geçen sene ilk versionunu kodlamaya başladığım , Windows Store’da 3 binden fazla değerlendirmesi olan , 50 binden fazla indirilen ve 4.5 yıldız ortalamaya sahip olan televizyon izleme uygulamam Güncel Televizyonu Github üzerinden açık kaynak hale getirdim.Bu uygulamanın bende yeri aslında oldukça büyük.Küçük projelerin yanında bu tarz büyük bir projeye başlamamlaberaber Windows Phone ve Windows 8 üzerindeki tecrübelerimi fazlasıyla geliştirme fırsatı buldum.Şu an bu teknolojiler üzerinde bildiğim neredeyse herşeyi bu projede bulabilirsiniz.Aşağıda özene bezene yazdığım bir hikaye mevcut.Projenin her bir aşamasını , neyi nerde neye dayanarak nasıl yazdım vs. hepsini öğrenebilirsiniz 🙂

Projeye buraya tıklayarak GitHub üzerinden ulaşabilirsiniz !

Hikaye

Fikir tamamen ‘Acaba yapabilir miyim ?’ düşüncesiyle ortaya çıktı.Uzun bir yolculuk olacağını biliyordum , fakat herzamanki gibi bu korku da beni yıldırmadı 🙂 Küçük bir araştırma yaparak HLS (m3u8) , RTMP ve MMS protokolleri üzerinden streaming yapmayla ilgili bilgiler edindim.Daha sonra bu protokollerin Windows Development konusunda yapılan örneklerini araştırdım.Çoğu kanallar HLS yayını yapıyordu ve Windows’taki MediaElement kontrolü by default olarak bu desteği vermiyordu.Araştırmalarıma devam ederek Windows Phone Media Streaming Library (PhoneSM) adlı open-source kütüphaneyi buldum.Bu kütüphane sayesinde MediaElement’e HLS oynatma desteğini entegre edebiliyordum.

Web API

Yayın adresleri sürekli değişiyordu.Bir gün çalışan bir HLS yayını bir sonraki gün çalışmayabiliyordu.Bunu farkettikten sonra uygulamanın içerisinde yayın linklerini sabit olarak gömemeyeceğimi anladım.Bu sorunu çözmek için de çalışan canlı yayın linklerini uygulamaya iletebilecek bir Web API hazırladım.API, izlenilmek istenen kanalın yayın linkini kendi hafızasından uygulamaya iletiyordu ve bu linkleri değiştirmek için tek yapmam gereken sadece API projesini güncelleyip publish etmekti.Böylece her yayın linki değiştiğinde uygulamayı güncelleyip Windows Store’a update göndermek zorunda kalmayacaktım.

Basit bir web api projesi üzerinden çoktan uygulamaya bir farklılık yaratmıştım.Arkasında bir web servis çalışan tek televizyon izleme uygulaması Güncel Televizyondu.Fakat bu da yeterli değildi.Her gün bütün linkler çalışıyor mu acaba diye kontrol edemezdim.Bu soruna da bir çözüm bulmam gerekiyordu , buldum da 🙂 Çok izlenen ve resmi sitelerinde ‘Canlı İzle’ özelliği olan kanallar için Web API projesini güncelledim.API’a bu kanallardan izleme linki isteği geldiğinde API kanalın web sitesindeki ‘Canlı Izle’ sayfasına gidecek , siteyi okuyup içerisinden uygulamaya gönderilecek izleme linkini hazırlayacak ve göndericekti.Böylece az bir eforla çoğu kullanıcının izlediği popüler kanalların kontrolünü yaparak vakit kaybetmeyecektim ve uygulamadaki linkler daha uzun ömürlü ; hatta ömürsüz olacaktı 🙂

Sırf yukarıdaki özelliği API’a entegre etmem bile işimi oldukça kolaylaştırmıştı.Fakat bu da benim için yeterli değildi.Uygulamanın daha ön plana çıkabilmesi için değişik özellikler düşünmem gerekiyordu.Ben de yine hiçbir televizyon izleme uygulamasında olmayan Yayın Akışı desteğini getirdim.API , istenilen kanalın o günkü yayın akışını belli başlı web sitelerine bağlanıp hazırlayarak uygulamaya geri döndürüyordu.Ilk yazdığımda her istekte site tekrar analiz edilip öyle gönderiliyordu ve bu da ciddi bir vakit kaybıydı (4,5 saniye).Bu özelliği daha da geliştirerek her gece 2’de otomatik olarak desteklenen bütün kanalların yayın akışını hafızasında tutacak bir sistem hazırladım.Azure Websites üzerinde çalışan Web API projesi her gece Azure Webjobs’dan tetiklenen bir komutla hafızasındaki bütün kanalların yayın akışını yeniliyor ve bir sonraki güne kadar hafızasında tutuyordu.Böylece istenilen kanalın yayın akışı milisaniyeler içerisinde uygulamaya iletilebiliyordu.

Kanal sayısı arttıkça uygulamalaya iletilecek yayın linkleri artıyor ve bunların kontrolü de zorlaşıyordu.Bu linkleri bir veritabanı altyapısına bağlayarak herhangi bir link değiştiğinde Web API projesini tekrar tekrar publish etmekten kurtuldum.Artık yapacağım tek şey canlı sitesinden okunamayan kanallar için linkini veritabanına girmekti.Böylece uygulamada kullanabileceğim fully functional ve oldukça hızlı bir altyapıya sahip oldum.

Windows 8.1

Web API projesini hazırladıktan sonra uygulamayı derli toplu bir hale getirmek için çalışmalara devam ediyordum.PhoneSM’i izleme sayfasınad entegre ederek HLS yayın desteğini sağladım.Çoğu kanal kendi sitelerinde HLS yayını yapıyordu.Aslında Güncel Televizyon’un sahip olduğu bu zengin ve çalışan kanal listesinin tek sebebi HLS videoları oynatabilmesiydi.Arkasındaki API altyapısı sayesindeyse bu linkler hiçbir zaman ölmüyor , marketteki ratingleri gittikçe artıyordu.

Uygulama kullanılmaya başlandıkça yorumları okumaya devam ediyordum.Herkesin şikayetçi olduğu donma sorununa alternatif birşeyler bulmam gerekiyordu.Ülkemizdeki internet altyapısının verdiği düşüklük nedeniyle bazı kullanıcılar yayınları izlerken buffering sürecinde sıkılıyor ve kötü yorumda bulunuyorlardı.Ben de uygulamaya desteklenen kanallarda HD – Low quality özelliğini getirdim.Interent hızına güvenen kullanıcılar HD butonuna basarak en yüksek kalitede izleyebiliyorlardı.Düşük hızlı internete sahip kullanıcılar göz zevklerinden biraz fedakarlık ederek en düşük kalitede izleyebiliyorlardı 🙂 İleride bu özelliği daha da geliştirerek kullanıcılara destekleyen kanallarda seçebilecekleri bütün bandwith değerleri üzerinden izleme özelliği sundum.

Bu zamana kadar uygulamanın eksiklerini arkadaşlarımdan ve marketteki yorumlardan okuyordum.Bu takibin kontrolü biraz zordu haliyle.Kullanıcılar benimle olan iletişimlerini daha kolay yollardan iletmelilerdi.Bu nedenle bir Mobile Services projesi hazırlayarak uygulamaya iletişim formu koydum.Artık uygulamayı geliştirebilmek için daha fazla kaynağım vardı.

Uygulamaya yeni bir kanal eklendiğinde veya bazı kanalları kaldırmam gerektiğinde uygulamayı günellemem gerekiyordu.Bu başlı başına büyük bir sorundu ve çözümü çoktan düşünmüştüm aslında.Uygulamaya kanal senkronizasyon mantığını getirerek bu sorundan kurtulabilirdim.Uygulama açılırken version numarasını API’a gönderiyordu.API , version numarasını kontrol ederek o versiondan yeni bir version varmı diye kontrol ediyordu.Eğer update varsa , uygulamaya yeni kanal listesini gönderiyordu.Eğer yeni kanal listesi gelirse , uygulama bütün kanalları silip yeni kanal listesini locale kaydediyordu.Böylece bütün kanallar version numarasına göre senkron bir şekilde çalışıyordu.

Her kanalın fotoğrafı Azure Storage üzerinde açtığım bir blob üzerinde veritabanındaki kanal numarasına göre saklanıyordu.Eğer bir kanalın fotoğrafını güncellemem gerekirse sadece Storage hesabımdaki dosyanın üzerine kopyalıyordum.

Windows Phone 8.0

PhoneSM , Windows Phone 8.1 üzerinde çalışmıyordu.Ayrıca telefon uygulamasının Metro uygulamasından biraz daha yanar dönerli olması gerekiyordu , kısacası ekstra bazı componentlar kullanarak uygulamanın arayüzünü güzelleştirmem gerekiyordu.Telerik for Windows Phone kullanmaya karar verdim.API projesine çağrı yapan ve Windows 8.1 uygulamasında kullandığım bazı classları Windows Phone projesine aktararak büyük bir iş yükünün altıntan kolayca kurtuldum.Windows uygulamasındaki bütün özellikleri Windows Phone projesine aktararak Universal Project olarak markete gönderdim.

Mutluyum 😀

Sonuç

Benim için ‘Ben bunu yapabiliyorum !’ diyebildiğim bir proje oldu Güncel Televizyon.Şu an en yeni sürümü Windows Store mağzasında , telefon sürümü ise şu an için yayında değil.Vakit buldukça biraz daha geliştirip yayınlayacağım.Bunun yanında iki platformdaki appten de kaldırdığım push notification özelliği gibi özellikler de vardı , onları da vakit bulursam tekrar eklemeyi düşünüyorum.

Sayonara ! 🙂

0
Shares

T2 Mobil Hackathon Maceramız

Bu haftasonu 28 – 29 Mart tarihleri arasında Ankara Cyberpark’ta gerçekleşen T2 Mobil Hackathon’a arkadaşlarım Nejat ve Sezgin ile ben de katıldım.Cumayı Cumartesiye bağlayan gece otobüse atladık , sabah 6:30’da Ankaradaydık 🙂

AŞTİ’de Ankara serüvenimiz başlamış oldu.Etkinliğin başlamasında daha 2.5 saat vardı ve hafif yağmurlu havada mahsur kalmıştık.Bir proje düşünmemiz de gerekiyordu.Bilkent’e giden servislerin Sıhhiye köprüsünün ordan kalktığını öğrenip köprüye doğru servise bindik.Bir çayevine oturup kahvaltı ederken proje fikirlerini tartışmaya başladık.Güzel fikirler ortaya atıldı ve en sonunda Live@’te karar kıldık 🙂

Live@

Live@ , sokak sanatçılarının 10 ile 30 saniye arasında preview ses kayıtlarını telefonunuzdan paylaşıp , diğer sanatçıları keşfetmenizi sağlayan lokasyon bazlı bir mobil platform.Live@ ile gittiğiniz herhangi bir şehirde Keşfet bölümünden hoşunuza gidebilecek sanatçıların kısa demolarını dinleyerek çaldıkları adrese yol tarifi alabiliyorsunuz.Facebook login ile çalışan uygulamada sevdiğiniz sesleri favoriye alabilir , diğer sosyal ağlarda paylaşabilir ya da diğer kullanıcıların görmesini kolaylaştırmak için likelayabilirsiniz.Fikir aşaması , tasarımı , servisi ve clientı ile bir bütün halinde tamamen hackathon süresi içerisinde (yaklaşık 27 saat) ortaya çıkmış , herşeyiyle hatasız çalışan bir platform 🙂

Live@ Logo

Cyberpark’a girdiğimizde girişte kayıtlarımızı yaptırdık.Açılış konuşmasını ve Mustafa Kasap’ın Azure’a giriş konuşmasını dinledikten sonra bir 10 dakika içerisinde planlama ve iş paylaşımı yaptık.Serviste Sezgin , tasarımda Nejat ve clientta bendeniz Burak olarak grup MSP Alpha hackathona hazırdı 🙂

Planlamadan sonra 10:30 – 12:00 arası bir brain storming yaptık.Bu süre içerisinde uygulamanın amacını , çözüm bulduğumuz sorunları , prototip için feature listi ve kullanacağımız teknolojileri tartıştık.Servis için bir ASP.NET Web API , ses dosyaları ve saklanacak diğer dosyalar için Azure Storage , source control için Visual Studio Online üzerinde TFS , client için Windows Phone 8.0 ve veritabanı için de Azure SQL kullanmaya karar verdik.Hem hakim olduğumuz teknolojiler olduğundan dolayı ürünü daha hızlı ortaya çıkartabilecektik hem de arkasında Azure desteği olması gereken bir mobil hackathon olması dolayısıyla hackathon ruhuna bu tarz bir yaklaşımın daha iyi olacağını düşündük.

Sayfa tasarımlarında nelere dikkat etmeliyiz , renk paletimiz nasıl olacak vs. gibi görsel algıları da brain storming sırasında bir gözden geçirdik.Uygulama sayfalarını Nejat aradan çıkartırken biz de Sezgin ile backendde kullanacağımız projelerin hazırlıklarını yapmaya başladık.Servis için bir Azure Mobile Services projesi oluşturabilirdik , fakat Web API ile çalışmak bizim için hız açısından daha mantıklı olduğunu düşündük.

 

Client tarafında bir Universal App yapmayı başta düşünüyorduk , fakat compatibility açısından 8.0 projesinin hem daha hızlı hem de daha çözüm odaklı olduğuna karar verdik.Bir Portable Class Library üzerinden ilerlemeyi , bunun ileriki zamanlarla diğer platformlara uygulamayı çıkarmak için daha kolay olacağını biliyorduk fakat bu hackhaton süresi içerisinde kaynaklarımızı daha fazla harcayacağından dolayı vazgeçtik.Bunun yerine Windows Phone projesi içerisinde daha modüler bir yapı izleyerek aynı code sharingi yakalamaya çalıştık , oldu da 🙂

Bu hazırlıkların ardından Sezgin ile saat 2 gibi artık backend tarafında veritabanı tasarımına başlayabilirdik.1 , 1.5 saatlik bir tasarım sürecinin ardından kodlamaya başladık.Gerek tasarım , gerek sunucu gerekse client tarafında bazı zamanlar ortak bir fikirde karar kılmakta zorlansak da sonuç olarak ortaya tamamiyle çalışan hatasız bir prototip sunabildik 🙂 Bizim için zaten hackathon mantığı da buydu.

Biz bütün bu dizayn aşamalarıyla uğraşırken organizasyonu düzenleyen T2 de bizler için süreci kolaylaştırmak için herşeyi yapıyordu 🙂 Sürekli masamıza gelen ikramlar , yemekler , çerezler , içecekler derken zaten çalışmakan kaytarmak için masa başından ayrılamıyorduk 🙂 Organizasyon tam anlamıyla en ince detayına kadar düşünülmüştü.Gece 12 – 1 gibi uygulamada artık birşeyleri gerçekten ortaya çıkartabildiğimiz fakat neticesinde de enerjimizin taban yaptığı zamanlarda gelen enerji içecekleri çok ince bir detay olmasına rağmen benim gözümden kaçmadı 🙂 Soğuk havada kocaman kazanlarda gelen sıcak çorbalar , ihtiyacınız olduğunda rahat uyuyabileceğiniz karanlık ve geniş bir oda , sırtınız yere gelmesin diye uyurken altınıza alabileceğiniz Microsoft Azure matları falan derken size düşen tek şey de fikrinizi geliştirmek oluyor 🙂 Biz kullandığımız teknolojilere hakim olduğumuzdan dolayı pek mentor arayışına girmedik , fakat bütün bu süreçte etrafta takıldığınız yerde size yardımcı olmak için çabalayan mentorlar da bulunuyor , daha ne !

Çalıştığımız masa ilk günün sonunda (gerçi sürekli çalışma içerisinde bulunduğumuz için bizim için baş – son kavramı pek olmadı) resmen çöplüğe döndü.Heryerde kağıtlara çizilmiş ekranlar , user controller , usbler , detay yazıları , çerez kırıntıları , sandviçler , kola kutuları … 🙂

Masamız ...

Hackathon bitimine doğru jüri sunumu için ufak bir slayt hazırladık.Uygulamayı son olarak birkaç kere daha test ettik , jüri sunumunda yapacağımız demoda aksilikle karşılaşmamak için … 🙂 Artık hazırdık.Jüri sunumları başladı , 3. sırada biz vardık.Jüri üyeleri arasında Mustafa Kasap hocamız da vardı 🙂

Sunumdayız :)

Sunum sırasında Bilkent Cyberpark Genel Müdürü Canan Çakmakçı bize “2015 yılında neden video upload özelliği yok ?” sorusunu yöneltti , biz de video yükleme özelliğinin uygulamanın basitliğine aykırı olduğunu ve müziğin göze değil kulağa hitap eden birşey olduğunu belirttik 🙂 Sunum sırasında belirtmedim fakat bu soru üzerine benim söylemek istediğim birkaç şey daha var açıkçası.Ben bu yaklaşımı 2 farklı şeye benzettim.Birincisi , bu proje Twitter olsaydı , bundan birkaç sene önce olsaydı ve biz de Twitterın kurucuları olsaydık , sunum sırasında bu soruyu sormak “201x yılında sınırsız yazabilme imkanım varken neden 140 karakter ?” sorunusu sormak ile aynı şey 🙂 Ikincisi ise bu yaklaşımı “2020 yılındayız , bu uygulamada neden hologramik görüntüleme desteği yok ?” ya da “Bu uygulama neden Hololenste çalışmıyor ?” yaklaşımına benzetebiliriz 🙂

“Iş modeliniz nedir ?” ya da “Gelir modeliniz nedir ?” sorularına hiç değinmek istemiyorum , çünkü zaten biz bu projeyi geliştirirken tamamen fun project kafasında çalıştık , hatta organizasyona gelirken de bir haftasonu kaçamağı kafasındaydık 🙂 Sunum sırasında bu sorulara tabiki gelir elde edebileceğimiz kaynakları sunduk ki bunun sorulacağını biliyorduk ve hazırlığımızı yapmıştık.Fakat 27 saat içerisinde geliştirilmiş bir prototipten de gelir elde etmeyi beklemek hem hackathon ruhuna aşırı aykırı bir yaklaşım , hem de pek verimli bir yaklaşım değil.Bize göre bu sorunun cevabı 27 saatlik bir hacakthonda verilmesi gereken bir cevap değil ; ürünlerin değil , fikirlerin yarıştığı ve ucunda yatırımın kesin olduğu yarışmalarda verilmesi gereken bir cevap 🙂

Tabiki bu durum yalnızca T2 hackathon jürisine özel bir durum değil , genel olarak herhangi bir hacakthonun sonunda yaşanan bir durum malesef.Biz katılımcılar olarak hackathon jürilerine “Bizim uygulamamız bu kadar para kazandıracak , bakın arkamızdaki sunumda da görüyorsunuz zaten , uygulamayı bitiremedik ama sunumdaki gibi olacak ileride …” demekten ziyade “Biz xx saat aşırı yoğun bir tempoda çalıştık , sonuç olarak bu ürünü çalıştırabilir bir hale getirdik , buyrun cihaz budur , uygulama budur , alın elinizde canlı olarak test ederek değerlendirmenizi yapın” demeyi tercih ediyoruz.Çünkü bizim için hackathon ruhu böyle birşey 🙂 Sunum odaklı bir çalışma ortamı olsaydı biz 27 saat boyunca fikrimizi uygulama haline getirmek için çalışmazdık , bunun yerine 27 saatte dünyanın en göz boyayıcı sunumunu hazırlar , jüriden gelebilecek sorulara en ödül odaklı yanıtları belirler ve ön çalışmamızı yaptıktan sonra karşılarına çıkardık 🙂 Keşke Ankarada geçirebileceğimiz birkaç saat vaktimiz daha olsaydı da blogumda yazmak zorunda kaldığım fikirlerimi canlı olarak tartışabilseydik 🙂

Ikincilik pozumuz :)

 

MSP Alpha ekibi olarak geliştirdiğimiz mobil uygulama Live@ hackathonda ikinci oldu 🙂 Sunumların ardından yapılan kokteylde diğer gruplar ile keyifli sohbetler yaptık , organizasyon ekibiyle çok güzel bağlar kurduk.Özellikle teşekkür etmek istediğim ve bizi hackathon süresince yanlız bırakmayan iki isim ; Soner Altın(a.k.a Soner Abi) ve  Mustafa Kasap , herşey için teşekkürü borç biliyoruz , katıldığım(ız) en keyifli hackathondu ! Bir dahaki sefere görüşmek üzere ! 🙂

0
Shares

[Azure] MVA için Azure Virtual Machines Eğitimi

 

Herkese merhabalar , 5 Ocak Pazartesi günü Micosoft Türkiye ofisinde Microsoft Virtual Academy’de açılacak olan Türkiye kanalı için Azure Sanal Makineleri’ni anlattım.

Stüdyo ortamı 🙂

Başlıca değindiğim konular şu şekilde :

  • Windows & Linux sanal makineler
  • Basic Tier ve Standart Tier sanal makineler
  • Availability Setler
  • Windows Sanal Makinelere uzak bağlantı
  • Linux Sanal Makinelerine uzak bağlantı (SSH)
  • VMDepot
  • D-Serisi Sanal Makineler
  • Scaling
  • Endpoints
  • Pricing ve Calculator

Yakın zamanda Microsoft Türkiye tarafından hazırlanacak video yayınlanır ve bende buradan sizlerle paylaşmış olurum 🙂 Iyi haftalar !

0
Shares

[Azure] “Provisioning Failed” hatası

Güncel Televizyonun yeni sürümü için geliştirdiğim yeni Web API’ın testlerini yapmak için oluşturduğum bir Azure Website vardı.Makine durdur – çalıştır , sil – aynı isimle ekle işlemleri yapa yapa sanırım Azure’un bazı kısımlarını bozdum 🙂 Daha önceden 2,3 kere aynı isimle website açtığım için o arada birşeyler olmuş olacak ki 4. denememde ‘Provisioning Failed‘ diye bir hatayla karşılaştım.

Eğer siz de bu hatayla karşılaştıysanız , aşağıdaki garip ama etkili çözümü uygulayarak hatadan kurtulup eski ismiyle yeni bir Azure Website oluşturabilirsiniz :

  1. Azure Portal‘a giriş yapın.Girmiş olduğunuz Portal , Azure’un yeni portalı ve eski management system kafasındaki portaldan biraz daha gelişmiş özelliklere sahip.(Web Hostingplan Management gibi yalnızca Powershell üzerinden erişebileceğiniz değişik featureları da destekliyor)
  2. Sol alttaki “+”  işaretine basarak yeni bir Website oluşturun ve ismine hata alırken verdiğiniz Website ismini girin.
  3. Portal siteyi oluşturmaya çalışacak fakat hata verecek.Endişelenmeyin 🙂 Azure Management Portal ‘a giriş yapın.Bu da alışık olduğumuz eski portal.Websites kısmıan baktığınızda göreceksiniz ki az önce yeni Portalde oluştururken hata aldığımız Website aslında oluşturulmuş gözüküyor , ama aslında tam olarak da öyle değil.URL’den erişmeye çalıştığınızda 404 (Not found) HTTP sonucu alıyorsunuz.
  4. Azure Management Portal’den aslında var gözüken ama gerçekte olmayan Website’ı seçin ve silin.
  5. Silme işlemi tamalandıktan sonra Website’ı tekrar oluşturun.

Yukarıdaki adımlardan 4. adımdan sonra zaten sorunlu websitemize ait bütün sorunlar ortadan kalkıyor. 5. adım da yeniden oluşturmak için 🙂

Herkese mutlu pazarlar !

0
Shares

[Azure] Windows Azure Mobile Services Clientı Üzerinden Custom API’a Erişim – InvokeApiAsync Kullanımı

Bugün Microsoft Summer School ’14 için WAMS Custom API & Client Webineri verdim.Eğitimden sonra anlattıklarımı güzel bir blog yazısında toparlarsam herkes için daha faydalı olacağını düşünüyorum.Ufak bir Custom Controller oluşturma girişi yaptıktan sonra client kısmına geçeceğim.

Windows Azure Mobile Services (WAMS) Custom API Nedir ?

WAMS aslında Entity modelini destekleyen bir Web API projesi olarak düşünülebilir.Kendisinin oluşturduğu InserAsync,DeletAsync gibi methodların aksine biz Custom Controller’lar yazarak bu methodları özelleştirebiliriz.Büyük projelerde Custom API hazırlamak hem performans hem işlevsellik açısından büyük önem taşımaktadır.

 

WAMS Projesinde Custom API Controller Nasıl Oluşturulur ?

Projemizin klasörleri arasında yer alan “Controllers” klasörüne sağ tıklayarak “Add > Controller …” yolunu takip ediyoruz ve karşımıza çıkan template ekranında “Windows Azure Mobile Services Custom Controller” ı seçtikten sonra çıkan pencerede Custom Controllerımıza bir isim veriyoruz.Burada vereceğiniz isim sizin API isminiz olacak ve client tarafında kullanıyor olacağız.Ismin sonundaki Controller kelimesini silmeyi düşünmeyin bile 🙂

a1

 

WP8 & Win8 Projelerinde Mobile Services Clientı Nasıl Oluşturulur ?

Bunun için öncelikle henüz Prerelase sürümünde olan Windows Azure Mobile Services SDK’ı Nuget Packages aracılığıyla indirip projemize referans olarak eklemeliyiz.Projenize sağ tıklayın ve “Manage NuGet Packages” seçeneği ile paket yükleme penceresini açın.Ekranın sağ üst kısmındaki Search Online kısmına “Mobile Services” yazarak aratın ve en üstteki “Windows Azure Mobile Services” isimli paketi Install’a basarak projenize referans olarak ekleyin.

a2

Package dependencies’e bağlı olarak sizden birkaç farklı paketi daha onaylamanızı isteyecek.”I Accept” e basarak hepsini onaylayın ve paketi yükleyin.Paket başarıyla yüklendikten sonra References altında eklenen referansları görebilirsiniz.

 

App.Xaml.cs” dosyasına gelin ve en üstteki referanslar kısmına

using Microsoft.WindowsAzure.MobileServices;

 

yazarak Mobile Service Client için gerekli olan referansı kullanmak istediğinizi belirtin.Daha sonra aynı dosyada “sealed partial class” bölümünün hemen altına aşağıdaki gibi bir statik Mobile Service Client oluşturabilirsiniz.

public static MobileServiceClient mbs = new MobileServiceClient("MobileServicesUrl", "ApplicationKey");

Yukarıdaki kodda :
MobileServicesUrl = Azure’a publish ettiğiniz Mobile Services projenizin URL adresi
ApplicationKey = Oluşturduğunuz Mobile Services’ın Azure Portal’dan görebileceğiniz Application Key’i.( Manage Keys’e basarak görebilirsiniz )

Custom API Methodlarına Erişmek – InvokeApiAsync Kullanımı

Örnek projenin otomatik olarak oluşturduğu gibi TableController üzerinden Insert , Delete vb. işlemleri yapmak yerine , biz kendi yazdığımız Custom Controller üzerindeki methodlara erişmek istiyorsak bunu MobileServiceClient altında bulunan InvokeApiAsync asenkron methoduyla yapabiliyoruz.Bu methodun birçok overloadı mevcut ve ben bu yazıda sizlere en çok kullanılan türlerini , yani Entity , JToken ve Dictionary yapılarını kullanarak post etme ve HttpMethod belirterek Get & Delete işlemleri yapmayı anlatacağım.

Örnek kullanımlara geçmeden önce demoda kullandığım client datamodelini sizlerle paylaşıyorum , gerekli olan referansları imleç ile üzerine gelip Ctrl + (.) kısayoluyla kolay yoldan ekleyebilirsiniz.Demonun kullandığı Custom Controllerda bütün methodlar geriye bir string döndürmektedir.Bu nedenle InvokeApiAsnyc her kullanımda bir değişkene eşitlenmiştir.

    public class User
    {
        public string Id { get; set; }
        [JsonProperty("username")]
        public string Username { get; set; }
        [JsonProperty("password")]
        public string Password { get; set; }
        [JsonProperty("mail")]
        public string Mail { get; set; }
    }

Entity (DataModel) Kullanarak POST Işlemi

Syntax

MobileServiceClient.InvokeApiAsync<T,U>("ApiName",DataModelObject);

 

string ServiceOutput = await App.mbs.InvokeApiAsync<User, string>("User", new User { Id = Guid.NewGuid().ToString(), Username = "Burak",Password = "xxxxxxxxxx", Mail = "bkaankose@outlook.com" });

 

Yukarıdaki ilk kod örneğinde T = User Classımı , ApiName = Custom Controllerımın Adını , DataModelObject = User Classından Oluşturulmuş User Objesini temsil etmektedir.

Bir altındaki satırda ise demodaki hali yani örnek kullanımıdır.Biz burada InvokeApiAsync’in generic halini kullanıyoruz.
“<T,U>” şeklinde yazdığımız bölümde T = Sisteme Göndereceğimiz Objenin Türü (string,int,Class,bool vs.) , U = Sunucudan Bize Döndürülecek Olan Tür.

 

JToken Kullanarak POST Işlemi

Service client aracılığıyla bir class gönderebildiğimiz gibi bu classı parametreler halinde bir JToken olarak da yine InvokeApiAsync methoduyla yollayabiliyoruz.Fakat bu sefer sisteme göndermek istediğimiz türü veya sistemden almak istediğimiz türü belirtmemize gerek kalmıyor

Syntax

MobileServiceClient.InvokeApiAsync("ApiName",JTokenObject);
var j1 = new JObject();
j1.Add("id", Guid.NewGuid().ToString());
j1.Add("Username", "Burak");
j1.Add("Password", "xxxxxxxx");
j1.Add("Mail", "bkaankose@outlook.com");
string ServiceOutput = await App.mbs.InvokeApiAsync("User", j1);

Tıpkı Entity gönderirken yaptığımız gibi … Fakat burada bir class değil de parametre – değer ilişkisi tutan bir yapı gönderdik.

Dictionary Kullanarak POST Işlemi

Bir üstteki kod örneğinde yaptığımızın biraz daha değişik halini kullanarak bu sefer Post işlemi gerçekleştireceğiz.

Syntax

MobileServiceClient.InvokeApiAsync<Dictionary<string,string>,U>("ApiName",DictionaryObject);
App.mbs.InvokeApiAsync<Dictionary<string, string>, string>("User", new Dictionary<string, string> { { "Id", Guid.NewGuid().ToString() },{ "Username","Burak"},{"Password","xxxx"},{"Mail","bkaankose@outlook.com") } };

 

JToken’da yaptığım gibi göndereceğim parametreleri bir Dictionary<string,string> türüne getirerek InvokeApiAsync methodumu çalıştırıyorum.

 

Dictionary ve HttpMethod Ile GET Işlemi

Yukarıdaki kod örneklerinde 3 farklı şekilde POST işlemi yaptık.Sonuç olarak bakarsak aralarında hiçbir fark yok , yani hepsi aynı POST işlemi yaparak sunucuya kayıt eklemeyi sağlıyor.Yalnızca kullanımları farklı.

Bu örnekte bir HttpMethod belirterek Custom Controllerımızın GET methodunu çalıştıracağız.

Dikkat ! Kodlarda kullandığımız HttpMethod , Windows.Web.Http referansı altında değil , System.Net.Http referansı altındadır.Yanlış referansı eklemeniz kodların çakışmasına neden olur !..

Syntax

MobileServiceClient.InvokeApiAsync("ApiName",HttpMethod.Get,DictionaryObject);

 

string ServiceOutput = await App.mbs.InvokeApiAsync("User", HttpMethod.Get, new Dictionary<string, string> { { "uName", "Burak" } });

 

 

Parametre olarak gönderdiğim “uName” stringi , benim Mobile Services projemde Custom Controllerıma yazdığım GET Methodumun aldığı parametrenin adı.Aşağıdaki resimde örneğini görebilirsiniz :

a3

Dictionary ve HttpMethod ile DELETE Işlemi

Yukarıda GET işlemi yaparken yazdığımız kodların aynısını DELETE işlemi için de kullanabiliriz.Yapmamız gereken tek şey HttpMethodumuzu GET değil , DELETE e çevirmek.

Syntax

 

MobileServiceClient.InvokeApiAsync("ApiName",HttpMethod.Delete,DictionaryObject);

 

string ServiceOutput = await App.mbs.InvokeApiAsync("User", HttpMethod.Delete, new Dictionary<string, string> { { "uName", "Burak" } });

 

 

GET örneğinde olduğu gibi burada da Dictionary içindeki uName parametresi benim sunucu kısmında yazdığım parametrenin adına denk geliyor :

a4

InvokeApiAsync Kullanımında Dikkat Edilmesi Gereken Noktalar

WAMS üzerinden Server – client bazlı çalıştığımız için aldığımız hatalar client veya server tabanlı olabilir.Fakat InvokeApiAsync kullanırken aldığınız (500) Internal Server Error mesajları sizin client uygulamanızın çalışmasını durdurabilir.Bu nedenle InvokeApiAsync methodunu kullanırken try – catch yapısını kullanmayı ihmal etmeyin.Biz demoda veya eğitim videosunda bu tarz bir yaklaşım yapmadık , fakat sizin kişisel projelerinizde bunu yapmanız oldukça önemli.

Custom Controller içerisindeki Contextlerde “Contains” methodu ile arama yaptırmayın.WAMS .Net Backend henüz prerelease aşamasında olduğu için bazı methodlar tam olarak desteklenmiyor.Normalde bir collection içerisinde arama yapmak için “Contains” methodunu kullanabilirsiniz.Fakat siz Custom Controller Contextinizin içerisinde bir Entity sakladığınız için Contains methodu tam olarak isteğinizi karşılamıyor.Kodu yazarken herhangi bir hata almazsınız , fakat bu satıra ait method tetiklendiğinde sunucu anlık bir hata verir ve çalışmayı durdurur.

ApiName kısmına dikkat edin ! Oluşturduğunuz Custom Controlün ApiName’i , Controller kısmının solundaki kısımdır.Yani BurakController isimli bir Custom Controllerın Api Adı Burak tır … InvokeApiAsync methodundaki ApiName parametresine girmeniz gereken yer tam olarak bu kısım.

Client tarafında Id göndermeyi unutmayın ! Clientınızdaki DataModelinizde string türünden  bir “Id” özelliği tanımlamayı unutmayın.

 


Yukarıdaki örneklerde bahsettiğim Windows 8 Demo Clientına ve örnek Azure Mobile Services projesine buraya tıklayarak erişebilirsiniz !

27 Temmuz 2014 tarihinde verdiğim Webinerin kaydını aşağıdaki Youtube linkinden izleyebilirsiniz.

 

 

0
Shares