Workflows: Android पर डेव टास्क ऑटोमेट करें, कोई सर्वर नहीं चाहिए

हर डेवलपर के पास वही छोटे-छोटे काम जमा होते रहते हैं: push के बाद टेस्ट चलाना, deploy होते ही डेटाबेस का बैकअप लेना, save पर फ़ॉर्मैट करना, build fail होने पर खुद को पिंग करना। लैपटॉप पर आप इन्हें CI runners, cron jobs और कहीं किसी सर्वर पर पड़ी कुछ shell scripts के ज़रिये जोड़ लेते हैं। फ़ोन पर आम जवाब होता है "यह नहीं हो सकता"। PocketCode इसे Workflows के साथ बदल देता है — एक इवेंट-ड्रिवन ऑटोमेशन इंजन जो आपको पूरी तरह डिवाइस पर ही Android पर टास्क ऑटोमेट करने देता है, न कोई सर्वर किराए पर लेना है और न ही क्लाउड में कुछ ज़िंदा रखना है।

एक workflow को बताना आसान है: एक trigger (IDE के भीतर कोई इवेंट, या एक शेड्यूल) और साझा context पर चलने वाले steps का एक क्रम। असली डेव वर्कफ़्लो बनाने के लिए इतना काफ़ी है — वैसे ही जिनके लिए आपको आम तौर पर एक CI pipeline खड़ी करनी पड़ती — ठीक आपके एडिटर, टर्मिनल और डेटाबेस मैनेजर के बगल में। इस मॉड्यूल की पूरी झलक आप Workflows टूल पेज पर देख सकते हैं।

बनाने के तीन तरीके

आपको कभी खाली कैनवास से शुरू नहीं करना पड़ता। मॉड्यूल आपको तीन शुरुआती रास्ते देता है:

तरीका	कैसे बनाएँ	उदाहरण
Template	8 बिल्ट-इन templates में से किसी एक पर Activate टैप करें	"CI/CD Pipeline", "Auto-Deploy on Push", "DB Backup on Deploy"
AI Generate	एक prompt टाइप करें, एक एडिटेबल ढाँचा पाएँ	"when push to main, deploy and notify" एक 2-step workflow बन जाता है
Editor	पूरे फ़ॉर्म के लिए "+" FAB टैप करें	bindings और retry policies के साथ शुरू से बनाएँ

किसी template को activate करने पर वह एक नए ID के साथ एक एडिटेबल कॉपी में क्लोन हो जाता है, ताकि आप मूल को छुए बिना उसमें बदलाव कर सकें।

Triggers: workflow को क्या जगाता है

Workflows IDE से बहते इवेंट्स को सुनते हैं। इंजन ऐप के आंतरिक इवेंट बस को subscribe करता है और हर इवेंट को एक trigger type से मैप करता है। कुल दस trigger types हैं:

Trigger	कब चलता है	सामान्य filter
Git push	एक पूरा हुआ push	branch ("main", "develop")
Git commit	एक नया commit	branch
File saved	एडिटर में फ़ाइल save होना	extension (".kt", ".ts")
App opened	ऐप का foreground में आना	—
Terminal command finished	एक टर्मिनल कमांड का पूरा होना	command pattern
Database query executed	एक query रिज़ल्ट आना	table name
Deployment completed	एक सफल deploy	provider ("vercel", "railway")
Deployment failed	एक असफल deploy	provider
Error detected	किसी दूसरे workflow का fail होना	workflow name / error pattern
Manual	कुछ नहीं — शेड्यूल से या हाथ से चलाएँ	—

केवल वही enabled workflows जिनका trigger type मेल खाता है, evaluation में आते हैं, और एक वैकल्पिक filter इसे केस-इनसेंसिटिव substring मैच के साथ और संकुचित कर देता है — तो main पर filter किया गया एक Git-push workflow बाक़ी हर branch को नज़रअंदाज़ कर देता है।

शेड्यूलिंग: आपके फ़ोन पर cron, कोई सर्वर नहीं

यहीं "no-server automation" ठोस रूप लेता है। manual trigger और एक जुड़े हुए schedule वाला workflow एक scheduled job बन जाता है। भीतर ही भीतर scheduler, Android के WorkManager को लपेटता है और दो मोड देता है।

Interval शेड्यूल एक periodic work request का उपयोग करते हैं। WorkManager की न्यूनतम सीमा 15 मिनट है, इसलिए इससे छोटे मान ऊपर की ओर clamp कर दिए जाते हैं। presets:

Preset	Interval
हर 15 मिनट	15 मिनट
हर घंटे	60 मिनट
हर 6 घंटे	360 मिनट

Cron शेड्यूल असली दिलचस्प हिस्सा हैं। PocketCode अपना ख़ुद का 5-फ़ील्ड cron parser देता है (minute, hour, day-of-month, month, day-of-week) — कोई बाहरी लाइब्रेरी नहीं — जो * wildcards, single values, N,M lists, N-M ranges और */N steps को सपोर्ट करता है। दो cron presets बिल्ट-इन हैं:

