0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #15

Gauloran

Global Moderatör
7 Tem 2013
8,129
620
Merhaba hoş geldin. Bu konu mobil uygulama geliştirme serimin bir parçası. Serinin 14.bölümünden sonra uzun bir araya girmiştim ve yine devam ediyorum. Ne oluyor burada diyenler için:

0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #1
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #2
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #3
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #4
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #5
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #6
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #7
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #8
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #9
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #10
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #11
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #12
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #13
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #14

! STATE


Şimdi devam ediyoruz. Açıkçası 14.konuya kadar birçok temel konsepte değinmişiz ancak yeterli mi? Değil. Bu konum biraz farklı olacak çünkü 14.konuya kadar yaptığımız şeyler benim kendi kafamda belirlediğim bir sıralamaya ve öğretmeye öğrenmeye çok daha açık sıralaması dikkatle yapılmış bir şekilde ayarlamıştım ancak bu konuda birazcık sapmalar olacak yine de serinin devamı olacak. Bu sapmalar neler?

Bu sapmalar biraz benden de kaynaklı örneğin şimdi Google for Developers'ın da değindiği yahu bu Stateful Widget'ın mantığı ne şeklinde bir konuya değinip daha sonra artık oradan nereye süzülürsek diye devam etmeyi düşünüyorum yine de bu bir serinin katledilmesi olmayacak çünkü seri zaten uzun. Sabırla devam etmek gerek.

StatelessWidget kullanımını zaten bildiğimiz bir kavramdı serinin bu zamana kadar olan kısmında sürekli olarak kullanıyoruz

Kod:
class ItemCount extends StatelessWidget{
    final String name;
    final int count;
   
    ItemCount({this.name, this.count});
   
    @override
    Widget build(BuildContext context){
        return Text('$name: $count');
    }
}

Nedir işte Text widgetı alır ve bunu gösterir böyle bakınca epey basit. Bir şeyleri göstermek üzerine kurulu bir senaryoda mükemmel. Ama burada final int count olarak yazdığımız final bunu değiştirmemizi engelliyor ve ben bu count değerini artırmak ve bu değişimi UI üzerinde göstermek istiyorum? İşte bu noktada karşımıza Stateful Widget çıkıyor ama o nedir?



Kod:
class ItemCounter extends StatefulWidget{
    final String name;
    ItemCounter({this.name});
   
    @override
    _ItemCounterState createState() => _ItemCounterState();
   
}

class _ItemCounterState extends State<ItemCounter> {
    int count=0;
   
    @override
    Widget build(BuildContext context){
        return Text('${Widget.name} : $count');
    }
}
}

Üstteki kodları Stateful Widget'a çevirdiğimizde 2 sınıfımız oluşuyor birisi widget, diğeri state object. Widget 2 şeyden sorumlu bu bizim immutable name value'müzden ki oraya ekledik diye değişmeyecek final olarak belirtmişiz ve state object'i oluşturmaktan sorumlu. State object de final olarak belirtmediğimiz count'a sahip ve build metodu ile Text widgetı döndürülmüş.

1*5-aoK8IBmXve5whBQM90GA.png
Şimdi aslında ekranda gözüken şeylere element tree denir ve widgetlar sadece bu elementler için blueprint gibidir şema gibi düşünebilirsiniz. Tıpkı classların yani sınıfların kendi custom widgetlarımızı oluştururken classların blueprint olması gibi. Stateless Widget kullandığınızda Flutter sıkıntı yaşamaz ve bunu gösteririm derdim yok der. Elemente ihtiyacı var sadece widgeta sorup elementi oluşturur musun der böylece Stateless widget stateless elementi oluşturur.

Stateful yapısını kullandığınızda bu sefer Stateful widget stateful element döndürür ve bu stateful element, widget'a dönüp der ki selam bebeğim benim için state object yapabilir misin? İşte bu oluşturulan state object aslında yukarıdaki koddaki createState() metodudur.

ZeIxyQ.png


Şimdi yukarıdaki kodlamada bir Gesture Detector widgetını bu Text widgetının üzerine sarmalayın ve onTap'ine

setState(); koyun. setState() bu şekilde kullanılmaz da içerisine bir anonymous function alır yani

