Mobile Uygulama Çoklu Form

[3ddark]

Merhaba,

Mobil uygulama geliştirme yaparken çok fazla ekran olması durumunda. Tüm ekranlar için TForm kullanmak doğru mu? Hayır yanlış ise yerine TFrame kullanmak mı doğrudur.
Bu işin doğru yolu hangisidir. Veya bunların dışında bir yöntem mi kullanılıyor.

Karmaşık çok fazla ekranı olan veya ileriye dönük uygulamanın ekranlarının artacağı bir uygulamada nasıl yol alınmalı?

Mobil tarafında hiç ihtiyacım olmaması nedeniyle Mobil için sadece ufak test amaçlı bir iki ekran olan uygulamalar yaptım. Bu nedenle Mobil tarafta tecrübe eksiğim var.

Ayrıca böyle orta veya büyük ölçekli mobil uygulama olması durumunda önerileriniz varsa bunları da söylerseniz benim ve benim gibi yeni başlayanlar için çok iyi olacaktır.

Uygulamayı giriş ekranındaki güvenlik kısmında şifre ve kullanıcı adını hatırla işlemi için nasıl bir yol izleniyor? SQL Lite?, ConfigFile? nasıl bir yol izleniyor. Güvenliği nasıl sağlanıyor.

Teşekkürler.

[RAD Coder]

Merhaba,
Bir adet TForm (main), diğer  tüm ekranlar TFrame.

Beni hatırla için Cihaz UUID kullanıyoruz. 
Her cihazın kendine özgü UUID'si var. 
Kullanıcı beni hatırla seçeneğini işaretledi ise arka planda bu id'yi db yazıyorum. Bir defaya mahsus login olmasını istiyorum.
Çünkü bu UUID'yi bu kullnıcı ile doğrulamam gerekiyor.
Sonrasında uygulama açılışında login ekranı gelmeden önce (genellikle form show olayında) cihaz UUID'yi db den sorguluyorum. Kayıt varsa ve beni hatırla seçeneği (integer bir alan) true ise şifre ekranı yerine main forma yönlendiriyorum. 
Tersi bir durumda, login ekranına yönlendiriyorum.
Ana menüye oturumu kapatt seçeneği, ayarlara da beni hatırla seçeneğini ekliyorum. 
Kullanıcı, oturumu kapat seçeneğini seçerse yada ayarlardan beni hatırla seçeneğini pasife alırsa; db tarafında beni hatırla seçeneğini sıfır yapıyorum.

[3ddark]

Bilgilendirme için teşekkürler. Genel kullanılan mantıkla UUID yeterli değil. Web API ile çalıştığımızı düşünürsek. API tarafında güvenlik içinde JWT kullaniyorsak. Biz bu durumda her istek için header içinde jwt token gondermeliyiz. Bu durumda token bilgisini login olmadan edinmeliyiz. Bunun için daha önce alınan token saklanmalı. Bu saklanan bilginin güvenliği nasıl sağlanıyor. Database de şifreli olarak mı saklanıyor. Acaba mobil os tarafında private bir şekilde saklama yönetimi mi var. Bunu araştırayım.

Tekrar cevap ve bilgilendirme için teşekkürler

Ayrıca örnek tasarım verebileceğiniz link var mı.
Rad sample içindekilere de bakayım

[RAD Coder]

JWT'ye, kullanıcı adı şifre veya bunlara ilave bir kaç parametre de gönderilir ve access token alınır.
Sunucu tarafını da biz modellendirdiğimiz için mobile özgü dinamik parametreli (opsiyonel olarak kullanıcı adı ve şifre veya UUID alıyor) bir metod ile kullanıcı adı ve şifreye ihtiyaç duymadan access token alıyoruz.

[3ddark]

Açıklama için teşekkürler. Yaptığım aramalarda bulduğum bilgilere dayanarak Android tarafında şu linkte bahsi geçen Shared Prefrerences diye ini dosyası benzeri bir yapı var. Benzeri yapı Apple tarafında ios için burada bilgileri verilmiş. Delphi tarafında SharedPreferences nasıl kullanılacağı ile ilgili olarak @AliZairov burada bilgi vermiş. Ayrıca burada Japon bir arkadaş tüm platformlar için bir sınıf içinde implemente ettiği kodu yayınlamış. SharedPreferences denemesini yaparak uygun olması durumunda kullanabilirim.

[berk06]

Konulardan kısmen bağımsız olarak; ben çoklu form yerine tabcontrol üzerinde her bir tab sayfasını sayfa olarak kullanıyorum. Acaba yanlış mı yapıyorum diye düşündüm şimdi.

