XCode’da Build Numarası Otomatik Olarak Nasıl Artırılır?

Yazılım geliştirirken karşılaştığımız kod dışında kalan birçok zorluk vardır. Bunlardan bir tanesi test. Beta dağıtımı hangi sağlayıcı üzerinden olacak? CI-CD süreçleri nasıl olacak? Kod nerede saklanacak? Teknik bilgi takım içerisinde nasıl dağıtılacak? Versiyonlama nedir? Build Numarası nedir? Uygulama yayınladıkça 1.0 dan 2.0 a çekilen Apple Store’un artırmamızı istediği sayıdan ibaret midir? Ve daha bir sürü soru aklımıza gelmektedir.

Yazılım geliştirmede karşılaştığımız sorunlardan bir tanesi de versiyonlamadır. Günlük hayatımızda kendisiyle sıkça karşılaşırız. Kullandığımız yazılımsal ürünlerin menüsünde, profil sayfasında, ayarlar sayfasında, sağında, solunda… v1.4.3 veya x.y.z gibi numaralandırmalar illaki gözümüze çarpmıştır. Bunlar versiyonlamanın ta kendisidir. Peki neye göre ve nasıl yapılır bu versiyonlama? Neye göre ve nasıl yapıldığı, firmanın sektördeki pozisyonuna, yaptığı işlere veya geliştiricinin keyfine göre tamamen farklılık gösterebilecek bir durumdur. Dünya genelinde sabit bir versiyonlama tekniği olmamakla birlikte, kullanılan teknikler birbirleriyle oldukça benzerdir. En yaygın kullanılanı da semantik versiyonlamadır. Biz de Peakup Labs mobil geliştiricileri ekibi olarak bu versiyonlama tipini kullanmaktayız. Semantik versiyonlamanın detaylarını buradan öğrenebilirsiniz. Versiyonlama konusunda bir çok Türkçe kaynak da vardır bu arada.

Build Numarası Nedir?

Çok temel bir şekilde anlatacağım. Bir yazılım ürününü geliştirirken genel olarak tüm ürünü bir anda ortaya koymuyoruz. Başlıyoruz bir şeyler yapıp kullanıcıya/tester a/yöneticiye… yolluyoruz. Yolladığımız kişi bakıyor ve şunları ekleyebilir miyiz, bunları değiştirebilir miyiz, şurada hata var… şeklinde geribildirim veriyor. Yapıyoruz tekrar gönderiyoruz. Peki gönderdiğimiz kişi bu 2 ürünü nasıl ayırt edecek? İşte burada versiyonlama ve build numarası devreye giriyor. İlk ürünümüzün numarası 1.0 iken ikinci ürünümüzün numarası 1.1 olduğu zaman, ikinci ürünün daha sonra çıktığını kullanıcı kolayca ayırt edebiliyor. Bazen 2. ürün yerine 1.ürünü kullanan bir kullanıcı olduğu ve 1.1 de düzelttiğimiz bir hatadan bahsettiği zaman direkt olarak kendisine 1.1 sürümünü indir orada o hatayı çözdük diyebiliyoruz mesela.

Build numarası da versiyon numarası da ürünü kimliklemek için kullanılan numaralardır.

Bu numaraların tek görevleri tabiiki kullanıcının sürümleri ayırt edebilmesi değildir. Aynı zamanda AppleStore veya Google Play Store aynı sürüm numarasına sahip build ları güncelleme olarak görmediği için yayınlamamaktadır. Belirli bir şekilde Build numarasının ve versiyon numarasının artırılması gerekmektedir. Versiyon numarası elle artırılabilir. Çünkü güncellememizin büyüklüğünü sistem bilemez belirleyemez bunu bilen bizzat geliştirici olduğu için genel olarak kendisinin artırması daha uygun oluyor. Ancak Build numarasını sürekli elle artırmak gerekmez. Adı üstünde Build numarası. Her Build’da artırılır. Bunu sürekli elle artırmak gibi bir iş bence Geliştirici olmanın ruhuna aykırı. Yazdığımız sistemi, uygulamayı otomatiğe bağlamaya çalışırken build numarasını sürekli elle artırmak resmen çelişkidir 🙂

IOS Ortamında Versiyonlama Sistemi

Şimdi gelelim fasülyenin faydalarına. Bu yazıda build numarasını nasıl otomatiğe veya git commit sayısına bağlayabileceğimizi anlatacağım. iOS uygulamaları yukarıda da bahsettiğimiz gibi 2 ayrı tipte versiyon numarasına sahiptir.

  • Short bundle version string CFBundleShortVersionString (e.g. 1.12)
  • Build Number CFBundleVersion (e.g. 190)

Her “Short version” içinde birden fazla build barındırır. Build ların herbiri de “Bundle Version” a tekabül eder. Yani build numarası her build yapıldığında artırılırken Versiyon numarası birkaç build dan sonra artırılır. Alttaki ekran görüntüsünde gördüğünüz üzere 1.4 Versiyon numarasına sahip sürüm, 34 ve 35 numaralı 2 farklı build barındırıyor.

Versiyon ve build numaralarından gereğinden uzun bahsettiğimize göre artık sadede gelip Build numarasını otomatik olarak nasıl artırabileceğimize geçelim. Çok basit bir Shell script kullanarak bunu başarabiliriz

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")buildNumber=$(($buildNumber + 1))/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Yukarıdaki script plist dosyasındaki build numarasını alır, 1 yükseltir ve elde edilen yeni sayıyı XCode’un PlistBuddy özelliğini kullanarak plist dosyasına geri yazar.

  • ${PROJECT_DIR} :  Ana projenin tam yolu
  • ${INFOPLIST_FILE}:  Info.plist dosyasının tam yolu

XCode’da Build Numarasını Otomatik Olarak Artırmak

İyi güzel hoş da XCode’da bunu nasıl yapabiliriz? Öncelikle bu yazı XCode 11.4 versiyonunu kullanarak yazılmıştır. İlerleyen XCode sürümlerinde bir şeylerin yeri değişirse eğer yazı güncellenecektir. Eğer güncellenmemişse bize ulaşmanız yeterlidir anında güncellenir. Adım adım yazdıklarımızı uyguladığınız takdirde Build numarasını otomatik olarak artırabilirsiniz.

    1. Uygulama Target alanını, ardından Build Phases sekmesini seçiyoruz
    2. Yeni bir Script eklemek için yukarıdaki + butonuna basıyoruz
    3. Açılan pencereden New Run Script Phase‘i seçiyoruz
    4. Yeni Script ekranı açılınca, alttaki ekran görüntüsünde gördüğünüz bölüme yukarıda yazdığım script parçasını yazıyorsunuz. Bu arada bu scriptin adını da değiştirebiliyorsunuz. İsimlendirme ımmm severiz
    5. Projeyi Build ettiğiniz zaman Build numaranız otomatik olarak artırılacaktır.

Build numarasını bu şekilde artırmak her ne kadar güzel bir yaklaşım olsa da ben bir türlü sevemedim. 🙄

İçinizden “ya arkadaş bu kadar yazıyı boşa mı yazdın buraya kadar boşa mı okudum seni tatmin etmek için daha nasıl build numarası artıralım?” dediğinizi duyar gibi oluyorum. Bu yaklaşım Build numarasını artırmakta Best Practice değil. Peki nedir bu konudaki Best Practice?

Tabiiki Build numarasını Git commit sayısına bağlamaktır. 

Build Numarasını Git Commit Sayısına Nasıl Bağlayabilirim

Eğer build numarasını git commit sayısına eşitlerseniz, build numarası arşa çıkmış olmaz. Ayrıca Apple Store ve iş arkadaşlarımızın istediği gibi daima bir önceki sürümden fazla olacağı garantidir. Her build de bu numarayı artırmak, zaman içerisinde bu numaranın çok fazla artmasına neden olabilir. Peki bu numaranın çok fazla artmasının bir zararı var mıdır yoo. Tamamen keyfimden git commit sayısına bağlıyorum 🙂

https://gist.github.com/alparslandev/51ad5bc0192ad4d52ffcac02d5e3b541

Yukarıda paylaştığım gistte gerekli scripti yazdım. Sizin de gördüğünüz üzere Build numarasını Git commit sayısına bağlı olarak artırmak tabiiki mümkün. Gistteki scripti yukarıda anlattığım şekilde 4. adımda gösterdiğim boşluğa yazabilirsiniz.

iOS Development hakkındaki diğer yazılarımıza buradan
Android ve Kotlin üzerine olan yazılarımıza buradan erişebilirsiniz.

Ali iyi bir yazılım geliştiricidir. Kendini geliştirmeyi yeni şeyler öğrenmeyi çok sever. Build numarasını sadece Apple Store’a uygulama yayınlayacağı zaman öğrenenlerden değildir. Çok daha önceden versiyonlamanın ve build numarasının değerini öğrenmiştir zaten. Ali Apple Store’a güncelleme yollayamadığında “aa Build numarası 1.0 kalmış. 2.0 yapayım o zaman” diyenlerden değildir. Ali Build numarasını otomatiğe bağlar ve Versiyonlama numarasına da çok titiz bir şekilde dikkat eder.

Ali için sürüm notları da çok önemlidir. Ali hep güzel, anlaşılır, kullanıcının hoşuna gidecek sürüm notları yazar. Çok küçük bir uygulama yazıyor bile olsa versiyonlama sistemini düzgün kurar ve artırır. Sonuçta nasıl alışırsa öyle gider değil mi? Eğer Ali bir kere bile amaann salla gitsin derse bunun sonunun hayra alamet olmayacağını çok iyi bilir. Boş vermeye alışmanın eninde sonunda olmadık yerde çok büyük bir patlamaya ve prestij kaybına yol açabileceğini çok iyi bilir.

Ali gibi olun. Çalışın.

Kaynaklar

https://developer.apple.com/library/archive/technotes/tn2420/_index.htmlhttps://crunchybagel.com/auto-incrementing-build-numbers-in-xcode/https://www.mokacoding.com/blog/automatic-xcode-versioning-with-git/https://fuller.li/posts/versioning-with-xcode-and-git/

Android Projesi Nasıl Git Submodule Kütüphanesi Yapılabilir?

