Daha önceki bir yazımda Flutter dan bahsetmiştim. Son zamanlarda detaylı inceleme ve birkaç uygulama yapma şansım oldu. Oldukça beğendiğimi ve sıkıntı yaşamadığımı ama öğrenim sürecinin eski yöntemler ile native mobil uygulama geliştirenler için çokda kolay olmadığını belirtmek isterim. Genel olarak tüm dünyada Flutter a karşı güven artıyor. Daha önce bu tarz bir güveni ben React Native e karşı hissetmemiştim. Plugin bağımlılığı ve yaşanan sıkıntılar bizi soğutmuştu ve tamamen ios için XCode da Swift dilince ve Android için Android Stuidio da Java veya Kotlin dillerinde yazıyorduk. Uzun zamandır bu şekilde devam ediyor ancak sıkıntımız işin bu şekilde çok zor olmasıydı. Her projede Android ve Ios u baştan yazmak hem kaynak dolayısı ile maliyet hem de uygulamaların farklı ellerden çıkmasında dolayı bazı farklılıklar oluşmasına sebep oluyordu. Şöyle örnek vereyim Android hızlı gidiyorsa Ios onu bekliyor yada özellik olarak biri diğerini geçebiliyordu.

Son zamanlarda tasarım aracı olarak Figma kullanıyoruz. Şimdi size eskiden veri devam eden tasarımdan canlıya alıma kadar süren bu yöntemi kısaca göstereyim.

Süreci görüyorsunuz. XCode ve Android Studio aşamasında mobil uygulama yazılımına başlandığında uygulamayı yazanlar yan yana dahi otursa sonuçların ne kadar farklı olduğuna defalarca şahit oldum. Ayrıca her mobil uygulama yazılımcısının eski yaptığı işlerden bir kütüphanesi, işi hızlandırmak için bazı ekran tasarımları, kod yapıları olsada her işte sıfırdan ekranlar uygulamada oluşturuluyor ve uygulama mantığı baştan ele alınıyor.

Flutter’da tek bir ortamda Dart dilinde yazıyorsunuz ve çıktı aynı olmakla kalmıyor üstelik Native e derlediği için performans olarakda bu eski yönteme göre bir eksisi olmuyor.

Şimdi gelin yeni yönteme ve sürecin nasıl işlediğine bakalım.

Görüyorsunuz bu sefer iş direk aslında maliyet olarak yarıya düşmüş gibi görünüyor.

Benim son zamanda gözlemlediğim aslında böyle değil. Bence yarıdan daha fazla kazanç söz konusu.

Flutter da UI hazırlamak bence mesela XCode StoryBoard da yada Android Studio da layout hazırlamaktan daha kolay. Layout larda değişiklik yapmak ve layout ları kod ile birleştirmekdee Flutter da daha kolay. Dolayısı ile şöyle bir hesap yapabiliriz.

Diyelim bir mobil uygulama yazmanız gerekiyor ve hesap yapmaya başladınız. Kapsamlı bir iş diyelim. 1 ayda yani 20 iş gününde anca ekranları hazırlıyorsunuz. 2 ay yani 40 iş günüde yazılım sürecek. Bu Android ve Ios için genelde aynı çıkar.

Sonuçta

Android toplam 60 iş günü
Ios toplam 60 iş günü.

Genel Maliyet buradan hesaplanır ve 120 birim maliyet çıkar.

Flutter da ise bir baktınız aslında ekranlara 20 değil 15 günde hazırlanabilecek gibi ve kod açısından da 40 iş günü değil 35 iş gününde halledebiliyorsunuz. Bunun daha az zaman aldığını Flutter da biraz ilerledikten sonra göreceksiniz. Belki bundan bile daha az zaman alacak ama ben şimdilik bu şekilde yazdım.

Sonuçta Flutter da

Android+Ios toplam 50 günde işi bitirebiliyoruz.

120 günden 50 güne düşürmek hem maliyet hem zaman açısından uygulama geliştirenlere ve girişim amaçlı fikrini hayata geçirmek isteyenlere kolaylık sağlayacak diye düşünüyorum.

Ben standart iş yapan birçok projede bunu artık tavsiye ediyorum. Ancak bazı projeler vardır ki o projeler direk Swift yada Kotlin/Java değil dahada native C de yazmanız gerekir. C. de yazılan kodu derler Swift veya Java dan çağırırsınız. Bu tip çok ileri seviye bazı projelerde Flutter tavsiye etmeyebilirim. Ama uygulamaların %99 u zaten bu tarz uygulamalar değil. Düşünsenize Google ın tüm mobil uygulamaları çok uzun zamandır Flutter da geliştiriliyor. Arayüz ve performans olarak ne kadar iyi sonuçları var hepimiz kullanıyoruz günlük hayatta bu uygulamaları. Örneğin tüm dünyada 50 milyon kullanıcısı olan Alibaba tüm uygulamalarını Flutter’a geçirdi ise bizler, bu dünya devleri bunu tercih ediyorsa, neden bir şans verip Flutter kullanmayalım. Ben denemeler yapmadan yada gerçek uygulamalar geliştirmden böyle önerilerde bulunmam. O yüzden tüm çalışmalarımı yaptıktan sonra sizlere bunları yazmak istedim.

Herkese merhaba,

Bu konu çok sorulduğu için değinmek istedim. Çünkü web uygulamasının artıları olduğu gibi eksileri de var aslında. Bunları bir uygulama yaparken düşünmek lazım.