[nguzeller]

bende eskiden senin gibi yapıyordum, açılış çok zaman alıyor, fesih bey in Orangeui eğitimlerinden sonra sistem çok daha iyi oldu.

[Mr.X]

Merhaba,

FMX platformunda çoklu form kullanımı konusunda düşüncelerimi söylemek gerekir ise formların adedini platform sayısı ve kullanıcı çeşitliliği belirler. Örneğin 4 platformda kullanılması hedefleniyor ise (Android, Ios, MacOs, Windows) ikili şekilde Android- IOS ve Windows-MacOs üzerinde kullanılacak iki form hazırlanır. Formlar sadece tasarım için kullanılıp tüm işlemler için ayrı bir tek pas dosyası kullanılmasından yanayım. Yani kendi unitinizi yazın. Böylece tek merkezde yazılan kodlar tüm formlardan aynı şekilde erişilebilir olur. Kod tekrarı ile karşılaşılmaz. Formlardaki tek farklılık platformlara özgü tasarımlardan ibaret olarak kalır. Kullanıcı çeşitliliğini de hesaba katarsak;
Müşteri ve personel ayrımı olsun.
Kullanıcı deneyimi için 2 form (birisi mobil diğeri masaüstü sistemler için), personel deneyimi için ise yine 2 form kullanılır. Böylece toplamda 4 farklı form ve tek kod merkezi yapısı oluşmuş olur.
Formların çokluğu karmaşa değil düzen getirir. Kaynak dosyasında platform kontrolü yaparak istenilen form create edilir ve işlemler hızlı bir şekilde ilerler. Mobil ve masaüstü sistemlerin arayüzleri aynı ebatlarda olmayacağından ötürü form fazlalığı bu zorluğun üstesinden gelmiş olur.
İçerik olarak da gerek personel gerekse de müşteri panelleri tüm platformlarda aynı görsel bileşen sayısında üretilemeyeceğinden (üretilse dahi saçma ve gereksiz alan kaplaması olacağından ) ötürü çoklu formlarda ayrı ayrı kendi platformuna özgü tasarımlar üretmek en mantıklısı olacaktır. Sıfırdan toplamda 4 farklı tasarım yapılacak olsa da 4 özgü ve istenildiği gibi tekrar ve tekrar düzenlenebilen, kodların etkilenmediği bir yapı olacaktır. Delphideki view menüsünün kullanılmasını tavsiye etmiyorum. Deneyimlerime dayanarak söyleyebilirim ki tek formda tüm platform ve arayüzlerine tasarım yapılabilse bile mantıklı bir hareket olmayacaktır. Örneğin masaüstü üzerinde 3 görsel bileşen de yaptığınız arayüzü mobil üzerinde yine 3 bileşen kullanarak yapmış olursunuz ve toplam da 6 bileşen değil 3 bileşen kullanılmış olur. Yani aynı bileşenleri mobil üzerinde farklı şekilde konumlandırıp kullanma şansı verir. Bu hoş gibi dursa da işler tasarım konusunda ilerledikçe hoş olmaktan çıkar. Örneğin Mobil de ekran ölçeklerinden ötürü birden fazla listeyi okunur türde kalacak biçimde ve şıklığı da hesaba katarsak yan yana gösterme imkanı yoktur. Fakat masaüstü sistemlerde ekran yatayda uzadığı için bu imkan bulunur. Bu durumda iki platformdan birinde kullanılmayacak olan daha fazla görsel bileşen ekrana eklenir ve tasarım platforma özgü yapılır. Bu da platformlardan birisi için zoraki olan bu bileşenleri diğer platform ya da platformlar için artık ( çöp ) görsel bileşen haline getirir. Bu bileşenler için platform bazlı silme işlemi gerçekleştirilemediğinden dolayı visible durumları ile oynamak zorunda kalınır. 3,5,10 ya da 50 bileşen için göz ardı edilse bile hatırı sayılır profesyonel arayüzler de bu hezimete dönüşür. Tabi bileşen isimlendirmenin önemini anlamak isteyen için önerilen bir tasarım anlayışı olur. Karmaşadan doğan düzen…
 
Bu view yapısı, taslağı sabitlenen ve neredeyse tamamen sabit fikir ve düşünceler üzerine kurulmuş projeler için tavsiye edilir. Ama ben bugün bunu ekledim yarın şunu eklerim diğer gün hiçbir şey eklemem baştan yaparım diyenler için önerilemez. Kendinizi kısıtlamak ya da özgür bırakmak arasındaki ince çizgidir.
 