Bu yazıda Android Git Submodule kütüphanesi nasıl yapılabilir sorusuna cevap vereceğim ancak nereden başlayacağımı tam olarak bilmiyorum. Galiba “Bir Android Projesi başka bir Android projesine nasıl eklenir” sorusunu kendime ilk sorduğum zamandan başlasam iyi olacak. Böyle bir ihtiyaç neden ve ne zaman doğdu?

Tam geçen sene birkaç hafta önce başlamıştı her şey. Peakup’ta işe girme sürecim devam ederken Peakup Labs departman yöneticisi Emrah Uslu ile yaptığımız teknik görüşme esnasında “Kaç proje yapacağız? Nasıl projeler yapmayı düşünüyorsunuz? Takımda Native Mobil geliştirici var mı?(Bu soru Legacy kod var mı anlamına gelir ve sorulması gerekir) …” vb bir çok soruyla kendisini güzel darlamıştım. “Yapılacak çok proje var hiç merak etme” diyerek, seneler sürecek tek bir büyük proje yerine irili ufaklı birbirinden farklı bir çok proje yapacağımızı ekledi. Bir önceki iş yerimde aklıma düşmüş olan “farklı projeler arasında ortak olarak kullanılabilecek bir Kütüphane” fikri bir kez daha mantıklı geldi. Kendisine bundan bahsettim mi hatırlamıyorum. İş başı yaptığım ilk günden itibaren bu tarz bir ortak kütüphane yapmamı özellikle talep etmişti.

Java mı? Tabiiki biliyorum Emrah Bey.

Örneğin Login sayfası, Dil ayarları sayfası neredeyse her projemizde var ve aynı. Veya onlarca method, özelleştirilmiş buton, envai çeşit view(CustomView), Extension function, Web servis request mimarisi, DSL yazacağız ve bunların her projede de bulunması gerekiyor. Üstüne üstlük hepsi aynı. Kopyala yapıştır döngüsüne girip projeyi çöpe çevirmektense bu ortak sayfaları ve özellikleri ayrı bir kütüphaneye ekleyip oradan ortak bir şekilde kullanmak daha basit ve akla yatkın değil midir?

Kopyala yapıştırın çok büyük bir zararını daha önce şöyle yaşamıştım: Birbirinden forklanarak oluşturulmuş 8 10 tane proje vardı. En ufak servis değişikliği bu projelerin hepsinde aynı değişikliği tek tek tekrar tekrar amele amele yapmak anlamına geliyordu. Ne derseniz deyin bu iyi bir geliştiricilik örneği değildir. Yapmayın. Uzak durun. Fork özelliğini çok daha verimli kullanabilirsiniz ve kullanın.

Open/Closed Principle, Software Reuse Don’t Repeat Yourself, Hatta SOLID prensiplerinin hepsi kütüphane sistemlerini şöyle bir düşündüğünüz zaman göreceksiniz ki büyük oranda destekler, kod kopyala yapıştır yapmayı da sağlıklı bulmaz.

 

Teknik Olaraakk?

Ne olduğunu ve neden gerekli olduğunu yeterince anlattığımı düşünüyorum. Peki anladık da teknik olarak tam olarak nasıl yapacaksın gibi bir soru zihninizde oluştuysa buyrun. Kütüphane deyince aklıma başta direk JAR dosyaları geldi. Ancak gördüm ki JAR dosyaları sadece Java SDK’sındaki sınıfları barındırabilir. Android SDK’sındaki Activity, Fragment, SharedPreferences, WifiManager… gibi sınıfları barındıramaz. Benim istediğim Kütüphane yapısında Activity, SharedPreferences gibi yapılar bulunmak zorunda. Bu durumda aklımıza gelen bir diğer yapı ise AAR dosyaları. AAR dosyalarının birkaç dezavantajı var. Bunlardan bir tanesi ve en büyüğü herhangi bir kod ekleyişinizde yeni bir AAR uzantılı dosya yaratıp bunu asıl projenize eklemeniz gereğidir. Peakup’ta legacy kodun bulunmadığı, kütüphanenin de asıl uygulamaların da tamamen sıfırdan, birlikte ve paralel yazılacağı düşünüldüğünde AAR dosyaları ile uğraşmak gerçekten eziyet verici. Kütüphane önceden yazılmış ve hazırlanmış olsa tamam AAR daha küçük yer kaplayacağı için tercih sebebim olurdu tabiiki ama değil.

Gerekliliklere baktığımız zaman:

  • Dinamik bir yapı başta geliyor.
  • Sürekli değişime yatkın. Ve sürekli değişimde bana(geliştiriciye) çok iş çıkarmayacak bir yapı.
  • Open / Closed Principle’a tapınma derecesinde uyması gerekiyordu. Çünkü bir çok proje yapacaktık ve yeni projelerde kütüphaneye kod eklediğim zaman varolan projeleri de bozmamalıydım. Herhangi bir proje VSTS’ten indirildiği an çalışıyor vaziyette olmalıydı.
  • İşte burada devreye Git’in bir özelliği olan Submodule girdi.

Kütüphane ilk olarak her projede aynı şekilde kullanılacak bir Authenticator katmanı içermeliydi. Malum giriş yapma ekranı. Kütüphanenin en büyük işi bu olduğu için adını PeakAuth olarak belirledik. O günden sonra PeakAuth gel PeakAuth git resmen çocuğum gibi oldu. Sevdim iOS’a geçene kadar sürekli geliştirdim sürekli bir şeyler ekledim… Peakup’ta yazdığım ilk Android Uygulama EnviSense‘ti. Ve sürekli “aa bu extension function’ı ben başka projelerde de kullanırım PeakAuth’a ekleyeyim. Aaa ben bu tarih formatlarını her projede neden tekrar yazayım ki hemen PeakAuth’a ekleyeyim…” diye diye Kütüphaneye ortak kullanılacak özellikler ve kod parçacıkları zamanla eklene eklene büyüdü. Çocuk örneği verdim ya tam bir çocuktu yani.

Tamam kodu ver artık hadi çok konuştun içim şişdi.

Not: Android Git Submodule, Git’in bir özelliği olduğu için kütüphane de asıl projemiz de git içerisinde barınmak zorunda.

 

Bir Uygulamayı Nasıl Android Git Submodule Haline Getirebiliriz?

Ana projemize kütüphaneyi eklemeden önce PeakAuth’un bir kütüphane olması gerekmektedir. Bunun için yapmamız gereken 3 adım vardır ve çok basittir.

    1. Android’de bir kütüphane projesi, başlatıcı bir activity ye sahip olamaz. AndroidManifest dosyasındaki hiçbir activity Launcher etiketine sahip olamaz.
    2. Android’de bir kütüphane projesi, app level build dosyasında en yukarıda com.android.application etiketine değil com.android.library etiketine sahip olur.
    3. 2.madde ile aynı dosyada default config bölümü altında normalde uygulamalarda bulunan applicationId kütüphanelerde bulunmaz, silinmesi gerekir.

İşte bu kadar. Artık PeakAuth diğer projelerde de ortak olarak kullanılabilecek bir kütüphane haline geldi.

Bir Kütüphaneyi Başka Bir Android Projesine Nasıl Ekleyeceğiz?

Kütüphane projemizi oluşturduktan sonra sıra geldi bunu kullanacağımız Android projelerine nasıl ekleyeceğimize. İsterseniz bunu Git’teki README dosyasına yazın ki ekip halinde çalışıyorsanız diğer arkadaşlarınıza kolaylık olsun. Hem bu tip önemli noktaların şirketteki tek bir geliştiriciye bağlı olmaması gerekir. Ayrıca sadece yapanın değil diğer geliştiricilerin de çok basit bir şekilde anlayabilmesi, ekleyebilmesi ve ihtiyaç olduğunda kullanabilmesi gerekir. Yazıda da pek çok kere bahsettiğim, Peakup’ta kullandığımız PeakAuth isimli Android ortak kütüphanesinin README dosyasında nasıl ekleneceği açık bir şekilde yazıyor. Çok önemli olan bir noktayı en başından belirtmem lazım. Aşağıda yazdığım son adıma kadar sync işlemi yapılmaması gerekmektedir. Tüm bağlantı ve ayarlar tamamlandıktan sonra sync yapılacaktır.

    1. Terminalden kütüphaneyi eklemek istediğiniz proje cd komutu çalıştırılarak açılır. İçerisine aşağıda gösterilen kod yazılır ve kütüphanenin linki eklenir.
      git submodule add https:…Veya çok daha basit bir şekilde SourceTree üzerinden de ekleyebilirsiniz. Projenize Git Submodule ekleyecekseniz hele benimki gibi dinamik bir amacı varsa bence mutlaka SourceTree kullanın. Proje içerisindeki submodule’ün yönetimi çok çok daha basit olacaktır. Projeyi SourceTree’de açtığınızda alttaki ekran görüntüsünde de gördüğünüz gibi Submodule seçeneğine sağ tıklayın ve Add Submodule seçeneğine tıklayın.
    2. Açılan pencerede gerekli bilgileri ve Submodule’ün linkini girin. Eğer Submodule’de birden fazla branch varsa da Advanced Options seçeneği ile hangi branche bağlamak istediğinizi yazabilirsiniz. Ardından tabiiki OK butonuna basmanız gerekiyor. Burada eklediğiniz dosyaya verdiğiniz isim çok önemlidir. Biz Peakup Labs mobil geliştiricileri olarak PeakAuth kütüphanesinin bulunacağı dosyaya haliyle “peakauth” ismini veriyoruz.

      Bu adımın ardından asıl projenize .gitmodule dosyası otomatik olarak eklenecektir.
    3. Projenin settings.gradle dosyasına girilerek şu satırlar eklenir
      :include ':peakauth' project(':peakauth').projectDir = new File('peakauth/app')
      
      

    4. Projenin application level gradle dosyasına şu satır dependency olarak eklenir
      implementation project(":peakauth")
    5. Sync yapılır. Yukarıda da söylediğim gibi bu adıma kadar sync yapılmaması gerekmektedir.

Eğer herhangi bir ara adımda yanlışlıkla sync yaptıysanız tüm değişiklikleri Git üzerinden Reset/Discard yapıp eklenen dosyaların tümünü silip sürece baştan başlamanız gerekmektedir. Son commit’e dönün yani. Ben birkaç kere yaptım ve baştan başlamaktan daha temiz bir yol bulamadım. Ayrıca kütüphane ekleme sürecine başlamadan önce de bir commit atmanızı tavsiye ederim. Başka değişiklikler olmasın ki toplu reset yaptığınızda kod kaybına uğramayın.