Önce artılarından bahsedilim ya da neden web tarafına ihtiyacımız var. Yapacağınız uygulamaya göre tabi değişir ama uygulamanın bir tanıtım sayfası, hakkında, gizlilik ilkeleri ve kullanıcı sözleşmesi gibi sayfaların bulunduğu bir web sitesine ihtiyaç duyacağız zaman zaman. Sebebi de bu bilgilerin artık google ve apple tarafından isteniyor olması. Uygulamaların gizlilik ve sözleşme sayfaları yok ise olumlu karşılanmıyor ve mobil reklamlar kısıtlanabiliyor ya da kaldırılabiliyor uygulamanızdan. Apple ve Google bunları kullanıcılarını korumak ve app hakkında ne haklara sahip bilmek için istiyor.

Tanıtım sitesi yapmak dışında mobil uygulamanızın tüm özelliklerini içeren bir web uygulaması yapıp yapmama konusunda kararsız kalıyorsanız şunları düşünerek karar verebilirsiniz.

Mobil uygulamada reklamdan gelir elde etmek istiyorsanız web tarafının olması bu gelirinizi bir miktar düşürebilir. Web sitesine gelen kullanıcıları mobil uygulamayı indirmeye yöneltmek daha iyi bir çözüm olabilir. Ancak büyük çaplı ve ya global bir uygulama yapıyorsanız bu durumda her platformda hizmet sunmak için web uygulaması da düşünebilirsiniz. Çünkü burada amaç reklamdan daha çok kullanıcılara en iyi hizmeti her kanaldan vermek olacaktır.

Web sitesini yapmayı benim tavsiyem sona bırakın. Eğer yapacaksanız işleri fazlandırın. Backend oturduktan ve uygulamalarınız hayata geçtikten sonra da web sitesi yapıp yapmamaya her zaman karar verebilirsiniz.

Bazı durumlarda ise web den başlamak ve android/ios u sona bırakmak tercih sebebi olabiliyor. Bu genelde eldeki imkanlar ile de alakalı tabiki. Önce bir yapı otursun belli şeyleri tecrübe edelim, şu anda elimizde web yazılımcısı mevcut buradan başlayalım gibi konulardan dolayı web öne çıkarak mobil uygulamalar sona bırakılabiliyor.

Ben hangisi önce ya da hangisi sonra buna şu iyidir demek istemiyorum. Bu konuda kesin bir karar yok ancak mobil uygulamalardan başlamak da bazen daha maliyetli olabiliyor. En iyisi yapacağınız işin hedef kitlesine göre hareket etmek tabiki. Kullanıcılar en çok hangi kanaldan gelecek bunu düşünerek bir karar vermek en doğrusu.

Umuyorum bir miktar faydalı olmuştur yazdıklarım. Sorularınız var ise bu konu ile alakalı bu sayfanın altındaki yorum kısmına yazabilirsiniz. Her soruyu en kısa sürede cevaplamaya çalışıyorum.

Merhaba,

Hybrid vs Native arasındaki farkları anlatmıştım. Artık hybrid deki kötü performansı kimse istemiyor bunda hemfikir olduğumuzu sanıyorum. Bu yazımı okumayanlar buradan okuyabilir.
https://ferhatbalaban.com/hybrid-vs-native/

Bu yazımda native mobil uygulama yaparken nasıl daha hızlı yaparız konusuna değineceğim.

Biliyorsunuz native app , yada bilmeyenler için kısaca anlatayım 🙂 , android uygulaması android studio da Java yada Kotlin dilleri ile yazılırken, Ios uygulaması ise Xcode da Swift yada Objective-C ile yazılıyor. Son zamanlarda daha çok swift tercih ediliyor.

Tamam bunda bir sorun yok ama bir uygulamayı yazmak için 1 backend, 1 android 1 ios yazılımcısı gerekiyor ve maliyetler artıyor. Teknoloji artık çok hızlı ilerliyor ve her firmanın, her girişimin bir mobil uygulaması olmaya başladı. Bu nedenden herkes bir arayış içinde.

Native performansı olsun, ancak nasıl daha hızlı hem ios hem android için kod geliştirebilirim?

Herkes bu arayış içinde ve maliyetleri azaltırken aynı zamanda daha hızlı uygulamalar çıkarmak peşinde. Bunun içinde karşımıza ortak bir dilde tek yerde kod yazabileceğiniz ama sonuçta kodu android için ayrı ios için ayrı bir native koda dönüştüren 2 platformdan bahsedeceğim. React Native ve Flutter.

React Native, Facebook tarafından başlatılmış bir proje ve 2015 yılında açık kaynak olarak açılarak herkesin kullanımına sunuldu. O günden bu yana birçok kullanıcı kitlesine ulaştı.

Flutter ise 2017 yılında Google tarafından duyruldu ve kullanımı giderek artıyor.

Şimdi bu 2 mobil uygulama platformunun geleceğinden, farklarından ve biz eğer bir ortak dilde yazıp bu işi yapmak istiyorsak hangisini seçmeliyiz bundan bahsedeceğim.