Ayrıca ağırlıklı olarak tasarım üzerine konuşma sebebim ise Delphi kısmı ne olursa olsun veriyi alıp ekranda gösterdiğimiz alan olarak kalmalıdır. Tüm ama tüm işlemler yapısal mimariniz nasıldır bilmiyorum ama daima Delphi tarafından uzakta olan alanda yapılmalıdır. (PHP, veritabanı vs…)
Böylece uygulama tarafında donma kasma gibi süreçlerin yerini beklemek alacak ve güvenlik bakımından da uygulamanızın bildiği tek şey veriyi nereye yollayacağı ve hangi formatta verinin geleceği olacaktır. Uygulamanın bulunduğu sistem üzerinde hiçbir veri kalıcı olarak tutulmaz böylece yazılımcısı için de kolaylık olmuş olur. Cihaz ID si konusunda ise login, bloke, yetki gibi tüm işlemlerde rahatlıkla kullanılabilir bir kimlik numarasıdır. Her şey sadece gönder ve al üzerine kurulmalı.
Bütün karmaşa ağırlıklı olarak veri tabanında çözümlenmelidir.
 
Arayüz kısmına dönecek olur isek;
Formlar hakkında sözlerimizi bitirdi isek şimdi frame tarafına gelelim.
Uygulama üzerinde neredeyse her şey dışarıdan geleceğinden ötürü tüm listelemeler frameler üzerinde yapılmış olmalı ve bu da form üzerinde sadece 1 listbox ya da türevi bileşen tutmak demektir. Tüm işlemlerde yine bu frameler üzerinde yapılacağından (silme, düzenleme vesaire gibi)
Form tarafına hiçbir şekilde yük binmeyecektir. Onlarca hatta yüzlerce frame oluşmuş olsa bile her şey kendine özgü ve karmaşadan uzak olacaktır. Framelere can eliyle sarılın. Projenizin performansı onlarda saklıdır…
 
Form üzerinde tabcontrol kullanmak benim için vazgeçilmezdir. Tüm işlemleri frameler ve veritabanı alanında yaptığım için tabcontrol sadece ayraç görevi görür.
Ufak bir bilgi-öneri vererek bitirmek istiyorum ;
Formunuzun Fmx dosyasının boyutu maksimum 2 mb civarlarında olsun. Aksi halde dönüp tasarımınızı kontrol ediniz. Ya gereğinden fazla bileşen ya da haddinden fazla resim formatı koymuş olabilirsiniz. Diğer bir önerim ise ne olursa olsun svg formatını kullanın (Tpath bileşeni).
 
Şuana kadar hiçbir harici görsel bileşen kullanmadan bir çok büyük sistem kurdum. Ne olursa olsun her fırsatta diyeceğim şudur ki;
Harici bileşen kullanmayın!

[RAD Coder]

Neden tek form diyorum?
FMX mimarisinin bize sunduğu çok güzel nimetler var. Bunlardan faydalanmak lazım. 

Tek bir form yapısı, hangi platformda ne gibi davranış göstereceğine kendisi karar veriyor.
En güzel tarafı da tek satır kod yazmanıza gerek yok.
Nasıl mı?

   

View: Master
Bir form ve üzerinde yalnızca Button1 yazan buton var.

   

View: Android
Buton caption ve konumu değiştirildi.

   

View: macOS
Buton caption ve konumu değiştirildi. Form boyutu değiştirildi.

Tek bir uygulama, tek bir form sizce 5 platformda çalıştırılsa nasıl görünecektir?

Söyleyeyim;
Android platformunda çalıştırılırsa, sol üst köşede başlığı"Deneme" olan bir buton görürsünüz.
macOS platformunda çalıştırılırsa, sağ üst köşede başlığı "Deneme macOS", WordWrap özelliği true olan buton ve genişliği 1482 px olan form görürsünüz.
Windows ve Linux GUI (FMX Linux eklentili) platformunda çalıştırılırsa, sol-ortaya yakın kısımda başlığı "Button1" olan bir buton ve genişliği 385 px olan form görürsünüz.
iOS platformunda çalıştırılırsa, sol-ortaya yakın kısımda başlığı "Button1" olan bir buton görürsünüz.

Master görünümde eklenen bir bileşeni, diğer görünümlerden silemezsiniz. Fakat visible özelliğini false yaparak o platformda görünmemesini sağlaybilirisiniz.