Projeniz yukarıdaki ekran görüntüsündeki gibi iç içe görünüyorsa Android Submodule kütüphanesi kullanıma hazır demektir. Gördüğünüz üzre içinde istediğiniz gibi gezebilirsiniz. Ki bu da AAR tipi kütüphanelerde olmayan bir özellik. Baştaki icon da önemli. Alttaki ekran görüntüsünde de SourceTree üzerinde projenizin nasıl görünmesi gerektiğini iletiyorum.

 

PeakAuth’a yani submodule olan kütüphanenize commit/push attığınızda SourceTree’de asıl projenizin altında duran Submodule’e tıkladığınızda nasıl görüneceğini de alttaki ekran görüntüsünde görebilirsiniz.

 

Hayat Kurtarıcı Not: Submodule’ü sadece kendi Repositorysinden kendi içinden güncelleyin. EnviSense’in içindeki PeakAuth’u güncellersek eğer bu asıl PeakAuth’a da yansıyacaktır ve kütüphaneyi kullanan diğer tüm projelerimizi bozabilir. Submodule’ü Dikkatli kullanmazsanız ortalığı fena karıştırabilirsiniz. Her ne kadar tatlış olsa da yönetimi projeler ilerledikçe zorlaşacaktır.

Android’de Submodule kütüphane kullanımı hakkında daha fazla bilgi istiyorsanız alttaki 2 kaynak benim için çok faydalı olmuştu. Onları da buraya ekliyorum.

https://medium.com/@deepakpk/how-to-add-a-git-android-library-project-as-a-sub-module-c713a653ab1f
https://proandroiddev.com/creating-a-library-for-android-ea976983db1

Blogumuzdaki diğer android yazıları için tıklayınız

İyilik ve Sevgi dolu, Bol okumalı günler dilerim.

Mart Ayı Ürün Güncellemeleri

Mart ayı PassGate ve Velocity ürün güncellemeleri:

PassGate

  • Yönetim paneli arayüzleri tamamen yenilendi.
  • Son kullanıcı web portal ayarlarının yapılandırabileceği yeni bir ekran eklendi.
  • Son kullanıcıya giden SMS’lerin içeriklerinin düzenlenebileceği yeni bir ekran eklendi
  • Cihaz bilgisi ekranı cihaza ait daha fazla bilgi gösterecek şekilde yeniden düzenlendi

Velocity :

  • Web Push Notification: Kullanıcılarınız; Velocity’e girdiğiniz tüm içerik ve haberlerden, tarayıcıları açık olmasa dahi, anlık bildirimler ile haberdar olabilecekler.
  • Widget Taşıma: Tüm widget’larınızı portal içerisinde dilediğiniz şekilde sıralayabilirsiniz. Yönetim paneli üzerinden istediğiniz widget’ları sağa, sola, yukarı ve aşağı taşıma işlemlerini yapabilirsiniz.
  • Multi-Tenant: Velocity içerisinde Holding> Grup Şirketler> Şubeler, Lokasyonlar temelli ayrımı yönetebileceğimiz MultiTenant geliştirmesi tamamlandı. Grup şirketler ya da birden fazla ofisi olup kendilerine özel portal oluşturmak isteyen şirketler tenant’larını tamamen ayrı bir şekilde yönetebilirler. MultiTenant alt yapısı ile birlikte alt portallar içerisine widget indirme yapabilecekler ve oluşturulan bir widget’ın hangi tenant’larda spesifik olarak görünebileceğine karar verebilecekler.

 

Şubat Ayı Ürün Güncellemeleri

[vc_row][vc_column][mk_fancy_title size=”20″ font_family=”none”]

PASSGATE

  • Active Directory üzerindeki herhangi bir kullanıcı ya da kullanıcı grubundaki kişilerin parolalarının başka bir kişi tarafından (Örneğin; Yönetici, Vardiya Amiri, Acenta Sahibi, Güvenlik Müdürü gibi kişiler) SMS ile sıfırlayabilmesi sağlanmıştır.
  • Entegrasyon: IBM AS/400
    AS/400 entegrasyonu yapılacak firma AS/400 sistemine verilen ad, yetkili kullanıcı adı, parolası, IP adresi ve IBM’in Windows için “Client Access” yazılımını PEAKUP ile paylaşması durumunda kurulum tamamlanır. AS/400 üzerindeki ilgili alanlar Kullanıcı Bilgi Servisi, Parola Sıfırlama Servisi ve Parola Değiştirme Servisi için kullanılabilir.
  • Kısıtlama: Yönetim panelinden gerekli durumlarda kullanıcıların PassGate ile parola sıfırlama özelliği pasif edilebiliyordu. PassGate ile parola sıfırlama işleminin kısıtlanmasını istediğiniz kullanıcının telefon numarası üzerinden süreli ya da süresiz kısıtlama tanımlama yapılabiliyordu. Artık parola sıfırlama özelliğinin yanında, parola değiştirme ve profil güncelleme özellikleri de kısıtlanabilir duruma geldi. Üstelik kısıtlama sadece telefon numarası üzerinden değil, e-posta adresi, kullanıcı adı, telefon numarası üzerinden kısıtlanabiliyor.
  • Parola Değiştirme Servisinin sadece Active Directory’de değil, sürece dahil olan tüm platformlar üzerinde kullanılabilmesi sağlanmıştır.
  • Parola prosedürleri için art arda gelen aynı karakterlere izin verilmesi/verilmemesi konfigürasyonu eklenmiştir. Firmaların “PassGate-Sistem Gereksinim & Konfigürasyonlar” formu üzerinde taleplerini belirtmeleri durumunda sistemlerine konfigürasyonları yapılır.
  • Sistem yöneticisinin yönetim paneli üzerinden kullanıcıların parolalarını sıfırlama işlemine ek olarak, hesap kilitlerini açma işlemini de yapabilmeleri sağlanmıştır.
  • Self-Servis Web portal üzerinden parola sıfırlama ve hesap kilidi açma süreçlerinin kullanıcı adı ile başlatılabilmesi sağlanmıştır.
  • Parola değiştirme ekranında validasyon kurallarına ek olarak uyarı mesajlarının da gösterilebilmesi sağlanmıştır. Firmaların “PassGate-Sistem Gereksinim & Konfigürasyonlar” formu üzerinde taleplerini belirtmeleri durumunda sistemlerine konfigürasyonları yapılır.
  • Parola prosedürleri için art arda gelen aynı karakterlere izin verilmesi/verilmemesi konfigürasyonu eklenmiştir. Firmaların “PassGate-Sistem Gereksinim & Konfigürasyonlar” formu üzerinde taleplerini belirtmeleri durumunda sistemlerine konfigürasyonları yapılır.
  • PassGate Web ara yüzünde firmaların hazırlamış olduğu KVKK Aydınlatma Metni’nin ayarlanabilir şekilde konumlandırılması sağlandı. Firmaların “PassGate-Sistem Gereksinim & Konfigürasyonlar” formu üzerinde taleplerini belirtmeleri durumunda sistemlerine konfigürasyonları yapılır.
  • Self-Servis Web portal üzerinde doğrulama kodu dışında T.C. kimlik numarasının kontrol edildiği bir adım ekleyebilme opsiyonu getirildi. İsteyen firmalarda aktif hale getirebilir durumdayız.

VELOCITY

  • Header’daki canlı hava durumu görselinin özelleştirilebilmesi ve yönetim paneli üzerinden yönetilebiliyor olması sağlandı. Firmalar Header için canlı hava durumunu ya da istedikleri bir görseli yönetim paneli üzerinden ekleyebilirler.
  • Çapraz kur entegrasyonu tamamlandı. Yönetim paneli üzerinden istenilen çapraz kur portal içerisine eklenebilir. Sadece çapraz kur değil, altın (XAU), kripto paralar da portal içinde listelenebilir.
  • Video yüklenebilen widget’lar için eklenen video görseli üzerine otomatik “Play” ikonunun konumlandırılması sağlandı.
  • Mega Slider için modal box’da içerik veya videonun gösterilmesi sağlandı.
  • Gönderilen widget bildirim e-postaları için “Bcc” özelliği aktif edildi. Firmalar yönetim paneli üzerinden bildirim yönlendirilecek e-posta içinde “Bcc” ve “To” alanlarını ayrı ayrı belirleyebilirler.
  • Widget içerisine yüklenen Pdf dosyalarının otomatik olarak indirilebiliyor olmasının ya da tarayıcıda açılabiliyor olmasının parametrik olarak belirlenebiliyor olması sağlandı.
  • Kullanıcılara yönlendirilen e-posta bildirimlerinde ilgili widget içeriğinin paylaşılıp paylaşılmamasının parametrik olarak belirlenmesi sağlandı.
  • Portale giriş yapanların lokasyonuna göre şehir seçiminin otomatik yapılması sağlandı.

Yeni Widgetlar:

  • KVKK Dokümanları
  • İSG Dokümanları
  • İnsan Kaynakları Prosedürleri ve Formları
  • Numaratör Widget’ı: Bir firmanın şirket dışındaki firmalarla yapılan satın alma teklifi gibi yazışmalarında kullanması için alınan yazışma numarası altyapısını sağlayan widget’dır. Numarayı alan kişi, yapacağı mailin konu kısmına bu numarayı ekler. Mevzuata uygunluk ve geriye dönük takip amaçlı olarak kullanılır.