Öncelikle benim görüşüm şu oldu bugüne kadar. Bu tip ortak dilde yazılan ve sonuçta android ve ios uygulama üreten sistemlere ben biraz uzak durdum ve uzaktan izledim. Mesela react native de yazılmış uygulamalar geldi karşıma ve insanların bazı sorunları kolay çözemediğini ve tıkandığını gördüm. Yeri geldiğinde framework yetersiz kalınca gerçek native ile kod yazma ihtiyaçları ortaya çıktığına şahit oldum. Native de bize basit gelen hataların framework ün kendisinin ayrı bir yapısı olduğundan ve iyi bilinmeyince çözülemediğini gördüm. Ancak dert o kadar büyük ki bu arayış devam ediyor ve bunu gören google da kendisi android i desteklemesine rağmen Flutter ı çıkartarak bu derde bir çözüm sunduğunu göstermiş oldu. Çünkü ios içinde google ın hazırladığı birçok mobil uygulama var ve bu dertden tüm dünya gibi onlarda çekiyor.

Programlama dili olarak React Native, javascript dilini kullanırken (tabi kendine ait bir yapısı ve kuralları var yine frameworkün), Flutter ise Dart programlama dilini kullanıyor. Dart yine Google ın 2011 de geliştirdiği bir dil ve kullanımı çok yaygın değil ama javascript oldukça yaygın. Bu açıdan React Native , Flutter a göre biraz daha avantajlı görünüyor. Buradan React Native e +1 veriyorum.
Sonuç: React 1 – Flutter 0

Teknik altyapı olarak React Native js altyapısına dayandığından ve native e çevirirken biraz köprü vazifesi gören bir sistem üstünden çevirim yapıyor ve kötü performans verebiliyor ancak Flutter kendi içinde hemen hemen tüm native kütüphaneleri barındırdığından native sistem ile haberleşmek için ayrı birşeye ihtiyaç duymuyor. Bu konuda Flutter +1
Sonuç: React 1 – Flutter 1

Kurulum konusunda React Native NPM(Node Package Manager) ile daha rahat kurulurken Flutter bu konuda biraz manuel kurulum aşamasında kalmış. En kısa zamanda iyileştireceklerini düşünsemde React Native bu konuda +1
Sonuç: React 2 Flutter 1

Proje Hazırlığı konusunda Flutter hem android hem ios için daha açıklayıcı bilgilere sahip. Mesela React da IOS dökümantasyonu biraz zayıf. Ayrıca Flutter da yer alan flutter doctor her kontrolü yaparak hazır olup olmadığınızı denetliyor. Bu konuda Flutter +1
Sonuç: React 2 – Flutter 2

UI (Arayüz) ve Development API konusunda ise native bileşenlere sorunsuz ulaşmak çok önemli. React native UI bileşenleri ve bazı native erişim API ı sunsada birçok konuda 3rd party yani dışarıdan eklenen plugin lere ihtiyaç duyuyorsunuz. Herkes kendi en iyi plugin ini yapmaya çalışıyor ya da bulmaya çalışıyor. Başkalarının geliştirdiği bu plugin ler hatalı kalabildiği gibi bir süre sonra destek kesilebiliyor ve projeniz de siz bu plugin i geliştirmediğiniz için zor durumda kalıyor. Flutter da ise kendi içinde ihtiyaç duyacağınız hemen hemen herşey var. Bence bu aslında +3 ve bir yazılımcı için en önemli şey. Hatta benim react native e uzak durmamdaki sebeplerden biri bu. Hadi yinede adil olsun diye bu maddeye de Flutter +1 diyelim.
Sonuç: React 2 – Flutter 3

Geliştirme Hızı konusunda yazılımcı js biliyorsa React Native(RN) de hızlı kod geliştirebiliyor. Js bile çok yazılımcı var ama RN için bence js den daha çok kendi kuralları olduğu için RN bilen kişi aranıyor. Js bilmesi avantaj tabi ama kurallar çok iyi öğrenilmesi lazım. Flutter da ise Dart dilinin öğrenilmesi lazım. Çok zor değil ancak çok yaygın değil. Flutter yaygınlaştıkça bu açığı kapatacak görünüyor ancak şu an için RN +1
Sonuç: React 3 – Flutter 3

Destek konusunda React Native daha önce çıktığı ve daha çok kullanıldığı için daha büyük bir kitle tarafından destekleniyor. Bu konuda yine Flutter geriden gelse de açığı kapatması bekleniyor.
RN +1
Sonuç: React 4 – Flutter 3

Test konusunda React Native de birkaç 3rd party çözüm var ancak Flutter bu konuda kendi içinde çok güzel çözümlere sahip. Cihaza aktarmadan uygulamanızı test tool ları üzerinden deneyip test edebiliyorsunuz.
Flutter +1
Sonuç: React 4 – Flutter 4

Yayına alma konusunda React Native de otomatik çözümler yok ancak Flutter CLI ile build (derleme) ve release (yayına alma) işlemleri yapabildiğiniz gibi Fastlane ile otomatik build ayarları yapabiliyorsunuz. Bunun nasıl yapılacağı güzel anlatılmış. React da da fastlane kullanılabilir ama dökümantasyon konusunda zayıf gibi geldi bana. Sonuç olarak bu konuda Flutter +1
Sonuç: React 4 – Flutter 5

Bakım ve Sürekli Geliştirme konusunda React Native de yine detaylı birşey bulamadık ancak Flutter da bu konuda gerekli bilgiler mevcut ve CLI ile yapılabiliyor. Bu sayede hataları giderip kullanıcılar teste açma , geri bildirim alıp tekrar teste gönderme süreçleri daha hızlı ilerliyor.
Flutter +1
Sonuç: React 4 – Flutter 6

