MERHABA! Bugün size, içerik yönetimi deneyimini geliştirmek ve yeni bir CMS türü olan Flutter uygulama geliştirme dünyasına ek özellikler getirmek için gece ve hafta sonları aylarca süren çalışmalarımın meyvesini tanıtmak istiyorum.

Nanc'tan bahsediyoruz - Normal Bir C MS Değil . Bunun neden "normal olmadığını" ve bununla ne yapabileceğinizi bu makaleyi okuduktan sonra öğreneceksiniz.

Makale sadece teoriyi değil aynı zamanda "pratiği" de içerecektir; Nanc sanal alanında oynayabileceksiniz. Halka Nanc'ın yeteneklerini göstermek için iki demo uygulaması yapıldı: herhangi bir Flutter uygulamasını taklit eden bir istemci uygulaması ve Flutter tabanlı bir Nanc uygulamasının neler yapabileceğine dair fikir veren bir başka uygulama - önceden oluşturulmuş Nanc CMS. Ve istemci uygulamasını CMS ile senkronize etmek için uygulanan ek bir mantık katmanına sahip, önceden yapılandırılmış bir CMS olan Nanc CMS uygulaması.

Metindeki mantık bloklarının çoğunun sonunda, Nanc'ın nasıl kullanılacağına/bazı yönlerinin nasıl gösterileceğine dair bir örnek içeren bir youtube videosu bulacaksınız.

İçindekiler

1. Giriş
2. CMS Hakkında
   1. Model türleri
      1. Toplamak
      2. Solo
   2. Editör
      1. Genel açıklama
      2. Önce kod
      3. Arayüz öncelikli
      4. Hibrit mod
   3. Alanlar
      1. Bool
      2. Renk
      3. Tarih
      4. Dinamik
      5. Sıralama
      6. Başlık
      7. Simge
      8. İD
      9. Çoklu Seçici
      10. Sayı
      11. Seçici
      12. Sicim
      13. Yapı
      14. Ekran
3. Dinamik Flutter uygulamaları
   1. Etkileşimli belgeler
   2. Genişletilebilirlik
   3. Basitlik
   4. Güç
   5. Kolaylık
   6. Verim
4. Nanc demo uygulamaları
   1. Genel
   2. Müşteri
   3. Yönetici
   4. Bağlantı yöneticisi
5. Sırada ne var / Son Sözler

Nanc CMS Hakkında