[/mk_fancy_title][/vc_column][/vc_row][vc_row][vc_column][mk_image src=”https://peakup.org/wp-content/uploads/2023/12/velocity_imza_son.gif” image_size=”full”][/vc_column][/vc_row][vc_row][vc_column][mk_image src=”https://peakup.org/wp-content/uploads/2023/12/passgate_imza_son.gif” image_size=”full”][/vc_column][/vc_row]

Android Programlama İçin Kotlin mi Java mı #1

Kotlin mi Java mı

Kotlin ve Java programlama dilleri hakkında onlarca yazı yazıldı çizildi ancak 2020 yılında Kotlin mi Java mı sorusunun cevabı pek çok insan tarafından hala merak edilmekte. Yakın çevremde pek çok farklı kişiden aynı soruyu duymaktayım. İş görüşmelerinde mutlaka sorulan bir sorudur mesela. Kotlin’i tercih etmemin sebebi popüler kültür ve ilgi mi yoksa bilinçli yaptığım bir tercih mi. Amaç bunu ölçmek gerçi. Görüşmelerde “Kotlin diye bişey çıkmış. Herkes ona geçiyormuş ben de geçeyim diye düşündüm” demeyin uyarısını yapmama bilmem gerek var mı.

Peakup’ta işe girdikten sonra birkaç ay içerisinde geliştiricilerden oluşan takım arkadaşlarıma Kotlin mi Java mı konulu yaklaşık 45 dakikalık bir sunum yaptım. İstanbul Aydın Üniversitesi’nde IAU Android Talks etkinliğinde yapmış olduğum konuşmaya katılan öğrenciler ve yakın zamanda İstanbul Teknik Üniversitesi Girişimcilik Kulübü’nden ofisimize ziyarete gelen öğrenciler de aynı soruyu sormuştu. Yani tecrübeli iş arkadaşlarımdan öğrencilere kadar yazılımla ilgilenen herkes hala normal olarak Kotlin ile Java’nın farklarını merak etmekte. Ben de bu konu hakkında bir yazı kaleme alarak daha çok insana ulaşmak ve elimden geldiği kadar yardımcı olmak istedim. Çünkü bu sorunun daha çook sorulacağını düşünüyorum.

 

https://gph.is/2t3wKwS

 

Bu yazıda neden Kotlin, 2020 de Android programlama için Java bilmek gerekli mi, Android uygulama yazmak istiyorum Java öğrenmeli miyim, Android için Java mı Kotlin mi? Java ölecek mi hatta öldü mü gibi sorulara kendimce cevap vermeye çalışacağım. Ayrıca herhangi bir dil kıyaslaması yapmadım. Sadece Kotlin’e geçmeli miyiz veya ne zaman geçmeliyiz sorusunu cevaplamaya çalıştım. Dil kıyaslaması yapacağım bir başka yazı birkaç hafta içerisinde yayında olacak.

Özet Bilgi

Özet olarak Kotlin mi Java mı sorusunun basitçe verebileceğim bir cevabı bence yok ancak yazının özeti olabilecek bir cümle söylemem gereirse:

“Duruma göre değişir” derim

Yapacağınız projeye, öğrenci olup olmadığınıza, öğrenciyseniz üniversitenizin dillere yaklaşımına, sektörde çalışıp çalışmadığınıza, çalıştığınız yerde miras (legacy) kod olup olmadığına… Bu sorunun cevabı bunun gibi onlarca değişkene bağlı. Hap bilgi peşinde koşmak açık net cevap istemek yerine lütfen yazıyı sonuna kadar okuyun. Özellikle yeni jenerasyon çok sabırsız hemen her şey olsun, hemen cevap alayım, hemen bitireyim, hemen çok iyi proje yapayım, hemen… Lütfen biraz sabır. Siyah ile beyaz kadar net değil. Hayatınızın bu kadar hızlı akmasına gerek yok. Nefes alın nefes verin yaşayın. Benim Kotlin mi Java mı sorusuna vereceğim cevap gerçekten uzun. Okumaya üşenen bir insansanız şu an sekmeyi kapatmanızı tavsiye ederim ancak basit bir cevap olmayacağı olamayacağı için vaktinizi ayırmanızı daha çok tavsiye ederim. (Geliştirici olmak istiyorsanız okumaya üşenmeyin bi zahmet) Vakit vermeye değer dolu dolu bir yazı okuyacaksınız buna emin olun.

İnternet ne yazık ki koca bir çöplük haline geldi ve bilenle bilmeyen ayırt edilemiyor. 3 5 fazla reklam gösterelim diye koca sayfaya 3 satır yazılıp geçiliyor. İnternet çöplüğündeki pek çok yazı gibi Kotlin şöyle iyi böyle iyi hadi hemen geçin demeyeceğim bunu baştan belirteyim. Kotlin’e geçmek istiyor ve desteklenmeye ihtiyaç duyuyorsanız o tarz bir yazı tercih etmelisiniz. Bu yazı bambaşka bir yazı olacak.

Başlıyoruz !

Öncelikle şunu söylemek istiyorum ki herhangi bir dilin bir teknolojinin bağımlısı, fanatiği hatta kölesi olmamak lazım. Projeye göre duruma göre dil ve framework değiştirebilir olmak bence daha iyidir. Örnek olarak biz Java’cıyız 20 senedir böyleydik 20 sene daha böyleyiz düşüncesi bence yanlış. Kullandığımız teknoloji dil ve frameworklerin ne kadar süre hayatta kalacağı kesin değil. 2000 li veya 2010 lu yıllarda çok ünlü olup şu an 1 tane bile iş ilanı olmayan kaç tane programlama dili ve framework var. Bu dinamik dünyada ne olacağını asla tam olarak bilemeyiz.

Başka bir örnek vermem gerekirse şu an iOS ve Android çoğunlukla native olarak geliştiriliyor. Biz hala Java mı Kotlin mi diye tartışırken Google bir yandan da Flutter  isimli bir cross platform uygulama geliştirme frameworkü geliştiriyor ki birkaç sene sonra belki de o revaçta olacak. Belki de telefonlarımız Android işletim sistemine değil de ondan çok daha stabil çıkacak olan Fuchsia işletim sistemine sahip olacak. Bu yüzden dile veya frameworke bağımlı kalmak başka dil asla olmaz demek bence yanlıştır.

Bu yazıda kesinlike direkt olarak Kotlin daha iyidir deyip 1995’ten beri gelen Java kültürünü, kaynaklarını ve altyapısını da, kesinlikle Java deyip Kotlin’in getirdiği yenilikleri ve kolaylıkları da çöpe atamam, atmam kimseye de attırmam. Şimdi biraz daha derine inelim isterseniz.

1. Üniversite Öğrencisiyim Kotlin mi Java mı?

Kotlin mi Java mı sorusunun cevabını vermeye öncelikle öğrencilerden başlamak istiyorum. Bu soruyu soran merak eden kişi bir öğrenciyse kendisine olan tavsiyelerim ve sektörde çalışan arkadaşlara tavsiyelerim çok farklı olacak. Hatta sevgili öğrencimizin okuduğu yarıyıla derslerine göre bile değişecek.

 

  1. Okuduğunuz bölüm nedir?
  2. Yazılım dersleri bulunan bir bölümde mi okuyorsunuz?
  3. Hangi yarıyılda okuyorsunuz?
  4. Java dersiniz veya Nesne Tabanlı Programlama (Object Oriented Programming yazının her yerinde kısaca OOP diyeceğim) dersiniz müfredatınızda var mı? Bu dersi aldınız mı yoksa alacak mısınız?

Yazılım dersleri içeren Bilgisayar Mühendisliği, Yazılım Mühendisliği, Yönetim Bilişim Sistemleri… gibi bir bölümde okuyorsanız bulunduğunuz yarıyıl hayati derecede önemli.

1.a ) Daha ilk yarıyılda veya hazırlık sınıfındaysanız ve OOP dersiniz Java dili ile verilecekse

Kotlin mi Java mı sorusuyla üniversitenizin ilk yarıyılında veya hazırlık sınıfı aşamasında karşılaştıysanız müfredatınızı kontrol etmenizi şiddetle öneririm. Üniversitenizde OOP dersini Java ile mi anlatıyorlar? Öncelikle üst sınıflardan veya üniversite ders programından bu bilgiyi öğrenmeniz gerekmekte.  Java veya OOP dersi görecekseniz Java mı Kotlin mi sorusunun cevabı kesinlikle Java olacaktır. Java öğrenmeniz OOP dersinizin notlarına pozitif anlamda çok büyük katkı sağlayacaktır.

İstanbul Aydın Üniversitesi’nde yaptığım konuşmada sorulan bir soru buydu ve ben önce öğrenciye hangi yarıyılda okuduğunu sordum. 1.sınıf ta okuduğunu söyledi ve verdiğim cevap yukarıdakinden başkası değildi. (Şu an napıyor çok merak ediyorum 🙂 Java çalışmaya acilen başlayın. Acilen proje yapmaya ve GitHub’da paylaşmaya başlayın. Kodunuzun kalitesini şu anlık dert etmeyin kötü olabilir iyi olabilir. Kötü de olsa iyi de olsa bir şeyler yapın üretin paylaşın. Çünkü ileride işveren için bir şeyler üretmiş olmanız kesinlikle çok büyük bir önem arzedecek. Nerede bir yazılım öğrencisine rastlasam hep aynı öneriyi yaparım. Yazın boş durmayın kısa bir dinlenmenin, tatilin ardından mutlaka oturup Java çalışın. Eğer Java’yı veya herhangi bir programlama dilini nasıl öğreneceğim diyorsanız Bir Yazılım Dilini Nasıl Öğreniyorum başlıklı kendi blogumda paylaştığım yazıya mutlaka beklerim.

1. b ) Daha ilk yarıyılda veya hazırlık sınıfındaysanız ve üniversiteniz OOP dersini Java haricinde bir programlama diliyle C#, C++… aracılığıyla verecekse

Kotlin mi Java mı sorusuyla üniversitenizin ilk yarıyılında veya hazırlık sınıfı aşamasında karşılaştınız, müfredatınızı kontrol ettiniz ve C# anlatılacağını öğrendiniz. “Ben nasıl olsa Android Developer olacağım canım ne gerek var C# öğrenmeye” demeyin hiç boşa vakit kaybedeceğinizi düşünmeyin. “C++ ı da bitek bizim üniversite kullanıyor bir işe de yaramıyor” diyorsanız çok yanlış
düşünüyorsunuz. OOP Dersinin amacı size nesne tabanlı programlamanın temel prensiplerini öğretmektir. Size dil öğretmek değildir. Üniversite programlama dili kursu değildir. Üniversite size altyapı verir teori verir. Siz o altyapıyı alır nerede isterseniz kullanırsınız. Bu size kalmış. Üniversitenize C++ anlattığı için yeni jenerasyonun deyimiyle “atar yapmayın”. OOP’nin ne olduğunu bir kere öğrendikten, analitik düşünme yetisini bir kere kazandıktan sonra nesne tabanlı bir başka dile geçmeniz çok zor olmaz.