Sonuç olarak iki sisteminde kendi artıları eksiler var. Flutter daha avantajlı görünüyor. Bu konuda ona bir şans vermeyi düşünüyorum. Bazı mobil uygulamaları Flutter ile yapıp denemek lazım. Ancak bu tip framework ler sonuçta Google da geliştirse Facebook da geliştirse bir şekilde bir yerlerde tıkanmanıza yol açabiliyor. İçeride React ya da Flutter bilen yazılımcılar olması gerekiyor. Bu konuya eğildiğinizde ve tüm yazılım dilinizi değiştirmeye başladığınızda sonradan sorun yaşarsanız kötü olabiliyor.

Basit ve sıfırdan yapılacak uygulamalarda bu yöntemlere şans verilirken. Kritik uygulamalar bence hala gerçek ait olduğu yerde yazılmalı. Sonuç olarak hiçbir ara framework gerçek native de yazmak gibi olmayacaktır. Orada ne isterseniz yapacağınız kesinken bu ara tek dilde yazalım framework leri hep bir firmaya birilerine ihtiyaç duyacağınız anlamına geliyor. Örneğin facebook kapanır yada React Native i bırakırsa ne olacak? Çok kritik bir app yapıyorsanız sizde mi bırakacaksınız ya da komple sıfırdan mı yazacaksınız. Ya da Google, Flutter a gerektiği önemi vermez ise?

Ancak şu da var. Şans da vermek lazım. Flutter’ın geleceği parlak gözüküyor. Mesela Alibaba flutter a geçmiş ve çok memnunlar bu video yu izleyebilirsiniz.

Karar vermek zor ancak dediğim gibi basit kurgusu olan bazı app ler Flutter ile yapılabilir. Benim düşüncem bu yönde. Neden bilmem ben React Native e zaten ısınamamıştım sorunlarından dolayı. Şimdi daha heyecanlandım Flutter ile.

Herkese merhaba,

Bugün önemli bir konuya değineceğim. Mobil uygulamaların görünmeyen ama en önemli kısmı. Backend.

Backend ne demek ne işe yarar kısaca önce bundan bahsedelim. Daha önceki yazılarımda yönetilebilir mobil uygulamalar ve yönetim paneli nasıl olmalı onlardan bahsetmiştim. Bu yazıyı da okumanızda fayda var. Bkz:
https://ferhatbalaban.com/yonetilebilir-mobil-uygulamalar/

Backend, yönetim paneli ile karıştırılmamalı. Yönetilebilir uygulamaların mutlaka bir backend i vardır. Neden mi? Yönetilebilir olması demek aynı zamanda client app lerin yani ios ve android in ayarları çektiği işlemleri yaptığı bir backend api si vardır. Bu api genelde json formatında çıktılar verir client mobil uygulamalara.

Basit anlamda bir mobil uygulama backend şunlardan oluşur.

1 – Veritabanı

2 – Backend Api

Örneğin en basit anlamda backend api de bulunan bir settings servisi veritabanında bulunan settings tablosundan gerekli verileri çekerek json a dönüştürür ve clientlara iletir.

Örnek json çıktısı:

{
“success”: true,
“error_code”: 0,
“error_message”: “”,
“data”: [
{
“key”: “default_banner_mode”,
“value”: “2”
},
{
“key”: “admob_app_id_ios”,
“value”: “ca-app-pub-34534345345345~4361065035”
},
{
“key”: “admob_banner_id_ios”,
“value”: “ca-app-pub-43353453453/7181055093”
}
]
}

Bu çıktıda ios a gerekli bazı ayarlar gönderilmiştir. Backend istek yapan client a bakarak ve istek yapan user a göre gerekli dönüşleri yapabilir. İşte tüm bu kurgu yani nasıl çıktı vereceği veritabanındaki değerleri nasıl döneceği yada veritabanına nasıl insert/update/delete yapacağına backend api karar verir.

Peki bu backend api nasıl hazırlanıyor?

Öncelikle backend api yi oluşturacağınız yazılım dilini seçiyorsunuz. Bu dotnet, php olabilir. Hangi platformu seçerseniz onunda içinde kullanacağınız mvc framework lerden birini seçmeniz gerekiyor.

Dotnet için:
.net mvc framework
.net mvc core framework

Php için:
Laravel
Symphony
Codeignitor
…

Tüm bu seçimleri nasıl yapmalısınız ne seçmelisiniz buna bu yazıda girmeyeceğim ancak müşteriniz yada yazılımcılarınız hangi platformu tercih ediyorsa onu seçiyorsunuz genelde. Ancak seçim şansınız varsa ne seçmelisiniz? Buna başka bir yazıda değineceğim çünkü çok uzun olacak o yazıda. Sebebi de bu konu en çok tartışma konusu ve özellikle microsoft ile çalışanların .net kullananların php tercih etmemesi yada linux ile çalışanların .net e çok uzak olması sebebi ile 2 platform arasında şu daha iyidir gibi tartışmalar çok oluyor.

Bu güne kadar hem müşterilerin tercihi sebebi ile hem de bilgi edinmek amacı ile 2 tarafta da oldukça tecrübem oldu. Ağırlıklı olarak php-mysql tercih etsekte .net ve .net core kullandım ve karşılaştırma şansım oldu. Ancak son zamanlarda eğer tercih bize bırakılırsa Php-Laravel tercih ediyoruz. Bunu da başka bir yazıda anlatacağım.