setState( () {} ); şeklinde. {} içerisine count++; şeklinde yazarsanız Flutter'da setState count ile ilgili yapılan değişimden sonra ilgili widget tree'leri günceller ve böylece UI'a yansır. Arkaplandaki şemada setState çalıştığında count 0'dan 1 olur

ZeIyf1.png



ancak yalnızca bu olmaz bir de state object onun elementini damgalar bu damgalamanın anlamı da bir sonraki gelen frame'de rebuild edeceği anlamına gelir. Artık yine build metodu çalıştığında yeni Text widgetı gösterilir ve bir önceki Text widgetı sallar peki ya bu Text widgetına karşılık gelen element aynı mı kalır? olduğu yerde kalıyor çünkü yeni frame ile oluşturulan bu Text widgetı yine Text widget olduğu için. Yani orijinal widget değişse bile element tree yapısı bozulmaz (ama aynı türde olması lazım gidenin yerine gelenle) Hatta didUpdateWidget metodu bile var. Bu metod ile eğer state object'inizin widget'ın ne zaman değiştiğini öğrenmeye ihtiyacı varsa override edebilirsiniz. Ama sürekli stateful widget kullanmak da işleri karmaşık yapacağından Inherited Widget'dan bahsetmemek olmaz.

? GENEL TEKRAR EVRENİNE GEÇİŞ

not: bu evrende geçen her 1 konu mobil uygulama geliştirme serisinin 0,1 konusuna denk geliyor.
image-w1280.jpg


Dur dur... duralım biraz. Çok hızlı yol almadık mı sence de? Çok hızlı gittik sanki. Ben bile anladım bahsederken 1.konudan 14.konuya kadar geldiğimiz yere kadar bir ton şeyden sırasıyla bahsettik ve şimdi hızlanmaya başladık ve buraya kadar geldik. Bence şu an hemen burada durup genel bir tekrar yapmanın vakti geldi. Sence de gelmedi mi? Şöyle serisinden hızlı hızlı bir tekrar atmak bence fena olmaz. Tekrarı atarken de belki bahsetmediğim bazı ufak detaylardan bahsederim belki yine üzerinden geçeriz. Devam ettiğimizde de bu STATE başlığından devam ederiz.

Bu zamana kadar Flutter'ın runApp(); ile başladığını ve bu fonksiyonun core'dan gelen bir şey olduğunu ve flutter tarafından sağlandığını anlattım. Yani dart dilinde built-in olan bir şey değil de flutter framework tarafından sağlanan bir şey. Fonksiyonlardan ve fonksiyonların body kısmından bahsettik yazım şekli şöyleydi

dönüş türü - fonksiyon ismi (parametreler/argümanlar) { .... }

bir fonksiyonu çağırmak istediğimizde runApp(); kullandığımız buydu ve Flutter open source yani açık kaynak kodlu olduğu için runApp fonksiyonunu girip inceleyebiliyoruz ve nereden geldiğini anlayabiliyoruz. Normalde flutter projemizde klasör yapımıza göre pubspec.yaml dosyamızda flutter framework'ün ekli olması gerektiğini ancak bir flutter projesi oluştururken zaten bunun otomatik olarak pubspec.yaml dosyamıza eklendiğini söylemiş olmam lazım. import keyword'ünden bahsettik ki bu da dartta built-in bir mevzu yani bu keywordler önemli ve Dart bunları algılıyor. package eklemek için import '' veya "" kullanmamız gerektiğini söylemiştik ve statementlarımızın sonuna ; eklememiz gerektiğini belirtmiştik.

main fonksiyonu da zaten özel bir fonksiyon çünkü uygulamamızın giriş noktası. Bizim main fonksiyonumuzu çağırmamıza gerek yok. Flutter'a ekranda neyi göstereceğini sıra sıra düşünürsek runApp söylüyor ve bu şekilde UI elementleri gösteriliyor.

Positional Argument

parametrenin argüman demek olduğunu biliyoruz. Flutter user interface widgetlar tarafından oluşturulduğundan eninde sonunda uygulamamızın widget tree yani widget ağacından meydana geleceğini biliyoruz örneğin yukarıdan aşağıya:
MaterialApp
Scaffold
Row
Text, Text, Text