Yıldırım Beyazıt Üniversitesi’nde bir hocam şunu söylemişti “Nesne tabanlı programlama dillerinden kimisi sınıfa import ile başlar kimisi using ile kimisi başka bir şekilde ancak bunun alt kısmı diller arasında çok büyük farklar oluşturmaz.  for if while her programlama dilinde vardır ve aynıdır. Yazılışları farklı olabilir ancak aynı işi yapar aynı anlama gelirler. Bir Object Oriented dili çok iyi bir şekilde öğrendiyseniz bir başkasına geçmek ancak bir kaç haftanızı alabilir.” Kotlin mi Java mı sorusunun cevabına gelirsek Kotlin öğrenmek için acele etmeyin.

OOP dersinizde göreceğiniz dil üzerine çalışın. Hangi dil olduğu önemli değil o dile çalışın ve OOP dersinizi güzel güzel notlar alarak geçin. Sonrasında Android programlama öğrenmek istiyorsanız tekrar Java öğrenmenize bana göre gerek yok. Kotlin’den başlayabilirsiniz. Nesne tabanlı programlamanın temelleri çok önemlidir. Algoritmalar, Tasarım Desenleri, Yazılım prensipleri, Kod standartları… Bunları üniversiteniz hangi dilde öğretiyorsa siz de o dili çok iyi bir şekilde öğrenin. Emin olun ileride Kotlin’e geçmeniz çok daha kolay olacak.

1. c ) Üniversitenin 5. yarıyılından sonra bu soru ile karşılaştıysanız