Php kullananlar da genelde php ile tam uyumlu mysql veritabanını kullanmayı seçiyor. Laravel framework ile de backend api yi oluşturarak sağlam bir backend api yi kolayca yapabiliyorlar.

Birçok yerde Laravel nedir nasıl çalışır bilgi alabilirsiniz ancak ben gözlemlediğim en büyük faydaları yazacağım burada.

1 – Güvenlik: Php framework lerde birçok yapı hazır gelir. Bunlar içinde en önemliside bence kullanıcıların authentication yani yetkilendirme işlemleridir. Hangi kullanıcı ne yapabilecek hangi api functionlarını çağırabilecek gibi tüm bunları Laravel altyapısı ile sağlam şekilde kurgulamak çok kolay ve etkili sonuçlar verir.

2 – Migration: Veritabanınızı migration lar ile yönetmek oldukça pratiktir. Özellikle test ortamınız var diyelim burada bir tablo yada kolon oluşturdunuz aynısını prod a da yapmanız lazım hazır olduğunuzda. Ne yapmıştım diye hep test db sini incelemek zorunda kalırsınız. Migration lar ile tüm bunların kaydını tutabilir ve kolayca tek bir komutla bunu prod ortamına aktarabilirsiniz.

3 – MVC: Kullanılan her framework günümüzde bir mvc yapısından oluşur. Yani Model-View-Controller. Modeller veritabanındaki tabloları simgelerken, Controller arayüzünüzle veritabanı arasında tüm kurgularınızın yer aldığı işi yapan kısımdır. View ler ise arayüz yani ekranda görünen kısımdır. Laravel de buna ek olarak bu model, view ve controller ları komutlar ile kolay şekilde oluşturabilir ve hızlı şekilde kod geliştirebilirsiniz.

4 – Performans: Cache yapısı Laravel de iyi kurgulanmış ve kullanması çok kolay. Sürekli veri çekmeniz gerekmeyen tablolarınız illaki olacaktır. Bunları cache yani önbellek ile saatlik , günlük cache ler ile kullanabilir ve performansınızı kolay şekilde yönetebilirsiniz.

5 – Model – Tablo İlişkisi: Modellerimiz ile sql yazmadan php kodları ile select/insert/update/delete işlemlerini kolay şekilde yapabiliriz.

6 – Hazır kütüphaneler: Laravel birçok hazır kütüphane içeriyor ve bunları kolay şekilde projeye import edebiliyorsunuz.

Bunların dışında hiçbir framework siz iyi kurgulamazsanız backend api tam olarak iyi olmaz. Birazda bunlardan bahsedelim.

1 – Loglama: Her işlemi loglamanızda fayda vardır. Bunun için bir log request tablosu yaratabilir ve client ların yaptığı her request i ve dönüşlerinizi loglayabilirsiniz. Laravel burada yine imdadımıza yetişiyor. Middleware dediğimiz katmanda tek bir class ile bu işlemleri yapabiliyorsunuz. Hatta 500 hataları oluştuğunda yada client lara verdiğiniz response ların süreleri belli değerleri aştığında alert ler üretip ilgili kişilere mail ve sms atabilirsiniz burada. Bu sayede bir problem olduğunda anında haberiniz olur.

2 – Kritik kontroller: Backend i yazarken örneğin kritik işlemler var ise bunları çok iyi kontrol etmek ve açık kapılar bırakmamak gerekir. Örneğin bir satınalma işleminiz var ise Apple store yada Google play üzerinden bu satınalma genelde client dan yapılır ancak alınan receipt yani fatura çıktısı diyelim buna bu backend e iletilmeli ve backend tarafında yine google ve apple a sorgulama yapılarakçift kontrol yapılmalıdır. Çünkü backend api nizin yapısını çözen biri mutlaka satınalma yapmış gibi backend inize istek yapabilir. Bundan dolayı bu gibi yerlerde yani kritik yerlerde mutlaka çok fazla detaylı düşünmeli her aşamada kontroller koymalı ve bazende bir hacker gibi düşünmeniz gerekmektedir.

Daha anlatacak tabi çok şey var ama çok da uzun yazmak istemiyorum. Sadece genel bilgi vermek istedim. Başka yazılarda backend ile ilgili farklı detaylara girmeye devam edeceğim. Şimdilik hoşçakalın.

Merhaba,

Mobil uygulama geliştirmek isteyenler yada mobil uygulama yaptırmak isteyenler için mobil uygulama geliştirme nasıl oluyor ve aşamaları neler bunları aktarmak istiyorum. Çünkü sürekli sorulan bu sorulara basit ve anlaşılır cevaplar vermek çok önemli.

1 – Mobil Uygulama Geliştirmelerini Kimler Yapar?