Bu yüzden. Nanc, kendi arka ucunu çekmeyen, arka uçtan bağımsız bir CMS'dir. O nasıl çalışır? Nanc, şu anda 6 yönteme sahip olan ancak piyasaya sürüldüğünde yaklaşık 10 yönteme sahip olacak ağ hizmeti arayüzlerini uygulamayı teklif ediyor. Bu çok mu yoksa az mı? Örneğin, demo uygulamasına yönelik API'yi uygulamak için 170 satır kod gerekiyordu. Bu yöntemler, Nanc'ın mevcut arka ucunuzla yaptığı tüm çalışmalardan sorumludur. Uygulama Dart'ta (Flutter'ın geliştirme dili de) yazılmalıdır. Gelecekte Nanc, belirli arka uç seçenekleri için bu arayüzlerin hazır uygulamalarıyla gelecek - Firebase, Supabase, yerel / ağ SQLite ve REST ve GraphQL'in genel uygulamaları (belki başka bir şey?) ve bu uygulamayı düşünmek zorunda kalmayacaksınız. hepsi ya da zorunda kalacak, ama sadece biraz.

Model türleri

Nanc'taki bir model, Nanc ile kontrol etmek istediğiniz bir varlığın yapısal açıklamasıdır. Bir model, bir varlık adını, çeşitli görsel parametreleri ve alanların açıklamasını içerir.

Toplamak

Koleksiyon, birçok örneğe sahip olabilen bir varlıktır. Kullanıcıların, kitapların ve incelemelerin bir listesi, Nanc'taki Koleksiyon türü modellerin iyi örnekleridir.

İlişkisel veritabanlarına aşina iseniz, Nanc'taki Koleksiyona örnek olarak veritabanınızdaki hemen hemen her tablo verilebilir.

Solo

Solo (model), tek bir örnekte var olan bir varlıktır. Örneğin - Özellik Geçişleri veya bir şeyin konfigürasyonu veya... "Bir mobil uygulamanın ana ekranı". Genel olarak konuşursak, Solo modeller yalnızca veritabanınızın bir yansıması olarak kullanılabilirliği artırmak için tasarlanmıştır. Ve Solo modeli, veritabanınızdaki tek bir kayıtla kolayca herhangi bir tablo olabilir. Ancak şu anda, bu model sınıfının uygulanması, bu modelin kaydının (veritabanındaki satır) modelin id eşit bir id sahip olmasını gerektirir.

 final Model landingPage = Model( name: 'Landing page', /// ? id in format [toSnakeCase(name)] will be set automatically, if omitted // id: 'landing_page', isCollection: false, icon: IconPackNames.flu_document_page_break_regular, fields: [ ...

Editör

Genel açıklama

Nanc çeşitli şekillerde yapılandırılabilir: kodla, Nanc arayüzünün kendisi aracılığıyla ve bu seçeneklerin bir kombinasyonu aracılığıyla.

Kod öncelikli yapılandırma

"Konfigürasyon" derken öncelikle modellerinizin yapısını anlatmayı kastediyorum. Basit bir örnek olarak, bir ürünün özelliklerini açıklayan bir varlık olan Özellik modelini ele alalım. Bu varlık aşağıdaki alanları içerir:

• İD
• başlık
• görüntü
• Tanım

Ve kod öncelikli yapılandırma olarak uygulama aşağıdaki gibi olacaktır:

 import 'package:fields/fields.dart'; import 'package:icons/icons.dart'; import 'package:model/model.dart'; final Model feature = Model( name: 'Feature', icon: IconPackNames.flu_ribbon_star_filled, fields: [ [ IdField(width: 200), StringField(name: 'Title', maxLines: 1, isRequired: true, width: 400), ], [ IconField(name: 'Image', isRequired: true), ], [ StringField(name: 'Description', isRequired: true, showInList: true), ], ], );

Böyle bir modeli tanımlayıp Nanc CMS'de kullanarak o modelin tüm CRUD işlemlerini kullanımınıza sunabilirsiniz.

Arayüz öncelikli yapılandırma

Nanc arayüzü aracılığıyla tam olarak aynı Özellik modelini (buna Özellik Varyantı diyelim) oluşturabiliriz. Ve (Nanc'ı kullanmaya yönelik tüm hazırlık çalışmalarının yapıldığını göz önünde bulundurursak) - Nanc'ta bir model oluşturduğunuzda, hemen veritabanında bir tablo oluşturacaksınız ve CRUD'un tamamı da anında kullanımınıza sunulacak.

Ayrıca Nanc arayüzü aracılığıyla bir model oluşturduğunuzda veritabanında hiçbir şey oluşturmamanın daha güvenli yolunu kullanabilirsiniz. Ve bağımsız olarak veritabanınızda bir tablo oluşturun ve ardından onun altında Nanc'ta bir model oluşturun. Bu arada, yapılandırmayı kodda açıklarsanız yapmanız gereken şey budur - veritabanınızda yeni tablolar görünmeyecektir.

Hibrit yapılandırma

Bu seçenek, Kod-önce yapılandırmanız olduğunda ve bunu Nanc arayüzü aracılığıyla değiştirmeye karar verdiğinizde kullanımınıza sunulur. Bu durumda, bu modelde yapılacak tüm diğer değişiklikler yalnızca arayüz aracılığıyla mümkün olacak ve orijinal kod modelinde yapılan değişiklikler göz ardı edilecektir. Code-first'e dönmenin tek yolu modeli "sıfırlamaktır"; bu durumda model yapısında arayüz aracılığıyla yapılan tüm değişiklikler silinecek ve Code-first yapılandırması yeniden kullanılacaktır. Bu sıfırlamadan hiçbir veri etkilenmez. Yalnızca model yapısını etkiler.

Alanlar

Şimdi Nanc'ın şu anda ne tür alanları desteklediğine bakalım.

Boolean

BoolField, bool veri türünü kontrol etmenize ve varsayılan değeri özelleştirmenize olanak tanır.

Renk

ColorField, Nanc'ta hemen bir renk seçmenizi sağlayan kullanışlı bir renk seçici sağlar. Ayrıca AHEX kodunu düzenleyerek manuel olarak değişiklik yapma olanağı sağlar. AHEX klasik bir HEX Rengidir (örneğin, #10A0CF ), ancak önce ek bir şeffaflık değeri belirtilir. Bu durumda bu renk #FF10A0CF rengine benzer olacaktır ( FF %100 opaktır - renk tamamen opaktır). Aynı renk %50 opaklıkla şu şekilde görünür: #7F10A0CF .

Tarih

DateField, tarih ve saati kontrol etmekten sorumludur (her iki değer aynı anda, tarih ve saat için ayrı olanlar daha sonra uygulanacaktır). DateField, bu alanın davranışını, onu bir varlık oluşturma zamanı zaman damgası ve değişiklik zamanı zaman damgası haline getirerek değiştirmenize olanak tanıyan iki boole parametresi içerir.

Dinamik

DynamicField bir yandan çok basit bir alan ama diğer yandan diğer alanların tüm karmaşıklığını da içeriyor. Başlangıçta, bu alanın yalnızca görünümünü yapılandırabilirsiniz (Nanc arayüzünde nasıl görüneceği - renk ve ona eşlik eden simge). Bundan sonra bu alan, kendisi de dahil olmak üzere Nanc'ta mevcut olan tüm değerleri içerebilir. Bu ne anlama gelir? Esasen DynamicField, alanları kendi içinde sırayla konumlandırma yeteneğine sahip, yazılı bir JSON'dur.

Sıralama

EnumField, birden fazla değerden değer seçmek için kullanılan bir alandır. Bir EnumField seçerken uyulması gereken kural, ayrı bir veritabanı tablosunda saklanmayan, seçilecek değerlerin son bir listesine sahipseniz Enum'u seçmenizdir. Aksi takdirde, aşağıda daha ayrıntılı olarak ele alınan SelectorField'ı seçin. YAPILACAKLAR: Şu anda bu alan yalnızca CodeConfig aracılığıyla yapılandırılabiliyor, arayüz aracılığıyla yapılandırma henüz gerçekleştirilmedi.

Başlık

HeaderField aslında bir alan değil, Nanc'taki modeliniz için görsel bir geliştiricidir. Bu alan olmayan alanı, ilgili alanlardan oluşan bir grup için ortak bir başlık ayarlamak veya sınırlayıcı olarak HeaderField'ı kullanarak model alanlarını birbirinden ayırmak için kullanabilirsiniz.

Simge

IconField size önceden tanımlanmış bir simge kümesinden bir simge ( IconData sınıfı) seçme olanağı sağlar. Şu anda yaklaşık 25.000 tane var ve bu set aşağıdaki simgeleri içeriyor:

Gerekirse temel dağıtım setine başka simgeler de eklenebilir ve çok uzak olmayan bir gelecekte kendi simgelerinizi kullanma seçeneği de mevcut olacaktır.

Birisi şunu merak edebilir: "Simgeler var, renkler var ama yazı tipleri?" Bunu yaptıysanız cevabını Metin widget'ının belgelerinde bulabilirsiniz. Kısa cevap, Fonts'taki tüm yazı tiplerinin kullanımınıza açık olmasıdır.

İD

IdField çok basit ama bir o kadar da önemli bir alandır. Nanc tarafından yönetilen her model, Id türünde en az bir alana sahip olmalıdır. Şu anda yalnızca dize kimliği türü desteklenmektedir (bir varlık içindeki herhangi bir benzersiz dize olabilir). Sayısal tür için de destek ekleme planları vardır; ancak bu, şu anda bile yalnızca alan verilerinin API uygulamasındaki sayısal türe dönüştürülmesiyle uygulanabilir.

Çoklu seçici

MultiSelectorField, ilişkisel çoktan çoğa veya çoktan bire ilişkinin uygulanmasından sorumlu olan oldukça karmaşık bir alandır. Bu alanı kullanmanın üç modu vardır. Her birini daha ayrıntılı olarak ele alalım. YAPILACAKLAR: Şu anda bu alan yalnızca CodeConfig aracılığıyla yapılandırılabiliyor, arayüz aracılığıyla yapılandırma henüz çözülmedi.

Kimlik dizisi

Bu mod size ilgili varlıkların id doğrudan üst varlıkta saklama olanağı verir. Örneğin iki modelimiz var: Reader ve Book. Bu modda, okuyucunun aldığı kitaplar, Okuyucu modeli alanında saklanan kimlikler olarak dikkate alınacaktır. Örneğin şöyle:

 /// user table { id: 'UUID', name: 'String', books: [ 'UUID', 'UUID' // ... ] }

Yukarıda JSON5 sözdizimi kullanılarak ifade edilen örnek bir tablo yapısı verilmiştir.

Bu modun dezavantajı sınırlı veri bütünlüğüdür. Eski (silinmiş) kitap kimliklerinin books Okuyucusu alanından otomatik olarak kaldırılmasını uygulamazsanız hatalar alırsınız.

Üçüncü tablo

SQL dünyasından ilişkiler sağlamanın klasik modu. Bu modu kullanırken varlık ilişkilerini ayrı bir tabloda saklar ve %100 veri bütünlüğü sağlarsınız. Aşağıdaki yapı bu modun bir örneğidir:

 [ /// user table { id: 'UUID', name: 'String' }, /// book table { id: 'UUID', title: 'String' }, /// user_books_relations table { user_id: 'UUID', book_id: 'UUID' } ]

7. saniyede hafif bir seğirme görebilirsiniz ve yakından bakarsanız sayfa URL'sinin değiştiğini fark edebilirsiniz - hatayı bu şekilde gizlemeye çalıştım: üçüncü tablo modunda veriler yalnızca ana sayfaya kaydedilir. zaten kurtarıldı 🤷🏼

Nesne dizisi

Ana kaydın tanımlayıcıları değil tüm nesneyi (iç içe geçmiş kaydın olası ilişkili varlıkları olmadan düz bir yapı olarak) depolaması dışında genel olarak kimlik dizisine benzer. Array of id ile aynı dezavantaja sahiptir, ancak ek olarak artan depolama alanına sahiptir. Ancak bu modun (en azından şimdilik) bir uygulama alanı var ve bu çok önemli. Ancak bunun hakkında biraz sonra konuşacağız.

ScreenField'ı gösteren videoda kendimin önüne geçiyorum, buna geri döneceğiz

Genel olarak, "kanonik olmayan" modları sanal hale getirme fikri vardır - böylece bir şekilde Üçüncü tablo üzerinden çalışırlar ve sayfa düzenlenirken (gerekirse) gerekli veriler yüklenir.

Sayı

NumberField sayıları saklar; bu kadar basit.

Seçici

SelectorField, MultiSelectorField'a benzer (adlarından da tahmin edebileceğiniz gibi), ancak biraz daha basittir - buradaki ilişki bire bir veya bire çoktur ve iki mod vardır. YAPILACAKLAR: Şu anda bu alan yalnızca CodeConfig aracılığıyla yapılandırılabiliyor, arayüz aracılığıyla yapılandırma henüz gerçekleştirilmedi.

İD

Ana kayıt alanının bağlı kaydın kimliğini depoladığı yaygın bir SQL bağlantısı sağlama biçimi. Örnek olarak Reader'ı ele alalım. Kim o? Her şeyden önce bu bir insandır ve insan neye sahiptir? Bu doğru! Doğduğunuz şehir (Kütüphanemiz de bir sebepten dolayı bilmek istedi).

 /// user table { id: 'UUID', name: 'String', birth_place_id: 'UUID' }

Nesne

MultiSelectorField'daki nesnelerin Array'ine çok benzer, ancak ilişkili tek bir değeri ana kaydın alanında saklayacağız. Dezavantajları aynı, artıları da biraz aşağıda anlatılacak.

Sicim

StringField dizeleri saklar. Bu alanın Nanc'ta düzenleme kolaylığından sorumlu kişisel bir ayarı vardır; düzenlenebilir alanın maksimum yüksekliğini sınırlayan parametre. Metniniz büyükse - onu hiç belirtmemek mantıklıdır, o zaman alan metnin yüksekliğine göre ayarlanacaktır. Büyük ile sınırlıysa - alanın yüksekliğini (satırlar halinde) açıkça belirtebilirsiniz ve bu her zaman böyle olacaktır. Ve son olarak, kısa dizeler için bunu bir satıra ayarlayabilirsiniz ve daha sonra ne kadar yazarsanız yazın alan genişlemeyecektir.

Yapı

StructureField, model kayıtlarında bir dizi yazılan yapıyı saklamanıza olanak tanır. Saklanacak veri türünü siz belirlersiniz ve bunu kolay ve basit bir şekilde yönetebilirsiniz. Yapı alanları için mevcut türler kesinlikle her şeydir. Böylece kolayca "Dinamik Yapı Alanı Tekrarı" oluşturabilirsiniz. YAPILACAKLAR: Demoda StructureField'a yalnızca "düz" alanlar eklenebilir.

Ekran

ScreenField, bir uygulamanın tamamını Nanc'ta, Flutter'da yazmanıza olanak tanıyan bir alandır! ScreenField ile tek bir ekranın arayüzünü tanımlayabilir, onu istediğiniz gibi güncelleyebilir ve bunu istediğiniz zaman dakikalar içinde yapabilirsiniz - Apple ve Google'dan gelen incelemeleri sıkıcı ve sinir bozucu bir şekilde beklemek zorunda kalmadan.

Bu tür bir alanı (ve aslında Nanc'ın tamamen ayrı bir işlevsel dalını) biraz daha ayrıntılı olarak inceleyelim.

Dinamik Flutter uygulamaları

ScreenField ile, doğrudan tarayıcınızda (ve IDE'nizde) hemen hemen her karmaşıklıkta bir arayüz oluşturabilir ve ardından - stok yayını yapmadan - uygulamanızdaki ilgili ekranı güncelleyebilirsiniz. Varsayımları hızlıca kontrol etmeniz gerekiyorsa bu harika bir özelliktir. Bu işlevsellik, uygulamanızdaki nispeten basit (mantık açısından) sayfalar için mükemmeldir, ancak bunların oldukça sık değişmesi gerekir. Gelecekte bu işlevsellik, herhangi bir kısıtlama olmadan gerçekten istediğiniz her şeyi yaratabileceğiniz bir duruma genişletilecektir. Şimdi Nanc ile dinamik ekranlar oluşturmanın tüm yönlerini inceleyelim.

Etkileşimli belgeler

Flutter'da çok sayıda widget var. Birçoğu. Widget nedir? Uygulamanızı bir araya getirdiğiniz bir işlevsellik tuğlasıdır. Yalnızca görsel olabilir veya içinde bazı davranışlar bulunan mantıksal olabilir. Nanc, kullanıcı arayüzünüzü oluşturmak için kullanabileceğiniz uygulanmış widget'ların kapsamlı bir listesini sağlar. Ancak olasılık ne kadar fazlaysa, onlar hakkında bilgi edinmek o kadar zor olur... Yani Nanc'taki ekran düzenleyici size şu anda hangi widget'ların uygulandığını, hangi parametrelere ve yapılandırılabilir özelliklere sahip olduklarını bulabileceğiniz etkileşimli bir belgeye erişmenizi sağlar. doğrudan belgelerde, oluşturduğunuz arayüzün görünümünü nasıl etkilediklerini görün.

Basitlik

Nanc, gerçek zamanlı bir arayüz oluşturmanıza olanak tanır, ancak en önemlisi, bunu çok kolay ve hızlı bir şekilde yapmanıza olanak tanır (bir demo uygulamasının arayüzünü oluşturmak 2 saatten biraz fazla zaman aldı). Ancak şu soru ortaya çıkıyor: Kullanıcı arayüzünün kendisi nasıl oluşturulur? Nanc'ta kullanıcı arayüzünü tanımlamak için egzotik bir sözdizimi veya Nanc'ta arayüz oluşturmaktan nefret etmenizi sağlayacak uzun JSON gibi "fazla" basit çözümler yoktur.

En iyi çözümü bulmanın sonucu basit ve anlaşılır XML sözdizimidir. Tüm standart Flutter widget'ları tam olarak aynı adlara sahiptir ancak XML biçimindedir. Örneğin, Nanc'taki SizedBox widget'ı <sizedBox>...</sizedBox> olacaktır ve bu kural istisnasız tüm widget'lar için geçerlidir. Widget'ın bazı karmaşık özellikleri varsa, prop önekiyle XML ile aynı (veya daha basit) ada sahip olacaktır. Örneğin, Container widget'ı, kendi dahili özelliklerine sahip karmaşık bir boxDecoration sahiptir. Yani, Nanc'taki bu özellik şu görünüme sahip olacaktır: <prop:decoration>...</prop:decoration> . Bu kural tüm karmaşık özellikler için geçerlidir. Ve son husus, nispeten basit olan argümanların XML etiketi parametreleri olmasıdır. Örnek olarak aynı SizedBox ele alalım:

 <sizedBox width="50" height="50"> ... </sizedBox>

Bazı widget'lar için kod yazmayı basitleştirmek amacıyla ek argümanlar uygulanır ve SizedBox için hem width hem de height ayarlayan ize argümanıdır.

Burada yazılan her şey çevrimiçi belgelerde yer almaktadır; dolayısıyla bir şeyi unutursanız veya bir şey bilmek istiyorsanız, ona bakın ve tüm sorularınızın yanıtlarını orada bulabilirsiniz.

Genişletilebilirlik

Yeni widget için desteğin uygulanması 10 dakikadan birkaç saate kadar sürebilir. Bu noktada, mantıkla karmaşık bir arayüz oluşturabileceğiniz temel widget'ların neredeyse tamamı uygulanır. Zamanla Flutter'da bulunan tüm widget'lar Nanc'ta uygulanacak ve gerçekten her şeyi yapabilirsiniz. Ama hepsi bu değil. Kolayca ve basit bir şekilde kendi widget'larınızı uygulayabilir ve bunları bir veya iki satırlık XML koduyla Nanc'ta kullanabilirsiniz. Örneğin, standart Flutter kütüphanesinde Carousel Slider'ı resimlerle kolayca görüntülemenizi sağlayacak bir widget yoktur. Kendiniz bir uygulama yazmanız veya gibi açık kaynaklı bir çözüm kullanmanız gerekecek. Ve ihtiyacınız olanı uyguladıktan sonra widget'ınızı Nanc'a çok kolay bir şekilde entegre edebilir ve kullanabilirsiniz.

Güç

Nanc, XML kodunu Flutter'daki bir arayüze dönüştürme yeteneğinden daha fazlasını sağlar. Nanc, şablon oluşturma ve mantıksal yazma yetenekleri sağlar. Koşullu öğe oluşturma, döngü çizimi, kademe yönetimi - bunlar zaten Nanc'ın mevcut 0.0.1 sürümünde bulunmaktadır.

Şu ana kadar mantık kısmı oldukça basit - dokunma yoluyla etkileşimi ve önceden yazılmış `.dart' kodunuzdaki olay işlemeyi destekliyor - ancak sonunda Nanc'ın bu kısmı önemli ölçüde genişleyecek ve Dart'ta mantığı doğrudan tarayıcıdan yazmanıza olanak tanıyacak ve uygulamanızda da çalışmasını sağlayın.

Kullanıcı tıklamalarını yönetme yaklaşımı şu şekildedir; kullanıcının uygulamanızda yapabileceği "eylemlerin" bir listesini tanımlayabilirsiniz. Örneğin - dahili uygulama ekranını açın, harici bağlantıya tıklayın, SnackBar'ı görüntüleyin, kalıcı pencereyi açın ve daha birçok şey yapın ve bu tür eylemler için önceden işleyici oluşturun. Ve sonra bu eylemi Nanc'ta istediğiniz şekilde kullanın. Olay işleme hakkında daha fazla bilgi için Nanc'taki InkWell widget'ına ilişkin belgelere bakın.

Kolaylık

Nanc'ın yerleşik bir XML düzenleyicisi vardır, ancak pek kullanışlı değildir. Aranabilir değil (henüz), çok fazla kod içerdiği için çok hızlı değil ve otomatik tamamlama özelliği yok. Bununla nasıl yaşanır? Örneğin, kullanıcının favori IDE'sini kullanmasına ve Nanc'taki değişiklikleri gerçek zamanlı olarak izlemesine izin verin. Size nasıl yapılacağını göstereyim. Ve bu da Web (oynamanız gereken şey bu):

Gelecekte otomatik tamamlama desteği eklenecek, belki de uzak bir gelecekte... XML Şemasını derinlemesine incelemeye çalıştım, birkaç gün harcadım ama şu ana kadar başaramadım 🤷🏼

Verim

Ayrı olarak performanstan (mobil cihazlarda XML'den arayüz çizimi) bahsetmek istiyorum. Kısacası herhangi bir ek yük olmadan Flutter'ın performansıyla aynıdır. Şu anda, "ekran", eşzamansız olarak oluşturulan, tembel bir şekilde oluşturulmuş bir widget listesidir (SliverList). Daha sonra bu uygulama, widget'ları eşzamansız olarak oluşturmaya başlayacak şekilde geliştirilecek, ancak bu sayede içeriği görüntülemek için gereken süre, XML'de açıklanan ilk widget'ı oluşturmak için gereken süreye eşit olacak.

Nanc demo uygulamaları

Genel

Yetenekleri göstermek için, Nanc ile şu anda nelerin başarılabileceğini gösteren halka açık bir dizi demo uygulama oluşturuldu. Bu, Android ve Web'deki bir istemci uygulamasıdır (ikincisi geçici olarak bir iOS uygulamasının rolünü de oynar). Nanc CMS uygulamasının yanı sıra. Aşağıda onlar hakkında daha fazlasını okuyun.

Bağlantılar

Müşteri

Client, nanc ekosistemindeki tek bir kütüphaneyi kullanan bir istemci demo uygulamasıdır. Bu kütüphane, XML'i Flutter'daki bir uygulama arayüzüne dönüştürmenize olanak tanır. Bu uygulamanın tamamen Nanc'ta oluşturulmuş tek bir ekranı vardır ve depolara gerek kalmadan istenildiği zaman güncellenebilir. Sağ altta bağlantı simgesi olan bir düğme vardır - bağlanmaktan sorumludur. Bu "bağlantının" ne olacağı hakkında daha fazla bilgiyi aşağıda bulabilirsiniz.

Yönetici

Yönetici, istemcilerle senkronizasyon olanağı sağlayan ek olarak uygulanan bir mantık katmanına sahip bir Nanc-CMS demo uygulamasıdır (bağlantı hakkında daha fazla bilgi aşağıdadır). Nanc-CMS demo uygulamasında kullanıcının tarayıcısının kendisi ve localStorage'ı "arka uç" görevi görür. Eklediğiniz veya değiştirdiğiniz her şey yalnızca tarayıcınızda saklanır. Nanc-CMS'de mevcut modellerle ilgili verileri değiştirebilir / oluşturabilir / silebilirsiniz (onları göreceksiniz) ve - arayüz aracılığıyla kendi modellerinizi oluşturabilir ve aynısını onlarla yapabilirsiniz.

Bu demonun oluşturulmasında kullanılan veri modellerinin SQL temsili olarak aşağıdaki ekran görüntüsü size yol gösterebilir:

Bağlantı yöneticisi / "Bağlantı"

Bu bölüm yalnızca istemci ve CMS uygulamalarındaki "demo" mantığıyla ilgilidir. Nanc ile etkileşim deneyimini ve müşteriyi güncelleme sürecini simüle etmek için uygulandı. Ama önce ilk şeyler.

Gerçek bir üretim projesinde Nanc'ı şu şekilde kullanabilirsiniz: API hizmetlerinin uygulandığı statik bir Nanc CMS uygulamasını bir yere dağıtın. Arka ucunuzla iletişim kurar ve Nanc'ı beğeninize göre kullanırsınız. Uygulamanız, nanc ekosisteminden arayüzü oluşturmanıza olanak tanıyan bir kitaplık içerir. Bir güncelleme yaptınız - uygulama arka uçtan yeni kod yükledi, güncellendi - herkes mutlu ve memnun.

Bu modeli çalışırken göstermek için aynı şey uygulanır, ancak basitleştirilmiş bir şekilde: Nanc CMS, github sayfalarında statik olarak bulunur ve onu tıpkı "gerçek hayatta" olduğu gibi kullanabilirsiniz, ancak tarayıcınız arka uç görevi görür. Yani, API'ler localStorage tarayıcısında "ağa gidecek" şekilde uygulanmıştır. Bu bölümle işimiz bitti, ancak hala size bir şekilde "güncelleme" sürecini göstermesi gereken bir mobil uygulama var.

İşte "bağlantı" burada devreye giriyor. Kısacası herhangi bir Nanc istemci demo uygulaması ile herhangi bir Nanc CMS demo uygulaması arasında doğrudan bağlantı kurabilirsiniz. Bunu yapmak için CMS'de sağ alt kısımdaki QR kod simgesinin bulunduğu düğmeye tıklamanız gerekir. Görünen modal pencerede QR kodunu göreceksiniz. Daha sonra iki sandalyeniz var - sağ alttaki benzer düğmeye basarak bu kodu mobil (veya tarayıcı) istemci uygulamasıyla tarayabilirsiniz, ardından bağlantı otomatik olarak kurulacaktır. Veya QR koduna tıklayabilirsiniz; bağlantı için gereken veriler panoya kopyalanacaktır. Daha sonra bu verileri mobil uygulamanın giriş alanına yapıştırmanız ve butona basarak bağlanmanız gerekecektir. Bağlantı kurulduğunda kendinizi anlayacaksınız. Bundan sonra, mevcut Açılış Sayfasıyla istediğinizi yapabilir ve değişiklikleri gerçek zamanlı olarak (kaydettikten sonra) mobil uygulamada görebilirsiniz.

Ancak Açılış Sayfasıyla sınırlı değilsiniz. Doğrudan tarayıcıda herhangi bir yeni model oluşturabilir, bunları içerikle doldurabilirsiniz ve modellerinizde arayüz açıklaması için bir alan varsa (Ekran yazın), bu tür varlıkları kaydettiğinizde sonucu uygulamada da göreceksiniz - Yeni modeldeki ekran, mevcut uygulama ekranının yerini alacak. Tek nokta, istemci uygulamasının yeni oluşturduğunuz kaydın ne tür bir alan olduğunu bilmediğinden, ScreenFields olması beklenen olası tanımlayıcıların belirlenmiş olmasıdır.

Yani tamamen sıfırdan bir ekran oluşturup bunu uygulamada görüntülemek istiyorsanız IdField değeri olarak aşağıdaki listeden bir şey kullanın:

• ekran
• kullanıcı arayüzü
• sayfa
• arayüz
• işaretleme
• görüş

Bir şeyi bozarsanız verilerini sıfırlayın (Chrome: F12 -> Uygulama -> Uygulama -> Depolama -> Site Verilerini Temizle), istemci uygulamasını yeniden açtığınızda her zaman oluşturulan gerçek ekran kodunu yükler Bu demo için. (Tarayıcınızdaki kod yalnızca bağlandığınızda yüklenecektir)

Ve son olarak, ScreenField içeren yeni bir modelin yeni sayfasının oluşturulmasına ve uygulamada işlenmesine ilişkin küçük bir örnek:

Sıradaki ne?

Herkese açık demo hazır. Giriş yazısı yazılmıştır. Nanc'ın gelecek planları, model oluşturmaya yönelik arayüz yaklaşımının işlevsel bütünlüğünü tamamlamak ve tüm alanların (Enum, Selector ve MultiSelector) yapılandırılmasını mümkün kılmaktır. StructureField'daki öğelerin konumunu değiştirmek gibi bilinen hataları düzeltin. Sonra "blah blah blah" ve ardından "falanca". Birikmiş iş en azından önümüzdeki altı ay için yeterli olacaktır, ancak işlevselliğin genişletilmesine yönelik daha ileri model müşteri ihtiyaçlarına dayalı olacaktır, yani fikirleriniz/eleştirileriniz/bulunan hatalarınız (ve bunlardan birçoğu varsa) /başka herhangi bir şey varsa - lütfen bağlantısı müşteri demo uygulamasında bulunan formu doldurun.

Nanc'ın özellikleriyle ilgileniyorsanız ve işbirliğiyle ilgileniyorsanız - siz de formu doldurun, mutlaka konuşalım.