OOP dersi geçti gitti. Ve siz bu dersten yeterince faydalanmadınız. Veya bu dersi hiç görmediniz. Veya Seçmeliydi zor hoca veriyordu almadınız(mezun olunca geliştirici olmayı düşünüyorsanız çok büyük hata. Mezun olunca ne olacağınıza karar vermediyseniz o çok farklı bir yazının konusu 🙂 İşte bu durumda üniversiteniz size nesne tabanlı herhangi bir dil öğrettiyse yine
Kotlin’den başlayabilirsiniz. Hiçbir yazılım dili göstermeyen veya en azından OOP prensiplerini öğretmeyen üniversite yoktur diye düşünüyorum ama her yer üniversite dolunca kalite düştü haliyle. Belki de vardır diye ben şu eklemeyi de yapayım. Eğer programlamanın temellerini biliyorsanız ama eksikleriniz de varsa Kotlin’e başlamanızı tavsiye etmem. Java ile başlayın. Çünkü Java’da kaynak sorunu çekmezsiniz. Onlarca kitap onlarca blog ve video bulabilir kısa zamanda uzun bir yol katedebilirsiniz. Çeşitli Kotlin kaynakları var ancak Java’nın kaynaklarıyla boy ölçüşebileceğini zannetmiyorum.

Sonuç olarak üniversitenizden güzel bir OOP bilgisi aldıysanız hangi dilde aldığınız önemli değil. Kotlin mi Java mı sorusuna Kotlin diye cevap veririm. Programlama altyapınızı yeterince iyi hazırladıysanız analitik düşünme yetisi kazandıysanız istediğiniz bir başka OOP dilde birkaç hafta içerisinde ufak da olsa proje üretir hale gelirsiniz.

2. Android Geliştirici Olarak Halihazırda Çalışmaktayım Kotlin mi Java mı?

Eğer zaten bir şirkette Android Geliştirici olarak çalışıyor ve Kotlin mi Java mı sorusunu soruyorsanız cevabım direk Kotlin olmayacaktır tabiiki. Size eninde sonunda Kotlin’e geçmenizi tavsiye edeceğim. Zaten Java’yı belli bir seviyenin üzerinde bilen birisi olduğunuz, OOP kavramlarını bildiğiniz için Kotlin’e geçmek sizi zorlamayacaktır. Kotlin’e geçin ama herkes hemen geçecek gibi bir durum yok. Ne zaman geçeceğinizi öğrencilere sorduğum gibi size de birkaç soru sorarak önereceğim.

  1. Şirkette şu an yaptığınız projeleriniz ne büyüklükte?
  2. Şirketiniz ne kadar yenilikçi ve yöneticileriniz kendinizi geliştirme isteğinize destek veriyor mu?
  3. Java ile halihazırda yaptığınız uygulamayı kaç kullanıcı aktif olarak kullanıyor?
  4. Kotlin’e geçirmek istediğiniz uygulamaya sürekli düzeltmeler ve güncellemeler çıkarmanız kullanıcı tarafından bekleniyor mu?

Yeni mezunsunuz üniversitede Java gösterildi. Java ile Android uygulamalar yazmaya başladınız ve bir start up firmaya girdiniz 3 aydır çalışıyorsunuz 2 tane ufak çaplı Android uygulamanız oldu ve bunlarda Java kullandınız. Size bir süre daha bu firmada Java ile devam etmenizi önereceğim. Sizin durumunuzda şu anlık ne yazık ki Kotlin’e ayıracak vaktiniz yok. İşverene kısa vadede sonuç üretmek kendinizi ispat etmek zorundasınız. Çok iyi bilirim o duyguyu. İş değiştirdiğinizde, veya bu iş yerinde 6 ay, 8 ay, 1 sene gibi önemli bir mihenk taşını devirdiğinizde Kotlin’e ufak ufak vakit ayırmanızı boş zamanlarda çalışmanızı tavsiye ederim. Sonra da yavaş yavaş şirket projelerinize entegre edersiniz.

2 3 senedir Java ile geliştirdiğiniz büyük bir projeyi sırf Kotlin çıktı ve Java’dan daha kolay diye direkt olarak bir anda Kotlin’e geçirmek, istemeyeceğiniz sonuçlar doğurabilir. Kotlin’i henüz öğrenme aşamasındayken direkt olarak büyük projeye giriştiğiniz için bocalayabilir, zorlanabilirsiniz ve motivasyon kaybına uğrayabilirsiniz. Benim de zamanında yaptığım hata gibi: Kotlin yazarsınız ancak Java gibi Kotlin yazarsınız.

Böyle bir şey çıkar ortaya ondan sonra

Şunu eklemeden geçemeyeceğim, PEAKUP’ta kendini geliştirmek isteyen her insana daima vakit ve kaynak ayrılır, yaratılır.

İşin bir de kullanıcı boyutu var ki bana göre yenilikçilikten de yöneticilerinizden de önemli bir boyut. Java ile yazdığınız uygulamayı onlarca kullanıcı kullanıyor ve sürekli iyileştirmeler, geliştirmeler yapmanız kullanıcı tarafından bekleniyorsa bu durumda Kotlin’e geçmeniz zor olabilir. Naçizane tavsiyem mesai saatleriniz dışında kesinlikle Kotlin çalışmanız ve Kotlin kullanarak birkaç orta ölçekli proje yapmanız ve kullanıcı da elveriyorsa projenizi yan bir dal (Branch) açıp yavaş yavaş Kotlin’e geçirmeniz olacaktır. Böylece ana dalı etkilememiş olursunuz ve istediğiniz an ana dala gidip hata düzeltme yapıp, özellik ekleyip sonra yine Kotlin migration dalına dönebilirsiniz.

  • Eğer yöneticileriniz kendiniz geliştirmeniz için zaman tanıyorsa,
  • Şirkete yeni girmişseniz ve şirketinizde daha önce hiç Native Android uygulama yazılmamışsa (Peakup’a girdiğimde karşılaştığım durum)
  • Şirkette varolan Java ile yazılmış Android uygulamalarınız stabilse, hata düzeltme ve özellik ekleme maddeleri çok fazla gelmiyorsa

Yukarıda sıralanan durumlarda hiç düşünmeden bir an önce Kotlin’e başlayın derim. Sıfırdan bir proje başlatıyorsanız direk Kotlin ile başlayın. Bilmiyorsanız da öğrenirsiniz ve bir proje yaparak Kotlin öğrenmek öğrenme yöntemlerinin en güzeli. Hem atalarımızın dediği gibi Kervan yolda dizilir, Damlaya damlaya göl olur, Denize dalmadan yüzme öğrenilmez…

Android Java’dan Tamamen Vazgeçecek mi?

https://gph.is/2In7bNS

Çoğunlukla iş arkadaşlarınızın veya iş görüşmelerinin sevilen çok tatlış bir sorusudur bu. Android’in Java’dan vazgeçmesi şu an için mümkün görünmüyor. Çünkü Android işletim sisteminde de milyonlarca satır Java kodu var. Google Play Store’da da sadece Java ile yazılmış onlarca uygulama var. Buna karşın şöyle de bir durum var Android Studio o kadar geliştirildi ki bir Kotlin projesine Java kodu yapıştırdığınızda (eğer yapıştırdığınız kodda syntax hatası yoksa) otomatik olarak Kotlin koduna dönüşüyor. Google, her etkinliğinde Kotlin’i hype yaparken, uzun uzun överken, Java hakkında iyi veya kötü bir açıklama yapmıyor. Şahsi fikrime göre Android Studio bile Kotlin için bu kadar bağırırken Kotlin’e geçmemek yanlış olur. Zaman içerisinde bu geçiş Google tarafından bile somut olarak yapılacaktır. Bir gün mutlaka ama bugün değil.

Kotlin’e Başlama Hikayem

Kısaca kendi Kotlin öğrenme hikayemden de bahsetmek istiyorum. Ben üniversite yıllarımda Java öğrendim. Pişman değilim. Bugün sahip olduğum bilinçle üniversiteye yeni giriyor olsaydım yine Kotlin değil Java öğrenmek isterdim. Java ile arayıp bulamayacağınız kaynak yokken Kotlin’de hala kaynak ve örnek sıkıntısı var. Kotlin pek çok konuda hala Java’dan destek alıyor.

Üniversitede Türk olmayan, Türkçe bilmeyen Java hocamızdan güzel bir OOP bilgisi aldık. Ayrıca önceki yaz ben de kendi çapımda Java çalışmıştım tabiiki bunun da etkisi oldu. Yine kendim uygulayıp faydasını gördüğüm ve öğrencilere sık sık verdiğim önerilerden birisi. Sene içinde göreceğiniz derslere önceki yaz çalışmak.

Üniversitenin ardından 2 sene Java kullanarak Android uygulamalar geliştirdim. Sonra Kotlin, Google tarafından resmi dil olarak ilan edildi ve ben Kotlin öğrenmek için yanıp tutuştum ancak öyle hemen başlayamadım. Çünkü çok büyük bir kaynak sıkıntısı vardı ve o dönemki iş yerimde hadi hemen Kotlin’e geçelim gibi bir ortam da oluşmadı. Daha çok -olması gerektiği gibi- bi bakalım durum ne olacak gibi bir yaklaşıma sahip olmuştuk ama kolaylıklarını kodu ne kadar kısalttığını öğrendiğimde gerçekten çok heveslenmiştim. 2017’de yıl içerisinde Kotlin öğrenme kaynakları artınca ben kendi çapımda kişisel blogumda yazılar yazmaya ufak çaplı projeler yapmaya başladım ama bir yerden sonra tıkandım. Neden ve nerede tıkandım?

Peki Kotlin Biliyor muyum?

“Kotlin öğrendim” veya “Kotlin biliyorum” gibi cümleler fazlasıyla iddalı cümleler. Bunlardan birini kurabilmek için daha büyük ölçekli projeler yapmaya ihtiyacım vardı. Kendi çapımda onu da yapmaya çalıştım. Orta büyüklükte olan eski bir projemi sıfırdan Kotlin kullanarak tekrar yazdım. İş yerindeki projelere entegre etmeye başlamaya hazırdım ki askere gittim. Ve askerde bir Kotlin kitabı edinerek Kotlin çalışmaya devam ettim. Askerlik bitince de PEAKUP’ta işe girdim ve burada sıfırdan başlattığım her projeye Kotlin ile başladım. Peki Kotlin biliyor muyum? Bu soruya hala “çok iyi biliyorum, sınav yapsalar 100 alırım, 10 üzerinden 10 biliyorum, Kotlin’le şöyle uçarım böyle kaçarım” gibi bir cevap veremem. Hem bir dili biliyorum demenin ölçütü nedir? O da çok ayrı bir mesele.

Java Öldü mü, Ölecek mi

Java öyle kolayca ölecek bir dil değil arkadaşlar. Java Android’den çok önce de vardı ve asla Android’e bağımlı bir dil olmadı. Java’nın arkasında dünyanın en büyük teknoloji şirketlerinden birisi olan Oracle var. Bu kadar büyük bir destek ve bitmeyen yatırımla binlerce geliştiricisiyle Java ölebilecek silinip gidebilecek bir dil kesinlikle değil. 20 yıl sonrasını bilemem ama 3 sene 5 sene sonrasını tahmin etmek zor değil bence. Pek çok otoriteye göre hala dünyanın en çok kullanılan 5 dili içerisinde. Oracle teknolojiye yetişmekte zorlanıyor olabilir. Ürünleri ve işlerinde bu günlerde pek çok açık kaynak rakip edindi ancak Oracle’ın asıl ürünü hardware. Kullandığımız onlarca makinenin içinde Oracle ürünü çalışıyor. Zaman içinde yeni dünyanın IBM’i olabilir mi evet olabilir. Oracle düşebilir ancak yakın bir zamanda değil. Oracle fakirleşse bile Java, geliştiricileri ölürse ve üniversiteler yüz çevirirse ölebilir. Belki. Kısa zamanda değil.

PEAKUP Blog‘da çıkan diğer Kotlin yazılarını görmek için tıklayınız

SwiftUI ve Jetpack Compose’dan bahsettiğim yazıyı okumak için tıklayınız

 

Cloud PaaS Servisleri

[vc_row][vc_column][mk_fancy_title color=”#0a0a0a” size=”20″ font_family=”PT+Sans” font_type=”google”]İstanbul Büyükşehir Belediyesi ile 3. CodeRunner buluşmamızı, Zemin İstanbul’da gerçekleştirdik. Etkinliğimizde Cloud PaaS Servisleri hakkında konuştuk.

Cloud PaaS Servisleri hakkında detaylı bilgi almak için sunumumuzu aşağıdaki linkten indirebilirsiniz.[/mk_fancy_title][/vc_column][/vc_row][vc_row][vc_column][mk_button dimension=”savvy” size=”medium” icon=”mk-moon-download-2″ url=”https://peakup.org/wp-content/uploads/2023/12/cloud-paas-servisleri.pdf” target=”_blank” align=”center”]İndir[/mk_button][/vc_column][/vc_row]

Jetpack Compose & SwiftUI

Herkese Merhaba. Peakup’ta Android Developer olarak çalışmaya başlayalı 6 ay oldu. Gidişat çok güzel. 5 ayda Google Play Store’a 5 adet sağlam Android uygulama yayınladık. Buradan uygulamalarımızın listesine erişebilirsiniz. En son yaptığımız İzin Yönetimi Android uygulamamız 12 Ekim 2019 tarihinde Google Play Store’a yüklendi ve kullanıma hazır hale geldi. Bu tarihten itibaren (yani 1 aydır) XCode ile iOS uygulamaları yazmaya başladım.

Android ve iOS ortamları cihaz olarak farklılar biliyorsunuz. Geliştirme ortamındaki fark cihaz farkından kat be kat fazla. Yeni bir dil, yeni bir IDE, yeni UI, yeni bir tasarım anlayışı, yeni kullanıcı alışkanlıkları, yeni … derken başlarda açıkçası sudan çıkmış balığa dönmüştüm. Swift ve Kotlin birbirine çok yakın diller olduğu için dil konusunda şanslıydım. Peki arayüz? Çok farklıydı. iOS’ta sürükle bırak kullanılıyordu kendimiz koda müdahale etmiyorduk ama Android’de de tam tersi sürükle bırak kullanmıyorduk. Derken SwiftUI’ın imdadıma yetiştiğini düşünmüştüm. Ama yanılıyordum. SwiftUI’a başlayalım mı başlamayalım mı derken Android de Jetpack Compose çıkarıp kafamı alt üst etmesin mi…

SwiftUI

SwiftUI

Google’da iOS öğreniyorum ne öğrenmem gerekir, iOS yedim zehirlendim, iOS kafası, iOS olmak istiyorum, iOS bize gelsin, iOS sistem gereksinimleri gibi araştırmalara başladım. Dolayısıyla çok uzun bir süre aramak zorunda kaldım 🙂 Haziran 2019 WWDC’de Apple’ın SwiftUI isimli yeni bir UI framework yayınladığını öğrendim. Bu Framework UI yazımını bayağı kolaylaştırıyor. Döküman ve internetteki çeşitli örnekleri incelediğinizde işleri kayda değer derecede hızlandırdığını ve çok pratik olduğunu göreceksiniz. Ayrıca öğrenmesi de çok kolay. Bu hevesle “Apple böyle taş gibi bir UI framework çıkardığına göre Storyboard sisteminin daha da yüzüne bakmaz” diye düşünerek hareket ettim ve ilk iOS projemi SwiftUI kullanarak açtım.

Projeyi yazmaya başladıktan sonra farkettim ki SwiftUI yeni çıktığı için dökümanlar ve örnekler çok azdı. Çıkalı 4 ay olmasına rağmen pek çok class deprecated olmuştu bile ve yerine stabil, çalışan bir kod da koymamışlardı. Buna dökümanlarda anlatılan bazı methodlar dahil. E tabiiki siz okuyana kadar çoktan düzelmiştir. Ancak o an ihtiyacım olan çok az bilgiyi bulabildim.

iOS 13

Mesela yazdığım uygulama için WKWebView bileşenini kullanmak zorundaydım. Bunun SwiftUI ile kullanımını merak ettim. Çok zor kaynak buldum. WKWebView içerisinde değişen linki almak istedim. Ancak başarıya hızlıca ulaşamadım. Hiçbir zaman kolay yolu tercih eden bir insan olmadım ancak alması gerekenden fazla vakit almasını da istemedim. Neyse deyip devam ettim. WKWebView ile olan işim uzun uğraşlar sonucunda çözülmüştü. Ancak SwiftUI da bir sayfadan başka bir sayfaya geçmekte bile zorlandım. Çünkü tüm View’ları NavigationView içerisine eklemeniz gerekiyor. Ve WKWebView ile oluşturduğum sayfayı onun içerisine almak pek mümkün görünmüyordu. Belki yeni başladığım için ben de becerememiş olabilirim. Bu yaşadığım çeşitli problemlere sadece bir örnekti.

SwiftUI Dezavantajları

  •  Bazı CustomView’ları SwiftUI kullanarak yapmaya başlayayım dedim ancak iOS 13 sınırı olduğunu öğrendim. SwiftUI ‘ı sadece iOS 13 güncellemesi yapmış iPhone’larda ve XCode 11 ve üzeri sürümlerde kullanabiliyorduk. Ayrıca kullandığınız mac, macOS Catalina işletim sistemine sahip olmak zorundaydı.
  • SwiftUI’ın henüz emekleme aşamasında olması geliştirilmeye devam ediliyor olması.
  • NavigationView içerisine eklenen WKWebView’dan url değişikliklerinin alınamaması.
  • SwiftUI yeni olduğu için bazı bugların olması ve stabil olmaması

gibi birçok sebepten ötürü aklım ve gönlüm SwiftUI’da kala kala şimdilik Storyboard’a dönmek zorunda kaldım. Bazı quora soruları ve bazı makaleler de bu görüşümü destekleyecek nitelikte. Acele etmeyin 1 sene hatta 2 sene bekleyin hemen geçmeyin diyen pek çok yazı ve görüşle karşılaştım. Storyboard sistemi ile yaptığım uygulama 2 hafta sürdü. SwiftUI’a verdiğim 1 haftada bunun çeyreği kadar ilerleyememiştim.

Ufak bir kod örneği vermek istiyorum.

SwiftUI Örnek

Bu yapı bildiğiniz DeclarativeUI yapısı. Kısa, net, anlaşılır ve açık yapısı ile gözlerimi kamaştırdı resmen. SwiftUI hakkında detaylı bilgi için sizi apple dökümanına davet ediyorum. Keşke Android’de de böyle rahat bir sistem olsa diyordum ki 2019 Ekim ayında yapılan Android Dev Summit‘te Android Jetpack Compose isimli bir UI Framework kullanıma açıldı.

 

Android Jetpack Compose

Android Jetpack Compose

Nedir Jetpack Compose? “React, Litho, Vue.js, Flutter gibi teknolojilerden esinlenilen Declarative UI Toolkit’tir” – Compose tanıtım videosu. İlk olarak 2019 Google I/O’da tanıtılan bu framework o zamanlar baya havada kalmıştı. Çünkü henüz yenebilen birşey değildi. Deneyemiyorduk ne olduğunu bile tahmin edememiştik çünkü sadece birkaç satır kod gösterilmişti. Böyle bişey yapıyoruz gelecek bu haberiniz olsun diye gösteriyoruz demişlerdi. 23 Ekim 2019’da yapılan Android Dev Summit’te ise resmen tanıttılar, gösterdiler. Android Studio 4.0 indirip Jetpack Compose’u deneyebileceğimizi söyleyerek iyice heyecanlandırdılar 🤓Henüz indirip deneme şansım olmadı. İlerleyen zamanda Android Jetpack Compose için ayrı ve özel bir yazı PEAKUP Blog’da belirecek hiç merak etmeyin.

Gördüğümüz kadarıyla Compose, işimizi çok hızlandıracak, UI yazımını çok kolaylaştıracak, daha okunabilir, daha hızlı anlaşılabilir, birkaç ay sonra döndüğümüzde şair burada ne demek istemiş diye daha az düşüneceğimiz kaliteli kod üretmemizi sağlayacak. XML dosyalarındaki kalabalık kodu güzel bir yolla azaltacak gibi. Heyecanla ilk fırsatta denemeyi ve ağzını yemeyi bekliyorum. E tabi içimden bi ses acele etme stabil değildir. Stabil olduğu zaman daha çok konuşulacak daha çookk rüyayı süsleyecek diyor. Compose için de bir kod örneği sunarak değerlendirmeye geçiyorum.

Android Jetpack Compose örneği

Ne güzelmiş öyle Text yazıp parantez açıp içine yazdığım textin hemencecik önizlemede TextView’a dönüşmesi. Altyapısını çok merak ediyorum bu hantal Android sisteminde bunu nasıl böyle yapabildiniz diye yakalarına yapışıp sormak istiyorum 🤗 Android Jetpack Compose hakkında detaylı bilgi alabilmeniz için döküman ve eğitim bağlantısını buraya ekliyorum. Yandaki telefon görüntüsü acaba preview mu yoksa emülatör mü diye de düşünüyorum bir yandan. Neyse olumlu düşünelim olumlu olsun. Preview o aynen. Hı hı preview tabi canım. Preview o emülatör değil o. İyi iyi baya iyi hızlı da aynı zamanda aynen.

Şaka bir yana şunu sorayım. Tanıdık geldi mi syntax yapısı? Gördüğünüz üzere Android’in getirdiği Jetpack Compose View Toolkit’i de SwiftUI gibi DeclarativeUI yapısına sahip. Sanırım yan yana kıyaslamasını gösterdiğimde daha da şaşıracaksınız:

SwiftUI & Android Jetpack Compose

 

Farkları

Evet benzerlik şaşırtıcı. Hatta ürkütücü derecede şaşırtıcı. Yeminle kopyala yapıştır yaparım 3 5 harf değiştiririm varya iki tarafın da arayüzünü bitirmiş olurum. Hem de responsive. Her cihaza uyumlu.

  1. Legacy kod ile olan bağları: SwiftUI, UIView ve UIViewRepresentable sınıfları ile oluşturulur ve UIViewController içerisinde, UIHostingController ile birlikte kullanılır. Jetpack Compose ise @Composable annotation ile oluşturulur ve @GenerateView annotation ile de XML içerisinde kullanılır.
  2. SwiftUI sınıfları Struct yapısına sahiptir. Struct’larda inheritance yok sadece protocol inherit edebilirler. Composable ise bildiğimiz normal bir fonksiyondur ve arayüzün sadece bir kısmını oluşturur. Tüm sayfadan sorumlu değildir. Ancak Kotlin’de fonksiyonlar sınıfa bağlı olmak zorunda da değildir. Dolayısıyla sadece Kotlin kullanarak hiç XML kullanmayarak View oluşturabiliriz diye düşünüyorum.
  3. SwiftUI’da body: View{ } kalıbı içerisine kod yazmak zorundayken Compose’da böyle bir zorunluluk yoktur, annotation bir fonksiyonu Compose fonksiyonu yapmak için yeterlidir.
  4. İki yapı da View’ları dikey veya yatay dizebiliriz. Dizilim sisteminde görünürde çok büyük fark olmasa da dizilim bileşenlerini  isimlendirmede farklar vardır. (Bi zahmet)
    Compose SwiftUI
    Row HStack
    Column VStack
    Stack ZStack
  5. SwiftUI “Bir kere yaz heryerde kullan” mantığından ziyade, “Bir kere öğren her yerde yaz” mantığına hitap ederken Compose tamamen tekrar kullanılabilir bir mantık sunuyor. Compose open source iken SwiftUI değil haliyle.
  6. Stil başlığında da birkaç fark olduğu görünüyor. Alttaki gistte gördüğünüz satırlar kendi içlerinde aynı işi yapıyor.

https://gist.github.com/alparslandev/d869f8a89443df184d4a9b5152a39496

Ortak Özellikleri

  1. Her iki teknoloji ile de özel view objeleri üretebilirsiniz. SwiftUI ile yapılan sınıflar da Compose ile yapılan sınıflar da başka sayfalarda CustomView olarak kullanılabilir.
  2. Bu Toolkitlerin en iyi yanı ise preview hizmetleri. SwiftuUI Canlı preview ile birlikte geliyor. Hatta etkileşime bile girebiliyorsunuz SwiftUI Preview ile. Burada bahsedildiği kadarıyla Android Studio da Live Preview özelliğine sahip. Şu çalıştır butonundan bizi bi kurtarın rica ediyorum. Button{ } yazdığım anda kendisi sağda preview açsın koysun butonu. Canlı canlı göreyim. SwiftUI’da kalbimi fetheden özelliklerden birisidir kendileri. Android Studio’da da performanslı ve tatlı olacağını umut ediyorum  (Gelecek gelecek Jetpack Compose yazısı gelecek ve geldiğinde buralara linklenecek…)
  3. SwiftUI’da macOS Catalina ve iOS 13 zorunluluğu olduğu için yakın zamanda SwiftUI’a geçen çok fazla uygulama göremeyebiliriz. Ve Compose tarafında da daha hızlı uygulanabilir olan daha şeffaf bazı sınırlar var elbet. Android Studio 4.0 ve uygulamanızın Api Level 21 üstü olması lazım. Android Studio zaten işletim sistemi bağımlılığı olmayan bir ide. Ancak zaten biz Peakup’ta Android projelerini zaten api level 21 üstüne açıyoruz artık.

Farklar benzerlikler uzayıp gider. Şimdilik burada bırakalım ileride Toolkitler geliştikçe buraları da güncelleriz.

Şimdi derin ve cevabını merak ettiğim bir soru var aklımda. İnşallah sizin aklınızda da uyanmıştır bu soru. Yazıyı buraya kadar okuduysanız uyanmalı bence 🙂  Neden 2 dev şirket birden ardı ardına DeclarativeUI yapısına sahip yeni UI Toolkit ve Framework yayınlar? Nedir ki bu DeclarativeUI biraz da ondan bahsedelim.

DeclerativeUI

Bir hesaplama mantığını, kontrol akışını açıklamaksızın ifade eden bir programlama paradigmasıdır. DeclarativeUI denince hemen hemen hepimizin aklına React ve Flutter geliyor. Hatta Google I/O’da kullanılan sunumun görselini hemen buraya iliştiriyorum. Google I/O Jetpack Compose DeclarativeUI

Klasik yöntem olan Imperative UI ile kıyaslarsak:

https://gist.github.com/alparslandev/3e62219a398f9daba916380bbc9ebe4b

Bu iki paradigma da UI yaratımı paradigması. Bunlar arasında heryerde geçen bir tabir var. DeclerativeUI da neyin neye benzediğini sadece açıklıyoruz. UI’da neye benzeyen bir obje istediğimizi söylüyoruz ve bir yere kadar onun stilini belirleyebiliyoruz. Mesela Buton istediğimizi yazıyoruz ancak tam pozisyonunu (x, y) cinsinden belirtmiyoruz. Yazılımcı tüm sürecin nasıl işleyeceğini tek tek yazmaz. Obje yaratımı ile frameworkler ilgilenir. UI yaratımı için her adımını bizim yönettiğimiz model ise paylaştığım Gistten de anlaşılacağı üzere ImperativeUI adını alır.

DeclarativeUI bize yazının başından beri bahsettiğim övdüğüm gibi çok daha kolay, çok daha kısa kod ile çok iş yapabileceğimiz bir model sunuyor. Kod daha okunabilir daha anlaşılabilir oluyor. Yapılacak şeye odaklanıyoruz. Nasıl yapılacağına değil. Vaktimiz de çok kısalıyor böylece. Peki buna Apple ve Google’ın altyapısı hazır mı. Android ve iOS platformları acaba bu tarz yeri yerinden oynatacak birer frameworke hazır mı bunu biraz düşünmek lazım. İşimizi hızlandırıp kolaylaştırdığı için bu modele yöneldiklerini düşünüyorum ancak bazı uyumsuzluklar stabilsizlikler ve bilimsizlikler işimizi uzatabilir de. Zaman içerisinde daha net yorum yapacağız elbet.

Gelecek

Okuduk anladık güzel hoş declarativeui swiftui compose tamam hadi dağılalım. Hemen değil 🙂 Beyin fırtınası olmadan olmaz. Bu işin geleceği ne olur? Android Studio’da UI tasarlayıp bunu iOS’a da uygulamak mümkün olabilir mi? Ya da tam tersi? UI kısmını tek bir kere geliştirip ufak değişikliklerle diğer ortama da uygulamak 🤔

Diyelim ki 3 sene sonra böyle birşey yapıldı. Cross-platform ama bir yandan da native UI geliştirebileceğimiz ortak bir toolkit bir framework yapıldı. Kolaylaştıkça işimiz hızlanıyor kabul. Ancak acaba işlerin fazla kolaylaşması kod yazıyor olma hissimi yok eder mi? Tarihte fazla kolaylaşan her şeyde olduğu gibi burada da değeri ve saygıyı düşürür mü? Neyse bunlar da başka bir yazının konusu 🙂

Not: Framework’ler henüz emekleme aşamasında. Gelişmeleri takip ediyor ona göre yazıyı güncelliyor veya yeni yazılar üretiyor olacağım.

Daha iyi bir yazılım için, gözünüz Kotlin ve Swift üzerinde olsun.
Yazılımla kalın, Esen kalın.

Kaynakça

http://nilhcem.com/swift-is-like-kotlin2019 Ekim Android Dev Summit Youtubehttps://flutter.dev/docs/get-started/flutter-for/declarativehttp://intelligiblebabble.com/compose-from-first-principles/https://quickbirdstudios.com/blog/swiftui-vs-android-jetpack-compose/https://medium.com/@ZoeWave/swiftui-jetpack-compose-db29036532dfhttps://codeburst.io/declarative-vs-imperative-programming-a8a7c93d9ad2https://medium.com/front-end-weekly/imperative-versus-declarative-code-whats-the-difference-adc7dd6c8380

DevOps Pratiğinizi Nasıl Geliştirirsiniz?

[vc_row][vc_column][mk_fancy_title color=”#0a0a0a” size=”20″ font_family=”PT+Sans” font_type=”google”]İstanbul Büyükşehir Belediyesi ile ilk CodeRunner buluşmamızı, Zemin İstanbul’da gerçekleştirdik. Etkinliğimizde ilk konumuz DevOps oldu.

DevOps Nedir ?

Development ve Operations kelimelerinin birleştirilmesinden oluşan bir terimdir.

Bilgi İşlem bölümleri içindeki farklı disiplinlerin sağlam bir güven ilişkisi ve etkili iletişim üzerinden beraber çalışmasıdır.

Yazılımcılar (dev) ve sistem yöneticilerinin (ops); tasarım, geliştirme, test ve yayınlama aşamalarından oluşan yazılım yaşam döngüsünde ve daha sonrasındaki destek aşamasında ortaklaşa çalışmaları için gerekli faaliyetlerin bütününü temsil eder.

DevOps sadece bir araç mı? HAYIR

DevOps hakkında detaylı bilgi almak için sunumumuzu aşağıdaki linkten indirebilirsiniz.[/mk_fancy_title][/vc_column][/vc_row][vc_row][vc_column][mk_button dimension=”savvy” size=”medium” icon=”mk-moon-download-2″ url=”https://peakup.org/wp-content/uploads/2023/12/devops-pratiinizi-gelitirmek-inovasyon-hznz-ve-evikliinizi-nasl-artrrr.pdf” target=”_blank” align=”center”]İndir[/mk_button][/vc_column][/vc_row]

Kotlin’de Yüksek Seviye Fonksiyonlar (High Order Functions)

Merhaba

2010’da Oracle, Sun Microsystems’ı satın aldığından beri Oracle ile Google arasında bir Java savaşı sürmekteydi. Oracle, Google’ı Java’nın ücretsiz olmayan özelliklerini kullanmakla suçlayarak büyükçe bir dava açtı falan filan hikayeyi biliyorsunuzdur hepsini anlatmama gerek yok sanırım. 2 sene önce GoogleIO 2017 etkinliğinde Kotlin, Google tarafından resmi programlama dili olarak ilan  edildi. O gün bugündür Android Geliştiricileri olarak Kotlin öğreniyoruz ve öğrenmeye devam ediyoruz.

“Kotlin fonksiyonel dil özelliklerine sahiptir” cümlesini pek çok Kotlin ve Android hayranından duymuş olabilirsiniz (Ben dahil). Nedir yani bu fonksiyonel dil özellikleri hadi örnek ver hadi… diyorsanız, toplanın yamacıma. Bu yazıda, Kotlin’in fonksiyonel dil özelliklerinden birisi olan yüksek seviye fonksiyonların kullanımını anlatacağım.

Fonksiyonel dillerde, fonksiyonlar özeldir tek başlarına bireylerdir. Literatürde bu first class tabiri ile ifade edilir. Yani String, Integer veya bir Sınıf ile fonksiyonlar aynı seviyededirler. Fonksiyonlara parametre olarak String veya Integer yollayabildiğimiz gibi first class fonksiyonlara sahip dillerde parametre olarak fonksiyon da yollayabiliriz. Fonksiyona parametre olarak fonksiyon yolluyoruz yani. Aynı şekilde başka fonksiyonlardan return tipi olarak fonksiyon da döndürebiliriz. Fonksiyonlar Java’nın aksine fonksiyonel dillerde herhangi bir sınıf içerisinde yer almak zorunda değillerdir. Fonksiyon çağıran fonksiyonlara yüksek seviye fonksiyonlar ismi verilir ve fonksiyonel diller yüksek seviye fonksiyon özelliğine sahiptirler. Kotlin de doğal olarak bu özelliğe sahiptir. Ayrıca fonksiyonel dillerde fonksiyonlar veri yapılarında ve değişkenlerde tutulabilirler. Özet olarak High Order Functions, Kotlin’in gözde özelliklerinden birisidir. Şimdi önce küçük bir örnek ile daha iyi açıklayacağım. Ardından Android’de real-life kullanımını göstererek pekiştireceğim. İzninizle, Başlayalım…

 

Parametre olarak fonksiyon kabul eden bir fonksiyonun tanımlanması aşağıdaki gibi yapılır.

https://gist.github.com/alparslandev/e9bfc3f401bf71cbfa1660fa33cf5924

Bu fonksiyon, şu 5 şekilde çağırılabilir:

passMeFunction ( “text” ) { print ( it ) }
passMeFunction ( “text” ) { s -> print ( s ) }
passMeFunction ( “text” , { print ( it ) } )
passMeFunction ( “text” , { s -> print ( s ) } )
passMeFunction(“text”, ::print )  // En pratik versiyon tabiiki bu. it veya herhangi bir başka değişkene gerek kalmaksızın Fonksiyon Referansı kullanarak kodu daha da basitleştirebiliriz.

KISS : Keep It Small Stupid hell yeeaa

 

Ben açıkçası bu özelliğe ihtiyaç duyduğumun farkında bile değilmişim. Kullanmaya başladığımda farkettim ki pek çok yerde high order function kullanabilirim.Özellikle orta ve daha büyük ölçekte bir proje yazarken pek çok defa aynı koda başka Activitylerde Fragmentlarda Sınıflarda ihtiyaç duyarsınız. Bu normaldir. Mesela kullanıcı silme işlemi kullanıcı listesinden de gerçekleşebilir kullanıcı detay sayfasından da. Ancak kopyala yapıştır yapmaya başlarsanız büyük projede ilerleyen safhalarda boğulabilirsiniz. Çöp kod üretebilirsiniz ve kod yönetimini kendi elinizle zorlaştırabilirsiniz. Her projeyi başından düzgün yazmanızı öneririm ki ilerleyen zamanda refactor için çok daha fazla zaman harcamanız gerekmesin.

Kullanım Örneği

Real-life örneğe gelirsek. Peakup’ta çalışanların hızlıca izin alabilmelerini, izin sürecini takip edebilmelerini, takım liderlerinin ve insan kaynaklarının da izin süreçlerini kolayca yönetebilmelerini sağlayan bir Android uygulamamız var. Leave Management. Bu uygulamamızı yazarken bir sorunla karşılaştım. İzin silme, izin onaylama ve izin reddetme işlemleri için hemen hemen aynı fonksiyonu yazdığımı ve gereksiz kod tekrarı yaptığımı farkettim. 3 operasyonda da İzin detay DialogFragment’ını önce kapatıp sonra silmek / reddetmek / onaylamak istediğinize emin misiniz? diye soran bir dialog çıkartıyordum. Kullanıcı onay butonuna basınca da ilgili fonksiyon aracılığı ile backende request yolluyordum. Yazılan fazladan kodu farkettiğimde High Order Function özelliği geldi aklıma. Çünkü 3 fonksiyonda da sadece Dialog’da yazan text ve çağırılan request fonksiyonu farklıydı. Ve şöyle bir Fonksiyon yazdım:

https://gist.github.com/alparslandev/eb148a5b847bec635dd855b04fd5d90f

showAlertAndOperate ismini verdiğim bu fonksiyon, 3 adet parametre alıyor. İlk parametresi bir Int ancak annotation olarak StringRese sahip. Yani bu fonksiyona göndereceğiniz ilk parametre R.string.xxx gibi bir string id olacak. İkinci parametre bir leave objesi. Son parametre ise işlemi yapacak olan fonksiyon. Son parametrede eğer izin silme işlemi yapacaksak izin silme requestini yapan fonksiyon, izin onaylama işlemi yapacaksak onaylama requestini yollayan fonksiyon çağırılacak yani.

showAlertAndOperate fonksiyonu önce izin detay dialog fragmentını kapatıyor. Ardından normal Dialog içerisinde gösterilecek olan texti StringRes ve Leave parametrelerini kullanarak hazırlıyor. Ardından bu texti showAlertDialog fonksiyonuna yollayarak Global alertdialogun çıkmasını sağlıyor. Dialogun onay butonuna basıldığı takdirde ise fonksiyona parametre olarak gönderilen fonksiyon çalışıyor.

https://gist.github.com/alparslandev/6eeeef8a852b3f07f51907aea2092dba

 

Yukarıda gördüğünüz fonksiyonlar ise İzin detay dialog fragmentına ait interface içerisinde bulunan buton onClick işleminde çalışan callbackler. Gördüğünüz üzre onLeaveApprove‘da confirmLeave fonksiyonu accepted modunda, onLeaveDecline‘da confirmLeave fonksiyonu declined modunda çağırılmış. onDelete’te ise deleteLeave() fonksiyonu çağırılmış. showAlertAndOperate fonksiyonunda belirtilen func() fonksiyonu yerine bu fonksiyonlar çağırılacak.

Kodu kopyala yapıştır yapmamak için tabiiki pek çok farklı yöntem de mevcut. Bu yazıda bu yöntemlerden sadece birinden bahsedebildim. En güzel yöntem budur golden keydir gibi iddialara sahip değilim. Sadece bu seferlik bunu tercih ettim ve sizlerle paylaşmak istedim.

Bol kodlu günler dilerim.