Mobil Uygulama bir yazılım firması yada bu işi bilen mobil uygulama yazılımcısı tarafından yapılabilir. Burada kimin yaptığından daha çok nasıl destek alacağınız ve nasıl çalışacağını önemlidir. Genelde freelance mobil yazılımcı olarak çalışanlar ek bir iş olarak bu işi yapabilmektedir ve buda bazı sıkıntıları beraberinde getirir. Freelance sürekli bu iş ile uğraşıyorsa yani bir yerde çalışıp ek zamanında yapmıyorsa sürekli bu işle uğraşıyorsa sorun olmayabilir ancak bu durumda da yaptığı işi yasal yapıyormu , en azından şahıs firması varmı ve referansları sağlam mı sorgulamak gerekir. Eğer bir yerde çalışıyor ve bu işi yapıyorsa o zaman işiniz yapılsa bile devamında destek konusunda sıkıntılar yaşayabilirsiniz. Bir mobil uygulama yapıldıktan sonrada sıkıntı yaşadığınızda bu işi başkasına aktarmak o kadar kolay bir iş değildir. Bu yüzden en iyi çözüm seçtiğiniz firma yada kişi ile devam etmektedir. Ancak bu konuda aktarım yapmak durumunda kalırsanız da bir başka yazımızda anlatacağımız bu yazının konusu olmayan yazımı okumanızı tavsiye ederim. Linki burada daha sonra paylaşacağım.

İş yaptığınız firma yada şahıstan mutlaka bu bilgileri isteyin.

• Firma yada şahıs referanslarında bulunduğu web sitesi
• Ne kadar zamandır bu işi yapıyor
• Hangi yöntemi kullanıyor? (Madde 2 de anlattığım 3 yöntemden biri?)
• Sonrasında nasıl destek veriyor?
• Destek vermez ise ne olacak? Bu durumda desteği garanti altına almak için sözleşme yapmanızı şiddetle tavsiye ederim.
• Tasarım konusunda çözüm sunabiliyor mu? Bunu sizde başka birileri ile çalışarak halledebilirsiniz ancak tek bir yerden tüm hizmetleri almanız daha iyi olacaktır. Bu yüzden bunu mutlaka sorun. Eğer bu konuda hizmet vermiyorsa başka bir çözüm bulmanız gerekecektir.
• Proje bazlı anlaştınız devamında ek istekleriniz çıktı bu durumda ek istekler için nasıl bir fiyatlama yapıyor. Örneğin adam/gün ücreti nedir. Bir işin kaç gün süreceğini neye göre belirliyor.

2 – Mobil Uygulama Geliştirmesi Nasıl Yapılır?

Mobil uygulama 3 farklı şekilde hazırlanabilir. Günümüzde en çok tercih edilen bu 3 yöntemi ve avantaj dezavantajlarını da başka bir yazımda paylaşacağım bu yazıyı çok uzun tutmamak adına şimdilik bu 3 yöntemden bahsedelim.

2-a – Native Mobil Uygulama Geliştirme:

Native dediğimiz uygulama geliştirme yöntemi aslında Google ve Apple ın önerdiği her platforma yani android e uygun Android Studio da Java yada Kotlin dilleri ile veya Ios için Xcode Uygulamasında Swift yada Objective-C dilinde yapılan geliştirmelerdir. Günümüzde Android için Java , Ios için Swift dilleri daha çok tercih edilmektedir. Kotlin yaklaşık 1 sene oldu aşağı yukarı çıkalı ancak şahsi görüşüm ben ısınamadım bana garip geldi. Java yada Swift i tercih ederim. Eğer projenize sıfırdan başlanacak ise ve ileride yazılımcı bulma konusunda sıkıntı yaşamak istemiyorsanız en çok tercih edilen bu dilleri kullanan mobil yazılımcıları yada firmaları tercih etmenizi öneririm.

Bu aşamadan sonra diğer anlatılan yöntemlere Cross Platform Mobil Uygulama Geliştirme Yöntemleri denir. Cross platform özetle bir ortamda geliştirme yapıp 2 platform içinde uygulama üretebilmektir. Android için ayrı Ios için ayrı kod yazılmaz. Bu maliyet ve zaman konusunda tasarruf etmenizi sağlar. Ancak madem bu kadar iyi neden öyle yapmıyor herkes dediğinizi duyar gibiyim 🙂 Elbette dezavantajları da var. Bunları da yine anlatacağım.

2-b React Native ile Mobil Uygulama Geliştirme:

Facebook tarafından desteklenen bir cross platform. Facebook uygulamasında mesela bu kullanılıyor.

Ancak detaya girmeden daha fazla ingilizce bilenler yada çeviri yaparak bu yazıyı okuyabilirsiniz.

https://medium.com/mop-developers/mobile-app-development-react-native-vs-native-ios-android-49c5c168045b

Özetle şunu söylüyor , facebook uygulamasında da kullanılan bu sistem facebook tarafından bir gün desteklenmez ise ne olacak. Yada facebook react native de çıkan hataları facebook app ini çok etkilemiyorsa 2. öncelik vererek sonraya bırakabiliyor. Yada google ve apple ın yeni çıkardığı bir özellik react native de sonradan yapılabiliyor.

Avantajı ise aynı anda 2 platform içinde mobil uygulama geliştirme yapabilmesi. Bu yüzden çok tercih ediliyor. Yoksa kimse native varken riske girmek istemez yada facebook böyle bir işe soyunmaz.

2-c Cordova ile Mobil Uygulama Geliştirme

Cordova aslında cihaz içindeki browser da çalışan html tabanlı bir uygulama sunuyor. Basit işler için tercih edilebilir ancak native bir uygulama hissiyatı veremiyor. Bu yüzden bence en son tercih edilecek seçenek bu. Bu konuda daha önceki yazılarımu şu linkden bakarak okuyabilirsiniz https://ferhatbalaban.com/tag/cordova/

