Pažingsniui papasakosiu, kas tiksliai nutiko: nuo to, kaip DI sugeneravo 1 000 kodo eilučių per tris minutes, iki momentų, kai prieš dar spėdamas išbandyti prisijungimo ekraną susidūriau su vykdymo klaidomis. Pamatysite, ką Thunkable atlieka puikiai, kur jis visiškai stringa ir ar tai iš tiesų verta žetonų biudžeto jūsų konkrečiam naudojimo atvejui.
Kas yra Thunkable?
Thunkable yra be kodo mobiliųjų programų kūrimo įrankis, kuris naudoja DI, kad iš teksto promptų sugeneruotų vietines iOS ir Android programas.
Skirtingai nei tradicinės be kodo platformos, kurios remiasi drag-and-drop blokais, Thunkable DI kūrimo įrankis generuoja realų kodą – įskaitant JavaScript failus, komponentų struktūras ir stilius.
Stebite, kaip DI „mąsto“ jūsų reikalavimų kontekste, suskaidydamas promptą į programos struktūrą, dizaino stilių, pagrindines funkcijas ir duomenų modelius prieš rašydamas kodą. Toks skaidrumas išskiria jį tarp juodą dėžę primenančių DI kūrimo įrankių, kurie slepia techninius niuansus.
Kokias problemas tai sprendžia?
- Greitis palyginti su kūrimu nuo nulio: kelių ekranų programos su autentifikacija, formomis ir duomenų valdymu, kuri tradiciškai užtruktų kelias dienas, sugeneruojama per kelias minutes
- Profesionali mobili sąsaja be dizaino įgūdžių: DI supranta mobiliųjų įrenginių dizaino įpročius ir generuoja programas, kurios atrodo vietinės, o ne kaip mobiliosios svetainės
- Lankstumas techniniams vartotojams: skirtingai nei grynai be kodo įrankiai, gaunate prieigą prie React Native kodo šaknų, tad kūrėjai gali pritaikyti programą už DI sugeneruotų ribų
Kaip ji save pozicionuoja: kol tokios platformos kaip Bubble orientuojasi į žiniatinklio programas su vizualiais redaktoriais, o Flutterflow taikosi į kūrėjus, norinčius Flutter kodo, Thunkable užpildo spragą. Jis pakankamai greitas netechniniams įkūrėjams atlikti prototipų bandymus, tačiau kūrėjams suteikia galimybę dirbti su kodu ir kontroliuoti procesą.
Kam skirtas Thunkable?
Thunkable geriausiai tinka technologiškai linkusiems kūrėjams, kurie nori greitai paruošti mobiliųjų programų prototipus ir nebijo ieškoti klaidų arba pažvelgti į kodą, kai kažkas sugesta. Taip pat ypač tinka:
- Pradedančiųjų įmonių įkūrėjams, tikrinantiems mobiliųjų idėjų gyvybingumą: jei kuriate prekyvietę, rezervacijų sistemą ar paslaugų portalą ir jums reikia veikiančio iOS/Android prototipo, kurį galite parodyti investuotojams ar ankstyviems vartotojams, Thunkable per kelias valandas perneša jus nuo idėjos prie bandomos programos.
- „Python“ kūrėjams, tyrinėjantiems mobiliųjų programų vystymą: suprantate serverio logiką ir API, tačiau Swift ar Kotlin mokytis atrodo pernelyg daug MVP stadijoje. Thunkable generuoja React Native kodą, kurį galite skaityti ir keisti, leisdamas greitai prototipuoti mobiliųjų sąsajų dizainą ir sutelkti dėmesį į API integracijas.
- Nedidelių verslų savininkams, kuriantiems vidinius įrankius: galite apibūdinti savo darbo eigą paprastais žodžiais, gauti veikiantį prototipą ir publikuoti jį kaip žiniatinklio ar gimtąją mobilųją programą be atskiros kūrėjų komandos.
Netinkama: netechniniams vartotojams, tikintis visiškai be kodo ir be klaidų patirties. DI dažnai generuoja klaidingą kodą, o vykdymo klaidų taisymas reikalauja arba naudoti žetonus „Fix with AI“ mygtuke, arba savarankiškai redaguoti JavaScript.
Jei nesijaučiate patogiai spręsdamas klaidas arba skaitydamas kodą, dažni programos gedimai greitai jus atmuš.
Thunkable privalumai ir trūkumai
- DI generuoja programas per mažiau nei 3 minutes
- Rodoma gyva „mąstymo“ eiga generavimo metu
- Pagal numatytuosius nustatymus – švari, profesionali mobili vartotojo sąsaja
- Priima išsamius promptus (300+ žodžių)
- Visiška prieiga prie React Native kodo
- Versijų istorija kiekvienai DI iteracijai
- Publikavimas iOS, Android arba internete
- Atsisiųsti surinkimo failus (jokių platformos apribojimų)
- Apatinės navigacijos šablonai veikia sklandžiai
- Tema pritaikoma redaguojant kodą
- Paslaugų užklausų formos atvaizduojamos teisingai
- Integracijos galimybės: Airtable, Firebase, Google Sheets
- Žetonų sistema apsaugo nuo nenuspėjamų DI išlaidų
- DI dažnai generuoja klaidingą kodą
- Pritaikymui reikia redaguoti kodą
- Numatytasis saugojimo variantas – vietinis, ne debesies
- Žetonų išlaidos kaupiasi taisant klaidas
Išbandykite Thunkable nemokamai ir stebėkite, kaip DI paverčia jūsų mobiliųjų programų koncepciją veikiančiu kodu per mažiau nei 5 minutes. Jokių Swift, jokių Kotlin – tik jūs ir teksto laukas.
Thunkable funkcijos
- DI generuoja React Native kodą iš promptų
- Kelių ekranų programos su apatine navigacija
- Vartotojų autentifikacija ir rolės valdymas
- Formų konstruktoriai su išskleidžiamaisiais sąrašais ir validacija
- Versijų kontrolė kiekvienai kodo iteracijai
- Publikavimas iOS, Android arba internete
- Integracijos: Airtable, Firebase, Google Sheets, Xano
- Atsisiųsti APK/AAB failus diegimui
Mano praktinė patirtis su Thunkable
Tai mano išsamus pasakojimas apie Paslaugų užklausų portalo kūrimą naudojant Thunkable. Norėjau turėti pilną sistemą su vartotojo prisijungimu, informacine skydeliu ir veikiančia duomenų baze. Čia tiksliai aprašoma, kaip viskas vyko – kiekvienas paspaudimas ir kiekviena nusivylimo akimirka.
1. Pradžia: registracija ir pirmieji įspūdžiai
Apsilankiau Thunkable pagrindiniame puslapyje ir pirmas dalykas, kurį pamačiau, buvo didžiulis, minimalistinis raginimas veikti: „Paverskite savo idėją programa.“
Ekrano viduryje stovėjo didelis baltas tekstinis langas. Po juo buvo keturios siūlomos kategorijos, kad padėtų pradėti:
- Renginių planavimas
- Atsargų valdymas
- Kelionės
- Meditacija
Pastebėjau, kad paspaudus vieną iš jų teksto laukas automatiškai užsipildo pavyzdiniu aprašymu.
Tačiau nenorėjau šablono; norėjau sužinoti, ar DI sugebės įvykdyti sudėtingą, keliapakopį užklausą.
Bet kol dar nespėjau parašyti nė žodžio, norėjau susikurti paskyrą. Spustelėjau mygtuką „Sign up“ viršutiniame dešiniajame kampe.
Iššoko tvarkingas baltas langas, siūlantis tris prisijungimo būdus:
- Tęsti su Google
- Tęsti su Apple
- Registruotis el. paštu
Įvedžiau savo el. pašto adresą ir paspaudžiau mėlyną mygtuką „Sign up with email“. Thunkable šioje pradinėje fazėje nevartoja slaptažodžių.
Vietoje to naudojama „magic link“ sistema. Turėjau išeiti iš svetainės, atidaryti el. paštą naujame skirtuke ir surasti laišką iš „The Thunkable Team“. Paspaudžiau „Confirm“. Galiausiai buvau nukreiptas atgal į Thunkable prietaisų skydelį.
Pirmas dalykas, kurį pastebėjau prisijungęs, buvo tai, kad sąsaja yra be galo tuščia. Nėra jokių „Welcome! Let’s take a tour“ iškylančių langų, jokių mokomųjų vaizdo įrašų ir jokių erzinančių chatbotų, mojavusių man.
Ką apie tai galvojau:
Registracija vyko greitai, tačiau aš nesu magiškų nuorodų šalininkas, nes jos verčia peršokti tarp skirtukų. Tačiau pati sąsaja yra graži. Joje nėra gausybės mygtukų ar šoninių juostų – tiesiog vienas didelis prompto langelis žiūri į tave, todėl procesas atrodo ypač prieinamas tiems, kurie nežino, nuo ko pradėti.
2. Pirmasis promptas ir simbolių ribos
Grįžau į pagrindinį prompto ekraną, kad įvesti savo projekto detales. Norėjau sukurti „Paslaugų užklausų portalą“ namų savininkams.
Tai nebuvo tik paprasta užklausa; norėjau visavertės darbo eigos. Kelias minutes ruošiau ypač konkretų promptą, kad pamatyčiau, ar DI tiksliai vykdys mano nurodymus.
Be to, detalizavau duomenų struktūrą dviem lentelėms: „Paslaugų lentelę“ ir „Vartotojų lentelę“. Netgi apibrėžiau roles „Klientas“ ir „Administratorius“.
Mane nustebino, kad teksto laukas buvo labai dosnus. Įklijavau visą savo išsamų promptą, beveik 300 žodžių, ir jis manęs nenutrūko.
Niekur nemačiau nei simbolių skaitiklio, nei įspėjimo apie „maksimalų ilgį“. Tiesiog priėmė tekstą ir laukė mano veiksmo. Kai buvau patenkintas promptu, paspaudžiau raudoną mygtuką „Generate App“ apačioje.
Mano įžvalgos apie promptinimo procesą:
Ši dalis vyko sklandžiai. Atrodė visiškai natūraliai, tarsi rašyčiau darbo brifą laisvai samdomam specialistui. Patiko, kad galėjau labai tiksliai nurodyti duomenų stulpelius ir išskleidžiamųjų sąrašų parinktis, ir įrankis nesipainiojo.
Palyginti su kitais kūrimo įrankiais, kurie leidžia naudoti tik trumpą vienos eilutės lauką, Thunkable didelis teksto laukas iš tikrųjų skatina smulkmeniškumą. Jauti, kad nuo pat pirmos sekundės kontroliuoji dizainą.
3. Stebėjimas, kaip DI kuria: „Mąstymo“ fazė
Kai tik paspaudžiau Generate, ekranas patamsėjo ir pasirodė būsenos pranešimas: „Analyzing your request.“
Tai buvo įdomiausia viso proceso dalis. Vietoje įprasto įkėlimo sukimosi indikatoriaus Thunkable parodė gyvą DI „mąstymo proceso“ žurnalą.
Stebėjau, kaip DI suskirstė mano promptą į keturias aiškias kategorijas:
- Programos struktūra: pasirinko apatinės navigacijos maketą su trimis pagrindiniais ekranais: Pradinis, Nauja užklausa ir Profilis.
- Dizaino stilius: užfiksavo mano pageidavimą dėl „pagrindinės mėlynos spalvos“ ir „profesionalaus“ estetinio vaizdo. Taip pat pažymėjo tikslą – „švari, moderni sąsaja“.
- Pagrindinės funkcijos: nurodė komponentus, kuriuos ketina sukurti, įskaitant prisijungimo/registracijos sistemą, paslaugų užklausų formą ir skydelį su filtravimu pagal būseną.
- Duomenų struktūra: patvirtino, kad kuriamos dvi lentelės: users ir service_requests. Išskyrė stulpelius, tokius kaip id, service_type ir status.
Po analizės ekranas persijungė į pilnavertį kodo redaktorių. Stebėjau, kaip DI tiesiogiai rašo React Native kodą.
Kairėje juostoje matėsi failų kūrimas: App.js, theme.js, HomeScreen.js ir kt. Mačiau parašomas funkcijas handleSubmit, fetchRequests, toggleStatus.
Visas procesas nuo „Generate“ paspaudimo iki programos paruošimo užtruko beveik tiksliai tris minutes. Ekrano apačioje pasirodė mažas pranešimas: „Your app has been generated!“ ir atsirado mėlynas mygtukas „Preview“.
Ką apie tai galvojau:
Stebėti DI „mąstymą“ buvo neįtikėtina. Tai suteikė galimybę patikrinti, ar jis supranta mano užklausą, dar nepradėjęs rašyti kodo.
Šiek tiek keista naudoti „be kodo“ įrankį ir matyti 1 000 eilučių JavaScript kodo, bet tai iš tiesų įdomu, jei nori suprasti, kaip tavo programa veikia viduje. Tai pašalina bet kokį DI „juodos dėžės“ jausmą.
4. Pirmasis įspūdis: sugeneruotos programos apžvalga
Kai kūrimas baigėsi, paspaudžiau mygtuką „Preview“. Dešinėje pasirodė mobiliojo telefono emuliatorius.
Pirmasis įspūdis – programa atrodė labai švari ir „vietaine“. Ji neatrodė kaip mobilioji svetainė, o kaip tikra programa iš App Store.
Štai ką pamačiau:
- Skydelis: pirmasis ekranas – „Service Requests“ sąrašas su gražia antrašte ir perjungimo juosta su keturiomis skiltimis: All, Pending, In Progress ir Completed.
- Spalvų schema: visiškai atitiko mano nurodymus. Mygtukai – profesionali tamsiai mėlyna, o fonas – švelniai pilkas, kad baltos kortelės išsiskirtų.
- Navigacija: ekrano apačioje aiški meniu juosta su trimis piktogramomis: „Requests“, „New Request“ ir „Profile“.
- Išvaizda: akivaizdžiai profesionalus stilius. Šriftai – aštrūs, tarpai tarp elementų – vienodi, naudoti standartiniai mobiliųjų UI šablonai, kurie atrodo pažįstami.
Tačiau skydelis buvo tuščias. Neišgavai jokio „pavyzdinio“ duomenų įrašo, todėl sunku buvo įsivaizduoti galutinį vaizdą be rankiniu būdu pridėtų duomenų.
Mano pirma įžvalga: dizainas buvo tiksliai toks, kokio prašiau – profesionalus ir mėlynas. Nelabai apkrautas „gudrybėmis“, kas man patiko paslaugų portalui. Mane sužavėjo, kaip sklandžiai veikia skirtukai ir navigacija.
Vienintelis mažas priekaištas – būtų buvę gerai, jei būtų sugeneruota kelios netikros paslaugų užklausos, kad ekranas nebūtų toks tuščias iškart pradžioje. Tai padidintų „wow“ efektą.
5. Kai pradėjo kilti klaidos: klaidų taisymo ciklas
„Medaus mėnuo“ baigėsi akimirksniu, kai bandžiau bendrauti su programa. Paspaudžiau skirtuką „New Request“, norėdamas pamatyti formą, tačiau emuliatoriuje užtekėjo ryškiai violetinė dėžė su pranešimu:
Runtime Error: Your app encountered an error while running. Cannot read properties of null (reading ‘id’) at Line 433, Column 50. Error location: the ‘HomeScreen’ screen.
Dar nebuvau liestis kodo, o programa jau krito. Vis dėlto Thunkable, panašu, buvo tam pasirengęs.
Klaidų lange buvo didelis mygtukas „Fix with AI“. Jį paspaudžiau, DI grįžo į „mąstymo“ režimą, per 45 sekundes išnaujojo analizę ir perkrovė peržiūrą.
Pradinė klaida dingo ir pagaliau pamačiau „New Service Request“ formą. Ji atitiko mano aprašymą:
- Išskleidžiamasis meniu „Service Type“ su parinktimis Plumbing, Electrical ir kt.
- Didelis teksto laukas aprašymui.
- Datos pasirinkimo kalendorius.
- Išskleidžiamasis meniu „Urgency Level“.
Bet kai spustelėjau piktogramą „Profile“, atsirado antra klaida:
Runtime Error: Cannot read properties of null (reading ‘name’) at Line 949, Column 42.
Ką apie tai galvojau:
Ši dalis buvo nuvilianti. DI – puikus dizaineris, bet polinkių į klaidas jaučiuosi taip, tarsi jis būtų bugų gamintojo padalinys. Atrodo, kad jam sunkiai sekėsi su autentifikacijos logika: bandė gauti vartotojo vardą ar ID, kai jo dar neprisijungė.
Mygtukas „Fix with AI“ – galingas, bet tris kartus jį spaudinėti, kad pamatyčiau tris ekranuose – šiek tiek vargina. Sukelia įspūdį, kad programa dar nėra pasirengusi „gyvai“.
6. Žetonų ribos: kūrimo sąnaudos
Spaudinėdamas mygtuką „Fix with AI“, susimąsčiau, kiek tai man kainuoja. Savo paskyros nustatymuose radau skiltį „Tokens“.
Nemokamame plane turėjau 1 200 žetonų. Kiekvienas naujas generavimas ar kodo taisymas vartoja šiuos žetonus. 
Pastebėjau, kad po pirminės statybos ir dviejų „taisymų“ žetonų likutis sumažėjo apie 250.
Tai reiškia, kad sudėtingai programai su daugybe klaidų taisymo galite vieną popietę sudeginti nemokamų žetonų atsargas.
Mano įžvalgos apie žetonų ribas:
Sąžininga sistema, bet prie proceso prideda šiek tiek streso. Kiekvieną kartą spaudžiant „Fix with AI“ jaučiuosi tarsi mėtyčiau pinigus. Būtų geriau, jei DI taisymai nekainuotų žetonų, ypač kai klaidos kyla iš paties DI kodo.
7. Dizaino pritaikymas: be kodo vs. aukšto lygio kodas
Norėjau pakeisti dizainą be DI pagalbos. Paspaudžiau skirtuką „Edit“, tikėdamasis matyti drag-and-drop redaktorių, kaip įprastoje Thunkable platformoje. Vietoje to gavau tik kodą.
AI sugeneruotoms programoms „pritaikymas“ reiškia React Native kodo redagavimą:
- Spalvų keitimas: turėjau atidaryti theme.js failą ir pakeisti heksadecimines reikšmes, pvz., #0000FF.
- Mygtukų perkėlimas: reikėjo koreguoti Flexbox nustatymus CSS tipo kode.
- Kompentų pridėjimas: jei norėjau pridėti naują mygtuką, turėjau jį rankiniu būdu įrašyti į kodą.
Kol kas nėra jokio vizualaus „Design Panel“ su slankikliais ar spalvų parinkikliais AI sugeneruotoms programoms. Arba naudojate DI, arba rašote kodą patys.
Ką apie tai galvojau:
Tai buvo didžiulė staigmena. Tikėjausi, kad DI sugeneruos blokais paremtą programą, kurią galėčiau redaguoti vizualiai.
Gavęs žalią kodą, Thunkable iš esmės sako: šis įrankis skirtas kūrėjams, norintiems pradėti nuo paruoštų pamatų, o ne visiškiems pradedantiesiems, kurie nenori matyti nė vienos kodo eilutės. Tai padaro įrankį galingą, bet ir sudėtingą ne techniniams vartotojams.
8. Duomenys ir serverio pusė: kur yra mano duomenys?
Norėjau pažiūrėti, kaip saugomi duomenys. Kode radau šią eilutę viršuje:
const storageStrategy = ‘all-local’;
Gilyn radau, kad programa naudoja useQuery ir useMutation iš ‘platform-hooks’:
const { useQuery, useMutation } = require(‘platform-hooks’);
Iš pradžių buvo neaišku, kur iš tikrųjų keliauja duomenys. Ar jie lieka telefono atmintyje? Ar siunčiami į debesies duomenų bazę?
Štai ką sužinojau:
‘all-local’ strategija reiškia, kad duomenys saugomi vietoje įrenginyje, bet ne tikroje debesies duomenų bazėje. Tai tarsi pažangus localStorage panaudojimas, kuris atrodo kaip duomenų bazė (su užklausomis ir mutacijomis), bet iš tikrųjų tvarko duomenis laikinoje atmintyje.
Geras dalykas: kodas jau sukonstruotas taip, kad veiktų su realia duomenų baze – useQuery ir useMutation aiškiai paruošti darbui su backend’u.
Blogas dalykas: nėra prijungimo prie Airtable, Firebase, Google Sheets ar kitos debesies duomenų bazės. Jei vartotojas pateikia užklausą, ją matys tik to paties įrenginio savininkas. Duomenys dingsta išvalius aplikaciją arba persijungus į kitą įrenginį.
Kas nutiko, kai paklausiau „How do I connect a database?“
Nebuvau tikras, kaip prijungti realią duomenų bazę, todėl tą klausimą įrašiau pokalbių lange su pradiniu promptu, tikėdamasis, kad DI paaiškins procesą arba pasiūlys integraciją.
Vietoje to pamačiau kažką keisto. DI „mąstymo“ žurnale (rodoma vykdymo laiko metu) atsirado pranešimas:
„The user is asking ‘How do I connect a database?’ This is not a request to modify the code, but rather a question… However, based on my instructions, I need to return complete, updated code only.“
DI yra programuotas išvesti tik kodą, o ne paaiškinimus. Todėl vietoje atsakymo į mano klausimą jis suprato, kad tai kodo keitimo užklausa, per 13,6 sekundės „pagalvojo“ ir vėl sugeneravo kodą.
Tačiau pateiktas kodas beveik nesiskyrė nuo turimo: truputį pertvarkė vidinę struktūrą (ServiceRequestContext kontekstas ekranuose), bet išlaikė ‘all-local’ saugojimo strategiją.
Jis neperjungė manęs į debesies duomenų bazę ir nepasiūlė Airtable integracijos – tik šiek tiek perfunkcionavo vietinę saugyklą.
DI „mąstymo“ žurnalas net pripažino šį apribojimą:
„The appropriate response would be to explain that: 1. The current strategy is ‘local’ (no database) 2. To use a database, they need to migrate to ‘all-local’ strategy (which uses platform-hooks with useQuery/useMutation) 3. The ‘all-supabase’ strategy (cloud database with auth) is coming in a future release. However, I’m instructed to ONLY return code, nothing else.“
Kitaip tariant, DI žinojo, ko prašau, bet negalėjo paaiškinti – tik pateikti kodą.
Be to, debesies integracija („all-supabase“) dar nėra prieinama (paminėta, kad bus „būsimoje versijoje“), todėl DI susitelkė į vietinę saugyklą.
Mano požiūris į backend’ą:
DI kūrimo įrankis numatytai naudoja local-first metodą, kai demo versijoms tai tinka, bet ne daugelio vartotojų programoms. Labiausiai erzina tai, kad:
- DI neišklausė, kur norėčiau saugoti duomenis (Airtable? Firebase? Google Sheets?).
- DI negalėjo paaiškinti savo pasirinkimų – jis programuotas tik įvesti kodą, o ne diskutuoti apie architektūrą.
- Kodas atrodo pasiruošęs darbui su duomenų baze (useQuery/useMutation), bet iš tikrųjų tik apgaulingas localStorage sluoksnis.
Pagal Thunkable dokumentaciją teoriškai galima pakeisti storageStrategy iš ‘all-local’ į ‘all-supabase’ (tikrus debesies duomenis su autentifikacija), bet DI kūrimo įrankis kol kas neturi prieigos prie debesies strategijų.
Tikrasis klausimas: ar tai DI apribojimas, ar mano promptas nebuvo pakankamai konkretus? Jei būčiau parašęs: „Sukurk paslaugų portalą, kuris saugo užklausas Airtable“, ar DI būtų susitvarkęs? Galbūt, bet DI turėtų užduoti papildomą klausimą: „Kur norite saugoti duomenis?“ vietoje numatyto lokalumo.
9. Galimos integracijos: susiejimas
Nors DI manęs neautomatizavo, patikrinau platformą, kokias integracijas galima įdiegti rankiniu būdu:
- Airtable: debesies duomenų bazė su skaičiuoklės sąsaja. Puiku valdyti paslaugų užklausas tiek kūrėjams, tiek nenutechniniams administratoriams.
- Firebase: reali vartotojų autentifikacija ir duomenų sinchronizavimas tarp įrenginių.
- Google Sheets: paprastas duomenų sekimas, kurį gali pasiekti bet kuris vartotojas be kodo.
- Xano: išskalaujamas backend’as be serverių priežiūros.
- Backendless: vizualios duomenų ir vartotojų valdymo galimybės be serverio.
- Cloudinary: nuotraukų valdymas (pvz., nutekėjusio vamzdžio foto paslaugų užklausoje).
- Webflow: turinio sinchronizavimas tarp svetainės CMS ir programos.
- RevenueCat: programų vidinės prekybos ir prenumeratų valdymas.
Įrankiai yra – klausimas, kodėl DI jų nepanaudojo?
Žvilgtelėjau į DI „mąstymo“ žurnalą, kai klausiau „How do I connect a database?“:
DI žinojo apie šias integracijas, bet AI kūrimo įrankis ribojasi iš anksto apibrėžtomis saugojimo strategijomis („all-local“, būsima „all-supabase“). Jis nepasiūlė: „Kur norite saugoti duomenis?“ Arba „Airtable, Firebase, Google Sheets?“ – o pasirinko lokalumą kaip greičiausią sprendimą.
Ką apie tai galvojau: potencialas – didžiulis, bet DI kūrimo įrankis turėtų aktyviau klausti atsiliepimų apie integracijas. Vienas klausimas „Kur saugoti duomenis?“ būtų sutaupęs daug laiko.
10. Versijų kontrolė: saugumo tinklas
Vienas funkcionaliausių įrankių – Versijų istorija. Spustelėjus laikrodžio ikoną viršutiniame įrankių juostos kampe atsiveria šoninė juosta su kiekviena DI iteracija.
Matau laiko juostą:
- Service Request Portal with User Authentication (tas, kuris krito)
- „Fix null reference error“ (pirmasis taisymas)
- Connect database to application
Galiu peržiūrėti bet kurią versiją arba „Restore“ su viena užklausa.
Mano įžvalgos apie versijų kontrolę: geriausia patirtis, kokią mačiau bet kuriame no-code ar DI įrankyje. Leis eksperimentuoti be baimės – bet kuriuo momentu gali grįžti atgal.
11. Publikavimas ir diegimas
Kai programa atrodė paruošta, spustelėjau didelį mygtuką „Publish“ viršutiniame dešiniajame kampe.
Atsirado trys pagrindiniai pasirinkimai:
- Publikuoti iOS: siuntimo į App Store procesas (reikalinga Apple Developer paskyra).
- Publikuoti Android: generuojama APK arba AAB failas Google Play parduotuvei.
- Publikuoti web programą: gaunate URL, kad vartotojai galėtų naudotis programa per naršyklę be diegimo.
Taip pat yra „Download“ mygtukas, leidžiantis atsisiųsti Android ir iOS build failus. Tai reiškia, kad nesame įrankio nelaisvėje – nuosavybė lieka jums.
Mano įžvalgos apie publikavimą: srautas labai aiškus. Web programos parinktis atvira visiems. Galimybė gauti raw build failus suteikia profesionalumo įrankiui.
Bendra patirtis ir santrauka
Po kelių valandų darbo turėjau prototipą – prisijungimo ekraną, užklausų formą ir skydelį su statusų filtru.
Galutinė nuomonė:
Thunkable DI kūrimo įrankis – galinga pradžia, jei norite mobiliąją programą perkelti nuo idėjos iki veikiamos versijos per valandas, o ne dienas. Jis puikiai tinka idėjos įrodymui, bet ne stebuklingas sprendimas: tekste laukia klaidos, prieigos prie debesies integracijų reikalauja klaidų taisymo ir kodo redagavimo.
Jei jus tenkina greiti prototipai ir jūs nesibaiminate JavaScript klaidų taisymo bei žetonų sąnaudų, Thunkable – stiprus MVP spartintuvas. Tačiau jei tikitės tobulo, gamybai paruošto sprendimo be kodo – nusivilsite.
Thunkable kainodara ir planai
Thunkable siūlo keturis planus, pagrįstus DI žetonų limitais, projektų privatumu ir publikavimo galimybėmis.
Visi planai apima AI kodo generatorių. Pagrindiniai skirtumai – kiek galite kurti ir kur publikuoti.
| Plan | Price | AI Tokens | Projects | App Store Publishing | Best For |
|---|---|---|---|---|---|
| Free | $0 | 2,000 | 3 public only | No | Testing the platform |
| Accelerator | $19/mo | 20,000 | 5 public + 1 private | No | MVP prototyping |
| Builder | $59/mo | 50,000 | Unlimited public + 10 private | 1 active app | Launching your first app |
| Advanced | $189/mo | 100,000 | Unlimited everything | Unlimited apps | Agencies & product suites |
Paslėptos sąnaudos
Norint publikuoti programą, reikės Apple Developer paskyros ($99/metus) ir Google Play paskyros ($25 vienkartinis mokestis). Thunkable apie tai aiškiai neįspėja, bet be to programos nepakelsite į parduotuves.
DI žetonai mokamuose planuose atnaujinami kas mėnesį (neperkeliasi į kitą laikotarpį). Jei Accelerator plane išleisite 3 000 iš 20 000 žetonų, kitą mėnesį gausite naują 20 000.
Svarbu: jei prenumerata baigs galioti, publikuotos programos taps neprieinamos vartotojams, kol nepratęsite plano – nėra kaip „WordPress“ svetainė, kuri liktų gyva po atšaukimo.
Mano rekomendacija
Pradėkite nuo Accelerator ($19/mėn.), jei rimtai ketinate kurti. Nemokamas planas su 2 000 žetonų labai greitai išeikvojamas taisant klaidas, o verslui bent viena privati programa privaloma.
Sukūrę programą Thunkable, galite rankiniu būdu susieti ją su savo Django backend’u redaguodami API taškus gautame React Native kode.
Alternatyva Thunkable
Thunkable AI kodo generatorius – greitiems prototipams, tačiau jei siekiate tiksliai sureguliuotos mobiliųjų UI su pilna kodo kontrole, verta apsvarstyti FlutterFlow.
| Funkcija | Thunkable | FlutterFlow |
|---|---|---|
| Kūrimo būdas | DI generuoja kodą iš promptų | Drag-and-drop su Flutter valdikliais |
| Geriausia | Greiti AI prototipai | Tikslus UI su pilna kontrole |
| Kodo prieiga | Matomas React Native kodas, ribota redagacija | Pilnas Flutter šaltinis eksportui |
| Pritaikymas | Redaguojate kodą arba vėl prašote DI | 170+ komponentų + pasirinktinio kodo galimybės |
| Serveris | Numatytai – vietinė saugykla, ribota debesies | Integruota Firebase, pasirinktiniai API |
| Mokymosi kreivė | Lengva pradėti, sudėtinga taisyti klaidas | Šiek tiek statokas (reikia Flutter žinių) |
| Pradinė kaina | $19/mėn (Accelerator) | $15.60/mėn (Basic) |
| App Store publikavimas | $59/mėn (Builder planas) | $15.60/mėn (Basic planas) |
Rinkitės Thunkable, jei esate netechninis įkūrėjas, norintis greitai patikrinti mobilią idėją. Priimate klaidas ir turite žetonų biudžetą.
Rinkitės FlutterFlow, jei esate kūrėjas, siekiantis išeksportuoti skaitomą kodą, valdyti UI animacijas ir backend logiką.
Galutinis verdiktas apie Thunkable
Thunkable DI kūrimo įrankis suteikia tai, ką žada: veikiančias mobiliąsias programas per minutes iš paprasto teksto promptų.
Stebėti, kaip DI aiškina reikalavimus ir generuoja React Native kodą, iš tikrųjų įspūdinga, o versijų kontrolė leidžia eksperimentuoti be baimės.
Tačiau realybė tokia: klaidų taisymas užims daugiau laiko nei naujų funkcijų kūrimas. Vykdymo klaidos nuolat gadina nuotaiką, o žetonai tirpsta ant „Fix with AI“ bandymų, kurie neretai sukelia naujų problemų.
Tačiau jei tikitės be kodo, be klaidų, gamybai paruoštos programos – greičiausiai nusivilsite.