widgetları şeklinde widgetlar bütününe widget tree diyebiliriz ve Flutter bize birçok widget veriyor zaten örneğin butonlar inputlar layout widgetları falan filan. Kendi custom widgetlarımızı yapmayı da biliyoruz ama yine de genel tekrarı öyle toz alırmış gibi yapmayıp oralara da geleceğim. runApp(MaterialApp()); burada MaterialApp widgetı yine core bir widget ve Flutter uygulamamızla ilgili bize bir ton şey anlatan bir setup. MaterialApp'e bir parametre eklememiz gerekli ki ekranda bir şey gösterebilelim. Bir fonksiyon tanımladığımızda fonksiyonun parametresi olarak named parameter dediğimiz çeşidi kullanabiliriz sadece {}ile sarmamız yeterli. Ve böylece fonksiyonu kullanırken parametreleri hangi sıralama ile geçtiğimiz önemsizleşir.

MaterialApp widgetına gidin flutter core'undan bahsediyorum orada {} bunları göreceksiniz çünkü bir sürü named parameter kullanılmış. MaterialApp widgetında home: named parameter var örneğin.

FONKSİYON PARAMETRELERİ, POSITIONAL VE NAMED PARAMETERLAR

ZeItjM.png


Positional: örnek olarak
Kod:
void add(a , b )
dümdüz positional parameter diyebiliriz bunlara. Bunları vermek zorunlu bir halde şu an.
void add({a,b}) bunlarsa yukarıda bahsettiğim gibi named parameter verirken a: blabla, b: blabla şeklinde sıralaması da önemli değil ayrıca bunlar default olarak opsiyoneldir vermek zorunlu da değil vermeden de kullanabiliriz fonksiyonu.
ama positional argumentslar da opsiyonel yapılabilir mesela
Kod:
void add(a, [b])
şeklinde burada b parametresi artık opsiyonel. Ve bir parametre opsiyonel ise ona default değer de atayabiliyorsun.
Kod:
void add(a, [b=5])
b opsiyonel bir parametre default değeri de 5 yani bir değer atanmazsa 5

default değerler named parametrelere de atılabilir
Kod:
void add({a  ,b = 5 } )
şeklinde yine. örneğin a ya bir değer atanmazsa burada fonksiyon kullanılırken a null gelecektir. o da ayrı bir type ondan sonra bahsederiz. Gerçi bahsettik zaten genel tekrar içindeyiz şu an farklı bir zamanda gibi düşünün tenet interstellar güzel filmler bunlar burada durun izleyip gelin belki bir aydınlanma yaşayabilirsiniz.

named parametreleri de yine dartta built-in required keywordü ile opsiyonel olmaktan çıkartıp zorunlu hale getirtebiliyorsunuz ki genelde bu daha fazla kullanılır void add({required a, required b}) artık a ve b opsiyonel değil.

CONST VALUELARI ANLAMAK

Vscode da hep gördüğümüz optimizasyon ve geliştirme potansiyeline sahip olan kodlarda const kullan uyarısını almayan yoktur. Const dart tarafından bize sağlanan bir keyword ve uygulamamızın runtime performansını artırmayı sağlıyor. Örneğin bir Text widget cihazın hafızasında tutulurken const kullanılmışsa bu text widgetı ikinci defa kullanılacağı zaman hafızada ikinci bir nesne yaratılması yerine tekrar kullanılıyor ve böylece memory efficient dediğimiz hafızayı daha iyi kullanmış oluyorsunuz.

DAHA KOMPLEX WİDGETLAR KULLANMAK VE TYPE'LARI ANLAMAK


MaterialApp widgetının bizim root widgetımız olduğunu ve uygulama ile ilgili setup ayarlarını buradan yönettiğimizi söyledik. Scaffold widget ise şöyle genel olarak uygulamamız için bir iskelet gibi iyi görünmesini sağlayan bir widget. Dart type-safe bir dil olduğu için çalışacağımız her şey belli türlere ait oluyor.

ZeI4aK.png


String örneğin, int, num, hatta MaterialApp'in türü MaterialApp ve en nihayetinde bu bir Widget türünde ve bahsettiğim her şey en sonunda bir Object'tir. Yani değerler birden fazla type olabilir örneğin bahsettiğim int çok daha spesifik bir type. Objectler Dart dili için core bir konsept objectleri hafızdaki data yapıları gibi düşünebiliriz. Dart dilinin desteklediği bazı türlere bakalım