2-d Soru; Özet;

React native kullanmaya değer mi?  Cevap: Değişir ancak çoğu sorunun cevabı gördüğünüz üzere Native dir.

Sadece ios yada sadece android uygulama mı yaptıracaksınız ? Native
Küçük bir ekibiniz yada kısıtlı zamanınız ve bütçeniz mi var?  React Native.
Çok kapsamlı bir uygulama mı yaptıracaksınız ? Native.
Yaptırdığınız mobil uygulama çok uzun süreler hayatta kalacak mı, Facebook a ya birşey olursa korkunuzu atamıyormusunuz? Native.
Çıkar çıkmaz yeni cihaz özelliklerini desteklemeye ihtiyacınız var mı ? Native.

Genel Özet;

Tüm bu kriterleri değerlendirerek mobil yazılım geliştirme yapacak yada yaptıracak iseniz çalışacağını kişiyi ve çalıştığı platformu iyi değerlendirin. İşiniz için büyük emekler verip paralar harcıyorsanız iyi düşünmek ve iyi bir karar vermek çok önemli diye düşünüyorum. Sorularınız olursa ana sayfadaki iletişim bölümünden benimle irtibata geçebilirsiniz.

 

Saygılar, sevgiler.

Merhaba,

Bu yazımda olmazsa olmaz bir konudan bahsedeceğim. Yönetim paneli nedir ? Nasıl olmalıdır? Neler içermelidir?

Önce nedir bundan başlayalım. Yönetim paneli genelde atlanan bir konu oluyor bu yüzden bu konuya değinmek istedim. Bir mobil uygulama yada web sitesi yani online olarak çalışan bir uygulama yapmak istediniz diyelim. Bu uygulama yaptığı işe göre değişir ama her online çalışan uygulamanın bir yönetim sistemine mutlaka ihtiyacı vardır. Tamamen client tarafında çalışsa bile mutlaka bazı ayarlar dinamik, bazı içeriklerde dinamik yönetilmelidir. Bu şekilde olması pratik ve avantajlı olandır.

Örnek vermek gerekirse yaptığını uygulama açılırken cihaz bilgilerini bildirim gönderebilmek için api aracılığı ile backend e göndermelidir. Yada uygulama içindeki bazı bilgileri yada sayfaları api aracılığı ile çekmelidir. Yoksa uygulama statik çalışan ve yönetilemeyen bir uygulama olarak kalır. En basitinden uygulamanızı kullanan kullanıcılara bildirimler göndermek için bile bir yönetim paneline ihtiyacınız olacaktır.

En basit olan bu ihtiyaçları karşılayacak ve işinizi kolaylaştıracak bazı hazır çözümler geliştirilmiştir. Mesela firebase , onesignal gibi platformlar bu işlemleri kolay şekilde halletmenize olanak sağlar. Toplu bildirimler göndermek için bu gibi platformları kullanabilirsiniz. Ancak bazı ayarları dinamik olarak çekmek , bazı içerikleri dinamik olarak uygulamaya getirmek yada kafanızda yer alan özellikleri yönetmek için daha kapsamlı bir yönetim paneline ihtiyacınız olacaktır.

Mesela bu bahsettiğimiz platformlardan firebase de çoğu içeriği yönetebileceğiniz ve uygulama ile konuşan bir api ve arka planda çalışan bir veritabanına sahip olabilirsiniz. Bu durumda uygulamanızı da firebase e göre yazmanız gerekir.

Bazı basit işlemlerde bu tercih edilebilir. Yada sadece push bildirimleri göndermek için onesignal seçebilirsiniz. Ancak şöyle bir düşündüğümüzde biz ne isteriz?

Biz aslında bir uygulamaya sahip olacaksak tüm kontrol bizde olsun isteriz. Bir platforma bağımlı olmasın, bir sistem kapanırsa biz ondan etkilenmeyelim.

Buna geçmişten güzel bir örnek vermek gerekirse, belki duymuşsunuzdur yada duymadıysanız anlatayım bundan birkaç sene önce herkes parse platformu üzerine uygulama geliştiriyordu. Evet çok kolaylıklar sağlıyordu hatta talep üzerinde bizde bazı işler yaptık. Ancak hep içimde bir şüphe vardı bu tip altyapılar kullanırken pratik ama uzun vadede bize ait değil ve bağımlı hale geliyoruz diye. Nitekim bunları düşünürken platform sahipleri sistemi kapatacaklarını açıkladı. İnsanları mağdur etmemek için ise kodları aık kaynak olarak paylaştılar. Yani platform kodlarını. Bu tip altyapılar karmaşık sistemler ve herkese hitap eden sistemler olduğundan kodları anlamak yada sistemi kendi sunucularınızda çalıştırmak o kadar kolay bir iş değil. Bir sorun çıktığında müdahale etmeniz o kadar kolay değil. Birçok insan ise bu platformu ya kurmaya çalıştı kendi sunucularında yada yapılarında değişikliklere gitti. Bildiğim çoğu değiştirdi çünkü en güzel olan sistem yönetebildiğiniz ve hakim olduğunuz sistemdir.

Şimdi bu örneklerden sonra ihtiyacımız olan yönetilebilir sistemin nasıl olması gerektiğinden bahsedelim.

Mobil yada web uygulamaları için ihtiyacımız olan 2 bileşen var. Hatta veritabanını da düşünürsek 3 diyebiliriz.