• रोज़ सुबह 9 बजे — 0 9 * * *
• साप्ताहिक, सोमवार सुबह 9 बजे — 0 9 * * 1

चूँकि WorkManager का periodic API असली cron व्यक्त नहीं कर सकता, हर cron run एक one-time job के रूप में शेड्यूल होता है जो पूरा होने पर अगली fire को फिर से arm कर देता है, जिससे cron अनिश्चित काल तक ज़िंदा रहता है। schedule एडिटर आपके expression से गणना किया हुआ एक लाइव "Next fire" preview दिखाता है, और parse fail होते ही "Invalid cron expression" के साथ लाल हो जाता है — save करने से पहले ही तुरंत feedback। इस वर्ज़न में parser जानबूझकर चीज़ों को सरल रखता है: महीने और दिन के नाम, ?, L, #, seconds और year सपोर्ट नहीं हैं। expression syntax में और गहराई तक जाने के लिए Workflows डॉक्स देखें।

शेड्यूल persist किए जाते हैं, और ऐप स्टार्टअप पर फिर से queue किए जाते हैं ताकि किसी process death से आपकी ऑटोमेशन चुपचाप ख़ाली न हो जाए।

विज़ुअल एडिटर

एडिटर एक पूरा फ़ॉर्म है: name, description, एक enabled switch, एक वैकल्पिक filter वाला trigger dropdown, और step cards की एक वर्टिकल लिस्ट जिन्हें आप फिर से क्रमबद्ध, edit या delete कर सकते हैं। एक step जोड़ने पर एक picker खुलता है जो Control flow (Wait, If / Else) और Actions में बँटा होता है — आठ action types, हर एक के साथ एक पठनीय लेबल और एक dynamic config फ़ॉर्म:

Action	फ़ॉर्म फ़ील्ड
Run command	Command
Notification	Title, message
AI analyze	Prompt, language (वैकल्पिक)
AI generate	Prompt, language (वैकल्पिक)
Git operation	Operation (commit/push/pull), branch, message
Deploy	Branch (वैकल्पिक)
Database backup	Command (वैकल्पिक)
Open file	File path, line (वैकल्पिक)

हर action step में collapsible Reliability और Conditional सेक्शन भी होते हैं (इन पर नीचे और बात)। जब तक आप ऊपर की बार में Save नहीं दबाते, कुछ भी डेटाबेस तक नहीं पहुँचता — apply और cancel local editor state पर काम करते हैं, तो आप खुलकर प्रयोग कर सकते हैं। Save तभी enable होता है जब workflow का एक name और कम से कम एक step हो।

एडिटर आज Wait और If/Else का एक स्तर उजागर करता है। इंजन ख़ुद Loop, Parallel और Try/Catch steps भी execute करता है, लेकिन इनके लिए एक विज़ुअल एडिटर एक ज्ञात follow-up है, कोई शिपिंग सतह नहीं — तो इन्हें इंजन-स्तर के building blocks मानें, ऐसी चीज़ नहीं जिसे आप अभी picker से खींचकर ला सकें।

Steps के बीच डेटा पास करना

Steps अलग-थलग नहीं चलते — वे एक context साझा करते हैं, और कोई भी value फ़ील्ड {{binding}} से किसी पिछले step का संदर्भ ले सकती है। सिंटैक्स:

Expression	किसमें बदलता है
{{var.<name>}}	एक context variable
{{step.<id>.status}}	किसी step का status
{{step.<id>.output.<field>}}	किसी step के output का एक field
{{step.<id>.error}}	किसी step का error message
{{item.<alias>}}	किसी loop के भीतर मौजूदा item
{{trigger.eventName}}	वह इवेंट जिसने run शुरू किया

जो expression resolve नहीं होता वह जानबूझकर एक empty string लौटाता है, ताकि किसी ऐसे step (मसलन किसी skip किए गए conditional branch में) की binding जो कभी चला ही नहीं, पूरे run को न उड़ा दे। Conditions इसी विचार पर बनी हैं: resolve किए गए values की तुलना equals, not-equals, greater-than, less-than, contains या is-null से करें, और उन्हें सामान्य and/or/not बूलियन logic से जोड़ें।

Reliability: retries, backoff और timeouts

जिस ऑटोमेशन पर आप भरोसा न कर सकें, वह ऑटोमेशन नहीं है। हर action step एक retry policy और एक timeout को सपोर्ट करता है, जो उस collapsible Reliability सेक्शन में दिखते हैं:

Setting	Default
Max attempts	1 (कोई retry नहीं)
Backoff strategy	Exponential
Initial delay	500 ms
Max delay	initial × 30
Timeout	कोई नहीं