ZeIOJ3.png


Mesela Container widgetı const'u desteklemeyen bir widget bu nedenle onun widget tree'sinde const kullanamazsınız IDE bunu söyler tabi ve Container widgetını incelediğinizde Decoration? decoration görürsünüz Decoration da bir type tır ve şu şekildedir:
Kod:
{Decoration? decoration} Type: Decoration?

Örneğin orada BoxDecoration kullanabilirsiniz çünkü BoxDecoration da zaten Decoration sınıfından türemiştir.

Generic Typelardan da bahsetmeden geçmeyelim bunu da List lerden örnek verilip bahsedilir sadece kavramın üzerine bir iki şey söyleyeceğim yine geleceğim buna ama örneğin List ler de Dartta bir type ve epey de esnek. Yani 2,3,4 koyabilirsiniz 'a','b','c' koyabilirsiniz <> List<> olarak <> arasına koyabilirsiniz ve bu şekilde kullanılabilir haldeyse Generic Type lara şimdilik flexible typelar diyelim.

Genel tekrara devam genel tekrarı yaparken birkaç uygulama örneği ardından Riverpod'tan bahsedip genel tekrar evrenini bitirdikten sonra Inherited Widget ile Bloc pattern ve sonrasında örnek uygulamalara geçebiliriz. Genel tekrarın henüz tahminimce 10-15 bölüm olur 3.kısmına falan gelmişizdir tam kestiremedim. Bu uzun soluklu bir seri olduğu için devamm.

Okuduğunuz için teşekkürler <3 Gauloran​
 

drjacob

Uzman üye
21 Ocak 2012
1,773
402
localhost
Merhaba hoş geldin. Bu konu mobil uygulama geliştirme serimin bir parçası. Serinin 14.bölümünden sonra uzun bir araya girmiştim ve yine devam ediyorum. Ne oluyor burada diyenler için:

0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #1
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #2
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #3
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #4
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #5
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #6
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #7
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #8
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #9
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #10
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #11
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #12
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #13
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #14

! STATE


Şimdi devam ediyoruz. Açıkçası 14.konuya kadar birçok temel konsepte değinmişiz ancak yeterli mi? Değil. Bu konum biraz farklı olacak çünkü 14.konuya kadar yaptığımız şeyler benim kendi kafamda belirlediğim bir sıralamaya ve öğretmeye öğrenmeye çok daha açık sıralaması dikkatle yapılmış bir şekilde ayarlamıştım ancak bu konuda birazcık sapmalar olacak yine de serinin devamı olacak. Bu sapmalar neler?

Bu sapmalar biraz benden de kaynaklı örneğin şimdi Google for Developers'ın da değindiği yahu bu Stateful Widget'ın mantığı ne şeklinde bir konuya değinip daha sonra artık oradan nereye süzülürsek diye devam etmeyi düşünüyorum yine de bu bir serinin katledilmesi olmayacak çünkü seri zaten uzun. Sabırla devam etmek gerek.

StatelessWidget kullanımını zaten bildiğimiz bir kavramdı serinin bu zamana kadar olan kısmında sürekli olarak kullanıyoruz

Kod:
class ItemCount extends StatelessWidget{
    final String name;
    final int count;
    ItemCount({this.name, this.count});
    @override
    Widget build(BuildContext context){
        return Text('$name: $count');
    }
}

Nedir işte Text widgetı alır ve bunu gösterir böyle bakınca epey basit. Bir şeyleri göstermek üzerine kurulu bir senaryoda mükemmel. Ama burada final int count olarak yazdığımız final bunu değiştirmemizi engelliyor ve ben bu count değerini artırmak ve bu değişimi UI üzerinde göstermek istiyorum? İşte bu noktada karşımıza Stateful Widget çıkıyor ama o nedir?



Kod:
class ItemCounter extends StatefulWidget{
    final String name;
    ItemCounter({this.name});
    @override
    _ItemCounterState createState() => _ItemCounterState();
}

class _ItemCounterState extends State<ItemCounter> {
    int count=0;
    @override
    Widget build(BuildContext context){
        return Text('${Widget.name} : $count');
    }
}
}