1 –  Veritabanı : Tüm uygulama ile ilgili verilerinizin saklandığı yer. Bu veritabanı, mssql, mysql, oracle, postgresql gibi veritabanları olabilir.

2 – Yönetim paneli:  Veritabanı ile konuşan ve tim veritabanını yönetmenizi, ayarları değiştirmenizi ve işlemler yapabilmenizi sağlayan web tabanlı arayüz. Bu arayüzün mobil uygulama olması pratik değildir. Web tabanlı olması sebebi genelde bu ayarları mobil haldeyken yapmazsınız. İşinizin başına oturur ayarları yapar ve kalkarsınız. Web tabanlı arayüzler geliştirmek ve güncellemek için daha pratiktir. App store a çıkmanızı da gerek yoktur. Değişiklik için hosting de bulunan kodları değiştirirsiniz ve web yönetim paneli isteğinize göre şekillenir. Ayrıca mobil cihazınızdan da kullanabilirsiniz. Tabi bunun için hazırlanan yönetim panelinin de mobil uyumlu yani responsive dediğimiz şekilde olmalıdır.

3 – Api: Client yani app leriniz ile konuşan sizin görmediğiniz ama web servis dediğimiz kendi response dili olan (xml yada json) bir servistir. Bu serviste yönetim paneli gibi hazırlanabilir ancak arayüzü web gibi değildir. Genelde yazılımcıların yazılımcılar ile haberleştiği bir katman gibi düşünün. Mobil uygulama yazılımcısı bu api yi kullanmak için api yi yazan kişiden api doc ister. Yani api kullanım klavuzu. Mobil yazılımcı direk yönetim panelinden işlem yapamaz – yapmamalıdır. Yada direk veritabanına veri gönderemez. Bunu yapmak için belli kurallar çerçevesinde api yi çağırır. Api ye veri gönderir, api bunu işler ve veritabanına yazar ve api client a yani mobil uygulamaya haber verir. Uygulama sahibi de yönetim panelinden tüm bunları görür bu işlemleri inceler ve yönetir. Yani api bu işe yarar, client app ler ile backend arasında bağlantı kurar.

Şimdi birde yönetim panelimizin neler içermesi gerekir bundan bahsedelim.

Yapacağınız işe göre , ihtiyaçlarınıza göre şekillendirebilirsiniz. Örneğin içerik ağırlıklı bir app var ise mesela Kategoriler ve buna bağlı yazılar var. Bu kayıtları ekleme, silme, güncelleme yapabilmelisiniz. Tüm bu kayıtları kolay şekilde aratabilmeli, sıralatabilmeli,  filtreleyebilmeli, çok kayıt olduğunda da size liste şeklinde sayfalama yaparak gösterebilmelidir. Özetle bu işlemlere kayıt yönetimi diyelim. Bunu içermelidir elbette.

Ancak burada yapacağınız işleri yönetmek dışında olması gereken bazı konular var.

1 –  Güvenlik :

Bu konu genelde atlanan bir özelliktir. Yönetim paneli en çok korunması gereken yerlerden biridir. Buraya sızan bir kişi herşeyi değiştirebilir öyle düşünün. Sıradan bir kullanıcı adı ve şifre ile bu yönetim paneline girmemelisiniz. Bir parola politikası , birden fazla yanlış denemeye – brute force saldırı yani çoklu şifre denemelerine karşı korumalı olması gerekmektedir. Şifrelernizi bu yüzden karmaşık şifreler olarak belirlemelisiniz. Zaten yönetim paneli şifre belirlerken basit şifre girmenize izin vermemelidir.

2 – Yönetici yönetimi ve roller:

Ayrıca ana yönetici olarak farklı yöneticiler yaratabilmeli ve yönetim panelinin belli yerlerini kullanabilme imkanı sağlayabilmelisiniz. Bu yönetim panelini sadece ben kullanacağım diye düşünmeyin. İlerde işiniz büyüdüğünde bu basit özellik yok ise yine ihtiyacınız olacak ve tek kullanıcının olduğu sistemde şu sorunları yaşayacaksınız. Herkes aynı kullanıcı ile işlem yaptığından bir sorun olduğunda kimin ne yaptığını bilemeyiz.

3 – Log:

Bunu anlamak için herkes farklı kullanıcılar ile girmeli ve yönetim paneli altyapınız audit log dediğimiz yönetim loglarını tutmalıdır. Yani kim ne işlem yaptı ne değiştirdi bunu süper yönetici rolundeki kişiler kolay şekilde görebilmelidir. Yani yönetim panelinden süper yönetici roller, izinler , yeni yöneticiler belirleyebilmelidir. Her yönetici tipi farklı işler yapabilir. Bu yüzden yönetim panelinizin her giren kişi için farklı menüler ve haklar ile çalışması gerektiği ortaya çıkar.

4 – Mobil uyumluluk: Bu çok önemli olmasada bilgisayar başında değilken rahat işinizi yapabilmeniz acilen bir ayar değiştirmeniz gerektiğinizde zorlanmamanız açısından yönetim panelinizin mobil uyumlu olması önemlidir.

Bu yazıda yaptırdığınız yada yapacağınız mobil uygulamada yönetim paneli neden önemli ve neleri içermeli onu anlatmaya çalıştım. Sorularınız olursa lütfen çekinmeyin.