Backoff fixed, linear और exponential रूपों में आता है (exponential दोगुना: 500, 1000, 2000, 4000…), हर एक max delay पर capped। Timeouts असली timeouts हैं — जब कोई fire होता है, तो step को timed out मार्क कर दिया जाता है। एक हल्की condition भी है जिसे आप किसी अकेले action से जोड़ सकते हैं: उसे एक value से bind करें, और जब वह value empty, false, 0 या null हो तो वह एक step skip हो जाता है — तो आप किसी अकेले step को पूरे conditional में लपेटे बिना उस पर gate लगा सकते हैं।

Run history जिसे आप जाँच सकते हैं

हर run अपने step results के एक पूरे snapshot के साथ persist होता है, जिसका मतलब है कि history crash से बच जाती है। Runs timeline runs को नए-पहले क्रम में एक status icon, timestamp, step count, duration और कुछ fail होने पर एक-पंक्ति error preview के साथ सूचीबद्ध करती है। किसी run पर टैप करने से एक step-by-step drill-down खुलता है: हर step का status रंग (success, failure, skipped, timed-out, running), step की duration, key=value जोड़ियों के रूप में render किया गया उसका output, और कोई भी error string।

Retention अपने-आप होता है — repository प्रति workflow नवीनतम 100 runs रखता है और 30 दिन से पुराना कुछ भी हटा देता है, ताकि history उपयोगी बनी रहे बिना असीमित रूप से बढ़े।

शुरू करने के लिए Templates

आठ बिल्ट-इन templates आम मामलों को कवर करते हैं, ताकि आप एक ही टैप में काम करती हुई ऑटोमेशन पा सकें — किसी एक को activate करने पर वह एक एडिटेबल कॉपी में क्लोन होता है, तो उसमें बदलाव करने से कभी मूल पर असर नहीं पड़ता:

• CI/CD Pipeline — push पर, टेस्ट चलाएँ, deploy करें, और आपको notify करें
• Auto-Deploy on Push — main पर push होने पर, deploy करें और आपको notify करें
• DB Backup on Deploy — deploy पूरा होते ही, डेटाबेस का बैकअप लें और आपको notify करें
• किसी workflow error पर, आपको notify करें और AI से fix सुझाने को कहें
• file save पर, Prettier चलाएँ (prettier --write .)
• file save पर, stage और commit करें (git add -A && git commit)
• main पर push होने पर, टेस्ट चलाएँ और आपको notify करें कि branch protected है
• हर commit पर, टेस्ट चलाएँ और आपको notify करें

इसे सादे शब्दों में बताएँ

अगर आप steps को हाथ से जोड़ना नहीं चाहते, तो AI Generator एक prompt को एक एडिटेबल workflow में बदल देता है। यह एक trigger अनुमान लगाने के लिए keywords पढ़ता है ("push", "deploy failed", "error", "save"…) और actions का एक क्रम ("deploy", "backup", "test", "format", "notify"…), फिर एक preview दिखाता है जिसे आप Save & enable या discard कर सकते हैं। "when push to main, deploy and notify" जैसा prompt main पर एक Git push से जुड़ा एक two-step workflow बनाता है। Generator के पास एक LLM-समर्थित रास्ता भी है जो आपके configured AI provider का उपयोग करता है और कुछ भी ग़लत होने पर चुपचाप heuristic parser पर fall back कर जाता है — तो आपको हमेशा एक preview या एक साफ़ "couldn't infer" संदेश मिलता है। उपलब्ध AI क्षमताओं के बारे में जानने के लिए हमारा pricing पेज देखें।

आपकी ऑटोमेशन आपके डिवाइस पर ही रहती है

Workflow definitions, run history और schedules आपके फ़ोन के एक local database में रहते हैं। Definitions को restore के लिए क्लाउड पर बैकअप किया जा सकता है, लेकिन आपकी ऑटोमेशन को चलाने के लिए क्लाउड में मौजूद कुछ भी कभी नहीं पढ़ा जाता — इंजन locally execute करता है, बस इतना ही। Run history और schedules बिल्कुल sync नहीं होते: history डिवाइस-लोकल है, और schedules WorkManager state हैं जो हर डिवाइस के लिए विशिष्ट होते हैं। आपकी ऑटोमेशन आपकी है, और यह वहीं चलती है जहाँ आप हैं।

PocketCode, Google Play की ओर बढ़ रहा है, एक पूरा ऑटोमेशन इंजन — triggers, फ़ोन-पर-cron शेड्यूलिंग, retries और एक विज़ुअल एडिटर — उसी ऐप में ला रहा है जहाँ आप कोड लिखते और ship करते हैं। अपने ख़ुद के डिवाइस पर इसे सबसे पहले आज़माने वालों में शामिल होने के लिए प्री-रजिस्ट्रेशन में शामिल हों।