Üstteki kodları Stateful Widget'a çevirdiğimizde 2 sınıfımız oluşuyor birisi widget, diğeri state object. Widget 2 şeyden sorumlu bu bizim immutable name value'müzden ki oraya ekledik diye değişmeyecek final olarak belirtmişiz ve state object'i oluşturmaktan sorumlu. State object de final olarak belirtmediğimiz count'a sahip ve build metodu ile Text widgetı döndürülmüş.

1*5-aoK8IBmXve5whBQM90GA.png
Şimdi aslında ekranda gözüken şeylere element tree denir ve widgetlar sadece bu elementler için blueprint gibidir şema gibi düşünebilirsiniz. Tıpkı classların yani sınıfların kendi custom widgetlarımızı oluştururken classların blueprint olması gibi. Stateless Widget kullandığınızda Flutter sıkıntı yaşamaz ve bunu gösteririm derdim yok der. Elemente ihtiyacı var sadece widgeta sorup elementi oluşturur musun der böylece Stateless widget stateless elementi oluşturur.

Stateful yapısını kullandığınızda bu sefer Stateful widget stateful element döndürür ve bu stateful element, widget'a dönüp der ki selam bebeğim benim için state object yapabilir misin? İşte bu oluşturulan state object aslında yukarıdaki koddaki createState() metodudur.

ZeIxyQ.png


Şimdi yukarıdaki kodlamada bir Gesture Detector widgetını bu Text widgetının üzerine sarmalayın ve onTap'ine

setState(); koyun. setState() bu şekilde kullanılmaz da içerisine bir anonymous function alır yani

setState( () {} ); şeklinde. {} içerisine count++; şeklinde yazarsanız Flutter'da setState count ile ilgili yapılan değişimden sonra ilgili widget tree'leri günceller ve böylece UI'a yansır. Arkaplandaki şemada setState çalıştığında count 0'dan 1 olur

ZeIyf1.png



ancak yalnızca bu olmaz bir de state object onun elementini damgalar bu damgalamanın anlamı da bir sonraki gelen frame'de rebuild edeceği anlamına gelir. Artık yine build metodu çalıştığında yeni Text widgetı gösterilir ve bir önceki Text widgetı sallar peki ya bu Text widgetına karşılık gelen element aynı mı kalır? olduğu yerde kalıyor çünkü yeni frame ile oluşturulan bu Text widgetı yine Text widget olduğu için. Yani orijinal widget değişse bile element tree yapısı bozulmaz (ama aynı türde olması lazım gidenin yerine gelenle) Hatta didUpdateWidget metodu bile var. Bu metod ile eğer state object'inizin widget'ın ne zaman değiştiğini öğrenmeye ihtiyacı varsa override edebilirsiniz. Ama sürekli stateful widget kullanmak da işleri karmaşık yapacağından Inherited Widget'dan bahsetmemek olmaz.

? GENEL TEKRAR EVRENİNE GEÇİŞ

not: bu evrende geçen her 1 konu mobil uygulama geliştirme serisinin 0,1 konusuna denk geliyor.
image-w1280.jpg


Dur dur... duralım biraz. Çok hızlı yol almadık mı sence de? Çok hızlı gittik sanki. Ben bile anladım bahsederken 1.konudan 14.konuya kadar geldiğimiz yere kadar bir ton şeyden sırasıyla bahsettik ve şimdi hızlanmaya başladık ve buraya kadar geldik. Bence şu an hemen burada durup genel bir tekrar yapmanın vakti geldi. Sence de gelmedi mi? Şöyle serisinden hızlı hızlı bir tekrar atmak bence fena olmaz. Tekrarı atarken de belki bahsetmediğim bazı ufak detaylardan bahsederim belki yine üzerinden geçeriz. Devam ettiğimizde de bu STATE başlığından devam ederiz.

Bu zamana kadar Flutter'ın runApp(); ile başladığını ve bu fonksiyonun core'dan gelen bir şey olduğunu ve flutter tarafından sağlandığını anlattım. Yani dart dilinde built-in olan bir şey değil de flutter framework tarafından sağlanan bir şey. Fonksiyonlardan ve fonksiyonların body kısmından bahsettik yazım şekli şöyleydi

dönüş türü - fonksiyon ismi (parametreler/argümanlar) { .... }

bir fonksiyonu çağırmak istediğimizde runApp(); kullandığımız buydu ve Flutter open source yani açık kaynak kodlu olduğu için runApp fonksiyonunu girip inceleyebiliyoruz ve nereden geldiğini anlayabiliyoruz. Normalde flutter projemizde klasör yapımıza göre pubspec.yaml dosyamızda flutter framework'ün ekli olması gerektiğini ancak bir flutter projesi oluştururken zaten bunun otomatik olarak pubspec.yaml dosyamıza eklendiğini söylemiş olmam lazım. import keyword'ünden bahsettik ki bu da dartta built-in bir mevzu yani bu keywordler önemli ve Dart bunları algılıyor. package eklemek için import '' veya "" kullanmamız gerektiğini söylemiştik ve statementlarımızın sonuna ; eklememiz gerektiğini belirtmiştik.

main fonksiyonu da zaten özel bir fonksiyon çünkü uygulamamızın giriş noktası. Bizim main fonksiyonumuzu çağırmamıza gerek yok. Flutter'a ekranda neyi göstereceğini sıra sıra düşünürsek runApp söylüyor ve bu şekilde UI elementleri gösteriliyor.

Positional Argument

parametrenin argüman demek olduğunu biliyoruz. Flutter user interface widgetlar tarafından oluşturulduğundan eninde sonunda uygulamamızın widget tree yani widget ağacından meydana geleceğini biliyoruz örneğin yukarıdan aşağıya:
MaterialApp
Scaffold
Row
Text, Text, Text

widgetları şeklinde widgetlar bütününe widget tree diyebiliriz ve Flutter bize birçok widget veriyor zaten örneğin butonlar inputlar layout widgetları falan filan. Kendi custom widgetlarımızı yapmayı da biliyoruz ama yine de genel tekrarı öyle toz alırmış gibi yapmayıp oralara da geleceğim. runApp(MaterialApp()); burada MaterialApp widgetı yine core bir widget ve Flutter uygulamamızla ilgili bize bir ton şey anlatan bir setup. MaterialApp'e bir parametre eklememiz gerekli ki ekranda bir şey gösterebilelim. Bir fonksiyon tanımladığımızda fonksiyonun parametresi olarak named parameter dediğimiz çeşidi kullanabiliriz sadece {}ile sarmamız yeterli. Ve böylece fonksiyonu kullanırken parametreleri hangi sıralama ile geçtiğimiz önemsizleşir.

MaterialApp widgetına gidin flutter core'undan bahsediyorum orada {} bunları göreceksiniz çünkü bir sürü named parameter kullanılmış. MaterialApp widgetında home: named parameter var örneğin.

FONKSİYON PARAMETRELERİ, POSITIONAL VE NAMED PARAMETERLAR

ZeItjM.png


Positional: örnek olarak
Kod:
void add(a , b )
dümdüz positional parameter diyebiliriz bunlara. Bunları vermek zorunlu bir halde şu an.
void add({a,b}) bunlarsa yukarıda bahsettiğim gibi named parameter verirken a: blabla, b: blabla şeklinde sıralaması da önemli değil ayrıca bunlar default olarak opsiyoneldir vermek zorunlu da değil vermeden de kullanabiliriz fonksiyonu.
ama positional argumentslar da opsiyonel yapılabilir mesela
Kod:
void add(a, [b])
şeklinde burada b parametresi artık opsiyonel. Ve bir parametre opsiyonel ise ona default değer de atayabiliyorsun.
Kod:
void add(a, [b=5])
b opsiyonel bir parametre default değeri de 5 yani bir değer atanmazsa 5

default değerler named parametrelere de atılabilir
Kod:
void add({a  ,b = 5 } )
şeklinde yine. örneğin a ya bir değer atanmazsa burada fonksiyon kullanılırken a null gelecektir. o da ayrı bir type ondan sonra bahsederiz. Gerçi bahsettik zaten genel tekrar içindeyiz şu an farklı bir zamanda gibi düşünün tenet interstellar güzel filmler bunlar burada durun izleyip gelin belki bir aydınlanma yaşayabilirsiniz.

named parametreleri de yine dartta built-in required keywordü ile opsiyonel olmaktan çıkartıp zorunlu hale getirtebiliyorsunuz ki genelde bu daha fazla kullanılır void add({required a, required b}) artık a ve b opsiyonel değil.

CONST VALUELARI ANLAMAK

Vscode da hep gördüğümüz optimizasyon ve geliştirme potansiyeline sahip olan kodlarda const kullan uyarısını almayan yoktur. Const dart tarafından bize sağlanan bir keyword ve uygulamamızın runtime performansını artırmayı sağlıyor. Örneğin bir Text widget cihazın hafızasında tutulurken const kullanılmışsa bu text widgetı ikinci defa kullanılacağı zaman hafızada ikinci bir nesne yaratılması yerine tekrar kullanılıyor ve böylece memory efficient dediğimiz hafızayı daha iyi kullanmış oluyorsunuz.

DAHA KOMPLEX WİDGETLAR KULLANMAK VE TYPE'LARI ANLAMAK


MaterialApp widgetının bizim root widgetımız olduğunu ve uygulama ile ilgili setup ayarlarını buradan yönettiğimizi söyledik. Scaffold widget ise şöyle genel olarak uygulamamız için bir iskelet gibi iyi görünmesini sağlayan bir widget. Dart type-safe bir dil olduğu için çalışacağımız her şey belli türlere ait oluyor.

ZeI4aK.png


String örneğin, int, num, hatta MaterialApp'in türü MaterialApp ve en nihayetinde bu bir Widget türünde ve bahsettiğim her şey en sonunda bir Object'tir. Yani değerler birden fazla type olabilir örneğin bahsettiğim int çok daha spesifik bir type. Objectler Dart dili için core bir konsept objectleri hafızdaki data yapıları gibi düşünebiliriz. Dart dilinin desteklediği bazı türlere bakalım

ZeIOJ3.png


Mesela Container widgetı const'u desteklemeyen bir widget bu nedenle onun widget tree'sinde const kullanamazsınız IDE bunu söyler tabi ve Container widgetını incelediğinizde Decoration? decoration görürsünüz Decoration da bir type tır ve şu şekildedir:
Kod:
{Decoration? decoration} Type: Decoration?

Örneğin orada BoxDecoration kullanabilirsiniz çünkü BoxDecoration da zaten Decoration sınıfından türemiştir.

Generic Typelardan da bahsetmeden geçmeyelim bunu da List lerden örnek verilip bahsedilir sadece kavramın üzerine bir iki şey söyleyeceğim yine geleceğim buna ama örneğin List ler de Dartta bir type ve epey de esnek. Yani 2,3,4 koyabilirsiniz 'a','b','c' koyabilirsiniz <> List<> olarak <> arasına koyabilirsiniz ve bu şekilde kullanılabilir haldeyse Generic Type lara şimdilik flexible typelar diyelim.

Genel tekrara devam genel tekrarı yaparken birkaç uygulama örneği ardından Riverpod'tan bahsedip genel tekrar evrenini bitirdikten sonra Inherited Widget ile Bloc pattern ve sonrasında örnek uygulamalara geçebiliriz. Genel tekrarın henüz tahminimce 10-15 bölüm olur 3.kısmına falan gelmişizdir tam kestiremedim. Bu uzun soluklu bir seri olduğu için devamm.

Okuduğunuz için teşekkürler <3 Gauloran​
eline sağlık
 
Üst

Turkhackteam.org internet sitesi 5651 sayılı kanun’un 2. maddesinin 1. fıkrasının m) bendi ile aynı kanunun 5. maddesi kapsamında "Yer Sağlayıcı" konumundadır. İçerikler ön onay olmaksızın tamamen kullanıcılar tarafından oluşturulmaktadır. Turkhackteam.org; Yer sağlayıcı olarak, kullanıcılar tarafından oluşturulan içeriği ya da hukuka aykırı paylaşımı kontrol etmekle ya da araştırmakla yükümlü değildir. Türkhackteam saldırı timleri Türk sitelerine hiçbir zararlı faaliyette bulunmaz. Türkhackteam üyelerinin yaptığı bireysel hack faaliyetlerinden Türkhackteam sorumlu değildir. Sitelerinize Türkhackteam ismi kullanılarak hack faaliyetinde bulunulursa, site-sunucu erişim loglarından bu faaliyeti gerçekleştiren ip adresini tespit edip diğer kanıtlarla birlikte savcılığa suç duyurusunda bulununuz.